Introduction

Over the past several years of hash(password) cracking, password analysis, and countless articles on compromised databases, I’ve learned three things for certain.  Most passwords aren’t hard to crack, people reuse  passwords, and no one is safe from having their account information stolen.

The world of password management is saturated with password managers, utilities, and tools, and yet none of them have seemed to catch on with enough popularity to have a drastic impact. Something such as Lastpass is fairly easy for me to use, yet I can’t hope to explain to my Grandma or non techie friends the intricacies of how to use it. Likewise the Yubikey is nice for two factor logins that support it, it can be configured to have a single long password. However the two factor option is limited in it’s uses, and having a single password regardless of it’s complexity for all accounts is an obvious no no.

So what could someone use that can hold multiple passwords or tokens, is easy to use and configure, and secure against being compromised if it were lost or stolen. Enter the Pass-pal

Development:

It has been six months since I started development on the Pass-pal. It first started out as a simple non-configurable USB device that would print out a static password when you pressed one of the four buttons. It has since morphed into a fully developed device, with an on-board clock, 10 buttons and able to hold 20 configurable two factor tokens or passwords (text).

Thanks to the ATmega32u4 development board it was easy to program the device  to print text on a PC as if it was a USB HID keyboard. The tricky part was coming up with a way to configure the device from a windows client that didn’t involve a programmer or flashing firmware every time I wanted to make a change. The result was a rewrite of the HID descriptors that allowed for the use of feature reports which I spoke about here. Once completed I was able to configure it using a simple windows program (as seen right).  If I wanted a button to print a password I simply updated the EEPROM on the device with the new password. When the button was pressed it simply looked in EEPROM for what to print and it typed it as if a human had typed it on the keyboard. This was the basis for future development.

Features:

Currently the Pass-pal can store 20 two-factor tokens (OTP) or passwords. By simply pressing or by holding down one of the 10 buttons the Pass-pal will  type out a OTP(One Time Password) or password the same as a standard USB keyboard. The benefit being that it requires no special drivers for use on a Windows, Linux, Mac, or even a PS3 for that matter.

Any of the 20 slots can be configured to print standard text up to 39 characters. If someone wanted button one to print an email address, and button two to print the password simply update the two buttons with that text, it’s as simple as that.

The tokens it supports are any RFC-6238 or RFC-4226 SHA1 based style tokens which are the bases for things like Google Authenticator, Lastpass, Battle.net two-factor, Symantec VIP, as well as many other password authentication modules.  Additionally it supports a Yubikey style token (however it can’t be registered with Yubico’s servers). Regardless of what the slot is set to do it can also be configured to append a Tab or Enter afterwards.

Security:

The concern I had was what if the device is lost or stolen? Unlike the Yubikey which only has one button the Pass-pal has a full ten, this lends itself perfectly to being able to have a pin entered before use. When the device is first plugged in it’s locked, the indicator light is red and none of the buttons can be used to type out passwords or tokens. Additionally the configuration software won’t connect while locked. Once the correct unlock pin is entered the indicator light shows green and the Pass-pal operates as normal. When setting up the device the user can set how many attempts are allowed for the correct pin to be entered, if it’s entered incorrectly to many times the EEPROM is wiped and all saved passwords and keys are erased. Additionally the Pass-pal will keep track of how many times an incorrect pin is entered, and will save the date and time of the last incorrect attempt. The next time the user connects to the configuration software they will be notified that incorrect attempts were made. The user can also elect to have a time out placed on the device. If one of the buttons are not pressed within a set amount of time the device will auto lock itself to help prevent unauthorized people from using it.

The configuration also allows a user to select which orientation they would like the buttons to be in. For example if a user wanted the buttons to be reversed this would allow someone to simply place the Pass-pal in a USB dock and still be able to keep the same button order (when it’s upside down).

Since the Pass-pal acts as a USB keyboard it is able to sense when the user enables caps lock, num lock, or scroll lock on their keyboard. The Pass-pal can be configured to auto-respond to such events by tying one of the lock buttons to a slot. For example caps lock can be configured to ‘emulate’ the pressing of button 4 on the Pass-pal. Once configured the user simply hits the caps lock key twice in secession and the Pass-pal will print out the value for button 4 as if the user actually pressed the button. This feature is great for someone who uses a certain password many times through out the day and doesn’t want to reach over and physically hit the button on the Pass-pal. This feature is disable if the Pass-pal is locked.

Future Development:

Firmware and software are mostly complete for the Pass-pal. The only remaining task is to begin development of a case. Available cases very greatly, from preformed molded plastic, to acrylic cut cases. Once completed I hope to allow for a range of colors for both the case, and it’s buttons.

UPDATE: CNC case design complete, several beta cases complete. Case will be composed of buttons, front, and back. The CNC files will be made available for free on the site once it’s up.

Open Source:

I’ve been asked if the Pass-pal will be open source. The current version of the Pass-pal firmware and software will be left closed source. However a version of the Pass-pal will be available that will be preloaded with the common Arduino Leonardo boot loader. Libraries will be made available that will allow someone to interface with a PC using the HID feature protocol, and to allow for development of their own password or token uses.  My hope is to allow the community to develop new and inventive uses for the Pass-pal hardware and host the firmware, software, and libraires on a dedicated site.

When will it be available?

Look for the Pass-pal to be submitted to Kickstarter or Indiegogo in the next couple months, once beta testing is complete.

Introduction:

‘Wired’ featured an online article titled “Google Declares War on the Password”. In the article Robert McMillan summarizes a paper set to release in IEEE Security & Privacy Magazine. The article talks about some of Google’s current account security solutions, namely two-step login (2sv). Which help protect a user’s accounts by requiring multiple forms of authentication. The focus however is on a method of protecting a users “bearer tokens” known by most as session cookies.

