Sunday, September 18, 2011

Cracking OS X Lion Passwords

UPDATE [2011-10-15]:
The issues described in this post have now been resolved by Apple. Users running OS X Lion 10.7.2 or security update 2011-006 are no longer affected by the vulnerabilities detailed below (CVE-2011-3435 and CVE-2011-3436). For further details on this security update please see Apple's advisory.

In 2009 I posted an article on Cracking Mac OS X passwords. Whilst this post has been quite popular, it was written for OS X 10.6 and prior. Since the release of Mac OS X Lion (10.7) in July, I have received numerous requests for an update. Typically, I would have just updated the existing article without the need for a new post. However, during my research I discovered something interesting about OS X Lion that I'd like to share.

In previous versions of OS X (10.6, 10.5, 10.4) the process to extract user password hashes has been the same: obtain the user's GeneratedUID and then use that ID to extract hashes from a specific user's shadow file (See my previous post for a more detailed description).

When it comes to Lion, the general premise is the same (albeit a few technical differences). Each user has their own shadow file, with each shadow file stored under a .plist file located in /var/db/dslocal/nodes/Default/users/.

The interesting thing when it comes to Lion's implementation, however, is privilege. As mentioned above, all OS X versions are using shadow files. For the unfamiliar, a shadow file is that which can only be accessed by users with a high privilege (typically root). So for all modern OS X platforms (Tiger, Leopard, Snow Leopard and Lion) each user has their own shadow file (hash database) whose data is accessible only by the root user… or at least it should be.

It appears in the redesign of OS X Lion's authentication scheme a critical step has been overlooked. Whilst non-root users are unable to access the shadow files directly, Lion actually provides non-root users the ability to still view password hash data. This is accomplished by extracting the data straight from Directory Services.

If we invoke a a directory services listing on user bob by specifying the /Local/ path we can see bob's standard profile information:

$ dscl localhost -read /Local/Default/Users/bob

This provides us with nothing too exciting. However, if we invoke the directory services listing using the /Search/ path, we see a different result:

$ dscl localhost -read /Search/Users/bob

From the output, we can see the following data:


62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060

Note: The SHA512 hash is stored from bytes 32-96 (green) and the salt is stored from bytes 28-31(red). For more information on these hashes please see this thread.

This ShadowHashData attribute actually contains the same hash stored in user bob's shadow .plist file. The interesting thing about this? root privileges are not required. All users on the system, regardless of privilege, have the ability to access the ShadowHashData attribute from any other user's profile.

Due to Lions relatively short time on the market, I am yet to find any of the major crackers supporting OS X Lion hashes (SHA512 + 4-byte salt). To simplify the cracking of these hashes I have created a simple python script which can be downloaded here.

Now, if the password is not found by the dictionary file you're out of luck, right? Well, no! Why crack hashes when you can just change the password directly! It appears Directory Services in Lion no longer requires authentication when requesting a password change for the current user. So, in order to change the password of the currently logged in user, simply use:

$ dscl localhost -passwd /Search/Users/bob

And voilĂ ! You will be prompted to enter a new password without the need to authenticate.

There has been some conjecture surrounding the severity of these attacks. Whilst the ability to change the currently active user’s password is not a privilege escalation flaw per se, it can under some circumstances be used for these purposes. Allow me to provide a scenario:

A user with administrative rights is browsing the internet with Safari. The user happens to browse to a website hosting a malicious Java Applet. Unbeknownst to the user, they allow the innocent looking Java Applet to run. The Applet will proceed to make a connection back to the attacker, providing the attacker with full shell access. Whilst the attacker has access to the system, they are provided only with limited user privileges (they still do not have root access). This would limit what an attacker could accomplish. However, with the vulnerabilities described above the attacker now has an advantage:  they can change the password of the current user. Now remember, the current user is an administrator. So now all the attacker has to do is sudo –s  to become root. If lets say the victim did not have administrative rights, the attacker still has the ability to extract user hashes from the system and attempt to crack them.

As a temporary measure to mitigate these attacks (before Apple release a patch), it is recommended to limit standard access to the dscl utility. The can be done as follows:

 $ sudo chmod 100 /usr/bin/dscl

Thursday, April 21, 2011

Attacking LM/NTLMv1 Challenge/Response Authentication

In Part 1 of the “LM/NTLMv1 Challenge/Response Authentication” series I discussed how both the LANMAN/NTLMv1 protocols operate and the weaknesses that plague these protocols. In this post I will demonstrate how attackers leverage these weaknesses to exploit the LANMAN/NTLMv1 protocols in order to compromise user credentials.

For the remainder of this article I will be focusing on attacking the SMB protocol (Windows file sharing) as this is where LANMAN/NTLMv1 is most commonly used.

Capturing the Response

In order to capture a client’s LANMAN/NTLMv1 response, attackers will often utilise one of two methods:

  1. Force the client host to connect to them
  2. Conduct a man-in-the-middle (MITM) attack and “sniff” the client’s response

To demonstrate these methods, I will be using the Metasploit Framework or Cain and Abel respectively.


