Tag: Web App Security

OWASP Zed Attack Proxy (ZAP) or ZaProxy, as it is also called, is an exceptional tool for both security testers and developers to test web application security. In this tutorial we will take a quick look at how to use a couple common features in the latest version of ZAP, including the quick attack and the Man-in-the-Middle Proxy scan and fuzzing features.

For this article, I used Mutillidae as a test target and ran ZAP from a Kali Linux system. As always, never use tools like this against systems that you do not have permission to do so.

Quick Scan & Attack

To start the quick scan, simply enter the address of your target (a Mutillidae system here) in the “URL to attack” input box and click the “Attack” button.

This will spider the entire target website and then active scan it for vulnerabilities. The scan progress and pages found will be displayed in the bottom window. When it is finished press “Alerts” to see any security issues with the website:

And as you can see, ZAP found multiple issues with the website! Each folder contains different types of security issues, color coded for severity. Clicking on the folder will reveal individual issues that you can select for additional information. ZAP is wonderful because it not only lists an in-depth explanation of the problem, but it also gives you recommendations on resolving the issue.

This is nice, but we can do a much more in-depth scan and even perform fuzzing attacks using ZAP’s proxy function.

Proxy Scan and Fuzzing

Start ZAP and then set your browser internet proxy settings to Localhost:8080. Then surf to the target webpage and login. Surf to a few other pages if you like, entering data as you go, the more site interaction the better. When done, return to ZAP, highlight the website in the “Sites” window, right click on it and select “Attack”, and then “Active Scan”:

ZAP will perform an in-depth scan of the page, including the new information obtained with the ZAP proxy. When the scan is done, click on the Alerts folder:

Notice we now have more alerts including SQL Injection issues. Let’s see what SQL attacks would work against the target.

In the sites Window, select the login webpage, right click on it and select, “Attack” and then “Fuzz…” This will open the fuzzer screen. It lists the header text in the top left box, the target query with selectable text in the bottom left box and the fuzz location/tool window on the right.

In the bottom left window, highlight the name you used to login as a keyword. I used the username, “test”.

Now click “Add” in the right Window:

A Payloads box pops up showing the value of “test”. Click “Add” again to select our attack payloads.

In the drop down box that says ‘Type:’ select, “File Fuzzers”:

Now click the triangle next to “jbrofuzz” to expand the options:

Notice the large amount of different attack types you can use! We just want to try SQL Injection for now, so check the “SQL Injection Box”, and click “Add”.

You will now be back at the payload screen. Notice that at this point you could add multiple keywords and numerous payloads if you wanted to create a very complex attack. But for now we just want to attack the keyword ‘test’ with SQL Injections.

Click “OK” to continue.

Now just click, “Start Fuzzer” to begin.

This can take a short while to run, but within a few seconds you should already see multiple SQL injection attacks and their statuses shown in the status window:

So fairly quickly we were able to scan a site for a host of SQL injections issues. Add to that the ability to select multiple keywords and payloads and you have a very powerful web application testing tool!

A select panel of experts met to discuss the security issues with Obama’s Healthcare.gov website. But only one of them demonstrated vulnerabilities live.

TrustedSEC CEO (and creator of the Social Engineering Toolkit) hit the ball out of the park yesterday at the Congressional Committee Hearing on the Affordable Healthcare Act – Healthcare.gov website security issues.

According to the opening statements by Chairman Lamar Smith, Healthcare.gov is “One of the largest collections of personal data in the world“. The site contains data from 7 different agencies, and includes personal information such as citizen’s birthdays and social security numbers.

According to the President, the website was safe, secure and open for business. But the administration has cut corners with the website that leaves the site open to hackers.

At the hearing, Kennedy said that through passive reconnaissance his company had discovered 17 different direct exposures which they reported. He would not talk about all of them, because as of the time of the hearing not all of them had been fixed. He then went on to actually demonstrate several possible ways that hackers could target the site.

David does not talk about all of the issues that they discovered, but their full report(PDF) that was submitted to congress is very interesting.

The report shows several issues that include:

Open Redirection (where a malicious re-direct link could be inserted into a Healthcare.gov link)

The internet can be a very unfriendly place, especially for older operating systems like Windows XP. In this post we will take a look at exploiting Windows XP browsers using BeEF, the Browser Exploitation Framework.

It has been a long time since I have done a post on BeEF, about three years in fact, but after going through a great Web Application and XSS security class, I figured it was time to brush it off again. I was very pleased to find that a ton of new features (called commands) have been added to BeEF since I last used it, dramatically increasing its functionality.

Granted a lot of the attacks in BeEF no longer work against Windows 7 with the latest browsers, but it seems that Windows XP systems are still very vulnerable to many of the browser attacks, even when using the latest browsers.

So let’s see what BeEF can do against a Windows XP system.

First we need to start the Exploitation Framework. In Kali, just open a terminal and type:

This starts the BeEF server and shows you the web address to open the graphical user interface and a couple sample pages that you can use to hook browsers:

Just surf to 127.0.0.1:3000/ui/panel to view the user interface and login with the username and password of ‘beef’:

You will now be greeted with the BeEF control panel:

Listed under the “Getting Started” section you will see links for two test pages that you can use to play with hooking browsers. I like the “Advanced version” as it looks like a real webpage.

On our XP system running the latest Firefox browser, if we surf to the “Malicious” demo page that BeEF creates, we will see this screen:

Or this if we are using Chrome:

The page shows some delicious looking beef, and nothing really seems awry. But what the user can’t tell, is that this particular webpage contained a hook. A malicious program that allows an attacker to hook the browser and, well, pretty much take over complete control of the browser.

As soon as the visitor simply visits the page, the hook is set. Notice that the user does not have to run anything or mouse over anything for the attack to work. Just visiting the page triggers the attack.

When machines are hooked, they show up in the BeEF control panel:

Now that we have the system listed in the control panel, we simply click on the system we want to attack and then pick from the numerous attacks listed in the commands section:

Using these commands we can grab information from the victim’s browser, or even change what they see. For example, if we want to try to Social Engineer them and grab their Facebook credentials we can go to the Social Engineering tab and click “Pretty Theft”. And then ‘Execute’.

On the victim’s browser a pop up will appear:

Oh no! My Facebook timed out!

If the user fills in their creds and hits Log in, this appears in the BeEF control panel:

Or we could try to grab credit card numbers with this Amazon looking attack:

BeEF can do much more than just send pop-ups. You can grab the HTML of the webpage that the victim is on:

And then change any links on the page in realtime, without the user ever knowing, to point to wherever you want the victim to go. Here is a look at the webpage source after changing all the links on the page to point to the Dallas Cowboys website:

Of course an attacker wouldn’t normally send them to a sports site, but most likely a website that was, say, a complete spoof of Amazon or Facebook.

You can also send custom Javascript, or even tie it in with Metasploit to attempt to get a remote shell.

As you can see, an attacker having control over the browser can be very bad.

The attacks are color coded as to the chance that they might work. But I did notice that some attacks that were marked red did in fact work, while some marked green did not.

I also noticed that newer browsers seemed to stop some of the attacks, but XP was still pretty open as to what would work against it.

I tried these attacks against a Windows 7 system and nothing was displayed:

A hook was created, but only lasted for about a second or two before it was dropped.

The best mitigation against this type of attack is to use the latest Windows OS and browser versions. If you can, update or replace your Windows XP systems, especially if they are used online. The base security in Windows 7 and 8 is much better than WinXP. Finally always run a script blocker like “NoScript”, and don’t click on or open links and attachments in unsolicited email and social media messages.