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

6-march-2023-1
21 March 2023,
by a1qa
4 min read
The ultimate QA guide for smoothly migrating to Web 3.0
Find out how businesses can seamlessly migrate to Web 3.0 by relying on quality assurance.
Cybersecurity testing
General
Performance testing
Usability testing
27 February 2023,
by a1qa
5 min read
Reaching HIPAA compliance for eHealth solutions through QA
We reveal HIPAA’s data safety benchmarks and shed light on how software testing may help in its conformity.
Cybersecurity testing
Software lifecycle QA
Mobile app testing
15 February 2023,
by a1qa
4 min read
Mobile app testing guide: win the race with five-star software
Which aspects of mobile apps to test first to produce a really high-quality product? Find the answer to this and other questions related to mobile app testing in the article.
Cybersecurity testing
Functional testing
Mobile app testing
Performance testing
Test automation
Usability testing
qa-trends-in-telecom
30 September 2022,
by a1qa
5 min read
4 telecom trends for 2023 and how to painlessly implement them with QA
It’s time to explore the telecom trends for the upcoming year. Let’s look at them together and also see the value that QA brings for their smooth deployment.
Cybersecurity testing
Migration testing
QA trends
Quality assurance
Test automation
black-friday
29 July 2022,
by a1qa
4 min read
Get ready for Black-Friday-to-Cyber-Monday shopping: 5 testing types to include in your QA strategy
What’s your nightmare during Black Friday and Cyber Monday shopping? If it’s a loss of sales, read about the ways to prevent this in the article.
Cybersecurity testing
Functional testing
Localization testing
Performance testing
Usability testing
30 June 2022,
by a1qa
4 min read
App software testing for telecom: What are the common issues telco providers face?
Facing problems with the quality of your telecom software products? Read more in the article and find out the ways to address them.
Cybersecurity testing
Performance testing
Test automation
20 June 2022,
by Alina Karachun
5 min read
Top-quality IoT solutions: 3 problems and ways to solve them
What quality aspects of IoT solutions are predominant to care about and why? Find the answers in the article.
Cybersecurity testing
IoT testing
Performance testing
19 April 2022,
by a1qa
5 min read
What prevents companies from boosting eCommerce customer experience: 4 common mistakes
Dreaming of a flawless online shopping journey for your users? Explore 4 widespread situations that hamper achieving this goal.
Cybersecurity testing
Performance testing
Test automation
Usability testing
Clutch awards
23 March 2022,
by a1qa
2 min read
a1qa recognized for cybersecurity expertise by Clutch!
The global online review platform Clutch added a1qa to the Top 15 Penetration Testing Companies for 2022.
Cybersecurity 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.