Anonymous can seemingly attack any website at will, and deface the content, and steal data. Why was Bart attacked? In response to Bart blocking cell phone access last week to prevent a protest at one of their stations. So this hack is an extension of free speech or simple theft and vandalism? Either way, just another example of how easy Web applications are to damage and exploit because they are not protected by any type of security.
Also an interesting quote from anonymous in this article from the SFGate.
BART “stored their members’ information with virtually no security,” the hackers wrote. “Any 8-year-old with an Internet connection could have done what we did to find it. On top of that, none of the info, including the passwords, was encrypted.”
Sony’s woes continue as web properties of Sony’s and their affiliates continue to succumb to attackers. The total body count thus far comes to at least 7; with the last few being Sony’s sites in Canada, Greece, and Thailand.
It would seem that the success of the initial attacks might have encouraged others to try their luck on other Sony web properties. The impetus for this might be that if Sony’s Playstation Network can be that susceptible to an attack, some hackers might wonder what else might be up for grabs. It could very well be that Sony utilized the same approach to application development and thus suffer from the same Achilles’ heel elsewhere, or that they may not have a sufficient security practice in place to thwart attacks. Beyond this, another possible weakness that many organization suffer as a consequence of doing business is that new improvements are often times stacked on top of pre-existing older code, which can be like stacking new bricks on an old house over time, the other portion then to fail under stress and weight of the newer layers. This is further complicated by the fact that employees (i.e., developers) do flow in and out of an organization; so when developers leave, others that fill their place and assume responsibility for their code might not necessarily be aware of existing underlying issues or write code in a consistent or secure manner, which leaves room for weaknesses.
The scary truth is that at the end of the day, Sony is not unique in the issues they face. The challenge is there for almost every company out there for the same reasons above.
Mykonos Software’s Chief architect discusses the Sony PlayStation hack with PC World.
Sony’s PlayStation Network has been hacked, resulting in a the theft of critical customer data such as username, passwords, and credit card numbers. The stolen information in turn can be utilized to further victimized affected customers on an individual level. For example, as many people tend to stick with the same user name and password, an attacker can then use this information to log into other online accounts that the user might have signed up to such as with a bank.
This is not the first time that Sony has been compromised, as it was also the victim of an SQL injection attack back in 2008. Though the consequences of the most recent attack is the most severe give the amount of sensitive data stolen, and the potential number of customers that might fall further victim to subsequent fraud and theft activities as a result.
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.
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.
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.