So recently I found a number of flaws in a few websites, which I promptly informed the web admins of. Nothing major just a few XSS holes that needed to be closed to prevent persistant XSS. Since then I have been playing around on the site (with said web admins permission) to see what else I can discover. My finds have been glorious, educational and horrifying all in one.

Before I expand on my finds and thoughts let me start off by saying I am nowhere close to a professional pentester and the bit I do know I have taught myself over a few years, the rest is just common sense and extrapolating the information and techniques I have acquired.

So lets begin, the first few bugs/holes I found were persistant and non-persistant XSS or Cross Site-Scripting. The main difference between persistant and non-persistant XSS is in that persistant XSS allows client side code to reamin on the page permanently, so it doesn’t matter how a user gets to the page once they are there the code (generally Javascript) will execute. This is bad as an attacker can input some javascript into the site that each time a user visits it will forward a the attacker the users session cookie thus allowing the attacker to steal the session and login as the user. Furthermore, an attacker can inject code which will insert an iframe into the content. If the destination of this iFrame is pointed at a site which exploits a known web-browser flaw the attacker can setup a shell which will provide them with access to the victims computer. So as you can see a small XSS hole can lead to much much larger problems if it is exploited by a malicious attacker.

After a while I got board with all the XSS holes and informed the web admin that they should ensure that all user data is correctly escaped and validated before committing it to the database. So from here I moved onto SQL injections.

After bashing around at the obvious GET data, with little success, I moved over to the POST parameters. It was here that I have a little bit more luck and managed to login as various users without their passwords. What was most surprising to me wasn’t that this was possible, but was rather that the developer had taken the time to ensure SQL injections were secured everywhere except on the login form. The rest of the site was seemingly secure from SQL injections, however, the mitigation approaches taken by the developer could easily be circumvented by someone who knew more about advanced SQL injections than me. So I will return to this site and test it out again once I have brushed up on my SQL knowledge.

The next set of vulnerabilities I was on the search for were RFI or Remote File Include vulnerabilities. These allow you to upload a file to a website server and then visit this page. The fist thing I did was check all the upload boxes, the images, file, video and document uploads were all safe not allowing PHP files to be uploaded. So I tried adding other extensions to the PHP files such as .shtml .php.pdf and so on in the hope that I can rename them, however the file manager interface wouldn’t allow this. The site was using a 3rd party plugin to manage file uploads and it appeared well secured, a google for know vulnerabilities didn’t produce anything and the developer had installed it all properly. Then it dawned on me that this plugin probably has an install file, which will be deleted by the developer after installation… or will it. So I fiddled around with a few URLs before I finally got it, install.php, from this point it was childs play. I re-installed the plugin adding a special directory which will allow PHP to be uploaded I also password protected the directory so that only I had access and then I uploaded a shell.

From this point the site is screwed, while I removed the shell and informed the web admin, if someone else had figured this out then they could have done anything. The whole site could have been defaced, the webserver could have been rooted (assuming there is a known local root exploit, which there was) and the attacker could reign free causing chaos to all parties involved. I didn’t try root the server as I didn’t have permission for that, I was only asked to try compromise the site.

So after my little delve into pen-testing and speaking to the web admin I realized a few things:

Very few developers test their sites, or even consider security of their site. The reasons for this vary from, I hacked it together late one night and improve it as I go along to it doesn’t matter if the site gets hacked as there is no really important info on it and I back it up daily. So if it gets hacked I will just restore the backup. None of these excuses make any sense, as what developers, admins and site owners fail to realize is that if your site is vulnerable it is jeopardizing the security of every other site on that server. If an attacker roots the server they may be able to get access to sensitive information hosted on another site and this is completely independent of how well the server is secured.

Then again it also brought me to realize that ISPs/web hosts don’t actually care about security either. Why are they running unpatched versions of Linux and hosting software, surely they care if their server are compromised. So I followed up with them and the response I got was our server is patched, and if it compromised we will hand over the IP logs to the police and take legal action. Well that is all fine, but they have failed to realize that if their server is compromised by any attacker who has a slight enjoyment of freedom, then there won’t be any IP logs to take to the police. Secondly this is South Africa and I doubt a police officer will even know what to do with IP logs let alone how to catch a paranoid malicious hacker.

Another realization I came across was when I used the shell and had a peak inside the database, and guess what I found, a whole bunch of unhashed passwords, unencrypted credit card and address information and a ton more stuff. I mean come one, really, it doesn’t even take additional code to hash passwords you literally call one additional function. Yes I know that a pure MD5 hash isn’t great, due to rainbow tables and dictionary attacks, but it is a million times better than nothing at all. While site developers don’t care about this info being plaintext, I am sure most users will. I for instance don’t want anyone knowing my password, credit card details or address. It open you up to fraud. Furthermore, many users use their GMail accounts to login and most likely the same password. I did a quick check (about 10 accounts) and managed to log into 3 people GMail just because they used the same basic password. At least it gave me some hope that not all people are so laid back about security, to use the same password. But the number of passwords that correspond to dictionary words was terrifyingly high.

Finally I would like to leave a message for web developers:

Even if you are hacking a site together, from scratch (have no idea why you would still do this) or with a framework, please just take 1 minute to think about security. Every piece of user supplied input needs to be sanitized. Even the HTTP REQUEST headers. Yes very few people think about these and the number of exploitable sites due to SQL injection in the IP or User-agent field of a REQUEST header is huge. Passwords and sensitive information that you wouldn’t give out to a complete stranger needs to be hashed or encrypted. Just think, if someone called now and asked where I lived would I tell them? Probably not. So why do you leave it in plaintext for anyone with a slight understanding of technology to see. Furthermore, don’t just blatantly use 3rd party libraries, and if you do ensure that they are installed correctly, also make sure you REMOVE the install file else all efforts of security are pointless. Before using a 3rd party tool, read up on the known vulnerabilities, as this will give you information on how to fix it or what would be a better option to use. And lastly don’t reinvent the wheel. MVC frameworks are popular, one because they make your code very maintainable, two they have all the main functions you need to build a decent site pre written and three because they have large support communities which ensure that these functions are well sanitized and guarantee a base level of security. By doing everything yourself you will leave holes open, and attackers will get in. If you claim frameworks don’t suit your coding style, or design layout then you are not using them correctly. Just take a few days to familiarize yourself with MVC and a framework (there are enough out there that you will find one you like) and you will never return I can promise you that.