SailPoint has recently released their survey results regarding employee behavior with respect to corporate data. An interesting figure indicates that 24% of the surveyed Brits mentioned they would copy electronic data and files to take with them when they leave a company.

This figure should certainly raise concern and comes as no surprise. In fact, a similar survey conducted by Imperva in 2010 covering 1000 individuals in London demonstrated how severe this problem really is. That survey showed that 79% of the respondents mentioned that either their organization does not have data removal policies (upon employee departure), or they were unaware of such policy. Furthermore, the vast majority (85%) stores corporate data in home computers or personal mobile devices. This is an immediate consequence of the trend called “Consumerization of IT”. While the common belief is that the insider threat is usually a corporate spy or a revenge-seeking employee, the reality is more mundane. As it turns out, it is the average Joe that represents the most probable threat. Employees enjoy legitimate access to sensitive corporate data while on the job. They use their access privileges to rightfully create copies of the information as they process it for their daily tasks. Upon leaving the organization, many individuals do not care to remove copies of sensitive information, and in some cases even develop a sense of personal ownership towards it. What should organizations do to prevent this data getting out of control?

• Enforce strict access controls over critical data. This access control should be based on a business need-to-know level. This cannot be achieved by a singular project but rather imposes a process of constantly evaluating user access privileges
• Monitor access to sensitive corporate data and maintain a detailed audit trail.
• Detect abusive access patterns to sensitive corporate data

There has been a lot of interest surrounding our Web Application Attack Report (WAAR). We have also received quite a few questions regarding the report. We hope this FAQ will clarify some points and respond to some of your questions.

Q1: How did you find that when sites come under automated attack, the target can experience up to 24158 attacks per hour?

A1: This is the actual observed traffic of SQL Injection, RFI, DT, and XSS attacks per hour.  You can find these figures in Table 1 of the report.

Q2: Your report indicates that both the number of SQL Injection attacks and RFI attacks are on the decline. Does this mean that the total number of Web attacks is decreasing?

A2: No. As you can see in the following graph, there has been a dip in Web attacks. Yet, the number of attacks jumped up once again in May. We’ll continue to monitor this trend to gain more insight into the rate of these attacks throughout time.

Q3: The report shows a clear correlation between HTTP violations and Directory Traversal (DT) attacks. Why are the two so closely correlated?

A3: Most often, DT attacks are generated by automatic tools which contain HTTP anomalies in their request. Additionally some DT attack vectors are intentionally crafted to include structure and content that violates the normal HTTP behavior. These violations are the “secret sauce” that make the attack work.

Q4: Is Directory Traversal a popular method used to perform vertical scanning of an application?

A4: Yes.

Q5: When you discuss the geographic distribution, you mentioned the following statistic: “the average ratio of attacks to attacking hosts is about 10:1 for RFI, 25:1 for SQL Injection and 40:1 for DT”. What does this statistic mean?

A5: For each attack type, this represents the average number of attacks a single host (identified by its IP address) had initiated. For example, a ratio of 10:1 RFI attacks means that, on average, an attack source initiates 10 RFI attacks.

We’d like to also make a necessary correction here: the ratio is 40:1 for SQL Injection attacks and 25:1 for DT attacks.

Q6: Why aren’t RFI and DT featured in OWASP’s Top-10?

A6: The shortcoming of OWASP Top-10 is that they concentrate on the most prevalent vulnerabilities. And while this is important – it does not focus on what hackers are actually hacking. Hackers are going after the path of least resistance. This report shows that if there is a vulnerability in the Web application, overlooked by the developers, not appearing in the OWASP Top-10, though easily exploitable – then hackers will go after it.

Blackhat conference is around the corner and we're beginning to receive glimpses of upcoming talks. One of the presentations will show attendees how to manipulate a Mac battery in order to install malware. Cool? Yeah! Sophisticated? Absolutely! Practical? Not really...

Our own ADC member, Tal Be'ery, provides his thoughts...

No matter how obscure and fun an attack sounds, we need to focus on the real threats. Although it's an original vulnerability that reflects the deep security knowledge of the researcher, we do not expect to see too much of it (or any) in the wild as it...

1. Requires physical access to the battery.

2. Makes no sense economically - Why would hackers invest time and money in the R&D of a new tool that would cost 130$ per deployment (the cost of a battery), would only be relevant for a selected group (specific battery model of apple laptops), and would require physical access when the hacker could infect millions of machines using OS exploits and social engineering with a low cost per infection - without even getting up from the couch?

With that said, if a possible target of an Advanced Persistent Threat (APT) attack (such as highly sensitive state infrastructures) is using such a vulnerable device - they may need to evaluate its use until a patch is released.

So the general public should not worry about this super cool attack, but instead invest time and resources in protection from the usual threats by installing Antivirus software and maintaining awareness of social engineering attacks.

