DevelopSec

penetration test

by Leave a Comment

XSS in Script Tag

Cross-site scripting is a pretty common vulnerability, even with many of the new advances in UI frameworks. One of the first things we mention when discussing the vulnerability is to understand the context. Is it HTML, Attribute, JavaScript, etc.? This understanding helps us better understand the types of characters that can be used to expose the vulnerability.

In this post, I want to take a quick look at placing data within a <script> tag. In particular, I want to look at how embedded <script> tags are processed. Let’s use a simple web page as our example.

<html>
	<head>
	</head>
	<body>
	<script>
		var x = "<a href=test.html>test</a>";
	</script>
	</body>
</html>

The above example works as we expect. When you load the page, nothing is displayed. The link tag embedded in the variable is rated as a string, not parsed as a link tag. What happens, though, when we embed a <script> tag? 

<html>
	<head>
	</head>
	<body>
	<script>
		var x = "<script>alert(9)</script>";
	</script>
	</body>
</html>

In the above snippet, actually nothing happens on the screen. Meaning that the alert box does not actually trigger. This often misleads people into thinking the code is not vulnerable to cross-site scripting. if the link tag is not processed, why would the script tag be. In many situations, the understanding is that we need to break out of the (“) delimiter to start writing our own JavaScript commands. For example, if I submitted a payload of (test”;alert(9);t = “). This type of payload would break out of the x variable and add new JavaScript commands. Of course, this doesn’t work if the (“) character is properly encoded to not allow breaking out.

Going back to our previous example, we may have overlooked something very simple. It wasn’t that the script wasn’t executing because it wasn’t being parsed. Instead, it wasn’t executing because our JavaScript was bad. Our issue was that we were attempting to open a <script> within a <script>. What if we modify our value to the following:

<html>
	<head>
	</head>
	<body>
	<script>
		var x = "</script><script>alert(9)</script>";
	</script>
	</body>
</html>

In the above code, we are first closing out the original <script> tag and then we are starting a new one. This removes the embedded nuance and when the page is loaded, the alert box will appear.

This technique works in many places where a user can control the text returned within the <script> element. Of course, the important remediation step is to make sure that data is properly encoded when returned to the browser. By default, Content Security Policy may not be an immediate solution since this situation would indicate that inline scripts are allowed. However, if you are limiting the use of inline scripts to ones with a registered nonce would help prevent this technique. This reference shows setting the nonce (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src).

When testing our applications, it is important to focus on the lack of output encoding and less on the ability to fully exploit a situation. Our secure coding standards should identify the types of encoding that should be applied to outputs. If the encodings are not properly implemented then we are citing a violation of our standards.

by Leave a Comment

What is the difference between Brute Force and Credential Stuffing?

Many people get confused between brute force attacks and credentials stuffing. To help clear this up, here is a simple description of the two. These are both in regards to the login form only.

Brute Force
Brute force attacks on the login form consist of the attacker having a defined list (called a dictionary) of potential passwords. The attacker will then try each of these defined passwords with each username the attacker is trying to brute force. Put simply, this is a 1 (username) too many (password) attack.

A common mitigation to brute force attacks is the implementation of account lockout. In this case, after 3, or 5, or 10 failed attempts for a single username, the user account is locked to block any more attempts. This drastically reduces the number of passwords that may be tried in a short period of time.

Credential Stuffing
Credential Stuffing is another attack on the login form but it differs from a brute force attack in that the list used contains both a username and a password. This list is often obtained through a data breach at another organization. The purpose is to find accounts that are re-used across multiple sites. In this case, the attack is a 1 (username) to 1 (password) attack. For each username, only one password will be attempted.

Unlike with Brute Force, account lockout doesn’t have much affect on credential stuffing. Multi-factor authentication is a good mitigation as it will limit the use of valid credentials.

by Leave a Comment

What is a Penetration Test

You spend all day looking at requirements, creating functionality and doing some testing of the code you just created. You have been working for months on this application making sure it worked as expected. The testers have been diligently working to ensure that the requirements have been fulfilled and the application will work as expected and allow the end users the capability to solve a specific set of tasks. Then it happens… You find out that a penetration test is coming. Unfortunately for many, they really don’t understand what that means. Often times it is met with anger or resentment. How many people are actually excited to see the “pen testers” coming?

