Jan 19

The arrest of two hackers seems to indicate that the days of hacking for fun are very much history. The Wall Street Journal reports the arrests, stating that AT&T acknowledged in June that a flaw in its website made it possible for iPad users’ email addresses to be revealed and said it had fixed the problem. If AT&T and all its resources can be the victim of web application abuse, then what chance do companies with less resources have?

Now the next question is were the alleged hackers white hat, black hat or somewhere in between? SC Magazine has a strong quote:

U.S. Attorney Paul Fishman said in a statement said that other researchers should think twice before using their technical skills for illegal purposes.

“Hacking is not a competitive sport, and security breaches are not a game,” U.S. Attorney Paul Fishman said in a statement. “Those who use technological expertise for malicious purposes take note: Your activities in cyberspace can have serious consequences for you in the real world.”

Tagged with:
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:
Sep 29

A report released by McAfee has put a number on the size of the financial problem from web application abuse -  in this case it’s called ‘Web 2.0 breaches’. And that number is $1.1Billion.  Over 60% of respondents reported losses of $2Million from their business. Now that is a significant problem. The interesting fact is that 79% of the respondents have increased firewall protection since introducing Web applications into their business. Looks like all the firewall protection is missing $2Million worth of abuse. How big does this financial impact need to be before business people people start questioning the nature of security around web applications? And the final interesting part is that only 40% of businesses had budget allocated to securing Web 2.0 applications. This problem is not fully understood as a business problem. The scale of the problem may be much larger. It’s not often that you get to wonder is $1.1Billion in losses just the tip of the iceberg?

Tagged with:
Sep 24

We all have an idea of what sites we think are safe: Twitter, Facebook, linkedin – they’re safe.  We expect to be able to visit them without risking infection. Of course, if you visit porn or piracy sites, you get what you get. These kinds of incidents redraw those lines. They make users re-think which sites they trust.

This week’s incident was definitely a wake-up, especially for the really large online properties like Twitter. And it’s a big responsibility – if Twitter becomes a hub for malware, that’s going to hurt a lot of people. They obviously know their stuff, and have implemented filters against obvious XSS attacks. But of course, those filters are going to fail – you have thousands of smart people out there looking at your code as much as they please. When they figure out how the filters work, they can craft the attack to that. That’s what happened here.

It points to the fact that Twitter and other large online properties need better approaches to preventing this kind of abuse. That vulnerability was hard to find – someone had to probe that input over and over again to figure out precisely what it would do under very specific circumstances. They may even have written a program to do it for them. Could Twitter get an alert on that kind of behavior, and manage it?

The Twitter attack this week could have been a lot worse. A devastating payload could have been delivered that would have caused catastrophic problems for regular users worldwide. That is why it’s imperative that companies look at ways to protect web applications from hackers who are increasingly trying to find holes.

Tagged with:
Sep 17

Here’s an article about a mass attack that recently hit about a million pages, including a couple on apple.com.

It’s the latest in a wave of automated SQL injection attacks that compromise Web site databases and inject a hidden iframe into Web pages – the iframe loads malware from a third party domain, compromising the sites’ users.

Secure development experts cluck at attacks like this – SQL injection takes advantage of insufficient input validation in application code, a well understood developer error. It can be stamped out over time, but it’s still a big problem today. These attackers likely found a SQL injection vulnerability in a commonly used piece of server software, tailored a single-request attack for it, and sucker-punched millions of sites at once to see which ones would fall. It’s hard to defend against that.

It’s also interesting that input filtering at the gateway couldn’t really block this. The SQL was heavily encoded. Signature-based firewalls can’t reliably block this kind of malicious request without blocking many valid requests as well.

So what can be done? Lots. First, a gateway can be a lot more sophisticated about how it checks application input. A broad signature match may not be enough evidence to block a request, but it is a clear indicator that the request is suspicious. Delaying the request and performing additional analysis probably makes sense. It may slow down a small set of valid (but unusual) requests, but it will do a much better job of identifying an injection attack reliably.

Second, SQL injection isn’t really the end, just the means. If you can’t always prevent a SQL injection attack, you can detect that one has taken place and respond to it quickly. The sudden existence of an iframe linking to an unknown domain in your pages is something you want to know about right away. You also probably want to strip it out until you can learn more. A gateway that looks at HTTP responses in the right context can provide that visibility.

Tagged with:
Sep 15

Kelly Jackson Higgins from Dark Reading wrote an interesting article titled Accepting The Inevitability Of Attack.

The crucial idea that security involves three different components of prevention, detection and response is important for understanding next generation security and particularly Web application abuse. Traditional security methods have focused primarily on prevention – from implementing secure development lifecycles, pre-and post development code scans and blocking traffic using Web Application Firewalls. But what of detection and response? Detecting a malicious user of your web application in real-time before the damage is done is more valuable to many of today’s on-line companies. And how valuable is a response to that malicious user in order to protect the business and make sure a future attack doesn’t affect a normal user? It’s not just companies that are affected by Web abuse – normal paying users of the site area also affected by poor performance of Web applications.

Tagged with:
Jul 09

Mykonos Software’s Director of Product Management, Al Huizenga presented at the Cornerstones of Trust event in Silicon Valley. The event held by ISSA (Silicon Valley and San Francisco chapters) and Infragard provided a fascinating array of topics and security perspectives.

Al’s presentation to IT Security professionals was titled “Pro-actively Managing web Application Abuse” and was included in the track Proactive Defense: Technologies to Overcome Hidden Threats.

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:
Feb 24

Mykonos has kept its latest project under wraps but the launch is looming. Next week we launch our new product – called the Mykonos Security Appliance. The launch will be at the RSA conference in San Francisco on March 1, 2010. The product is unique in that it helps organizations gain intelligence about hackers who attack their Web applications, and also allows them to respond in real-time with counter-measures.

The product complements our other product, the Mykonos Framework, which helps build new web applications more securely at the code-level. The Mykonos Security Appliance now helps secure the existing legacy Web applications that are already in use.

Mykonos grew out of the team’s experience building and securing Bluetie, one of the largest Web applications in the world. The team learned that beyond Web application firewalls, which are difficult to implement accurately and only offer point-in-time reporting, there are no real-time code-level security solutions in the market.

Mykonos started with building a Framework that helps you build secure Web applications. But next week, Web application security will gain intelligence with the release of the Mykonos Securty Appliance.

Tagged with:
preload preload preload