Tag Archives: penetration testing

JavaScript in an HREF or SRC Attribute

Leave a reply

The anchor (<a>) HTML tag is commonly used to provide a clickable link for a user to navigate to another page. Did you know it is also possible to set the HREF attribute to execute JavaScript. A common technique is to use the onclick event of the anchor tab to execute a JavaScript method when the user clicks the link. However, to stop the browser from actually redirecting the HREF can be set to javascript:void(0);. This cancels the HREF functionality and allows the JavaScript from the onclick to execute as expected.

In the above example, notice that the HREF is set with a value starting with “javascript:”. This identifier tells the browser to execute the code following that prefix. For those that are security savvy, you might be thinking about cross-site scripting when you hear about executing JavaScript within the browser. For those of you that are new to security, cross-site scripting refers to the ability for an attacker to execute unintended JavaScript in the context of your application (https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)).

I want to walk through a simple scenario of where this could be abused. In this scenario, the application will attempt to track the page the user came from to set up where the Cancel button will redirect to. Imagine you have a list page that allows you to view details of a specific item. When you click the item it takes you to that item page and passes a BackUrl in the query string. So the link may look like:

https://developsec.com/item.php?backUrl=/items.php

On the page, there is a hyperlink created that sets the HREF to the backUrl property, like below:

<a href=”<?php echo $_GET[“backUrl”];?>”>Back</a>

When the page executes as expected you should get an output like this:

<a href=”/items.php”>Back</a>

There is a big problem though. The application is not performing any type of output encoding to protect against cross-site scripting. If we instead pass in backUrl=”%20onclick=”alert(10); we will get the following output:

<a href=”” onclick=”alert(10);“>Back</a>

In the instance above, we have successfully inserted the onclick event by breaking out of the HREF attribute. The bold section identifies the malicious string we added. When this link is clicked it will prompt an alert box with the number 10.

