My Apologies For The Brief Hiatus

Aside

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.

More Java Vulnerabilities

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?

USSS Warns Hotel Operators To Check Machines for Hardware Keyloggers

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.

GCHQ Catalog Leaked

Aside

Several months ago Greenwald et. al. reported on the NSA’s TAO division and provided a somewhat redacted copy of what amounts to their “spy catalog”. Yesterday the GCHQ’s catalog was leaked and there indeed appears to be many similarities in capability to their American allies.

Blogsig Spec Progress Report

I figured I had better give y’all a brief update on how my specification documentation for blogsig is coming along. As it turns out defining a spec is a bit like looking into a crystal ball, as you have to try and anticipate any future changes to the standard and how someone would implement them. The most long lived protocols are ones that have an innate ability to be easily modified and upgraded as time goes by and the needs of the users change. However this often isn’t the best way to engineer a security related protocol as such modularity can often be used against you, for example TLS and its vulnerability in certain configurations to a cipher downgrade attack.

So again we run into the age old problem where engineering in modularity and making your protocol more upgradeable could potentially compromise its security. The answer is always going to be a compromise but I believe that we will try and get the balance right.

Another practical design goal for blogsig was to have the signature take up no more than a single traditional 80 column line. Fortunately this was easy enough to achieve, but there are certain features that probably should make their way into the spec despite everything I have already mentioned.

The traditional PoC browser plugin – once it had found a blogsig string would parse out the length from the blogsig line and use a fuzzy algorithm to find, through trial and error based on an educated guess (derived from the length field – which you must remember will never be absolutely correct due to the way that blogs reformat text) where the first character of the encoded message is located. Obviously this is a matter of continually validating until we find the honey spot. This is very time consuming and slows down the identification and processing of the signature significantly.

The most obvious solution would be to have a PGP style BEGIN header but this quite flagrantly violates two of our design goals, those being a) the blogsig must add just one line of a maximum of 80 characters to any post, and; b) the blogsig should waste as little space as possible within the post.

I am playing with a potential solution where the first eight characters of the post are encoded within the blogsig (which isn’t a problem as we are consistently coming in well under our 80 character limit) and this is used in addition to the length information to assist the detection algorithm in finding the beginning of the post in a rapid manner. Obviously a “meet me in the middle” compromise solution would involve the use of a header, but one that is far more unobtrusive – perhaps an unused Unicode character or a sequence of a few low ASCII characters that are unlikely to find themselves in normal conversation, like +BsG:

Of course my simple algorithm that searches “near” the boundary inferred from the length encoded in the blogsig works just fine: it just isn’t particularly efficient. An optional combination of all of the above may be the most flexible, but again, I feel there is a much more simple solution staring me in the face.

The final solution is to have the browser plugin that does the verification to be somewhat blog platform aware. Fortunately there are only a handful of blogging software that runs well over 50% of the Internet’s blogs. A blog agnostic solution – like the “hunting” algorithm I described earlier – could be used only on blogs that the plugin is not aware of. Fortunately most of the popular blogs use a pretty sensible format and the post divider is generally within one or two lines of the beginning of the text.

John Young’s Effort To See The Snowden Documents Released

Cryptome, the infamous repository of daylighted classified information run by John Young and a number of other volunteers, posted a few interesting tweets on their feed about two weeks back suggesting that they may have possession of some of the unreleased (and unredacted) Snowden material and that they were going to release it in July to prevent a “war” – his later tweet clarified that he was speaking about the current ISIS situation, stating that “ISIS war would not be happening … [if documents were released] … July war not averted.”

Well, we are now well and truly within the month of July and I had yet to see anything more on this subject so I figured I would visit Cryptome to see if there has been any movement. On the site’s front page is a link to a PDF which is effectively a demand for the documents to be released, addressed to the relevant news organizations involved. So I don’t believe that this is going to happen, barring the intervention of a ‘safety’ (one assumes that Snowden gave a few of his most trusted buddies the raw material to release in the event that he was disposed of).

Unfortunately, it still remains in the interests of the newspapers involved to keep the documents and slowly roll out the stories over an extended period of time. I suspect that after the Guardian’s UK office was raided that the news organizations involved have been, uh, ‘briefed’ on what journalism really is all about in the 21st century, remembering that the government could potentially make things difficult for their newspaper companies (or easier for their competitors).

Young’s Cryptome has always been an excellent resource, but I just don’t think that this will even come to close to attaining the level of interest and inertia that such a protest would need in order to get the attention of the powers that be. However, I suspect that the documents will eventually see the light of public scrutiny. Edward Snowden isn’t an unintelligent man, and he would have ensured that multiple people with different agendas had access to the source material. One can’t keep a united front together indefinetely when there are ego’s at work.