In order for a client host to connect to us, we first need to create a listening SMB service that will accept incoming connections. Fortunately, the Metasploit Framework has already provided us with a module to do this :)

1. Fire up Metasploit

2. Load the SMB server module

msf > use auxiliary/server/capture/smb

3. Set the server host address

msf > set srvhost x.x.x.x

4. Run the module

msf > run


Now that we have a listening SMB service, all that is needed is for a victim to connect to our machine. By calling “info” on the SMB server module, the module’s description explains “The easiest way to force a SMB authentication attempt is by embedding a UNC path (\\SERVER\SHARE) into a web page or email message.”

A successful capture will look something like this:


Cain and Abel

The second method we can use to capture a client’s response is by conducting a MITM attack using Cain.

1. Start Cain’s sniffer

2. In the “Sniffer” tab, select the “Plus” icon and choose the hosts victims to poison.


3. Activate Cain’s ARP Poison Routing feature

4. Select the bottom “Passwords” tab and wait for the client’s response to appear in the left pane under “SMB”.


Cracking the Response

Three approaches are often referenced when cracking a LANMAN/NTLMv1 response:

  1. Rainbow Tables
  2. Dictionary Attack
  3. Brute Force

All of these methods use what is known as the “known challenge attack” technique. In order to crack the LANMAN/NTLMv1 response we are exploiting the fact that the only randomness (or entropy) that makes the LANMAN/NTLMv1 response unique every time is the challenge sent by the Server. As the attacker is always the Server, we can send the client a static challenge. This effectively defeats any randomness in the protocol. Because we now know what the challenge will be every single time, we can effectively crack the LANMAN/NTLMv1 response as if it were a static response.

Note: It is common practice to use \x11\x22\x33\x44\x55\x66\x77\x88 as the static challenge.

Before we look at each of these methods it should be noted that LANMAN responses are only configured on Windows XP and Server 2003 system (by default). Windows 7, Vista and Server 2008 systems are configured to utilise NTLMv2 by default.

A simple test to check which protocol is currently in use is to see if the LM Hash and NT Hash are different in the capture logs. A difference in these hashes would indicate LANMAN is in in use. If these hashes are the same, LANMAN is disabled and NTMLv1 is in use.



1. Rainbow Tables

As you would remember from Part 1 of this series, the difference between LANMAN challenge/response and NTLMv1 is that the former uses the locally stored LM Hash whilst the latter uses the locally stored NT Hash. This fundamental difference makes a substantial difference when it comes to cracking the LANMAN response. Because LANMAN utilises the weaker LM hashing algorithm, an attacker can trivially obtain the plain-text of a LANMAN response within minutes.

The quickest approach to cracking the LANMAN response is by using rainbow tables. Due to the nature of the LM Hash, rainbow tables are very effective against this hash type. The rainbow tables necessary for this exercise are called “halflmchall” and can be found here. To use these rainbow tables the rcracki_md tool will need to be downloaded.

The following rcracki command will inflate the rainbow table chains and attempt to find the plaintext password for the LANMAN response:

> rcracki_mt.exe –h b4dfbf8fa9eaac3 "C:\rainbowtables\*.rti”

Note: We are only cracking the first 8 bytes of the captured LANMAN response. Due to the nature of the LM Hash, we are only able to use rainbow tables on the first portion of the LANMAN response. The rest we will have to use brute-force.

A successful result will look like this:


The remaining characters we can brute force using the Metasploit “halflm_second.rb” script. This can be found in the “tools” directory in the root Metasploit directory. The script is run as follows:

# ruby halflm_second.rb –n 5b4dfbf8fa9eaac3d939df32af8c61a0c122288e90918896 –p ADMINIS

Where –n is the LANMAN response and –p is the discovered plaintext.

Whilst it is possible to crack an NTLMv1 response using rainbow tables, I have yet to come across any that have been pre-computed. Due to the nature of NT Hashes, NTLMv1 rainbow tables would be far more time consuming to generate and require large amounts of disk space.

2. Dictionary Attack

The second method often used to crack LAMNAM/NTLMv1 responses is a dictionary attack.

I will demonstrate the dictionary attack using two common tools:

  • John the Ripper
  • Cain and Abel

John the Ripper

The following syntax is used to mount a dictionary attack against LANMAN responses:

# ./john –format:netlm /tmp/capture.txt

Where capture.txt is the file containing the LANMAN response. The format of capture file must be as follows:


Where test is the username, home is the workgroup/domain, the first hash is the LM Hash, the second hash is the NT Hash and the final value is the challenge.

To use john against NTLMv1 specify netntlm with the -format flag.

Cain and Abel

If Cain was used to sniff the capture, right click on the entry and select “Send to Cracker”.


In the “Cracker” tab, right click on the entry and choose your appropriate option from the “Dictionary Attack” menu option.


Note: For a list of dictionary files see my post on wordlists.

If you did not capture the response using Cain, and are importing a capture file, the file must be in the following format:


3. Brute Force

Whilst crude, brute-forcing can be effective against weaker passwords.

To brute-force in Cain, follow the steps detailed above and select “Brute-Force Attack” from the menu item.