To remedy this, we could (or typically) use output encoding to block the escape from the HREF attribute. For example, if we can escape the double quotes (” -> &quot; then we cannot get out of the HREF attribute. We can do this (in PHP as an example) using htmlentities() like this:

<a href=”<?php echo htmlentities($_GET[“backUrl”],ENT_QUOTES);?>”>Back</a>

When the value is rendered the quotes will be escapes like the following:

<a href=”&quot; onclick=&"alert(10);“>Back</a>

Notice in this example, the HREF actually has the entire input (in bold), rather than an onclick event actually being added. When the user clicks the link it will try to go to https://www.developsec.com/” onclick=”alert(10); rather than execute the JavaScript.

But Wait… JavaScript

It looks like we have solved the XSS problem, but there is a piece still missing. Remember at the beginning of the post how we mentioned the HREF supports the javascript: prefix? That will allow us to bypass the current encodings we have performed. This is because with using the javascript: prefix, we are not trying to break out of the HREF attribute. We don’t need to break out of the double quotes to create another attribute. This time we will set backUrl=javascript:alert(11); and we can see how it looks in the response:

<a href=”javascript:alert(11);“>Back</a>

When the user clicks on the link, the alert will trigger and display on the page. We have successfully bypassed the XSS protection initially put in place.

Mitigating the Issue

There are a few steps we can take to mitigate this issue. Each has its pros and many can be used in conjunction with each other. Pick the options that work best for your environment.

  • URL Encoding – Since the HREF is meant to be a URL, you could perform URL encoding. URL encoding will render the javascript benign in the above instances because the colon (:) will get encoded. You should be using URL encoding for URLs anyway, right?
  • Implement Content Security Policy (CSP) – CSP can help limit the ability for inline scripts to be executed. In this case, it is an inline script so something as simple as ‘Content-Security-Policy:default-src ‘self’ could be sufficient. Of course, implementing CSP requires research and great care to get it right for your application.
  • Validate the URL – It is a good idea to validate that the URL used is well formed and pointing to a relative path. If the system is unable to parse the URL then it should not be used and a default back URL can be substituted.
  • URL White Listing – Creating a white list of valid URLs for the back link can be effective at limiting what input is used by the end user. This can cut down on the values that are actually returned blocking any malicious scripts.
  • Remove javascript: – This really isn’t recommended as different encodings can make it difficult to effectively remove the string. The other techniques listed above are much more effective.

The above list is not exhaustive, but does give an idea of ways to help reduce the risk of JavaScript within the HREF attribute of a hyper link.

Iframe SRC

It is important to note that this situation also applies to the IFRAME SRC attribute. it is possible to set the SRC of an IFRAME using the javascript: notation. In doing so, the javascript executes when the page is loaded.

Wrap Up

When developing applications, make sure you take this use case into consideration if you are taking URLs from user supplied input and setting that in an anchor tag or IFrame SRC.

If you are responsible for testing applications, take note when you identify URLs in the parameters. Investigate where that data is used. If you see it is used in an anchor tag, look to see if it is possible to insert JavaScript in this manner.

For those performing static analysis or code review, look for areas where the HREF or SRC attributes are set with untrusted data and make sure proper encoding has been applied. This is less of a concern if the base path of the URL has been hard-coded and the untrusted input only makes up parameters of the URL. These should still be properly encoded.

Insulin Pump Vulnerability – Take-aways

Leave a reply

It was recently announced that there were a few vulnerabilities found with some insulin pumps that could allow a remote attacker to cause the pump to distribute more insulin than expected. There is a great write up of the situation here. When I say remote attack, keep in mind that in this scenario, it is someone that is within close proximity to the device. This is not an attack that can be performed via the Internet.

This situation creates an excellent learning opportunity for anyone that is creating devices, or that have devices already on the market. Let’s walk through a few key points from the article.

The Issue

The issue at hand was that the device didn’t perform strong authentication and that the communication between the remote and the device was not encrypted. Keep in mind that this device was rolled out back in 2008. Not to say that encryption wasn’t an option 8 years ago, for these types of devices it may not have been as main stream. We talk a lot about encryption today. Whether it is for IoT devices, mobile applications or web applications, the message is the same: Encrypt the communication channel. This doesn’t mean that encryption solves every problem, but it is a control that can be very effective in certain situations.

This instance is not the only one we have seen with unencrypted communications that allowed remote execution. It wasn’t long ago that there were computer mice and keyboards that also had the same type of problem. It also won’t be the last time we see this.

Take the opportunity to look at what you are creating and start asking the question regarding communication encryption and authentication. We are past the time where we can make the assumption the protocol can’t be reversed, or it needs special equipment. If you have devices in place currently, go back and see what you are doing. Is it secure? Could it be better? Are there changes we need to make. If you are creating new devices, make sure you are thinking about these issues. Communications is high on the list for all devices for security vulnerabilities. Make sure it is considered.

The Hype, or Lack of

I didn’t see a lot of extra hype over the disclosure of this issue. Often times, in security, we have a tendency to exaggerate things a bit. I didn’t see that here and I like it. At the beginning of this post I mentioned the attack is remote, but still requires close physical proximity. Is it an issue: Yes. is it a hight priority issue: Depends on functionality achieved. As a matter of fact, the initial post about the vulnerabilities states they don’t believe it is cause for panic and the risk of wide scale exploitation is relatively low. Given the circumstances, I would agree. They even go on to say they would still use this device for their children. I believe this is important because it highlights that there is risk in everything we do, and it is our responsibility to understand and choose to accept it.

The Response

Johnson and Johnson released an advisory to their customers alerting them of the issues. In addition, they provided potential options if these customers were concerned over the vulnerabilities. You might expect that the response would downplay the risk, but I didn’t get that feeling. They list the probability as extremely low. I don’t think there is dishonesty here. The statement is clear and understandable. The key component is the offering of some mitigations. While these may provide some inconvenience, it is positive to know there are options available to help further reduce the risk.

Attitude and Communication

It is tough to tell by reading some articles about a situation, but it feels like the attitudes were positive throughout the process. Maybe I am way off, but let’s hope that is true. As an organization it is important to be open to input from 3rd parties when it comes to the security of our devices. In many cases, the information is being provided to help, not be harmful. If you are the one receiving the report, take the time to actually read and understand it before jumping to conclusions.

As a security tester, it is important for the first contact to be a positive one. This can be difficult if you have had bad experiences in the past, but don’t judge everyone based on previous experiences. When the communication starts on a positive note, the chances are better it will continue that way. Starting off with a negative attitude can bring a disclosure to a screeching halt.

Conclusion

We are bound to miss things when it comes to security. In fact, you may have made a decision that years down the road will turn out to be incorrect. Maybe it wasn’t at the time, but technology changes quickly. We can’t just write off issues, we must understand them. Understand the risk and determine the proper course of action. Being prepared for the unknown can be difficult, but keeping a level head and honest will make these types of engagements easier to handle.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Login Forms and HTTP

Leave a reply

Does your application have a login form? Do you deliver it over HTTPS to protect the username and password while being transmitted to the server? If you answered yes to both of those questions, are you sure?

Many years ago, before there was a huge push for HTTPS all the time, it was common practice for many applications to load a login form using HTTP, but then submit the form over HTTPS. This was accomplished by setting the action attribute of the form to the full HTTPS version of the site.

<form action=”https://www.somesite.com/login” method=”post”>

There was a flaw in this setup. The flaw is not even with the submission of your credentials. Instead, the issue is how that login form is initially loaded. Remember we said that the initial request was HTTP? The belief was that because the loading of the form doesn’t transmit any sensitive data, it would be ok to use HTTP. You could even take a trip back to the performance wars during that time stating that HTTP was much faster to load. (We learned a lot of the years).

The problem is that if there is a malicious user (attacker) on your same network that is able to redirect your traffic through them they could manipulate the initial load of the page. Imagine if the attacker intercepted your request to the login page (initial load) and changed the action of the form to a different site?

<form action=”http://myevilsite.com/login” method=”post”>

Notice how the new form submission will go to a different site, not even using HTTPS. From the end user’s point of view they wouldn’t even know the form was going to send their credentials to a different site.

Over the years, we have seen the use of this methodology shrinking down. Many sites are now loading their login forms all over HTTPS. As a matter of fact, many sites are 100% HTTPS.

But Wait!!

There is another angle to this that is often overlooked, but works very similar. Does your site allow it to be loaded into frames? I have seen a lot of sites that have been including another application’s login form using either frame sets or frames. The issue, the container site is often a simple marketing or branding site and runs over HTTP.

Like the above example, the HTTP site is including a frame reference to an HTTPS site. Again, the login form submission is still correct. However, it is possible that the attacker from the previous scenario could intercept the containing page and change the reference for the login frame. In this case, the attacker would most likely create a page that is identical to the real login form and point the frame to that one. The user would have no idea that the authentication page was incorrect, because it would look like the original. When the user submits their credentials, they would then be submitted to the malicious user instead of the real site.

It is recommended to not allow your site to be hosted within a sub frame. There are plenty of articles that discuss frame busting techniques and you could look into the X-Frame-Options header as well. If your form doesn’t load in a frame then your risk of being included on a non-secure site is reduced. For all other scenarios, there isn’t a lot of reason to not be using HTTPS from end to end. By securing all of the transactions, it reduces the risk that an attacker can easily manipulate that traffic.

How Serious is Username Enumeration

Leave a reply

Looking through Twitter recently, I caught a very interesting stream that started with the following message:

There were quite a few replies, and a good discussion on the topic of the seriousness of username enumeration flaws. 140 characters is difficult to share a lot of thoughts, so I thought this would actually be a great post.

What is Username Enumeration?

Username Enumeration refers to the ability to determine not only if a username is valid within a specific application, but also to automate the process of identifying a multiple valid usernames. The most common example of username harvesting is on the application logon form. The culprit, the unsuccessful login error message. This happens because the application creators want to be helpful and let the user know what went wrong. When the message is not generic, for example “unsuccessful login”, it may indicate if the user exists or not. An example message would be “Username does not exist”. This is bad. A better response would be “Username or password are incorrect”. This is a much more generic answer and doesn’t give away whether or not the username is valid.

Where do we find Username Enumeration?

As I mentioned above, the login screen is one of the most common locations we find username harvesting. However, it is not the only place. Probably the two next biggest offenders are the Forgot Password screen and the User Registration screen. With all three of these screens, it is critical to realize that the display message is not the only way to detect username harvesting. In reality, it is any difference that comes back between an invalid and a valid user. This could be the error message, a status code that is different, timing attacks, or a myriad of other techniques. Don’t just think about the error message. That one is typically the easiest, but not the only method for identification. API calls may also be a source for username harvesting.

The Login Form

The login form is typically vulnerable through the error message. To help protect the login form, make sure that the application returns a generic error message for any error situation. A good example of this is “Your login attempt was unsuccessful. If you continue to have trouble, contact support.” This message is good for invalid username, invalid password, and even account lockout.

The Forgot Password Form

The forgot password screen is usually vulnerable due to poor forget password design. Most systems ask for the username/email address and if correct, do one of the following: 1) Ask for secret security questions, 2) Display a message that an email has been sent to the email address on record. Unfortunately, for an incorrect username, the system returns an error message that the username was not found. To correct this problem, it is possible to either ask for more than just the username (something that is private to the account), or just always display the “email has been sent” message. In this configuration, no matter what, the email is sent form is displayed.

