Friday, November 16, 2012

Old Working Exploits - or how you can log in to vbulletin forums with a user's uncracked hash

This is an issue I reported way back in 12/11/10 (reference SID-1046901-fc4373fb) and they declined to recognize it as a bug, so I'll post it for the benefit of the public.

It requires an uncracked md5 hash of a user's password on vBulletin forums.  When you log in, it doesn't actually transmit the password in plain text - it transmits the md5 hash of the password.  That's great! So any forum software running on http won't be nearly as vulnerable to sniffing plaintext passwords.  There's a problem, though:

md5 is commonly used as a password hashing algorithm, and hacked websites out there commonly have databases full of these accounts.  Typically, md5sum hashed passwords can be cracked 40-50 percent of the time.  Hackers use a lot of password-reuse attacks and the fact that you can pass along a hash instead of the cracked password means that that if you're part of the 50-60 percent of users with an uncrackable password, any accounts you have on a VBulletin forum aren't safe, if you've reused your passwords.  The issue can be mitigated by updating the password sending method to anything that an attacker can't use a known md5sum to log in with.

It's an edge case for sure, but if you're in the business of mass hacking accounts, then perhaps this edge case can net you that many more victims.

Here's an example login request that would be produced from any of the latest VB forums:

username: abcd
password: aaaa
hash: 74b87337454200d4d33f80c4663dc5e5 = aaaa


POST /login.php?do=login HTTP/1.1
Host: forums.forum.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Proxy-Connection: keep-alive
Referer: http://forums.forum.com/
Cookie: bbsessionhash=bbd4f543da0af78506ebe3b185368240; bblastvisit=1353135560; bblastactivity=0; AAJSID=balancer.www1
Content-Type: application/x-www-form-urlencoded
Content-Length: 185

vb_login_username=abcd&vb_login_password=&s=&securitytoken=guest&do=login&vb_login_md5password=74b87337454200d4d33f80c4663dc5e5&vb_login_md5password_utf=74b87337454200d4d33f80c4663dc5e5

Wednesday, November 14, 2012

Hackin' The Boss [Part 2]


Before diving into the injectable "id" parameter, I wanted to explore other options to potentially gain complete control over the target. This would in effect make finding the remaining flags quite simple. With that goal in mind, and a local saved version of the "test.php" configuration page (which was removed by this time, of course I kept a copy) it was time to start looking for potential methods of ingress.

After exploring multiple OSINT sources (Shodan, Exploit-DB to name a few), I wasn't able to find much promising literature. Perhaps then, if the webapps weren't the gateway I needed, something else that could provide me access. A quick nmap of common ephemeral ports indicated that, as expected, ports 80 and 443 were open. However, port 22 (SSH) was also open. Not a ton of additional information, but enough for nmap to fingerprint the OS. Next up, the excellent Metasploit front-end gui, Armitage.

With Metasploit updated, I loaded up Armitage and ran a msfscan against the target host. Selecting "find attacks" revealed a large number of potential exploits to try. Since I was behind my totally not-at-all suspicious VPN, it was to time fire everything at the CTF server. Alas, all automated attempts failed and no sessions were established. Oh well, it can't always be easy! **Note: Apparently, the original CTF was designed to be vulnerable to the php_eval() module found in Metasploit, apparently this particular setup was not vulnerable.**

My first plan thwarted, it was time to dump the database and comb for useful information (and flags!). With ye olde sqlmap up and running, I fed the parameter "id=" to the beast. Within a minute, the entire database had been dumped to my local hard drive  and while watching the console print the results, I noticed a pretty interesting flag that appeared to have credentials! Unfortunately, the console has scrolled far too quickly for me to catch the details, so I started to dig into the dumped db information to retrieve what looked to be my golden ticket.

After a quick search, I found the flag in the "board.users" table of the database which contained a user/password combination. The next flag was found in "test.notes", and this seemed to be the only other flag present in the db dump. I now had 5/11 (at the time, thought to be 12) flags, MySQL database credentials, and what appeared to be a user/password combination. From previous nmapping, I knew that port 22 was open, so it was time to try and login with the recovered credentials.

With the provided Username/Password combo, I was able to SSH successfully to the CTF server. The home directory contained a single file, an ELF executable, which accepted a string as its parameters. Sensing the presence of another flag a hexdumped the file and found flag #6 (I should have just run a strings against the file, but I wanted to see the context). I moved to the base directory and found another text file labelled "flag". Boom, #7. At this point, I wasn't entirely sure where to look next, so I poked around until I got to /etc/php/apache2 and catted out the php.ini file. Therein was flag #8.

Moving back into the /var/www/ directory, there was an additional element included with this version of the CTF that differed from the OWASP one. A fully functional, basic version of "Frogger" (written in JavaScript) was present. I have never been good at frogger, and I expected there could be a flag hidden somewhere. I grepped through the various files found in the directory to no avail, but decided to take a second look at the JavaScript of the game. Inside was a hex encoded string, flag #9.

