Day 2 – SQL Injection

We learned about SQL injection today and were just randomly picking Malaysian websites to test it on. This is the result that I managed to get with a local organisation’s website (which shall remain nameless). I managed to find out the version of MySQL server that they were running (5.0.45) and also the account credentials for that MySQL server (root@localhost).

Nice!

Our trainer was able to exploit this further and enumerate a whole bunch of stuff, including all the user login credentials for their MySQL database, a list of all their databases and column fields, a dump of all the records of any selected database and more. This is not a bad reflection on MySQL as our trainer says that MySQL databases are amongst the hardest to attack.

However, if there system administrator is not doing their jobs correctly, things can get screwed.

Hacker Halted – Day 1

I attended Day 1 of Hacker Halted today. I signed up for Workshop 1 – on web-application hacking – because I wanted to learn more about it. Our morning started with mainly basic stuff on the underlying mechanism behind web applications – HTTP protocol, DNS services and what nots.

Our afternoon session was more interesting, with our trainer – Sean Arries – showing us the information gathering aspect of web-application hacking (vulnerability analysis). This is done in order to increase the attack space of the target. The thing that I learned from this section of the training is that – sites are far more vulnerable from side-channel and internal attacks than direct external attacks.

The tools that I already knew (and are part of every System Admin’s arsenal) were things like whois, dig, nslookup, host and other network layer stuff. However, at the application level, I learned how to use XSS ME. Manually testing cross-site scripting (XSS) is quite fun.

The basic techniques shown were really useful. We even practiced it on a number of prominent local Malaysian sites. Very interesting. Tomorrow, we get to the actual act of attacking web applications (penetration testing) and see if we can pwn any machines. I am looking forward to hacking my own websites.

Seeded Hash

For the sake of security, I had to implement a seeded-hash system to secure passwords in a database. While straight-forward hashes are good for ensuring that passwords are not stores in clear text, they are still vulnerable to rainbow-table attacks. A seeded hash helps to reduce this risk.

However, the question occurred on how to actually do a seeded hash. I got my apprentice to look around and we finally found a useful scheme. The seed and password are usually concatenated before being hashed.

hash = Hash(seed + password);

However, if the seed was fixed, then it does not really help much because it would still be susceptible to rainbow attacks if the secret seed ever got out. So, we had to use a random seed. However, a random seed would generate all manners of rubbish unless we could somehow embed the seed in the hash.

Since this was part of a password storage scheme, it would be perfectly alright to embed the seed with the hash because the size of the hash result is fixed. So, any extra data stored with the hash result would be the seed. We could convert everything to Base64 to store it in clear-text on the server. This was the scheme that we used in the end:

seededhash = Base64(Hash(seed + password) + seed);

This way, to do a password match, the application would need to decode the Base64, separate the seed from the hash and then perform the hash operation on the supplied password with the seed to see if it matched the hash.

Caveat: this solution only works in the situation of password matching – where we already know exactly which record to match against and merely need to verify that the information provided is accurate. This would not be useful for indexing purposes, like that used in Git. In such a scenario, straight-forward hashing would still need to be done.