The Registration Form

The registration screen is a bit more tricky because, in most situations, you need to be able to alert the user that their username is already in use. Unlike the other two scenarios, the error message can’t really be fixed. One option on a registration screen is to enable the use of a CAPTCHA to attempt preventing automation attacks. If implemented properly the attacker would be slowed down in their enumeration making things more difficult. It may not make it impossible, but the goal is to reduce the risk.

How is Username Enumeration Used?

There are a few ways that username enumeration becomes important to an attacker. First, it is a good technique to limit down the list of possible usernames to attempt password attacks on. One example on twitter gave the example of taking a list of 100 million usernames and reducing it to 100 thousand to perform actual password guessing on. In this scenario, the attackers are also attempting to take advantage of weak password complexity, or just bad password hygiene. Often times, they may take the top 3 or 4 common passwords and try those against all of the valid usernames to see if anyone is using them.

The second way that username enumeration is used is for social engineering attacks. Or, at least, more targeted social engineering attacks. If the attacker knows that the user has an account on a specific application, it can make phone calls and emails much more convincing and ultimately more successful. Limiting emails to 100,000 users rather than 100 million helps reduce the overhead and reduces the chances of getting detected.

Somewhat related to social engineering attacks, this information could also be used to target individuals based on moral values. Remember the Ashley Madison breach that happened a while back. Depending on what the username is in use, it may be possible to identify people that use a particular site and sort of out them, or blackmail them. Think of other sites people may not want to be public about visiting.

