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.
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.
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.
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”.
Oh, come on, already!
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
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.
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 day, another Android vulnerability which allows malicious actors to inject malicious code into Android applications without triggering cryptographic safeguards. And another reason to refrain from using app stores other than Google Play for the time being.