It may be true that cloud computing services are permeating nearly every facet of our networked world; but in the process of sharing our data with the companies that provide these resources, what do we do about the trust issue? Data in the cloud is vulnerable unless it’s protected somehow. And if this protection isn’t implemented, then the whole service becomes less useful for those people who require it.

Not all services are affected equally, however; and some are not affected much at all. For example, protecting certain data fields stored in a distributed online database may be as common-practice as using strong encryption. However, more delicate services may not be as flexible…

How do you force the image data stored on a cloud image editor to be encrypted at their end? Or force a word processor to encrypt your latest holiday shopping list? Without the assistance of the service providers, the only solution is a customized technical workaround; colloquially known as a hack.

An example of precisely this kind of workaround was outlined in this paper (pdf) by Yan Huang and David Evans. In it, they describe a method (and a working example) by which a user can use Google Docs while maintaining both confidentiality and integrity.

It works by way of some very clever applications of incremental encryption, data structuring, and indexing to transparently handle all of the security operations. And although it interferes with some functional capabilities, it stands as an example of the kind of solutions needed to shine some light on the shady parts of the cloud.

Back in January, Google announced they would pay between $500 and $1,337 for bugs in their Chromium web browser code, if the discoverer first reported it privately to them and followed certain conditions. Since then, the company has handed out quite a few bounties to security researchers who found problems.

Now, Google has expanded the program by offering similar bounties for vulnerabilities in their web-based applications. Hackers who find issues such as HTML injection or cross-site request forgery in important Google services can now report them and possibly qualify for rewards ranging from $500 to $3,133.70. As with the Chromium bounties, bug hunters have to follow a few rules and conditions, such as giving Google some time to fix the issue before public disclosure.

Given the success of the Chromium bounties, it’s likely this new experiment will be beneficial both for security researchers and Google’s users. It certainly adds an interesting new twist to the debate over how to handle outside bug discoveries – perhaps we’ll see more companies offering such compensation in the future.

You may have seen Ben’s post earlier this week on Firesheep. I am running a Mac and I use FileVault, as I recommend most people do in order to protect their sensitive files.  Unfortunately the current release of Firesheep does not support FileVault.  That didn’t stop me, here is what you need to get Firesheep running on Firefox 3.6.x on a Mac running FileVault from start to finish.

1. Download the Firesheep .xpi file here.
2. Drag the .xpi file into your Firefox browser window to install it, then quit Firefox.
3. Move the extension folder from your user account to the application folder.  The /Users/[youraccount]/Library/Application Support/Firefox/Profiles/[yourprofile]/extensions/firesheep@codebutler.com folder should be moved into the /Applications/Firefox.app/Contents/MacOS/extensions folder.
4. Relaunch Firefox, and you should be good to go.  If you receive an error related to “–fix-permissions”, make sure you moved the folder (and didn’t copy it), and if it still didn’t work try running once as root (sudo /Applications/Firefox.app/Contents/MacOS/firefox-bin).

Enjoy. Use responsibly. And encourage your local coffee shop owner to turn on WPA2 to limit its usefulness.

Here at Security Musings, we occasionally discuss some fairly technical topics. Like most speciallized subjects, there is a plethora of disorganized information, and occasional spatterings of highly organized resources on the Internet that help widen one’s knowledge and expertise in any given area.

One such spattering I recently came across is the online version of the Handbook of Applied Cryptography (not to be confused with the other book of similar appellation that is more-frequently used in college classes around the country).

Although it can get pretty nitty gritty at times with regard to the math and science involved in cryptography, sometimes that is exactly what you need to get the full picture and/or fill in the blanks that other resources gloss over in the interest of comprehensibility.

And best of all, the publishing company has released the chapters for free electronic distribution: http://www.cacr.math.uwaterloo.ca/hac/

Keep in mind, the last printing was in 2001, so some of the information may be a little aged. But if you’ve ever read any of our posts regarding public key encryption (Ch. 8, pdf), hash functions (Ch. 9, pdf), or digital signatures (Ch. 11, pdf), and wish we went a little further with the technical details, this just might satiate your thirst for knowledge.

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!