DevelopSec

You are here: Home / blog

blog

by Leave a Comment

You’re not always right and that is ok

How do you feel when you realize that a decision you made or an action you took wasn’t as right as you thought?

For me, being right is something I try too hard for, almost. I have spent most of my life living over cautiously to make sure that what I was doing was right. I am typically quiet on topics unless I believe my response is right. I do this because I don’t want to fail. I don’t want to be wrong.

When it comes to security, I think this is a common feeling. Those in the security industry want to be right. We want to feel like we are doing something positive and to be honest, there is a fear that if you are wrong you will not be taken seriously.

The thing is. we won’t ever be 100% right all the time. It doesn’t matter how long you have been doing this, there is always something new to learn. In my case, it wasn’t really something new, it was just a situation where I had too narrow of a focus. Being wrong was actually a wake-up call to realize that things are not in a vacuum.

So what happened?

During a test last year I identified what I considered to be insufficient server-side validation. We have all seen the forms, for example changing your password, where it requires you to enter your password twice. That second text box is a confirmation box attempting to verify that you didn’t mistype your password the first time. The idea that if you typed it twice, you wouldn’t have mis-typed it.

In this case, the server was not validating the confirmation password. Instead, it just used the new password value and stored it. Through testing, it was clear that it didn’t matter what I put in that confirm password field, the new password was always accepted.

When we think about validation, we always talk about server and client side. We can’t trust the client. So from a non-contextual stand point, this is a clear issue where the new password and confirm password fields are not validated on the server to match.

When I met with the client to go over the report this finding came up. The developer’s stance was that the confirmation is there on the client to make sure they use the password they think they typed, but not necessary on the server side. To be fair, this caught me off guard. The more I thought about it, and I still think about it today, the more I agreed that he was spot on.

In this scenario, the weakness is that the user may mistype their new password the first time and the confirmation field would alert them to the mistake. This makes sense as a client-side validation. But how does it make sense from a server-side validation? What would the attack scenario look like? How would an attacker abuse this? From a raw request standpoint, it is nothing to set to fields to be the same. So setting them different doesn’t gain any advantage.

I realized that I hadn’t given this finding enough thought, rather I just jotted it down. It was a low risk finding. It could have also been an indicator of other locations that might not be performing server-side validation. But in its application, this was not a risk that would need addressing as the client-side validation was sufficient. In fact, there are many applications that no longer require a confirmation field with creating new passwords.

Security is changing every day. Things that were once top priority are now low priority. Things that were not an issue yesterday may be one today. When working with your clients make sure to think through these types of scenarios. It is easy to quickly find something and write it down. The ability to accept that something may not be what it seems can go a long way in building relationships with those you are supporting. It allows them to feel more comfortable asking these types of questions knowing that you are actually listening.

Don’t be afraid to ask questions or share your opinions when it comes to application security. There are so many things to know and learn, you are bound to say something wrong. If that is the case, take the opportunity to learn what is right and not dwell on being wrong.

by Leave a Comment

Choosing Application Security Tools

There are lots of security tools available, so how do you know which one to pick?

If your security team is not including the application teams in the decision, you run a big risk of failure. The security team does get the ability to form relationships with vendors. We see them at conferences. We know people that work there. Because our focus is on security, we know the tools that exist in our space and we have an idea of which ones may be better than others. Of course, this is often due to what we hear from others, rather than our own experience with those tools.

Picking a tool in a vacuum is less than ideal. Sure, the tool may have five stars and has great detection rates. However, if the tool doesn’t fit into the development process and causes more overhead and friction, it will end up failing. A tool with 100% accuracy is still useless if it is not actually being used.

I have seen over and over where a security group acquires a tool, especially static analysis, and a few months later they realize it is just sitting on the shelf. Like all of us, we are excited when we get a new toy. We use it, learn it. Then, the newness wears off. Without the proper processes in place, this can happen with security tools as well. We don’t want this to happen to you.

The first step in determining which tools make sense is to understand the development process now and where it is going. Lets talk about static analysis for a moment. If your development process doesn’t make use of continuous integration and doesn’t plan to then that is not a high priority feature of the tool you receive. Have you considered what IDE the developers use?

I once had a situation where static analysis was about to be rolled out. The security team worked to pick a vendor and get the ball rolling. It was later in the process that the development team was brought on board with the conversation. They asked questions that were less of a priority to the security team, but more of a priority to them. For example, The tool provided a plugin for their IDE. However, when digging deeper, the plugin ran a few versions behind. So what had appeared to be a good setup, now looked a little less efficient since the plugin may not work. This isn’t a deal breaker, but depending on how you were planning on this solution working, it adds friction to the process. The more friction, the more pain.

