It’s a truism often repeated: Don’t roll your own cryptography! There are countless traps laying in wait for the unwary—so stick to trusted, tested libraries and beware the unknown unknowns.
The recent brouhaha around the UK police CyberAlarm service deftly shows why. Security researchers have been pointing and laughing at some absolute howlers, calling it “profoundly dangerous,” “woefully insecure,” “very broken,” “nonsense” and “a dream come true for hackers.”
When it comes to cryptography, we simply don’t know what we don’t know. In this week’s Secure Software Blogwatch, Messrs. Dunning and Kruger would like a word.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: The “future” in 1984.
[ Get key takeaways from a survey of 300+ professionals on software security. Or, download the full report: Flying Blind: Firms Struggle to Detect Software Supply Chain Attacks ]
Wake up—don’t snooze
What’s the craic? Scott Arciszewski keeps a cool head and dispassionately reports—“CyberAlarm Uses Alarming Cryptography”:
“CyberAlarm is not secure”
Today we’re going to be talking about this code, shared on Twitter by Paul Moore. [It’s] a novel cryptographic implementation … clearly written in order to support a data format migration. … However, they never took the time to learn the proper way to handle cryptographic migrations:
…
Remove the value between the first :: and the second :: … re-encode it with base64, then feed this altered message into the system. … Now you’ve successfully downgraded the message to the legacy format, which didn’t provide any authentication over the ciphertext. [Or] we can completely bypass the HMAC check [by simply] removing the length prefix. … Using either of the two methods … you’ve reduced the security of this construction to unauthenticated AES-CBC mode, which is vulnerable to a Padding Oracle Attack.
…
[It] doesn’t expose an Additional Authenticated Data mechanism. All fields are also encrypted with the same, static, hard-coded key. … To mitigate confused deputy attacks, an AEAD construction is recommended.
…
[It] uses the same encryption key for both AES-CBC encryption and for HMAC-SHA256. This violates one of the tenets of cryptography protocol design: Never use the same key for more than one purpose. … The correct thing to do is use a key derivation function.
…
The cryptography used by Police CyberAlarm is not secure and should be replaced with something more secure. … There’s enough vitriol in the security industry. I don’t feel like … making a neophyte’s impostor syndrome worse than it already is.
Who raised the alarm? Paul Moore lays down the lore—“Abysmal security, yet again”:
“It has utterly failed”
18 months ago, I reviewed two versions of Police CyberAlarm. … After many hours of reviewing some of the worst code I'd seen in quite a while … I responsibly disclosed everything. … However, their responses were both defensive and dismissive—to the extent of [saying] my claims were "completely untrue."
…
In February, a network admin from a local School reached out, asking me to audit CyberAlarm again. … So, 18 months later, is it any better? … Over the next couple of hours, I created a list of serious issues [and] several critical flaws. … CyberAlarm is profoundly dangerous. It's woefully insecure, ill-conceived, poorly written and provides questionable value.
…
[1] Locally stored passwords are still hashed with unsalted SHA256, but incredibly … passwords are actually sent to and returned from the central API in plain text! … An attacker can simply request it from the API. …
[2] Any attacker can remotely control the box if they know the current time and can count to 9,000. … To a local endpoint, this takes around 2.5 seconds to complete. … Don't worry about writing it to a log or limiting further requests—just abort and let the attacker try again. …
[3] The central API has no authentication whatsoever! Want a customer's records? Sure. Make a GET request with the data collector's ID and it just hands it over. … Surely we can't update a record without authentication? Of course we can! …
[4] If you're going to compare two password hashes, it's vital to compare them using a timing-sensitive comparison. Rookie mistake … PHP created "hash_equals" for a reason. …
[5] They've tried to roll their own crypto; breaking the cardinal rule of cryptography. There are only two possible outcomes here: Broken and very broken.
…
[It’s] had 3 attempts and well over 18 months to develop cyberAlarm into something resembling a decent, secure and deployable application. [But] judging by this latest iteration, it has utterly failed to do so.
Are you experiencing any déjà vu? Set your trusty time machine back 19 months or so, when Gareth Corfield wrote this—“Bitter war of words erupts between UK cops and web security expert”:
Paul Moore says he uncovered what he described as a number of serious flaws in CyberAlarm, a distributed logging and monitoring tool intended to be deployed by small public-sector organisations. … A free tool, it is intended to give police direct visibility of online threats. … In essence it's a distributed firewall log monitoring system: end users deploy CyberAlarm's "data collectors" on their networks in a demilitarised zone and those then send alerts to the local police.
…
We asked Pervade's director Jon Davies to comment. [He said] that prior to publication of [his] review, Moore had "reported in to us 20-something issues, all of which were to do with the live version. Some of which we were able to take some helpful things from."
Are we sure Moore and Arciszewski are correct? amluto backs them up:
Reading the code, I found it challenging to find a severe crypto bug—simply because everything is wrong. Even their way of packing the data into a base64 is nonsense. The parser is nonsense. Almost every line of code is wrong. … It’s like the most severe bugs are buried in code that is 100% bug!
…
The key is a constant. I’m speechless.
But is this a big deal in practice? Yes, argues Unbelievr:
The code is clearly not written with security in mind from the beginning. … Telling people to install it behind their firewalls is a dream come true for hackers.
…
The quarrel between the original researcher and the police seems rather infantile though—on both sides. There's some legitimate criticism, and some real awkward blunders.
All of which leaves The Man Who Fell To Earth scratching their head:
Huh? … Tell me again why would I want unqualified police on my network using a crude tool specifically created for IT dummies that produces oversimplified output they can't interpret?
OK, OK, I get it. So what can we learn? Don’t roll your own cryptography, ofc. But api thinks we should go further:
We need to stop saying “don’t roll your own crypto,” and start teaching it—with good examples and good explanations. The only people who will listen to “don’t roll your own crypto” are people who [already] approach it with the needed level of humility. The people who should not be writing crypto are precisely the ones who will ignore this advice.
It’s also sort of elitist sounding. … That puts people off and further reduces the odds that they will listen.
But didn’t anyone audit or review the product? Yes, three separate organizations, each accredited and certified by CREST, alleges Paul Moore in a followup tweet:
Does it not concern you that several supposedly … accredited firms have signed off on this? It doesn't just weaken CREST-STAR — it basically makes a mockery of it.
Meanwhile, with a neat summary, here’s CommieBobDole:
Wow. Worrying about the cryptography on this thing is like worrying about the quality of the padlock you're using to secure the flaps of a cardboard box.
And Finally:
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Chuttersnap (via Unsplash; leveled and cropped)