Monthly Archives: February 2017

Kali with Damn Vulnerable Web App in Docker

If you have landed here I hope you are looking at starting your training with Damn Vulnerable Web App. I am excited for you as you have so much to learn. I hope it means that you are considering a career in Cyber Security, and that this post will save you a few hours of frustration, and get you to the fun bits quicker.

You are going to need access to tools and access to targets so you can explore legally and for free. This post is about getting you to setup two things which will simply provide you with first the tools and then the targets easily:

  1. Kali Linux – the goto distribution of choice for penetration testers at all parts of their careers. A Debian base with repositories that contain all of the most common “hacking” tools.
  2. Docker – I risk offending people with my simplistic definition here. I think of this as a lightweight virtual machine. Really it is a “container” which can include an entire ecosystem.We can use this to clone down vulnerable targets to play with quickly which will run inside our Kali. This will provide the targets.

In this post I will cover setting things up by providing links to the appropriate guides. By the end you will have access to Damn Vulnerable Web App (DVWA) which you can start targeting immediately!

Pre-Amble

The simplest way to interact with Kali Linux for most readers will be to use virtualisation.

  1. Install vmware player or virtual box. I prefer vmware Player and so the rest of this guide assumes you are using this. Sorry folks.
  2. Download Kali ISO and build a virtual machine.
  3. Boot and log into Kali with the credentials you created.

If all is going well you have a new OS with a fresh desktop environment.

Setup VMWare Tools

Before you go too far you are going to want to setup “VMWare Tools”. This will allow you to copy/paste between your host and guest machine as well as smooth out lots of bumps.

Fortunately there is an easy to follow and official guide here:

http://docs.kali.org/general-use/install-vmware-tools-kali-guest

By the end of this you should have a more useful virtual machine.

Setup Docker (the Lazy way)

To me docker is not that easy to setup. As Kali is Debian based you may assume that it is simply “apt-get install docker”. This is not the case and a major reason for me writing this post is to make sure you can get Docker into Kali as easily as possible.

The following script was made by some genius called “apolloclark” on Github:

Save this script to a file on your desktop called “getdocker.sh”. Then execute that in a terminal by first “chmod +x getdocker.sh” and then “./getdocker.sh”. This will install docker for you.

I am not going to explain how to actually use docker in the general cases. So you probably want to eventually get round to reading this:

https://docs.docker.com/engine/getstarted/

You can skip reading tutorials for Docker right now if you just want to focus on DVWA as soon as possible.

Getting DVWA and Running it

Various people have made docker containers which contain DVWA. At the time of writing the top hit on Google was made by another rockstar called “infoslack”. Open the following URL to see the details:

https://github.com/infoslack/docker-dvwa

The following commands are all you would need to execute:

docker pull infoslack/dvwa
docker run -d -p 80:80 infoslack/dvwa

At this point you can access DVWA on localhost port 80.

Check that you are ready

Open this URL in the browser within Kali:

http://localhost/ 

As you have not configured your server yet it will ask you to setup your database:

setup-dvwa1

Setup your DVWA now and get hacking

If you click on “Create / Reset Database” button then you will complete the setup. This will take you to a login page. Enter “admin” and “password” to login.

This will present you with the full interface which will include a long list of options down the left. By default your DVWA install will be set to “Impossible” level of difficulty. You should be unable to exploit any of the vulnerabilities because the code is not designed to be vulnerable at this level.

Click on “DVWA Security” and then alter the drop down from “Impossible” to low and click “Submit”.

At this point you can click on links on the left to load specific vulnerable exercises.

Play safe.

 

 

Impact Assessment 101

When interviewing candidates, who have no previous penetration testing experience, there is often a gap in their knowledge. While they have all practised and honed their technical skills they will generally not have practised risk assessment or the impact that a vulnerability would have.

The probable reason for this is that the act of hacking a target is way sexier than trying to categorise or document the fault. There is no impetus to generate a report while you test Damn Vulnerable Web App or the myriad of other safe to play with targets. So exactly why should you?

The difference between a hacker and a consultant is that as a professional you will have to document what you do. You will definitely have to tell the customer exactly what is impacted, who can do it, and for extra points equate that directly to their business if you can.

Failing to do so will generally result in a shrug from your customer and a look in their eye that asks “why should I care?”, while they spin a coke bottle absentmindedly.

In order to work out an appropriate impact rating you are going to need to answer at least these questions:

  1. What is impacted?
  2. Who can locate or exploit the vulnerability?
  3. Are exploit tools and techniques freely available?
  4. Does an attacker need any conditions to be true to exploit the flaw?
  5. If an attacker was to exploit it is there a direct impact to the business?

Simple eh? Let’s work through one example so you can see the reasoning and logic going into an impact rating.

SQL Injection

Anyone with a clue will tell you that SQL Injection is a “high” risk vulnerability. But do you know exactly why? That is the difference I look out for.

A deeper understanding and not simply memorising the impact rating of everything will help you risk the previously unknown flaws. Or deal with the crafty bespoke ones that will never come around again in your career.

