USENIX: Securing Search, Refereed Papers

Measuring and Analyzing Search-Redirection Attacks in the Illicit Online Prescription Drug Trade

Nektarios Leontiadis, Carnegie Mellon University; Tyler Moore, Harvard University; Nicolas Christin, Carnegie Mellon University. Presented by Nektarios Leontiadis.

The researchers chose to focus on illegal sales of prescription drugs, as it's the most dangerous form of online crime - if someone takes the wrong dosage of a drug, or gets a counterfeit drug, they can die.

This type of spam takes advantage of trust that people have in someone's blog or other social network by exploiting search results. The search results in a browser shows what looks like valid links, but will redirect you to an online pharmacy - they call these infected links.

The researchers collected a lot of search results where they queried for various drug related topics (from "cialis with now prescription" to "ambien overdose"), and they got many infected servers (like umass.edu) and legitimate servers (online pharmacies).

These infected sites and illegitimate comments to blogs are crowding out legitimate online health resources. .Edu domains and high ranking sites are particularly at risk, and the infection seems to last longer on .Edu sites.

The problem is that they are actually getting a very high conversion rate (ie number of click-throughs where people actually make purchases).

The researchers see three possible solutions: getting the prominent infected sites fixed, which would not be too hard, as there are only a handful there, fixing the search engines to recognize these attacks, and trying to stop illegitimate redirection.

The audio and video of this presentation are now online.

deSEO: Combating Search-Result Poisoning

John P. John, University of Washington; Fang Yu and Yinglian Xie, MSR Silicon Valley; Arvind Krishnamurthy, University of Washington; Martín Abadi, MSR Silicon Valley. Presented by John P. John.

John showed us the malware pipeline: find vulnerable servers-> compromise webservers and host malicious content - > spread malicious links via email, IM, search results -> bad stuff happens.

Their research focused on on the spread on the malicious links. Nearly 40% of popular searches contain at least one malicious link in top results. Instead of getting the content you want, you get "scareware" that tells you that your PC is infected and you need to install software to fix it. As if that's not bad enough, give it a few weeks or months, and it will ask you to pay $50 in order to keep protecting your PC, even though it is actually malware.

Sites running osCmmerce are particularly at risk, due to it being a popular piece of shopping cart software with many well known unpatched vulnerabilities.

The script is obfuscated, but what it basically does is generates a page for a keyword, gets text from Google and images from Bing, and now it's got something that will look legitimate and get you to click through. They get their keywords based on top trending keywords from Bing and Google.

The malicious sites can sufficiently cloak their behaviour using redirects and javascript, so they can hide themselves from automatic detection by search engines.

Their tool looks for sites that suddenly have a new type of content or large quantities of new content, clustering similar domains, and comparing the new pages on one site to another's.

The audio and video of this presentation are now online.

This article syndicated from Thoughts on security, beer, theater and biking!

USENIX: I'm From the Government and I'm Here to Help: Perspectives From a Privacy Tech Wonk

Tara Whalen, IT Research Analyst from the Office from the Privacy Commissioner of Canada, was a last minute fill in.

Ronald Reagan: "The nine most terrifying words in the English language are 'I'm from the government and I'm here to help.'", and while Whalen is from the government, she hopes that we aren't terrified of her. :-)

As the US Government doesn't have an Office of Privacy, Whalen gave us an overview of her Canadian agency. The office was established in 1983 with the passing of the Canadian privacy act. Their mandate is to oversee compliance with the 1983 Privacy Act and the 2000 PIPEDA Act, which means they protect both corporate world and individual citizens. They help review new policies and guide parliament.

In addition to those more standard government functions, they also have a technology analysis branch, where they do investigations, audits, privacy impact assessments, and research. This division supports a lot of research, even including a game for Canadian children to teach them about privacy.

Whalen went into detail into a couple of case studies. The first one was their investigation of Facebook, where a group of law students had reviewed Facebook's policies as compared to Canada's PIPEDA and Privacy acts. Their result was a 24 point complaint to Whalen's office, which triggered an in depth investigation.

The investigation was very detailed and involved using things like packet sniffers to see what actually is happening with data on the wire. After a year, the Canadian government had an official complaint to give to Facebook requesting eight items to be corrected, six of which where relatively easy changes to the language on the site. For example, disambiguation between account deactivation and account deletion.