Since I had the MySQL database credentials, why not connect to the database and check for the presence of more flags? Upon successful connection and enumeration of the table names, several simple SELECT * FROM queries confirmed the 2 previous flags I had found, and an additional flag in "board.posts" which I had previously missed. And thus Flag #10 was recovered.

Unfortunately, I wasn't able to recover the last flag. Apparently there was a webpage with a very colorful, animated image with a flag embedded as a test of one's steganography skills. I had suspected this seizure inducing page hid a flag, but I never suspected steganography. Yeah, I completely missed that one (I would blame colorblindness, but that likely isn't an adequate excuse). Oh well, 10 of 11 Isn't too bad!

All in all, this was a lot of fun. If you haven't participated in a CTF event before, I would highly recommend it. Especially if the CTF server belongs to your boss. That makes it all the sweeter.

Monday, November 12, 2012

Hackin' the Boss [Part 1]


After attending a local OWASP chapter conference, DA "The Boss" decided that he wanted to replicate the CTF experience for those of us on the Analysis Team at DSWRX in Providence.

Here's a quick write-up of my experience as a simulated "Pentester" (a complete 180 from my normal work role).

The Server was built using the latest [as of September 2012] Ubuntu Server with a typical, updated LAMP installation. All source code for the actual CTF WebApp was obtained from the previously mentioned OWASP meeting. This setup led to the first problem: the updated PHP was not vulnerable to the Metasploit module: /unix/webapp/php_eval, and thus one of the 12 Flags was not obtainable. 11 to go!

I only looked at the actual webpage, a domain provided by a co-worker, once to look for potential injectionable parameters. Since I had not previously taken part in a scenario like this, I wanted to experiment with some of the tools packaged with the excellent BackTrack 5r3.

I started up my local version of BackTrack, logged into a not-at-all suspicious VPN, and fired up burp (free edition) to start mapping the entire website. Immediately I saw that the typical "test.php" page was still enabled, which typically provides a verbose listing of server and application configurations. I mentioned this to "The Boss" eventually and it was then disabled. Following that I found the first flag using a relatively simple XSS. The second tag quickly followed as I was browsing through the completed spider report and found a URI for "flag" (a text file in /var/www/). Having exhausted the obvious options, it was time to start reading the source code!

From a quick review of the source, I was able to find: an additional flag (#3), default MySQL credentials (Hard-coded), and a parameter to test for SQLi. After a quick test it was pretty clear that the "id" parameter was vulnerable to SQLi, and thus after some useless spamming of the webpage with W3AF, it was time to get down to business.

Why this domain?

I originally registered this domain back in 2011, shortly after this talk was released:
http://www.blackhat.com/html/bh-us-11/bh-us-11-archives.html
"Bit-squatting: DNS Hijacking without exploitation"

It intrigued me and I attempted to duplicate the results of this experiment.  micrmsoft.com was one of several domains I registered.  I got some variants of paypal, mozilla, and facebook domains as well, but microsoft variants yielded the most misdirected requests.  My conclusion was ultimately that the author of the original talk was not full of BS, and traffic to microsoft was high enough that there will be some misdirected requests going to the domain.  The paypal, mozilla, and facebook domains did not perform nearly as well.

Here's a small example pcap from a day of traffic:
http://micrmsoft.com/smallsample.pcap

example request:

GET /pki/certs/MicrosoftWinIntPCA.crt HTTP/1.1
Accept: */*
User-Agent: Microsoft-CryptoAPI/5.131.2600.5512
Host: www.micrmsoft.com
Connection: Keep-Alive


You can see that the vast majority of those requests are from crawlers, but occasionally you'll see a few Microsoft CryptoAPI requesting some certs.  I think this bit flip stuff is really only a concern for the top handful of domains in the world, but it was interesting to see a tiny slice of what Microsoft sees.

Could this be used for evil?  Perhaps this could be used to MITM some poor soul's failing hardware.  We only monitored passively and did not see any personal information.  After the misdirected requests for certificates were given 404 errors, the errant IPs did not come back again.

Edit: This was recently released, and the original author discusses much more in depth information on the subject: http://blog.dinaburg.org/2012/10/a-preview-of-bitsquatting-pcaps.html

First post!!!!

This is the first post of our blog. This blog is to document shenanigans and whatever interesting discoveries.  Current contributors are Allison Nixon(@nixonnixoff) and Brandon Levene(@SeraphimDomain).

First content, here's a link to a Sophos puzzle that we won: http://nakedsecurity.sophos.com/2012/11/05/wall-of-fame-for-skyfall-sophospuzzle/

The challenge was pretty tough, and involved several puzzles as well as cracking a variant of the Vigenère cipher.  But we managed to submit answers in time to get t-shirts.  Horray for us!