How Serious is it?

I bet you didn’t think we would ever get here. It is important to understand how the attackers may be using a vulnerability to start to determine how serious it really is. Unfortunately, there isn’t an easy answer that fits every application. As I mentioned above, with poor password hygiene, the risk would be raised if someone is using one of those top 4 passwords. It also depends on the type of system, the type of data collected, the functionality the application performs, etc. No systems are created or rated equally.

In the scenario above for the login screen guessing the top 4 passwords, let’s not forget that it is possible to try all 100 million usernames from our list. Sure, it is helpful to reduce it down to only valid usernames, but the attack is still possible without the username enumeration flaw. In the ideal setup, the application would have some form of detection system in place that might detect all of the unsuccessful login attempts, but that is the ideal. It is not common enough to see that type of detection implemented in many applications. Without that detection, and a little crafty rate limiting by an attacker, the difference between 100 million attempts and 100,000 attempts is really just time.

As we all know, social engineering attacks are the latest and greatest. Any help we provide attackers in that arena is a step backwards for us. This could lead to a bigger problem and that is why we need to understand the issues we are trying to solve.

Should we fix it?

If we had all the time and resources in the world, the answer would be an easy “yes”. Unfortunately, we don’t have that. This really comes down to your organization’s risk assessments and priorities. I always like to provide the recommendation to resolve the issue, as it makes for a better application overall. Depending on your situation, the fix may not be straight forward or easy. You may have other higher priority items that need to be worked on. Remember, for the password attack, it is really a combination of a weak password issue as well. It is not just username harvesting on its own.

Take the opportunity to review how you are auditing and logging these types of events within your application. In some cases we may see logging occurring, but then there is no auditing of those logs. Detection and response is critical in helping reduce the risk of these types of flaws.

Continuing Forward

Username enumeration is a risk to any application. It is up to the organization to understand their business to determine how big or small that risk is. This isn’t something that should just be ignored, but it also doesn’t mean it is something that is a critical finding. Don’t just write the finding off. Use that as an opportunity to discuss the functionality, understand how it works, and determine the best course of action for the organization and the users.

Username enumeration is typically fairly simple to test for and should be worked into the QA testing cycle. Take the time to discuss with the architects, developers, business analysts, and the testers how the organization can test for this and reduce the risk.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Understanding the “Why”

Leave a reply

If I told you to adjust your seat before adjusting your mirror in your car, would you just do it? Just because I said so, or do you understand why there is a specific order? Most of us retain concepts better when we can understand them logically.

Developing applications requires a lot of moving pieces. An important piece in that process is implementing security controls to help protect the application, the company, and the users. In many organizations, security is heavily guided by an outside group, i.e.. the security group or 3rd party testers.

