HOPE was this weekend at the Hotel Penn in New York City. Except for the choice of venues, it’s a pretty nice (and cheap) conference to get to. I went to several of the talks, although, not all of them would be interesting to purely security people – like cooking for geeks… The talks I did attend were interesting, if not ground breaking. HOPE isn’t generally where people release new code, tools or exploits – that’s Black Hat and Defcon in two weeks, but there tend to be more talks about hacker culture and privacy. The one talk I skipped that I would have liked to go to was the Social Engineering talk – at 9pm on a Saturday (I was already half asleep). I heard that they tried to social engineer a BP gas station, with some success.

I also hit up the talk on the American Bombe – yes, we had a few – a well researched and interesting discussion on how the US got started on that project and some of the stumbling blocks along the way. I also went to the HTTPS discussion, but it rehashed old SSL vulnerabilities and issues with the default CAs trusted in the browsers. One of the better talks I went to was the Locational Privacy and Wholesale Surveillance via Photo services talk by Ben Jackson. He discussed using the EXIF GPS data to stalk people. I promptly told my iPhone that the Camera app was not allowed to use location services.

For me, HOPE is more about the hallway track and meeting people and learning new things on the mezzanine level. This year, the lockpick village was so small that no one could fit in, so I didn’t stop by there – even if I did take my picks. There were more vendors on the M level as well, mostly books, with very little electronics as there have been in years past.

This year, I borrowed a friend’s ham radio and used my license for the first time in 10 years to get an N2H QSL card – along with my friend and several others. Just listening to the hams talk from N2H was interesting as well.

Last year I discovered an unusual but useful method for writing web application code: non-alphanumeric JavaScript. This technique has been pioneered by several script ninjas on the hackers forum sla.ckers.org and lets you write scripts without directly using letters or numbers. Application filters or sandboxes may catch typical attacks by monitoring for requests such as “document.cookie,” but they may let non-alphanumeric code slip through.

How does it work? First, you can use blank objects or arrays to generate basic values. For instance, +[] evaluates to the number zero, while !{} returns the boolean value false. You can also combine these simple results to create strings, such as [!{}]+[+[]] == "false0". By treating these strings as arrays, we can grab individual letters. From our previous example, "false0"[0] == "f", so we can use ([!{}]+[+[]])[+[]] == "f" instead.

Once we have enough of the alphabet available as strings, we can start combining letters to reference more useful objects and functions, thanks to JavaScript’s flexibility. For instance, if you wanted to load the sort function for an array, you’d probably use a [].sort() syntax. But []['sort'] works equally well, and even []['s'+'o'+'r'+'t'] loads fine.

In fact, if we set _=[]['sort'] (variable names need not require letters and numbers either!) and call _() in Firefox, we’ll get back the window object, opening up many more possibilities. Accessing this object also means we don’t have to write all of our code without the benefit alphanumeric characters, since we can load data from window.name or window.location. For instance, if we load http://server/page.html#alert(document.cookie), the hash is only seen by the client (and our script), not the server.

This means that if a server is vulnerable to cross-site scripting and doesn’t filter our non-alphanumeric script, we can execute arbitrary JavaScript even though we only send non-alphanumeric code to the server.

If you’re interested in more details, check out the sla.ckers.org threads on optimizing code, cheat sheets, and the Great JS Wall (researchers have found that you couldn’t load arbitrary scripts if you draw from a set of less than six characters). Also, several of the people who contributed to those threads are releasing a book on this method and other attack strategies later this year, entitled Web Application Obfuscation.

Fact: Twitter uses Amazon’s S3 AWS to store user images.
Fact: Twitter apparently only checks the file extension to determine the file type of uploaded images, not an image library or a method that checks for binary image data.
Fact: This can be used (or abused) to obtain un-metered free hosting of files that are less than 800K in size.

How is it done? A user can rename any file with a ‘jpg’ ‘gif’ or ‘png’ extension and upload it as their background image on a dummy Twitter account.

Then they can simply grab the URI of the “image” from the inline CSS declarations. Since the file is believed to be an image, it is uploaded and stored with no changes. The URI will point to a file having an image extension, but non-image content.