A penetration test, or pen test, is nothing that should be feared. While it is considered to be an adversarial act, the end goal is to assess the security of the environment or application to identify security risks before the “bad guys” do and help provide recommendations to reduce that risk.

That doesn’t sound that bad right, or does it? I may have left out the fact that a pen test may include exploiting your applications, retrieving your sensitive data, or even social engineering staff members to get what they want. But seriously, that is not as bad as it sounds and a pen test done right can be a very positive experience.

A big issue with a pen test is that in different companies and communities it has a different meaning. Sure the simple definition above should always fit that, but the scope that is defined and the results that are received can be very different. Here are some examples of some different types of pen tests (network and application specific).

Basic Pen Test (Scanner Only)
In my opinion this is not a pen test, but rather a vulnerability scan. In this situation, the “testers” will run a tool like Nessus or Qualys and then provide the results of that scan. The test is usually started by providing a set of IP addresses or URLs and then the scanner is configured and let loose. A few hours later, or maybe days, you get a report from the tool that is then passed on to the client. This type of assessment can make it difficult to identify the true risk of the vulnerabilities identified because they were not fully exploited. Maybe the scanner identified that there was SQL injection, but it didn’t follow through with the vulnerability to see how much access that provided.

Limited Scope Pen Test (Fairly Typical)
This type of test has scope limitations, meaning that it might just include a subset of IP addresses, specific functionality of an application, or how far you can take an exploit if one is found. This is fairly typical as it is rare to find a pen test that is fully open with everything on the table. The scope is defined in the rules of engagement as to what can and cannot be performed.

Full Pen Test (Not as Common)
Everything is game in this type of test. Be prepared to receive phishing emails or phone calls trying to get you to fall for a malicious attack. Your social profiles may also be a concern for you as when everything is game, a tester will use any avenue they can to try and gain access. All IP’s or the entire application is in scope. It can be very difficult to stop the testers from gaining access to systems when everything is in play.

Both the Limited and Full scope pen tests usually consist of both automated tools and lots of manual testing to identify the security risks.

In addition to the types of tests, we need to think about the different goals the client may have for requesting a pen test. Here is a quick rundown of some of the goals we see during a test.

Compliance Check Box
This is commonly seen by organizations that fall under some form of compliance, like PCI. “We are required to do this, so lets just get it done.” Often times the client is not really looking for security risks, but rather just trying to check the box. This doesn’t mean you should short change the testing efforts. The purpose of having a test performed is to help identify and reduce risk to the company.

Assess the Security of the Endpoint
This is seen in most tests where the client wants a vulnerability assessment of their endpoint, whether it is an IP or an application, so they can work to mitigate the risks identified. This type of test can be broken down into multiple levels, depending on how far the client wants to go. Some pen tests with this goal may not allow exploitation, making the goal just to identify vulnerabilities. Others, however, have higher goals of gaining access to internal networks, exploiting vulnerabilities, or gaining domain admin rights. This all depends on the goal of the organizer of the test.

High Stakes Goals
Some tests have very limited, yet high stakes goals. For example, many tests just want to see if the tester can gain domain administrator rights to the domain. In these types of tests, many of the other “vulnerability assessment” type findings may be overlooked. While they may be identified to help reach the ultimate goal, the goal is not to identify all, or as many as possible, of the risks to the endpoint.

In most tests, it is the assessing the security of the endpoint that we see the most. The goal is to identify the different risks, and while gaining internal access or domain administrator rights is great, the client is looking for more actionable results to it.

When testing occurs, often times the development teams have very little involvement. They may know it is going on, or have to provide some support if the applications are not configured properly, but that is usually the extent of it. It is important that we understand the goal and type of testing that is being performed. Also understand the purpose of the test should be to provide insight we didn’t have previously that could help us decrease the risk to our company.

Penetration tests, while “adversarial”, should be a collaborative effort with a positive feel. Don’t look at it as an “us” vs. “them”. The team was brought in for a specific task. The task should produce actionable results that are relevant to the environment. If they don’t, then it may be time to switch testing companies. Keep an open line of communication and a positive attitude.