Looking at an external test, or even a test by an internal security team, often the result is a report containing findings. These findings typically include a recommendation to guide the application team in a direction to help reduce or mitigate the finding. In my experience, the recommendations tend to be pretty generic. For example, a username harvesting flaw may come with a recommendation to return the same message for both valid and invalid user names. In most cases, this is a valid recommendation as it is the reason for the flaw.

But Why? Why does it matter?

Working with application teams, it quickly becomes clear the level of understanding regarding security topics. The part that is often missing is the Why. Sure, the team can implement a generic message (using the username harvesting flaw above) and it may solve the finding. But does it solve the real issue? What are the chances that when you come back and test another app for this same development team that the flaw may exist somewhere else? When we take the time to really explain why this finding is a concern, how it can be abused, and start discussing ways to mitigate it, the team gets better. Push aside the “sky is falling” and take the time to understand the application and context.

As security professionals we focus too much on fixing a vulnerability. Don’t get me wrong, the vulnerability should be fixed, but we are too focused. Taking a step back allows us to see a better approach. It is much more than just identifying flaws. It is about getting the application teams to understand why they are flaws (not just because security said so) so they become a consideration in future development. This includes the entire application team, not just developers. Lets look at another example.

An Example

Let’s say that you have a change password form that doesn’t require the current password. As a security professional, your wheels are probably spinning. Thinking about issues like CSRF. From a development side, the typical response “Why do I need to input my password when I just did that to login to change my password?” While the change will most likely get made, because security said it had too, there is still a lack of understanding from the application team. If CSRF was your first reason, what if they have CSRF protections already in place? Do you have another reason? What about if the account is hijacked somehow, or a person sits at the user’s desk and they forgot to lock their PC? By explaining the reasoning behind the requirement, it starts to make sense and is better received. It dominos into a chance that the next project that is developed will take this into consideration.

When the business analysts sits down to write the next change password user story, it will be a part of it. Not because security said so, but because they understand the use case better and how to protect it.

If you are receiving test results, take the time to make sure you understand the findings and the WHY. It will help providing a learning objective as well as reduce the risk of not correcting the problem. Understand how the issue and remediation effects your application and users.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

Originally posted at https://www.jardinesoftware.com

Introduction to Penetration Testing for Application Teams

Leave a reply

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at: https://youtu.be/I1PukF8Glh0

HTTP Strict Transport Security (HSTS): Overview

Leave a reply

A while back I asked the question “Is HTTP being left behind for HTTPS?”. If you are looking to make the move to an HTTPS only web space one of the settings you can configure is HTTP Strict Transport Security, or HSTS. The idea behind HSTS is that it will tell the browser to only communicate with the web site over a secure channel. Even if the user attempts to switch to HTTP, the browser will make the change before it even sends the request.

HSTS is implemented as a response header with a few options shown in the below example:

Strict-Transport-Security: max-age=31536000; includeSubDomains

In the example above, the max-age (required) is specified in seconds ( a year in this case) and indicates how long the browser should remember this setting. Setting a max-age of 0 will tell the browser to stop enforcing HSTS for the domain.

The includeSubDomains is optional and indicates if HSTS should be enforced an all of the sub domains as well.

You might wonder why this is needed when a user can just go to the HTTPS version of a site. If you watch most users, I am guilty of this myself, they just type the domain of the site they are going to. For example, I might just type developsec.com into the browser. With no indication of which protocol I want to use, the browser will start with HTTP and then the server may respond to switch it to HTTPS. With HSTS enabled, the goal is when a user types http://www.developsec.com or www.developsec.com into the URL, the browser will make the switch automatically.

There are some considerations for this to work as expected. The response header is not respected until the first time you visit the domain using HTTPS with a trusted certificate. Until this happens the browser doesn’t know not to use HTTP. There is a way around this by signing your domain up on the preload list. The preload list can be used by browsers to find out about your domain’s HSTS status before accessing the site. The linked site shows what needs to be done to be allowed on the preload list. Both with the preload list and support for HSTS in general, your browser has the final say. For a list of browsers that support HSTS you can go to the OWASP site.

Self Signed Certificates
One of the security features of HSTS is that tries to block man in the middle (MitM) type of attacks. An attack where your traffic is redirected through an attacker so they can view your data. To do this, HSTS requires the certificate to be a trusted certificate. If it is not a trusted certificate, for example a self-signed one, then you will see the following image indicating it cannot connect:

Hsts1

