Almost five million gmail credentials were posted to a Russian language bitcoin forum a few days ago. Google’s official position is that these credentials were harvested externally and that gmail itself does not have a vulnerability that has allowed credential disclosure.
This seems like a reasonable position given the limited (relative to the massive number of gmail users) number of credentials leaked. I believe the list was harvested through the use of password stealing malware or through social engineering (e.g. phishing) and/or a combination of such techniques. Some of the leaked passwords appeared unlikely to have been dictionary cracked so a leak of hashed passwords from Google looks even more unlikely.
UPDATE: A site has appeared – isleaked.com (unfortunately also Russian language) to allow concerned users to search the list of leaked credentials to see if they are affected. I would not personally enter my gmail address into a web resource published by an unknown party, as while the author’s intent may be benevolent it is also equally likely that form submits are being harvested for unsolicited email lists.
UPDATE: PC World and the mainstream tech media have taken up the story.
Matt Green recently blogged about the shortcomings of PGP for e-mail encryption. He makes some valid points, and without a doubt the trust management of PGP and its clone GNUPG is probably its Achillies’ heel. The “web of trust” was supposed to counter the issues inherent in heirarchical certification authority schemes like X.509, and for the most part it does a reasonable job at doing just that when the number of group participants are small. In the real world it suffers from much of the same human factors that have brought the CA style model into question over the past decade. There isn’t an easy answer to this ongoing engineering problem and until a reliable, decentralized way of establishing identity is developed. I suspect that the ultimate solution will draw inspiration from current cryptocurrency “proof of work” type systems.
Seeing as I have unfortunately been away from this blog for a while I figured it best that I update my canary document so that nobody need concern themselves that I have been compromised. I will endeavor to return to providing a high quality commentary on the current matters of concern within our industry within the following few weeks as my personal situation slowly returns to normal.
I have been away from this blog and most of my other responsibilities for a little over a week as a result of tending to some family issues and preparing ourselves for a move across town.
Fortunately I will be back on track in the next few days and will update this blog again very shortly.
I was asked by a reader who I assume wishes to remain anonymous to post the following thesis on here. In PDF format, here is the document entitled, “Converting .GOV to .MIL: The Pentagon’s Recipe for Wet Dreams of War, the Never-ending Climax“
Oracle recently announced an update which patches twenty separate vulnerabilities all of which individually can provide remote access to an affected system without authentication. I’ll re-iterate that just in case you figured it was a mistake on my part: each of the individual twenty CVEs mentioned in their patch summary pose a direct remotely exploitable risk to a machine running their Java VM.
Those of you who have been reading my blog for a while will know how I feel about Java – more specifically the official implementation, and I realize that I am, to an extent, preaching to the converted. I realize that those who are still running the Oracle JVM are doing so for a very good reason and that there are custom application suites which have been developed specifically for certain niche industries where it is simply infeasible to even consider migrating to any sort of alternative solution.
That said there are literally millions of home and small business machines with the Oracle JVM on-board for no good reason other than that the OEM decided it was a good idea (along with all of the other bloat that vendors typically include for reasons no intelligent engineer can understand). The world wide web has pretty much abandoned the Java experiment, and it is safe to say that most users in the aforementioned group are needlessly increasing the risk profile and exposure of their PC.
I’d like those of you who are stuck with the Oracle JVM to just take a few minutes to consider whether there is anything your organization can do (over and beyond the obvious – staying up to date on patches) to reduce the risk to your enterprise. Can an alternate Java virtual machine be substituted? Can you apply the principle of least privilege to at least minimize the amount of damage a compromised Java VM could actually do to your infrastructure?
… and finally, most importantly, the most important question of them all: how can your enterprise extricate itself from requiring this behemoth of bad engineering?
Brian Krebs reports that the US Secret Service is warning those in the hospitality industry to beware of keylogging devices being attached to publically accessible computers, quoting a circular stating that the “malicious actors were able to utilize a low cost, high impact strategy to access a physical system, stealing sensitive data from hotels and subsequently their guest’s information.”
Public machines are a great choice for such operations as they are often used by people who are ‘caught out’ whilst vacationing and suddenly have need to transfer some cash to cover an unexpected expense or have a quick look at their work email. The diverse mix of people you would get in such an establishment would provide ample opportunity and expose the perpetrators to little risk, especially with the newer generation keylogging devices which are self powered (via 5V from the USB bus) and allow for remote dumping of their buffer (which can be extremely large, i.e. megabytes) via bluetooth from some distance away. Having to only touch the computer once (to plant the keylogger) is a definite advantage. A member of the cleaning crew could potentially swap a computer keyboard for one of the same design which has had the keylogging component secreted inside the keyboard’s enclosure, making detection via simple visual inspection highly unlikely.