[00’21”] The “Independence Day Weekend” ransomware drama. [15’55”] The PrintNightmare nightmare continues. [24’16”] An email hacker gets his conviction overturned. [30’35”] In this week’s Oh! No! story, a server room fills with toxic fumes…
With Doug Aamoth and Paul Ducklin.
Download the IBM 3270 retrofont that Duck admired in the podcast.
Intro and outro music by Edith Mudge.
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.
WHERE TO FIND THE PODCAST ONLINE
You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher, Overcast and anywhere that good podcasts are found.
Or just drop the URL of our RSS feed into your favourite podcatcher software.
If you have any questions that you’d like us to answer on the podcast, you can contact us at tips@sophos.com, or simply leave us a comment below.
Cassandra
Kasaya sounds very worrying but how many of us
– automatically let Canonical Livepatch our Linux Kernel
– automatically click on Install for OS updates
– let Sophos update their software running on our computers
Presumably the Canonical Microsoft Sophos download servers represent quite a rich cookie jar for miscreants?
What reassurance can you offer – conceptually and specifically?
Paul Ducklin
Yes, an attack against this sort of target could have far-reaching consquences. In fact, we have seen this sort of attack tried on popular apps and distros many times, e.g. Linux Mint, the macOS version of the popular video app Handbrake, and PHP (more than once):
https://nakedsecurity.sophos.com/2016/02/22/worlds-biggest-linux-distro-infected-with-malware/
https://nakedsecurity.sophos.com/2017/05/09/mac-video-app-handbrake-now-with-free-spyware/
https://nakedsecurity.sophos.com/2021/04/30/php-community-sidesteps-its-third-supply-chain-attack-in-three-years/
As for Sophos or any other vendor, we can’t *prove* anything about the end-to-end safety of our updates; as you say, we and any other vendor can only really offer reassurances.
The good news about updaters specifically intended to upgrade your own software, and not to act as a generic distribution tool for a wide range of other software, is that you can use digital signatures to check that the updater only ever consumes code that came from your own organisation, and not have to worry about all the other software baggage you might be carrying on behalf of other vendors or suppliers.
So, reliably using trusted and tested cryptographic algorithms to ensure a “true source” for your updates helps to stop the crooks injecting imposter code at last step of the update process.
Of course, that doesn’t prevent criminality at the code level, but it does push the crooks further “upstream”, if you like, so that they would need to trick you into signing their code as well as yours before release. Sadly, we have frequently written about blunders such as lost or stolen code signing certificates, sloppy certificate issuing by certificate authorities, and poor security over the code signing process itself, so this sort of mistake can happen.
But if you have a secure build environment and a strict code signing process, for example where your keys are never given to other people, only stored in secure hardware devices, and managed by strict and disciplined physical access controls, you can reduce the risk of criminals signing their own code and thus subverting the middle part of the update process.
Even then, if you force the crooks further upstream so that they have to convince you to accept their poisoned code before you even build it into your own product, blunders can still happen.
But if you have a strong culture of code review, so that all changes get a second pair of eyes and good scrutiny, plus a separate and independent QA process that does more than just subject products to a list of basic tests, you can reduce the risk of crooks injecting malware into the development process itself, whether they try to bribe, hack or trick their way into your codebase.
I am aware that this isn’t really *the* answer, but it’s *an* answer, albeit only a very general one… perhaps an interview with one of our internal security team is something that we should consider for a minisode of the Naked Security podcast?
Cassandra
Thanks for your detailed (and “out of hours”) response.
On reflection I think I am surprised that we do not have more of these Supply Chain poisoning events and we (end users) take for granted a lot of the security that is “built in”.
We are told to “update promptly” and we do – with barely a thought about whether those updates are making our systems more or less secure.
Within my Ubuntu based system I just take the alert and update system “on trust” – although I instinctively baulk at implementing “livepatch” – which updates my kernel on the fly. I do review the proposed updates and ponder “why am I being asked to accept this update?” and sometimes look for publication of a security alert to see if it provides illumination – but I have to take a lot on trust.
I presume that, as you say, the communications between my machine and the update servers is hardened (almost like a permanent VPN?) and that an interception attack is virtually impossible. Any attack has to be “at the ends”.
Either my end point has to be poisoned by me either being phished into accepting malware that behaves like “Software Updater” (The GUI to presumably the Ubuntu package management system) – unlikely in a Linux type system – or I have to be persuaded to add repositories that might not be all they seem*, OR the update servers and repositories have to be compromised – and you hope Canonical (or their equivalent in this hybrid of Open Source and commercially curated software) have the sort of controls you describe.
* For instance, what exactly is “http://dl.google.com/linux/chrome/deb/” doing (presumably supporting Chromium – but the signing key is dated 2007)? Or “http://ppa.launchpad.net/mozillateam/ppa/ubuntu”? Note the non https prefix. But you don’t “fiddle” with a system that is working – and you try and “keep it vanilla” – or as vanilla as possible (having learnt that the red streaks in “raspberry ripple” software probably isn’t raspberry).
Many on Linux have a degree of “smugness” about the security of their systems compared to Windows. This may have been justified a decade ago – but I am not skilled enough to know whether it is still true or whether I have may have compromised my system by taking online advice to, for instance, add a repository to get a particular bit of software working. If I was a “IT person” in a small business I would probably be a nervous menace! I really need to understand how to audit & prune my repositories (and moving from 18.04 LTS to 20.04 LTS is probably the time to do so! Do a rebuild rather than let the system do a full upgrade).
(An interview with one of your security team would undoubtedly be interesting and informative.)