To enable me to set an impact I am going to need to spit out a bit on the location of the vulnerability as context is absolutely everything when you are creating an impact rating. Slavishly replaying the same ratings every time without reviewing the context makes a poor consultant. You are being paid to tailor your work to the actual environment and provide the right advise to them.

Overview of the target

The target web application is an e-commerce platform which sells items. It handles personal information for users including their contact details, home address, and their order history. The payment is handled by a 3rd party. The technology stack is Linux running MySQL and Apache. The location is on the product page through the “productId” parameter which is sent in the URL.

What is impacted?

  • Database for certain. With the applications configured user you can: Read, Modify, Insert and Delete data.
  • Potentially the operating system through “file read” and “file write”.
  • Potentially the operating system through command execution though more difficult in MySQL than in some alternative databases.
  • As a pro you will need to confirm these extra “potential” impacts to the operating system. For my simple scenario lets say they have configured away your ability to access or write files, and that you cannot achieve OS command execution.

Who can locate or exploit the vulnerability?

  • The product page is accessed without authentication since people sign in at the point of sale only. There is no authentication barrier to limit knowledge of the flaw, any attacker can find this.

Are exploit tools and techniques freely available?

  • SQL Injection is a well known technique.
  • Training and practical tutorials are free and easy to find.
  • Tools exist such as sqlmap which can automatically find and exploit it WITHOUT needing to know the intricacies of the exploitation.
  • Bottom line: it is very easy to exploit.

Does an attacker need any conditions to be true to exploit the flaw?

  • Short answer: no
  • Longer answer: no user interaction is required to exploit. The attacker is over the Internet so does not require physical access or access to a particular local network. Worth repeating again that it can be found an exploited without authentication.

If an attacker was to exploit it is there a direct impact to the business?

  • There is a direct impact to the business.
  • The personal data that is being stored is identifiable and so would fall under the Data Protection Act in the UK. Should someone dump all the data and then leak that then a fine is likely for the business. Depending on the scale of the breach and the target customer this might be a sufficient fine to cripple their business or close it entirely.
  • There is also a potential reputation damage risk to the business. Consumer trust can be lost and sales will go down.

There we have it all of the ingredients to consider when you think of the impact. There was a slight of hand up there where I split the answer for “what is the impact” into two different entities: the database, and the operating system. I will get back to that in a moment.

First lets explain a simple impact model to you. There is a model called “CIA” which stands for Confidentiality Integrity and Availability. Lets expand a little on these three concepts:

  • Confidentiality – Access to information which an attacker should not have. Pretty simple if an attacker can read your account details or access files from the server then they will know more than they should. The impact of a loss of confidentiality is dependent on the value of the disclosed information.
  • Integrity – Ability to modify information or execute arbitrary commands on a system would affect the integrity. If you change the contents of a web page to suit your needs you have affected the integrity. If you execute an operating system command you cannot trust the server is operating as intended anymore.
  • Availability – If an attacker can simply delete the data or the website content then you will be making it unavailable for legitimate users. If there is another means by which to prevent legitimate users acting as they would like, then you will also have removed availability.

Lets say you provide customers with impact ratings in the categories: high, medium, or low. A very simplistic approach but a fairly effective one and not uncommon in the industry. In order to get to your category of impact you will need to evaluate your vulnerability in terms of the CIA for each answer in “What is impacted?”,

As we provided two entities that are impacted (or potentially so) lets ask and answer ourselves two more questions:

What is the impact rating for the database?

Reminder: our SQL injection has allowed full: read, modify, insert and delete privileges.

Lets fill out the CIA model for the database then:

  • Confidentiality – We can read everything. All user data is at risk including login credentials potentially but definitely including personally identifiable information. There is a “high” impact to confidentiality.
  • Integrity – We can modify everything. You cannot trust the data anymore since an attacker could alter every accounts password, invent new orders etc. There is a “high” impact to integrity.
  • Availability – We can delete everything. Dropping all tables would remove everyone’s orders and their personal information. The site would be dead and nobody could access it or browse the product range. There is a “high” impact to availability.

Three “highs” under CIA? Seems to me we have a “high” impact vulnerability to me, what about you?

What is the impact rating for the operating system?

Reminder: our SQL injection cannot read or write files to the operating system, and cannot execute operating system commands.

Lets fill out the CIA model for the operating system then:

  • Confidentiality – We cannot read files. The impact to confidentiality of data held outside the database on the operating system is non-existent.
  • Integrity – We cannot modify files, and we cannot execute commands. The impact is non-existent.
  • Availability – We cannot execute commands. Even if we “drop all tables” at the database layer the OS would be functioning perfectly. Splitting hairs here because the net effect of dropping all tables is that the site would remain unavailable. But just to be clear the OS is sitting pretty and available.

Three “non-existent” impacts to the OS? Smells like a zero impact issue then.

You would provide customers with one impact rating only. The artistry in penetration testing is being able to calculate all of the potential impacts to arrive at a final snappy answer for the customer. They will often want to order vulnerabilities by the perceived “risk” or “impact” so that they can address the biggest points first.

