In this latest round of Newegg vs. the patent trolls, Newegg went against a company that claimed its patent covered SSL and RC4 encryption, a common encryption system used by many retailers and websites. This particular patent troll has gone against over 100 other companies, and brought in $45 million in settlements before going after Newegg. We won. Winning against these trolls has become a national pastime for us.
Source: Newegg vs. Patent Trolls: When We Win, You Win – Unscrambled
Basically, by generating a specially crafted SSL certificate, attackers can regenerate a bug and cause apps that perform SSL communication to crash at will. With our finding, we rushed to create a script that exploits the bug over a network interface. As SSL is a security best practice and is utilized in almost all apps in the Apple app store, the attack surface is very wide.
via “No iOS Zone” – A New Vulnerability Allows DoS Attacks on iOS Devices ».
This exploit only crashes a device making it unusable. There is no mention of making end to end encrypted communications vulnerable. By moving outside the range of the access point the IOS device automatically connected to should break the connection bringing the phone back to normal.
Devices with wifi left on will try and connect themselves to any open access point. While this shouldn’t be a problem attacks like this can happen. I would classify this attack more of an irritant than anything serious.
In this case, performing a man-in-the-middle attack would require the attacker to attack the SSL certificate first before being able to snoop on someone’s traffic.
For whatever reason, however, Gogo Inflight Internet seems to believe that they are justified in performing a man-in-the-middle attack on their users. Adrienne Porter Felt, an engineer that is a part of the Google Chrome security team, discovered while on a flight that she was being served SSL certificates from Gogo when she was requesting Google sites. Looking at the issuer of the certificate, rather than being issued by Google, it was being issued by Gogo.
via Gogo Inflight Internet is intentionally issuing fake SSL certificates – Neowin.
Issuing fake SSL certificates is clearly a deceptive practice that should be illegal for providers of wifi. This article shows a good reminder that an attacker must get your permission from your system to grant the fake certificate and pop up windows explaining this on most systems are very clear. Never click yes when this window pops up unless on a secure network with prior knowledge as to the purpose for the certificate issuance.
Past reports on Gogo from this blog here and here.
Apparently Gogo’s Terms of Service may claim hijacking SSL connections is an acceptable form of “filtering.” Beware of any open wifi system that does this. It’s bad enough with third party script kiddies hijacking your sessions let alone the provider of your network.
Acknowledgement of Filtering and Restriction of Access to Pornography or Other Offensive or Objectionable Material. You specifically acknowledge and agree that Gogo may, as a necessary incident of providing the Service, or as required or permitted by law, by law enforcement authorities or by the host airline, or as hereby expressly contemplated by this Agreement, use any advanced blocking technologies and other technical, administrative or logical means available to it, to identify, inspect, remove, block, filter, or restrict any uses, materials or information (including but not limited to emails) that we consider to be actual or potential violations of the restrictions on use set forth in this Agreement, including, but not limited to, those activities that may subject Gogo or its customers to liability or danger, or material that may be obscene, lewd, lascivious, filthy, excessively violent, pornographic, harassing, or otherwise objectionable.
So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.
OpenSSL is not developed by a responsible team.
This is a pretty serious problem so I’ll devote more space to another collection of tidbits from various sources.
EDITED TO ADD (4/9): Has anyone looked at all the low-margin non-upgradable embedded systems that use OpenSSL? An upgrade path that involves the trash, a visit to Best Buy, and a credit card isn’t going to be fun for anyone.
via Schneier on Security: Heartbleed.
From: https://news.ycombinator.com/item?id=7548991
The fact is that no programmer is good enough to write code which is free from such vulnerabilities. Programmers are, after all, trained and skilled in following the logic of their program. But in languages without bounds checks, that logic can fall away as the computer starts reading or executing raw memory, which is no longer connected to specific variables or lines of code in your program. All non-bounds-checked languages expose multiple levels of the computer to the program, and you are kidding yourself if you think you can handle this better than the OpenSSL team.
We can’t end all bugs in software, but we can plug this seemingly endless source of bugs which has been affecting the Internet since the Morris worm. It has now cost us a two-year window in which 70% of our internet traffic was potentially exposed. It will cost us more before we manage to end it.
Ironic how the above link uses https. The Ars Technica article below has interesting screenshots.
From: Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style
For an idea of the type of information that remains available to anyone who knows how to use open source tools like this one, just consider Yahoo Mail, the world’s most widely used Web mail service. The images below were recovered by Mark Loman, a malware and security researcher with no privileged access to Yahoo Mail servers. The plaintext passwords appearing in them have been obscured to protect the Yahoo Mail users they belong to, a courtesy not everyone exploiting this vulnerability is likely to offer. To retrieve them, Loman sent a series of requests to servers running Yahoo Mail at precisely the same time as the credentials just happened to be stored—Russian roulette-style—in Yahoo memory.
If you’re using an older OpenSSL version, you’re safe.
via OpenSSL bug CVE-2014-0160 | The Tor Blog.
I find that statement quite interesting due to how many security experts tout keeping your software constantly updated without realizing sometimes updates can introduce exploit vectors.
From: The Heartbleed Bug
What makes the Heartbleed Bug unique?
Bugs in single software or library come and go and are fixed by new versions. However this bug has left large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitation and attacks leaving no trace this exposure should be taken seriously.
Am I affected by the bug?
You are likely to be affected either directly or indirectly. OpenSSL is the most popular open source cryptographic library and TLS (transport layer security) implementation used to encrypt traffic on the Internet. Your popular social site, your company’s site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL.
From: Exploits allow attackers to obtain private keys used to decrypt sensitive data.
They called on white-hat hackers to set up “honeypots” of vulnerable TLS servers designed to entrap attackers in an attempt to see if the bug is being actively exploited in the wild. The researchers have dubbed the vulnerability Heartbleed because the underlying bug resides in the OpenSSL implementation of the TLS heartbeat extension as described in RFC 6520 of the Internet Engineering Task Force.
Public and Private keys form cryptographically matched pairs. It is not feasible to derive one from the other, yet what one encrypts only the matching other can decrypt. Website SSL security certificates provide the site’s Public cryptographic key which is the public side of the server’s secret Private cryptographic key which is never publicly disclosed. Only the certificate’s public key can be used to encrypt data which the remote server can decrypt only using its matching private key. Since the SSL Proxy Appliance does not have the private key of the remote server—because only the remote server has it—the fake & fraudulent certificate the SSL Proxy provides to the user’s web browser is forced to use a different public key for which it does have a matching private key. And that means that no matter how hard any SSL-intercepting Proxy Appliance may try to spoof and fake any other server’s certificate, the certificate’s public key MUST BE DIFFERENT
via GRC | SSL TLS HTTPS Web Server Certificate Fingerprints
The remote server’s REAL certificate and the SSL Appliance’s FAKED certificate MUST HAVE AND WILL HAVE radically different fingerprints. They will not be remotely similar..
The technical details get very complicated very quickly, but what it all amounts to is simple enough. The proposal expects Internet users to provide “informed consent” that they “trust” intermediate sites (e.g. Verizon, AT&T, etc.) to decode their encrypted data, process it in some manner for “presumably” innocent purposes, re-encrypt it, then pass the re-encrypted data along to its original destination.
In essence it’s a kind of sucker bait. Average users could easily believe they were “kinda sorta” doing traditional SSL but they really wouldn’t be, ’cause the ISP would have access to their unencrypted data in the clear. And as the proposal itself suggests, it would take significant knowledge for users to understand the ramifications of this — and most users won’t have that knowledge.
This editorial illustrates that Man In The Middle (MITM) attacks cannot happen without user consent. This blogger fears that ISPs will require consent for all SSL sessions making all users’ end to end encryption vulnerable to a “trusted” proxy. Here is a blurb in the draft.
From the IETF draft: Explicit Trusted Proxy in HTTP/2.0 draft-loreto-httpbis-trusted-proxy20-01
This document describes two alternative methods for an user-agent to automatically discover and for an user to provide consent for a Trusted Proxy to be securely involved when he or she is requesting an HTTP URI resource over HTTP2 with TLS. The consent is supposed to be per network access. The draft also describes the role of the Trusted Proxy in helping the user to fetch HTTP URIs resource when the user has provided consent to the Trusted Proxy to be involved.
The consent is supposed to be on a per network (or destination) basis which means there may be a reason the user agent will want to use a trusted proxy — perhaps they do not trust the destination network. The blogger implies ISPs will want blanket consent over all destinations which 1) they could implement now without this standard and 2) this would not make for a good PR move because it would not go unnoticed.
But Jones didn’t invent SSL; nor did he invent RC4, an algorithm invented in 1987, two years before the filing date of the Jones patent.
Whatever his invention is, it came before the World Wide Web, which was made available to everyone in 1993. Jones filed for his patent in 1989, and it uses some distinctively pre-Web vocabulary; describing encryption via modems and phone lines.
via Newegg hurtles toward Texas showdown with famed “patent troll” | Ars Technica.
By claiming such common encryption, the TQP patent is essentially a “we-own-the-Internet” patent. Spangenberg declined to speak to Ars for this story, but in an August interview he said the TQP licensing campaign has reaped around $40 million in revenue.
Too hard. Let’s try some side channels. Let me show you how you can view all SSL encrypted data, via exploiting Amazon 1Button App installed on your victims’ browsers.
via Jealous of PRISM? Use “Amazon 1 Button” Chrome extension to sniff all HTTPS websites!.
tldr; uninstall NOW!