Having multiple authentication systems is great for protecting users at initial login. However it does little to protect them from man in the middle attacks, credential phishing, and cookie stealing.  This is what Google hopes to fix by implementing a technology known as “Identity Assertions”.

Identity assertions replace users traditional session cookie with a public/private key system combined with an out of band device such as a USB token.

The aforementioned IEEE paper (ISSN :1540-7993) states: “Our first implementation of such a solution is an experimental USB token for 2sv. The token speaks the USB HID protocol to appear like a “human interface device” with bidirectional communication abilities.” … “A higher level protocol specifies packet formats for obtaining signed assertions from this token, and can be exercised by application level code on the host OS.”

It’s not certain yet exactly how the browser will interact with the token, it’s suspected that it will have direct access to the token as Chrome already has an API for directly accessing a hardware device. This method would not require any additional software to be installed on the client machine, and two options exist for allowing data to transfer from the browser to the token. The first option would be that the token would present itself as a HID serial interface, which would easily allow for bidirectional data. The drawback with this is that the user would potentially require administrative access to install a serial device on the system. The second option (which I spoke about in my previous article) is to present the device as a USB HID keyboard, then use the devices feature report channel to exchange ticket information and identity assertions.

Implementation:

The question still remains as to exactly what these identity assertions are composed of. The inner works of the identity assertion are described in a  paper presented by Alexei Czeskis titled “Strengthening User Authentication through Opportunistic Cryptographic Identity Assertions” and a related web page “browserauth.net” authored by Dirk Balfanz of Google.

Id assertions - Credit Image Alexei Czeski

Czeskis paper states “The server uses the login ticket as the vehicle to communicate its view of the TLS channels ID to the ["USB token"]. The browser communicates the TLS channel ID directly to the ["USB token"]. If there is a man-in-the-middle between browser and server, these two TLS channel IDs will differ.” … “The ["USB token"] compares the two TLS channel IDs and will not issue an identity assertion if they differ, causing a login failure”.

In short the server sends a signed and encrypted packet that contains session information called a “login ticket” that only the server and USB token have keys for. As stated above the USB token compares the results from the server and the browser. If the token approves the connection it issues an id assertion to the requesting server.

The beauty of this approach is that there is very little impact from the user’s perspective other than the initial provisioning of the token, and of course the user has to remember to have the token with them should they need to login. There is also virtually no way for an attacker to compromise both a victim’s machine and the externally attached token.

Conclusion:

Personally can’t wait for a system such as this to be implemented. It virtually eliminates all methods of man-in-the-middle, session stealing, and phishing even if the users account login and password is compromised. Once the protocol is finalized it’s likely we’ll see a version of the Yubikey that supports it. I also hope to have this working in the security token I’m developing as well. Now if I could just get my bank to support it.

Update: After further research it appears NXP’s a7001 line of micro-controllers may be what the Yubikey NEO is using at it’s core. Anyone wanting to start development on their own token should be able to use this micro-controller once the standard is released.

Introduction:

Recently while working on a project I had the task of configuring a USB device using software on a client machine. The problem being that the USB device was basically nothing more than a USB HID keyboard. The configuration required sending at a minimum several hundred bytes from the PC to the device.  In my research I found two methods to make it work. The first method used a Morse code bit level style of flashing Caps, Scroll, and Num lock. Since any keyboard attached to the PC is able to see the output reports generated by the PC it is one method of sending data out to a keyboard as covered in this article ‘Leaking data using DIY USB HID device‘. The title of the article accurately describes how quickly data can be moved in this method. Which is approximately “1.24 effective bytes per second”. This equates to about 1024 bytes in a little under 14 minutes. A second method involves using a USB HID’s feature reports to transfer bytes directly over the HID protocol.  Thomas Cannon spoke about using this method in 2010, in his article ‘Data Leak Prevention Bypass‘. While this second method would be much faster than the first Thomas never actually releases any software or proof of concept. In the end the decision was easy, I went with the second method. After getting it working so that I could quickly and easily update my device it occurred to me that what I learned could easily be adapted to transfer data off a secured PC without so much as raising an eyebrow.

Background:

Modern USB keyboards use the HID(Human Interface Device) specification. In simple terms it is a protocol for sending data to and from a device. Data can be sent over three channels. The first being input reports (data sent from the device to the PC), second is output reports (PC to the device), and finally feature reports(which is bi-directional). The nice thing about HID Keyboards & Mice is that the OS will automatically install the necessary device drivers. Windows locks the ability to send ‘Output reports’, it will however allow you to send ‘Feature reports’. With the ability to send ‘Feature Reports’ to the device it is possible to transfer several bytes of data at a time from the PC to the “Keyboard”.

Application:

The first hurdle to using a USB HID Keyboard’s feature reports to transfer data is that a custom USB HID descriptor must be created for the device. The HID descriptor basically defines to the PC what it is, and what it supports. One of the elements to the descriptor defines feature request. After writing a custom descriptor the next step is to be able to save those bytes coming in over the feature reports to media that can easily be written to. The final step is client software to transfer the data from the PC to the USB device.

Since Thomas Cannon spoke of using a Teensy as his platform I decided to go the same route. I purchased both a Teensy 2.0 and a Micro SD adapter. The adapter can cleanly and easily be mounted to the Teensy (As seen in the image to the right). I removed the Teensy’s default descriptors for HID Mouse, Joystick, and Debug device,  and modified the descriptor for the keyboard allowing it to accept feature reports. Once the descriptors were complete AVR code was written to handle the reports, and transfer the data to a mounted SD card. (Note: The SD card is not mounted to the host PC, it is mounted locally to the Teensy). Functions were added to print out a file from the SD card as text, more specifically the VBS script stored on the SD card that was used to type out the application needed to transfer files from the PC to the USB. The final step was actually writing the application.

