8th December 2012 (2 notes)
Note: I saved the following post originally as draft, because I wanted them to give a chance to fix the vulnerabilities before making them public. So I sent them an email. The next day I received a call from an unknown number, which to my surprise, was from them. The guy on the other side of the line told me that he tried to email me back, but that my server was down and the email didn’t go through. Which was true. I was having problems with my server that day. He also told me that he tried to contact me through the contact form on my website, and that that didn’t work either. I did sense slight amusement in his tone of voice, as if he was thinking, “you may know how to hack our website, but you can’t even code a freaking contact form in PHP”.
I explained him in detail all the problems with their site, although I’m not entirely sure he understood everything I said. He also seemed surprised that I found these vulnerabilities, and wondered how I did it.
At the end, he thanked me, and promised to take care of everything. As of writing this, roughly 4 weeks after the phone call, only about 40% of the issues are fixed. I don’t think more is coming anytime soon.
Now to the actual post:
Every now and then, I write scripts to automate processes, like the uploading of our entire database full of products. These are generally being uploaded to web portals, where we’re looking for exposure.
This involves writing cURL based scripts that have to do things like logging in, inserting descriptions and prices, and uploading images to a remote server. In order to do that, I have to get a pretty good understanding of how the sites work internally.
Today I wrote such a script for huisenaanbod.nl, which is a Dutch real estate portal. After creating an account there, I received an email from them which asked me to confirm my email address. But that was not all it contained, they also thought it would be a good idea to send me my password, in plain text! I know, a lot of sites do this, and while it’s not a good thing to do, that alone is not worth a blog post. But this is only the beginning. I got slightly more offended when I saw that they also had my password in the account activation link. Why would they do that?
How can a big site like this be so poorly coded? I decided to take a closer look at it after this, and now I don’t even know where to start…
The first thing I noticed while writing the script was that every HTTP request contained cookies with my email address, and a short string of random characters as it seemed at first. I didn’t want to think they’d be that stupid, but then I just had to see what happened if I base 64 decoded the little string. Before you ask… yes, it was my password. It’s being sent back and forth on every… single… request.
If you absolutely must send the password through cookies to the server, and I honestly can’t think of a good reason why, then for fuck’s sake, don’t use base fucking 64. Security through obscurity does never work. Usually it just slows things down. Well, unless you’re using base 64… fuck!
That’s pretty bad already, but it gets worse. While I haven’t found an SQL injection vector (yet), to my surprise, and there better not be any, seeing as they’re storing passwords in plain text, I’ve found several other exploitable bugs. It’s actually a combination of three, that work beautifully together. The second one makes the first one way more potentially dangerous. And the third one makes the second one more dangerous, which makes the first one a killer.
It’s pretty much an invitation to embed some code that grabs other people’s cookies (remember they contain your whole access data in plain text?), and send them over to your own server. All you have to do is to sit tight, grab some popcorn, and wait for the data to fly in.
Want to accelerate the process? No problem! The third exploit allows you to edit other people’s ads. That includes descriptions, prices, and even photos. It’s so simple, it’s embarrassing. You just have to browse through their main site, open a property you like (perhaps one of the featured ones on the home page?), and copy its ID from the URL. Then you go back to your control panel, click “edit” on one of your properties, and swap IDs in the URL. After that, you may change or insert anything you like, then click “save”, and you’re done. It works the same way for photos too. You can even delete anyone else’s ad.
I tried to do the same in the user area, where I can change my personal details, such as my email address and my password. My user ID is being submitted in the URL to the ‘edit’ page, (which, in a perfect world would be completely redundant), and then my data is being fetched based on that ID. But astonishingly, when I put another ID there, it just said I wasn’t logged in. Which is not entirely true, but I’d rather see this erroneous error message than other people’s sensitive data (I’m probably lying here). Why do they verify the ID there, but nowhere else? Who knows. But good for them someone had a slight sense of security here, and thought something bad might be able to happen.