The next step is understanding who will ultimately be using this tool? For those that listen to the podcast on a regular basis and follow my blogs, you know I am a huge fan of the application teams having direct access to these tools. In my opinion, static analysis is a developers tool. It is there to evaluate the source code and identify policy violations that only the developer can resolve. Giving them access and control over that function and embedding it into their process reduces that friction. Don’t confuse this with the idea that security is not getting the results. Security still needs to have insight into what is going on with security flaws within the application. But to be efficient, the results of these tools need to fit into the flow of how development works. Not be one-off reports under different processes.

This is no different, in my opinion, than dynamic analysis or interactive analysis. These are tools that should be used by the QA group. The group that is responsible for testing and most likely already has automated testing capabilities. They are trained in identifying bugs, reporting, and tracking them. Building these types of tools into their process just makes sense. How many listeners have their own stories of the security team exporting a thousand page report out of that dynamic scanner and sending it to the application team as a pdf? I have been there. Even I won’t read through that report.

The moral of the story here is that if we don’t understand how development works, what type of tools they already use, and what they can handle, we will probably pick a solution that will be ineffective, or at the very least, cause us a lot more work. The goal is not to just shove tools onto the development teams and say do this. As application security representatives, our goal is to help build better applications. That doesn’t mean that our job is to run all the tools and hound the application teams to fix items. By understanding the environments and processes we can pick tools that will fit much better, allowing us to focus our time on building out other solutions or processes for the organization. We are still relied upon to provide the expert advice and guidance to the issues that are identified.

If you are considering implementing these types of tools, take a moment to sit down with all involved parties to get everyone on board. A well laid out plan will go much further than a shotgun approach.

by Leave a Comment

Burp Extension – Juice Shop Routes

When it comes to testing for security within our web applications, we often look to creating simple tools to help speed things up. They also help provide a consistent way to help identify known patterns. For those that haven’t been following, I have been doing a few posts about getting the OWASP Juice Shop application up and running. In this post, I want to introduce a simple burp extension I created to help with a few of the challenges presented in the OWASP Juice Shop.

The Challenge

The OWASP Juice Shop has multiple challenges built into it to help guide the user along in finding web applications. The app is written as a single page app (SPA) and is a little different than your traditional applications. Rather than make a full page request for everything you click, instead the application just makes API calls. In short, the entire UI is returned on the first load of the application.

There are multiple challenges within the Juice Shop that require the user to access specific URLs that are not available via a menu or link. For example (and I don’t want to directly give away answers to the challenge here), imaging visiting the contact screen. If you click the menu item for contact us, it will update the URL in the address bar to be like /#/contact. So I don’t have to actually click a link to access the contact us page, I could just update that URL directly in the address bar.

Finding the Routes

So how do you find the URLs that are available to access? There are multiple ways of doing this. First, of course, you could try to just fuzz them. This is good if the URLs are not available anywhere for us to find. Fortunately, this Angular application embeds the different routes within the client-side code. It uses a RouteProvider object to do this.

With a little digging, you can find this information in the /dist/juice-shop.min.js file. This is a pretty large file and looking through it can be a little tough. Searching for RouteProvider will bring you to the route definitions.

A Burp Extension

As a professional web app tester, I spend a lot of time using Burp Suite as my web proxy. It allows me to easily view and intercept all the traffic my browser sends back and forth to the server. Another cool feature is it allows building your own extensions to solve just this type of problem. Of course, you probably wouldn’t just create an extension for this one piece or a specific app. Instead, the hope would be that it would become helpful for other applications that use angular’s route provider object. This way, when I go to test other sites, I may get this information right there in my scanner results.

I built a quick little burp extension that looks for the routeProvider object and then, if found, pulls out each route defined. The code can be found at https://github.com/jamesjardine/juiceshoproutes. The code that performs all the tasks are in the BurpExtender.java file.

Once the extension is built into a JAR file it can be added into Burp. Note that this only works for Burp Pro because it uses the passive scanner. To install it, just navigate to the “Extender” tab and click the Add button. Then select the Jar file you created:

Be 0

Here is a quick run down of what it does:

  • Looks to see if the response from the server contains the phrase $routeProvider. If it finds this phrase it then gets the start offset and the end of the object by identifying the next ] character.
  • It then loops through the specific body text looking for a match to e.when. This basically defines when the URL matches X, load a specific template.
  • Each route that is identified is then displayed in an unordered list.
  • When you visit the Target Tab and select your site, click on the Issues tab to look for Angular Routes.

