Last week, as part of the Spammer-Anti-Spammer wars - An attack on Spamhaus was created using a DNS amplification attack on highly rated DNS servers, the attack used Botnets to send an initial reflection request to the DNS Servers, which then generated the actual traffic. Today, although we are not sure if the same vector of attack was used again, the attack was able to draw enough web traffic to Spamhaus to reach a reported peak of 300Gbps of DDoS – a respectable number indeed. It is clear that proper DNS Server monitoring and configuration should have deflected the attack at an early stage. The DNS Attack vector showed again the effectiveness of using servers as initial attack vectors rather than a user-based botnet.

Where can you learn more about DDoS?

• Imperva White-Paper about the four steps to defeat a DDoS attack
• HII report that analyzes different DDoS attack techniques, and how to deal with them
• A short DDoS protection customer story that shows both attack and defense mechanisms

Last week, we covered the way that the threat landscape has changed from network attacks at the front, to more advanced Web attacks. As you may know, Web application firewalls are designed to deal with those threats and are ever evolving to provide the best coverage to the latest threats.

With that in mind, Imperva aims to always focus on where hackers will hit next. In order to do that, we focus on what WAF solutions must have in order to mitigate the most advanced threats.

The top 10 features that every WAF should include:

1. Understand web applications - To accurately stop attacks, a Web application firewall must understand the protected application, including URLs, parameters, and cookies.
2. Stay ahead of hackers - A Web application firewall must have up-to-date protection to defeat the latest Web-borne threats.
3. Thwart evasion techniques - A Web application firewall must include an analytics engine that can examine multiple attack indicators to block attacks without false positives.
4. Prevent automated attacks and bots - A Web application firewall must be able to stop automated attacks like site scraping, comment spam, application DDoS, and vulnerability scans. Due to the explosion in automated attacks, stopping malicious users can be as important as stopping malicious requests.
5. Recognize malicious sources - To protect Web applications, a Web application firewall must recognize known malicious sources and sites. It should identify users that are actively attacking other Websites and stop them instantly, before they can inflict more damage.
6. Virtually patch vulnerabilities - A Web application firewall must prevent attempts to exploit application vulnerabilities.
7. Stop malware - A Web application firewall must be able to mitigate the growing scourge of fraud malware.
8. Eliminate payment and account origination fraud - A Web application firewall must be able to mitigate payment and new account fraud without requiring application changes.
9. Support on premise and cloud deployment - A Web application firewall must provide flexible configuration options to satisfy every organization’s unique requirements. As many businesses transition their application infrastructure to the cloud, Web application firewalls must adapt, supporting virtual appliance solutions for private clouds and cloud-based security services to protect hosted Web applications.
10. Automate and scale operations – A Web application firewall must deliver point-and-click security policies. Simple, but flexible policy configuration not only eases initial configuration, but it also makes it easier for administrators to review security policies developed by their peers.

Where can I learn more?

Imperva is proud to present the Future of Web Security eBook for your viewing which will provide more details. Enjoy.

In the past year we have seen numerous Web attacks hit companies globally. Organizations have been
breached and data has been stolen. And companies’ web applications have been taken down by DDoS attacks. Hackers easily dance around network security defenses, bypassing firewalls, IPSs, and other controls.

The Problem has Moved On…

For the past 10 years, companies have invested their efforts and budget in securing their infrastructure. Most of that budget went toward solving the most acute problems that existed, which were network hacks and virus propagation. And although companies have done a great job at solving these problems, it motivated hackers to look for other ways to penetrate their networks.

Hacking today is all about profit. In today’s industrialized hacking environment, hackers are focused on one major goal: maximize profit and minimize effort. When companies found a way to prevent the network attacks, hackers moved to where there is less resistance – the Web. Most compromised companies are those that have invested a lot in their security infrastructure: they upgrade their firewalls to the latest and greatest, but they have not invested in stopping today’s attacks that go after their most valuable assets through their web applications. Thus, when the hackers come today, companies aren’t ready.

In the Details

Attacks on the Web side of life are divided into two main categories:

• Technical Web Attacks
• Business Logic Attacks

Technical web attacks are attacks that use a software flaw in order to steal data, inject software and generally manipulate the application to get data. Security research cites that 97% of all data breaches are due to SQL Injection.

Business logic attacks and fraud attacks are gaining popularity. Hackers understand how to break an application’s logic to provide access to restricted areas, run fraudulent transactions, break search engines by creating enormous search terms (which in effect creates a DoS on the application), and countless other forms of abuse.

Heads Up!

Next week, Imperva will release an eBook discussing the future of web security. We will outline our thoughts on the most important features and controls that Web Application Firewalls should provide.

Sharing security research and intelligence makes the community as a whole safer. By uncovering and sharing information on weaknesses in the Internet, common vulnerabilities and new attack techniques, our customers and the industry learn specific ways to improve their risk posture and gain deeper insight into how cybercriminals operate.

Once upon a Time…

In 2012, a new attack against SSL named “CRIME” (Compression Ratio Info-leak Made Easy) was introduced.  The attack uses an inherent information leakage vulnerability resulting from the HTTP compression usage to defeat SSL’s encryption.