In short order I was copying files from my desktop to the SD card on the Teensy all without the PC ever seeing anything but a USB keyboard.

Implementation:

I’m releasing everything needed to setup your own data ex-filtrator. Firstly you’ll need a Teensy 2.0, a micro SD adaptor, and some pins. This should only set you back about $25, you’ll also need a micro SD card which is fairly cheep, a 8GB card can be found for as little as $10. Next you’ll need to download this ZIP file. The zip contains two files exfil.hex and exfil.vbs. You’ll need to save exfil.vbs( It must be named exfil.vbs) to the root directory of the SD card. Then mount the SD card into the adapter. The next step is to use the Teensy loader application to write exif.hex to the Teensy. If you’ve done everything correctly plug in the Teensy and you’ll be able to open up Windows notepad place your cursor on the blank page and double tap the CAPS lock button (hit Caps lock quickly in succession).  This signals the Teensy that you are ready to print out the VBS script from the SD. In under 30 seconds the Teensy will have typed out the VBS script. Save the notepad as exif.vbs, double click it and exfil.exe will be extracted to the the same directory.

Once the exfil.exe is extracted you simply run it and drag files onto it to copy them to the SD. The on-board Teensy LED will flash to signal that data is being transferred. The ex-filtrator application has been shrunk down as small as it can be. This means that it has very few “bells & whistles”, no icons, or version information. It has also been packed with UPX, a EXE compression utility. Warning: Some Anti-virus vendors will flag on ANY EXE packed with UPX, so be cautious if it is to be used on a machine using one of those types of AV. (An anti-virus safe version can be found below)

The maximum file size that can be copied is 2,097,120 bytes, or approximately 2MB (This could be increased but was intentionally limited). The application is auto throttling and will increase transfer speed if the USB device will support it. My calculations show a transfer speed of 10,600 bytes per second (about 2.7 min for a 1.7MB file).

Once you have all the files you want copied simply plug the micro SD into a card reader and the files will be stored in the root of the drive. File names longer than 8 characters will be auto-shortened to comply with 8.3 naming convention.

Conclusion:

I hope this demonstration shows how something as simple as a keyboard can be used to lose sensitive data. Most HBSS systems would not detect the transfer activity. GPO’s and machine hardening would prevent the addition of new hardware. However if the Teensy was programmed with the same VID & PID it may not be prevented.

FILES:

Exfil.zip  (Exfil.vbs, Exfil.hex)

Smaller Exfil.vbs file (12,120 bytes vs 13,869) This version is about 12.6% smaller, which makes if faster to type out into notepad from the Teensy, but adds an extra step. It outputs a zip file rather than the exe. The exe can be uncompressed from the zip using windows built-in unzip (right click, Extract All).

Antivirus safe version – This version (12,868 bytes) does not use a UPX packer that can sometimes be flagged by AV. It does require being unzipped after the VBS extracts it. IT MUST be renamed from avsafe-exfil.vbs to exfil.vbs when saving it in the root of the SD card.

Introduction:

The human mind is an amazing thing, while incredibly complex it still follows a basic blueprint. As much as we like to think of ourselves as unique, and endeavor to be unique, we all as a whole tend to follow patterns. Take for example the small word puzzle to the right. Asides from the obvious circled passwords you probably quickly saw several other words or potential passwords. You may have even saw some words that while randomly generated look like a word. This all stems from the fact that humans are excellent at pattern recognition, and as such well suited to follow patterns. You may be wondering what all this has to do with your password? Well while you may be the only one to think of the password “$up3rP@$sw0rd1″ (superpassword in leet speak). You can certainly bet that some one else has used a ‘P’ followed by a ‘@’ before in their password. This is where the statsprocessor comes into play. The statsprocessor works in two parts. The first part is to profile a given dataset such as a password dictionary. This is done by using hcstatgen. Hcstatgen generates a statistics file by doing a frequency analysis of the dataset as well as positional statistics of characters within the dataset. This works very much like the Markov model with positional character statistics overlaid. The second part is the statsprocessor which uses the statistics file to create candidate passwords and allows you to tune how much time you want to spend searching a given keyspace by setting a threshold.

Application:

The reason statsprocessor is so powerful is that it allows someone to bruteforce a keyspace that before was not feasible. It does this by removing all of the low probability passwords and only trying statistically higher probable passwords. For example if you were to bruteforce all upper, lower, special and digits at length 8 that would be 95^8. Which is a staggering 6,634,204,312,890,625 combinations, it would take 18.4 hours at a rate of 100 billion combinations per second. However using statsprocessor with a threshold of 48 would only generate 28,179,280,429,056 combinations, it would only take 4.69 mintues to bruteforce this keyspace. Not only can this reduce the keyspace it also promotes the cracking of more hashes initially due to the nature of the positional occurrences. It effectively bruteforces the highest probable passwords eliminating those less likely to occur.

To get started download the latest version of hashcat-utils, select 64 or 32 bit version associated with your OS, and find your favorite password dictionary. Once it’s downloaded and extracted you can run hcstatgen. I’ll be using the ever popular ‘rockyou‘ list from SkullSecurity.

root@erebus:~# hcstatgen.bin rockyou.hcstat < rockyou.txt
Reading input...
Writing stats...

