Earlier this week, the “Moroccan Ghosts” published a list of 52 defaced Israeli sites, replacing site
content with political propaganda pages (and some cool Moroccan music).

Looking into the hacked domain list, we noticed that most of the domains in the disclosed list are hosted on the same server. In this case, a large hosting company in Israel. It was relatively easy to see that the server itself runs PHP v5.

Although this is merely educated speculation, it seems that the hackers were able to exploit a configuration mistake in the server rather than individual vulnerabilities in the hosted applications or taking over the entire server through a vulnerability in a single application.In a shared hosting environment “one rotten apple spoils the barrel” – so a single vulnerability may result in owning the entire server and the database that holds data for all applications.

In other words, when an application is hosted on a shared hosting server, even if one application owned by company A is secured, if a second application owned by company B is not so secure and is being hacked, the end result may be a breach to both. This is also true to a secured application on an insecure platform.

What can hosters do to prevent incidents like this?

• Proper server administration should enable creating silos in terms of database servers, virtual directories and permissions per customer. This reduces the risk in some ways but does not remove it.
• Hosters should offer the same compartmentalization services they offer to physical customers, to the digital and hosted customers by adding web application controls that will reduce the risk of such hacks.
• Make sure that the management platform is secure, since lots of the hoster hacks are breached via an insecure management console that allows file changes and DNS changes per user provisioning, or globally.
• Offer web vulnerability scans to your customers, because most companies do not have the experience that hosters have dealing with web applications and the security required around them. It makes sense that customers that outsource hosting their applications will appreciate outsourcing the security around them. However, to complete the cycle scanning is not enough! Once vulnerabilities are found it is critical to use controls such as Web Application Firewalls to remediate the findings.

The issue of sharing information for security purposes has become a hot discussion topic by both industry practitioners and legislators. The CISPA in the US and the CISP in the UK are examples of how regulators try to facilitate the cyber security information sharing by private sector actors. In fact cyber security information sharing is already applied for quite a long time to domains like malware identification spam mitigation and anti-phishing.

So far, however, cyber security information sharing has not been applied to what is probably one the most critical domains – web application attacks. Whatever sharing was going on was mostly of a “tell-tale” nature – organization sharing success (or failure) stories and vulnerability information made public (usually with a substantial delay).

The research we’ve conducted in our labs for the past year focused on cyber security information sharing for the web application layer domain. We tackled the issue from many different angles including: what is the minimal set of data that should be shared (and still makes sense), how can we measure the potential value of the sharing process and whether the information being shared can be automatically translated into structured actionable intelligence information that can be disseminated back to the community and deployed automatically in a timely fashion.

We covered attack data from over 50 applications in our research and the results are very favorable. While many details can be found in the reports I’d like to share a couple of examples here in the blog. First one is what we called “reputation quadrants” which shows the relevance of attack agents (attack source, attack vectors or attack tools) for the sharing process. In the reputation quadrant for RFI payloads for example (see below) we can see that one third of the attack payloads contribute 76% of attack traffic across the entire set of applications. 

This clearly shows that fast identification of some attack agents can have a meaningful contribution to all members of the community. Moreover, if we look at the progress chart (below) of one specific attack source (among many) that was identified as persistent SQL injection source across multiple applications, we can see a pattern at which the source is simultaneously attacking only a single target, however it persistently increases its effect on the community over time by hoping from one target to another.

All in all the contribution made by our work is twofold: quantify the real value of applying cyber security information sharing to the web application domain and promote the idea of automatically producing actionable intelligence from the data. You are all invited to view the full report on this Link.

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

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.

Last week I attended an OWASP conference in Israel and participated in a panel about WAFEC. This panel is part of the currently ongoing effort to generate the second version of the WAF evaluation criteria standard. The panel gave me an opportunity to express my major concern about WAF evaluation today – the lack of measuring tools and in particular the continuous disregard towards measuring false positives.

I've already expressed these concerns in the last OWASP US conference where I presented a tool that might help the community overcome these issues.  The tool called WAF Testing Framework (WTF) is easily configurable with traffic samples that represent attacks (in a stateful manner) and good traffic. It then communicates according to this configuration with a bundled web application, assuming a WAF is installed in the way. The tool is able to measure the response of the WAF to each one of the requests and display a chart that includes information on False Negatives as well as False Positives.