You may notice that this looks very similar to when you try to connect to a site with a certificate issue with one major difference. There is no way to allow the exception. For testers that use a proxy, such as Burp Suite, you can tell your browser to trust the certificate generated from the proxy tool and it should work just fine.

If you are working toward implementing this feature, make sure you perform appropriate testing to make sure it is working properly. If you use the “includeSubDomains” setting make sure your test environments are using SSL or you may have some trouble shooting to do during testing. If your site is HTTPS only, this is a great feature to add to make sure that your users are only making requests over HTTPS. Hopefully the links included will provide any other information you may need on HSTS.

Tips for Securing Test Servers/Devices on a Network

How many times have you wanted to see how something worked, or it looked really cool, so you stood up an instance on your network? You are trying out Jenkins, or you stood up a new Tomcat server for some internal testing. Do you practice good security procedures on these systems? Do you set strong passwords? Do you apply updates? These devices or applications are often overlooked by the person that stood them up, and probably unknown to the security team.

It may seem as though these systems are not critical, or even important, because they are just for testing or don’t touch sensitive information. It is common to hear that they are internal, so an attacker cannot get to them. The reality is that every system or application on a network can be an aide to an attacker. No matter how benign the system may seem, it adds to the attack surface area.

What Can You Do?

There are a few things to think about when any type of application server or device is added to the network.

  • Change Default Passwords
  • Apply Updates
  • Remove Default Files
  • Decommission Appropriately

Change Default Passwords

While this seems simple, it is amazing how often the default password is still in use on systems on a network. This goes beyond unused systems or rogue systems, but to many other production devices. It only takes a moment to change the password on the device. It may not seem like it, but a quick Google search for default passwords for just about any device/COTS application can yield quick results.

Fortunately, many recent systems have switched to not use default passwords, rather they force you to set a password during setup. This is a great step in the right direction. It is also a good idea to change the default administrator account name if possible. This can make it a little more time consuming for an attacker to attempt brute forcing the password if they don’t know the user id.

If you develop software or devices that get deployed to customers you should be thinking about how the setup process works. Rather than setting a default password, have the user create one during the setup process.

Apply Updates

One of the most critical controls for security is patching. Many organizations will have patching procedures for the systems and software they know about, but if you are standing up an unknown device it may not get patched. Software patches often times contain security fixes, some of which are critical. Make sure you are keeping the system updated to help keep everyone safe. It is also a good idea to let the team that handles patching and system maintenance know about the new application/device.

Remove Default Files

If the application is deployed with default files or examples, it may be a good idea to remove them. It is common to see these types of files, meant only for testing purposes, not be very secure. Removing the files will help tighten the security of the system, leading to a more secure network.

Decomission Appropriately

If you are done using the system, remove it. I can’t tell you how many times I have found a system that hadn’t been used in months or even years because it was just to try something out. No one even remembered it, security didn’t know about it, and it was very vulnerable. By removing it, you no longer have to worry about patching it or the default passwords. It reduces the attack surface area and limits an attackers ability to elevate their privileges.

Is the Risk Real?

You bet it is. Imagine you have left an old Tomcat server on the network with default credentials (tomcat/tomcat) or something similar. An attacker is able to get onto the internal network, lets just assume that a phishing attack was successful. I know.. like that would ever happen. They log into the management console of Tomcat and deploy a WAR file containing a shell script.

I have a video that shows deploying Laudanum in just this manner that can be found here.

Now that the attacker has a shell available, he can start running commands against the operating system. Depending on the permissions that the Tomcat user is running under it is possible that he is running as an admin. At this point, he creates a new user on the system and even elevate that user to be an administrative user. Maybe RDP is enabled and remote login is possible. At the very least it will be possible to read files from the system. This could lead to getting a meterpreter shell, stealing administrative hashes, even leading to gaining domain admin access if a domain admin has logged into that system.

That is just one example of how your day may go bad with an old system sitting on the network that no one is maintaining. The point is that every system on the network needs to be taken care of. As a developer who may be looking to try a new application out, take some time to think about these risks. You may also want to talk to your security team (if you have one) about the application to see if there are known vulnerabilities. Let them know that it is out there so they may help keep an eye out for any strange behavior.

This doesn’t mean you can’t stand different things up, but we need to be aware of the risks to it. You may find that there is a network segment that is heavily controlled that the application or device will be put on to help reduce the risk. You don’t know until you ask. Keep in mind that security is everyone’s job, not just the team that has the word in their title. They can’t help protect what they don’t know about.