Back

Cracking Stats for Q2 2014

During many of our penetration tests, we gather domain password hashes (with permission of the client) for offline cracking and analysis. This blog is a quick summary of the hashes that we attempted to crack in the second quarter of 2014 (and so far for this year). The plan is to continue doing this each quarter for the rest of the year to see how we did overall for the year. Please keep in mind that this is not an all encompassing sample. We do not collect domain hashes during every single penetration test, as some clients do not want us to.

Q Hash Cracking Pie Chart

The sample for this quarter included three sets of domain hashes that added up to 23,898 hashes. All three sets had some LM hashes stored along with the NTLM hashes, but none of the LM stored passwords were that complicated, so it wasn’t a huge advantage. Of the hashes, 8,277 were duplicates, leaving 15,621 unique hashes. Of the 23,898 hashes, we were able to crack 21,465 (89.82%).

Cracked Password Length Breakdown:

Q Hash Cracking Bar Chart

As you can see, the cracked passwords peak at the eight character length. This is pretty common for a minimum password length, so it’s not a big surprise that this is the most common length cracked.

Some interesting finds:

  • Most Common Password (820 instances): Changem3
  • Longest Password: 20 characters
  • Most Common Length (10,897 instances): 8 characters
  • Instances of “password” (case-insensitive): 1,541
  • Instances of “spring2014” (case-insensitive): 111
  • Instances of “spring14” (case-insensitive): 93
  • Instances of “summer2014” (case-insensitive): 84
  • Instances of “summer14” (case-insensitive): 59

So far this year, we’ve collected 33,950 hashes to crack. Of those, we’ve been able to crack 29,077 (85.65%).

Some more interesting finds:

  • Most Common Password (1274 instances): Password1
  • Longest Passwords: 20 characters – Two passwords based off of the name of the business group using them
  • Most Common Length (14,339 instances): 8 characters
  • Instances of “password” (case-insensitive): 2,675
  • Instances of “winter2014” (case-insensitive): 23
  • Instances of “winter14” (case-insensitive): 18
  • Instances of “spring2014” (case-insensitive): 102
  • Instances of “spring14” (case-insensitive): 91

I put together an hcmask file (to use with oclHashcat ) of our top forty password patterns that were identified for this quarter. Additionally, I put together one for everything that we’ve cracked for the first half of the year. You can download the files here: Top40_Q2 and Top40 Q1 and Q2. I plan on keeping up with this each quarter, so check back in next quarter to see how this mask files have changed and to see how well we’ve done across the three quarters.

For more information on how we built our GPU-enhanced password cracking box, check out our slides
For a general outline of our password cracking methodology check out this post


Back

Intercepting Native iOS Application Traffic

In this blog, we will go through proxying an iOS application which uses native web sockets to interact with a web server. The blog will help penetration testers who are trying to intercept sensitive data that is being sent by an iOS application in a non-trivial manner over the network because some applications do not respect the iOS proxy settings.

During a recent iOS application penetration test, I encountered an iOS application that was sending data to port 20xx on a web server. This application traffic could not be proxied by changing the iOS manual proxy settings located at (Settings -> Wi-Fi -> HTTP Proxy -> Manual) and forwarding the iDevice traffic to the proxy. One of the reasons that the normal proxying method might be failing is because it might be using some native websockets to interact with the web server instead of the normal UIWebView class. For more technical details of how websockets in native iOS can be configured, check out this elabs blog post.

There is a workaround to fix this problem. We can perform DNS spoofing to forward all the HTTP traffic for all of the ports through a MitM proxy like Burp. The blog is divided into three main steps.

  1. Sniff traffic using Wireshark to find out the port and IP of the webserver.
  2. Spoof the DNS for the iDevice to send all data to laptop.
  3. Start a proxy on the laptop to intercept traffic all traffic from iDevice after DNS spoofing.

Given below is a step by step approach to intercept Native Web Socket iOS application traffic.

  1. Create a wireless hot spot with your machine and connect the iDevice to the hotspot. [Note the machine needs to be connected to Ethernet or some other route out to the internet as the Wi-Fi interface will be used for the hotspot. Refer here for information on how to create a hotspot on a windows machine]
  2. Start a network sniffer (like Wireshark) and look for traffic going to any non-standard ports.
    1. Filter the traffic to look at the traffic going to the destination server IP (ip.dst== ip.ip.ip.ip)
    1. Note the port number where the traffic is being sent.
Vk Intercepting

Fig 1: Finding the non-standard port number where application sends Traffic.

  1. Start the Metasploit console to perform DNS spoofing and enter the following commands.
    1. Search fakedns
    2. use auxiliary/server/fakedns
    3. set SRVHOST = (IP address of laptop which is running the hotspot)
    4. set SRVPORT = 53, set TARGETACTION = BYPASS, set TARGETDOMAIN = www.apple.com (Note: by setting TARGETDOMAIN= www.apple.com, all the traffic except the traffic coming from apple.com will be spoofed)
    5. set targethost = (IP address of laptop which is running the hotspot)
Vk Intercepting

Fig 2: Configuring DNS server on the laptop using fakedns module in Metasploit.

  1. Configure Burp to listen on specific ports for the incoming traffic from iDevice and forward it to the appropriate port as follows:
    1. Go to Proxy’Options’Add; set ‘bind port’ to the port where the traffic needs to be sent (note: this is the non-standard tcp port number recorded in Wireshark)
    2. Listen on all interfaces
    3. Click Request Handling’ Redirect to host: (Enter the domain name of the server)
    4. Request Handling ‘ Redirect to port: (Enter the corresponding port number)
    5. Click force use of SSL if the outgoing traffic is sent using https.
    6. Click ok and repeat the above steps for all the ports that the iOS application is explicitly sending HTTP application traffic to. In other words, every port will require a separate Proxy listener to be configured in burp.
Vk Intercepting

Fig 3: Configure incoming listener and redirect the iDevice traffic to appropriate IP and port to Server.

  1. Configure Proxy settings in iDevice:
    1. Click settings ‘ Wi-Fi ‘Click on hotspot ‘ DHCP and set DNS = (IP of Laptop)
    2. Set HTTP Proxy to the IP address of the laptop and corresponding port in burp. (this is the normal setting to proxy standard HTTP traffic)
Vk Intercepting

Fig 4: Configure IP and DNS forwarding settings in the IOS device.

  1. Type “exploit” in the Metasploit console and you will see the application traffic been proxied for non-standard ports in burp.

This small tweak can be used to overcome the problem of proxying non-trivial iOS application traffic.

Discover how the NetSPI BAS solution helps organizations validate the efficacy of existing security controls and understand their Security Posture and Readiness.

X