We've decided to make this tool available to the community as open source. Initially it is available on our site Here. We will probably open an open source project for it on one of the standard repositories soon.

Imperva CTO Amichai Shulman:

Let me start by saying that I’m not a big fan of back and forth argumentative discussions taking place in the blogosphere. However, the religious rage that erupted over the past couple of weeks with respect to our paper, Assessing the Effectiveness of Antivirus Solutions, compels me to provide some response.

Trying to avoid dragging the reader through a lengthy text full of complex arguments I’ll try to take this backwards (kind of the “Backwards Episode” from Seinfeld). The bottom line is in fact that many people have questioned the core aspects of our research: choice of malware samples and method of sample evaluation. However, even among those who have questioned our methodology, there seems to be a consensus around our conclusions – that standard AV solutions have reached the point of diminishing returns and organizations must shift their investments towards other solutions that protect organizations from the effects of infection. I have to assume that if our methodology leads us in a logical way to conclusions that are so widely acceptable, it can’t be all that wrong.

Criticism #1:  Sampling
The first part of the criticism targeted our choice of malware samples. Let me again put forward the bottom line – our critics basically claim that our results are so different than theirs because the method we used to collect the samples is incorrect. Let me put this in different words – if attackers choose malware the way AV vendors instruct them to, detection rates become blissful. If attackers choose malware in a different manner, you’re toast.

Poor sampling would be a fair argument to make if we used some mysterious technique for collecting malware that can only be applied by high end criminal gangs. That is, of course, not the case. We used Google searches with terms that get us close to sporadic malware repositories in publicly accessible web pages. We salted that with some links we obtained through sporadic searches in soft-core hacker forums.  We did focus on Russian language forums, but I do not believe that this is controversial.  Meanwhile, the “cream of the crop” was supplied by some links we took from traffic obtained through anonymous proxies. All this collection work was done by unbiased people, those who are NOT in the business of hacking nor employed by antivirus companies.

Moreover if we inspect the claim made by antivirus vendors with respect to what is the “right” set of malware samples, it actually supports our finding. They claim that if you take the sample size they are dealing with – 100K per day, they achieve higher than 90% detection (98% according to one report). That is – they miss 2,000 malware samples out of 100K. How hard do you think it is for an attacker (and I intentionally did not add the term “skilled”) to get his hands on a couple of those 2,000 undetected samples? I should add that all the samples that we included in our statistics—out of the samples that we’ve collected and tested—are those that were eventually detected by a large enough sample of AV products, and that none of them was a brand new malicious code – rather they were all variations and instances of existing malware.

Criticism #2:  Using VirusTotal
The second part of the criticism touches on our use of VirusTotal.com (VT) as a tool for conducting an experiment related to AV effectiveness. We recognize the limitations of using VT, and described those limitations in our paper.  However, bottom line first – we are not the first one to publish comparative studies of AV efficiency or to publish some analysis of AV efficiency based on VT. We drew explicit conclusions that are not put in technical terms but in plain business terms – organizations should start shifting their budgets to other solutions for the malware infection problem.

The first and foremost statement made by critics is “you should not have used VT because they say so." Again, here’s the bottom line – we have used VT in a prudent and polite way. We did not use undocumented features, we did not subvert APIs and we did not feed it with data with the purpose of subverting results of AV vendor decisions (which is an interesting experiment on its own). So basically, our wrongdoing with respect to VT is the way we interpreted the results and the conclusions we drew from them – going against this has no other term but “thought police”. This is of course before mentioning the fact that various recent reports and publications have been using VT for the same purpose (including Brian Krebs). I know that VT do not claim or pertain to be an anti-malware detection tool and that VT is not intended to be used as an AV replacement. However, they cannot claim to only be a collection tool for the AV industry with results provided per sample being completely meaningless. I must add that having an upload / get results API further disproves that claim. I deeply regret being dragged into this debate with VT since I truly value their role in the anti-malware community and have the utmost respect to their contribution to improvements of AV detection techniques and malware research.

One of the most adamant arguments against the validity of VT as a measurement for effectiveness is that it uses the command-line version of AV products and that configuration may not be ideal. I’d like to quote:

• VirusTotal uses command-line versions: that also affects execution context, which may mean that a product fails to detect something it would detect in a more realistic context.
• It uses the parameters that AV vendors indicate: if you think of this as a (pseudo)test, then consider that you’re testing vendor philosophy in terms of default configurations, not objective performance.
• Some products are targeted for the gateway: gateway products are likely to be configured according to very different presumptions to those that govern desktop product configuration.
• Some of the heuristic parameters employed are very sensitive, not to mention paranoid.

Regarding the first point, I personally do appreciate the potential difference between a command-line version of an AV tool and other deployed versions. However, in terms of signatures and reputation heuristics I don’t really get it. I’d love to see AV vendors explain that difference in details and in particular pointing out which types of malware are not detected by their command line version that are detected by their other version and why. I am certainly willing to accept that our results would have been somewhat different if tested an actually installed version of the product that is not the command-line version. However, I do think that they are a good approximation. If AV vendors claim that this is by far untrue I’d really like to see the figures. Is the command-line version 10%, 50% or 90% less effective than the product?

I don’t see the point in the second argument. Are they really claiming that VT configuration is not good because it is the recommended vendor configuration?

As for the third argument, this is really puzzling. According to this, we should have experienced a high ratio of false positives, rather than the high ratio of false negatives that we have observed in practice.

Quoting again:

VirusTotal is self-described as a TOOL, not a SOLUTION: it’s a highly collaborative enterprise, allowing the industry and users to help each other. As with any other tool (especially other public multi-scanner sites), it’s better suited to some contexts than others. It can be used for useful research or can be misused for purposes for which it was never intended, and the reader must have a minimum of knowledge and understanding to interpret the results correctly. With tools that are less impartial in origin, and/or less comprehensively documented, the risk of misunderstanding and misuse is even greater.

Again, the writer agrees that VT is indeed a tool that can be used for research as long as results are correctly interpreted. Yes, it is possible that we’ve misinterpreted the results. If that is your opinion then argue with our interpretation of the results. Unfortunately most critics chose not to do so, but rather argued that we used the wrong tools.

Epilogue
I could continue, however, I think that I’ve addressed the main criticism against our work and shown that most of it is of immaterial nature. I would like to see a livelier debate around our interpretation of the results and the conclusion – AV solutions attempting to prevent infection have reached a point of diminishing returns and are thus providing attackers with a large enough window of opportunity time-wise and device-wise to penetrate organizations and remain undetected for extremely long periods. It does not mean that we have to throw AV solutions away, it just means that we need to start shifting some of the money towards solutions that detect and prevent the effects of infection.

What caused the breach? No one stated explicitly but as some may suspect, it was probably a SQL injection attack.  What are the indications?

First, according to official statements attacker took off with identity related information and not, for example, details of tax reports (which may be far more interesting) or bank account numbers (same here).

Second, look at the following statement:

On Oct. 16, Mandiant confirmed that in early September, unknown hackers "probed" agency systems, and sometime in the middle of the month, they were able to access the data that was stolen. On Oct. 16, the vulnerability that permitted the intrusion was closed.

Assuming that the timeline described in SC Magazine article is correct, it took Mandiant less than a day to figure out the attack and the dates, which indicates that they immediately went for the web server native logs and looked for SQL injection patterns. 

Third, we can rule out "insecure object reference" as a culprit since credit card information was stolen partly in encrypted format and partly unencrypted.  This indicates that the information was not taken from an HTML display but from the database. 

Sadly, there is some misinformation taking place.  Notice this statement by one reporter, “In August 2011, a group of hackers used Google to steal 43,000 Social Security numbers from faculty, staff and students of Yale University, due to an unprotected FTP server.”  The attackers didn’t use Google to steal information.  Rather, the attackers used Google to find out that the server was holding sensitive information.

Banks have been asked to step up their DDoS protection.

The request, however, is mostly CYA. Take, for example, the call to check for vulnerabilities--which has nothing to do with DDoS attacks. I think that generally this is missing the point. In particular, it seems that the latest DDoS attacks were very massive and thus are hard to sustain over time by anyone that is not government sponsored.