You should now have a 32MB file called rockyou.hcstat, this hcstat file contains the frequency  and positional analysis of all the passwords from rockyou.txt. This stat file can be used with statsprocessor, oclHashcat-lite, and oclHashcat-plus. All three tools have the following similar options:

--markov-hcstat        Specify hcstat file to use, default is hashcat.hcstat (excluding statsprocessor)
--markov-disable       Disables markov-chains, emulates classic brute-force
--markov-classic       Enables classic markov-chains, no per-position enhancement
--markov-threshold=NUM Threshold when to stop accepting new markov-chains

In addition to being supported by plus, lite, and statsprocessor oclhashcat-plus supports it in attack modes -a3, -a6, and -a7. So for example you could run the following -

root@erebus:~#oclHashcat-plus64.bin -a6 hashlist.txt --markov-hcstat=rockyou.hcstat rockyou.txt -j]]] ?a?a?a -t 20

This would try each word in the rockyou dictionary while truncating 3 characters from each word(-j]]]), then bruteforce all upper, lower, special, and digit (?a) of length 3 at the end. While using the rockyou.hcstat file that was created above (–makrov-hcstat). This normally would take a long time however with the addition of -t 20 this lowers the combinations to a reasonable timeframe. This value could be raised or lowered depending on your GPU(s). The nice thing is you can create a hcstat file for a password dictionary that is assciated with a language or subject type you are targeting. Another good use is to create a hcstat file from the cracked hashes of a list your still targeting since your current cracked list will contain keywords or frequencies associated with the uncracked hashes.

DG

Update to Tahiti:

It’s been about a year and a half since version 2.0 of Erebus was assembled. The lot of 6970 cards has served me well over that time. It was however time for a bit of an update. With the release of ATI’s Tahiti chipset it offered an upgrade over the current Cayman cards. The 7970′s supported stock core clock speeds of 925Mhz vs the 6970′s 880Mhz, and 2,048 stream processors over 1,536 cores. There was some concern with the new cards having 3GB per card vs 2GB with the older cards, but was later found not to be an issue. With all the 6970′s removed and the 7970′s in their place the core count went from a total of 12,288 to 16,384. With the cards in place the only update that was needed was an update to the current ATI drivers.

Benchmarks:

The new cards of course brought with it an increase in hash cracking speeds. Below shows the difference in speeds from 6970′ to 7970′s.  The full set of benchmarks can be seen here. Note: V2.5 is using v0.10 of oclHashcat-lite.

To give you an idea how fast that is, it would take 12hrs to brute force the whole key space for any upper, lower, special, or digit password at length 8 for NTLM. The true magic with the updated chipset is the increase in multi-hash speeds. Now with even 2M hashes I’m seeing speeds of 20B/sec. No other updates are planned for a now, but should be more than enough speed for the next year or so.

DG

Introduction:

It never surprises me the lengths some people will go to be lazy. Lately I’ve been doing password audits of networks with surprisingly decent password policies. Such as requiring a minimum length of 15 characters, and at least 2 of each upper, lower, special, and digits. Surely with such a stringent policy you wouldn’t expect to be able to crack any of the passwords. This however wasn’t the case thanks to two techniques that users have to promote their laziness, keyboard walking, and password doubling. In this two part article I’ll be covering how to attack those password and what methods can be used to prevent it..

Method: Keyboard walking

In part 1 I’ll be covering keyboard walking, this is the act of creating a password that is composed of a string of characters that move in a row or pattern on the keyboard. Common examples might be 1qaz, !@#$, ZAQ!, and 1234, I call these short strings “character sets”. It’s not certain if users think they are being smart, or they are just being lazy the fact remains that most patterns are pretty simple and are composed of only 3 or 4 characters. Using the four character sets above, and depending on the password policy a user may come up with something like ‘1qaz1234ZAQ!!@#$‘. This password meets all the complexity requirements, it’s greater than 15 characters, and has two of each character type. The problem is that if we knew the user used those 4 character sets we would only have to try at most 4^4(256) combintations to find the password (actually only 110 combinations contain an upper, lower, special, and digit).  In my testing I have found about 229 common length 4 character sets, if we wanted to build every combination of length 16 characters it would be 229^4 = 2,750,058,481 combinations. Given a standard desktop CPU could do 10M guesses a second it would take less than 5 minutes to compute every possible combination.

I see keyboard walking as being most prevalent in Active directory domains. In order to audit these the first step is to extract the hashes from the SAM database on the domain controller. I use a tool called fgdump, the output from this tool is saved as a pwdump file and it contains User name, User ID, LM hash, and NTLM hash, in a colon delimited format. Hopefully you will see “NO PASSWORD” in the LM field otherwise don’t bother with the NTLM as the LM’s can easily be cracked using rainbow tables. Depending what cracking tool your using you may have to extract the NTLM hashes from the pwdump file. Hashcat tools accept hashes only, so to extract the NTLM hashes do:

root@erebus:~# grep -v -h \$ 127.0.0.1.pwdump | sort -u | cut -d: -f4 > ntlm.hash

The command greps the file 127.0.0.1.pwdump for all hashes not containing $ (which are machine accounts), pipes it to sort using the unique switch, it is then piped to cut using a colon as a delimiter and selecting the 4th field, outputting to the file ntlm.hash. Conveniently JTR will accept the pwdump format directly. I will be using JTR to attack most of the keyboard walking accounts because JTR supports wordlist on stdin. I built a custom perl script that will allow you to pass keyboard combinations directly to JTR’s stdin, the script can be downloaded here. Here is an example of its usage:

root@erebus:~# perl keywalk-gen.pl 4 4
-pl,-pl,-pl,-pl,
-pl,-pl,-pl,-pL<
-pl,-pl,-pl,!@#$
-pl,-pl,-pl,!@34
-pl,-pl,-pl,!Q@W
..... <CTRL>+c to stop

