Zone Transfers on The Alexa Top 1 Million Part 2

In part 1 of this blog post I conducted a DNS Zone Transfer (axfr) against the top 2000 sites of the Alexa Top 1 Million. I did this to create a better subdomain brute forcing word list. At the time, conducting the Zone Transfer against the top 2000 sites took about 12 hours, this was using a single threaded bash script. I was pretty proud of this achievement at the time and thought that doing the same for the whole top 1 million sites was beyond the time and resources that I had.

After creating a multithreaded and parallelised PoC in Ruby to do the Zone Transfers, it took about 5 minutes to conduct the Zone Transfers against the top 2000 compared to the 12 hours it took me to do the top 2000 using a single thread. I decided it was possible to do a Zone Transfer against the whole top 1 million sites.

There were 60,472 successful Zone Transfers (%6) out of the Alexa Top 1 Million, this equates to 566MB of raw data on disk. This amount of data brings its own challenges when attempting to manipulate it.

The top 10 subdomains in the Alexa Top 1 Million are:

Instances, Subdomain
54520 www
41581 mail
39873 ftp
38590 localhost
22771 webmail
17643 smtp
17410 webdisk
15439 pop
15155 cpanel
14904 whm

There are some big differences in this top 10 compared to the top 10 against the top 2000. In this one the www subdomain takes the number one spot. The m subdomain is not in this list. The cpanel subdomain is in this list but didn’t feature in the top 2000 list.

Continue reading

Zone Transfers on The Alexa Top 1 Million

At work as part of every assessment we do a some reconnaissance which includes attempting a DNS Zone Transfer (axfr) and conducting a subdomain brute force on the target domain/s. The subdomain brute force is only as good as your wordlist, the Zone Transfer is a matter of luck.

Alexa release a list of the top 1 million sites which is updated on a daily basis. To create a better subdomain wordlist to conduct subdomain brute forcing I attempted a DNS Zone Transfer against the first 2000 sites in the Alexa Top 1 Million list. With every successful Zone Transfer the DNS A records were stored in a CSV file.

This was all done using Carlos Perez’s dnsrecon DNS enumeration tool. Dnsrecon was ever so slightly modified to only save A records, apart from that I just used a bash script to iterate over the Top 1 Million list and ran dnsrecon’s axfr option for each site with CSV output enabled.

Continue reading

Cracking Microsoft Excel 97-2004 .xls Documents

A client emailed to say they had forgotten a password for their Microsoft Excel .xls document and asked if it was possible to recover it. After searching on Google it was clear that there was plenty of shi…bloatware, which may have worked if you were willing to go through a few of them and pay a few dollars. It wasn’t that important of a document according to the client but nevertheless a challenge is a challenge.

The document was encrypted when using ‘save as’, according to various sources online the encryption algorithm is 40bit RC4. As it is encrypted nothing could be gleaned by opening the document with a hex editor.

As always when Google turns up nothing useful I turn to Twitter. A few people recommended Elcomsoft which do Windows software to both recover and obtain the password of a Microsoft Excel document. This looked like a good bet and they offer free trials! The recover software which seems to do a brute force attack looked like it could have worked (especially now I know how weak the password was) but I was running the software on a Virtual Machine. The recovery tool unfortunately didn’t reveal the password, the paid for version may have, I don’t know.

Continue reading

Login Cross-Site Request Forgery (CSRF)

The new OWASP Top 10 2013 was released not so long ago, while reading over it I noticed this:

“Attackers can trick victims into performing any state changing operation the victim is authorized to perform, e.g., updating account details, making purchases, logout and even login.” – https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_(CSRF)

This must be a mistake I thought, why would you ever want to CSRF a user to log them into their own account? If you already had their login credentials this must be utterly pointless.

Today I came across an academic paper which gives three examples of why Login CSRF can be an issue and how wrong I was.

Google

“Search History. Many search engines, including Yahoo! and Google, allow their users to opt-in to saving their search history and provide an interface for a user to review his or her personal search history. Search queries contain sensitive details about the user’s interests and activities [41, 4] and could be used by an attacker to embarrass the user, to steal the user’s identity, or to spy on the user. An attacker can spy on a user’s search history by logging the user into the search engine as the attacker; see Figure 1. The user’s search queries are then stored in the attacker’s search history, and the attacker can retrieve the queries by logging into his or her own account.”

Continue reading

HTTP Form Password Brute Forcing – The Need for Speed

HTTP Form password brute forcing is not rocket science, you try multiple username/password combinations until you get a correct answer (or non-negative answer).

Password brute forcing, especially over a network, takes time and while your software is attempting to find a correct username/password combination it is taking up your and the remote system’s resources. While the brute force is being carried out you might not want to run an automated scan, for example, as the remote server may not be able to cope with the amount of connections or the rapid succession of connections. At the same time, your network bandwidth and system memory are also limited. It makes sense that when you conduct a weak password brute force it is done as fast as possible so that your time and resources are restored for other tasks.

And of course not forgetting that you’re always going to be limited by time on a pentest/web app assessment as the client’s budget is never unlimited.

So what is the fastest way to brute force a HTTP form today? I use Burp Suite for my Web Application Security Assessments and I would normally use Burp’s Intruder, but is this the fastest tool to do it with?

Of course, there are other limiting factors when brute forcing remotely such as your Internet/Network speed, CPU speed, RAM and the remote system’s response times, as well as other factors. For this experiment we’ll only be focusing on the software used to carry out the password brute force attack. This is far from being a perfect in-depth study but it should hopefully give an idea which tool out of my small collection (Burp Intruder Spider Vs Hydra http-post-form) is fastest.

The Setup

On both tools I set one user to brute force, admin, and used the rockyou-75.txt wordlist (19963 lines), which has one addition which is the correct password which was added to the last line of the file. Both the same username and password list was used for Burp’s Intruder (Sniper) and Hydra. Each tool was run one after the other, not at the same time.

Burp Suite Professional Intruder (Sniper) Version: 1.5.11
Hydra (http-post-form) Version: 7.4.2

A “Local” test was carried out on a localhost Apache 2 web server as well as a “Remote” test against the www.ethicalhack3r.co.uk Nginx web server.

The Test Form that I created to test against (both locally and remotely) does not make a database call which is what would normally be expected on a real HTTP login form. I’d expect my test login form to reply quicker than if it had to make a database call. The ‘Local’ and ‘Remote’ columns represent the time it took the tool to find the correct password which was at the end of the wordlist.

Continue reading