Blog

Top 10 vulnerabilities from a1qa. Part 1

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.
5 December 2016
Cybersecurity testing
The article by a1qa
a1qa

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!

More Posts

5G impact
31 May 2021,
by a1qa
4 min read
5G network impact on mobile app testing
Check out what 5G connectivity will bring to the IT world and how it will modify mobile app testing.
Cybersecurity testing
Mobile app testing
Performance testing
29 April 2021,
by a1qa
4 min read
Addressing 4 security issues for digital transformation programs
Find out the top 4 safety challenges of digital transformation and a QA playbook to address them and contribute to a higher level of cybersecurity.
Cybersecurity testing
31 March 2021,
by a1qa
4 min read
QA scenario to introduce 6 eCommerce trends in 2021
Discover what trends will rule the eCommerce industry in 2021 and how QA can help implement them with confidence and ease.
Cybersecurity testing
Test automation
25 February 2021,
by a1qa
4 min read
9 QA points for delivering high-quality SaaS-based solutions
In the article, we’ve gathered 9 QA factors relying on the SaaS specifics that may help to perform SaaS testing with ease.
Cloud-based testing
Cybersecurity testing
Functional testing
Performance testing
Test automation
16 February 2021,
by a1qa
5 min read
Winning trust: 5 industries that need blockchain testing
Get to know what industries are prone to rapid transformation within blockchain solutions, and how their catch-all testing can help keep leading positions.
Blockchain app testing
Cybersecurity testing
Functional testing
Performance testing
13 January 2021,
by a1qa
4 min read
Reaching HIPAA compliance for eHealth solutions through QA
We reveal the HIPAA’s data safety benchmarks and shed light on how software testing may help in its conformity.
Cybersecurity testing
Software lifecycle QA
30 November 2020,
by a1qa
5 min read
Acumatica: ensuring sound business operations with well-tested ERP system
Internal business activities are advancing, while ERP systems’ usage is growing rapidly. Explore how to ascertain their accurate work through timely applying QA.
Big data testing
Cybersecurity testing
ERP testing
Functional testing
Performance testing
Test automation
19 August 2020,
by a1qa
4 min read
Data migration to the cloud: enable robust transition through QA
With cloud computing being a pervasive technology, many companies still face challenges to set well-tuned information transfer. Learn how to avoid possible quality issues and be confident in data safety.
Cloud-based testing
Cybersecurity testing
Migration testing
Performance testing
24 July 2020,
by a1qa
4 min read
OWASP as a guide to mobile apps security testing
More apps, more sensitive data, higher security levels... Learn how companies address the challenge of providing secure solutions harnessing unbiased safety recommendations.
Cybersecurity testing
Mobile app testing

Get in touch

Please fill in the required field.
Email address seems invalid.
Please fill in the required field.
We use cookies on our website to improve its functionality and to enhance your user experience. We also use cookies for analytics. If you continue to browse this website, we will assume you agree that we can place cookies on your device. For more details, please read our Privacy and Cookies Policy.