DevelopSec

secure development

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

Checking npm packages using npm-audit

Our applications rely more and more on external packages to enable quick deployment and ease of development. While these packages help reduce the code we have to write ourselves, it still may present risk to our application.

If you are building Nodejs applications, you are probably using npm to manage your packages. For those that don’t know, npm is the node package manager. It is a direct source to quickly include functionality within your application. For example, say you want to hash your user passwords using bcrypt. To do that, you would grab a bcrypt package from npm. The following is just one of the bcrypt packages available:

https://www.npmjs.com/package/bcrypt

Each package we may use may also rely on other packages. This creates a fairly complex dependency graph of code used within your application you have no part in writing.

Tracking vulnerable components

It can be fairly difficult to identify issues related to these packages, never mind their sub packages. We all can’t run our own static analysis on each package we use, so identifying new vulnerabilities is not very easy. However, there are many tools that work to help identify known vulnerabilities in these packages.

When a vulnerability is publicly disclosed it receives an identifier (CVE). The vulnerability is tracked at https://cve.mitre.org/ and you can search these to identify what packages have known vulnerabilities. Manually searching all of your components doesn’t seem like the best approach.

Fortunately, npm actually has a module for doing just this. It is npm-audit. The package was included starting with npm 6.0. If you are using an earlier version of npm, you will not find it.

To use this module, you just need to be in your application directory (the same place you would do npm start) and just run:

npm audit.

On the surface, it is that simple. You can see the output of me running this on a small project I did below:

Npm audit

As you can see, it produces a report of any packages that may have known vulnerabilities. It also includes a few details about what that issue is.

To make this even better, some of the vulnerabilities found may actually be fixed automatically. If that is available, you can just run:

npm audit fix.

The full details of the different parameters can be found on the npm-audit page at https://docs.npmjs.com/cli/audit.

If you are doing node development or looking to automate identifying these types of issues, npm-audit may be worth a look. The more we can automate the better. Having something simple like this to quickly identify issues is invaluable. Remember, just because a component may be flagged as having a vulnerability, it doesn’t mean you are using that code or that your app is guaranteed vulnerable. Take the effort to determine the risk level for your application and organization. Of course, we should strive to be on the latest versions to avoid vulnerabilities, but we know reality diverts from what we wish for.

Have you been using npm-audit? Let me know. I am interested in your stories of success or failure to learn how others implement these things.

by Leave a Comment

Overview of Web Security Policies

A vulnerability was just identified in your website. How would you know?

The process of vulnerability disclosure to an organization is often very difficult to identify. Whether you are offering any type of bounty for security bugs or not, it is important that there is a clear path for someone to notify you of a potential concern.

Unfortunately, the process is different on every application and it can be very difficult to find it. For someone that is just trying to help out, it can be very frustrating as well. Some websites may have a separate security page with contact information. Other sites may just have a security email address on the contact us page. Many sites don’t have any clear indication of how to report such a finding. Maybe we could just use the security@ email address for the organization, but do they have it configured?

In an effort to help standardize how to find this information, there is a draft definition for a method for web security policies. You can read the draft at https://tools.ietf.org/html/draft-foudil-securitytxt-03. The goal of this is to specify a text file in a known path to provide contact information for users to submit potential security concerns.

How it works

The first step is to create a security.txt file to describe your web security policy. This file should be found in the .well-known directory (according to the specifications). This would make your text file found at /.well-known/security.txt. In some circumstances, it may also be found at just /security.txt.

The purpose of pinning down the name of the file and where it should be located is to limit the searching process. If someone finds an issue, they know where to go to find the right contact information or process.

The next step is to put the relevant information into the security.txt file. The draft documentation covers this in depth, but I want to give a quick example of what this may look like:

Security.txt

— Start of File —

# This is a sample security.txt file
contact: mailto:james@developsec.com
contact: tel:+1-904-638-5431

# Encryption - This links to my public PGP Key
Encryption: https://www.developsec.com/jamesjardine-public.txt

# Policy - Links to a policy page outlining what you are looking for
Policy: https://www.developsec.com/security-policy

# Acknowledgments - If you have a page that acknowledges users that have submitted a valid bug
Acknowledgments: https://www.developsec.com/acknowledgments

# Hiring - if you offer security related jobs, put the link to that page here
Hiring: https://www.developsec.com/jobs

# Signature - To help secure your file, create a signature file and reference it here.
Signature: https://www.developsec.com/.well-known/security.txt.sig

—- End of File —

I included some comments in that sample above to show what each item is for. A key point is that very little policy information is actually included in the file, rather it is linked as a reference. For example, the PGP key is not actually embedded in the file, but instead the link to the key is referenced.

The goal of the file is to be in a well defined location and provide references to your different security policies and procedures.

WHAT DO YOU THINK?

So I am curious, what do you think about this technique? While it is still in draft status, it is an interesting concept. It allows providing a known path for organizations to follow to provide this type of information.

I don’t believe it is a requirement to create bug bounty programs, or even promote the security testing of your site without permission. However, it does at least provide a means to share your requests and provide information to someone that does find a flaw and wants to share that information with you.

Will we see this move forward, or do you think it will not catch on? If it is a good idea, what is the best way to raise the awareness of it?

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

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.