Some of the roadblocks that her team hit were Facebook redoing all of their privacy settings and adding many new features in December 2009 as well as all of the third party apps that hook into the system. New complaints have come in, so the investigation is still undergoing and Whalen could not comment further.

The next case study she presented was on the Google WiFi complaints, which was initiated by privacy investigator in Germany. Basically, while Google was driving around collecting pictures for their Street View service, they were also collecting information on WiFi networks. Google's initial response was that there was no data payload being collected, which made the privacy experts very happy ... until they found out that wasn't a true statement. Google had actually accidentally collected over 600 GB of payload data from around the world from unprotected WiFi networks.

Google of course apologized and quickly discontinued the practice.

Google did hand over the data collected in Canada (18G) to the government, who then was faced with a bit of a conundrum. Google had not looked at nor utilized the data, so the privacy group didn't want to go and deep dive into the potentially very personal information and expose things that at this point had still been private. They did a cursory examination where they did look at some of the personal information to verify that it was indeed collected, and presented aggregate information in their report. They did find whole emails, even though Google had stressed they had only picked up fragments of information - obviously, the data they collected depended on what a user was doing at the exact moment the Street View car drove past their house.

Google did take the complaints very seriously, added changes to training for engineering and then also appointed an internal privacy officer.

Another area the privacy office looks at is location privacy. The case shown here was about a German citizen who sued Deutsche Telecom in order to get his own data about his locations and then shared it with the world. Quite a shock about how much information his cell phone carrier had for him!

Then there was the recent case where Apple was collecting location information from iPhones and 3G iPads, even if the location services were disabled on the device. This information wasn't just stored on the device, but also transferred to any computer you would sync with and transmitted to Apple. This was well discussed in the media, particularly due to how visually interesting the maps were.

It wasn't just Apple. Android and Microsoft did this as well, though to varying degrees.

In Canada, there is a lot of legislation being proposed to help protect privacy and better define when data can be held and accessed by law enforcement.

It is good to know that, at least in Canada, there is someone in the government that cares deeply about protecting citizen privacy.

The audio and video of this presentation are now online.

This article is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Forensic Analysis, Refereed Papers

Forensic Triage for Mobile Phones with DECODE

Written by Robert J Walls, Erik Learned-Miller and Brian Neil Levine, University of Massachusetts Amherst, presented by Robert Walls.

Forensic triage attempts to acquire evidence quickly, accurately from a crime scene. DECODE works on mobile phones and can extract information from the raw data on the phone, without specific knowledge of the phone's file system or operating system.

Phones are the focus of this research as they are everywhere and essentially record our lives, and likely contain evidence. Even without direct evidence, they can be used to find motivation and establish a time line.

Directly browsing the phone only gets law enforcement the information that hasn't been deleted, and could possibly modify the data while the phone is being inspected. Many commercial tools currently available are very expensive and focused on the most common phones.

DECODE will look at the raw storage (bytes of data with unknown format), which helps retrieve "deleted" data, meta-data and time-stamps. It does this using block hash filtering and inference.

Inference relies on most phones having data listed together, like name, time, and phone number.

This work can be applied to phones that have not been previously seen - making it much more extensible in this ever changing market.

The audio and video of this presentation are now online.

mCarve: Carving Attribute Dump Sets

Written by Ton van Deursen, Sjouke Mauw, and Sasa Radomirovic, University of Luxembourg. Presented by Sjouke Mauw.

These researchers used beer, card readers and time to look at hacking their public transport cards. Unfortunately, were not able to use existing forensic carving tools, so had more work to do. The researches knew when the cards were purchased, how much money was left on them, and when they were last used - as they were their own cards. This gave them some "known text" to search for, ie attributes of the card.

Just knowing that "plain text" was not enough, in some cases the plain text was too simple and would appear multiple times on the card, for example, knowing that the card had been used 4 times. But, using that data, with others, they were able to narrow down the different components of the card.
The audio and video of this presentation are now online.

ShellOS: Enabling Fast Detection and Forensic Analysis of Code Injection Attacks

Written by Kevin Z. Snow, Srinivas Krishnan, and Fabian Monrose, Universyt of North Carolina at Chapel Hill; Niels Provos, Google.

Exploit kits are making it easier and easier to deploy attacks. The speaker started out with a real world example of an email that looked very much like the standard email you get from a Xerox copy-scanner, except that the attachment contained shell code that could be used to attack the system.

