Tuesday, 13 October 2009

Unwanted Guests

Users who have upgraded to Apple's recently released 10.6 update to OS X, codenamed Snow Leopard, have reported a seemingly rare bug that results in their entire user account, including settings and data, being lost inadvertently. The bug apparently rears its head when a user logs in, either intentionally or unintentionally, to the 'guest' account on their machine. When the user logs out and logs back into their regular user account they receive the nasty surprise that it has been fully reset to the default state for a new account and their data has been lost.

If this bug turns out to be as easy to trigger as it sounds, then the security implications are pretty serious since they effectively translate a short window of physical access to a machine into the ability to do irreparable damage in fairly subtle way. Although reports of the bug appear to have surfaced within days of Snow Leopard's release, Apple has only just now acknowledged the problem.

Until Apple addresses this problem properly, a good first-step defense is to disable the 'guest' account.

CNET has posted tips for avoiding the bug and recovering data if you've fallen prey to it already.
Posted by jwest at 4:04 PM in Vulnerabilities-Breaches

Wednesday, 17 June 2009

Basket Full of Eggs?

With services like Twitter gutting the English language leaving only 140-character shells of real communication, the ability to minimally shorten URLs for sharing has become hugely popular. However, a recent hack against Cligs has shown that URL-shortening services can be a central point of security failure.

URL-shortening services began with href="http://www.tinyurl.com">TinyURL in 2002, whose creator wanted to link to cumbersome newsgroup URLs more easily. Although early exploits against predictable hash values led to some amusing redirects, such as ‘dick’ taking users to www.whitehouse.gov, they were mostly harmless. The greatest security concern to-date has been that shortened URLs introduce an extra level of abstraction between the user and the content they wish to view. We in the security community are fond of instructing users to only visit trusted domains with a reputation for being free of malware and other nasties, but this becomes nearly impossible in the face of multitudes of nearly indistinguishable shortened URLs.

Last weekend, hackers exploited a vulnerability in Cligs, a competitor of TinyURL, to redirect millions of users to a seemingly benign, but certainly unintended, site. Although the motivation for the attack is unclear (some suggest the unusual destination may have been a mistake on the part of an attacker who wanted to redirect users to a malicious site), the implications are dire. Had the site been a launch pad for malware or a phishing attack, the more than 2 million users who were sent there against their will would have little recourse.

From a business perspective this is an interesting example of security becoming a major competitive differentiator. For companies that provide a comparatively generic service like URL shortening, distinguishing oneself from competitors can be challenging. This attack suggests that companies who strive to grow market share without focusing on security run the risk of security becoming the competitive differentiator that drives users to other, more secure, services.

Posted by jwest at 11:52 AM in Vulnerabilities-Breaches

Sunday, 1 February 2009

Google's Security Glitch