In this case I would expect national authorities to be the ones to take steps against it rather than individual corporations. In general, I think that attacks of such magnitude should definitely be handled by authorities rather than by individuals. It makes sense to set up regulations for building a house that won't fall down due to a rainstorm. It does not make sense to expect individuals to build dams for the case of a Tsunami.

A recent article describes an apparently serious FBI investigation.   The article teaches an important lesson.  In this case, the FBI wasted resources on matters of relevant little importance because they can get results fast while a huge amount of more serious data and intellectual property theft related crimes go unnoticed.

When looking at quotes from the affidavit, provided by a Simplicty EX-EMPLOYEE (!) he describes what looks like a perfectly legitimate exploration of public resources. He describes how he was INSTRUCTED to look for PUBLICLY available resources by typing legitimate resource names in the address bar. Next, the FBI claims that someone from within Simplicity’s network (or an employee of Simplicity) accessed the login form of Maxient clients.  Really?  They don’t even claim that someone tried to brute force the form, just accessed it! There is only a brief mention of a claim that Simplicity attempted SQL injection attack against Maxient’s application (which is indeed an illegal activity). Again, the claim is very general in terms that an IP address that belong to Simplicity was behind this activity.

Now my question is this: We see on a daily basis web attacks that are on a far larger scale for each there’s a far more collection of hard evidence in terms of intent and potential risk. Why is the FBI investing so many resources in this particular one? I think that the key to understanding this is the following FBI statement:

On Nov. 4, 2011, a cooperating witness who formerly had been employed by Symplicity for approximately five years provided information to the FBI concerning the conduct of Ariel Friedler, the Chief Executive Officer of Symplicity.

Someone, it seems, may have approached the FBI and pointed the finger at an alleged culprit and detailed the method of operation. Not surprisingly, that someone (by their own testimony) was actually part of the operation. At that point, the FBI together with the alleged victim of this criminal activity, who was completely unaware of this EXTREMELY unsophisticated attack, made the effort to produce audit trail evidence (which I do believe to be genuine) going back TWO YEARS showing traces of this crime.  Notice that they were not able to produce ANY data that indicates actual penetration into the application or organization or any actual illegal access to accounts.

From this point of view, it looks like a case of disgruntled employee, colluding with a competitor of Simplicity to inflict a short term or even long term damage to Simplicity’s business.  How is this for a new twist on the “insider threat” attack vector?

As stated by another quote from the article: “While the FBI's search warrant doesn't put any of Simplicity's current contracts at risk, the vendor could face suspension or be banned from future federal contracts based on the issuance of the search warrant.”

Do I believe that Simplicity people were scanning competitor site for competitive intelligence? Yes I do. Do I believe that someone from inside Simplicity attempted SQL injection against a competitor site. Yes I do. Could that someone be the same employee who reported the entire story to the FBI? Yes he could have been that someone. Do I understand why FBI are going after this case with so much rigor? No I don’t. I’d be surprised if the investigation eventually ends up with shocking discoveries about a wide network of sophisticated industrial espionage, or even of a successful breach into competitor servers. Until that happens, I think there are more pressing cyber-crime issues to go after.

Oracle’s latest critical patch update (CPU) went live today.

Overall, this is a fairly consistent release:  80 overall patches with 4 database vulnerabilities.  Likewise, the same volume of MySQL vulnerabilities is consistent with previous releases.  Some observations:

• The database vulnerabilities are about denial of service, probably around the Oracle Listener component which helps users communicate with the database remotely.  Interestingly, for three of these database vulnerabilities all you need is network access, nothing more.  This component has been around for 25 years—yet very serious issues persist.  It emphasizes the complexity of software and the need for security outside of the code base as its written.  This highlights why enterprises need a security solution on top of what comes with the database itself.
• Fourteen of the patches were from an acquired from a company called Stellant.  This highlights the security issues with mergers and acquisitions—which were echoed with the Yahoo! Voices and Instagram-Facebook security issues.
• The biggest vulnerability?  A JRocket issue that was fixed recently with other Java vulnerabilities.

This patch continues to show how big companies with a wide product line struggle to find the resources to keep all their products up to speed with security fixes and how complex software created by a series of mergers and acquisitions drives the need for external security that does not rely on the code itself.