One way of detecting this with dynamic code analysis by partly executing the code in a sand box environment, to detect malicious code. Emulation based approaches are slow and can be easily detected by the malicious code.

This is where ShellOS comes into play. Execution runs uninterrupted, at native speed. If any fault occurs, it is trapped and skipped. It does this in real-time, which makes it more stealthy.

Their next experiments were around how effective they were in practice at detecting shellcode. At 100Mb line, they could process packets in real-time and not risk any dropped packets, running on one CPU.

Their most important test came for trying to detect PDF code injection attacks. This is where Niels Provos came into play, handing over documents that had been flagged by Google's Large-Scale Web Malware Detection System and compared it to past USENIX Security conference PDFs (the assumption being that those would be exploit free).

While examining these documents, they found almost all of them were attempting to get a shell, which is what ShellOS was created to detect. They were able to detect the code in the malicious documents, and didn't get any false positives in the presumed innocent set from USENIX.

This seems like a very cool project and I'd be very interested to see where this ends up going.
The audio and video of this presentation are now online.

This post is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Analysis of Deployed Systems

Why (Special Agent) Johnny (Still) Can't Encrypt: A Security Analysis of the APCO Project 25 Two-Way Radio System

The paper was written by Sandy Clark, Travis Goodspeed, Perry Metzger, Zachary Wasserman, Kevin Xu and Matt Blaze, presented by Matt Blaze.

APCO Project 25 (P25) is a standard for digital two-way radio used by law enforcement in the US and worldwide. They work over a narrow band radio channel at 9600 baudes, where the sender makes all decisions, everything is multi-cast and has no concept of "ACK".

The standard does allow for optional security, like encryption (AES, DES, etc) that are configured in a manual process - though they can be rekeyed live (while in use). What is interesting about these security options is that they are not explicitly defined in the standard, which leaves it up to vendors to come up with ways configure things like encryption. So far, the paper authors haven't found any of the devices that use authentication.

Looking at attacks, you can use something similar to "ping" to actually create a map of where all of the P25s in the area are - basically, giving away locations of security personal, which can help attackers find weak spots.

There are also very easy ways to jam these devices using consumer devices, like "GirlTech IMME" (an "instant messenger" toy), which could be purchased for $15. Jammers can even be configured to jam selective traffic, like block all encrypted traffic - a good way to get users to think something is wrong with their crypto mode so they'll disable it.

