Summerschool Aachen 2004/Hacking the Web Lab
Contents
Notes from the Lab Session
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!)
(a VB6 program), and extract from it the password by providing two magic strings. Since no 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...
fun with hackthispage.tk
I tried the puzzle at hackthispage.tk, too.
The first three levels are fairly simple to solve, but the fourth page contains a shockwave file. I first tried to get flash running with my firefox under FreeBSD. 4 different flash plugins later I decided to use [flasm, a flash action-script decompiler.
I also spent some time with level 6, in which you have to download a windows executable, that displays a window with two input lines and a button. when you use the right randomish strings in the two input fields, a popup window informs you about the password you need to enter the next level. I used Ollydbg and IDA for debugging and disassembly of the binary, which took some time, but worked quite well in the end.
Currently I'm stuck in level 25 (7). I have some ideas left, but didn't try them today.
--Cpunkt 10:12, 23 Sep 2004 (CEST)
My findings of an afternoon of webhacking
I first started doing the webchallanges on hackthispage.tk. The first 3 levels were trivial. The 4th was a flash .swf file which contained the login name and the password, unfortunatly running it thru strings didn't give me anything usefull. I was later told to that it was compressed, and that you can decompress it with a tool called flasm. I then runned strings again and found the information I needed. Level 5 was easy. Level6 required you to reverse engineer part of a windows application to find a login name and a password. After looking at the assembly code for a few minutes (I got it thru objdump) I decided to end the hackthispage game and move on to something else.
The next thing on the list was to find and exploit for the OSVDB: 8691 vulnerability (an include bug mediawiki < 1.3.0) this was dated as that 12th of august. mediawiki is a project which you can find on source forge, the source forge people have been so kind to store all the previous versions of mediawiki (and they were even dated). Mediawiki 1.3.0 was dated August the 12th and Mediawiki 1.3.0beta6 was dated August the 6th. I assumed that Beta6 was the vulnerable version and that 1.3.0 was the fixed version. after doing a diff on both source tree's you could read the following:
diff mediawiki-1.3.0beta6/RELEASE-NOTES mediawiki-1.3.0/RELEASE-NOTES 3c3 < == Version 1.3.0beta6, 2004-08-06 == --- > == Version 1.3.0, 2004-08-11 == 5,8c5,6 < 1.3.0 final release should come up very soon; this final beta includes < various bug fixes and a security fix affecting some PHP configurations < (when register_globals and are allow_url_fopen both on -- it's recommended < that you turn both *off* for security). ---
So it appears that the bug was actally fixed in Beta6 on august the 6th. So I downloaded Beta5 and did a diff of this beta (and beta6).
which stated the following:
diff -r mediawiki-1.3.0beta5/RELEASE-NOTES mediawiki-1.3.0beta6/RELEASE-NOTES 3c3,8 < == Version 1.3.0beta5, 2004-07-22 == --- > == Version 1.3.0beta6, 2004-08-06 == > > 1.3.0 final release should come up very soon; this final beta includes > various bug fixes and a security fix affecting some PHP configurations > (when register_globals and are allow_url_fopen both on -- it's recommended > that you turn both *off* for security). 5d9 < **** THIS IS A BETA AND MAY STUNT YOUR GROWTH OR KILL YOUR PETS ****
The entire diff file can be found at [1]
After briefly browsing thru the 1250 lines of diff file I was unable to find an include() like bug in there (that and I'm not really good at reading/writing php code). This is where I hit a dead end. After some googling I did find out that apparently mediawiki 1.3.0 tries to hack around the register_globals problem. I don't know if this is really the case, If it is, the include bug might still be present, but you just wouldn't be able to exploit it anymore (Hm, that's adleast what I'm assuming).
Third and last, I looked at the uniqid() implementation. which looks something like:
uniqid(char *str) {
char uniqid[138];
struct timeval tv;
/* do some boundchecking on str */
gettimeofday((struct timeval *) &tv, (struct timezone *) NULL);
sprintf(uniqid, "%s%08x%05x", str, (int) tv.tv_sec , (int) (tv.tv_usec % 0x100000));
RETURN_STRING(uniqid, 1);
}
So, if the string that is passed to uniqid() is static or predictable, you can probably bruteforce id's generated by uniqid() (if you have some idea when the id was generated).
I briefly looked at the artmedic-guestbook, but haven't come around to writing an exploit for this.
-- Ilja
