In the past, information leakage conjured images of securing data from physical theft (remember the alleged FBI laptop?) but thanks to the web, organizations need to secure information from growing “search giants”. In short, data leakage has taken on a whole new meaning in the Google age.

The causes of data leakage range from simple misconfiguration or improper classification of data, which makes it possible for Web servers to publish private and/or sensitive information, to users unwittingly (or not) storing sensitive data where they shouldn’t, Even best business practices such as site scraping -- a known method for gathering competitive intelligence in which company A automatically reads company B’s website for available data like price tables, and uses it to cut its own prices and remain on top – can lead to leakage of information.

Search Engines

By their very nature, search engines are the Internet’s biggest and most public Indexers. Search engines analyze websites, indexing them for the benefit of everyone who has ever done an Internet search. One urban legend even states that Google has a complete copy of the entire public Internet on file for data mining and analysis purposes.

As consumers and users of the Internet, we like to believe that most organizations do their best to remove sensitive information from their websites, FTP sites and other front facing business applications, As it turns out, however, this is not always the case.

Google Tables Search

Google has always been a pioneer of search algorithms, search visibility and advanced indexing, remaining one step ahead of other search engines, and introducing news ways to tag images by context, and even FTP sites for content. Their recently added Table Search capabilities, however, really brings to surface the idea of impact of data leakage in an indexed world.

This is not to say that Google is causing data leakage, but abilities like “Indexed FTP”,”Sesrch by image”, and now “Table Search” offer new ways to discover and extract data, which would otherwise have remained undiscovered.

Here’s one scary example (you can think of other interesting tables: PII, salaries,CC,…)

We used: http://research.google.com/tables?hl=en&q=username+password

Which is a structured representation of -

What is the Security takeaway?

The takeaway here is that Web security is more important now than ever before. Obviously, it doesn’t make sense to block Google from indexing your site (a business driver), but you should be aware of what content you are allowing access to, and who is accessing it.

Companies should:

1. Implement web application security to mitigate hacker risk.
2. Validate the content that is accessible via your web servers on a regular basis and/or implement policies to check for outgoing data.
3. Implement policies to mitigate Bots that may scrape your website for available content.

The bottom line is that no one really wants to block Google from indexing your website, however controlling the content that your website serves is important. Organizations should note that once content is up there, the “search giants” will index it and with ever-evolving mechanisms it will become easier to get around leaked information.

With the rise of blogs, forums, online magazines, e-commerce, and corporate websites, many organizations are turning to Content Management Systems (CMS), such as Joomla or SharePoint, to create rich websites. CMSs simplify website delivery - but they also expose your organization to a new set of vulnerabilities.

Join Barry Shteiman, Imperva Sr. Security Strategist, to see how malicious hackers exploit vulnerabilities found in popular Content Management Systems to systematically identify and attack unsuspecting organizations.

Presenter: Barry Shteiman, Sr. Security Strategist, Imperva

Date: Wednesday, June 26, 2013

Time: 11:00 AM PDT | 2:00 PM EDT

Register Now

* The blog was updated on the 5/20/2013 to make corrections with respect to the target of the analyzed hacked server screenshot  *

Yesterday, EC Council was reported to have been compromised by a hacker called “Godzilla”. based on published materials in seems that the hacker got access to training course material of several certification programs.

This is not the first time that EC council related sites have been reported to be hacked. Two years ago hackers breached the academy site of the EC Council eccouncilacademy.org. here is the analysis of the EC council academy  hack:   

Looking into the published content by the hacker analyzing the screenshot from shows that the server was hacked by the upload of the WSO web shell code.

The malicious shell was probably uploaded due to an exploit of a known vulnerability in the Joomla CMS (Content Management System) used by the site – judging by the file date in the screenshot the system has not been updated since 2010.

What is the takeaway here?

While we can take the provocative approach of looking into a company that its revenue is mostly based on teaching professionals about security and gets hacked, lets be honest – this can happen to any company and history has proved this point valid. In this case, we would rather show the interesting direction around CMS exploitation becoming more and more popular.

