9 posts from August 2012
August 27, 2012
 Analyzing the Team GhostShell Attacks
Pin It

Why did they do it?  They claim it was payback for law enforcement arresting hackers. 

How did they do it?  Mostly via SQL injection.  Looking at the data dumps reveals the use of the tool SQLmap, one of two main SQL injection tools typically deployed by hackers.   Here’s a picture from one of the data dumps showing SQLmap:


For more on these tools, click here.

How much data was taken?  Hard to count and verify.  Some of the breached databases contained more than 30,000 records.

What type of data was taken?

  • Admin login info.
  • Username/passwords.  And the passwords show the usual ‘123456’ problem.  However, one law firm implemented an interesting password system where the root password, ‘law321’ was pre-pended with your initials.  So if your name is Mickey Mouse, your password is ‘mmlaw321’.   Worse, the law firm didn’t require users to change the password.  Jeenyus!
  • Files/documents.  A very large portion of these files come from content management systems (CMS) which likely indicates that the hackers exploited the same CMS with a vulnerability in it that allowed a hacker to target it.  However, a lot of the stolen content did NOT include any sensitive information.

Who was targeted?

  • Banks—Credit history and current standing is a very noticeable part of the data stolen.
  • Consulting firms
  • Government agencies
  • Manufacturing firms.



August 23, 2012
 The Significance of the Aramco Hack
Pin It

Lots of press on the Aramco virus and DDoS attack.  But there are two key points that should be emphasized about the breach:

  1. This is the first significant use of malware in a hacktivist attack.  In the past, as we described in our February report, most hacktivist attacks were primarily application or DDoS attacks.
  2. Antivirus doesn't work.  Hackers claim to have infected 30K PCs, which, if true, represents a 75% infection rate of all the company's computers.  Ouch.  Evidence continues to pile up for the need for a new security model.

However, one should not miss the key evolutionary step this attack represents.  In the last couple of years, it became very popular to single out the Chinese, US and Israeli governments for cyber-warfare.

However, this is why the Aramco attack is so interesting. Why?  In this case, it wasn’t a government, it wasn’t an agency nor a company.  This time it was hacktivists working for a political and social cause.   In other words, a group of hobbyists and hacktivists with several very strong minded developers and hackers achieved results similar to what we have allegedly seen governments accomplish. Does this mean that the power of the hacktivism has become so strong that it can compete with government cyber warfare organizations?


August 15, 2012
 Imperva CEO: Companies Are Getting It Wrong On Cybersecurity
Pin It

Great interview with Imperva CEO Shlomo Kramer in Forbes.  The most interesting passage: 

Companies tend to react to cyber attacks rather than prepare for them, and malicious hackers meanwhile learn new tricks to circumvent the gates. “There is a dislocation,” says Shlomo Kramer, the chief executive of IT security firm Imperva and a 25-year veteran of the security industry. “The anti-virus market is not very useful against the new types of malware that come everyday. It’s a $10 billion market. It’s a renewal market.”

By “renewal,” Kramer means that IT managers at large companies — typically chief information officers (CIOs) — prefer to sign checks for the same, established software to protect their web applications, rather than make the uncomfortable changes necessary. It’s easier to do the former than change how money is spent, which can require all manner of approvals.

“But in security, the bad guys change and evolve,” says Kramer.



August 13, 2012
 Sherlock Holmes on WAF Evasion
Pin It

While running for President, former US Senator Paul Tsongas famously said, “That's a good question. Let me try to evade you.”  He didn't make it past the primaries.

There was a lot of discussion about WAF evasion techniques at this year's Black Hat.  Imperva's Tal Be'ery, in his weekly Security Week column, gives an interesting take on the issue.  In a nutshell:

By using evasion techniques hackers break the most basic principle of hiding as stated by Sherlock Holmes: “the best place to hide something is where everyone can see it.” The evasion technique usage just draws more attention from the WAF and actually helps the WAF to block the attack.



