Hi everyone! I’ve been away for quite a while. Work and family life have got the best of me, and I simply haven’t had much time to do anything remotely enjoyable – and well, authoring articles for this blog falls into the latter bucket. I have leave coming soon and intend to spend at least some of that time catching up with the people over at Bruce Schneier’s website and those who have commented here and/or e-mailed me. I apologize for the delay.
The canary has been updated and re-signed less someone think I’ve been taken captive by the CIA and forced to eat rodents for dinner. I am considering doing away with the canary page due to its limited utility, I make a brief but considered statement about this on the canary page itself.
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?