Jan 21

The legality of responding to malicious attacks was recently the conversation at BlackHat DC prompting Network World to pen an article intriguingly titled Is retaliation the answer to cyber attacks?. Maybe the legality is more easily defined if we split the types of counter-measures in two. The first type of response is an “aggressive” retaliation, similar to what the Stuxnet is supposed to have achieved against Iran’s nuclear infrastructure. Clearly there are legal ramifications for aggressively damaging property and corporations are not going to require this type of retaliation. The second type of response is a “protective” retaliation such as blocking the active connection or breaking the web application for that identified hacker. Or how about sending the hacker a warning? Is that a counter-measure that is too aggressive? Most companies would clearly see the difference and are comfortable with a more proactive protective response.

Jan 12

Dark Reading recently wrote about the weaknesses of firewalls and illustrate the problems of firewall proliferation in a very interesting way. There are four main problems:

  • Rules Management: Firewalls require rules and the configuration of these rules are time-consuming and ever-changing. Changing one rule may affect another already configured. Rules management is a burden on IT Security staff and increasingly the reason firewalls don’t work is because they are configured incorrectly.
  • Firewall Proliferation and Sprawl: More firewalls that reside within an enterprise require more rules to configure resulting in either more configuration errors or the likelihood that the firewall is configured to provide the least amount of possible security, possibly even letting all traffic through.
  • The Security Myth of Firewalls: Audits for PCI or SOX compliance are more likely to uncover a mis-configured firewall than either a hacker or the overworked IT security department charged with managing the device.
  • Application Ignorance: The majority of firewalls are ignorant about what they are protecting and do not understand what is the correct behavior of a normal user. Application-aware firewalls will become more important.

And another article lauds the three major tenets of PCI requirements. Companies holding customer data should:

  • Use a Web application firewall
  • Develop software using secure practices
  • And focus on whitelisting technologies for key servers.

With the Verizon Data Breach Report stating that 94% of compromised records involved a flaw in a web application, something is wrong. If firewalls are not being configured correctly and almost all records are stolen using a web application flaw, why is it a PCI requirement to use a Web application firewall?

Is a proactive defensive solution, protecting web applications that is application aware, and doesn’t require signatures, or cumbersome rules management, the next key solution?

Dec 16

We’ve been doing a lot of research on how to better detect threats to Web sites, and how to re-identify and track them over time. One key consideration is: How far can you push the standard ‘cookie’ mechanism as a way to track and manage users with a demonstrable history of abuse and malicious behavior?

So when Samy Kamkar, author of the infamous MySpace worm, recently released a new open source project called ‘evercookie’, it caught our attention. The goal of the project is to create a persistent tracking cookie that is extremely difficult to remove. Unlike traditional cookies, which can be cleared easily using standard browser privacy controls, the evercookie is designed to evade most purging tactics. Once tagged by the evercookie script, you must go through a long series of difficult steps to eliminate all traces of the unique identifier. In some cases, this requires additional software that average users don’t typically have. Missing even a single step will cause the cookie data to repeatedly propagate throughout the browser environment, forcing you to restart the purging process.

Sounds cool, so we checked it out. We found that while evercookie is still in an early stage and there’s definitely room for improvement, there are some pretty big problems with this overall approach.

The first is footprint. evercookie has a relatively large footprint on the client, making it fairly easy to detect. Some examples:

  • The “evercookie” token is ubiquitous in the JavaScript source and filenames.
  • The data points maintained by lengthy expiration dates, such as cookies and cache, use hard-coded values. By simply checking to see if a website has issued a cookie that expires on “Tue, 31 Dec 2030 00:00:00 UTC”, you can confirm the presence of an unedited copy of the evercookie code.
  • You could create a more extensive detection mechanism by testing a collection of JavaScript tokens that even experienced developers are unlikely to edit, including “localStorage”, “INSERT OR REPLACE”, “silverlight”, and “#userData”, to name a few.

A developer integrating evercookie code could reduce the footprint by adding a layer of strong and thorough obfuscation, but you can’t get rid of it completely.

The second problem is that evercookie exposes a site to new attack vectors. For example, the use of the “window.name” JavaScript variable enables cross-domain data leakage. This could be a serious issue depending on how the data in the cookie is actually being used. The general problem arises because any 3rd party, unrelated website can obtain the cookie value and impersonate the visiting user. The added trust given to the evercookie, because it is so difficult to manipulate, may further exacerbate this issue.