While you can rekey on the fly, it does require everyone already having a key to begin with. The P25s rely on centralized keying, so if just one radio comes in that does not have the key, then everyone needs to talk in the clear. So, why bother with cryptanalysis, when you can just look for clear text [USENIX Security '95]?

The researchers recommend that the encrypted switch be disabled all together and just encrypt an entire channel, and decrease frequency of rekeying, which is actually leading to security problems and getting people to talk in the clear.

The audio and video of this presentation are now online.

Dark Clouds on the Horizon: Using Cloud Storage as Attack Vector and Online Slack Space

The paper was written by Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber and Edgar Weippl from SBA Research.

There are many places where you can now store data in the "cloud", some using simple models like FTP or more complex, like delta detection. Most sites are now trying to use deduplication, which will help save on storage space.

Looking at Dropbox, which uses Amazon Simple Storage System (S3), dedup (SHA-256) and AES for encryption. The researchers' first attack takes advantage of the hash manipulation, where they could use unauthorized file access by just having the hash value - undetectable by victim or Dropbox.

The second attack they analyzed was the "stolen host ID attack", where Dropbox uses host ID to link particular host with an account - so, once someone else takes your credentials, they can impersonate you. This attack can be easily detected, and Dropbox is now preventing this.

If you know someone else's host ID, you can store your data in their Dropbox - won't count against your storage quota, and as long as you have the address, you can continue to retrieve your data.

The audio and video of this presentation are now online.

Comprehensive Experimental Analyses of Automotive Attack Surfaces

Written by Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, Stefan Savage, Karl Koscher, Alexei Czeskis, Franziska Roesner and Tadayoshi Kohno.

Cars are no longer a mere mechanical device, they are controlled by tons of computer controls (ECUs) running millions of lines of code. In general, this makes the car safer, but is a problem if an attacker is able to take control of the car.

Many of these ECUs can even be reprogrammed while the car is being driven! All it would take is for one of these devices to be infected for it to spread to the rest of the vehicle. These types of controlls could allow an attacker to do things like disable breaks, disable lights or even disable the engine!

The researchers said there were three major types of systems to attack. First, indirect physical attacks work over a physical interface, though no direct access to the physical device. Short-range wireless attacks can impact things like tire pressure sensors, remote keyless entry, wifi access points and vehicle-to-vehicle communications. Third type of attack was long-range wireless attacks, taking advantage of things like HD radio or systems that are used for roadside assistance.

Every vector of attack the team worked on led to some type of system shut down.

In the indirect physical attack, the team looked at the media player that uses ISO-9660, which is apparently pretty common. They were able to come up with a WMA file that would play fine on a computer, but would reprogram a car's radio.

Their short-range wireless attack used bluetooth to take advantage of a strcpy() bug, which was completely undetectable by the user. They were also able to take advantage of a buffer overflow in the telematics unit in the car - basically, you can call a car and fill it with malicious code.

In fact, they could take their malicious "song" from before on an MP3 player with the speaker going to a phone that has called the unique cell code for the car, and the attack code was loaded by the car.

Actually managed to install an IRC client onto the telematics unit, and could use that client to get a shell on the telematics unit, getting the car to send broadcast packets to attack other cars.

You can easily use this technology to steal a car - use GPS to locate the car, use their device to unlock the car, bypass security tools and start the engine. They showed a video where they did this - drove a car away with no key!

Same researchers took advantage of these same technologies to remotely eavesdrop on people in their car - 1,500 miles away!

These telematics units contained things like ftp, telnet, nc, vi... on a UNIX like real-time operating system. Not quite secure out of the box...

How did we get here? Basically, nobody's been attacking them, so there's been no reason to protect them. But, this is improving - SAE, USCAR and US DOT are working on this. Too little, too late? Let's hope not!

The speaker ended the talk with a picture of a hacked odometer. Great talk!

The audio and video of this presentation are now online.

This post is syndicated from Thoughts on security, beer, theater and biking!

USENIX: Three Cyber War Falacies, Dave Aitel, Invited Talk

Dave Aitel, CEO of Immunity, Inc, started out with a picture of "The truth shall make you free" - a quote from a wall in the offices of the CIA, which helped Aitel launch his talk on cyber security and cyber war and how irony pervades this industry.

According to Aitel, there are three fallacies of cyber war:

1. Cyberwar is asymmetric
2. Cyberwar is non-kinetic - as in it's in the virtual world, no "real" victims.
   
3. Cyberwar is not attributable

Aitel notes that there won't always be explosions or "instant death" when it comes to cyber war, but there can still be great consequences - including loss of utilities, the more things come on line.

He warns Californians about the security implications of PG&E's SmartGrid, where a not-so-smart chip will control when you can have AC, etc., that will be very easy to compromise. That type of attack, along with recently discussed expoits on automobiles, put people's lives in jeopardy every day.

For example, STUXNET, which many took as a temporary trojan horse that is now totally under control - what the community at large doesn't seem to see, is that it was a demonstration that this (or something like it) can be used to target any factory or any utility at any time.

The problem with a lot of these trojans and worms, is that once your corporate network is infected, it is virtually impossible to to completely rid your network of these hackers. Think about it, if it took you six months to a year to discover the intruder, then you have to assume they are everywhere and you will unlikely be able to totally get them out.

Aitel then started on his point about how cyber war is NOT asymmetric by giving many counter examples, though, unfortunately he spoke very fast and the slide ware moved quickly (and was overcrowded and filled with tiny words) so I had a hard time following that point...

Automated computer security commonly involves things like vulnerability scanners, static analysis, web application scanners - they just don't work, too slow and tedious and really still require manual analysis. Aitel believes his team can find more bugs by just looking at the code, rather than relying on this analysis. Personally, I think that's great if we were all perfect, but I've definitely seen static analyzers find stuff that humans missed, both in writing and while reviewing.

Aitel has a very strong opinion on "script kiddies" - he believes that the term "script kiddie" belittles what is really a challenging career, which he compares to nuclear scientist. I'm sure he's trying to be a bit tongue in cheek, but, as someone with a science degree, I can say for certain that a nuclear scientist would most definitely be a lot more skilled than someone that runs someone else's attack scripts. Sure, there may be some learning curve to running these, but... it's not nuclear science.

Aitel then went on to quote CERN about how SSL based VPNs are all broken, due to fundamental flaws in the architectures, but did not go into details. I'm happy that I'm reading my mail over an IPsec connection ;-)