As a part of its ongoing Hacker Intelligence Initiative, Imperva’s Application Defense Center (ADC) observed and categorized attacks across 30 applications as well as The Onion Router (TOR) traffic, monitoring more than 10 million individual attacks targeted at web applications over a period of six months.  Our analysis shows:

• Due to automation, web applications, on average, are probed or attacked about 27 times per hour or about once every two minutes.  At the apex of an attack, web applications can experience nearly 25,000 attacks per hour or 7 per second.   The way hackers have leveraged automation is one of the most significant innovations in criminal history. You can’t automate car theft or purse snatching—but you can automate data theft. We predict that automation will be the driver that will help make cyber crime exceed physical crime in terms of financial impact. Ironically, most organizations, especially smaller ones, have not yet emphasized Web application security and need to take notice as automated methods will virtually guarantee that criminals will find them
• Four dominant attack types comprise the vast majority of attacks targeting web applications: Directory Traversal, Cross-Site Scripting, SQL injection, and Remote File Inclusion.  These findings very much mirror the approach used by hacking groups such as Lulzsec and Anonymous whose attacks largely focus on data theft via application attack.  Our findings and the recent spate of high profile data breaches highlights how the battlefield has shifted to applications and databases and away from network firewalls and anti-virus.
• The United States is the main source of application attacks. Applications are attacked by infected computers, or bots, with most located in the US.  This highlights that advances in evasion are also significant. Our data shows that it is increasingly difficult to trace attacks to specific entities or organizations.  This complicates any effort to retaliate, shut down cybercriminal gangs or identify potential acts of war.

To download the report, with no registration required, click here.

The sad news about Amy Winehouse's passing isn't, unfortunately, sad for everyone.  As we saw with Bin Laden's death, the hacker underground moves quickly to exploit current events.  Below you see the process underway as a hacker tries to sell domain names to poison search engine results:

Note the comment, "these will get MILLIONS and MILLIONS of searches over the next few days the funeral ones even longer (sic)."

Once again we see how search engine poisoning is becoming one the most preferred means of spreading malware or stealing data.

US-CERT has come out with its security recommendations:  http://www.us-cert.gov/cas/techalerts/TA11-200A.html

We are glad to see the heightened attention on web applications.  Specifically, the security alert states:  “Use an application proxy in front of web servers to filter out malicious requests.”  By application proxy, they mean a web application firewall.   PCI has long required WAFs and, as the Verizon Data Breach Investigation Report highlighted, 89% of breached companies were NOT PCI compliant.

What should government entities trying to follow the US-CERT recommendation know about WAFs?  Full disclosure, we are a WAF vendor, but here are the key takeways:

• Filter out malicious application requests.  It also can perform input validation and detect and stop remote file inclusion and SQL injection attacks.  The US-CERT recommendation (correctly) recommends code review, the issue is vulnerability volume and time required to fix the vulnerabilities.  WAFs are essential to cover what developers can’t or won’t due to lack of time or skill.
• Stop SQL injections.  One of the most common attacks against government (and private sector) networks is SQL injection.  WAFs are an essential defense against SQL injection attacks.  For more information on SQL injection attacks, see: https://www.imperva.com/resources/glossary/sql_injection.html.
• Take measures to prevent DDoS attacks.  During the Lulzsec attacks, we described how botnets were used to help with cyber attacks.  WAFs can effectively detect and stop application DDoS attacks.

In addition, the US-CERT Technical Cyber Security Alert advises that organizations should require secure passwords. This recommendation is near and dear to our hearts here at Imperva. We have posted multiple blog posts and even a report about password security. So after you have undertaken the appropriate measures to protect your web applications, be sure to enforce password and authentication best practices.

The Onion's brilliant piece on the impact of the Anonymous arrests.

Today's Wall Street Journal features a story on small firms being  targeted by hackers.  For anyone in security, this confirms what we already knew (for example, Imperva recently spun off Incapsula who sells a web application firewall as a clould-based service).  Hackers are going after smaller firms because:

• Smaller organizations haven’t deployed proper defenses.  Hackers prefer the path of least resistance.  Although media reports focus attention on large, well-known organizations, the path of least resistance has made smaller, poorly resourced enterprises prime targets.  This even applies to social engineering (see example below) to make money through compromised data.
• Automated attacks are prevailing.  To maximize reach, hackers leverage automated attacks technologies.  Specifically, they use Google and, more frequently, commercially-available vulnerability scanners to find victims.  This approach keeps costs low while optimizing the odds of success.

The WSJ story focused on breach stats from the Verizon report.  But what do hackers think?  Here are some intersting bits from various hacker forums.

First, here's a snippet of a guide to hacking small companies using social engineering.  They key quote, "I'll be giving you 5 ways to hack into small business and get the data you want."

Less anecdotally, an analysis of hacker forum July 2009 – July 2011, there have been 930 total discussion threads about small businesses or small companies (or both).  