The script will output every combination (1,387,488,001) of keyboard walks within the character set selected. In the example above character set 4 was selected, with a multiple of 4. This combination would give you 16 character password guesses. If the password policy you were auditing only required 12 character passwords you may try keywalk-gen.pl 4 3. You could also use the keywalk-gen script to build a dictionary by redirecting output into a file, but why waste hard drive space on a dictionary when words can be built on the fly and piped to stdin. Here is an example of the syntax used for JTR:
root@erebus:~# perl keywalk-gen.pl 4 4 | john.exe --stdin --format=nt 127.0.0.1.pwdump
Loaded 1264 password hashes with no different salts (NT MD4 [128/128 SSE2 + 32/32])
Remaining 1003 password hashes with no different salts
1qaz1qaz!QAZ!QAZ (user476)
1qaz1qaz@WSX@WSX (user808)
1qaz!QAZmko0MKO) (user1167)
1qazZAQ!2wsxXSW@ (user508)
1qaz2wsx@WSX1qaz (user950)

From the example above 1264 NT MD4(NTLM) hashes were loaded.  Using my laptop it took 22 minutes to generate all 1.38 billion combinations. This technique could also be applied to any algorithm that JTR supports. In addition this could be used to pipe plains into oclHashcat-plus and apply rules to the keywalk patterns, or attack harder algorithms such as md5(crypt). Just remember that oclHashcat-plus only supports up to 15 characters plains as an input so keywalk-gen.pl 4 4 would be to large. Run keywalk-gen.pl without any arguments to see all of the characters sets available to choose from. Protip: Use the gate tool from Hashcat-utilites, splitting the wordlist among mutliple cores or computers as was discribed in “Multicore dictionary support in JTR using Hashcat utilities.”

Conclusion:

Hopefully it’s easy to see how vulnerable those keyboard walk passwords are. Next I’ll be covering how to attack doubled passwords and what steps we can use to help prevent it.

Links: keywalk-gen.pl

Introduction:

As a change of pace from the usual articles on how to crack passwords, I thought I’d show a method for making them harder to crack. In last weeks article ‘does password padding make your password more secure‘ I showed that adding a simple repeating character or characters to a password doesn’t necessarily make it more secure. The problem wasn’t that someone was adding characters, it was that they might have used repeating or patterned characters as their padding. So the question is how do we add complexity without lowering entropy.

Method:

It occurred to me that people are generally able to memorize simple pins, or numbers like in a phone number. However one of the worst things someone could do is simply add numbers to a password. Adding numbers to a base password is nearly as bad as adding a repeating pattern. Using a dictionary hybrid attack an attacker could bruteforce appending and prepending digits while simultaneously using dictionaries as a base word. It also occurred to me that people tend to write long or complex passwords down, which is also a concern. So if adding numbers is bad, and writing them down is bad what if you combine the two? The result is something I call the password pad. Surely many variations of this idea already exists, but none that I’ve seen are so simplistic.

The idea is not to remember a long complex high entropy password, or to be so insecure as to write them down or use simple padding. Instead one would use a small “password pad” to increase the size of an already used password.

As an example lets say you use Pass123 as your login password for a web site. This is an obvious bad password as it contains a dictionary word, it’s short, and is followed by a very common series of numbers. So instead of using 123 directly we could use our password pad to extend the complexity of the password.

On our sample password pad 1 = CY?, 2 = =45, and 3 = :Vh. So rather than having Pass123 we have PassCY?=45:Vh.  This increases our password complexity substantially. Not only are we now using characters from all character sets but the length has increased from 7 to 13. Even using a hybrid attack where ‘Pass’ was the base word, ‘CY?=45:Vh’ would take a prohibitively long time to try to bruteforce. Sounds simple enough but you may be wondering what if someone else uses the pin 123? The uniqueness comes from the fact that no two people’s “password pad” is the same. The sample pad I used was generated from the key “password”. Ideally you wouldn’t use something as simple as that, likewise you could use a randomly generated key. Thus everyone that has a pad will have different randomized characters for each digit on the pad. To create your own password pad use the generator below.

Password Pad Generator:

Conclusion:

Once your password pad has been generated you can print it out and put it in your wallet, stick on your monitor, save it as an image on your desktop or in your email, you could even msg it to your phone. Or keep it safe so it’s an easy way to have 2-factor authentication -something you have, and something you know. The pad is unique to the key that generated it, and has adequate entropy. It also allows you to chose digits that the password policy allows for, an example would be if a site only allows 10 characters then choose less padding digits that allow it to fit. Here are some do’s and do not’s.

Do -

• Choose a unique key to generate your pad
• Use a known password in addition to the pad
• Select at least 3 different digits from the pad that as a whole have at least one character from each character set
• Use a different pin for each web site login

Do not -

• Use only the pad to compose your entire password
• Write your base password on or near your pad
• Just add the padding to the end of your base word

Some other suggestions might be to use it as method for agreeing on a pre-shared key between two people without actually passing the plain text password. Use the 4 character pad option on the generator for better security. Mentally reverse some character sets from the pad to increase obfuscation. If you ever lose your pad you can generate the same one by using the same key. I’m sure there’s lot of other ideas you can come up with on your own just be creative.

(UPDATE!) Over the weekend I put together a windows executable version of the password pad. It can be downloaded here.The windows version allows you to generate a pad exactly like the php version. It also allows you to click the pad numbers and it will fill in the box below, click copy to clipboard and paste where ever you need it. Anyone interested in helping me develop a iphone/android app equivalent please contact me.

