The point of sales (POS) breaches at Hilton, and Starwood before that, suggest that a group of hackers is specifically targeting hotels, probably because most travelers have above average income. It should also make us brace for a likely wave of further POS breaches in many other businesses during the holiday shopping season. It really makes me wish that more merchants accepted secure payment tools like Apple Pay, or even that more than a small fraction accepted the new chip and signature cards.
The Hola peer to peer VPN service suffered a number of very damaging security revelations today including exploit vulnerabilities, exposed administrative tools, & broken architecture impacting 45 million active users of the service.Read More
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.
This article describes a clever attack against Secret, the “anonymous” secret sharing app.
Their technique allows the attacker to isolate just a single target, so any posts seen are known to be from them. The company is working on detecting and preventing this attack, but it is a hard problem.
In general, any anonymity system needs to blend the activity of a number of users so that any observed activity could have originated from any of them. For effective anonymity the number needs to be large. Just pulling from the friends in my address book who also use Secret is way too small a group.
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.
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.
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.
Update: Microsoft has issued an emergency patch removing trust from the compromised authority.
A vulnerability in LIFX WiFi enabled light bulbs allowed researchers at Context Information Security to control the lights and access information about the local network setup.
The whole “Internet of Things” trend is introducing all kinds of new vulnerabilities. Because these devices tend to be cheap, don’t feel like tech, and don’t expose much user interface, users are unlikely to secure, patch, or otherwise maintain them.
As these devices proliferate in our networks, we will be introducing ever more largely invisible vulnerabilities, usually without any thought to the consequences.
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.
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.
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.
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.
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.
It appears that China recently launched a poorly executed Man in the Middle (MITM) attack on GitHub.
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.
The latest Java exploit has given another view into the workings of the cybercrime economy. Although I should not be, I am always startled at just how open and robustly capitalistic the whole enterprise has become. The business is conducted more or less in the open.
Krebs on Security has a nice piece on an auction selling source code to the Java exploit. You can see that there is a high level of service provided, and some warnings about now to ensure that the exploit you paid for stays valuable.