Every Solution You Can Imagine – and More
What cybersecurity solution do you need? From Zero Trust to ADR, IAM, risk/privacy, data protection, AppSec and threat, securing digital transformation, to resiliency and remediation, we can build the right program to help solve your challenges.
A Single Partner for Everything You Need
Optiv works with more than 450 world-class security technology partners. By putting you at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can.
We Are Optiv
Greatness is every team working toward a common goal. Winning in spite of cyber threats and overcoming challenges in spite of them. It’s building for a future that only you can create or simply coming home in time for dinner.
However you define greatness, Optiv is in your corner. We manage cyber risk so you can secure your full potential.
ClassApps Inc. SelectSurvey.NET v5.0 Vulnerabilities Disclosure
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.
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.
Figure 1: SelectSurve.NET Administrative Dashboard
Figure 2: Example SelectSurvey.NET Survey
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.
Figure 3: CVE-2014-6030 Vulnerability Detailing File Upload Endpoint
Figure 4: Discovered File Upload Function
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.
Figure 5: Database File Storage Manager
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.
Figure 6: Unauthenticated Access to Uploaded Files
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.
Figure 7: CVE-2014-6030 Historical SQL Injection Vulnerabilities
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:
SELECT * FROM "TABLE_NAME" WHERE ID = 1
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:
SELECT * FROM "TABLE_NAME" WHERE ID = 1 AND 1=1
Figure 8: URL Encoded AND 1=1 Returns the Requested File
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.
Figure 9: URL Encoded AND 1=2 Returns a 302 Redirect
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.
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.
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.
Figure 10: Sniper Configuration Targeting the Value of the "ID" Parameter
Next, I load a payload list of sequential numbers beginning from 1.
Figure 11: Loaded Sequential Payload
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.
Figure 12: Intruder Attack Returning Multiple Uploaded 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.
for i in $(seq 1 x); do wget https://<URL>/UploadedImageDisplay.aspx?ID=$i; done
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.
Figure 13: Bash Wget Loop Automating File Retrieval
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.
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?
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.
Figure 14: ORDER BY 11 Statement Returning the Requested File
Figure 15: ORDER BY 12 Statement Returning a 302 Confirming 11 Columns In Use
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.
ID=-1 UNION ALL SELECT NULL,NULL,NULL,NULL,CHAR(79)+CHAR(80)+CHAR(84)+CHAR(73)+CHAR(86),NULL,NULL,NULL,NULL,NULL,NULL--
Figure 16: UNION Injection Handling the CHAR Function Returning "OPTIV"
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:
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:
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:
Optiv Security: Secure greatness.®
Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to nearly 6,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit www.optiv.com.
January 11, 2022
We identified Ivy framework fileless attack techniques that execute undetected in Microsoft Office. Here's how with suggested security augmentations.
August 17, 2021
We leveraged Microsoft’s OAuth authorization flow for a phishing attack. Here’s step-by-step guidance on how to conduct it for security assessment.
August 10, 2021
Multiple CVEs involving Active Directory Certificate Services and a new NTLM relay attack can be chained to compromise an Active Directory domain.
Let us know what you need, and we will have an Optiv professional contact you shortly.