I spend a lot of time telling people to use two factor authentication on their important web accounts. This may explain why I don’t get invited to parties.
While using 2FA is a great idea, there is one issue which you (and your employees) should be aware of.
If your 2FA solution relies on text messages to deliver it’s one time passcodes, it may be vulnerable to “mobile number port out” scams. This article from the always informative Brian Krebs explains the mechanics of this.
The solution? If a site offers the choice between using text messages and an authenticator app, choose the app. If you have to use text based authentication, make sure that your mobile phone account is protected from porting using a PIN or password.
tl;dr – If you are using Microsoft Office 365 (or any other hosted email solution) and have not enabled two factor authentication, you are bad and you should feel bad
Microsoft and other cloud vendors really need to make two factor authentication the default for their email and other business critical cloud applications. You should have to make an active decision to turn off 2FA and be forced to watch a video about companies who were hacked as a result of lack of 2FA in order to make the decision stick.
I spent too much time today dealing with two business partners (one small and the other large) from whom my users received multiple emails containing PDF phishing documents. These emails were hard for users to recognize as bad – they came from a real email account of a real person at a real firm that they had done business with.
What had happened is that our partners were using hosted email and had not enabled two factor authentication. A user at each got phished and the attacker in each case took control of their email to send the evil documents to all of their contacts.
Fortunately for us, our protections worked – user awareness training and multiple layers of web and email filtering alerted us to the problem and none of our users fell into the trap lain by the attacker.
It could have been much worse. A more sophisticated attacker could have utilized the identities of the email senders in a more sophisticated way, such as to redirect payments on invoices or to get our users to disclose confidential information. Or who knows what.
That being said, it still is pretty bad – any information we sent to those email accounts in the past is now in the hands of who knows who. We are reviewing the traffic to the hacked accounts to determine what could have been exposed. While it seems that these guys were not after intellectual property, we will never know where that information ends up.
The decision on the part of these two partners to not have 2FA has real costs for my firm – users had to be notified, all emails sent to those partners need to be reviewed for sensitive information and an incident report written.
For now, I am pulling all of our email logs to determine which of our vendors are using various hosted email platforms and sending them a note inquiring as to whether they use 2FA. If not, we are going to have some serious talks with them about their security posture. We’re also going to start monitoring for partners who move from on-prem to hosted email.
This type of attack is happening way too often and opens up companies who never signed up for these hosted services to risk which just should not be there.
Yesterday, at ShmooCon, security researcher Sean Cassidy announced a vulnerability in the popular LastPass password manager. He demonstrated a way that an attacker could send a user a phishing email, redirecting them to a specially crafted web page which logged them out of LastPass and presenting a “pixel perfect” copy of the LastPass login screen where the user could then enter their user name, master password and two factor authentication code. This information would be sent to the attacker, who would then have access to all of the user’s passwords.
Key to this evil plan was a “cross site request forgery” (CSRF) vulnerability in LastPass, which allowed the attacker to force the user to log out of the password manager. This vulnerability has been fixed in the latest version of the application, so this particular attack will not work today and LastPass users should not panic.
I have been a proponent of password managers in general and LastPass in particular and still think that LastPass, DashLane, Keepass and the like are great solutions for protecting your online accounts. In my opinion, the extra security you achieve by having unique long, strong passwords for each of your accounts outweighs the risks posed by using a password manager.
One of the debates around LassPass and its online brethren is whether their practice of storing encrypted versions of passwords in the cloud to allow them to be shared amongst devices and browsers presents too much of a security risk. Many people prefer to use offline password managers like Keepass which store the encrypted passwords locally. I can see the case for either choice, but I feel that for most people, the ease of use of a synchronized solution like LastPass or DashLane makes it more likely that they will use long, strong, unique passwords for all sites. In particular, the ability to use these programs with both mobile and desktop devices is important – non synchronized password managers can be a pain to use and keep up to date on mobile devices, where we are increasingly leading much of our online lives.
I did take this opportunity, however, to look at LastPass’ main competitors, Dashlane and was quite impressed with it from an ease of use point of view. It definitely gives a superior user experience on the mobile platform, but it does not seem to allow you to store attachments in Secure Notes, which is a LastPass feature I like and use. Dashlane is more expensive than LastPass ($39 per year versus LastPass’ $12 price tag). Dashlane seems to be easier to configure for the non technical user and uses the device itself as a second form of authentication, obviating the need for a separate authorization code. Of course, this means that a stolen phone or iPad could give an attacker access to your passwords, but you can specify a PIN or use the iPhone’s fingerprint reader to control access. I was able to import my LastPass data into Dashlane really easily and they provide a 30 day trial of their premium features, which I am currently taking advantage of. I’ll let you know how it goes.
To summarize, this vulnerability points out how seemingly innocuous vulnerabilities (being able to remotely log someone out of a website or tool) can be leveraged by malicious miscreants for their nefarious purposes. However, it is not a show stopper for LastPass and they seem to have responded in a timely fashion. Password managers are still a great security solution.
In August of last year, a security researcher at UC Berkeley found two security vulnerabilities in LastPass while researching the security of web based password managers. He reported the problems to LastPass, who quickly remediated them.
One of the vulnerabilities would have allowed an attacker to gain access to unencrypted credentials IF the user accessed a malicious web site and then used the LastPass “BookMarklet” to log into that site – if you use the browser extensions for Chrome, IE, Firefox, or Safari (as 99% of LastPass users do), your account was not vulnerable to this attack. BookMarklets are only used if the browser in use does not support LastPass directly.
The other vulnerability would have allowed an attacker who knew a user’s log in ID to retrieve an user’s encrypted password file, but not the key needed to decrypt this file.
LastPass states that they have no evidence that either of these vulnerabilities were exploited by anyone other than the researchers.
I still use and recommend LastPass – after all, if we stopped using software every time a security vulnerability was found and fixed, we would not be using Windows, Mac OS, or any browsers and plugins. The extra security provided by using LastPass to manage unique strong passwords for the sites you log into far outweighs the risk of being compromised by vulnerabilities such as the ones described.
There is a lesson to be learned for LastPass users, though. The security of your account is as only as good as the master password you choose for your LastPass account. Make sure that it is hard to guess, and is constructed using letters, numbers and special characters in order to make it as hard as possible for someone to crack.
I am disappointed in how long it took LastPass to reveal this issue – when you are entrusted with users’ “keys to the kingdom,” you have a responsibility to be transparent about issues like this in a timely fashion. I think that this is also a good time for LastPass to open up their code for third party security review to be proactive about finding and fixing security issues before the bad guys do.
It seems like the latest big security story is a newly discovered flaw in the OAuth and OpenID protocols which allow users to authenticate to third party web sites using their account on another web site like Google, LinkedIn or Facebook. Apparently, it is relatively easy for attackers to create an attack via a phishing email with a link to a site which then asks the user to authenticate (to the fake site) using their Google account (or any other identity provider which supports OAuth and OpenID). The authentication pop up will look legitimate – it will actually seem to point to the identity provider’s web site, but it will, in fact, deliver the unsuspecting user’s credentials to the attacker.
So what do we, as security professionals, do with this information? Given the “behind the scenes” nature of the issue, and the fact that there is no cue to the user that a particular site is trying to use the flaw to gather credentials, we are stuck with telling our users to “be more careful” about using their Google/Facebook/LinkedIn etc. credentials to log in to sites. Well, that’s pretty darn vague. I guess the best advice to give people would be not to set up any new site credentials using OAuth/OpenID until the problem has been fixed.
This is a classic example of the tradeoffs we make between security and privacy. While logging in to multiple sites using credentials from a “trusted” provide makes life easier for the web user, he or she also risks having the security of all of their accounts linked to that ID compromised when that one provider suffers a security breach or there is a problem with the underlying technology. This is one of the many reasons we need to move away from password authentication and come up with easy to use 2 factor login methods to reduce the risk associated with weak/stolen passwords.
Interesting blog post from Graham Cluley on LastPass’ support for using the Galaxy S5’s fingerprint reader as the key to your password vault. Since the S5’s fingerprint reader has been shown to be vulnerable to low sophistication fake fingerprint attacks, he wonders whether this (admittedly) very convenient feature is worth the risk. As a LastPass user, I don’t think I would base the security of the keys to my entire digital life on this particular piece of hardware. However, this does beg the question – is the low but non zero risk of someone getting hold of your phone and fingerprint exceed the risk of using the same damn password on every site you visit? LastPass also offers a mitigation for this scenario – it is possible to specifically permission which mobile devices can access your account. If you phone is lost or stolen, it is possible to revoke that permission (if you notice the loss or theft quickly enough). This is a risk calculation that users will have to make for themselves.
In this article over at Ars Technica, we get the scoop on Standford University’s new password policies which vary the requirements for password complexity (use of special characters, upper case, lower case, numbers, etc.) based on how long the user chooses to make their password. As the password chosen gets longer, the user is given more latitude to reduce the amount of complexity. I think that this is a great idea, providing users with choices in how their passwords are constructed while maintaining a level of security relevant to those choices. Unfortunately, this is not a policy which can be implemented off the shelf on today’s most ubiquitous operating systems – you would have to create some sort of a front end program to vet users’ password choices and then store them in the OS. Sounds like a great idea for an open source project to me.
It seems like Heartbleed is going to be keeping infosec people busy for a while.
First, multiple people have succeeded in extracting the private signing keys of a website’s SSL certificate using Heartbleed. This is not good news, since it makes it possible for attackers to set up sites with phony baloney SSL certificates which look and act like the real McCoy. I think we’ll be seeing a lot of revoked and reissued certificates this week. Nobody is likely to be happy about this except for CAs, who stand to profit from this debacle (although, since they had nothing to do with causing the problem, can we blame them?)
Obviously, any site which was Heartbleed vulnerable needs to get new certs toot sweet. But what about sites which were not vulnerable? From a technical point of view, if you never ran one of the vulnerable versions of OpenSSL, you really don’t need to buy a new certificate. However, given the fact that Heartbleed was around for 2 years, site owners will have to think back to whether they were ever running vulnerable software in combination with their current certificates. Hope you had good version control on your site!
And its not just web servers we need to worry about. Other, non port 443 services like email, databases, directory services, APIs and the like also use OpenSSL to protect their communications in transit. We may be hearing about Heartbleed attacks on these services in the coming weeks and months.
Finally, I think it is safe to assume that phishers are going to make the most of Heartbleed – fake “password reset” notices will be filling our inboxes, trying to make the most of Heartbleed hysteria to steal credentials in a low tech fashion.
So, expect Heartbleed related heartburn for the foreseeable future, folks…
In addition, the same company claims to have defeated the Activation Lock feature which cripples lost/stolen phones by:
Getting a good photo of the target’s fingerprint
Making a fake finger mold
Putting the device into airplane mode
Going to another computer and requesting a password reset on the target’s Apple ID
Unlocking the phone with the fake fingerprint
Turning airplane mode off just long enough to receive the password reset email and resetting the password on the account.
Once this is done, the attacker would have the ability to unlock the phone. The key to this attack is getting the phone into airplane mode, which can be done from the lock screen if Siri and/or the Control Center are enabled on the Lock Screen. I would again recommend that 5s users turn off access to Siri and Control Center from the Lock Screen.
The same webpage includes a video showing the fake fingerprint technique used successfully on another phone as well as on a Lenovo laptop.
It is starting to look like fingerprint based authentication on corporate/consumer devices is still a work in progress and CISOs in organizations with BYOD policies need to do a risk analysis to determine whether the convenience of fingerprint authentication is outweighed by the potential risks. This is not a “one size fits all” calculation and really depends on the profile of your attackers. For some organizations, this is easy – I would hope that a defense contractor targeted by nation states would not use fingerprint authentication. For small businesses or consumers who are mostly concerned with device loss and non targeted theft, fingerprints may be good enough (especially if devices were not protected with passcodes in the past. Unfortunately most businesses fall somewhere in the middle of these two cases.
PS – One small positive item I left out from my previous posts on this topic… if you power off your 5s altogether or have not authenticated to the phone for 48 hours, you will be required to enter your passcode to access the phone.
Some interesting insight on security and Apple’s TouchID fingerprint sensor from a quite comprehensive review of the 5S by Andrew Cunningham over at Ars Technica…
For my part, what Touch ID did do was make me more comfortable with using a complex passcode to protect my phone. I protected my previous iPhones with a standard four-digit passcode and by turning the “wipe phone after 10 unsuccessful unlock attempts” option on (which we recommended if you’re using a simple passcode, since otherwise a determined attacker will eventually be able to input the correct code from one of the 10,000 possible combinations). Previously, a complex passcode was too inconvenient for me to bother with, since it made quickly unlocking my phone too difficult. Now, Touch ID makes it so that you only need to input that passcode in a limited number of scenarios—if your phone has just rebooted, if you haven’t unlocked your phone in 48 hours, or if you’re trying to change your phone’s security settings.
You can set a complex passcode by going into Settings/General/Passcode lock.