This is just a quick example of how building custom burp extensions can help increase your efficiency or help provide some additional coverage for known patterns within applications.

————–POTENTIAL SPOILER INFO BELOW ——————–

IF YOU ARE WANTING TO TRY THIS OUT WITHOUT SEEING THE RESPONSE FIRST STOP READING HERE!!!

There is no interaction needed to trigger this scan except for just visiting the initial page of the Juice Shop site. The Issues tase will look like:

Be screen1

If you look at the response, you will see the following image:

Be 2

In the above image you can see the highlighted area showing where the RouteProvder routes are defined. In the following image, you can see the advisory screen which indicates the formatted list of routes that are available:

Be 3

by Leave a Comment

Installing OWASP JuiceShop with Heroku

I am often asked the question by clients and students where people can go to learn hacking techniques for application security. For years, we have had many purposely vulnerable applications available to us. These applications provide a safe environment for us to learn more about hacking applications and the vulnerabilities that are exposed without the legal ramifications.

In this post I want to show you how simple it is to install the OWASP Juice Shop application using Heroku. Juice Shop is a purposely vulnerable application written using NodeJS and Angular. It goes beyond just being an application with some vulnerabilities. It is set up to be a capture the flag (CTF) style application with its own scoreboard.

To learn more about the Juice Shop project, head over to https://www.owasp.org/index.php/OWASP_Juice_Shop_Project. This is the main landing page and looks like the following:

Juice Shop

The first step in installing on Heroku is to make sure you are logged into your Heroku account. If you haven’t created one, do that first. Once you are logged in you should be in your dashboard that looks something like this:

HerokuInstall 1

Now that we are logged into Heroku, let’s head over to the Juice-shop GitHub page at https://github.com/bkimminich/juice-shop.

HerokuInstall 2

As you can see there is a button to “Deploy to Heroku”. Clicking this button will take you back to Heroku and ask for the app name as shown below:

HerokuInstall 3

Once you select a unique app name and the region clicking deploy starts the process. It doesn’t take very long (maybe 3-4 minutes) for the deploy to complete. While it is deploying you will see the build output as shown below:

HerokuInstall 4

Once the deployment is complete, you can click the button to View your new app. This will basically open a new tab at the location of your named instance which is the [name you picked].herokuapp.com as shown below:

HerokuInstall 5

The Juice Shop has a lot of vulnerabilities in it. It is a great way to learn more about how to exploit some of these vulnerabilities and test your skills. If you have little knowledge of application security vulnerabilities or the OWASP Top 10 check out our training courses we have available:

Please remember that hacking is illegal. If you want to learn more about application security and test your skills, do it responsibly and use great applications like the Juice Shop as your targets.

by Leave a Comment

Installing OWASP JuiceShop with Docker

I am often asked the question by clients and students where people can go to learn hacking techniques for application security. For years, we have had many purposely vulnerable applications available to us. These applications provide a safe environment for us to learn more about hacking applications and the vulnerabilities that are exposed without the legal ramifications.

In this post I want to show you how simple it is to install the OWASP Juice Shop application using a Docker container. Juice Shop is a purposely vulnerable application written using NodeJS and Angular. It goes beyond just being an application with some vulnerabilities. It is set up to be a capture the flag (CTF) style application with its own scoreboard.

To learn more about the Juice Shop project, head over to https://www.owasp.org/index.php/OWASP_Juice_Shop_Project. This is the main landing page and looks like the following:

Juice Shop