But the key driver behind small firms being targeted is automated attacks.  We've written extensively on the industrialization of hacking and its far-reaching impact.  What does this mean for small firms? Automation means you can't hide.  A hacker can probe sites worldwide, large or small for vulnerabilities and ultimately, farm data.  We did an analysis of several web applications that were attacked, parsing them by Alexa ranking.  We found no correlation between number of attacks and Alexa ranking.  In other words, popularity of a site doesn't matter.  In the chart below, we show a sample of sites whose web applications were attacked over a six-month period:

One of the best pieces of evidence?  Hackers posted the result of one of their vulnerability scans, uncovering more than 5,000 sites that were prone to SQL injection.  While eyeballing the output, one thing is clear:  there are no big companies.  Instead, the list was full of small firms including fitness clubs, pet grooming services, restaurants, nonprofits, charities, schools, and more (though we redacted the names of the firms):

Imperva's Tal Be'ery analyzed the recent Google malware issue.

I would say it’s probably a boy in the browser attack (BITB).  See our original post on the subject almost half a year ago:

http://blog.imperva.com/2011/02/boy-in-the-broswer.html

There are two key points from what we wrote:

First, we noted that, "with a BitB, the trojan takes control of the victim’s traffic and re-routes the information through an attacker’s proxy site." Second, as a real-world example, we higlighted click fraud against, ironically, Google. We wrote:

This is an interesting scheme since the target is not a banking application, rather it is used in order to commit fraud. In this case, to defraud Google. The victim accessing a regional domain of Google, for example www.google.co.uk would be redirected to the attacker-controlled server. When a user performs a query, the attacker would fetch the results and ads from Google, but serve them on his own page. The result is that when a user clicks on a specific ad, the commission is attributed to the attacker, and not to Google. 36 Google regional domains were targeted in this scheme showing that the attacker’s aimed to target victims worldwide. 

Compare this with the post on Krebs:

http://krebsonsecurity.com/2011/07/google-your-computer-appears-to-be-infected/

The malware intercepts traffic destined for high profile domains like google.com, yahoo.com and bing.com, and routes it through intermediate hosts or “proxies” controlled by the attackers. The proxies are used to modify the search results that a victim sees for any given search term, and to redirect traffic to pay-per-click schemes that pay for traffic to specific Web sites.

Coincidence?  I think not.

Imperva's Tal Be'ery explains how The Sun was hacked.  

Bottom line:

• Lulzsec are using webapp vulnerabilities (as we said earlier).
• If you don't want to be the next lulzsec victim, invest in your web application defense.
• What Lulzsec is doing (and has done) simply mirrors what commercial hackers do to steal data. Their methods are nothing new--only the purpose is hacktivism.

See quote from http://www.theregister.co.uk/2011/07/19/anonymous_hacking_arrests/

Federal prosecutors announced the arrests of two other people who were charged with computer offenses that may have been related to hacks credited to LulzSec, which many believe to be a splinter group of Anonymous.

Scott Matthew Arciszewski, a 21-year-old student at the University of Central Florida, illegally accessed a website operated by the FBI-affiliated Infragard, a criminal complaint filed last week in Tampa alleged. He then uploaded three files he named “aspydrv.asp;jpg” – and, yes, the indictment includes that semicolon in the filename – which “caused damage to the server by impairing the integrity of the server,” according to FBI Special Agent Adam R. Malone, who prepared the document.

That's local file inclusion (LFI).

How does it attack work? It exploits a known vulnerability in IIS. (CVE-2009-4444)

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-4444

Microsoft Internet Information Services (IIS) 5.x and 6.x uses only the portion of a filename before a ; (semicolon) character to determine the file extension, which allows remote attackers to bypass intended extension restrictions of third-party upload applications via a filename with a (1) .asp, (2) .cer, or (3) .asa first extension, followed by a semicolon and a safe extension, as demonstrated by the use of asp.dll to handle a .asp;.jpg file.

If the application (say "app.com") allows jpg upload, the attacker can upload "malicious.asp;.jpg". The application filter will identify it as "jpg" based on the extension and allow the file upload.

The IIS server that runs the application identifies files with semicolon in their name, based on the extension before that semi colon.  so "malicious.asp;.jpg" is treated by IIS as an asp file – ASP file is an executable file that can take over the server.

Now the attacker can execute his malicious code by browsing to "app.com/uploaded-content/malicious.asp;.jpg" and activate the malicious asp file and take over the server.

According to the guardian on the Murdoch attack http://www.guardian.co.uk/technology/2011/jul/19/how-lulzsec-hacked-sun-website?intcmp=239

The most likely candidate for that hack – which would use the weakness discovered in 2009 – is the "mailback" page at http://www.new-times.co.uk/cgi-bin/newtimesmailback, which on Tuesday morning had been deactivated, along with the whole of the new-times site.

It's possible that the "newtimesmailback" page allowed the upload of files in a similar way as described above.