Monday, December 28, 2009

Cracking Mac OS X Passwords

In this post I will demonstrate how to both extract and crack Mac OS X passwords. The OS X variants that this tutorial is aimed at are 10.4 (Tiger), 10.5 (Leopard) and 10.6 (Snow Leopard).

Whilst Mac OS X is based on a Unix variant (BSD), there are several key differences between traditional Unix-based and Mac OS systems when it comes to password storage. Lets take a quick look at some of the differences.

If you have ever poked around on an OS X system, you may have noticed the absence of the /etc/shadow file. Whilst traditional Unix and BSD variants store their password hashes in /etc/shadow and /etc/master.passwd respectively, Mac OS X does not. Since the release of OS X 10.3 in 2003, Macintosh products have stored their shadow files in the /var/db/shadow/hash/ directory.

Another key difference is the way in which the two systems store their hashes. On a Unix-based system, every hash associated with the system is stored in the /etc/shadow file. This differs from OS X whereby each user has their own individual shadow file stored in the /var/db/shadow/hash/ directory. Each file is labeled by the user’s Globally Unique Identifier (GUID). N.B. A GUID is analogous to a Security Identifier (SID) on Windows-based systems.

Lastly, most Unix variants will use multiple rounds of the MD5 or DES cryptographic hash functions in order to encrypt system passwords. OS X systems encrypt passwords with the SHA1 hash function, coupled with a 4 byte salt.

In sum, OS X password storage has the following characteristics:

  • Password hashes are stored in the /var/db/shadow/hash/<GUID> file
  • Each user has their own shadow file
  • Local OS X passwords are stored as SHA1 hashes


So, the first thing we want to do in this exercise is find out what our GUID is. We do this by invoking the Directory Service command line (dscl) utility. Implemented in OS X 10.5 to replace the deprecated NetInfo directory service, dscl uses the Open Directory Framework to store, organise and access directory information. For our purposes, the directory service holds information specific to each user on the system.

The command we use to extract our GUID is as follows:

Note: Replace <username> with the username of the user you wish to extract.

10.4 (Tiger)

# niutil -readprop . /users/<username> generateduid

10.5 (Leapord) and 10.6 (Snow Leapord)

# dscl localhost -read /Search/Users/<username> | grep GeneratedUID | cut -c15-

This should return a value which appears in the following format: A66BCB30-2413-422A-A574-DE03108F8AF2


Next, we want to extract the SHA1 hash from the shadow file. For this, we do the following:

# cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 | cut -c169-216

Note: Replace the above GUID with the one you have extracted from the previous step.

You should have been returned with a SHA1 hash that looks similar to the following: 33BA7C74C318F5D3EF40EB25E1C42F312ACF905E20540226

At this point it should be noted that OS X has the ability to store Window NT and LANMAN hash representations. This will only occur if SMB/CIFS file sharing has been turned on. To extract these passwords from the shadow file, type the following:


cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 |cut -c1-32


cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 |cut -c33-64