Despite its shortcomings, evercookie has kicked off another round of debate about user privacy. Most browsers already support private browsing mode, which attempts to sandbox the all browsing activity and prevent sites from using cookies for user tracking. Unfortunately, not everything can be easily and effectively sandboxed, and evercookie takes full advantage of that fact (Samy admits that he has yet to conquer Safari’s private browsing mode, but give him time). In response, Anonymizer has announced a new Firefox plugin called “Nevercookie” (touché!). When used in private browsing mode, Anonymizer says Nevercookie will effectively purge an evercookie…

And the arms race continues. Browser and plugin vendors will continue to add protective measures that help users avoid tracking, and developers will continue to create code and tactics for evading those measures. It’s also important to note that Samy hasn’t invented anything new here – he’s just researched what’s possible with today’s Web browsers. And not every security researcher is as forthcoming as he is. It’s quite conceivable that Web applications in the wild are already using many similar tracking techniques.

The bottom line: No one can be certain whether their activities are actually being tracked and correlated across many visits to a site, or possibly to multiple sites. Technically, user tracking on the Web is a reality, and it’s not going away. The debate, accordingly, should shift to when and under which circumstances user tracking is appropriate.

Tagged with:
Nov 08

Below is a copy of the slides used in our Webinar titled ‘How Web Applications are Attacked’.

To watch the fascinating content, go to this page and complete the form to view the Webinar file at your leisure.

Oct 06

Join us for our complimentary Webinar. Register Here.

How Web Applications are Attacked: Understanding and Responding to the Five Phases of Web Application Abuse

Wednesday November 3, 2010 11am PST (2pm EST)

Web applications have created a massive attack surface for potential attackers. Because of this, the majority of attacks begin very quietly through a business Web application. This webinar outlines the problem of Web application abuse and how this abuse is used to steal data, money and resources from companies. Understanding the anatomy of an attack is key to selecting the best method of defending against widespread abuse.

Current solutions for securing Web applications rely heavily on signatures to identify and respond to threats. But signatures have become less effective at detecting threats over time, and aren.t sufficient to address the sophisticated abusive behavior that large, publicly exposed Web applications are subject to, including page scraping, logic abuse, malicious automation, phishing, and malware distribution. The key shortcoming is a lack of application context . without any grounding in actual application and user behavior, signature-based solutions can.t avoid flagging many false positives. This makes the information they provide to administrators practically un-actionable.

From this webinar, you will learn:

  • How sophisticated attackers successfully abuse Web applications
  • The five phases of a Web application attack
  • The weaknesses of signature based security
  • How companies respond today
  • A new innovative approach to Web application defense

Register Here.

Tagged with:
Jun 23

When Web applications are the core of your business, protecting them from abuse is crucial. High profile Web applications can provide front-door access to critical data. Sophisticated and organized attackers with deep technology skills are increasingly successful at accessing that data, and the results can be disastrous, from non-compliance, to fraud, to competitive loss.

For example:
»Bank account fraud. Attackers devise and execute phishing scams to highjack customer accounts and perform fraudulent electronic payments
»E-commerce fraud. Attackers make fraudulent purchases, or steal credit card information. This results in a loss of brand credibility, and threatens compliance status with PCI DSS
»Data scraping. For-hire hacking teams establish automated, non-sanctioned calls to business data to power a competitive site or service (e.g. retail pricing, travel bookings)

These problems are getting more severe as attackers become more organized and sophisticated. Traditional approaches to stopping Web attacks that rely on signature based intrusion detection and anti-virus are increasingly ineffective. This is the result of the combination of two factors. First, Web applications are exposed to the public, and easily introspected by the outside world. Attackers can take the time they need to understand how they are coded and which defensive measures are in place, allowing them to avoid being profiled by varying their attacks quickly. Second, the criminal community responsible for Web attacks has evolved into a market of its own, complete with highly productized “command and control” suites for creating and managing bots – armies of compromised computers on the internet that are used to distribute, transform, and obfuscate the attack. These suites are sold online as ready-to-go, do-it-yourself attack kits. The market for these kits is extremely competitive, with market demand driving new features and innovations all the time.

To realize how advanced targeted threats can be disrupted and prevented, you need to clearly understand the nature of those threats.

Tagged with:
preload preload preload