August 08, 2012
 The Evolving Nature of Hacktivism
Pin It

A recent Anonymous video admits that they’ve been fairly quiet lately.  From an American and Western European perspective, this is somewhat true.  In 2010, Anonymous built a reputation with Operation Payback.  Since then, there have been various campaigns that have been global in nature—such as the DDoS attack that followed the closure of MegaUpload. 

From a global perspective, the video isn’t completely correct.  Since then, Anonymous’ activity has become regional in nature.  Like soccer, every culture or nation brings their own twist such as the Spanish passing game, the German set piece or Brazilian flexibility.  For Anonymous, the process and objective remain pretty much the same:  distributed denial of service (DDoS) attacks and data theft.  In some special cases, there are more focused attacks designed to deface or steal targeted information such as Anonymous’ theft and exposure of Syrian government files and emails.

What does the present-day Anonymous look like?  There are two emerging groups.

Group #1:  Global
The group has a global presence which only occasionally embarks on a campaign.  Typically, these campaigns, such as the attack on the Syrian government, is reactive.  There is a simple patter:  incident, response.  The Syrian hack sticks out because of its visibility, but there are more examples:

    • Anonymous hackers aided a global search for a cyber-vandal who defaced a charity website.
    • Anonymous DDoSed a French company who tried to register the Anonymous motto.

But note that these incidents are reactive to an incident.  By contrast, there have been hardly any proactive attacks.  For example, one planned attack which was conceived in the Netherlands, Operation NewSon, never occurred.  The objective: attack the wealthiest, biggest companies worldwide.  According to the web page promoting the attack, they wished to:

attack several high corporate entities. Shortly after the start of the operation, we plan to release precious classified data on the already set out list of targets we do have. Those targets are none other then the ones who ultimately rule: the high revenue making companies of the world. While attacking the major companies of this planet may seem lulzy, we also wish that this operation make a difference.

Thought it attracted some attention, this campaign never got off the ground.

Group #2:  Regional
The local versions, by contrast, are much more proactive.  No incident required to invoke a response.  For the best examples, let’s go to Latin America.  In Brazil, Argentina and Mexico there have been numerous attacks that did not react to any specific incident.  Rather, the idea was attack for the sake of attack.  Though we can’t give precise numbers since it’s very difficult to follow activity globally, but it seems quite clear that this category of attacks is much higher by volume. In Brazil Anonymous attacked several major Brazilian government agencies, two major airlines and recently took down most government agencies in Rio.  In Argentina, where several attacks took down banks and government agencies as well.

What are the lessons?

  • Anonymous may be quieter, but only in your region.
  • Anonymous is much more active in developing countries, where presumably there is a larger pool of politically motivated hacktivists.
  • Watch out for incidents that can spark a global response.




August 07, 2012
 Apps Attacked Every Three Days
Pin It

Today, Imperva's ADC released the results of the third Web Application Attack Report (WAAR), which reveals that:

  • The median annual attack incidents on the 50 Web applications observed was 274 times a year, with one target experiencing more than 2,700 attack incidents.  This means apps, on average, get attacked once every three days.  This is consistent with Verizon's 2011 statistics that in 54% of breaches, the attack vector was the web application.  
  • Our report also shows the average attack incident for the observed Web applications lasted seven minutes and 42 seconds, but the longest attack incident lasted an hour and 19 minutes. 
  • SQL Injection remains the most popular attack vector.

Chances are most companies are totally unaware of the application attacks they exerience.  Why?  Part of the answer came out on July 30th, when Gartner released the Forecast: Security Infrastructure Worldwide, 2010-2016, 2Q12, featuring security spend figures for the security industry.  In 2011, nearly $56B was spent on security consulting, hardware and software.  How much was spent to secure applications?  Not much. In fact, Gartner didn't even bother to break out Application Security, instead grouping it into the "Other Security Software" category, which was just 6.6% of total spend.  By contrast, network firewalls and IPS, which are completely blind to the attacks we describe in our report, recieved the bulk of the spend.