You always lead with the biggest impact rating which in this case is to the database. You should also make mention of the OS impacts being explored in your report but proving fruitless on this occasion. However, we have arrived at “high” and that is what we go with.

There are various other models for calculating risk or impact and if you love a number from 0.0 to 10.0 then check out CVSS in particular. It is a fully fledged formulae which embeds the concept of CIA reasonably well. As with my process above you would need to calculate multiple risks based on what is being affected and then select the highest rating.

The problem is that CVSS does not always sit well with every type of potential risk you may need to capture in your report. For those fiddly bespoke ones you sometimes have to get your hands dirty and pick a “high”, “medium” or “low” out of the air.

Now that you have read this you will know exactly what to do on that day.

Using JS2PDFInjector to check risks of PDF files with embedded JavaScript

Lets do a very short script for a play to set the scene for this one. Positions everyone:

CornerPirate: Love PDF? Love your JavaScript? Everyone’s favourite office file format and interactive code engine together!

*interlocks his finger*

CornerPirate: Let’s weave them together. What could possibly go wrong?

What could possibly go wrong indeed. No point dallying you can find out how that could go wrong at these places:

These are all way more detailed than I would choose to go on the subject and are worth a read.

Probably a great idea to make sure that your email, and Internet proxy blocks them coming inbound then isn’t it?

This post will show you a tool which can be used to inject JavaScript into a PDF so that you can evaluate your own inbound filtering system’s.

Get the tool

You can get the source and the built jar from the repository below:

https://github.com/cornerpirate/JS2PDFInjector

Download the zip or clone it down it is your choice.

Using it

Goto the “dist” directory and run the jar file. In Windows you can double click on the jar if you have the Java Runtime installed. Alternatively you can run:

java -jar JS2PDFInjector.jar

When it launches it will:

  1. Ask you to select a PDF file to inject into.
  2. Ask you to select a file containing JavaScript that you want to run when users open the PDF.
  3. Create the new PDF with “js_injected_” into the file name and make a new file in the same directory as the original PDF.

Pretty simple I think. It could be a command line tool. But meh I wanted file choosers for some reason that day. You have the source so go fix it if you like.

Creating Payloads

The JavaScript APIs are slightly different from those you might be familiar with in web browsers. In order to understand exactly how to create payloads you are going to need to understand the APIs here:

http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/js_api_reference.pdf

As a pentester it is usually sufficient for me to simply evaluate the defences strip all JS from a PDF or quarantine the file on the way in. If your solution does not then I can infer that you could be doing more to protect yourself.

So for me it has been enough to go with a simple alert message like this one:

app.alert("Hello world!");

If you want to weaponize this by injecting malicious things, then you do so at your own legal risk and I am not responsible for your actions.

I just felt that if this was in anyway useful to someone then I should share it!

How to use your file legitimately

So you found this blog because you wanted to evaluate your companies defences against PDF’s with malware written in JavaScript? Awesome.

  1. Test your Anti-Virus [Local Only Test]
    1. Upload your PDF onto a server or workstation you want to test by USB or whatever works in your environment locally.
    2. Right click and scan with your anti-virus solution and see if it says anything.
    3. The chances are your PDF does not match any signature since you have made it yourself. However, if you have configured a solution which says it “warns when a PDF has JavaScript” or it “quarantines” such files. Check to see that it has found it.
    4. For bonus points if your AV is configured to log events centrally make sure someone has seen the log alert and has kicked off an investigation.
  2. Test your Email Filtering
    1. Use an external email address to email your PDF into a work address.
    2. If you have a complex system which has multiple in-line inspection points before it reaches a user. If the email arrives with the attachment intact and it triggers an alert or whatever your payload is in Adobe Reader? Then you should repeat step one (Local AV scan). Your company is at risk as you have found people can email in potentially dangerous PDF files. Repeating the AV scan manually will see if it will ever find that file. At this point the payload has already run and you have been compromised.
    3. If the email arrived but Adobe does not execute your payload. The chances are that you have something in-line before it hits users. This has attempted to remove the JavaScript from the PDF file but leave the original viewable content. Investigate on your filtering systems which component has done this and see if there was an appropriate alert raised and an investigation by a member of staff. This is still evidence that somebody *tried* to target your users.
  3. Test your Internet proxy Filtering
    1. Upload your PDF file to an Internet web server. It has to be the Internet because Microsoft’s various web browsers implements a “zone” model for security. The Internet zone is the least trusted so the fairest evaluation.
    2. Download the file in the default web browser for your users going through all Internet proxy and inspection routes.
    3. If the payload executes when opened in Adobe. Then you have found another route to download PDF files with JavaScript onto your target machine from an external source. Repeat step one to see if you have a last ditch defence in the AV. However, it is worth noting that the AV allowed the payload to run so…. hmmmm. You are already compromised and should look at the AV solution.
    4. Again. If the payload did not execute. Try to investigate where in the chain it happened, and then look for staff to have reacted to that alert.

You can take these techniques and alter them for all other routes into your organisation. A file-upload on a website? An SFTP service etc.

Hope that helps