Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
How did rapper JAY Z take the concept of Magna Carta to a whole new level?
Watch this week's 60 Second Security and find out!
? Can't view the video on this page? Watch directly from YouTube. Can't hear the audio? Click on the Captions icon for closed captions.
Google's Android operating system has another security hole. Same story as before: uou can tamper with other peoples' digitally-signed packages and Android won't notice.Rapper JAY Z's latest album release, "Magna Carta", was preceded by a custom Android app that had some privacy boffins up in arms.Tumblr managed to forget the S in HTTPS in a recent release of its iOS app. The social networking company is "tremendously sorry."
(If you enjoyed this video, you'll find plenty more on the SophosLabs YouTube channel.)
http://twitter.com/duckblog
Tags: 60 Sec Security, 60 Second Security, 60 Seconds, 60SS, Android, APK, app, carter, Code signing, data breach, Data Collection, EPIC, Exploit, exra field, Google, https, ios, Jay Z, master keys, Privacy, sniffing, Social Networking, Spam, Tumblr, vulnerability
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
Cryptographers have once again put SSL/TLS (that's the padlock in HTTPS) in their gunsights and opened fire.
This time, they've done some severe damage.
The attack they've devised doesn't work against all possible ways that TLS can be used; it requires you to capture somewhere between millions and billions of connections that all contain the same plaintext; and it only works well for the first 200 bytes or so of the transmitted data.
Nevertheless, it reveals a deep-rooted problem in using the RC4 encryption algorithm to secure your TLS traffic.
"Wait a moment," I hear you saying. "RC4 is a symmetric cipher, meaning that it uses the same key to encrypt and decrypt. TLS relies on public key cryptography, based on public/private key pairs. So how can RC4 affect TLS?"
The answer is that public key encryption is much too slow for scrambling all your network traffic, so TLS uses a hybrid approach.
You use your public/private key pair only when setting up a TLS connection, as a secure way to negotiate a random session key you can use with a symmetric cipher.
Once both ends of the connection have secretly agreed on a secret key, the actual data you want to exchange over TLS is conventionally encrypted using a regular, symmetric cipher.
There are many ciphers to choose from: OpenSSL, for example, supports AES, Blowfish, DES, Triple-DES, RC4 and many more.
Wait a moment," I hear you saying. "RC4 has known flaws sufficiently serious that they blew apart the WiFi encryption system known as WEP. So how can RC4 still be around for securing web traffic?"
The answer is that RC4 shouldn't be around.
Experts have recommended avoiding it completely, at least for any newly-written applications, for several years.
But replacing or banning RC4 in existing cryptographic implementations is a much trickier problem.
Indeed, according to the authors of of this latest research, RC4 is the cipher chosen for about half of all TLS traffic.
Instead, the paper they're working on (the full details aren't out yet, as the researchers are still working with vendors on countermeasures) is known as AlFardan-Bernstein-Paterson-Poettering-Schuldt (AlFBPPS), being the authors' names in alphabetical order.
RC4 is a stream cipher, so it is basically a keyed cryptographic pseudo-random number generator (PRNG). It emits a stream of cipher bytes that are XORed with your plaintext to produce the encrypted ciphertext.
To decrypt the ciphertext, you initialise RC4 with the same key, and XOR the ciphertext with the same stream of cipher bytes. XORing twice with the same value "cancels out", because k XOR k = 0, and because p XOR 0 = p.
Stream ciphers are handy for general-purpose network protocols because they can encrypt a single byte at a time, rather than processing only fixed-size multibyte blocks, so input data never needs to be padded.
? A PRNG can offer high-quality randomness without being cryptographic. Mersenne Twister, for instance, produces excellent random numbers from a starting key, known as a "seed". But if you know any 64 successive outputs of the algorithm for any given seed, you can reconstruct the internal state of the PRNG at that point and predict all future outputs, without ever knowing the seed. A cryptographic PRNG sequence can only be reconstructed if you know the starting key.
The problem is that although RC4 is a cryptographic PRNG, it's not a very high-quality one.
For more than a decade, we've known that it produces statistically anomalous output, at least early on in each stream of cipher bytes.
In 2001, Israeli cryptographers Itsik Mantin and Adi Shamir published a seminal paper entitled "A practical attack on RC4".
(Adi Shamir is the S in RSA; the R in RC4 is Ron Rivest, who's the R in RSA.)
Their paper is brief, but more than enough to undermine RC4's claim to randomness.
In particular, Mantin and Shamir examined the second output byte produced in any RC4 cipher stream, and found that the value zero turned up twice as often as it should:
You should see a zero as the second RC4 output once for every 256 keys on average; Mantin and Shamir showed that you would see it with a probability of 1/128.
This result, incidentally, was the basis of the attack that broke WEP, the original encryption protocol used in Wi-Fi networking, and forced its replacement with a newer encryption system called WPA.
AlFBPPS went much further than anyone else had done with RC4.
They produced statistical tables for the probability of every output byte (0..255) for each of the first 256 output positions in an RC4 cipher stream, for a total of 65535 (256x256) measurements.
By using a sufficiently large sample size of differently-keyed RC4 streams, they achieved results with sufficient precision to determine that almost every possible output was biased in some way.
The probability tables for a few of the output positions (which are numbered from 1 to 256) are show below.
(In a truly random distribution, each probability would be 1/256. The numbers here are multiplied by 256, so that each value ought to be 1, and the lines in the graphs should be perfectly horizontal at Y=1. Given a large enough sample size, any deviation from 1 reveals a statistically-exploitable anomaly in RC4.)
The authors realised that if you could produce TLS connections over and over again that contained the the same data at a known offset inside the first 256 bytes (for example an HTTP request with a session cookie at the start of the headers), you could use their probability tables to guess the cipher stream bytes for those offsets.
As Dan Bernstein very concisely put it at the recent Fast Software Encryption 2013 conference:
Force target cookie into many RC4 sessions. Use RC4 biases to find cookie from ciphertexts.
Here's how it works.
Imagine that you know that the 48th plaintext byte, P48, is always the same, but not what it is.
You provoke millions of TLS connections containing that fixed-but-unknown P48; in each connection, which will be using a randomly-chosen session key, P48 will end up encrypted with a pseudo-random cipher byte, K48, to give a pseudo-random ciphertext byte, C48.
And you sniff the network traffic so you capture millions of different samples of C48.
Now imagine that one value for C48 shows up more than 1% (1.01 times) more frequently than it ought to. We'll refer to this skewed value of C48 as C'.
From the probability table for K48 above, you would guess that the cipher byte used for encrypting P to produce C' must have been 208 (0xD0), since K48 takes the value 208 more than 1% too often.
In other words, C' must be P XOR 208, so that P must be C' XOR 208, and you have recovered the 48th byte of plaintext.
The guesswork gets a little harder for cipher stream offsets where the skew in frequency distribution is less significant, but it's still possible, given sufficiently many captured TLS sessions.
AlFBPPS measured how accurate their plaintext guesses were for varying numbers of TLS sessions, and the results were worrying, if not actually scary:
However, given the huge number of TLS sessions required, The Register's provocative URL theregister.co.uk/tls_broken might be going a bit far.
Initiating 232 (4 billion), or even 228 (260 million), TLS sessions, and then sniffing and post-processing the results to extract a session cookie is unlikely to be a practicable attack any time soon.
If nothing else, the validity of the session cookie might reasonably be expected to be shorter than the time taken to provoke hundreds of millions of redundant TLS connections.
On the other hand, the advice to avoid RC4 altogether because of its not-so-random PRNG can't be written off as needlessly conservative.
If you can, ditch RC4 from the set of symmetric ciphers your web browser is willing to use, and your web servers to accept.
Go for AES-GCM instead.
GCM, or Galois/Counter Mode, is a comparatively new way of using block ciphers that gives you encryption and authentication all in one, which not only avoids the risky RC4 cipher, but neatly bypasses the problems exposed in the Lucky 13 attack, too.
Easy for me to say, to be sure, but dropping old ciphers, especially those with known problems, is always the best plan.
Follow @duckblog
PS. If you run a website and you have already dropped TLS-RC4 support, please leave us a comment below to say whether any of your visitors were inconvenienced as a result. Did anyone complain? Did it cost you any transactions?
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
Last year, a Googler named Dr. Elie Bursztein noticed that Apple's App Store protocols weren't very secure.
Much of the interaction your iDevice had with the App Store was conducted via plain old HTTP.
Apple should really have been using HTTPS, or secure HTTP.
HTTPS, as you probably know, is HTTP traffic carried inside a Secure Sockets Layer (SSL) or Transaction Layer Security (TLS) wrapper.
? SSL/TLS uses public-key cryptography to create a secure data channel, even between users or websites that have never corresponded before. Conventional encryption, like a doorlock, relies on a single key that can lock or unlock. How to share that one-size-fits-all key before you start using it is a security problem all of its own. Public key cryptography relies on an algorithm that uses two keys. One is kept private, and the other made public. What the public key locks, only the private key can unlock.
The problem with HTTP is that if you're on someone else's network, whether it's wired or wireless, they can probably listen into all your web traffic.
Likewise, if someone else is on your network, they can do the same thing, eavesdropping undetectably.
Worse still, it's very likely that they'll be able not only to watch what you're doing, but also to modify the traffic you send and receive.
So, in an ideal world, there would be HTTPS only, since the encryption layer inhibits both eavesdropping and unauthorised modification. Nobody would use HTTP for anything.
And why not? SSL/TLS encryption can be made largely transparent both to the programmer and the user, so the difference in online experience between encrypted and unencrypted web sessions is pretty modest.
In practice, however, HTTPS isn't quite as convenient for your IT department as HTTP.
You need to get certificates signed, your private keys stored securely, and more.
That means an operational change, which means paperwork, implementation time and (you can guess what comes next) money.
Also, because every HTTPS download is encrypted uniquely for each user each time they fetch it, it's much harder to cache HTTPS traffic.
If 2000 users from the USA pull down the same image file from your database in New Zealand, you can't rely on a web cache on the USA side to serve up an identical copy of the file to 1999 of them, because each download is individually negotiated and encrypted.
That means an operational change, which means paperwork, implementation time and (you can guess what comes next) money.
As a result, a sort-of HTTP/HTTPS hybrid evolved.
You use HTTPS for the parts of the transaction that really have to be secret, such as sending passwords, credit card numbers and other Personally Identifiable Information (PII).
For everything else, you use HTTP.
That was the model used by many online services, including webmail providers and social networks, until fairly recently.
Things started to change after the release of Firesheep, security researcher Eric Butler's mildly controversial effort to push the envelope of web encryption.
Implemented as a Firefox plugin, Firesheep listened on the network until the HTTPS-protected part of your social networking session was complete.
Then it sniffed out your session cookie, the magic token embedded in your post-authentication HTTP requests that tells Facebook, Twitter and others that you're an authorised user.
Firesheep could then pretend to be you, posting status updates, links, tweets and more from your accounts as if you had done it yourself.
Of course, even without actively hijacking your social networking accounts, an eavesdropper can learn an awful lot about you from your HTTP traffic.
After all, not everything you upload to Facebook or Twitter is inevitably intended for public consumption, so it oughtn't really to be uploaded without being wrapped in an SSL/TLS session.
Facebook, Twitter and others, bless them all, eventually bit the bullet and simply switched to HTTPS for everything. (At least, they did for web-based clients. Special-purpose mobile apps were, and some still are, a different story, but we shall ignore that issue here.)
But Apple, it seems, didn't bother with HTTPS everywhere, even for its own App Store, until 2013.
Since there's no other place to shop when you're buying or selling iDevice software, and since Apple likes it that way, you might think that Cupertino would have set the bar a bit higher.
You might also have expected Apple to react a bit more quickly after Dr. Bursztein's fairly detailed explanations of why the bar really needed to be higher.
In July 2012, he explained several problems, which he's now made public, including active attacks (that's where you change HTTP content en route between server and client) by which a malcontent could steal your password, trick you into buying the wrong App, deliver you a bogus update, or quietly prevent you from applying a needed update.
Burzstein also showed that the App Store routinely uploaded an unencrypted list of already-installed Apps from your device.
That doesn't sound like much, but it is.
Firstly, some of those Apps will identify aspects of your life that would be handy for a social engineer to know: the bank you use, the newspapers you like, the games you play, the share-trading services you invest with, and more.
Secondly, the complete selection of Apps on your device may very well be unique to you, thus making it a handy form of digital fingerprint for an attacker.
Earlier this year, Apple finally made a start towards the change that many of its web traffic competitors like Google, Facebook and Twitter made some time ago, and bumped all the App Store's active content to HTTPS:
Good. (Better yet would have been to serve everything using HTTPS, but let's be thankful for what we've got.)
If you're a web developer and your web services rely on users sending you traffic that contains anything at all that oughtn't to be public, you should be doing the same.
Even data that isn't legally considered PII can be pure gold to cybercrooks, and so leaking it could be putting your customers at risk.
And you wouldn't want that, would you?
Would you like to know more about SSL/TLS?
Here's a quarter-hour Sophos Techknow podcast, featuring Paul Ducklin and Chester Wisniewski as they explain the S in HTTPS:
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
In April 2011, Naked Security wrote an open letter to Facebook about security and privacy.
Eighteen months later, it looks like he have some reason to celebrate - as Facebook appears to be saying "yes" to one of the three steps we asked them to take to better protect its users.
Way back in January 2011, Facebook announced it was implementing HTTPS to allow its many millions of users the ability to automatically encrypt their communications with the social network - preventing hackers and attackers from sniffing your sensitive data while using unencrypted wifi hotspots.
However, Facebook made this enhancement to security "opt-in" only. Which meant that most people never turned it on.
In Naked Security's open letter, we asked that Facebook did a better job with HTTPS.
As we wrote to them at the time:
"We welcome you recently introducing an HTTPS option, but you left it turned off by default. Worse, you only commit to provide a secure connection “whenever possible”. Facebook should enforce a secure connection all the time, by default. Without this protection, your users are at risk of losing personal information to hackers."
A posting last week on Facebook's developer blog, quietly announced that the site was finally going to be following our suggestion:
In the blog post, Facebook said that it was finally starting to rollout HTTPS to its North American users, with the rest of the world following "soon".
We want to say this really clearly and loudly, so we'll use a big font:
Sure, we might have liked it if Facebook had enabled HTTPS by default more quickly, but it would be churlish to grumble now they're doing it.
If you can't wait for Facebook to turn on HTTPS/SSL in your neck of the woods, you should set it up for yourself. Log into your Facebook account and navigate to Account settings / Security where you should be able to enable "Secure Browsing".
Of course, Facebook's roll out of HTTPS leaves us with a problem. We have a large pile of "Dislike" t-shirts that explain the three steps we'd like to see Facebook implement to improve privacy and security.
Clearly, with the roll out of HTTPS, one of those now needs to be crossed out.
So, we need to get rid of our T-shirts. We've decided the fairest thing to do would be to offer them to loyal subscribers to our email newsletter. Every month, until our stocks run out, we're going to give away 10 of these limited edition T-shirts to randomly selected newsletter subscribers.
If you're not already a subscriber to our newsletter, you can sign up here.
T-SHIRT GIVEAWAY TERMS & CONDITIONS: You need to be signed-up for our email newsletter at the time that we randomly select winners. If you've previously won a t-shirt from us in the giveaway, you can't win again. If you're a Sophos employee, tough luck - you can't win. If you're a Facebook employee, sure - feel free to subscribe and you might win a t-shirt, but we're not going to give you special treatment.
If you win, you will be contacted via email (naturally) to ask for your snail-mail address, so we can send you the shirt. It's kinda tricky otherwise. We'll do our best to give you a t-shirt in the size you want, but - hey - our stock is limited, so don't be too peeved if you get a baggy one. Your email address is only used for sending you the newsletter (you can unsubscribe at any time) and for asking you where we should send the t-shirt. No spam, we promise. We're nice guys.
Make sure that you keep informed about the latest security and privacy issues affecting Facebook users. Join the Sophos page on Facebook, where over 190,000 people regularly share information on threats and discuss the latest security news.
Over 170,000 people are part of the Sophos community on Facebook. Why not join us on Facebook to find out about the latest security threats.
Hi fellow Twitter user! Follow our team of security experts on Twitter for the latest news about internet security threats.
Already using Google+? Find us on Google+ for the latest security news.
About a week ago, popular IT news site The Register announced a security hole in Firefox.
Under the headline Firefox 'new tab' feature exposes users' secured info: Fix promised, El Reg decried the most recent Firefox release as "unlucky version 13".
The story ended up pretty widely reported, and Mozilla has publicly promised a fix.
But is this really a bug? If so, is it serious?
Even more importantly, do any of the workarounds popping up online actually do what they claim?
We decided to investigate - which took a lot more fiddling, digging and experimentation than you might think. (Unless you're a software tester. If so, you already know how explosively configuration options combine.)
Example of a New Tab page with images thumbnailed during earlier browsing
The controversial feature is Firefox 13's updated 'new tab' system. This takes thumbnail snapshots of sites you visit, and replays them later when you use the New Tab window.
The thing which outraged Register reader Chris, and led to all the news coverage, is that the thumbnails include images of content accessed over HTTPS, such as banking transactions and webmail sessions.
That much is true.
I opened a series of HTTPS pages looking like this:
Then I exited Firefox and reloaded it.
At this point, the New Tab page did indeed clearly reveal the content of my earlier secure browsing:
In hindsight, this is a bad idea, given Firefox's default privacy settings. I'm glad Mozilla has committed to change it.
If you permit Firefox to retain cached information from day to day in this form, anyone with even momentary access to your browser in the future can hit Ctrl-T or Command-T, and may immediately get a look at personal information you wouldn't expect to have been be preserved.
Nevertheless, HTTPS doesn't promise encryption at all times. The S-for-secure component applies only during the HTTP part of the transaction - the data transfer. It's worth keeping that in mind.
Whatever is inside an HTTPS request, and inside its corresponding reply, must exist in unencrypted form at each end of the conversation in order to be of any use.
That means both your browser and the server you're talking to may - indeed, probably will - end up with a permanent record of the transaction's content, even though it was encrypted during transmission.
In fact, that's exactly what happens in Firefox, version 13's New Tab thumbnails notwithstanding.
Even if you turn off the thumbnail display (clicking the matrix icon on the New Tab screen will do that for you), the contents of your HTTPS pages may very well end up in the Firefox cache anyway.
(When a web page is sent to your browser, whether securely transmitted or not, the server gets to say if and how it should be cached. The server does this by setting an Expires: or a Cache-Control: header in the HTTP reply.)
In my HTTPS experiments, turning off the thumbnails didn't do anything about Firefox's cache.
Here's what I saw after clearing all history and repeating my tests with thumbnail display turned off. I examined the cache with the special about:cache URL:
Zooming in to the seven files listed as cached shows three of the URLs duplicated - the HTTPS pages I visited in the test.
The objects denoted No expiration time are the thumbnail images; their partners are the original, decrypted, HTTP replies:
Zooming in to any of the files in the list brings up the complete HTTP header and body data in the reply:
So the new-found data leakage due to the thumbnails is a bit of a red herring.
The information from which Firefox 13 builds its thumbnails has been there all along in previous Firefox versions.
The cache isn't quite as easy to get to as the New Tab window, but it can still be accessed directly from your browser. Also, of course, it contains not just highly-compressed snapshots of your web pages at specific instants, but an exact history of all their components.
Your best bet for getting rid of cached content - which, as we have seen, includes the very thumbnails that got Register reader Chris worried in the first place - is to use Firefox's existing privacy features to purge old browsing data promptly.
Keeping a detailed record of your browsing history and maintaining it between sessions is convenient, but insecure.
A little inconvenience goes a long way towards improving security, which is why I recommend a Firefox privacy configuration similar to this:
I also recommend that you use the Clear Recent History... command as a matter of routine whenever you finish an online transaction involving personally identifiable imformation.
You'll find the history-clearing dialog in the Tools menu.
Finally, as I promised earlier, what about the "thumbnail bug" workarounds you'll find online?
You may be tempted to use a workaround until Mozilla adapts the behaviour of its 'new tab' system to exclude HTTPS pages.
For example, you may have read about the browser.newtabpage.enabled option you can change in about:config.
I've also read that you ought to change the other two newtab-related settings you can see here, too:
Bad news. This isn't actually a workaround at all. It feels like one, because the thumbnails no longer appear if you tweak the settings above.
But the thumbnails are still collected, are still held in the cache, and are still accessible by visiting about:newtab and clicking the matrix icon.
In conclusion, if this whole issue really is a bug, it's more of bug in our attitude to retaining browser data between sessions than a bug in the Firefox code.
Even when Mozilla "fixes" any thumbnail concerns you might have, I'll still be advising you to get much more aggressive about how often and how thoroughly you clear out your browser history...
Cryptographers have once again put SSL/TLS (that's the padlock in HTTPS) in their gunsights and opened fire.
Indeed, according to the authors of of this latest research, RC4 is the cipher chosen for about half of all TLS traffic.
Last year, a Googler named Dr. Elie Bursztein noticed that Apple's App Store protocols weren't very secure.
Things started to change after the release of Firesheep, security researcher Eric Butler's mildly controversial effort to push the envelope of web encryption.
Since there's no other place to shop when you're buying or selling iDevice software, and since Apple likes it that way, you might think that Cupertino would have set the bar a bit higher.
In April 2011, Naked Security wrote an open letter to Facebook about security and privacy.
About a week ago, popular IT news site The Register announced a security hole in Firefox.
In fact, that's exactly what happens in Firefox, version 13's New Tab thumbnails notwithstanding.
I also recommend that you use the Clear Recent History... command as a matter of routine whenever you finish an online transaction involving personally identifiable imformation.