Web Site Security

Internet Rumors Can Be Damaging - Even If Unconfirmed

A woman working at HP sent an email to hundreds of co-workers that a snack made by Osem, one of the largest food manufacturers in Israel and a local subsidiary of Nestle, caused infant death.

This email quickly spread and the result was a 6% drop in Osem's stock in just a few hours.
The email wasn't very sophisticated. It wasn't even remotely true. Still, Osem - one of the largest companies in Israel - had its stock damaged by a completely false email rumor.

Apple's stock goes down when rumors are circulated that Apple's CEO Steve Jobs has had a heart attack. The Apple stock takes a beating every time that rumor surfaces, and that happens regularly.

Stocks going up or down because of rumors is as old as the invention of the stock market. But the Internet makes it easier to fabricate a rumor and have it reach far and wide within hour. Just add one more component and a stock could be driven deeply into the ground: credibility. For maximum credibility, how about planting a confirming statement on the corporate web site!

How Damaging Could A Confirmed Rumor Be?

Imagine if you saw a news item on the corporate web site www.apple.com that actually confirmed the death of Steve Jobs. Imagine if you saw on Osem's web site an admittance of guilt that their snack was indeed poisoning infants. What would happen to their stock then?

Here's the scary part: it is not difficult to do this. Nobody even needs to break in or deface the corporate web site for this to happen. All that is needed are these two things:
1) An unhandled Cross Site Scripting (XSS) vulnerability on the corporate site, and
2) Inclusion of a carefully crafted link to the corporate site in the alarming email, on a social network page or included in a Twitter 'tweet' that takes advantage of the vulnerability

The link in the email will apparently take the alarmed person to the corporate site, but once they 'arrive' they will actually see a page that was created by the attacker and which confirms the alarming content. That link contains the XSS attack. When that link is then forwarded, every other person who uses it will also see this faked page. How far and how fast can such a link be spread? See the two examples at the beginning of this article again.

How Hard Is It To Do XSS?

Not hard at all. In fact, we made a quick proof of concept to the Tel Aviv Stock Exchange (TASE) a few years ago when we planted a false news item using a cross site scripting attack. The reaction from TASE was familiar to any computer security expert who ever reported a XSS vulnerability: "This is not really a problem as there was no change to any page on our site". For something that is "not a problem" they sure fixed it within the hour, though.

We've experienced this same response almost every time our vulnerability scanning service (see http://www.beyondsecurity.com/vulnerability-scanner.html) finds a XSS vulnerability in a fortune 500 corporate or government site. We are often asked to explain why the report presents it as a serious issue. Using cross site scripting we have demonstrated the planting of false financial reports in the 'investors' section, altering news items and in almost all cases we have been met with the reaction: "this is not a real vulnerability" and "how can this really affect me?"

Who's Damaged By A Cross Site Scripting Attack?

Most security researchers opt to explain XSS as an attack that steals cookies from site visitors. The damaged party in this case is 'just' the web site visitor who loses his account and any funds that maybe connected to it (setting aside how attackers may take that stolen account and use further explits to escalate permissions until they end up owning your serrver!).

While loss to the site visitor is a likely outcome, I think there's a greater risk in the alteration of information on a 'trusted' page which could be useful in a phishing attack, or like the examples above, an attack intended to drive stock down that had been sold short.

I'm waiting for the first XSS attack that will tank a big company stock after is has been sold short by the attacker. If you are responsible for the security of your site, make sure your company won't be the one.