For the sake of brevity, I will not go into how John the Ripper can brute-force hashes. This is quite a lengthy topic in itself. Further reading on this topic can be found using Google.

Wednesday, April 20, 2011

LM/NTLMv1 Challenge/Response Authentication Explained

The Microsoft Windows platform uses a myriad of protocols to authenticate users across a network. Two such protocols widely in use today are the LANMAN challenge/response and NTLMv1 protocols. Whilst newer, more secure protocols (such as NTLMv2) are ready to take their place, LANMAN challenge/response and NTLMv1 are still widely deployed today for reasons of interoperability. As with most things Microsoft-related, ubiquity often equates to exploitability.

In this two part series I will discuss how the LANMAN challenge/response and NTLMv1 protocols operate, how malicious users can take advantage of their shortcomings, and best practice recommendations for securely deploying these protocols.

Microsoft Windows supports two primary algorithms for locally authenticating users. These algorithms generate what’s known as an “LM Hash” or an “NT Hash”.

Enabled by default in Windows NT, 2000, XP, and Server 2003, the LM Hash has become synonymous with bad hashing practices over the years. Used for backward compatibility, this older hashing method has several inherit flaws, making it trivial for attackers to crack LM Hashes within minutes.

The second, more secure, hashing algorithm generates what’s known as an NT Hash. Exclusively on by default in Windows Vista, 7, and Server 2008, this hash is generated using the MD4 hashing algorithm.
Note: By default, Windows XP stores both the LM Hash and the NT Hash.

Whilst this reading does not require a technical understanding of how the NT Hash and the LM Hash are generated, some readers may like to broaden their understanding of how these hashes are generated. The following paper provides an in depth discussion on the topic.

Before we begin looking at the Microsoft network authentication protocols, it is important to note that LANMAN challenge/response and NTLMv1 are the same protocol except for one key difference: LANMAN challenge/response utilises the locally stored “LM Hash” whilst NTLMv1 uses the locally stored “NT Hash”. Aside from this, the protocols (for all intensive purposes) operate exactly the same way.

The LANMAN challenge/response and NTLMv1 protocols authenticate users in the following manner:
1. Client sends an authentication request to the Server.
2. A protocol negotiation occurs between the Client and Server.
3. The Server sends the Client a (pseudo-random) 8-byte challenge.
4. The Client sends a 24-byte response.
5. The Server authenticates the Client.
The Client’s response is made up of the following steps:
  1. Split the locally stored 16-byte hash (LM Hash for LANMAN challenge/response or NT Hash for NTLMv1) into three 7-byte portions.
  2. Using the DES encryption algorithm, encrypt the Server’s challenge three separate times using each of the keys derived in Step 1.
  3. Concatenate the response of all three outputs.
Now, at first glance this protocol seems fairly sensible. But you may have noticed something in Step 1 of the Client’s response. If the hash (LM or NT) is 16-bytes long, how do we break it up into three 7-byte portions? i.e. 7 does not divide into 16 evenly.
To combat this unevenness, the LANMAN and NTLMv1 algorithms pad the third key with 5 nulls. By doing this, we now have three evenly portioned keys.
So, the response process in its entirety looks something like this:
Now that we have an understanding of how the LANMAN challenge/response and NTLMv1 protocols work, let’s take a look at some of the deficiencies these protocols inherit.
  1. There is no “diffusion” within the protocol. That is, there are three separate parts to the response that could individually be attacked. Diffusion would ensure each part of the DES output relied on the previous – increasing the overall complexity.
  2. DES is old and considered cryptographically weak by many.
  3. The third DES key is weak. As the third DES key is padded with 5 nulls, there are only 2^16 possible unknown values. This would take a modern computer seconds to crack.
  4. There is a lack of randomness. The only randomness occurring within the algorithm is that provided by the pseudo-random challenge generated by the server.
In Part 2 of this series I will demonstrate how attackers can take advantage of the aforementioned deficiencies in the LANMAN challenge/response and NTLMv1 protocols.

Monday, January 3, 2011

Internet Explorer 0-Day: CVE-2010-3971

On December 22, 2010 Microsoft released an advisory stating that they are “...investigating new, public reports of targeted attacks attempting to exploit a vulnerability in all supported versions of Internet Explorer.” The vulnerability in question, CVE-2010-3971, allows attackers to execute arbitrary code in the context of the Internet Explorer application. Failed exploit attempts will result in denial-of-service conditions.

Microsoft states that the vulnerability exists due to “the creation of uninitialized memory during a CSS function within Internet Explorer.” The exploit takes advantage of the Internet Explorer DLL mscorie.dll having not been opted in to support address space layout randomization (ASLR). More details on the exact cause of this vulnerability can be found here.

This vulnerability is currently being exploited in the wild. Metasploit module ms11_xxx_ie_css_import has recently been uploaded to exploit this vulnerability. Offensive Security can be seen demonstrating the exploit here.

Microsoft is currently recommending users download the Enhanced Mitigation Experience Toolkit (MET) and opt-in Internet Explorer to mitigate this vulnerability.

For more details on DEP/ASLR please see the following links: