While evaluating a client’s on-premises deployment of a third-party survey web application during a recent perimeter security assessment, Optiv identified two vulnerabilities now classified as CVE-2021-41608 and CVE-2021-41609. The vulnerabilities yielded unauthenticated access to over 300 uploaded survey user file attachments, including resumes, contracts and other documents, due to broken access control, as well as access to and control over the application’s back end database via SQL injection. This blog aims to walk through my discovery process on identifying these vulnerabilities and highlight the importance of showing impact in the disclosure process.

 

 

About ClassApps Inc SelectSurvey.NET v5.0

SelectSurvey.NET is a web-hosted survey application written in ASP.NET supporting MS SQL, MySQL or Azure database backends with several advanced features, including automated survey deployment and workflows, HR onboarding, performance reviews and more. The SelectSurvey.NET application allows for easy deployment of surveys and viewable real-time results, making complicated workflows like HR management easier.

 

 

 

 

Discovery Process

One of my first steps after identifying the version of a web application is to determine whether it has any current or past public vulnerability disclosures, and fortunately, I found CVE-2014-6030. This disclosure involved two SQL injection vulnerabilities that had long since been patched. While the version I worked with was no longer vulnerable, the disclosure usefully identified a file upload endpoint I had yet to locate at UploadImagePopupToDb.aspx. Since I had managed to acquire low privileged user credentials for the application elsewhere during the engagement, I was able to authenticate to the application, navigate to this endpoint and test its functionality by uploading files.

 

 

 

My original goal was to understand what files could be uploaded and where they were stored to possibly bypass file upload restrictions and gain access to the host. However, as this was a black box test, I had no access to source code or prior application knowledge. So, I took advantage of ClassApps Inc’s 30-day trial option to work in a sandbox environment and test the endpoint with administrative access.

 

With my trial account setup, I navigated to the previously mentioned file upload function and uploaded several test files. Next, I used my administrative access to identify files uploaded by this method were made available from the UploadedImageDisplay.aspx?ID=(x) endpoint where “x” is the file’s corresponding value. I found that files uploaded in this nature were being stored in a database in sequential order; the first upload being given a value of “1” the second “2” and so on. By simply stepping through each value, I was prompted to download the corresponding file.

 

 

With this discovery, I returned to our client’s environment and identified the same behavior in file storage. By stepping through the file sequence, I was able to access other users’ submitted file attachments to completed surveys with my low privileged access, unlike my privileged access with the test environment.

 

After validating this finding, I tested the application’s access controls from an unauthenticated position by signing out and navigating to the endpoint requesting file ID 1. The application handled the request and prompted me to save the corresponding file.

 

 

While the application had been patched for the previously disclosed SQL injection vulnerabilities, the disclosure provided more value during my assessment, as it identified that the application was historically vulnerable to Boolean-based blind injections. This helped me to narrow my approach when testing for the existence of an injection vulnerability in this newly discovered endpoint.

 

 

SQL injection, according to the Open Web Application Security Project (OWASP), “consists of insertion or ‘injection’ of a SQL query via the input data from the client to the application.” By submitting a value of “1” to the ID parameter in the endpoint, the application is issuing a SQL query to the database to retrieve the corresponding file. That SQL query might look something like this:

 

 

An injection occurs by interfering with, adding to or even causing the application to ignore the above example. Boolean-based blind SQL injection is a technique that uses logic to force the web application to behave errantly, known as “error-based enumeration.” Once the researcher understands how an application normally operates, SQL queries that are logically false, such as 1=2, will cause the application to change its behavior. This change in behavior is the error in error-based enumeration.

 

In my case, the normal operation was to retrieve a file for a corresponding value. By appending an AND statement of 1=1 to the value submitted to the ID parameter, the web application returned the requested file. The new SQL query likely looked like this:

 

 

 

Now the SQL query requires two true conditions: the file requested must exist and the logic of the AND statement must be true. Because both cases are true, the file is returned. However, this does not prove the existence of an injection.

 

Confirmation comes after adjusting the AND statement to 1=2, resulting in the web application redirecting to an access denied page. This is due to the SQL server handling the AND statement and returning FALSE regardless of if the file exists or not, as both cases must be true.

 

 

In summary, I have validated two potentially critical vulnerabilities in this application: remote, unauthenticated information disclosure and SQL injection. Both discoveries were made possible by identifying previously disclosed vulnerabilities and creating a sandbox environment for further testing. As a researcher, this is an exciting point. However, my job isn’t quite done yet.

 

 

Impact

As consultants or security researchers in general, one of our primary responsibilities is demonstrating impact. When we discover a vulnerability, it is our job to answer the “Why should I care?” question so our clients can fully understand their risk. Alone, these vulnerabilities demonstrate a threat to our client and application users, but what is it? Is it data disclosure? How much of it? Answering these questions requires leveraging the vulnerability and moving into the exploitation phase.

 

 

