Tuesday, April 28, 2009

Hacking Time's Most Influential People poll

(Creative Commons licensed image courtesy MarilynJane)

Paul Lamere wrote a great post titled "Inside the precision hack" on his MusicMachinery blog outlining the 4chan hack of Time's influence poll. His interview with Zombocom, a 4chan /b/ denizen. The article is worth reading, as it outlines many of the common errors made in online polling applications. In the end, the most influential person is moot...

We see:
  • An easily modified and adapted submission URL
  • A total lack of authentication and validation
  • A lack of parameter control
  • A poorly protected salt once validation and authentication were included
  • A poor IP restriction protocol (each candidate could only be voted on once every 13 seconds...but there were many candidates, and it supported negative votes).
  • A possible work around from systems using an IPv6 stack
  • No banning mechanism
All of these added up into a great opportunity for a dedicated group of people to manipulate the poll. Take a look - Lamere's writeup is great.

Monday, April 13, 2009

LastPass - Answering Security Questions The Right Way

I was recently asked to take a look at LastPass. LastPass is an interesting solution to portable secure passwords - it works as a browser plugin, and works with IE and Firefox on MacOS, Linux, and Windows. It supports one time passwords, central synchronization, and a host of other features.

What impressed me the most, however, was the level of detail that the developers provide in their forum. These former eStara staffers give some great responses, as seen in this forum discussion which is a great example of how to answer questions about a password safe program effectively.

A user asks:

"You say you never receive and you never ask but when I access to your website I do send my password...
This is even more true when I don't have the lastpass plugin installed in FF and I just log to your site."
And Joe Siegrist, one of the founding developers responds:
You don't send your master password in either case, you may want to try it yourself to convince yourself: https://lastpass.com/faq.php#howcanilook

What's done is that password field is blanked out and the value is used to make a SHA-256 hash along with your email using JavaScript, locally on your computer.
As the discussion continues, further internal technical detail is explained:
We understand your concern and would like to help you verify. The data is base64'd AES encrypted data with the 256-bit key being made up by a SHA256(username+password) username is lowecased and has whitespace removed, password is untouched. m.lastpass.com is by far the simplest version to follow this logic. I can probably make an extremely simple page that just takes username+password and encrypts and decrypts data in JavaScript if needed.
I'll continue to look at LastPass for a while, but it looks like it may well be on my list of regular recommendations in the near future.

Monday, April 6, 2009

Real MacOS Malware - Getting Over Invulnerability

A local sysadmin recently emailed me about his experience with a compromised Mac:

We recently found and removed some Mac-based malware.

The user had enabled "safe content" in Safari, (More reason to script-o-magically uncheck it as a login hook) which allowed her to download a file from a web site that Safari thought was a movie. When the file ran it was really a shell script that installed a payload into her Movies folder and assigned another shell script as a login item. Then at login she noticed the terminal would open, and then she'd close it. I presumed it was an advertising script and removed it. Interestingly enough, I just discovered that the application was actually pirating movies. The script made no attempt to elevate privileges. No passwords we asked for. It simply ran in standard user space once the user logged in.
He noted that he didn't keep a copy of the malware, and that his user wasn't sure of what she was doing when the malware ran initially. For now, keep an eye out for shell scripts in login items.

A recent survey that we conducted pointed out that a significant portion of our MacOS using community still feels that they are invulnerable. Examples like this point out that there are threats, even if they're not as common as Windows and Linux malware and compromises.

Consumers and Card Skimmers

The Consumerist has a brief writeup with some great pictures of the card skimmer that a reader found on a WAMU ATM. This sort of picture is an excellent way to help raise awareness - it looks quite persuasively real. As the reader notes, "there is a battery, flash memory card, and a mini USB port" on the back of the skimmer. Hopefully the police will set up a sting to catch the person who shows up to check the skimmer - if this were wireless it would be far more difficult to catch th perpetrator.

Friday, April 3, 2009

Death By Powerpoint: Microsoft Security Advisory 969136

We've all heard the joke about corporate meetings - "Death by PowerPoint". Microsoft's most recent security advisory however should make system administrators running older versions of PowerPoint 2000, 2002, 2003, and Office 2004 for MacOS sit up and take notice. Per the advisory, "Microsoft is investigating new reports of a vulnerability in Microsoft Office PowerPoint that could allow remote code execution if a user opens a specially crafted PowerPoint file.".

The good news is that newer versions of Office are not vulnerable, and that as usual, this only executes with the rights of the local user, and it requires users to open the PowerPoint file.

This is referenced as CVE-2009-0556, for those who would like to track it.

Thursday, April 2, 2009

False Positive Forensics

Institutions often have a well defined incident response process, and may have either in-house or contracted forensic and incident analysis professionals. They should have a well defined process for handling incidents, and that well designed response process needs:

  • Trained support for end users, servers, and the network that support must have
  • An escalation process that leads to
  • A central group or team responsible for investigating incidents who have
  • A documented process using
  • Standardized tools which helps shape
  • A decision process from which
  • A report is written in a common and understandable report format which
  • Guides management and further responses
Communication of this is also important, as any step that isn't properly communicated can lead to a failure - either in the process, or in the implementation of the process.

Once the process is started however, there are three possible answers that can be found. This post focuses on the third answer, but first we need to discuss the worst case scenarios. In these three scenarios, I use two definitions: event - a documented occurrence that leads to an investigation, and incident - an event that when investigated turns out to be a compromise, exploit, or other actual compromise.
  1. There is a real incident, and responses must handle the compromise, data loss, or other event. This may be part of an ongoing cycle, as some compromises lead to further investigation.
  2. There may be a real incident, but insufficient data is available to assess the situation. In this case, response is typically to restore operation and to verify that the system or application fully meets current standards. This is typically accompanied by further monitoring of the system to ensure that a second compromise does not occur due to an unknown or undocumented problem.
  3. Finally, the incident may be a false positive. In this case, the goal is to prove that the event was not an incident. This can be just as difficult, if not more so than proving that an incident occurred.
How can your organization handle forensics for these false positives? Often, the best route is to verify 5 things - you may pick and choose from these, depending on the system, and you might even add event appropriate checks beyond this list, but often you must check for these:
  1. Verify that there is no sign of the reported event. If a system is reported to have acted like a system infected with a trojan, then verify that the system does not display any of the characteristics of a trojan infected system.
  2. Check that the system or application matches its documented configuration. This is where Tripwire and other file integrity checkers may come in handy. In the some cases, simply checking MD5 sums and directory file lists from a matching system may help.
  3. Check local logs for signs of compromise.
  4. Check netflows, firewall logs, and other network traffic logs to determine if the system was inappropriately accessed or if it attempted to connect to remote sites.
  5. Finally, look for a plausible cause for the behavior that caused the original alarm. In some cases, this is user error, or a misunderstanding, or a process that resulted in unexpected results.
In most cases, false positive forensics are a best effort task - proving beyond a shadow of a doubt that nothing happened is difficult on any but the best documented and monitored systems, and the great majority of workstations - and even servers don't fall into this category.

Once you have your documentation, two last tasks remain - documentation and communication. A report, even a simple "no sign of compromise" is required, and you should communicate to the affected user and support person. This is where appropriate thanks will pay off for future real events, and it can also serve as an excellent opportunity to sponsor awareness.