False Sense of Security

Are your security scans getting the coverage you need?

One of my posts on Application Security and Penetration Testing

Free Content on Jobs in Cybersecurity | Sign up for the Email List

This topic came to me by way of a recent penetration test. I faced a myriad of issues trying to scan a customer environment for the very basic security flaws that scanners tend to find. We always go beyond that to dive deeper into architecture and assess attack paths. But basic scanning is a solid place to start.

In this case, my scanner got repeatedly locked out almost immediately. Our contract and proposal state that for the best coverage and fastest results, clients should turn off rate-limiting tools for our IP addresses, as well as things that auto-block based on activity. That way 2nd Sight Lab can quickly and thoroughly scan for many known vulnerabilities. In this case, something on one of the sites was automatically locking out the account repeatedly.

Any experienced penetration tester will tell you there are ways around these types of auto-blocking tactics. They are excellent security controls for weeding out the script kiddies scanning the web with automated tools they pulled down from GitHub and are spewing across the entire Internet indiscriminately. So I’m not suggesting you should turn off these security tools completely!

The thing is, a persistent attacker will be able to bypass them to get to your thinly veiled web application flaws. They will poke and prod from different IP addresses and domain names and networks until they find a way around these basic blocking tacts. These methods of protection only slow down attackers in most cases. You still need to fix the underlying web application flaws.

In the case of a recent penetration test, it was clear that the customer used a well-known scanner to test their applications. That scanner left a trail as noisy as 2nd Sight Lab does when we perform penetration tests aimed at coverage rather than stealth. However, in the application where we faced repeated blocking issues while trying to test the site, no sign of this other scanner existed.

After hitting some issues with the scanner on this particular application I sent an inquiry to the customer about some of the issues I was facing. While waiting for an update from the client, I ran through some manual tests and found numerous basic cross-site scripting (XSS) vulnerabilities. Either they hadn’t run the scanning tool in that environment, or it was facing the same issues I was and providing the customer a false sense of security. The scanner might not be finding any problems, but that doesn’t mean they don’t exist in some cases.

We were able to get around the blocking issues initially by working with the customer to turn off network rate-limiting. That way we could run the scan more quickly. We could have worked around the rate-limiting. We would only slow down the scanner and alternate the timing of our attacks. We may have to attack the site from different networks or IP addresses.

Had we needed to slow down to bypass the rate-limiting and implement changes to bypass any other behavioral-based blocking, the test could have taken many months to complete, and we might not be able to get as much coverage. We aim to find as many vulnerabilities as possible in the allotted time. Rate limiting is not a benefit to the customer in this scenario. It just means we won’t be able to report all the vulnerabilities we could find otherwise.

On one of the sites, we worked around lockouts by automating various mechanisms to satisfy authentication requirements. Each programming language, authentication, or authorization mechanism may have different requirements. Sometimes you need to craft the appropriate requests and write custom code to allow scanners to work correctly. Ruby has a CSRF token challenge. Applications leveraging Azure authentication mechanisms require obtaining a token from a service to proceed. Applications leveraging .NET require numerous cookies in some cases that need to be tracked and refreshed at appropriate times. Other applications may need you to request a new JWT token on every request.

Once we made some progress on a few applications, we returned to the pesky site that gave us grief from the beginning. After additional troubleshooting, we realized that the login page was getting cached in place of the page we were trying to reach. We weren’t actually getting locked out. We could log in and access other pages, just not the one we were trying to test with a particular set of credentials. A scanner would likely not recognize or tell you if that is happening.

In another case, while testing HTTP Request Smuggling, it became clear that something was thwarting our attempts to validate the vulnerability existed. Earlier, we had a positive and certain finding, we were just trying to demonstrate the severity to the client. Upon revisiting the vulnerability, it appeared that some cloud provider tool or service was blocking our pentesting domain. Not every domain. Just ours.

What’s the problem with that? We might go back and say, “Nope, you’re good. There’s no problem.” The attacker comes along using a different domain and BOOM. Stolen credentials, data, or one of the many other problems resulting from a dangerous vulnerability like that. You need to know when a problem doesn’t exist versus when some security tool is simply blocking access to vulnerabilities under the surface. That is not always easy or possible to do in the time we have for a penetration test, but we aim for coverage and try to make sure we get it.

If your cloud provider is blocking anything, make sure you understand what it is and how it may be hiding information from your scanners, but not attackers. Ideally, you can turn it off for the IP addresses performing scans during a penetration test or scan. Then you can understand if you have underlying vulnerabilities. Security tools are great to help ward off attacks, but sometimes those tools only stop simple attacks, not devious, crafty, persistent attackers.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2021

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab