A tale of bad passwords and nude photos.

The Internet is on fire with discussions of the recent release of stolen nude photos of over 100 female celebrities. This is a massive invasion of their privacy, and it says something sad about our society that there is an active market for such pictures. While this particular attack was against the famous, most of us have information in the cloud that we would like to stay secret.

While there is not a definitive explanation of the breach the current consensus is that it was probably caused by a vulnerability in Apple’s “Find My iPhone” feature. Apparently the API interface to this service did not check for multiple password failures, a standard security practice. This allowed attackers to test effectively unlimited numbers of passwords for each of the accounts they wanted to access.

Because most people use relatively weak passwords, this attack is quite effective. Once they gained access to the accounts, they could sync down photos or any other information stored in iCloud.

Of course, the first rule of secrecy is: If it does not exist, it can’t be discovered.

If you do want to create something that you would be pained to see released publicly, then make sure you keep close control of it. Store it locally, and encrypted.

Wherever you keep it, make sure it has a strong password. Advice for strong passwords has changed over time because of the increasing speed of computers. It used to be that fancy pneumonics would do the trick but now the fundamental truth is: if you can remember it, it is too weak.

This is particularly true because you need to be using completely different passwords for every website. Changing a good password in a simple obvious way for every website is obvious. It might prevent brute force attacks but if some other attack gives access to your password, the attacker will be able to easily guess your password on all other websites.

You need to be using a password manager like 1Password (Mac), LastPass, Dashlane, etc. Let the password manager generate your passwords for you. This is what a good password should look like: wL?7mpEyfpqs#kt9ZKVvR

Obviously I am never going to remember that, but I don’t try. I have one good password that I have taken the time to memorize, and it unlocks the password manager which has everything else.

UPDATE: There appears to be some question about whether this vulnerability is actually to blame.

"The Big Hack, or maybe not..." — The Social Network Station

"The Big Hack, or maybe not..." — The Social Network Station

On Friday I was asked to come on The Social Network Show to talk about the fact and questions surrounding the theft of over 1 Billion passwords.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

Attack on Tor may have exposed hidden services and more.

Tor just announced that they have detected and blocked an attack that may have allowed hidden services and possibly users to be de-anonymized.

It looks like this may be connected to the recently canceled BlackHat talk on Tor vulnerabilities. One hopes so, otherwise the attack may have been more hostile than simple research.

Tor is releasing updated server and client code to patch the vulnerability used in this attack. This shows once again one of the key architectural weaknesses in Tor, the distributed volunteer infrastructure. On the one hand, it means that you are not putting all of your trust in one entity. On the other hand, you really don’t know who you are trusting, and anyone could be running the nodes you are using. Many groups hostile to your interests would have good reason to run Tor nodes and to try to break your anonymity.

The announcement from Tor is linked below.

Tor security advisory: "relay early" traffic confirmation attack | The Tor Blog

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

More proof that the web security model is totaly broken

Fake Google Digital Certificates Found & Confiscated

On July 2, Google engineers discovered unauthorized certificates for Google domains in circulation. They had been issued by the National Informatics Center in India. They are a trusted sub-authority under the Indian Controller of Certifying Authorities (CCA). They in turn are part of the Microsoft Root Store of certificates, so just about any program running on Windows, including Explorer and Chrome, will trust the unauthorized certificates.

The power of this attack is that the holder of the private key to the certificate can impersonate secure Google servers. Your browser would not report any security alerts because the certificate is “properly” signed and trusted within the built in trust hierarchy.

Firefox does not have the CCA in its root certificate list and so is not affected. Likewise Mac OS, iOS, Android, and Chrome OS are safe from this particular incident as well.

It is not known exactly why these certificates were issued, but the obvious use would be national surveillance.

While this attack seems to be targeted to India and only impacts the Microsoft ecosystem, the larger problem is much more general. There is a long list of trusted certificate authorities, which in turn delegate trust to a vast number of sub-authorities, any of whom can trivially create certificates for any domain which would be trusted by your computer.

In this case the attack was detected quickly, but if it had been very narrowly targeted detection would have been very unlikely and monitoring could have continued over very long periods.

As an end user, you can install Certificate Patrol in Firefox to automatically detect when a website’s certificate is changed. This would detect this kind of attack.

On Chrome you should enable “Check for server certificate revocation” in advanced settings. That will at least allow quick protection once a certificate is compromised.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

Update: Microsoft has issued an emergency patch removing trust from the compromised authority.

The one thing you need to do about password breaches

The recent Ebay password compromise is just the latest in a string of similar attacks. Each time we hear a call for people to change their passwords. Sometimes the attacked company will require password changes, but more often it is just a suggestion; a suggestion that a majority choose to ignore.

Further exacerbating the problem is the tendency of people to use the same username and password across many different websites. Even if a compromised website does require a password change on that site, it has no way of forcing users to change their passwords on any other sites where the same password was used. This matters because a smart attacker will try any username / password pairs he discovers against a range of interesting websites of value, like banks. Even though the compromise may have been on an unimportant website, it could give access to your most valuable accounts if you re-used the password.

The burden on the user can also be significant. If a password is used on 20 websites, then after a compromise it should be changed on all 20 (ideally to 20 different passwords this time). People who maintain good password discipline only need to change the one password on the single compromised website.

Trying to remember a large number of strong passwords is impossible for most of us. Some common results are that the the passwords are too simple,  the passwords all follow a simple and predictable pattern, passwords are re-used, or some or all of these at once.

Many companies and standards organizations are working hard to replace the password with a stronger alternative. Apple is using fingerprint scanners in its latest phones, and tools like OAUTH keep the actual password (or password hash) off the website entirely. Two factor authentication adds a hardware device to the mix making compromise of a password less damaging. So far many of these approaches have shown promise, but all have some disadvantages or vulnerabilities, and none appear to be a silver bullet.

For now, best practice is to use a password vault. I use 1Password but LastPass, Dashlane, and others are also well regarded. Create unique long random passwords for every website (since you no longer need to actually remember any of them). Don’t wait. If you are not using one of these tools, get it and start using it now.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me onFacebook, Twitter, and Google+.

Most websites may already be completely pwned by the Heartbleed Bug

Heartbleed Bug

Researchers recently announced the discovery of an incredibly dangerous bug in the OpenSSL encryption library. That library is used by about two thirds of websites, and many VPNs and other secure communications services.

The problem is in a memory leak that allows an attacker to request heartbeat responses which will contain up to 64KB of memory, and to do so over and over without being detected. This has already been shown to be able to capture the server’s RSA secret key. That is the key used to authenticate communications with the clients, and to encrypt the session keys. Other data could be captured as well, but those keys are really the biggest threat.

An attacker with that key could perfectly impersonate the server, or run man in the middle attacks undetectably.

It is unknown if, or how often, this attack has been run in the wild. It is entirely possible that major players, like national intelligence services, may have known about this for some time, and could have been silently intercepting traffic to certain websites, potentially for over 2 years. We just don’t know. There is a call for researchers to set up test sites to detect this activity going forward, but there is no way to know if it happened in the past.

The solution is non-trivial. All affected services need to install the recently available patch to fix the underlying problem. They then need to address the possibility that their keys have been stolen. All server certificates need to be revoked, so clients will know to reject them, and new certificates created and distributed. This is likely to take time, and many sites will be very slow to respond.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

Easy bypass to Android App signing discovered

Infosec Institute published an article showing in detail how application signing on Android devices can be defeated.

This trick allows the attacker to modify a signed application without causing the application to fail its signature check.

The attack works by exploiting a flaw in the way signed files in the .apk zip file are installed and verified. Most zip tools don't allow duplicate file names, but the zip standard does support it. The problem is that, when confronted by such a situation the signature verification system and the installer do different things.

The signature verifier checks the first copy of a duplicated file, but the installer actually installs the last one.

So, if the first version of a file in the archive is the real one, then the package will check as valid, but then your evil second version actually gets installed and run.

This is another example of vulnerabilities hiding in places you least expect.

Hacking for counter surveillance

Another from the "if the data exists, it will get compromised" file.

This article from the Washington Post talks about an interesting case of counter surveillance hacking.

In 2010, Google disclosed that Chinese hackers breached Google's servers. What only recently came to light was that one of the things compromised was a database containing information about government requests for email records.

Former government officials speculate that they may have been looking for indications of which of their agents had been discovered. If there were records of US government requests for information on any of their agents, it would be evidence that those agents had been exposed. This would allow the Chinese to shut down operations to prevent further exposure and to get those agents out of the country before they could be picked up.

I had not thought about subpoenas and national security letters being a counter intelligence treasure trove, but it makes perfect sense.

Because Google / Gmail are so widely used, they present a huge and valuable target for attackers. Good information on almost any target is likely to live within their databases.

The Privacy Blog Podcast – Ep.7: Blacklisted SSL Certificates, Social Media Hacking, and the “Right to be Forgotten” Online

Welcome to episode 7 of The Privacy Blog Podcast. In April’s episode, we’ll be looking at the blacklisting of SSL certificate authorities by Mozilla Firefox - Specifically, what this complex issue means and why Mozilla chose to start doing this.

In more breaking online privacy news, I will be discussing the security implications of relying on social media following the hacking of the Associated Press Twitter account earlier this week.

Next, I’ll chat about the “right to be forgotten” on the Internet, which hinges on the struggle between online privacy and free speech rights. In a closely related topic and following Google’s release of the new “Inactive Account Manager,” I will discuss what happens to our social media presence and cloud data when we die. It’s a topic none of us likes to dwell on, but it’s worth taking the time to think about our digital afterlife.

China launches MITM attack on GitHub

It appears that China recently launched a poorly executed Man in the Middle (MITM) attack on GitHub.

Greatfire.org has all the details.

In short:

GitHub.com is an https only website, so the only way to monitor it is to use a MITM attack to decrypt the contents of the communications. There is evidence that GitHub is widely used in China for code sharing, so the backlash from blocking it completely was too large, and it was unblocked a few days later.