On the right hadn’t side there are links to Installation instructions. Clicking on the Docker Link takes us to the following page (https://hub.docker.com/r/bkimminich/juice-shop/) (Scroll down to the section on docker):

Juice Shop Docker

As you can see, there are only 4 steps to getting up and running with Docker. The first step is to install Docker. I won’t cover that here, but make sure you do have it installed before continuing on.

The next step is to pull the Juice-Shop docker container. This container is all set up and configured to run the Juice-Shop. No configurations necessary. To do this enter the command: docker pull bkimminich/juice-shop

Docker Install Step 2

The next step is to run the container. It is performed by simply running the following command: docker run –rm -p 3000:3000 bkimminich/juice-shop

Docker Install Step 3

As you can see, the juice shop is up and running, listening on port 3000. Port 3000 was specified when we called run passing in the -p option. ** If you get an error about the container not being able to start up, try restarting docker. I ran into this a few different times and a docker restart resolved the issue.

If everything is running as expected, we should be able to browse to http://localhost:3000 and access the Juice Shop as shown below:

JuiceShop Running

The Juice Shop has a lot of vulnerabilities in it. It is a great way to learn more about how to exploit some of these vulnerabilities and test your skills. If you have little knowledge of application security vulnerabilities or the OWASP Top 10 check out our training courses we have available:

Please remember that hacking is illegal. If you want to learn more about application security and test your skills, do it responsibly and use great applications like the Juice Shop as your targets.

by

MyFitnessPal Breach – Take-Aways

It was recently announced that MyFitnessPal suffered a breach of around 150 million records (https://www.cnet.com/news/millions-of-myfitnesspal-accounts-hacked-under-armour-says/). The breach affected usernames, email addresses and hashed passwords. There are no reports that any other personal information, such as SSN or credit card info has been impacted. It is always important for us to understand the actual types of data exposed as it changes how we look at the risk created to the users. It is important to point out that while the site may allow purchases using credit cards, the way they are processing them doesn’t actually store them.

I don’t know what process is followed in this particular instance, but many applications now use 3rd party payment processors so there is no need for the site to store credit card numbers. Instead, the payment process is offloaded to the 3rd party, which in turn helps provide better protection for the information.

If we look at what type of information was released by the organization, we can make some assumptions about things we can do to help strengthen our own applications from this type of breach. The purpose is not to berate the group that got breached, but instead to learn from their experience. We already took a quick look at processing credit cards and how taking proper steps to not store them locally helps add a layer of protection. The next most important part of the information actually breached were the passwords. Well, hashed passwords. It was interesting that the statement in the article and the email sent by MyFitnessPal to its users stated that a majority of the passwords were hashed using bCrypt. This indicates that not all of the passwords were hashed this way. Of course, we don’t know how they were hashed, or even if they were hashed, so let’s focus on the fact that the ones that were hashed were hashed with bCrypt. When we talk about storing passwords, the two most commonly recommended algorithms are bCrypt and PBKDF2.

These algorithms combine both a unique salt per hash and a work factor. Hashing algorithms are perfect for storing passwords, because we rarely ever need to reverse the password back to its original value. Instead, we can hash the user supplied password at login and then compare it to the stored original hash. Unfortunately, hashing algorithms are fast, which makes them easier to brute force because a program can generate a large number of hashes very quickly. This is why the work factor is important. It slows down the hash process to reduce the number of hashes that can be created in a specified timeframe.

When we see a breach where it is announced that the passwords were stored using bCrypt or PBKDF2, there is a better chance that the passwords won’t actually be compromised. There are some exceptions and things to think about with this.

  • First, don’t make the mistake of announcing you used a certain algorithm when you didn’t. There are plenty of people that will get their hands on that data and if it is determined that the information provided was inaccurate, the fallout could be much worse than having just been honest up front.
  • Second, just because the passwords are properly hashed, poorly chosen passwords are still not very protected.

Passwords are a simple, yet complex beast. Determining what a good password is can be difficult and we see all sorts of rules about them on every site. We are taught that longer passwords are better passwords. And this is usually true. But we also have to realize that using common passwords, even if long, is a bad practice. Users that choose passwords like ‘Winter 2018’ are much more susceptible to having their password cracked, even if it was hashed with these recommended algorithms. I don’t recommend blocking users from using any random password that has been breached in the past, not associated with their account. However, you could block passwords that are on the “top 1000” type lists of commonly used passwords. For those users using password managers, this shouldn’t be a problem since they can be creating long randomly generated passwords.

The other part of the breach process I want to touch on is around the response to a breach. When we think about our SDLC, we should have a part where we start thinking about response plans. This is where we think about what types of events may occur, and more importantly, who will need to be involved if those events occur. Having the right response can have a huge impact on how the organization is perceived following a breach.

The type of information provided to the customers or end users and how it is provided is critical. We have seen with other breaches where if it appears the breach was covered up, or the information is inaccurate, people will have a very negative view of the organization. Make sure your organization has taken steps to identify the right people to have involved when getting ready to send out alerts. For example, you may want to have legal, marketing, HR, or other resources available. Each has their own specialty that can help make a smooth announcement.

As developers, as we identify potential breach scenarios, we can start to consider processes to handle them. For example, if your credentials database gets breached, what steps might you take to help protect the users. FIrst and foremost, containing the breach and making sure it is over. Then, how would you force a password reset to make sure that any passwords breached are no longer useful.

Use this recent breach as an excuse to review some of your internal processes.

How are you storing passwords?

How would you handle a password breach?

Reviewing these situations every once in a while is a healthy way to ensure that your applications are up-to-date in these protections.