A good application of this is using Twitter’s AWS account to host javascript files. Simply enter the URI as the “src” attribute in a script tag like so:

<script type="text/javascript" src="http://s3.amazonaws.com/twitter_production/profile_background_images/151911/my_javascript.jpg"></script>

For high-traffic websites that use large javascript files, this could save a considerable amount of bandwidth. Amazon’s S3 acts as a CDN as well, so this might also improve performance.

There are some ugly security implications of this, however. Many web-based exploits use unaware 3rd-party hosts to serve up malicious javascript files.  This is particularly troubling since other types of files can be uploaded (exe, swf, mp3, etc). Unless they want their Amazon S3 storage account to become a free data repository for the bad guys, perhaps Twitter should be a bit more prudent with their user-submitted data.

FireGPG is an OpenPGP MIME-compliant add-on to Firefox that allows you to select some text on a web page (or entered in a form) and perform some cryptographic operations on it.

This add-on provides immediate security benefits. It can allow you to easily and quickly encrypt a message and send it over a public channel without even having to leave your browser. For example, you can send a (short) secret message to someone by encrypting it and posting the block in a public forum or on a public blog– as long as the recipients have the correct key, they can decrypt it. This add-on can also be used to generate digital signatures, providing both integrity and non-repudiation.

Below is an example of some encrypted text sent via Gmail and the results of FireGPG’s decryption:

Although it doesn’t offer anything groundbreaking in terms of functionality, having access to these features with just a right-click within a browser window can certainly come in handy. And for people who want the benefits of public-key cryptography but their web-based email clients don’t support it, this might just scratch that security itch.

You can get FireGPG here.

NOTE: FireGPG is just the add-on that provides an interface to the PGP functionality. You will also need the software to manage keys and perform the cryptographic operations. For this purpose, FireGPG requires GnuPG– a free open-source implementation of OpenPGP. Get it here.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

Pop quiz! Be honest as you answer these questions:

Well, if you answered anything other than C for the above questions, let me introduce you to your worst nightmare: sslstrip.  The author of this program realized that most people don’t type in the https prefix, and don’t look closely for padlock icons; people don’t care about security, they just expect it to work.  Most of the time, the way you get to SSL pages is by clicking on links, or being redirected with an HTTP 302 status.

sslstrip takes advantage of this, and transparently hijacks HTTP traffic, replacing all HTTPS links and redirects with look-alikes.  It even can supply a favicon which looks like a browser’s lock icon.

It’s pretty evil, actually. Of course it requires that the attacker running sslstrip has already compromised your network, through ARP spoofing, DNS poisoning, or otherwise having your traffic routed to the attacker. Good luck noticing if it’s being used against you. The author used it on a TOR node — note that TOR is generally used by people that are paranoid by their privacy and security — and collected 254 passwords over a 24 hour period.

What’s the fix? As far as I’m concerned, there isn’t one. It’s a design flaw with the way most “secure” websites work today. Do you have ideas on how to prevent this attack? Let us know in the comments.

A recent security incident involving embedded executables in GIF images reminded me of the art of steganography. This is the science of hiding secret messages, often in plain sight or in a way that only intended recipients even know a message exists.

Such techniques could be as simple as writing a message using disappearing ink, or as complex as deliberately inducing errors in quantum data to encode private data (I love quantum steganography; it’s so bad [pdf]).

Here, I will describe one of many ways to hide a simple text file inside of a JPEG image. All you need to have is access to the command line and a RAR or ZIP file archiving program such as WinZip or WinRAR.

1. Make a simple text file in any text editor (for this example, we’ll call it “secret.txt”)
2. Rar or zip the text file and save it as “secret.rar” or “secret.zip”
3. Get a JPEG image (“coverimage.jpg”)
4. Open a command prompt and type: “copy /b coverimage.jpg + secret.rar newimage.jpg”

In essence, you are concatenating two binary files, with the image data at the beginning. The file “newimage.jpg” should now contain a hidden message, yet it will still appear to be a simple picture to those who don’t examine its contents. To view the message, the recipient need only open the image as if it were a regular rar or zip file and extract the concatenated compressed archive.

To illustrate, here is a very small picture of a very large grizzly bear. If opened as a rar file, the message in the embedded archive “secret.txt” can be read.