For a full copy of the Web Application Attack Report, click here.

To register for the August 15th live webinar detailing the report, click here


August 06, 2012
 Application DDoS: A Primer
Pin It

With all the fuss around application attack vectors that keep hitting the headlines, there is always one element that evades eyes and ears, Application Denial Of Service (AppDoS). Why?  Mainly because of a generic misconception around what this attack is and how it works.  (The OWASP reference can be found here.)

This attack has seen tremendous growth in the past year or so.  Specifically:

  • It is used by Anonymous.  In fact, the Anonymous DDoS attack tool, low orbit ion canon, defaults to HTTP attack—not TCP/IP.
  • Several tools, including LOIC, have been developed to for the purpose of application DOS.  One example is RefRef.

For an actual breakdown of how this attack works, check out this blog.

In this blog post, we will:

  • Define AppDoS
  • Show how does it works
  • Show the problem that it brings to the table
  • How to identify and mitigate AppDoS attacks using application security technologies.

What is AppDoS?

AppDoS, although not a new concept, has evolved greatly in the past few years, especially with the evolution of web applications, and organizations are putting more and more real estate online to serve customers.


Let’s first establish the difference between the Application DoS flavor from the classic network DoS.

In general, DoS is the idea of consuming resources from a service until it has no available resource to offer thereby denying the service’s users from gaining access. A good example for network DoS will the classic “SYN-Flood”, which targets the network service by consuming the server’s available sessions, addressing the TCP handshake directly .SYN is the first step of the three-way handshake.  This attack starts the handshake but never finishes so the attack relies on the server holding open connections and never terminating them.  If a server can provide, lets say, 1000 connections, and we SYN-Flood, it will exhaust its resources quite quickly, not allowing new connections to be established.  SYN-Flood is therefore a Network Denial of Service technique. It is today easily mitigated with most if not all IPS technologies.

Application DoS is somewhat different. It does not address the network resources, or the bandwidth to the service, but the application and the web server itself. Techniques that are included in Application DoS might be SQL Injection, RFI, and the more common service overload. Application DoS will be directed at specific flavors of Web Servers (such as IIS, Apache, etc...) or to specific applications (such as SharePoint etc…) by understanding backend architecture.


How does it work ?

To demonstrate AppDoS, we must first look at the architecture of a common web service.

The following diagram demonstrates a logical schematic of a web service with most of the common components that are usually present in an enterprise application delivered data center:


Note that the network DoS targets reside in the “Access Zone”, while AppDoS targets reside mostly in the “Application Zone” which includes the web front end and the data store for it.

The building blocks of a successful DADoS attack, are:

  1. Bypass ALL of the Access Zone controls in place, address a weakness on the Application Zone
  2. Execute a payload that communicates directly with the Web Server to hit either the Application , the Server and/or the backend server. All building blocks are usually wrapped inside an attack tool which has been used by Hacktivists.

In the past we did cover a few Application DoS tools such as Refref and LOIC. Both are great examples of AppDoS.  The first tool, RefRef, exploits a SQLi vulnerability to cause DoS on the mysql database backend, and the latter hits the service stack, bypassing the entire access zone.


For Guts and Glory

To demonstrate a technique of hitting the application service, let’s look at the service stack.

Typically, most of the repeated from a web page is cached by a frontend caching/proxy service, and at the top, an IPS to identify anomalies. Application DoS hackers rely on these facts when building the techniques they use.  How?

Step one? Bypass the mechanisms put in front of us. To do so, Hackers use a mixture of some very common techniques such as header content and order obfuscation, to avoid getting fingerprinted by IPS systems, and Unique Random Value generation on parameter values – to ensure that the request cannot be cached. Generally speaking, by using both techniques, the mechanisms in the access zone will forward the requests as unique and non-harming data, letting it all the way through to the server.