How do you take down The Google? They have lots of data centers, gobs of bandwidth, unrivaled peering, and a scary amount of compute power. A DDOS from your pimply nephew's botnet won't get the job done. The one force in the universe able to tackle The Google head on? Google Security! Their list of malicious web sites is so powerful that a single fat finger on a Saturday morning can essentially shut down Google search for the better part of an hour. (If you haven't read the story already, go here.)

This turns out to be an all-too-common failure mode for security mechanisms. If the security is powerful enough to do a good job of protecting you, it's probably powerful enough to do some real damage too. People make mistakes, and so sometimes the whole web gets marked as a purveyor of malware, and sometimes your anti-virus deletes applications like Excel.

And those are only the accidents. The more exciting cases are the ones where attackers turn the security system back on the people it's supposed to protect. My favorite from 2008 was the Maryland high school kids who figured out that they could fake up a license plate with a laser printer, drive by a speed camera, and give a speeding ticket to anyone they chose.

People have long known that locking accounts based on authentication failures can have the same sort of effect: if I don't like you, I can lock you out of your account until customer support opens on Monday morning. If I don't like customer support, I can lock out a few thousand users and sit back and enjoy the chaos.

The moral to the story: security features are just like all of the other features. If you haven't thought through what happens when they go wrong, you're probably in for a surprise. Security features sometimes get a free pass because somebody in the security group dreamed them up, and that's a recipe for trouble.

Technorati Tags:

Posted by bchess at 8:34 PM in Vulnerabilities-Breaches

Tuesday, 27 January 2009

Confickering the Internet

Quite a bit of buzz has formed around a remotely exploitable buffer overflow in the RPC Server service of all modern versions of Microsoft Windows (2000, 2003, XP, Vista, 2008 and pre-beta 7). This vulnerability is the root cause a widespread worm, known as Conficker or Downadup, exploits to spread across Windows machines. This code has been a target time and time again for attackers seeking out remotely exploitable vulnerabilities in Microsoft systems.

As usual, the discussion in the community has been centered on the IT security response, often emphasizing identifying the worm on the network and cleaning infected machines. The justification for this emphasis is that now that Microsoft has found and fixed the bug, the biggest challenge is preventing unpatched machines from remaining or becoming infected. Clearly, this reactive approach is inadequate to protect users, roughly 10 million of whom are already infected with Conficker.

To draw a public health analogy, if Microsoft was better able to vaccinate its software against vulnerabilities like these from the outset, the patch/response cycle would become obsolete. Obviously, we cannot preemptively avoid every vulnerability; bugs in software are a fact of life. However, a strong software security assurance program that integrates security into software at every step in its development lifecycle can dramatically reduce the risk of serious vulnerabilities making their way into production software. Judicious application of the right security processes and technologies are the vaccine that will make worm outbreaks, like polio, a thing of the past. We've made a lot of progress over the last few years, but it's time for the security community and press to shift the balance to spend more time talking about prevention than about treatment.

Technorati Tags:

Posted by jwest at 4:27 PM in Vulnerabilities-Breaches

Wednesday, 21 January 2009

Inside Job?

Heartland Payment Systems said Tuesday that hackers had compromised its computer systems and gained access to customer information related to the roughly 100 million transactions the company processes each month. Although the number of customer records that was compromised hasn't been disclosed yet, this breach is likely to give TJX, who exposed more than 45 million customer credit card numbers to hackers beginning in 2005, a run for its money as the largest breach of credit card data to-date.

The breach, the early signs of which Visa and Mastercard may have identified back in late 2008, was perpetrated using what investigators describe as highly sophiscated malware that specifically targeted Heartland. Since the means by which cyber criminals mounted this attack remain to be seen, it will be interesting to find out if the person or persons responsible were insiders, specifically out to get Heartland, or whether they were working as part of a larger effort.

Although there's no evidence yet this was an inside job, insider threats always pose a serious risk. Never has this risk been more acute than under the current economic conditions. When large groups of employees are fearful about layoffs and other hardships, employers often need to take stock of how they might be exposed if an employee with an axe to grind decided to leave something behind when they leave the company.

A few months ago, the Fortify Security Research Group (SRG) developed a custom rulepack specifically designed to help code auditors look for insider threats in Java web applications. The rulepack is available through Fortify Exchange, which is part of the Premium Content area of the Fortify Customer Portal. Currently, we're testing the rulepack with a group of interested customers to fine tune its detection capabilities and target a broader range of potential attack vectors.

Technorati Tags:

Posted by jwest at 1:53 PM in Vulnerabilities-Breaches

Unexpected XSS Attack Vectors

In FreeBSD and UNIX, characters such as < and > are allowed in file names. As these characters are the main ingredients for a straight forward cross-site scripting (XSS) attack, it is not surprising that filenames can be used to exploit XSS vulnerabilities. An internal audit recently uncovered a vulnerability in the online photo album application Gallery, which allowed to use a specially crafted filename to exploit a XSS vulnerability. For example, uploading a picture with the name <script>alert('hi')</script>somefile.gif could exploit this vulnerability.

But the danger goes even further. Files can be archived in multiple ways, including ZIP, RAR, and other formats and some languages, such as PHP, provide functionality to display the contents of these archives. Therefore, even if it is impossible to upload a file with a malicious name directly, it may still be possible to upload an archive containing files, which in turn may serve as attack vectors. For example, the following zip file will lead to an XSS vulnerability when processed by the code below:
file.zip: (1) <script>alert('hi')</script>somefile.txt (2) ... 
example.php: <?php $zip = new ZipArchive; $name = $_GET['name']; echo "The used zip file is " ; echo $name; $res = $zip->open($name); if ($res == TRUE) {      echo "Name index 0 is ";      echo $zip->getNameIndex(0);      $zip->close(); } else {     echo 'failed, code:' . $res; } ?> 
This exploit is not restricted to Unix-based operating systems either, it suffices to create a valid zip archive containing these filenames. Malicious archives like the one above can be created on a Unix system and later be used to exploit a vulnerability on a different platform. Furthermore, malicious archives can also be created on non-Unix platforms by editing the internal filenames stored in the archive before it is distributed to potential victims.

The moral of the story is don't trust input. Even if a particular source of input has external constraints placed on it, such as the characters supported by a given file system, they might be altered or negated entirely.
Posted by mmadou at 12:52 PM in Vulnerabilities-Breaches

Wednesday, 7 January 2009

Twitter Continues to Be Caught With Their Pants Down

Ok, so Twitter may not be suffering as much as this poor guy, but Twitter should be equally embarrassed. Within the last 30 days, Twitter has had several high profile security incidents: an unintentional direct message leaks, an ongoing phishing attack, and now a hack of at least 33 high-profile accounts. Unfortunately neither Twitter or the reported perpetrators are giving specifics about how the hack was pulled off (I'll gripe about that at some later date), so we can't discuss ways to mitigate and prevent such attacks. However, we can expound on what we do know and why this compromise was potentially catastrophic for Twitter.

So, what happened?

By reading Twitter's own post, we can conclude that some of Twitter's admin functionality were compromised. The admin tool allowed the support team to edit an account's email address. This seems innocuous enough, right? In this age of multiple work, school, and personal email addresses, it's not surprising for a user to forget the address used during registration. Twitter's support tool was created just to handle such a scenario. Unfortunately for the Twitter team, though, they forgot to not only ensure that the admin tool was only accessible by their support staff but that the admin tools were designed with security in mind. Sadly, many companies don't realize that the administrative portions of their applications are prime targets for malicious users. In Twitter's case, the admin tool allowed a malicious user to change the targeted account's email address to an attacker controlled email address. The attacker could then use Twitter's "Forgot Password" link to have a new password emailed to the attacker controlled email address. Using a system's password reset functionality to compromise an account sounds pretty familiar to the Sarah Palin "hack" (and I use the term "hack" lightly) not too long ago.

So, why is this such a big deal?

Fundamentally, Twitter is a communication transport and as such, users not only expect data integrity ("Did what I write actually get communicated?", "Did I receive what was actually written?") but also data authenticity ("Did I receive this message from the real author?"). [Apologies to all the cryptographers out there for the over simplification] While Twitter is limited in their ability to verify the account owner's real-life identity, Twitter *is* responsible for the authenticity of the accounts on their system. Their current solution is the traditional username/password that we're all familiar with. However, if Twitter's administrative tools were compromised (as their own posting alludes to), Twitter failed to provide that authenticity since malicious users were able to change account passwords. While the attack was occurring, Twitter was unable to guaranty the authenticity of the messages being sent out to the millions of followers of the celebrities that were targeted. During those few hours, Twitter essentially ceased to be.

That is why getting security right is so important.

Driven by the adoption of several tech luminaries and jettisoned by the mainstream adoption of a group of high profile celebrities that even your mother would recognize, Twitter has had a meteoric rise within the social-networking field. Being a start-up, can Twitter really afford to be constantly putting out security fires? How do these incidents impact their ability to attract more users? Better yet, what will these incidents do to their user retention? Twitter's "microblogging" service isn't too different from Facebook's status messages. Most of the targeted accounts also have Facebook accounts, a switch of platform would be very low effort for them. Could Twitter go the way of their competitors because security vulnerabilities cause users to lose faith?

Posted by flee at 1:17 AM in Vulnerabilities-Breaches

Thursday, 21 February 2008

Bye-Bye Disk Encryption

Ed Felton and the gang at Princeton have struck again! This time they've figured out how to defeat the disk encryption schemes built into Vista, MacOS X, and others. The attack works because the values held in RAM don't disappear instantly when a computer is switched off. They decay slowly over a period of seconds, and that can be extended to minutes with a little bit of coaxing. That's long enough to boot up a second OS and read out the contents of memory. After that, it's just a matter of extracting the crypto keys, and the game is over. Awesome work. Read about Cold Boot attacks on Encryption Keys.

If there's a lesson to be re-discovered here, I think it's the amazing way we end up building security systems on what seem to be solid ground (as in "computers forget stuff when you turn them off"), and only when it's too late do we find out that our premise was strong enough for trying to explain computers to someone like your old uncle Hugo, but not strong enough to adequately secure your data.

It appears to me that this attack is still too sophisticated for the average thief who steals laptops in coffee shops, but it's plenty easy for the forensics guy down at the police station.

Posted by default at 10:00 PM in Vulnerabilities-Breaches

Tuesday, 29 January 2008

They Set the Wii Free

It appears that a buffer overflow vulnerability in The Legend of Zelda for the Wii, and that’s all hackers need in order to run their own code on the machine. Here’s the scoop.

Pretty soon this will mean game pirating for the Wii without the need to get out your soldering iron. That’s important if you want to get people to steal games in the same casual manner they steal music. Piracy is a big deal for all modern gaming platforms because most of the money comes from software (games) not from hardware.

Apple has run into similar trouble recently. It seems that more than a million iPhones have been unlocked, and I think it’s safe to assume that it’s mostly happening using the simplest mechanism out there, a web site that exploits a buffer overflow in the iPhone. That means Apple is missing out on their cut of the phone subscription going to AT&T, and that has to hurt. The moral to this story is this: if your business relies on the security of your software, you’ve got two choices:

  • Design a system that will be secure even when people discover a few bugs.
  • Make sure you don’t have even a single bug.

Neither of those options is easy, but creating a robust design not nearly as hard as creating a flawless implementation.

Posted by default at 11:49 PM in Vulnerabilities-Breaches