Despite the very interesting find, the CRIME attack suffered from two major practical drawbacks:

1. The attack threat model: for a CRIME attack to work, the attacker must control the plaintext AND to be able to intercept the encrypted message. This attack model limits the attack to mostly MITM (Man in the Middle) situation, you must use eavesdropping.
2. The CRIME attack was solely aimed at HTTP requests. However, most of the current web does not compress HTTP requests.

Last week at BlackHat 2013 in Amsterdam, Imperva’s Tal Be’ery, a Web Research Team Leader in the ADC Group, presented a new analysis of the CRIME attack, advising that the discovered cyber threat may be more serious than previously believed.

The analysis showed the potential for a new attack technique, which we’ve dubbed TIME (Timing Info-leak Made Easy), that could overcome the two limitations of the original CRIME attack, specifically removing the eavesdropping requirement and making the attack surface broader by focusing on HTTPS Response instead of HTTP request compression.

In Layman’s Terms

The TIME attack, which mainly affects Web Browsers, shows that all the hacker needs to do is redirect an innocent victim to the malicious web server, apply certain JavaScript and get the victim's secret data; the barrier of the eavesdropping requirement is removed.

Diving into the Research

First and foremost, SSL is NOT broken and your online bank accounts are pretty much as safe as they were before this research. Attackers will still try to get your data by infecting your machines with malware and attacking the server with SQL injection or other web application attacks to get the data within the database. Tal’s research focused on being one step ahead of the hackers - understanding how they could evolve the attack to make it easier and more effective – so that the security industry becomes aware of the potential problem.

The main focus areas of the research:

• Show that the CRIME attack could be extended to HTTP responses – The original CRIME attack had shown that the interaction between compression and encryption may leak data. However, the attack was limited to discovering secret data on the HTTP request only, namely the cookie. Therefore it was easily mitigated by disabling the compression of cookie header. Tal showed that CRIME attack techniques can be extended to attack any secret data on the HTTP response.
• The eavesdropping requirement of the CRIME attack is one of the main reasons that the attack vector was considered impractical, since it required the attacker to be located either on the same network or have some control already of the victim, which renders the vector ineffective. 

Key Takeaway

Using the extended TIME techniques, our research show that an attacker can infer on the data size from timing measurements taken by a JavaScript, allowing the attack to be carried out by a remote attacker, this elevates the severity of the attack vector for the first time as it removes the need for eavesdropping from the game. Second, the extension of the attack to HTTP Response grows the attack surface as most applications allow HTTP Response compression for performance reasons (unlike HTTP Request where compression is sometimes redundant) therefor making the vulnerable potential attack surface larger.

Where can I learn more ?

You are invited to download Tal’s BlackHat Presentation, Further information and relation to other research work could be found at ArsTechnica at This link.

In January, Incapsula released analysis showing how infected webservers were being used in order to elevate broader attacks, such as DDoS campaigns, which we have recently witnessed targeting the banking industry.

Today, ThreatPost released an article discussing the recent rise of DDoS against US Banks. Some banks were reported to suffer service disruption ( via sitedown ). This follows a warning issued by the Qassam Cyber Fighters hacktivist group, claiming it will disrupt US Banks operations as part of “Operation Ababil.”

Denial of Service (DoS) attacks are technical attacks that are focused on consuming the resources of a server/service, which prevents it from serving more legitimate users of that specific service. This is done either by consuming the available network bandwidth, or in the application age, by consuming the actual application resources. These attacks usually require many machines addressing the service in the same time to generate the load.

The Web Threat Angle

In the industrialized hacking age, where Hactivism has become talk of the day, hackers build botnets in order to coordinate such an attack from many computers. however, one of the easier way to create an effective bot-net, is by infecting a webserver instead of its users. this is due to the fact that althgough the infection effort may be the same, the actual attack requires far less machines due to the nature of webservers having a very large network pipe compared to normal users.

Now we are seeing itsoknoproblembro, which is one of the tools most used in the recent DDoS attacks against the US Banking industry, some peaking at 70 Gbps.

This tool is distributed mostly via a Remote File Inclusion (RFI) attack, planting a PHP worm on the server by including remote code, infecting the web server and adding it as a zombie to the bot-net. An RFI attack .

What does this teach us?

There are two problems that need to be dealt with here. One is the problem that the banks now deal with: the DDoS attacks themselves. The other is the infection vector of the malware via webservers.

The RFI vulnerability is the starting point that allows hackers to build the bot-net that eventually generates the DDoS attack. Since alongside spear-phishing, it enables one of the biggest ways for hackers to use web vulnerabilities to infect users/servers (webservers in this case) with DDoS-specific.

Interestingly enough, companies protected by Web Application Firewalls are capable of protecting themselves against RFI attacks and should be safe against this kind of infection, and from becoming an aid in the hands of hackers. And even though they do not suffer from the DDoS attack itself, by becoming the attacker machine, they suffer from bandwidth loss just as much, and of course a raputation risk.