Today we are going to talk about a vulnerability found in one of our External Pentesting exercises. For security reasons, the name of the client and sensitive information will be obfuscated:
Victim domain: redacted.com
Victim subdomain: documents.redacted.com
Detection
When talking about enumeration and data collection, we must always consider the search for subdomains using Google operators. For this task, we performed the following search with the aim of excluding the “www” subdomain:
- Google Dork: site:redacted.com -www
After contrasting each of the subdomains found with different techniques used and those found with Google, we discovered a new one:
New subdomain: documents.redacted.com
This subdomain presents the main endpoint of “/Pages/Home” and only has the “Login” functionality:
Then we conducted a search in the web’s source code, and in one of the scripts used by the Front-End, we detected a reference to the company’s intranet, and the extension used is “.aspx“:
The next step is to perform a fuzzing attack against the root path of the application with an offensive approach considering searching with “.“, “_“, and the same subdomain name “documents”:
https://documents.redacted.com/.<FUZZ>
https://documents.redacted.com/_<FUZZ>
https://documents.redacted.com/documents/<FUZZ>
ffuf -w redacted.com -u https://documents.redacted.com/_FUZZ -c -ac -r -t 1
From our attack, we captured the “_layouts” path. The next step is again to fuzz against this new endpoint, this time considering the “.aspx” extension that we detected in the source code:
ffuf -w redacted.com -u https://documents.redacted.com/_layouts/FUZZ.aspx -c -t 1 -r
Among the new endpoints obtained, one particularly draws attention:
Endpoint: https://documents.redacted.com/_layouts/viewlsts.aspx
Attempting to enter, we encounter the typical error of blocking by a WAF or inherent web protections:
Exploitation
At this point, we had several ideas on how to bypass and tried various of them without success. What led us to look more closely. In what conventional and unsecured way can authentication be handled in an application? Cookies!
In the request sent to the server we find that the cookie parameters are three:
- MySession=<value>
- cookiesession1=<32_character_value>
- Ribbon.Document=1920993|-1|397|475783322
Particularly the “Ribbon.Document” cookie quickly caught our attention.
Ribbon is known for its communication solutions and session control software, especially in the context of Session Border Controllers (SBCs) used in telecommunications networks to facilitate security and session control:
Ribbon session cookies are often used by web applications to maintain the user’s session state, such as authentication or tracking the user’s activity during a specific session on a website.
The next step we took is to remove this variable from the “Cookie” header; however, nothing happens. Next, we made one more modification to the “Cookie” header, this time with the “cookiesession1” parameter.
We removed the pre-established values but maintained the length (32 characters), and oh surprise! now the server allows us to view the web content:
Recapping the necessary and sufficient conditions to successfully bypass the defense mechanisms then are:
- Modify and keep the length of the cookie parameter “cookiesession1” to 32 characters.
- Remove the “Ribbon.Document” cookie parameter.
Finally, within this endpoint, we can view private and critical documents of the organization with classified information and only visible to authorized users with the highest level of access:
Conclusion
In conclusion, the importance of having a well-customized list of words and always thinking about how a developer would implement their design is the key to success in certain scenarios.
Thank you for reading.