Summerschool Aachen 2004/Hacking the Web Lab
Contents
The mediawiki vulnerability
Sourceforge has the source code for all previous versions of mediawiki still available, including the 1.3.0 beta versions. I downloaded beta4 and the final 1.3.0 version and did a diff -uNr, resulting in ~ 20000 (reduced to ~ 16000 without whitespace-only changes) lines. Most noticable changes include:
- additional addslashes calls in several places
- addslashes gets substituted by a new function escapePhpString in some places
Real World XSS exploits
Last year, myself and a friend found an XSS vulnerability on an ISP's website (NTL), and I wrote an exploit for it. A journalist picked this up and there is a short article on it in The Register. The vulnerability was particularly problematic, since the page in question was to enter credit card details so Javascript could be used to forward the details elsewhere. Also many other services, such as webmail, account management and purchasing services were run under the same domain name, so it could steal cookies used for these. There is also a blog posting which gives more details (after it was fixed).
The reason Matthew asked me about this was that I had previously written an exploit for another website (I mention this in another blog post). This was a little more interesting technically, since the session cookies for the site had a fairly short expiry. The normal technique is to use Javascript to steal the cookie, then send it back to the attacker for later use. Since the session would probably not be valid by the time the attacker got around to getting the cookie, I had to try a different attack. I wrote a Python CGI which would take the session cookie as a form parameter, then used the XSS vulnerability to insert Javascript to steal the cookie and send it to the CGI. The CGI then immediately took the session cookie and retreived the contents of the victims shopping cart, as a proof of concept. Because this happened without any human interaction, the session cookie expiry was not an issue.
If you are interested in finding more vulnerable webpages then looking for "Widdecombe of the Week" or "Widdy" in the NTK newsletter should find plenty.
Puzzle Game dievo.org
Nice playground for html tricks. Currently i am stuck level 1.
Spent most of the time installing java and WebScarab. LifeHeaders on the contrary is a more passiv approach. I like Paros Proxy, too. You might want to install another firefox plugin Switch Proxy.
-- Mario Manno
There are quite a few web-based and unix-based games on dievo.org, as well as two crypto-games. The Neophyte-game ist my favourite one among the web-based games. I have played it until level 6 (but not including that), and some of these levels are quite interesting to solve.
Firefox extensions
I took a look at some of the web proxies mentioned in the lecture this morning, and decided to investigate developing a Firefox extension to get some of the same functionality (without the pain!). I didn't get very far, but I did find some useful resources, and looked at the source code for a number of existing extensions.
(My other achievement was successfully negotiating the purchase of writing paper, envelopes and some stamps in German!)
Hackthispage.tk
This web-site provides an interesting war game, testing some web-hacking skills. The first few exercises just test your ability to read the html source of pages (with a pathetic attempt at preventing right clicking, that does not work in proper browsers such as FireFox). The third is testing our ability to decode uuencoded strings, which a symple python script can do. Then the real fun starts: Exercise four requires the decompilation of a flash (swf) file. We have used a trial version of the "Liatro SWF Decoder", to unpack and inspect the actionscript source. All its secrets were revealed to us. Exercise five is about locating a script, but six kept quite a few people in the lab busy for a few hours!
"Six" required us to download a windows binary (a VB6 program), and extract from it the password by providing two magic strings. Since no hints were provided, we disassembled the beast (using PE Explorer), and tried to understand what it does. The two string compare calls were identified, and we guessed that the test must be the conditions yielding the hidden password. After briefly trying to transform the jumps to "noop" instruction (using frhed) we ran the thing using a debuger (Ollydbr) and read out what the comparision strings were. Inputting them into the program provided the magic password!
Some pointers to resources:
PHP's uniqid()
Lutz and I both had a look into the php sources to find ways to mess with the uniqid() method used for getting session ids and other stuff. It is also heavily used by some guestbook (Max knows which) to create database files and query into user info. So it might be pretty interesting to guess existing ones.
Anyway the source is not that challenging, it basically converts current time information into hex values, hereby claiming to construct (almost) unique values. You can actually improve this a little by adding more information but the concept stays the same. An idea of attack might be taking log in information (e.g. from a guestbook) and narrow down the timeframe a certain id might have been generated. You can then start a brute force attack on the possible values. On the other hand, simple implementation details such as adding a rand() call would probably render this useless. Maybe we will look into this further once we are a little bored...
