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.

 

 

Apr 18

13470965718If 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”.

 

 

Apr 18

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.

Apr 14

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

Apr 13

heartbleedIt 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…

 

Jul 12

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.

Tagged with:
Jul 11

Via Gizmodo

Mar 20

Yes… hover and check…

If you are like me, “hover over the link and read the URL before you click” is a basic piece of advice you give to people who want to know how to avoid malicious links in web pages and emails.  Well, it looks like a little bit of Javascript trickery can be used to make malicious links look benign until they are clicked.  While email clients like Outlook will not execute Javascript in messages, links in web applications or webmail accounts could be disguised in this way.  Sounds like we need a browser based fix to combat this – it is possible, since Opera apparently is not fooled by this behavior.

Nov 28

Interesting post from security and cyberwarfare blog Digital Dao on how changes in Russian law will make it more difficult for foreign firms and investigators to track down the owners of .ru domains used for nefarious purposes.  Not a positive development.

Oct 14

Here is a textbook description of what companies should NOT do when someone privately reports a security vulnerability in their publicly available web site which is chock full of PII…

SC Magazine:
Security Researcher Threatened with Vulnerability Repair Bill

A couple of observations about the article…

The guy who found and reported the vulnerability was a customer of the firm in question and seems to have done everything in an above board manner.

It sounds like the vulnerability involved changing a single parameter in a URL in order to access another customer’s account.  Whoever designed/wrote that application needs some serious re-edumacation at the very least.  Maybe these are the folks who should be paying to fix the vulnerability.

I’m not sure why they are demanding the researcher’s computer.  The nature of the vulnerability would make it extremely easy to make sure he did not access additional PII by simply reading the web server logs.

I’ll bet that plenty of people at this organization are wishing that this incident never hit the news.  Had they simply thanked the researcher and fixed the bug, their customers and business would have been protected and they would not have gotten such a public flogging.  If I were a customer of theirs, I’d be wondering about the rest of their information security right about now.

So, to sum things up… WTF!

 

 

preload preload preload