TOP 10 vulnerabilities from a1qa. Part 2

In our previous post security testing engineer Vadim Kulish talked about five threats that took us no long to be detected. Today we continue with the hardest nuts to crack.

#6. Executable files upload

The tested app enabled to upload .exe files that could be accessed using an absolute file path. The contents of the file were checked, while its extension – was not. The files with the php code couldn’t be uploaded either.

When we were auditing the app, we changed the php file by adding HTML elements to its beginning. The .php extension was left untouched. As a result, we got the complete access to the server and could execute console commands.

Root cause: inadequate .exe files check.

Exploitation threat: getting complete control over the web application.

#7. SQL injection

In security testing, SQL injection is a code injection to the legitimate SQL statement that is inserted into an application entry field for execution. SQL injections may be of different types:

• Visible (the results of the attack can be seen by an attacker);
• Blind injections (the results of the injection are not visible and to get the data we apply the brute force search: the character is valid when the app changes its workflow or the time lag appears).

Possible threats of the SQL injection:

• Data theft;
• Authentication bypass;
• Getting server access control.

Sometimes, to automate the process of injection detection we use an open source penetration tool SQLMAP. However, more often we do it manually.

In our case, the injection was detected on the Home page of the website in the Search element.

Root cause: no input data check mechanisms.

Exploitation threat: getting complete access to the application database.

#8. Local files reading

We were testing the multi user application that stored personal data of its users. The app was built with defects and we could input the local file name in our entry and see the file contents.

Exploiting this vulnerability we managed to get a configuration file that allowed us to get in any account in the app. As the application allowed sending and receiving messages we could reset the users’ passwords and get the links the users would receive to change passwords. By following the link we changed passwords and logged into the app.

Root cause: no input data check mechanisms.

Exploitation threat: access to the web application configuration files.

#9. NoSQL injection

You already know that there is such a threat as a SQL injection. Are there NoSQl injections? Of course! Redis, MongoDB, memcached belong to the non-relational databases and malicious users couldn’t pass them by.

NoSQL ≠ No Injection

The main difference is that NoSQL databases don’t support SQL-like languages. Every database may use its own language. That’s why the number of potential threats increases.

When testing the app we dealt with the MongoDB database.

What did we discover?

The app had API that could be queried. The authentication to the app was implemented with a 32-character token that couldn’t be cracked. After giving a thought, we decided to manipulate the parameter. We learnt the MongoDB documentation and found out that it was possible to input regular expressions into the query and thus minimize the data for the query. As a result, the 32-character parameter was cut down to only 4 symbols that could be guessed to enter the app.

Root cause: no input data check mechanisms.

Exploitation threat:  application authentication bypassing.

#10. Race hazard

It’s probably the most interesting vulnerability we’ve ever come across and it was detected in the finance app.

The race hazard or race condition is the result of the multithreaded application poor design. When it occurs, several threads try to get a concurrent access to the shared memory location and at least one of them performs writing. As a result, the reading thread gets wrong values that were previously changed by the writing thread.

What did our team? We tried to create several concurrent queries to the web application. Actually, the web application is a good example of the multithreaded app as it may have many users working with it simultaneously. The key condition is that the writing (either of the file or to the database) should be performed. On our project, the writing was performed into the database. We generated some queries about money transfer and in return got more than we expected!

To make it more clear: for X coins a user gets Y coins. We generated 10 simultaneous queries to exchange X coins for rubles. As a result, X coins were deducted from our account and we were lucky to get 10*Y rubles.

Root cause: wrong application design.

Exploitation threat: money theft.

To avoid all these threats we urge the companies to conduct regular security checks and test the software products for all kinds of vulnerabilities.

By addressing the professional team, you’ll be confident that your solution poses no risks to users.