How one company implemented (almost) whole OWASP Top 10

During one of my talks I was presenting OWASP Top 10 to students, who were interested in software development. One of them said that OWASP Top 10 is irrelevant in today's world, because there are frameworks with built-in security safeguards and everyone uses them. Unfortunately, I didn't have any real-world examples prepared and couldn't provide them on the spot. Not long after I received a spam message with an ad for some new auction portal. Out of curiosity I went there (if you check links in your spam folder you may end up with some interesting findings, right?) and looked around. 

To my horror, the more I clicked the more vulnerable the portal seemed. I was able to find so many problems with it, that I dismissed it as a failed attempt at building a website made by a single developer, who wanted to play in "the big game". Some time after that event I received a spam for different auction portal, which had the same problems. Soon enough, with a help from my friend, I found the company (JMLNet) that - oh, really - sold and deployed this auction portal. It was a product and was sold for a price ranging between 150 to 350 euros. Not much, and I guess you get what you pay for.

The problems

First thing I did was to search for something. So I wrote the word "test", clicked on "search" and to my amusement this was the link that I was sent to:

SQL Injection w serwisie firmy JMLnet

That base64-encoded parameter looks interesting, doesn't it? It decodes to:

 AND (p.tytul LIKE '%test%')

Which is a part of an SQL query. Well, this probably (I didn't test it of course) means that we have the master of all SQL injections - basically, a free access to the database. (btw. did you notice the space at the beginning of the decoded SQL? ;)

At this point I decided to click some more and just go through a website to see if there are any other obvious security problems. Mind you, I wasn't even trying to find them, I was acting like a normal user. Sure enough, this came along:

XSS w serwisie aukcyjnym JMLnet

As you can see the message displayed on the website and the "info" value are the same. Coincidence? No, not all. In fact whatever was in the "info" value was copied over to the website and rendered in HTML. Like, a message that user isn't logged in (as above) or a javascript that send cookies to the malicious C&C server. All of that was one click away for a regular user.

So, I decided to create an account. When I clicked on a link I got redirected to this website:

Open redirect w serwisie aukcyjnym JMLnet

Again, we see the base64 encryption of what seems to be a redirect address. Of course, you can put any address you want in there. Why does it matter? Let's assume that a person receives a link saying: "Want to buy this thing? Just log in using the link below:". Being a watchful user, he spots that indeed link is directing to the auction portal website. He goes in, log in (successfully) and get redirected to a phishing website which looks just like the login website but says "your password is wrongt". Being used to mistype the password user tries again and gives credentials to the phishing website. This kind of error is called "open redirect".

OK, now we've registered, logged in and we've got a session cookie. How does it look like, you may wonder? Here it is:

user_id:username:MD5(password)

What's wrong with it, you may ask? Well, first of all it doesn't have a session identifier. Just by stealing this cookie you may login whenever you want and stay logged in for as long as you want. Second thing is that the MD5 hash (MD5...) is not salted. Hence, guessing the password may be very easy. The fact that this cookie is sent with every request makes it easier to steal the hash of the password. Well, but you don't even need the password, do you? You can just log in using the password MD5. You probably don't even have to send POST login request to brute force password. Just try doing GET requests using different cookies and see if you're logged in.

Now let's get to the final and the most worrisome error. After creating a profile, user could upload his or her photo. This photo was saved on the server and available under the following name:

MD5(file_contents) + . + original file extension

Turns out that you can upload a file with any extension. For example, ".php". This means that you have an arbitrary code execution on the server side.

Responsible disclosure

After finding all of that I decided to contact the developer. Here's the timeline for responsible disclosure:
  • 27.12.2015 – first contact, mentioned multiple vulnerabilities
  • 28.12.2015 – response asking for details, unsuccessful attempt at the PGP key exchange
  • 28.12.2015 – detailed information about the vulnerabilities
  • 29.12.2015 – JMLNet decides that they can fix the vulnerabilities and I can publish the description "at the end of January"
  • 05.02.2016 – I ask about the deadline and whether or not I can publish, no response
  • 11.02.2016 – I ask again, no response given
They released an update, but some of their clients still are vulnerable.

Oh, did I mention that they didn't use HTTPS at all? ;)

Comments

Post a Comment

Popular posts from this blog

Having fun with AndroidManifest.xml

Image
Before w will get back to Sandrorat let's have some fun. It's weekend after all, or rather it was weekend when I wrote this post. Everyone that ever tried to see the insides of the APK file knows what's an AndroidManifest.xml file is. Some even know that, inside the APK, it's not a real XML, but rather a compressed, binary form of an original XML. This compressed form was first abused in the Android.OBAD malware . Compressed form of an XML differs with the real XML in at least one key aspect, hidden in the String Pool. Let's have a look at a compressed AndroidManifest.xml file of the previously mentioned Sandrorat sample and see if we can do something interesting with it. If you want to skip directly to the fun part, just ignore the next section.
Read more

Android malware based on SMS encryption and with KitKat support

Image
Most of the malware based on the SMS C&C communication channel is not compatible with Android 4.4 KitKat. This is due to the fact that KitKat introduced a concept of one messaging app, which all other apps had to go trough before they send or handle a received text message. This prevented malware from hiding received short messages or sending without saving them in the "Sent" folder. Well, it wasn't hard to predict that this state of affairs wouldn't last long and that malware authors would eventually catch up. Malware described here not only supports KitKat, but also uses an open-source SMS encryption tool  as a basis for its code. Let's have a look at the insides of the new sample (hash: 84e2e9e8430792b583d02d3cc1bf8535 ) and let's call it SmsSecure, just for the sake of brevity.
Read more

Sandroid RAT analysis: Part I - synthetic communication

Image
My first post is about Sandrorat, a fairly new RAT tool that was prominent for being a part of a Polish spam campaign . The analyzed sample hash is bed05d8eace6a7ebc5dec7141ea4b9cc559f1b2aab8848e2c79df7a79de39b9d . Sample was obtained thanks to The Honeynet Project . Everything is synthetic First part will be about a little known synthetic methods and the way Sandrorat uses them to obfuscate the code . This sample declared three different services:
Read more