DG

Introduction:

I was listening to a recent security podcast in which this weeks episode included the topic of passwords, and a suggestion for increasing password strength while reducing its complexity. The method roughly involves appending or prepending various amounts of repeating characters or patterns to a sufficiently complex base password. For example using the base password:

W3akP@$$ —> W3akP@$$///////

This seems simple enough and from a strictly mathematical perspective the padded password is substantially more secure. Of course there are numerous methods for padding a password that can make it more complex yet still memorable such as using a series of “/\/\/\/\” rather than “///////“, but does doing this really add that much security? Today I’ll be covering how to attack those password, and find out if it really is more secure.

Method:

There are two common misconceptions I see that people often make regarding passwords and how they are cracked. One being they assume that there are only two methods of attacking a password, those being a bruteforce or a dictionary attack. The second misconception is that they don’t understand the difference between an online, and an offline attack. An online attack is when a program sends a username and password to a server checking the response each time for success. An example of this would be a routers admin interface, and the attack would ideally be done on a device which doesn’t have a lockout policy. This type of attack is usually very slow, and in this case generally the only options are dictionary and bruteforce.

However an offline attack is usually against a large database of password hashes such as a SAM(Security Account Manager) database from an active directory domain, or a SQL database from a forum. There can be hundreds or even millions of password hashes in this database. An offline attack can also be done against a single hash such as a WPA key. Unlike an online attack there are many different ways to attack the password hashes. The attack types includes but not limited to bruteforce (with or without positional mask), dictionary (with or without mutation rules), dictionary combination (with or without mutation rules), and finally hybrid ((dictionary and bruteforce), with or without mutation rules). In the case of password padding the important ones are those that allow us to use rules.
If you read my article “Rule-Fu: The art of word mangling” you may recall the “Z” and “z” rule. These rules basically append or prepend a character N amount of times to the base dictionary word.

Example: Using the rule – Z2 W3akP@$$ becomes W3akP@$$$$ and for z2 W3akP@$$ becomes WWW3akP@$$

It’s easy enough to create a rule set (a file containing one rule per line) that varies the number of appending or prepending characters, to do this I downloaded the latest version of the mask processor from here. Using that I ran the command (Ubuntu 64): (Mask processor uses the same syntax as oclhashcat)

root@erebus:~/maskprocessor-0.63# ./mp64.bin -1Zz -2123456789 ?1?2 > pad.rule


This output every combination of Z or z with 1-9 into a file called pad.rule. This simple rule file is only 18 lines and is probably not very effective. But what if the the last character of the dictionary word wasn’t the one the person padded it with, as in our first example W3akP@$$///////. For that we have to append and prepend every possible character to the original password using two separate commands like so:

root@erebus:~/maskprocessor-0.63# ./mp64.bin -1?l?u?s?d -2123456789 \$?1Z?2 > pad2.rule
root@erebus:~/maskprocessor-0.63# ./mp64.bin -1?l?u?s?d -2123456789 \^?1z?2 >> pad2.rule


In these commands we assign upper, lower, special, and digit to variable 1, variable 2 is assigned 1-9. In Linux \ escapes out the $ and ^ on the command line. Note that the second command has two > so as to append to the file rather than overwrite. The file pad2.rule should now contain 1710 rules to append and prepend every combination of upper, lower, special digit at lengths 1-9 to the base word in a dictionary. Running the rules with a decent dictionary should take a couple minutes if using hashcat or seconds if using oclhashcat-plus. You could even be creative and do a combination of both appending and pre-pending in a single rule.

Example: The rule ^/z4$\Z4 applied to W3akP@$$ becomes ////W3akP@$$\\\\

Now if you’ve been able to keep up with me so far you’ll quickly see that padding a password with a single repeating character doesn’t effectively increase it’s strength, especially if your using a base password found in a dictionary. It’s important to point out that a dictionary doesn’t mean a word you might find in the Oxford dictionary, instead it’s any word that closely matches a word from a list of already cracked passwords. The reason I say “closely matches” is because a dictionary word real or not can be easily modified using rules to covert something like monkey into M0nk3y!.

As a fix you may say instead of using a single repeating character use an alternating set such as ()()()() or 101010. Well there is still one more problem. After talking to Atom the creator of the hashcat suite of tools we came up with two new rules, the Y and y rules. Both are now in version 0.37 of hashcat and will be added to other versions shortly. The Y and y rule append and prepend N charcters from the base password.

Example: The rule $/$\Y2Y2 applied to W3akP@$$ would give us W3akP@$$/\/\/\

As before we can use the mask processor to generate every combination of alternating characters, example:

root@erebus:~/maskprocessor-0.63# ./mp64.bin -1?l?u?s?d \$?1\$?1Y2 > pad3.rule
root@erebus:~/maskprocessor-0.63# wc -l pad3.rule
   18050

Here the variable 1 is assigned all upper, lower, special, and digit, and the rule Y2 is statically assigned. The result is a rule file with 18,050 combinations of two characters that can be appending then doubled. Adding prepending rules would only bring pad3.rule up to 72.2k rules.  Anyone that’s ran my 30k list of rules on the GPU knows that it only takes a few minutes to run, even with a 5.6 million word dictionary. So having a 36k rule set that appends or prepends a repeating set of characters really wouldn’t take that long.

Conclusion:

So does password padding really increase the strength of a password? It really boils down to the method in which you do it. Simply adding repeating characters to it or alternating characters surly isn’t enough. What I’ve hopefully shown here is that there still need to be sufficient level of randomness to your password. The rules I generated were rather simplistic, and with a little thought they could be more effecent and encompassing. To top it off hashcat now supports the –stdout switch, rather than using the more complicated –debug mode. This means you can easily run a dictionary with tables through hashcat passing them through stdin to oclhashcat-plus, effectively having double mutations.