Example Attack Scenario: CVE-2021-41608 - Broken Access Control

I will begin with CVE-2021-41608. Working with the vulnerable endpoint and understanding how to retrieve files, now my goal is to scale higher. What data can I retrieve, and how much of it can I access?

 

For this attack scenario, I will be using two tools:

 

 

First, I navigate to the vulnerable application and append “UploadedImageDisplay.aspx?ID=1 to the URL and intercept an unauthenticated GET request with Burp Suite. Retrieval occurs with Burp Suite’s Intruder module by configuring a sniper attack targeting the value of the “ID” parameter. The sniper attack loops over a provided payload list, replacing the specified position with the list’s value one request at a time.

 

 

Next, I load a payload list of sequential numbers beginning from 1.

 

 

Execute the attack and review the responses to identify file types and contents. In the below screenshot, you will see the responses of each request and the content length of the response — essentially the size of the corresponding file. Previously I only validated unauthenticated access to one file, yet now I have proven access to multiple files.

 

 

It is important to note that Burp Suite is not downloading any files. The tool simply handles the requests and provides the responses. To demonstrate how a malicious actor might leverage this vulnerability, a simple Bash for loop is more than enough to automate the retrieval of every file identified by the intruder attack.

 

 

The above loop will submit a request for all files in a sequence of one to “x” where x is the ID value of the last file Burp Suite identified in the intruder attack. The $i variable is set to each concurrent ID value in the sequence delivering a unique wget command for each value. This is demonstrated in the below screenshot.

 

 

By showing how a malicious actor would leverage the vulnerability, I have tangible numbers to how many files could be accessed and the contents of those files. It is this type of data that demonstrates impact.

 

 

Example Attack Scenario: CVE-2021-41609 - SQL Injection

Continuing with CVE-2021-41609 and the Boolean-based blind SQL injection as demonstrated previously in the discovery process, I have a validated vulnerability. Yet, again, I lack impact. What can I do with this vulnerability and how far can I take it? Is it simply a bug in the code or can I access the application’s backend database?

 

For this attack scenario, I will be using two tools:

 

 

I begin by navigating to the vulnerable application and leverage the Repeater module in Burp Suite by intercepting a request to the target URL appended with “UploadedImageDisplay.aspx?ID=1”. Then, with error-based enumeration available, I test for an injection point with UNION-based SQL injection.

 

UNION injection works by extending or replacing the original query being sent to the database by the web application. If vulnerable, an attacker would be able to interact with and extract information from the database. But there is a requirement for this type of injection to work: the new query must match the structure of the original query, meaning it must contain the same number of columns.

 

The number of columns can be identified with sequential ORDER BY clauses using the same error-based enumeration performed earlier. ORDER BY clauses where the column exists will return the requested file. The correct number of columns is confirmed once the first 302 redirect (error) occurs. In the example below, the number of columns is two because the application returns an error on the third request.

 

 

In my attack scenario’s case, the correct number of columns for the UNION injection is 11, as identified by the error on the 12th request.

 

 

 

Because the current web application utilizes Microsoft SQL, the string function CHAR confirms that the backend SQL server is handling injected queries. This function transforms a given numerical value to its corresponding character, such as CHAR(65) returns “A.” By submitting a request for a nonexistent file, -1, and appending a UNION ALL SELECT SQL query, the web application will return the transformed CHAR values. Remember, the structure of the injection must match the original query, so for each column not being used to inject the CHAR function, a null value is submitted in its place.

 

 

 

The MS SQL database returns the handled CHAR function in the web application response transforming the submitted CHAR values to “OPTIV.” Next, I will leverage the vulnerability with SQLmap to automate further interactions with the application’s database. SQLmap is a powerful tool that can validate a SQL injection vulnerability, leverage access to alter data stored in the database, and even provide remote access to the host operating system if the correct privileges are available.

 

By passing the vulnerable endpoint to the tool, it identifies the same UNION-based SQL injection query and returns details of the database’s host operating system.

 

 

To protect our client’s privacy, I cannot share any more details from this point forward. However, I can speak to what I was able to perform with this access:

 

 

 

Conclusion

Before the attack scenario phase, I described the validated vulnerabilities as:

 

 

Yet now I have enough information to demonstrate the true impact of these vulnerabilities with evidence:

 

 

 

 

Mitigations

Organizations should replace the vulnerable version with the latest version of ClassApps Inc. SelectSurvey.NET v5.052.000.

 

For those still using the vulnerable versions of the application:

 

 

 

Vulnerability Disclosure Timeline