One thing that has changed over the years is that the attacking community is now mature, organized and highly motivated. After realizing that DefCon this year had reachead 19 years of age... and that I started attending back in DefCon 2, I can only imagine how accurate that statement is. [and at DefCon this year, there was a children's track.... ]

Regulation can't help here - it's too slow. Aitel argues until the "traditional bearded men that work on security get into Government" it isn't going to get better. I guess Professor Spafford meets that mold, but not sure how Susan Landau fits that mold.... guess she'd better work on her beard.

Overall, this talk was fun and entertaining, but seemed to be an agenda for why you couldn't possibly secure your own network or code on your own, and you need to hire his security team.

I think the important take-a-ways are that you cannot rely on static analyzers alone to make sure your code and network are secure, policies and tools need to be regularly re-reviewed, and keep ahead of the attackers.

The audio and video of the talk are now online.

This post is syndicated from Thoughts on security, beer, theater and bikes!

USENIX: Charles Stross Opening Keynote

Charles Stross, two time Hugo Award winning science fiction writer, greeted us with a talk on Network Security in the Medium Term (2061-2561). He quipped that by setting his predictions so far out, we'll be unlikely able to prove him wrong - and if we can, then he'll be happy to just be alive.

His talk started out with stating the obvious, that we won't have to worry about network security if, for example, we have a global system panic - so, he's going to assume that doesn't happen. The other issues around seeing his predictions come to fruition depends on medicine meaningfully extending our lives, having stable political systems and managing society's increasing complexity.

In the future, we won't be able to ignore emerging countries like China and India, and, well, the whole of Africa, all of which will change how we manage security and interact together.

Stross told a story of a theoretical time traveler from the 1960s and how huge of a technology hurdle he'd have to overcome - no imagine how much technology change we can expect in the next 50 years! Children nowadays will never know the experience of being lost, always connected, always with GPS at hand. [of course, such an assumption presumes the child growing up in a home of means, don't forget the aforementioned Africa!]

Stross took us through a myriad of potential futures - like will we, as humans, have a lifelog like we have in modern cars? Will we have to fight super viruses, bacteria and cancer? Will genome sequencing computers be able to help protect us? But, will we want to share our own DNA in order to aid these computers? Give up our privacy in order to always have an alibi? Give our insurance companies access to vehicle harddrives so they can detect how people really drive?? It seems unlikely.

I've personally submitted my DNA into two systems: Kaiser Foundation's Genome Study and 23andMe. I did this both to advance science and to give myself valuable information about my gene profile, though my neighbor, a DNA forensic scientist, believes I was insane to share my DNA with anyone. Perhaps I should've consulted her before I spit in that cup.

Lots of interesting scenarios to think about, we'll definitely have to be more careful with our privacy as more information is put online and in storage.

The audio and video of the talk are now online.

This article is syndicated from Thoughts on Security, beer, theater and biking!

Peaches en Regalia

My husband and I had the pleasure to see Peaches en Regalia from Wily West Productions at the Stage Werx Theater in San Francisco last weekend.

This is a new work, being presented for the first time as two acts. It's a sweet play revolving around the ever changing life of the title character, Peaches, who has recently taken a job at a restaurant where they serve... wait for it... Peaches en Regalia.

Sarah Moser, as Peaches, takes the stage by storm with her opening monologue which describes college, her internship at a financial institution and why she decided to take a job at a diner. Moser is energetic and her monologue comes to life as the other actor's help her reenact scenes from her recent past.

The hilarity continues when Philip Goleman comes into the diner as Norman and then gives us a hilarious monologue on bathroom etiquette and working on his flirting skills.

Of course, the two come together. The fast paced and delightful show moves along as Nicole Hammersla (Joanne) and Cooper Carlson (Syd) fill in the picture. Joanne has a nervous tic (picking at her sweaters) and Syd is a soft-hearted republican.

This was a wonderful production that will keep you entertained throughout! Even with a short 10 minute intermission, the show was still about 90 minutes running.
Definitely worth a trip up to San Francisco!

This post is syndicated from Thoughts on security, beer, theater and biking.