Thinking Like an Attacker: How Red Teams Hack Your Site to Save It

As discussed in SlashBI’s recent “Symphony of Self-Destruction,” the use of a Red Team and penetration testing can strengthen an organization’s security posture. But how does a Red Team member actually think like an attacker, and use that mindset to exploit security vulnerabilities?

Gillis Jones works for WhiteHat Security, where his job rests within the TRC (Threat Research Center). It’s here that he performs hands-on site assessments, which involve manually confirming all the issues reported by an automatic scan of a particular Website or application. Given how automatic scans won’t catch every potential exploit, that manual checking is a necessary and important job.

“In order to develop a realistic analysis of your security posture, pentesting and applications analysis is absolutely essential,” Jones said in an interview. “A good pentest can reveal issues that you weren’t initially aware of, and it can also help bring to light systemic design [and /or] implementation issues.”

Over the course of the discussion, it became clear that Jones sees the actual process of pentesting as a somewhat repetitive task, given how the same issues keep cropping up in organization after organization. Given how these same vulnerabilities sometimes lead to headline-grabbing data breaches, however, it’s important for Jones to ferret out and close down every single one as soon as possible.

Pentesting

While the primary goal of pentesting always remains the same—determine the weak points in any given application or network—the actual execution varies from practitioner to practitioner.

“I like to get a feel for the site itself, because you can’t really test a site unless you have an almost flawless idea of how it works and how the different parts interplay,” Jones explained.

For example, when testing a banking application, he will make a few transactions in order to determine the operational thresholds. His aim is to build a mental map of the Website and its applications, so he knows “where to hit, where important functionality is, stuff like that.”

This includes checking the application’s POST and GET requests for reflection of any inputs. It allows him to check for Cross-Site Scripting (XSS), which includes stored, reflected, and DOM XSS vulnerabilities. Those checks let him determine the Website’s basic security posture. If user input isn’t encoded or sanitized, that’s a good indicator of other problems. And if that’s the case, then Jones (or someone like him) will move on to checking for SQL Injection (SQLi) vulnerabilities and other issues.

Yet just because there are XSS issues present, that doesn’t always mean that the entire website is vulnerable. Sometimes, XSS flaws are present because a developer pushed code into production without proper QA checks. As mentioned, Jones manually tests a client’s Website first, before moving on to manually confirm the results of static scan. This process can reveal several problems, some basic and some complex. The most common issue discovered during his daily routine is information leakage: it’s the bane of his existence.

“This is where people are exposing their ASP.net version number, what specific OS their running, stuff like this. Things that essentially allow me to reduce the amount of time it takes for me to exploit your site,” Jones explained.

By itself, information leakage isn’t a major risk. However, when several points of information leakage are chained together, an attacker who knows the server is using an outdated version of Apache and PHP now has a starting point for an attack. Another example of information leakage comes from code comments. If the difference between a production application and one in development is commented-out HTML code (which is visible to the public and references the DEV environment), a would-be attacker now has a new target to examine.

There are other, lesser-known issues that are just as important.

“Insufficient authorization is actually a really big one,” Jones said. When proper authorizations aren’t put in place, banking apps (to go back to the previous example) allow a user logged-in with valid credentials to access records from other customers instead of holding them to their data alone.

Local File Inclusion (LFI) is another issue that Jones encounters on a regular basis. It’s not as common as the others, but it appears more often than he would like. With LFI, an attacker can access files outside of the Web directory, such as configuration scripts or server resources such as /etc/passwd files.

Other Issues

In Jones’ view, Brute Force and Insufficient Anti-Automation can almost be combined into a single issue: An attacker targeting these issues can either make an unlimited amount of password attempts, or call a password reset script repeatedly, in an attempt to gain access to an organization’s application or Website.

These vulnerabilities are easily discovered and exploited. When Jones recently tested an undisclosed bank, he discovered that, by chaining various vulnerabilities together, he was able to transfer money from any account to any account via a GET request. Playing the role of an unauthenticated attacker, Jones was even able to specify how much money to send.

In another example of a strange issue during a pentest, Jones discovered a base64-encoded value in the URL used by a mobile payments provider’s app. The URL had a “file=” parameter, but the base64 value was being reversed. Yet when the base64 was decoded, it turned out to be a server path leading to the customer’s account data. The application would allow any server path to be encoded with base64; when the encoding was reversed and submitted, the application passed it on and displayed whatever was asked. That flaw had the potential to expose transaction details or other sensitive works.

Sometimes though, vulnerabilities such as SQLi, XSS, information disclosure, etc. aren’t even needed for an attacker to gain access. Jones mentioned one company with a publically faced administration portal that used a user name and password combination of “admin.” Once accessed, an attacker had the ability to alter user accounts, read and write to databases (or turn them off for that matter). While he wouldn’t name the company, he did confirm that it was part of the Fortune 500.

Contracting a Red Team

“You need to know what kind of assessment base you have,” Jones said. This includes knowing how many applications or networks that need scanned.

Depending on the scale of things, an organization has to be confident that the outsourced pentesting firm can handle the job. Pentesting can be automated, but automation will never catch the business-logic flaws that attackers routinely exploit. This means someone has to test things manually. So if a firm needs 1,500 applications tested within a two-week timeframe, then the pentesting firm has to be able to do the job accurately and on time.

The security company should also have the ability to meet your organization’s needs when it comes to scale and time. The easiest way to ascertain this is to ask around, and to talk to other companies who have used the prospective firm. “Word of mouth will get you further than any sales guy assuring you they’re the best in town,” Jones added.

This also means that, before hiring a pentesting firm, the organization needs to know if the former uses a mix of automated vulnerability scanning and manual testing. A mix of the two will offer better results, but this often comes with a higher price. While manual or automated testing alone is often less expensive, the tradeoff is the overall value and quality of the test.

Another aspect to the selection process, especially when it comes to applications, is code. The organization needs to ensure that the pentesting firm can actually assess the code in which the application is written. It should also be clearly explained whether the final report will be delivered in multiple formats, and if any third party will have access to an organization’s vulnerability data. Finally, the contract needs to have a clearly defined start and end date.

Reactions

Jones said that organizations vary in their reactions to pentesting. He’s had companies tell him that they don’t care about a discovered SQL Injection; he’s heard developers resign over the phone during a vulnerability review call.

When it comes to addressing the discovered vulnerabilities, he’s seen clients take months to fix a basic XSS flaw. The time gap between those who rush to repair problems and those who let those issues linger, Jones explained, really depends on the internal security policies of the company. Yet, this leads to another thing that organizations should look for in a pentesting company—help.

There is tremendous value in the pentesting firm that can help you remediate vulnerabilities after they are discovered. “Essentially, any time a developer wants to ask a question, we have an interface for them to ask questions directly of the engineer that actually tested their website. So if they have questions concerning how to remediate a vulnerability, or suggested paths of security, they can ask us,” Jones said.

When it comes to public-facing code, network defenses and policy implementation, continuous security testing is a must. Pentesting can be a time-consuming and sometimes painful process—nobody likes to hear their code is flawed—but it’s far better to learn about a vulnerability from a pentester before anything bad happens, than from a reporter in the wake of a massive data breach.

“A good pentest can provide a company with essential benchmarks for their internal security posture, and provide actionable results on which organizations can build a rapidly maturing security program. At the end of the day having actionable results is the sticking point of any mature security program,” Jones said.

 

Image: wongwean/Shutterstock.com

 

Post a Comment

Your email address will not be published.