Web Security by Bugbounty

Alexander Kolesnikov (virus analyst in an international company) invites you to a master class “Technology fundamentals needed to understand vulnerabilities. OWASP TOP 10 classification “, which will take place as part of a professional course. Alexander also shared an article for beginner bug hunters, where he reviews the TOP 10 Vulnerabilities of 2020 that were found by the HackerOne platform.

The idea is as follows – to prepare a laboratory bench to study the vulnerabilities in this top. You can read about how to launch and find an example application with a vulnerability here. The tasks will be solved before the exploitation of the vulnerability in the application, the last step will be left to the readers.

TOP 10 vulnerabilities by HackerOne

Information on the top vulnerabilities can be found here… I will give below statistics on payments for each of the vulnerabilities:

This suggests a comparison with a very popular list – OWASP TOP 10. But it should be borne in mind that the last time an update to OWASP TOP 10 was made in 2017. At the moment, information is being collected to update the list. So, let’s carry out a comparative analysis of these ratings:

The OWASP list contains many vulnerabilities, while the HackerOne list contains specific vulnerabilities. Let’s combine all the vulnerabilities from the HackerOne list into types:

  • Injection

  • Broken Authentication

  • Sensitive Data Exposure

  • Security Misconfiguration

It turns out that to create a suitable laboratory for research, it is enough to find 3 vulnerable applications.

Injection

Injection is a method of exploiting vulnerabilities that allows you to add your commands for execution to the data processed by the application. This can lead to a variety of consequences, from gaining access to all of the application’s resources to executing code on the server side. The test application of the current section will contain a vulnerability that allows you to inject your own python code into the application code.

As a test, consider attachmentthat was used in the Real World CTF competition. The application provides the user with information about the books.

Let’s try to find out what structure this application has. We send any HTTP request using BurpSuite Community, we get the following:

The login form and the admin page are the same page – “Login”.

Standard tests for typical vulnerabilities for this form did not bring results, nor did standard passwords fit. This is probably not an attack vector. Let’s look at the tip left by the creators of the vulnerable application. The hint is in the application source code. You can download it at “source.zip”. Thus, we have a fully functional application that can be used for local research and search for vulnerabilities / shortcomings that were allowed while writing it.

We are only interested in the files that contain the code:

After analyzing the source code, it becomes clear that the application uses the framework to build Flask web applications. It is known that this framework can run an application in 2 modes – debug and release. In the debug version, the standard port is 5000. Let’s check if this port is used on the server:

It looks like another variant of the app is running. Perhaps this can be useful for checking versions of attacks against an application. Let’s look for vulnerable parts of the source code.

File of most interest:

.viewsuser.py

The vulnerability is in the code snippet shown above in the screenshot. The problem with this code is that the decorator @login_required specified in the wrong sequence, which makes its use pointless. Any user of the application can use the code that is called through the call to /admin/system/change_name/… There is also a piece of code that may also be interesting:

The source uses some Lua code to work with Redis. The data is initialized directly from the token that the user sends to the server. An application can be attacked through Redis. Data from the token will later be sent for processing to the python module – pickle. This can be used for code injection.

Security Misconfiguration

The vulnerability is that a misconfiguration could be exploited in the application’s technology stack, or it could contain a well-known vulnerability for which no patch was applied. Security misconfiguration can be used to retrieve sensitive information from a web application – configs, sources, etc.

We will use again the task from the Real World CTF competition. The application is a simple file downloader and can be used to download images from any source:

Let’s check the interface for the ability to read local files, for example, file:///etc/passwd… This technique will help us find out if there is a vulnerability from the title in this task. The result can be seen below:

The task implies the ability to force the server to execute the commands that we tell it, thanks to the information obtained through the exploitation of the vulnerability. Therefore, the next step will be useful for us to find out exactly how the application is launched on the server. Using the command file:///proc/self/cmdline you can get the application launch line:

The application works using a uwsgi server and can use the appropriate protocol to broadcast data from server to application and vice versa. The server works through socket 8000. The application working directory is “/ usr / src / rwctf”. To complete the attack, it is enough to learn how to create commands for uwsgi, with which you can control the server.

Broken Authentication, Sensitive Data Exposure

Broken Authentication – a vulnerability that can be used to access application resources bypassing the access control system. Sensitive Data Exposure – a vulnerability that can be used to access sensitive application data. These can be application configurations, logins and passwords from third-party services, etc.

The next application to be examined has collected the maximum number of vulnerabilities from the required list. This application was used in the “35c3 CTF” competition. It provides a minimal interface for registering users and gaining access to the private part. It looks like this:

Input fields accept nothing but the correct sequence of data. Let’s try to check how error-free the server is configured for data processing. Let’s run the dirbuster tool to find a list of directories that are specific to the application. As a result, the uploads directory was found, which returns an HTTP code of 403. Modify the path using special characters from the file system. To do this, simply add the symbol for the transition to the directory one level above: /uploads../:

It looks like we found all the vulnerabilities at the same time. We do not need to enter a username and password to access application data. We have full access to the original application. Now you need to find a way to execute your commands on the server. Here you can use the approach from the first task.

Instead of output

The content of this article can be used as a laboratory work for those who are just starting the path of searching for vulnerabilities in web applications. With their help, you can gain basic practical skills in web application testing and gain the first independent experience in this area.

Disclamer: All applications used belong to their authors.


Information on the top vulnerabilities can be found here… Is it interesting to develop in this direction? Learn more about the professional program “Web Application Security”, come to the Open Day and sign up for a free demo lesson “Technology fundamentals needed to understand vulnerabilities. OWASP TOP 10 classification “

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *