LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point. You can also listen directly on Soundcloud.
With Doug Aamoth and Paul Ducklin.
Intro and outro music by Edith Mudge.
You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.
The cryptocurrency world is full of weird stories.
You’ve probably heard of the Welshman who who claimed he inadvertently threw away a hard disk containing bitcoinage worth $500 million, and went to his local council for permission to dig up the landfill site where he assumed it would have been dumped, offering the authorities a cut of the coins if he recovered any.
The council declined his proposal.
You’ll no doubt remember the self-styled Crocodile of Wall Street, a female musician of sorts whose self-published rap videos included one with the lyrics, “Spearfish your password/All your funds transferred”.
Heather “Croc” Morgan and her husband Ilya Lichtenstein were arrested in early 2022, charged with living a high life off income derived from close to 120,000 bitcoins that mysteriously vanished from online cryptocoin exchange Bitfinex back in 2016, and that US law enforcement allege ended up in their possession after the heist.
Technically, they weren’t charged with the heist itself, but with trying to shift around cryptocurrency that they knew to be stolen, and of telling a bunch of lies along the way to make it sound as though they had acquired the cryptocoins legitimately.
Amazingly, the value of all the bictoins when they were stolen was about $72,000,000, but the value of the 80% of them recovered in 2022 had soared to about $4 billion.
And you may recall the late cryptocurrency trading hamster, Mr Goxx, who went viral during his brief and colourful life (black-and-white at night, when infrared cameras were used) as a rodentine coinhodler.
Sadly, given how this particular story ends, US cryptocurrency developer Virgil Griffith has provided another episode in the never-a-dull-moment world of cryptocurrencies.
Griffith’s story is simply, if bafflingly, told.
According to the US Department of Justice (DOJ), Griffith decided to look into business opportunities involving North Korea and cryptocurrencies, including cryptocoin mining in the country.
As the DOJ reminds us, however:
Pursuant to the [International Emergency Economic Powers Act (IEEPA)] and Executive Order 13466, United States persons are prohibited from exporting any goods, services, or technology to [North Korea] without a license from the Department of the Treasury, Office of Foreign Assets Control (OFAC).
Griffith therefore applied to the US authorities for offical permission to travel to North Korea to speak at a cryptocurrency event entitled Pyongyang Blockchain and Cryptocurrency Conference.
His application was denied, but Griffith, perhaps surprisingly, went anyway.
According to the DOJ, as well as attending and speaking at the event, Griffith also:
Pursued plans to facilitate the exchange of cryptocurrency between [North Korea] and South Korea, despite knowing that assisting with such an exchange would violate sanctions against [the North]. [He] also attempted to recruit other US citizens to travel to North Korea and provide similar services to [North Koreans] and attempted to broker introductions for [North Korea] to other cryptocurrency and blockchain service providers.
All of this, of course, despite having no official permit from OFAC.
Griffith was arrested in the US in 2019, and after initially pleading not guilty, decided to change his plea last late last year.
He was sentenced yesterday to 63 months in prison (10 months of which he has apparently already served on remand), followed by three years of supervised release.
Researchers at healthcare cybersecurity company Cynerio just published a report about five cybersecurity holes they found in a hospital robot system called TUG.
TUGs are pretty much robot cabinets or platforms on wheels, apparently capable of carrying up to 600kg and rolling along at just under 3km/hr (a slow walk).
They’re apparently available in both hospital variants (e.g. for transporting medicines in locked drawers on ward rounds) and hospitality variants (e.g. conveying crockery and crumpets to the conservatory).
During what we’re assuming was a combined penetration test/security assessment job, the Cynerio researchers were able to sniff out traffic to and from the robots in use, track the network exchanges back to a web portal running on the hospital network, and from there to uncover five non-trivial security flaws in the backend web servers used to control the hospital’s robot underlords.
In a media-savvy and how-we-wish-people-wouldn’t-do-this-but-they-do PR gesture, the researchers dubbed their bugs The JekyllBot Five, dramatically stylised JekyllBot:5 for short.
Despite the unhinged, psychokiller overtones of the name “Jekyllbot”, however, the bugs don’t have anything to do with AI gone amuck or a robot revolution.
The researchers also duly noted in their report that, at the hospital where they were investigating with permission, the robot control portal was not directly visible from the internet, so a would-be attacker would have already needed an internal foothold to abuse any of the bugs they found.
Nevertheless, the fact that the hospital’s own network was shielded from the internet was just as well.
With TCP access to the server running the web portal, the researchers claim that they could:
Cross-site scripting is where website X can be tricked into serving up HTML content for display that, when loaded into the visitor’s browser, is actually interpreted as JavaScript code and executed instead.
This typically happens when a web server tries to display some text, such as a robot ID or ward name, but that text itself contains HTML control tags that get passed through unaltered.
Imagine, for example, that a server wanted to display a ward name, but the name were stored not as NORTH WARD, but as <script>...</script>.
The server would need to take great care not to pass through the <script> tag directly, because that character sequence tells the browser, “What comes next is a JavaScript program; execute it with all the privileges any script offically stored on the server would have.”
Instead, the server would need to recognise the “dangerous” HTML tag delimiter < (less-than sign), and convert it to the safe-for-display code <, which means, “Actually display a less-than sign, don’t treat it as a magic tag marker.”
Attackers can, and do, use XSS bugs to trick even well-informed users – the sort of users who routinely check the URLs in their address bar and who avoid using links or attachments they weren’t expecting – into automatically running malicious script code under the apparently safe umbrella of a server they assume they can trust.
http:// URLs, and used TCP ports often associated with unencrypted traffic (80, 8080, 8081). Without https://, we assume that a manipulator-in-the-middle (MiTM) attack would have been possible even in the absence of these bugs, making it feasible to snoop on robot locations, image uploads and control messages, and even to manipulate them in transit, without being stopped or detected. Always use TLS (transport layer security) to put the S-for-security in https://.eeeefdf77f1ac2eb5cdb7cf82ad48b9a. (Try it: that one took us under a second to crack.)Although the researchers behind the name JekyllBot seem to have indulged themselves with dramatic examples of how these bugs might be used to wreak low-speed/high-torque robotic havoc in a hospital corridor, for example by describing robots “crashing into staff, visitors and equipment”, and attackers “wreak[ing] havoc and destruction at hospitals using the robots”…
…they also make the point that these bugs could result in the more pedestrian-sounding but no less dangerous side effect of helping attackers implant malware on the computers of unsuspecting internal users.
And healthcare malware attacks, very sadly, often turn out to involve ransomware, which typically ends up derailing a lot more than just the hospital’s autonomous delivery robots.
Three years ago, we published an article with the dramatic-sounding title Serious Security: Post-Quantum Cryptography (and why we’re getting it).
As you probaby know, so-called quantum computers work in a rather mysterious way compared to conventional computers, inasmuch as they can perform certain sorts of calculation so that they effectively “compute” all possible answers simultaneously in what’s known in the jargon as a quantum superposition.
At some point, if the resulting superposition of entangled answers has not been affected by operating errors (quantum superpositions collapse when you try to observe them, settling into a specific condition that can be measured), you can extract the answer without having to repeat the calculation over and over again in a loop.
Quantum computing makes it feel almost as though you could replace this sequential code…
-- try 1000 times to find a value of i that works, and report it for i = 1 to 1000 do if itworkedout(i) then return i end end -- or report that none of them worked out return nil
…with this rather magical-looking parallel code…
calculation = workitallout(range(1,1000)) -- get superposition inside box answer = disentangle(calculation) -- open box and peek at Schroedinger's cat return answer -- report what you saw
Not all algorithms can be converted into quantum-friendly equivalents, but some can, including one known as prime factorisation.
That’s where you take two prime numbers that have been multiplied together, giving an answer such as 15, and work backwards to figure out that 15 = 5×3, thus factoring the product into its original parts.
Of course, to factor 15 is easy enough by traditional brute force:
product = 15 for i = 1 to sqrt(product) do -- we don't need to go past the root if (product % i) == 0 then -- % computes the remainder of the division print(product, ' = ',i,' x ',product/i) -- it divides exactly! break end end
But numerous cryptographic algorithms, notably those widely used for public key cryptography, rely on the fact that this factoring process gets exponentially harder as the size of the variable product above increases.
Loosely speaking, for every digit you add to the value of product, the number of times you have to go round the loop goes up multiplicatively, not additively.
(Repeated addition is the same as multiplication, so that 12+12+12 = 12×3 = 36), but repeated multiplication is the same as exponentiation, so that 12×12×12 = 123 = 1728.)
In other words, adding one digit to the iteration count doesn’t mean you need to go round the loop 10 more times (additive), but that you need to go round 10 times more times (multiplicative).
Likewise, in binary arithmetic, each extra bit (short for binary digit, if you’ve ever wondered, which can be only 0 or 1) in an iteration count doubles the number of iterations needed.
For example, bumping up your iteration count from a 16-bit number to a 32-bit number would increase the number of bits needed to store the counter from 16 to 16+16 = 32 (a doubling).
But the number of iterations involved would increase from 216 = 65536 to 2(16+16) = 216×216 = 232 = 4,294,967,296 (a jump that’s exponential in the number of additional bits).
And the prime products we’re dealing with in modern cryptography can be thousands of bits long.
So although we can easily multiply together, say, two 3072-bit prime numbers to produce a 6144-bit prime product, we don’t currently know any reliably fast way to split that 6144-digit prime product back into its factors.
The discrepancy in effort between multiplying two known primes together, and splitting that product back into its two factors, is pretty much the computational basis of a lot of modern online security…
…so if quantum computers ever do become both reliable and powerful enough to work their superpositional algorithmic magic on 3072-digit prime factors, then breaking into messages we currently consider uncrackable in practice may become possible in theory.
Even if you’d have to be a nation state to have even the tiniest chance of succeeding, you’d have turned a feat that everyone once considered computationally unfeasible into a task might just be worth having a crack at.
This would undermine a lot of existing public-key crypto algorithms to the point that they simply couldn’t be trusted.
Even worse, quantum computers that could crack new problems might also be used to have a go at older cryptographic puzzles, so that data we’d banked on keeping encrypted for at least N years because of its high value might suddenly be decryptable in just M years, where M < N, perhaps less by an annoyingly large amount.
Beecause of this, the United States cryptographic standards body NIST has been running a Post Quantum Cryptography (PQC) competition for several years already, so that if quantum decryption ever does become a reality, we’ll be ready.
The competition isn’t finished yet – these sorts of standards take years to coalesce, for three main reasons:
Nevertheless, OpenSSH, one of the most widely-used secure remote access tools in the world, and a de facto standard in most Unix and Linux distros, has decided to get ahead of the PQC curve.
The newly-published OpenSSH 9, released last Friday, has already picked its own winner from NIST’s current shortlist, and will now use a public-key encryption system called NTRU Prime by default.
In both ssh, the client program used for connecting. and in sshd, the server program used for accepting secure connections:
[we now] use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default (“sntrup761x25519-sha512@openssh.com”). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo.
We are making this change now (i.e. ahead of cryptographically-relevant quantum computers) to prevent “capture now, decrypt later” attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.
The new OpenSSH version supports all the cryptographic algorithms that it did before, so your existing installations won’t break, and you don’t have to use NTRU Prime even in new OpenSSH installations if you don’t want to.
Presumably, if NTRU Prime doesn’t make NIST’s final, official list of winners, OpenSSH will quickly include one or all of the ultimate winners as well.
But for those who were wondering when they’ve be able to enter their own Post-Quantum Cryptographic era proactively, without waiting to see how either quantum computing or the NIST PQC contest pans out…
…that time is now.
Just don’t tell Schrödinger’s cat.
If you’ve ever written technical documentation to use online, you probably started out by creating it directly in HTML (hypertext markup language), so you could drop it directly into your website.
You may have used various HTML editors that gave you a real-time but not entirely precise preview, but you’ll have spent plenty of time wrangling with one of HTML’s most annoying characteristics, namely that the so-called “markup” is bulky, and hard to read, and easy to mistype.
To make a word bold, for example, you end up with the clumsy input <strong>bold</strong>.
To create lists you need to add special tags at the start and end of the list, and then special tags at the start and end of each item, which makes proofreading harder than it needs to be, like this…
<ol> <li><strong>Design.</strong> <em>Do this first.</em></li> <li><strong>Code.</strong> <em>Then hack away.</em></li> <li><strong>Test.</strong> <em>And finally check if works</em>.</li> </ol>
…just to get this:
Worse, your marked-up text only works on websites, or in browser-like windows, so you need a plethora of conversion tools anyway if you also want to render your documents into plain ASCII, or some other widely-used format such as PDF, RTF or DOCX.
Worst, not all HTML markup can readily be converted into other formats, so you need to remember which HTML constructs you’re not allowed to use, in case you end up with a document where most, but not all, of the content can be rendered in other types of file.
After a while of hand-coded HTML, you may have switched to a simplified form of markup intended to make typing, editing, proofing and publishing your documentation easier.
Two popular formats include Markdown (which is a pun on making markup shorter to type and easier to learn), and Asciidoc (because your inputs are simple ASCII files with no proprietary or binary bits and pieces).
Asciidoc is meant to be an even better sort of Markdown, a dialect that’s more powerful while also looking even leaner and meaner.
In Asciidoc, for example, you create documents that look a bit like early-1990’s text-based emails, but that can be converted into modern and better-looking forms quickly and easily.
To write in boldface, for instance, you just write **boldface**, and for italics, you use the slightly lighter-looking *italics*.
To create lists, you just write them as you might have done in ASCII emails back in 1992, using a lone asterisk to denote a bullet point:
* **Design**. *Do this first*. * **Code.** *Then hack away*. * **Test.** *And finally check if it works*.
Many programming languagues and web development toolkits have libraries that support the use of Asciidoc, automatically converting it for you as needed.
And Ruby, a popular web coding environment, has numerous support tools, including one called asciidoc-include-ext, short for Asciidoctor Include Extension.
This allows you to create placeholders for Asciidoc components in existing files, simply by writing include::[...], so that headers, footers and so on don’t need to be repeated everywhere they’re used, and can therefore easily be updated in one place. (The include part is automatically replaced with the relevant Asciidoc subsection.)
Unfortunately, the asciidoc-include-ext code turned out to have a command injection vulnerability, whereby a deliberately misplaced backslash in a user-supplied file could trick the library into running remote commands directly instead of simply referencing a URL.
The bug was found earlier this week by security researcher Joern Schneeweisz of GitLab, and has been assigned the bug identifier CVE-2022-24803.
Because this bug can be exploited for remote code execution (RCE) by someone who hasn’t already logged in, it’s been given a Critical rating, and a danger number of 10/10 on the widely used, if not always easy-to-follow, Common Vulnerability Scoring System (CVSS) scale
As far as we can see, the code is supposed to check for data that starts with http:// or https://, to confirm it’s processing a plain URL rather than reading in potentially harmful and unwanted shell script code. But if the URL part is deliberately split into two lines using Ruby’s line continuation character (a backslash at the end of the line), such that the first line is a shell command and the second is a plain URL, then only the second line is checked to see if it passes the “valid URL” test, which it does. However, the line continuation character means that the data ultimately gets processed as if it were one line, including executing any shellcode added to the first line.
If you are a Ruby programmer and you use Asciidoc document markup in your code:
asciidoc-include-ext installed. You can use gem list to show all packages you’ve got, or gem list -i "^asciidoc" to show all modules with names that start with the text asciidoc.The asciidoctor-include-ext project also has a workaround you can use if you’re affected but can’t update yet.
