Top 10 vulnerabilities from a1qa. Part 1

Security testing team assesses websites, applications and other software products to identify vulnerabilities and threats that can be exploited by abusers. Vadim Kulish, security testing engineer has made a list of 10 most severe vulnerabilities that were detected on real projects.

All vulnerabilities are arranged by the difficulties of detection: the most evident go first and are followed by the trickiest ones. There are also root causes of every vulnerability and exploitation threat.

#1. Google dorks

We’ve already talked about Google Dorks here. Let me remind you in short, Google dorks queries are search operators used in security testing to find information that isn’t readily available on the website.

Here are a few examples of advanced search parameters:

• site: – searches for files located on a particular website;
• filetype: – searches for files of the specified type;
• inurl: – returns results with that sequence of characters in the URL;
• intitle: – returns files with the string in the page title.

Google dorking is also known as Google hacking as it can return information that is not intended for public viewing but has not been adequately protected.

In our case we were performing security analysis of the bank’s website and made the following query: site:example.com filetype:pdf (example.com – customer’s website). The query returned a number of documents in pdf. This vulnerability wouldn’t have been ranked as a major one if these documents weren’t plans of the bank facilities. More than enough data for a massive bank robbery!

Root cause: wrong web server configuration.

Exploitation threat: leak of confidential documents.

#2. Data disclosure

When conducting security audit we always check the following resources for leakages:

• Github (source code, credentials);
• Files containing important information forgotten on the server (backup copies, source code, information about the installed software);
• Builds for developers and testers (as a rule, they run in a debug mode and if there is a mistake, show vital information about the application functioning);
• Pastebin.com (on this website developers exchange useful information about leakages or code threats).

Looking over these resources when testing the e-commerce website, we found a development build of the website on the server. The build contained numerous web application parameters, including, but not limited to those, that could be used for connecting to the PayPal API. Obviously, this data was enough to connect to the shop payment account and leave it without funds.

Root cause: wrong web server configuration.

Exploitation threat: leak of confidential data for PayPal connection.

#3. SSL DoS

DoS (Denial of Service) is a cyber-attack characterized by an attempt by attackers to prevent legitimate users of a service from using that service.

A little bit of technical information before moving to our point. I believe that you know that HTTPS is the secure version of the HTTP protocol. The “s” at the end stands for “secure”. This protocol is used to enable communication between the server and the browser. The communication is encrypted with keys. But if the server is wrongly configured, the client will ask for secure communication establishment several times. The problem is that the load on server in this case will be many times higher than on the client’s side. An average server may process 250-300 secure connection requests, while the computer may generate up to 1 000 requests per second.

Now back to our story. Our team was performing vulnerability analysis of the internet banking and run DoS attacks. Suddenly one of the attacks worked out and crashed the site. This vulnerability was a good one for hackers as it was hard to detect – the DoS attack didn’t crash the website. As soon as the hacking software was turned out, the website resumed working.

Root cause: wrong https server configuration.

Exploitation threat: complete server blocking.

#4. Cracking of one-time password (OTP)

We were testing mobile app and got access to users’ account. The problem was in the vulnerable authentication process. The user got a password over mobile phone and entered it to authenticate in the app. The server generated the OTP and then checked the password sent by the user.

What did we find out? We paid our attention that the password was a digital code composed of 4 digits only. It meant that there were only 10 000 possible combinations. And we decided to check whether the password could be cracked. Ideally, the user should be given only three attempts to enter the password. When the third attempt fails, the server should block the user. However, this wasn’t our case.

Then we decided to act as real users. We sent an SMS from our mobile phone and got the OTP. However we didn’t enter it and started cracking it. It took us only 15 minutes to get the valid password.

That wasn’t the limit as we went further and automated the process of OTP cracking. As a result, we got a little script that allowed getting into the app knowing only the user’s phone number. The harmfulness of that vulnerability was that the cracked app was a messenger and hijacking it we got access to the user’s correspondence. The unconscious real user got no idea what was happening as the only thing he saw was an incoming SMS with four digits.

Root cause: insufficient anti-automation, logical error.

Exploitation threat: access to the application users’ accounts.

#5. Control panel authentication bypass

It was the fastest hacking that us only a minute!

The customer approached us to test the e-commerce website. Looking for bottlenecks in system security we came across the control panel. And in a minute we were looking at it as if we were authorized to do this. How did we manage to do it?

It was due to the HeartBleed vulnerability in the popular OpenSSL cryptographic software library. It was publicly disclosed in 2014 and its exploitation allows to read adjacent server’s or client’s memory not intended to be accessible. In our case it was the HTTPS web server and it stored all requests from users. Exploiting the HeartBleed vulnerability, we managed to get cookie parameters and, as a result, access to the control panel.

Root cause: the application was using vulnerable system components.

Exploitation threat: access to the control panel.

Of course, our customers were promptly notified of these security flaws and got recommendations for their fixing, while our team stayed 100% satisfied with the outcome – we made sure that no app was delivered to customer with such major errors.

Next week we’ll continue with the hardest and most curious security bugs we’ve detected.

What vulnerabilities have you detected? Welcome to the comments!