Jul 13

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.

 

 

Jul 12

While the “Internet of Things” has great potential, it also opens up new attack surfaces for those with nefarious intent to exploit.  A good example of this was found by a security researcher last week.  LIFX offers wifi controlled LED light bulbs that can be turned on an off as well as color adjusted via an iOS or Android app.  In order to operate, the light bulbs must authenticate to the wireless network in the user’s home or office.  The researcher found that it was possible to retrieve the wireless network password from the bulbs themselves, giving them access to the rest of the devices on the same network.  LIFX has issued a patch to correct this issue, but this serves as a reminder that all of those new, whiz bang network connected devices are part of your network’s security perimeter.   Many of these devices are coming from startup companies which may not have a security culture embedded in their development process.   To be fair, the researcher had to do some fairly sophisticated to pull off this hack, but as IoT devices begin to proliferate, the payback for attackers will be worth the extra effort.

Jul 04

 

BAE Systems Spokeman

An update on the “hedge fund hacking” story from a couple of weeks ago… it appears that this attack (in which it was alleged that hackers penetrated hedge fund trading , delayed HFT orders and sent order information to servers in eastern Europe) did not actually happen. Apparently, this scenario was used internally at BAE Systems as a “what if” during table top exercises. For some reason, a BAE employee described this scenario to a reporter as if it was an actual incident. This is a real black eye for BAE (which probably explains why they waited for the holiday weekend to announce this).

More information:

http://www.cnbc.com/id/101807792

I still think that the kind of attack described in this scenario is bound to happen in the future as organized crime figures out that the capital markets provide much more profit potential than stealing credit card info – but there is no confirmed case of such an attack happening so far.

Jun 20

Ready cash – the ultimate attacker tool?

Cybersecurity firm BAE Systems (a large and credible industry player) announced that it had found and remediated an attack on an unnamed hedge fund back in late 2013 which placed malware on the firm’s servers which intercepted HFT trades, delayed their execution, and sent information about the trades to a third party server. BAE believes that “organized crime” was behind this attack.

If this report is accurate, it marks a new level of sophistication and business insight by attackers – rather than simply stealing random information or creating denial of service situations, these guys used knowledge of the financial industry (and at least some significant level of capital) to profit from their hack. Apparently, the attack went unnoticed for 8 weeks.

The firm’s report also mentions another attack on an insurance firm, where the attackers created bogus insurance policies in the firm’s underwriting systems and then file claims against them.

This is a new attack trend that I have been expecting to see for some time – now that attackers have gotten really comfortable and successful with the technical side of hacking, the next logical step is to combine these skills and wins with business knowledge and capital to create much more sophisticated, profitable and (for victimized companies) potentially devastating attacks.  The financial services industry needs to take this incident seriously and adjust its view of the motives and sophistication of attackers.  While we have all talked about the theoretical possibility of hacks like this one, it has always seemed to be one of those “just over the horizon” threats.  Well, this new bit of news should firmly place these blended cyber/business/capital attackers and attacks on our radar.

While we don’t know exactly how the attackers gained access to the servers in question, I would be pretty surprised if a workstation malware compromise was not one of the first steps in the attack chain.  Another reason to keep bolstering our workstation defenses – patching, EMET, browser virtualization, behavioral based malware detection, and web filtering and blocking.  And another reason to have a conversation with your employees about just how perilous the landscape is becoming.

 

May 08

encrypted.jpgA security vulnerability in the way that online storage provider DropBox (and possibly rival Box) handles links to shared files caused some documents (which were supposed to be viewable only people designated by the file owner) accessible and available to web site owners using Google’s visitor analytics and advertising tools.  The rival online storage firm which found the issue claimed to have reported the problem (which gave access to sensitive files like mortgage documents and tax returns) to Dropbox last November.  Dropbox fixed this issue, which it insists is a feature rather than a security flaw, this past Monday.

This issue highlights the need to make encryption of files and data stored on cloud service providers with keys stored on the user’s local system simple enough for non technical folks.  The solution also needs to be able to support sharing of encrypted files securely with a third party or with other cloud services you authorize.  If cloud providers can get this right (no small feat), living your life in the cloud will truly be ready for prime time.

Some solutions which currently exist:

  • Boxcryptor is a software solution which sits on top of Dropbox and other storage providers and automagically encrypts files as they are sent to and received from the cloud.  They provide secure sharing as well as mobile apps for the major platform.  Of course, since Boxcryptor is an overlay to services like DropBox, using this product would break the integration between DropBox and other cloud apps.
  • There is at least one consumer usable provider (SpiderOak) which currently claims to offer this type of Zero Knowledge Encryption.

The real answer to the issue of cloud encryption lies in having the encryption built in to the platforms in a standard and interoperable way.  C’mon cloud vendors, you can do it!

 

May 04

One of the nice things about Apple’s iOS platform is the “hardware level encryption” that protects “all of the information on the device.”  At least, that used to be the case.

Starting in iOS 7,  email attachments stored on iPhones, iPads, and iPod Touches (remember those?) are not stored in encrypted form.  A security researcher recently announced that he was able to retrieve plaintext attachments from encrypted iPhones using standard forensic tools.  Apple never corrected its previous statements indicating that all data in iOS was “protected by hardware encryption,” so millions of personal and business users have been working under a false assumption of security for a couple of months now.

When the researcher reported the issue to Apple, he was told that they were aware of it but had no date for a fix.

This is why I continue to recommend that corporate users stick with containerized solutions for their iOS and Android mobile users.  Consumer level mobile devices are not designed with the level of security appropriate for business (especially in highly regulated industries like Finance and Health Care).  Yes, it would be nice to use the native apps on personal devices to deliver corporate data from an ease of use point of view, but if your users are carrying around sensitive information in their email attachments, you have to consider the risk of an adversary extracting that information from the device relatively easily.

Apple really dropped the ball on this one.  They were not up front with their users regarding the loss of a key security feature and didn’t give them the chance to make an informed decision based on that information.   Not cool.  This incident underline’s Apple’s lack of commitment to and understanding of  the corporate market.  If they want to be a corporate player, they need to step up and accept the responsibilities that the role entails – otherwise, stop trying to do things half way, guys.

May 04

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.

Apr 30

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.

Apr 27

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.

Apr 20

Heartbleed strikes again… according to respected security consulting firm Mandiant, one of its corporate customers’ SSL VPN appliances was compromised by attackers using the Heartbleed vulnerability.  The attackers were able to hijack logged in sessions and thus access the organization’s network.  The key to detecting hijacked sessions is to look for log entries which show sessions switching between two different IP addresses at short intervals.  Mandiant isn’t telling which vendor’s SSL VPN is vulnerable, but Cisco,  Juniper, and the open source OpenVPN project have all issued security advisories related to Heartbleed.   Infosec people should be checking for new VPN vendor patches and scanning logs for telltale IP address changes.

 

 

preload preload preload