The CMS Exploitation vector of attack is very common and in fact a simple search on one specific flavor (Joomla) resulted in 629 CVEs. Thousands exist in the CVE database and hundreds exist in 0day databases.

Why does this matter?

Businesses rely on 3^rd party software and platforms to conduct their online business, and it is very common to use a CMS such as Joomla or similar and even Sharepoint to simplify delivering a rich website. However by doing so the website is exposed to vulnerabilities found within that CMS.

This brings up an interesting playfield for hackers, which can use Dork techniques and others to fingerprint many websites who use the specific CMS, easily locate many targets and exploit them with either a known (if the system is not up to date as it seems to have been the case here) or a 0day exploit, and have lots of surface covered.

Here is an example of a search term that looks for a specific function in a known CMS which is known to be vulnerable, in order to identify potential targets, the result is astounding. ~263,000 potential targets.

What can an organization do to protect itself?

This hack could have been probably prevented by either constantly patching of all the 3^rd party code of the application and/or by implementing a web application firewall in front of the application.

Where can I learn more?

Going back to our HII report from January (“Lessons learned from the Yahoo hack”). We have shown how third party code may contain vulnerabilities and security holes that could result in a hack, this is of course not the same case, as the HII spoken of talks about a 3^rd party service that got compromised, however the security implications are the same.

 

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.

 

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.

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.

Today, on the last day of RSA2013, InformationWeek has published an article that analyzes the security spend of companies vs the problems that they need to tackle. While referencing OWASP Top 10 Threats, they cover some of the more modern vectors of attack, focusing mainly on SQL Injection.

To quote our CTO, Amichai Shulman, “SQL Injection should have died years ago. Sadly, it didn’t.” SQL injection is one of the biggest threats and easiest vectors for an attacker to steal data and compromise an organization. Not only that, it has become industrialized, with tools like Havij,  SQLmap and others automating the attack and “dumbing it down” to make the it easier to approach by non-experts.

Today, even in the largest organizations, CIO’s still focus spending on fixing problems from the past: viruses and network threats that used to be acute. What is interesting is that companies did so well in spending in the right place in the past, and putting the right controls around their assets to fix the old problems, that the problem has moved. Hackers are now lurking in new places. It’s a classic example of “win the battle and lose the war.”

Nowdays, hackers are all about data and how to get it for profit. When that is the case, you should always expect them to look for the weakest point in your organization, because easy money is the best kind of money. SQL Injection is an easy way to get data.

What should you I do ?

• Dork yourself, check what SQL Injection really is and what is your threat.
• Check your access control, is your organization dealing with SQL Injection?
• Verify that you evaluate your online assets and applications to make sure that you are safe
• Regularly schedule “clean ups” to remove nasty bits.
• Put proper Web Application security controls such as Web Application Firewalls in place.

On January 29^th we released our Hacker Intelligence Initiative Report (HII) which covered the Yahoo hack via third party code that was compromised via a cloud partnership. In the HII we raised the problem that organizations have when they include third party alliance software or service within their own offering.

The cloud opens opportunities for businesses to grow using third party platforms, and embedding their services within their own platforms saving time, money and stepping up their offering.

Yesterday, In a Blog post by Zendesk they disclose the fact that they have been compromised and that the data of their customers may have leaked. Some of their customers are Tumblr, Twitter, Pinterest as revealed by Darkreading. This means that if you are a user of these companies, your data might have been compromised.

What should companies do ?

When a company builds its security model it usually does not take into account elements that are not in their control, which creates the security hole.

Companies should:

• Implement policies both on the legal and technical aspects to control data access and data usage.
• Require third party applications to accept your security policies and put proper controls in place
• Monitor.

We are not saying that you should avoid third parties. These services are pure business enablers and help your organization drive revenue with less cost to it. But when you do that, wear your security hat on!