Example: password –> hashcat + tables –> p@$$w0rd –> oclhashcat-plus + padd3.rule –> p@$$w0rd/\/\/\/\

DG

Links: pad1.rule, pad2.rule, pad3.rule, oclhc+rules.rule(30k), hashcat-0.37, maskprocessor

Introduction:

Project Erebus has been in a constant state of change over the past several months. What initially started off as a system with 6 water cooled Nvidia GTX 480′s in a over the top gaming motherboard has morphed into a system with 8 ATI 6970 cards housed in a rack mounted server case. While I don’t think it’s safe to say the transformation is complete it has certainly reached a precipitous. In the ever changing world of computing the bar of performance, and speed are in a constant state of escalation. What one days is top of the line, the next is just old news. At least for a short while I have the honor of setting the bar in some respects, even if it is a losing battle.

The build, V 1.0

Erebus version 1, was composed of a EVGA SR-2 Classified motherboard and 6 water cooled GTX 480′s running at 1504Mhz. Water cooling was done so that all 6 cards could fit into the 7 available PCI express slots. The intention was to leave the center slot open for the Magma expansion bay.  The Magma PCI-E expansion chassis provided room for several more cards, however a limitation of the SR-2′s 32bit BIOS prevented more than 8 total cards. The chassis was fitted with two Galaxy O/C cards running at 1520Mhz, slightly faster then the EVGA cards, but not requiring water cooling. With regards to a full Nvidia system this was one of the fastest personally owned single systems at the time. Any application capable of accessing multiple cards was able to utilize all 3,840 stream processors available in all 8 cards.

Version 1.5

In an effort to increase the available bus speed and the hopes that all 10 slots of the TYAN FT72-B7015 motherboard could be used an order was put in with RenderStream a company based out of Austin TX. The board it’s self is much larger than even the already large SR-2. However the bare bones system consist of an entire chassis and power supply. Simply moving the memory, processors and hard drives over to the Tyan board I was up and running in Ubuntu in no time. At nearly the same time Nvida had released the GTX 580′s increasing clocks speeds and unlocking all 512 stream processors from the GF110 core. Immediately 4 EVGA GTX 580 hydro-coppers were ordered with the plans to order 4 more once they were in stock. It was at that time I discovered that in fact not all 10 slots could be used on the Tyan board, even using the Magma expansion bay.  

There was some issues initially with getting all 8 cards to work, but once the BIOS was configured correctly both Windows 7 and Ubuntu 64 were able to detect all 8 cards. The system consisted of 4 GTX 480′s and 4 GTX 580′s any attempt to add another card regardless of the type would cause the system not to post, it had seemed as if the BIOS was unable to address all cards. Once again I was limited to 8 cards, it was a rather big disappointment because I hoped to be able to use the expansion and have a system with potentially 10 or 11 cards. Then there were rumors that Nvidia was to release the GTX 590′s essentially 2 under clocked 580 cores housed on one double slot card. This would give me the potential to have 16 total cards. However shortly before the release of the GTX 590′s I had decided to make a some what dramatic decision.

Version 2.0

After a short discussion in my frequented IRC channel I immediately searched and found a good price on 8 ATI 6970′s. There was some initial concerns if the Tyan motherboard would support ATI cards at all. I only knew of a small handful of people that had ordered the RenderStream system and no one that I was aware of had even tried ATI cards in the system. All the Nvidia cards were removed and the 6970′s were installed. At first I thought that Ubuntu could only detect 6 cards, but as it turns out there was some issues with aticonfig correctly detecting everything.  Manually setting the necessary configs got everything working and the results have been nothing but positive.

Results:

My first test consisted of running a new oclHashcat Beta application called oclHashcat-lite. Oclhc-lite is targeted at new users of the oclhc series of tools. Without the need to learn all the details of regular oclHashcat. In addition oclhc-lite was optimized for single hash performance utilizing the benefits of round reversal and various other hashing algorithm short cuts and GPU techniques to achieve the highest overall possible speeds. First up was the MD5 hashing algorithm the bench-press of benchmarks immediately showed us results just shy of what was predicted.  Here are the results of the test.

To date these are some of the highest speeds achieved by a single personally owned machine.

Video of oclhc-lite record runs

Multi-hash performance obviously suffers and drops down to 14.8B/sec with 6500 hashes in MD5 using regular oclhc. The setup is relatively new and I plan to continue doing several benchmarks and post them here. For now I’m overall pretty pleased with the setup. For the test that I’ve ran ATI has surpassed Nvidia with ease. The only drawback I foresee is having to run a separate Nvidia system to support those CUDA only apps. Many thanks to those that have helped me iron out the kinks and to Atom for make such wonderful elegant tools

DG

Introduction:

As GPU horsepower continues to increase the time it takes to bruteforce a given keyspace continues to shrink. Cracking a seven character upper, lower, digit, special hash in bruteforce mode used to take as long as 6 months using JTR on a single core CPU. However times have changed and a sufficiently fast system with several GPU’s can bruteforce that same keyspace in as little as two hours or less today. Even with a fast system attacking those 9+ length password can still be a challenge, and can take longer than a security audit can allow for. This is where profiling your hashlist can help target a large majority of hashes, and it can also reveal a password policy trend. For example some password policies state the password must be at least 8 characters, contain at least one uppercase, special character, and digit. From this users typically will capitalize the first letter, and add a special character and number to the end. So today I’ll cover a simple utility that can help you target a smaller keyspace that should increase the likely hood of finding the most passwords.