In a way, steganography is a close cousin to cryptography; they both deal with protecting and hiding information. Whereas cryptography involves scrambling information and obscuring its meaning, steganography deals primarily with hiding the fact that a message is even present.

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

Google has recently allowed users to see why it may flag a site as “suspicious.”

The service will show any information Google has about potentially harmful websites, including sites that have been compromised and sites that host malicious programs or malware. This is good in two ways— first, users can take advantage of this service whenever they question a site’s legitimacy; and second, website administrators may be alerted if their site gets compromised without their knowledge and starts serving up harmful content.

Of course, this assumes the compromise results in something that catches the attention of the Google application.

Although this is FAR from a 100% reliable test to determine if a website is safe to visit, it does provide an extra layer of protection just in case.

Example:

http://www.google.com/safebrowsing/diagnostic?site=http://badsite.com

Just replace the value of the “site” variable with whatever website you want to check out.

I think its good that Google is allowing this— they have an enormous amount of information at their disposal. Offering some of it to help keep people away from malicious sites definitely fits their motto— “Don’t be evil.”

Just stumbled upon some javascript code for determining what social networking sites you visit.

What are you to do if you want readers to promote your content? … You have to decide on which bookmarking site, if any, to dedicate your precious screen real-estate. It’s a hard choice. If you choose poorly your reader won’t vote—it’s not a single click coupled and out-of-sight means out-of-mind—and your content losses its chance to make it big. You have to choose your horse wisely.

If you could detect which social bookmarking sites your reader uses, on a per-reader basis, you could display only the badges they care about. But you can’t know that because the browser secures the user’s history, right? Wrong.

Let’s try it. You have visited: .

So, is this a cool capability, or a creepy violation of your privacy? I think it is the former; since the code all runs client-side and can be disabled using a tool such as NoScript, and it benefits the user with a cleaner interface. Provide your comments below!

I’m sure many people have already seen that data was recovered from a Columbia (shuttle) hard drive. Yes, this was the shuttle that blew up on reentry back in 2003. Needless to say, the drive would be expected to be quite physically destroyed. There was some quite important research data on the drive, and the drive was sent to OnTrack Data Recovery Services for an attempt at recovery. Well, they were able to recover 99% of the data off of the drive.

Now, admittedly, the details on the actual data recovery were slim. How well was it protected inside the shuttle’s hull? What kind of temperatures was it exposed to? What kind of impact did it have? How much did it cost (both in time and money)? But, that’s just impressive. (And it just confirmed that I will continue to buy Seagate drives!)

What does that mean for us mere mortals? Bashing a Seagate drive with a hammer is not enough for “Data destruction”. Incineration may not even be enough for complete and total data destruction. Some of the things we’ve taken for granted about destroying hard drives have been turned on their head. I used to recommend that people open up their hard drives and leave fingerprints all over the platters as a method of making them unreadable. Maybe this isn’t the case any more.

This type of article makes the case for disk encryption, whether full disk or at least the data. Then even if the drive does survive re-entry, the only data that’s recovered is garbage to anyone without the key. On the flip side – remember that the full disk encryption will probably render your data unrecoverable should you actually need it recovered. (That’s what backups are for people!)

I thought this was interesting:

The pathogen disguises itself as waste material and tricks cells into digesting it, just as they normally would with the remains of dead cells. As the immune response is simultaneously suppressed, the virus can be ingested as waste without being noticed.
…
As soon as they impinge upon the cell membrane, an evagination forms, a bleb. The virus itself is the trigger for the formation of the evagination. Using a messenger substance to “knock on the door”, the virus triggers a signaling chain reaction inside the cell so that the bleb forms, catches the virus and smuggles it into the cell.

Apparently, the vaccinia virus is able to disguise itself as cellular waste which other cells readily ingest, causing them to become infected without setting off any alarms. The parallels with computer malware/trojans is apparent— they work in much the same way. If a computer user can be tricked into executing what appears to be an innocent or trusted program/application, they could inadvertently let in all sorts of nasties.

As Jean-Baptiste Alphonse Karr once said, “Plus ça change, plus c’est la même chose…”

“The more things change, the more they stay the same…”