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.
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).
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.
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.
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.
If you are using Google Chrome to surf the series of tubes we professionals cal the Interwebs, you need to take action to reduce the risk of getting scammed by compromised SSL certificates. According to this post over at Net craft…
However, most Google Chrome users are left in the dark, as Chrome performs neither type of check for non-EV certificates by default. Instead of conventional revocation checks, Google Chrome relies on an aggregated list of revocations, dubbed CRLSets, which are compiled by Google. The revocations from GlobalSign’s CRL have not yet appeared in Google’s CRLSets and hence Chrome users will not be warned if presented with a potentially compromised, but revoked, CloudFlare certificate.
The CRLSets deliberately do not cover all CRLs in an attempt to reduce the total size of the aggregated list. In effect, Google has traded the completeness of their revocation checking for a speed advantage over rival browsers as downloading CRLs or making OCSP requests imposes a performance penalty.
Google Chrome setting to enable revocation checking.
However, it is possible to configure Google Chrome to check for revocation. There is a checkbox in the Advanced settings menu to “Check for server certificate revocation”.
Think your sites are safe from Heartbleed related sploits? Not so fast, sunshine…
According to one pen tester, many of the tools which purport to detect servers vulnerable to the Heartbleed bug are buggy themselves, leading to false negative results, and in turn, a false sense of security allowing vulnerable sites to stay vulnerable. According to his testing, Qualys SSL Labs site is the most accurate “big name” source for checking your servers. He has also released a script called Cardiac Arrest, which he claims is more accurate than other Heartbleed tests. If you have already “cleared” your sites using the tools released right after the bug was announced, you might want to double check your results using one of these tools just to be sure.
It also turns out that certificate authorities are not the only ones profiting from Heartbleed. Because many, many organizations are busily revoking potentially compromised digital certificates, the certificate revocation lists (CRLs) which browsers download in order to avoid trusting these out of date certs have been ballooning in size, from just a few kilobytes to megabytes. These CRLs get downloaded from the CAs millions of times a day, leading to additional bandwidth charges from their ISPs. So now we have two sections of the Internet economy benefiting from Heartbleed.
Finally, the Canadians have arrested a teenaged hacker in connection with an attack on the Canadian Revenue Authority’s e-filing website which resulted in around 900 taxpayers’ personal information being disclosed.
Aaaand we now have our first confirmed breach of data tied to Heartbleed – the Canadian Revenue Authority has reported that the social insurance numbers of about 900 Canucks were downloaded by attackers using Heartbleed. Canada’s equivalent of the US IRS had shut down their e-filing website last week when the bug was announced.
Akamai (whose network carries almost a third of the Internet’s traffic) was also in the Heartbleed news this AM… it turns out that their patch to correct their servers’ vulnerability had a bug in it. They are revoking their certificates and issuing new ones in the wake of patching the patch.
Stay tuned… I am sure there is more to come
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.
And the good news just keeps on coming – there’s a lot of client and embedded device software out there running vulnerable OpenSSL code. At least one expert thinks that malicious servers can be set up to exploit clients and extract passwords and crypto keys from devices which connect to them. While Apple’s OS X and iOS products are Heartbleed-free, Android version 4.1.1 (said by Google to be in use on millions of devices) is vulnerable to the bug.
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…
Another attack on the iPhone 5s TouchID sensor… a German security firm has claimed to be able to use an iPhone 4s camera to grab a fingerprint image and then make that image into a fake finger mold. It still takes a bit of effort, but one barrier to entry (hi res camera) has been removed.
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.