Method:

The method I’ll be covering uses a Linux environment but most of it can be adapted to Windows. The first step is to download PACK(Password Analysis and Cracking Kit)  a set of python scripts developed by iphelix.  The next setup is to download the latest version of oclHashcat from Hashcat.net. A supported ATI or Nvidia card is required in order to use oclHashcat/cudaHashcat. If you don’t have a supported GPU, this can also be adapted to PasswordsPro  for the CPU but I won’t be covering that here.

In order to use PACK you will need a system that supports python of course, it also uses a python extensions called psyco. Psyco isn’t requried and line 8 and 9 in dictstat.py can be commented out or deleted if you don’t have it.

To get an idea of how it works here is the output after running dictstat.py on ‘rockyou‘ dictionary:

# python dictstat.py -f rockyou.txt

[*] Analyzing dictionary: rockyou.txt
[+] Analyzing 100% (14344391/14344391) passwords
NOTE: Statistics below is relative to the number of analyzed passwords, not total number of passwords

[*] Line Count Statistics...
[+] 8: 20% (2966004)
[+] 7: 17% (2506264)
[+] 9: 15% (2191000)
[+] 10: 14% (2013690)
[+] 6: 13% (1947858)

[*] Mask statistics...
[+] stringdigit: 37% (5339715)
[+] allstring: 28% (4115881)
[+] alldigit: 16% (2346842)
[+] othermask: 05% (731240)
[+] digitstring: 04% (663975)

[*] Charset statistics...
[+] loweralphanum: 42% (6075055)
[+] loweralpha: 25% (3726656)
[+] numeric: 16% (2346842)
[+] loweralphaspecialnum: 03% (472673)

[*] Advanced Mask statistics...
[+] ?l?l?l?l?l?l?l?l: 04% (688053)
[+] ?l?l?l?l?l?l: 04% (601257)
[+] ?l?l?l?l?l?l?l: 04% (585093)
[+] ?l?l?l?l?l?l?l?l?l: 03% (516862)
[+] ?d?d?d?d?d?d?d: 03% (487437)

The output has been trimmed a bit as the output can be rather long. Each [*] section shows the analyzed dictionary in different aspects separately. We can see based on the “Line Count Statistics” that 20% of words are 8 characters, “Charset statistics” show that 42% of all words are loweralpha numeric. Based off this information it would be safe to assume that if you were to bruteforce lowercase and digits up to length 8 you would find the majority of your passwords. The nice thing is that the “Advanced Mask statistics” directly correspond to the format used by oclHashcat’s predefined mask.

Of course it’s easy to analyze a dictionary of already cracked passwords. The hard part is starting with a uncracked hashlist. So the first step is to do an initial run on your hashlist using a standard dictionary. Using oclHashcat+ with a dictionary and a good rule list will likely get you to a good starting point. Depending on if you have a ATI or Nvidia card will determine if you use cudaHashcat+ or oclHashcat+. If you haven’t yet used ocl/cudaHashcat+ you may want to read this over. For example my command was:

./cudaHashcat+64.bin -r ocl+rules.rule -m1000 -n160 -o found.out hashlist.hash /dict/rockyou.txt

In a recent pentest this attack alone netted 26,336 out of 222271 NTLM hashes, or about 11%. From this we were able to determine that the password policy for the company required at least 8 character, with at least one upper, lower, special, digit. From there the password were moved into a dictionary like so:

# cut -b 34- found.out | sort -u > found.dic

From there we can use dictstat:

# python dictstat.py -f found.dic

[*] Analyzing dictionary: found.dic
[+] Analyzing 100% (26336/26336) passwords
NOTE: Statistics below is relative to the number of analyzed passwords, not total number of passwords

[*] Line Count Statistics...
[+] 8: 78% (20683)
[+] 9: 15% (4150)
[+] 10: 03% (1048)
[+] 11: 01% (355)

[*] Mask statistics...
[+] stringspecialdigit: 74% (19652)
[+] othermask: 23% (6287)
[+] stringdigit: 01% (353)
[+] stringdigitstring: 00% (22)

[*] Charset statistics...
[+] loweralphaspecialnum: 53% (14133)
[+] mixedalphaspecialnum: 44% (11708)
[+] mixedalphanum: 01% (377)
[+] upperalphaspecialnum: 00% (91)

[*] Advanced Mask statistics...
[+] ?l?l?l?l?l?l?s?d: 17% (4616)
[+] ?l?l?l?l?l?s?d?d: 13% (3622)
[+] ?u?l?l?l?l?l?s?d: 12% (3300)
[+] ?u?l?l?l?l?s?d?d: 08% (2247)

Using the (truncated) output from dictstat like before we can target those mask that would get us the most return. Keeping in mind that we can use custom mask to target more than just the preset mask.
 
# ./cudaHashcat64.bin --remove -o found.out -n160 -m 1000 hashlist.hash -1 ?l?u? -2 ?s?d -3 ?l?s -4 ?d?s ?1?2?2?2 ?2?3?4?4

Conclusion:

This is just an easy way to reduce the time taken to bruteforce a given keyspace. In the above example there are 19,393,941,834,332 combinations instead of 6,634,204,312,890,625. This of course means that it will drastically reduce the amount of time to run the attack. Of course it’s not likely to find all the hashes, it is however another technique that can be kept in the arsenal. The scripts in PACK can of course be used for several other things such as reports for managment. The README is helpful for the various other switches and options.

Links:

PACK – Password Analysis and Cracking Kit
oclHashcat+/cudaHashcat+
Regular oclHashcat/cudaHashcat
PasswordsPro