At this point we are ready to crack the OS X passwords. To simplify this step, I have written a simple python script that can be downloaded here. To use this script, simply copy and paste the contents into a file ( and type:

#python bob

Note: 'bob' is the username whose password we want to crack.

This method is nice if you are only interesting in cracking passwords from a local system. If, however, you have captured a hash from a remote system, or would prefer a more familiar password cracking utility, then John The Ripper can also be used for this step. In order for John to work, John will need to be patched with the 'Jumbo Patch' - allowing SHA1 passwords (referred to as XSHA in John) to be cracked. The patch can be downloaded from the following locations:

Once we have download/patched John, the extracted hash and username should be placed in a text file. For this example I have added the username ‘bob’ and bob’s hash (that I obtained in STEP 2) into a file called sha1.txt. The file has the following format:


We can then use John the crack the password:

# ./john sha1.txt

If John is successful in recognising the hash, the following message will be displayed:
”Loaded 1 password hash (Mac OS X 10.4+ salted SHA1 [32/64])”

A successful cracking attempt will appear as follows:

password (bob)
guesses: 1 time: 0:00:00:00 100% (2) c/s: 153000 trying: password

Additional Resources

Sunday, December 13, 2009

Bypassing Anti-virus

Whether compromising a system for legitimate or non-legitimate purposes, bypassing anti-virus software is often an integral step in any intrusion exercise. Fortunately for enterprise, anti-virus and anti-malware software is now commonplace in most organisiations.

Whilst many of the tools that attackers wish to implement are constantly being blacklisted, this isn't without reservation. Attackers are still getting malware into systems and penetration testers are still able to compromise systems. So the question is, how is this possible? The answer: Bypassing anti-virus, of course.

In this post I intent to present several tools that can be used in bypassing anti-virus/anti-malware software. I will provide a brief background on each tools operation and a summary of its use. But first, some background.

Anti-virus software typically works by using either signature-based detection or heuristic-based detection (some products use both).

Signature-based detection products rely on receiving updates from the anti-virus vendor. Anti-virus vendors such as McAfee, Symantec, Sophos etc. work 24 hours a day 7 days a week to continually update their databases with newly discovered malware. Every time a new piece of malware is identified, a 'fingerprint', or 'signature' of the malware is made. These uniquely identifiable signatures are periodically downloaded by anti-virus clients and are used to identify malicious files. Software that the vendor has identified as malicious is able to be caught by the anti-virus software because an infected file's 'signature' (or fingerprint) matches that of the signature downloaded from the vendor. Signature-based detection can be seen as analogous with making a comparison. ie We compare the infected file's signature with the signatures I have in my database. Do the signatures match? If they do, we know the program is malicious and it goes into quarantine. If not, the program is safe and we can let the program run.

Heuristic-based detection is somewhat different. In the mathematics and computer science disciplines, the term heuristic can be simply described as a 'best guess'. Instead of making a signature comparison, heuristic-based detection looks at what the software is actually doing, as opposed to what it looks like. Based on behavior, heuristic-based products quarantine software that is acting suspiciously. So if a program is misbehaving by trying to elevate its privileges on a system, there is a possibility it may be flagged for quarantine. Heuristics-based detection is often prone to false positives, and as such, is not as common as it's signature-based counterpart.

Now lets talk about their shortcomings of signature-based detection.

Signature-based detection is overcome by something known as obfuscation. Code obfuscation is the process of changing the appearance of a program's source code. This can be done in many different ways, including: substituting for loops for while loops; eradicating loops with recursion; compression techniques; renaming variables; altering strings; and so on.

So now if we think back to how signature-based detection works, we can quickly see that it is near impossible for an anti-virus vendor to blacklist all the possible combinations of how a program can appear. And here in lies the dilemma. Anti-virus vendors can indeed continue to blacklist known malware, but this falls short reasonable quickly when programs can be obfuscated in a myriad of different ways.

Whilst there a many ways one can obfuscate a program's code, I am only going to discuss three here. These are three of the most common and simple tools for achieving anti-virus avoidance.

UPX Packer
Packing is a simple way to disguise executables. By adding a decompression header to the front of a the packed executable, the executable is able to be read and inflated in memory by the operating system.

The Ultimate Packer for eXecutables (UPX)
is a free, open source, portable packer written by Markus F.X.J. Oberhumer, László Molnár and John F. Reiser.

upx [-123456789dlthVL] [-qvfk] [-o file] file...

-1 compress faster -9 compress better
-d decompress -l list compressed file
-t test compressed file -V display version number
-h give more help -L display software license
-q be quiet -v be verbose
-oFILE write output to 'FILE'
-f force compression of suspicious files
-k keep backup files
file.. executables to (de)compress
PE-Scrambler is a simple utility written by Nick Harbour that scrambles and obfuscates binaries at the machine code instruction level. Altering the Opcodes at the lowest level, this utility is a highly effective obfuscator.

> pescrambler.exe -i [inputfile.exe] -o [outputfile.exe]

Interview with the author
Author's presentation on the tool

These two tools come standard with the Metasploit Framework. Whilst in previous versions of Metasploit it required a bit of a hack to obfuscate Metasploit payloads, the latest release (3.3) makes the process trivial. I would like to point you to Adrian Crenshaw's posting on IronGeek for this one. He has recently posted a very nice video tutorial on the process.

So, what was the point of me telling you all this? Was it to tell you that anti-virus software is dead and you should just uninstall it completely from your network? Hardly.

My intentions here were to inform people that anti-virus, like all security controls, has its weaknesses. Anti-virus should no longer be looked at as the be all and end all of end-point system protection. It should be, like every other control, one of multiple mechanisms within a multi-tiered security architecture.

Here are some additional controls that can compliment anti-virus software:

Host-based intrusion prevention/detection systems
Host-based firewall logging (Win)
Host-based firewalling (Unix)
Application white-listing

Additional Resources:
Chris Brenton's talk on why AV is dead