The attack happened on January 26. It was poorly executed in that the faked certificate did not match the real one in any of the meta-data and it was not signed by a recognized certificate authority. This caused most browsers to report a security error. The MITM attack only lasted about an hour.

Based on reports it only impacted users in China, which strongly suggests that it was government backed at some level. My work in censorship circumvention over the years has shown that China is far from monolithic. This could have been the work of a local government or regional ISP. I have not seen an analysis showing if this was country wide or not. It seems very ham fisted for the central government.

The speculated reason for the attack is to monitor access to a list of people who have been involved in creating the Great Firewall of China, which is hosted on GitHub, and is connected to a petition on Whitehouse.gov proposing that those people be denied entry to the US.

Anonymous / Antisec lied about iOS UDID leak?

NBC News is reporting that the iOS UDIDs leaked last week were actually stolen from Blue Toad publishing company. Comparing the leaked data with Blue Toad's data showed 98% correlation which makes them almost certainly the source.

They checked the leaked data against their own after receiving a tip from an outside researcher who had analyzed the leaked data.

It is certainly possible that this data had been stolen earlier and that, in tracking that crime, the FBI had obtained the stolen information. This strongly suggests that this is not a case of the FBI conducting some kind of massive surveillance activity.

The other possibility is that Anonymous and Antisec are simply lying about the origin of the information as part of an anti-government propaganda campaign.

Either way, it is a big knock on their credibility, unless you think this whole thing is just a conspiracy to protect the FBI.

The iOS UDID leak

Forbs is reporting that Anonymous and Antisec have dropped a file with a million Unique Device ID (UDID) numbers for Apple iOS devices. They claim to have acquired an additional 11 million records which they may release later.

In addition to the identifiers, the file is said to also contain usernames, device names, cell numbers, and addresses. It is this additional personal information that seems to be the real threat here.

The Next Web has set up a tool for checking to see if your information is in the leaked data. You don't need to enter your full UDID into the field, just the first 5 characters. That way you don't need to trust them with your information either.

None of my iOS devices showed up on the list, so I downloaded the entire file to look it over. You can see the release and download instructions here.

Looking through the document, I don't see any examples of particularly sensitive information. In the first field are the claimed UDID. The second field is a 64 digit hex string. After that is the name of the device, frequently something like "Lance's iPad". Finally is a description of the device itself: iPad, iPhone, iPod touch.

SHA hashes are 64 hex digits long, and are widely used in forensics to verify that captured evidence has not been changed. My intuition is something like that is what we are seeing in that second column.

I have no idea where the claims about addresses, and account names came from. I am not seeing anything like that.

It is interesting that Anonymous / Antisec claim that this data came from the hacked laptop of an FBI agent. This certainly raises big questions about why he would have this information on his laptop, and why the FBI has it at all.

While 12 million is a big number, it is a tiny fraction of the over 400 million iOS devices sold to date. Still, that would represent a shockingly wide dragnet if these are all being monitored in some way by law enforcement.

Of course, for all we know this list was captured evidence from some other group of hackers.

So, short answer (too late!), you probably don't have anything to worry about here, but you might want to check to see if your device is in the database anyway.

UPDATE: It appears that the UDID may tie to more information that was immediately apparent. While Apple's guidelines forbid tying UDIDs to specific account, of course that happens all the time. My friend Steve shared a link with me to an open API from OpenFeint which can tie a UDID to personal information. Certainly there are others which would reveal other information. The existence of these, and the leaked list of UDIDs would allow an app developer to tie a user's real identity to their activity and use of the app on their iOS device.

UDATE 2: I find it impossible to actually read documents from Anonymous and Antisec, they are just so poorly written. It seems I missed their statement in lines 353,354 of the pastbin where they say that they stripped out the personal information. The 64 digit block is actually the "Apple Push Notification Service DevToken". SCMagazine is reporting that the FBI is denying the laptop was hacked or that they have the UDIDs.

"Private" YouTube videos expose thumbnail images

Thanks to a PrivacyBlog reader for pointing me to this article: Blackhat SEO – Esrun » Youtube privacy failure

It looks like it is easy to find thumbnail images from YouTube videos that have been marked private.

If you have any such videos, go back and check that you are comfortable with the information in the thumbnails being public, or delete the video completely.

Schneier on Security: Domain-in-the-Middle Attacks

Schneier on Security: Domain-in-the-Middle Attacks

Bruce Schneier on the real world effectiveness of a very simple domain name based man in the middle attack.

Here is a Wired article on the same issue showing how it was used to steal 20 GB of email from a Fortune 500 company.

Stolen Credit Card website hacked

Vendor of Stolen Bank Cards Hacked — Krebs on Security Brian Krebs has an interesting blog post on how all of the credit card information was stolen by a hacker from a website that sells stolen credit cards.

This is in the "don't know whether to laugh or cry" department.

A Very Nice Analysis of the Lockheed Martin Network Breach

Here is a really nice analysis of the recent security breach at Lockheed Martin. The short version is that is looks like their SecureID tokens got duplicated. This is almost certainly related to the security breach at EMC / RSA. Digital Dao: An Open Source Analysis Of The Lockheed Martin Network Breach