Application security is a very complex process. Decision makers often do not allocate sufficient resources to regularly check if the application is in line with the best cyber practices. Serious vulnerabilities in the system often show up only long after they go live. In order to realize this, companies often need to face a serious security incident.
Our customer is responsible for the development and support of a website with thousands of registered users. Our client claims that their team of developers has paid special attention to security from the very beginning. Nevertheless several suspicious and inexplicable incidents have occurred in their application recently. They finally decided to call for help from external experts. As no penetration testing has ever been performed against their website, we suggested the conduct of such testing at first.
The team of Boltonshield has many years of experience in the application security testing of a variety of IT systems. Our activities include professional consultancy services and the training several topics in different fields of IT security as well. Through the years we have gained much valuable experience and we are always happy to support our clients with our expertise.
All technical data in the description (screenshots, script outputs, parameters) were changed in order to protect our client’s anonymity.
First impressions
At the very beginning of the testing it could be suspected that we would encounter serious issues. We listed below some of the signs:
An application managing sensitive data of thousands of users, but it has never been pentested before.
Bespoke software with custom source code in order to increase security. Applying the Security by Obscurity principle can often lead to overconfidence.
The occurred suspicious events are actually very serious security incidents which indicate the existence of exploitable, critical vulnerabilities.
Worries confirmed
The first step of the assessment of a web application security level is the reconnaissance of both the application to be tested and the related resources (files and directories). In doing so, the automated tools (by sending/receiving thousands of requests per minute) can easily detect paths that were intended to be hidden by the developers of the application originally. A few minutes after the start of the testing we already revealed several potentially vulnerable paths:
Revealing paths meant to be hidden
We continued the testing of application security on the internal/admin/login page which pointed to the login page to the administrator interface.
Besides the testing conducted by the automated tools we always attach great importance to the manual tests as well. In general it also allows the revealing of the vulnerabilities which otherwise remain hidden without the expert’s view.
The manual test brought the breakthrough in this case, too. Based on the test done by the automated tools we clearly established that the login process does not have protection against automated password guessing attacks, however, other serious problems were still not revealed in this phase of the testing.
In the course of the manual tests it was obvious at once that after failed login attempts, the application displays a verbose error message which discloses if the given user name is valid.
Verbose error message, the testadmin user does not exist in the system.
It is such a vulnerability which we encounter rather frequently during our work. By the exploitation of the error it can be determined which username is valid in the system, so the attacker can learn the login names of the administrators of the system very easily through automated requests. It may first seem to be a negligible issue but soon we will present the serious consequences it may bring.
In the course of the further tests it became clear that the login process is not vulnerable to the “traditional” SQL Injection techniques but it is still easy to hijack. The reason for this is that the developers did not appropriately implement the procedures which would have been responsible for the sanitizing the data received from the user. The application continued not to remove an SQL control character from the username. It was the “%” character. In our experience it is a frequent error which becomes exploitable only when using certain logical operators. In revealing vulnerabilities it was also important that for failed login attempts the application had disclosed if the given user name is valid in an error message in the previously presented way.
Successful SQL Injection attack with the use of the % control character
Normally the application evaluates the login successful if the username provided is valid and the password provided matches the password saved in the database belonging to the user. However, in this case when providing the “%” as username resulted that the first part of this condition was always true and the login was successful if the provided password belonged to any of the users in the database.
In short, if you manage to find a weak password in use, only by providing this weak password we were able to access the administrator interface.
The next step was that we launched a special attack in which we used every time “%” as username, and we attempted to login with different frequently used weak passwords. This type of attack was possible because of the previously mentioned weakness which permits login automation.
In only a few minutes we managed to gain several valid administrator accesses. One of them owned “system admin” privileges.
After successful login all functions of the admin panel are available
Owning the admin credentials we could access all functions of the administrator panel. Thus we practically took total control of the system and gained access to the data of the thousands of users of the application as well. We could have read and modified the data.
Instant measures
We informed the client of the revealed vulnerabilities as fast as possible since in case of such serious security concerns it is of key importance to take the appropriate measures immediately.
After the subsequent analysis of the application security and its logs in partucular, it was also confirmed that this vulnerability had been exploited several times in the past and the suspicious cases experienced earlier could also be linked to it.
Our client almost immediately started the execution of the detailed action plan suggested by us. Finally it also contributed to the rapid elimination of the vulnerabilities significantly.
What happened afterwards?
Testing of application security continued and we could reveal even more serious security flaws. We presented the results in a detailed report to our client. After fixing the revealed issues we conducted a retest to verify if the previously identified vulnerabilities had really been eliminated and we checked whether new weaknesses have evolved.
After the conclusion of the application security assessments we agreed with our client on the regular retest of the web application at given intervals. According to the feedback, as the result of the years of joint work the suspicious activities which were detectable earlier ceased and the general standard of the service also improved significantly.
We felt especially honored when our client asked us to provide support for their new application. It gave us the opportunity to identify the problems arising in the course of the development even before they had serious consequences. It is the result of our joint effort that our client could develop an application which was in line with good security practices in the most cost efficient way possible.
You can get in touch with us to find out exactly how Boltonshield can help your organisation.
