DevelopSec

security

by Leave a Comment

What is the difference between source code review and static analysis?

Static analysis is the process of using automation to analyze the application’s code base for known security patterns. It uses different methods, such as following data from it source (input) to its sink (output) to identify potential weaknesses. It also uses simple search methods in an attempt to identify hard-coded values, like passwords in the code. Automated tools struggle at finding business logic or authentication/authorization flaws.

Code Review is a much larger project where both automated and manual techniques are used to review a code base for potential security risks. A code review may incorporate a static analysis component to quickly scan for some types of vulnerabilities. The manual part of the secure code review involves a person looking at the code to identify flaws that automated scanners cannot. For example, they may look at the authentication logic looking for potential logic flaws. They may also look to identify other authorization or business logic flaws that the automation is challenged to find.

by Leave a Comment

XSS in Script Tag

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

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

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

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

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

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

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

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

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

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

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

by Leave a Comment

Apple Mail: Highlighting External Email Addresses

A simple error to make when sending an email with sensitive data is to send it to the wrong email address. Imagine you are sending some information to Dave down in accounting. When you fill out the email you start typing Dave and the auto-complete pops up and you select the first one (out of habit). You think you have selected the right Dave, but what if you didn’t? How would you know that you were about to send potentially sensitive information outside of the organization?

Apple Mail and iOS mail has a built in feature to highlight any email address outside of a specified domain. The steps to enable this are a little different based on the desktop vs. an iPad/iPhone. Let’s look at each one.

Desktop

By default, email addresses all appear the same when composing a new message. The image below shows me composing an email with two addresses:

  • To: james@jardinesoftware.com
  • CC: james@developsec.com

Mail 1

To change this, in the Mail program, go to Preferences…Composing. Under the Addressing: section there is a checkbox for “Mark addresses not ending with“. Check the box and enter your organization’s domain name in the text box. In the image below, I have entered my domain of @jardinesoftware.com.

Mail 2

Now, go back and compose a new message entering in an email address that is in the org and one that is out of it. The email address that is outside of your domain should be highlighted in red. The below image shows my configuration with the same 2 email addresses. Notice that the james@developsec.com address is now listed in red indicating it is external to my organization.

Mail 3

iPhone/iPad

The mail application with the iPhone/iPad also has this capability. To enable this, go into Settings->Mail. Scroll down to the Composing section and click the “Mark Addresses” button (shown below).

Mail 4

On the next screen, enter the email address you don’t want to highlight. In my case, I entered my domain of @jardinesoftware.com. (shown below)

Mail 5

Once the change is stored, go to mail and compose a new message. In my example, I used the same emails as above. Notice that the james@developsec.com email address is now highlighted in red:

Mail 6

Although this is not a fool proof way to stop this type of mistake, it does add in a visual clue that just might catch your attention. Simple changes like this can help reduce your risk of accidentally leaking sensitive information out of your organization.

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

Installing BeEF on ubuntu 18.04

While working on a VM for a class, I had the opportunity to install BeEF for the students. This was the first VM I have built using Ubuntu 18.04, so I expected there to be a few hiccups along the way. The good news is that the process was pretty straight forward and simple. Here are the steps to getting this up and running on Ubuntu 18.04.

I started off by creating a new virtual machine using Ubuntu 18.04. I won’t go through the steps of creating a new virtual machine image, but the takeaway here is that I am starting with a fresh Ubuntu system.