I remember a few years back hearing about the blackouts in California (oh yes, the good ol' Enron days). It was quite shocking to hear that major dot-coms were down for hours. Even the "365 Main" facility in San Francisco with its earthquake proof infrastructure lost power, proving that no matter how well equipped, no single location can withstand a big disaster.

Nowadays natural disaster is less and less a real issue for web sites - hurricanes and power failures are not an excuse to stop providing service: Amazon and Google showed that you can reach close to 100% reliability (barring software bugs) by eliminating all physical single points of failure. Today in the 'cloud computing' age, every web site can get Amazon-like reliability without worrying about a power failure in its office in Mountain View or a natural disaster at its co-location farm - and all this for just hundreds of dollars a month.

But as the local disaster problem is solved, there's a new one that may shape the way we think of disaster recovery. Register.com got hit by a massive Distributed Denial of Service (DDoS) attack on its Domain Name System (DNS) servers. This attack will have many casualties - not just Register.com's users who may have their web sites unavailable if they used Register.com's DNS services but also all those hit by the collateral damage. We don't yet have any technical information on how the attack was done, but a DDoS attack is typically 'logical' and not geographical - if your site is somehow 'logically' connected to a site that is being attacked, you will also be DDoS'ed and that won't be nice.

When Blue Security was DDoS'ed a few years ago the attackers decided to take down Blue Security's providers along with everything else hosted there, in all of the provider's geographical locations.

A DDoS attacks the servers wherever in the world they may be. Even if you span your server across multiple physical locations the attack will be done on all of them. No matter how distributed your servers there is always a limit to the number of transactions you can handle in a single second, and once the attacking botnet (a network of software robots, or bots, that run autonomously and automatically) passes this limit, then your services will effectively be denied. You will then have nothing to do but lean back in your chair and wait for the attack to end and count the lost visitors/revenue/reputation with every minute passed.

While cloud computing can save you from Hurricane Katrina, if someone decides to DDoS anyone - even facebook.com - they only need to pay a fee; there is nothing Facebook - even with its massive server infrastructure - can do to stop them.

We simply don't know how to stop a DDoS attack in progress (snake oil solutions aside). The only solution is to raise security awareness with administrators so that they will run sufficient security tests (see www.beyondsecurity.com/vulnerability-scanner.html) and eliminate any botnet code hiding on hundreds of thousands (some say millions) of servers. This will reduce the size of botnets and make DDoS less practical (or more expensive).

Until that happens, I wonder who will be the first to use DDoS to take out a competitor?

Anyone who has ever done serious security research reached the line that separates good from evil. If you are working with phishing emails you get links to bad web sites. If you research security holes you deal with exploits. If you are researching botnets you are up to your neck in sensitive information that was obtained illegally.

I'm sometimes asked if we ever get 'tempted' to cross over. The answer is simple: we may think like criminals and sometimes emulate their work, but it never ever enters our mind to do something malicious. Finding a SQL injection exploit that gives you full access to the database is fun; using this information to steal money or order items for free is light years away from what we do.

But not everyone understands that, and that's scary. A member of THC got pulled over at Heathrow airport by the UK government. The story has a happy ending, but it must have been scary, not to mention frustrating.

My good friend Zvi Gutterman found weaknesses in the Windows and Linux PRNG. Breaking the PRNG has consequences - while top-secret crypto systems will not use the standard Windows or Linux random number generators, who knows if there is a simple Linux based basic communication device used in one of the governments? An applicable weakness in the PRNG may have a serious impact and they might decide that shutting up Zvi is easier than replacing all their units.

If you think the previous paragraph is a paranoid conspiracy theory, lets talk about investigating the links that pop up whenever we deal with botnets, phishing and malware. The police are demonstrating zero tolerance for child porn, usually by arresting anyone who has visited such an illegal web site. How will you explain to your family, when they see you on the 8 o'clock news arrested on charges, that you are not a dangerous criminal and that you had no idea the link you clicked was to a nasty site?

There will be more incidents like the THC one. Security professionals can tell the difference between a proof of concept device to show how vulnerable GSM encryption is and an illegal wiretapping device. But the law officials can't, and often don't seem to care about the difference. Some of the time it's not even law officials: Fyodor had his site shut down to prevent spreading his nmap tool. Dmitry Sklyarov was arrested in Las Vegas for breaking the PDF encryption. In the Fyodor incident the decision was made by godaddy. In the Dmitry Skylarov case it was Adobe who got the court order.

I wouldn't want to see security research being a licensed profession (like a private detective license or a license to carry a firearm) - I've seen brilliant teenagers who think out of the box and find vulnerabilities no one else can, but are not old enough to drive a car. So what else can we do to make sure we hold a 'get out of jail' card?