Difference between revisions of "Summerschool Aachen 2004/Hacking the Web Lab"

From C4 Wiki
Jump to: navigation, search
Line 13: Line 13:
* pushes externally defined global vars (get/post) to namespace (register_globals)
* pushes externally defined global vars (get/post) to namespace (register_globals)
* unsecure use of eval function (unchecked vars)
* unsecure use of eval function (unchecked vars)
* PAPER Study and Scarlet
* PAPER Study in Scarlet
* Path filters are often os dependent
* Path filters are often os dependent
* .inc files may not be protected by the webserver against reading (password disclosure)
* .inc files may not be protected by the webserver against reading (password disclosure)

Revision as of 16:55, 22 September 2004

Presentation Summary


  • traditional weak security
  • use simple ssl proxy to work with https like http
   socat tcp-l:8888,reuseaddr,bind=,fork openssl:www.ccc.de:443
   socat - tcp4:localhost:8888
   socat - openssl:www.ccc.de:443
  • install the webapplication on a local pc, add --log=/tmp/log to your sql server to see queries
  • popular attack proxies: Burp Proxy, @stake Webproxy, WebScarab, Pharos, Spike, Firefox Plugins


  • pushes externally defined global vars (get/post) to namespace (register_globals)
  • unsecure use of eval function (unchecked vars)
  • PAPER Study in Scarlet
  • Path filters are often os dependent
  • .inc files may not be protected by the webserver against reading (password disclosure)
  • .inc files may be renamed to .inc.php, executing a config file, remote require problem
  • execute arbitrary php files by namespace pollution (via query string vars)
  • upload may allow to upload php files, may allow upload to arbitrary locations in servers file system via '..'
  • may execute uploaded php files with xss (javascript)
  • insert php code into apache log file, then make the server exec the log file as php
  • strings get converted to integer ('000'=0, but '000'!='0')
  • php sessions are generated in /tmp, local users may access these, session id encoded in filename, session data inside file
  • older versions, accept <script> as session_id and reproduced in every link

Source Disclosure

  • by changing filename casing to confuse handlers
  • encode url, i.e.: . -> %2e
  • double encode
  • insert space, + after filename
  • use helper or demo handlers to retrieve source
  • changing hidden fields may allow spamming, file creation, etc.
  • sessions/cookies may not check if Sessionid corresponds to a given username
  • password disclosure in referer urls via query string
  • XUser Surfing, use valid session to access other users data
  • XSS, push code to users browsers via modified links containing javascript and steal cookies, etc
  • found in the webtree, .mdb files, .sql backups, WS_FTP.log, .DS_STORE, .cvs, .bak, file~

SQL Injection

  • xp_cmdshell executes commands on server (tftp i.e.)
    • sa account may not be password protected, disabled but not deleted...
    • tool sqlat ?
  • make conditions always eval to true (1=1,a'='a')
  • php magic_quotes help against injection, but affects all sql commands
  • use prepare before executing statements to secure your code (exec "SELECT * from bla where a='%s'",param)
  • hiding error messages does not help against injection (blind sql injection)
  • use UNION in injected SQL to get at more interesting tables
    • use substring/etc. to get mysql.user passwords (char by char)
    • first column = 1 if char isn't guessed correct
    • binary search < 'a' is more efficient
  • if user can control some response header field 'header splitting' is possible (xss)

Top10 (OWASP)

  • Unvalidated Input
  • Broken Access Control
  • Broken Authentication and Session Management
  • Cross Site Scripting
  • Buffer Overflow
  • Injection Flaws
  • Improper Error Handling
  • Insecure Storage
  • Denial of Service
  • Insecure Configuration Management

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

-- AlexanderBecher

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.

-- Steven Murdoch

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.

-- Lisa Thalheim

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!)

-- Stephen Lewis


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:

-- George Danezis

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...

-- Ernest Hammerschmidt