The BeEF team has put together some simple instructions for installing the application (https://github.com/beefproject/beef/wiki/Installation). This walk through follows these instructions pretty close, with one exception to clear up an error we will see along the way (or at least an error I saw).

The first thing I am going to do is install Ruby on my Ubuntu 18.04 image. To do this we want to run the following command:

sudo apt install ruby ruby-dev

The next step is to get the BeEF source files. We will get these from git. If you haven’t installed git, make sure to run the following command first:

sudo apt install git

Once git is available, we can clone the git project with the following command:

git clone https://github.com/beefproject/beef

This will download the source files for BeEF. Next, move into the beef directory:

cd beef

This is where the I started to run into an issue. The original beef instructions say to just run:

./install

However, when I did this, I received a permission error. To resolve that I ran:

sudo ./install

There is probably a way to fix this permission error without running as sudo.. but I didn’t investigate that further.

Once the installation was successfully completed, I ran:

./beef

I was quickly greeted with the following error:

demo@ubuntu:~/beef$ ./beef
Traceback (most recent call last):
4: from ./beef:44:in `<main>’
3: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require’
2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require’
1: from /home/demo/beef/core/loader.rb:17:in `‘
/home/demo/beef/core/loader.rb:17:in `require’: cannot load such file — xmlrpc/client (LoadError)

After digging around, I found that ubuntu 18.04 by default installs Ruby 2.5, which apparently doesn’t have the xmlrpc/client embedded. To fix this, we just need to tell BeEF that it needs this gem. To fix this, I modified the Gemfile file following these steps:

rm Gemfile.lock – Do this first to remove the lock file. Click Y to remove it.

sudo nano Gemfile

In the file, add the following line:

gem ‘xmlrpc’

Save the file and re-run the installation:

sudo ./install

At this point, the installation should be successful. Try running the following command:

./beef

You should see something like the following:

demo@ubuntu:~/beef$ ./beef
[ 6:41:32][*] Browser Exploitation Framework (BeEF) 0.4.7.0-alpha
[ 6:41:32]    |   Twit: @beefproject
[ 6:41:32]    |   Site: https://beefproject.com
[ 6:41:32]    |   Blog: http://blog.beefproject.com
[ 6:41:32]    |_  Wiki: https://github.com/beefproject/beef/wiki
[ 6:41:32][*] Project Creator: Wade Alcorn (@WadeAlcorn)
[ 6:41:33][*] BeEF is loading. Wait a few seconds...
[ 6:41:38][*] 8 extensions enabled.
[ 6:41:38][*] 301 modules enabled.
[ 6:41:38][*] 2 network interfaces were detected.
[ 6:41:38][*] running on network interface: 127.0.0.1
[ 6:41:38]    |   Hook URL: http://127.0.0.1:3000/hook.js
[ 6:41:38]    |_  UI URL:   http://127.0.0.1:3000/ui/panel
[ 6:41:38][*] running on network interface: 192.168.116.139
[ 6:41:38]    |   Hook URL: http://192.168.116.139:3000/hook.js
[ 6:41:38]    |_  UI URL:   http://192.168.116.139:3000/ui/panel
[ 6:41:38][!] Warning: Default username and weak password in use!
[ 6:41:38]    |_  New password for this instance: ec04906c30d928fb857
[ 6:41:38][*] RESTful API key: 6bd0b11e772df40
[ 6:41:38][*] HTTP Proxy: http://127.0.0.1:6789
[ 6:41:38][*] BeEF server started (press control+c to stop)

Notice that there is a “New password” configured here. This is because by default beef sets the username/password to beef/beef. As this is a default, hard-coded password, it is insecure. To fix this, beef detects the default and creates a new temp password to protect the instance. It is recommended to update the username and password to your instance.

Updating the Password

To change the password stop beef by typing ctrl+c. Now, we will edit the config.yaml file:

sudo nano config.yaml

You should see something like this:


beef:
    version: '0.4.7.0-alpha'
    # More verbose messages (server-side)
    debug: false
    # More verbose messages (client-side)
    client_debug: false
    # Used for generating secure tokens
    crypto_default_value_length: 80

    # Credentials to authenticate in BeEF.
    # Used by both the RESTful API and the Admin interface
    credentials:
        user:   "beef"
        passwd: "beef"

    # Interface / IP restrictions

Modify the user and passwd fields to your own values and then save the file using ctrl+x.

When you restart BeEF and go to the ui panel you should now be able to login with your new credentials.

Notes
There should be a way to install the application without using sudo ./install. This should be checked so you don’t install using root permissions. This is a non-production image for me to use for student training.

Make sure you change the default username and password to help lock down your instance.

This tutorial is for educational purposes only. Hacking without permission is illegal and should not be done.

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.