Let’s look at an example request header of a well known AppDoS tool:

Accept-Encoding: identity
Keep-Alive: 112
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; SV1; .NET CLR 2.0.50727; InfoPath.2)
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cache-Control: no-cache

In the example above we can clearly identify the techniques to ensure that the request reaches the application server itself and does not get stopped by any perimeter security solution. As highlighted, the header contains some unique random values (in the GET request, and in Referer) has a random Keep-Alive value, asks for no-cache content explicitly, and obfuscates the User-Agent by changing it on every request.

The result – the web service’s own resource pool gets exhausted, because there is no controlling mechanism to throttle down the requests, bringing it down.


What Is My Risk

The risk with AppDoS boils down to two things: awareness and the lack of mitigation controls.

While most organizations today already address some of the risks of DoS by introducing redundant bandwidth lines, offloads, IPS technologies and the classic access control, they are not relevant to AppDoS in most of the cases.

Most DoS mitigation controls address the weakness of the network stack and bandwidth, looking for network load thresholds, or repeated traffic, which is not what DADoS is all about. Knowing that the problem is application should raise a concern understanding that specific mission controls should be put in place.

As demonstrated earlier, if an attack consists of about 1000-5000 requests, appears unique, does not trigger any policy – it will bypass all network DOS elements, leaving even the most sophisticated networks bare naked. Perhaps one of the best examples will be the techniques that hacktivists have been using, which proven to be effective against even the largest and most secure organizations in the world.


Mitigation Techniques

Application aware security controls are the generic answer here. If its Web, you need a Web Application Firewall, if its VoIP, you need a VoIP security gateway, RPC – application specific controls etc...

As mentioned earlier, awareness is key here. Knowing that attacks have elevated, means you can start taking measurements to secure your estate. In our case, if you look at Web Applications, it’s a WAF’s job to understand such behaviors, the anomaly from common usage of the application with technologies like Dynamic Profiling, the AppDoS vector can be shut down.

It is very important that you consult with your Application Security solution provider, consultant and vendor to make sure that this risk is taken into account in your data center.

A good place to start can be reading our Hacker Intelligence Report here



August 03, 2012
 Why the Cybersecurity Bill Failed
Pin It

The bill, it seems, is a no go.  With all the cyber attacks, why did it fail?

  1. It was all sticks, no carrots.  If the government wants to impose regulations and compliance, it should at least have the good sense to offer something to the cyber security community.  For example, Washington could have offered to increase law enforcement resources.
  2. There was little input from the cyber security community.  If you want legislation to succeed, it helps to get the consent of those it will affect.  In this case, we saw the “Washington knows best” dynamic that doesn’t go over well anywhere, especially with security geeks.  At Black Hat, for example, Bruce Schneier talked about the merits and demerits of the bill.  Imagine how much more effective if would have been if he talked about how he helped craft it, in essence, putting his weight behind the bill.  Similarly, it seems every time Obama comes to the Bay Area, it’s for fund raising versus gathering ideas from the Silicon Valley.



August 02, 2012
 Hacktivists Breach French E-Commerce Site
Pin It

According the hackers:

  1. wnd target  :
  2. Category     : french e-commerce website, not that big, not that small
  3. Type         : SQLi (PHP/MySQL) + various XSS
  4. Total loss   : 729115+ customers accounts compromised with e-mails/passwd
  5.                1115050+ bank transactions exposed

Though many passwords were not released as a part of the breach to do any real statistical analysis, we can say this much:

  1. There are lots basic passwords such as 1234abcd, nathalie, etc...  Though 'baguette' did not make it onto the list.
  2. The password are in cleartext. 
  3. We do have to call out the most complex, hard core breached consumer password:  



Find Us Online
RSS Feed - Subscribe Twitter Facebook iTunes LinkedIn YouTube
Monthly Archives
Email Subscription
Sign up here to receive our blog: