Sysadmins: Why not simply verify there's no backdoor in every program you install, and thus avoid any cyber-drama?
- Reference: 1627715644
- News link: https://www.theregister.co.uk/2021/07/31/enisa_supply_chain_attack_report/
- Source link:
Of the 24 supply-chain attacks studied by ENISA since January 2020, a dozen were attributed to APTs while 10 of them hadn't been attributed to anyone at all in open-source reporting, the agency said.
Juhan Lepassaar, ENISA's exec director, said in a canned statement: “Due to the cascading effect of supply chain attacks, threat actors can cause widespread damage affecting businesses and their customers all at once. With good practices and coordinated actions at EU level, Member States will be able to reach a similar level of capabilities raising the common level of cybersecurity in the EU.”
[1]
The open-source study is intended as a primer on supply-chain attacks, which typically consist of targeting B2B software suppliers that have extensive customer lists. Once the supplier is compromised, the attackers then move laterally into their customers' networks, typically to steal data and extort the victims.
[2]
[3]
"An additional characteristic of supply chain attacks involves the complexity in handling them and the efforts required to mitigate and address such attacks," said ENISA in its [4]report .
This was illustrated when IT management toolmaker Kaseya pulled the software-as-a-service offering of its VSA suite offline and told clients to turn off their on-prem deployments of VSA after installations of the software were [5]exploited to deliver ransomware. Restoration of those services was [6]repeatedly delayed as the biz tried to figure out how to patch its code to prevent any further infections.
[7]
To the best of our knowledge, all we [8]really know is that, according to Kaseya, "the attackers were able to exploit zero-day vulnerabilities in the VSA product to bypass authentication and run arbitrary command execution. This allowed the attackers to leverage the standard VSA product functionality to deploy ransomware to endpoints."
ENISA criticized suppliers for either not knowing or not admitting in public how they were compromised. The UK is [9]taking advantage of Brexit to lower incident reporting thresholds in security frameworks first created by EU laws; perhaps the political bloc may follow suit.
[10]Another supply-chain attack? Android maker Gigaset injects malware into victims' phones via poisoned update
[11]Mimecast bins SolarWinds and compromised servers alike in wake of supply chain hack
[12]Us? Pwn SolarWinds? With our reputation? Russian spy chief makes laughable denial of supply chain attack
[13]White hats reported key Kaseya VSA flaw months ago. Ransomware outran the patch
ENISA, which is soon to be dragged from its Greek home – split between capital Athens and the sunny island of Heraklion – to the grey towers of Brussels, also proposed its own unique taxonomy for analyzing supply chain attacks. In doing so it lightly pooh-poohed both MITRE's [14]ATT&CK and Lockheed Martin's [15]Cyber Kill Chain analysis frameworks as "too generic."
The report lists the supply-chain incidents studied by ENISA. Aside from the high-profile ones involving Accellion, SolarWinds, and Kaseya, it also lists Fujitsu's [16]ProjectWeb , the [17]Bignox Noxplayer Android emulator , and more.
Er, is this good advice?
"In order to compromise the targeted customers, attackers focused on the suppliers’ code in about 66 per cent of the reported incidents," noted ENISA. "This shows that organisations should focus their efforts on validating third-party code and software before using them to ensure these were not tampered with or manipulated."
Though we appreciate the spirit of this advice, it's doing a lot of heavy lifting for what is a non-trivial issue.
The most high-profile supply-chain attack of late was the [18]SolarWinds Orion compromise. In this, Russian spies [19]compromised the vendor's systems to hide a backdoor in an update for the Orion network management and monitoring software. The end goal being that SolarWinds' customers would install the tainted update, and selected valuable targets would be infiltrated via the implanted vulnerability.
[20]
That update was fetched by 18,000 organizations through normal channels, none of them suspecting any foul play; the backdoor was stashed in [21]a signed .dll file . It's tricky to see how your common or garden end-user organization could have detected that.
It's not feasible to ask every org to break out disassemblers, source code editors, and network and memory analysis tools, and have staff on hand capable of using them, to inspect every update, be they open or closed source.
It would be better to have robust mechanisms in place to verify that software packages are legit, and released and fetched as intended by their maintainers, and in a way that if build systems are infiltrated, as we saw with SolarWinds, unauthorized changes are still apparent. This can be done, though making it completely airtight is not quite as easy as one might hope if your adversary is the Kremlin.
Crucially, even then, it's on the suppliers to first create these mechanisms, and customers to then use them.
That all said, Google's [22]SLSA proposal may prove be useful down the line. ®
Get our [23]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YQUfYYqNa1iZ0UmOwEiqTwAAANc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YQUfYYqNa1iZ0UmOwEiqTwAAANc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YQUfYYqNa1iZ0UmOwEiqTwAAANc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks
[5] https://www.kaseya.com/potential-attack-on-kaseya-vsa/
[6] https://www.theregister.com/2021/07/09/kaseya_saas_restoration_july_11/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YQUfYYqNa1iZ0UmOwEiqTwAAANc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2021/07/06/kaseya_update/
[9] https://www.theregister.com/2021/07/27/uk_security_breach_reporting_law_thresholds/
[10] https://www.theregister.com/2021/04/07/gigaset_supply_chain_malware_android_phones/
[11] https://www.theregister.com/2021/03/17/mimecast_bins_solarwinds_after_compromise/
[12] https://www.theregister.com/2021/05/18/russian_spymaster_solarwinds/
[13] https://www.theregister.com/2021/07/08/kaseya_dutch_vulnerability/
[14] https://attack.mitre.org/
[15] https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
[16] https://www.theregister.com/2021/05/27/fujitsu_projectweb_supply_chain_attack/
[17] https://www.theregister.com/2021/06/09/eset_gelsemium_research/
[18] https://www.theregister.com/2021/02/03/solarwinds_patch_trustwave/
[19] https://www.theregister.com/2021/01/12/solarwinds_tech_analysis_crowdstrike/
[20] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YQUfYYqNa1iZ0UmOwEiqTwAAANc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[21] https://www.theregister.com/2020/12/20/solarwinds_update_trump_contradicts_pompeo_russia_attribution/
[22] https://www.theregister.com/2021/06/18/google_slsa_supply_chain_rust/
[23] https://whitepapers.theregister.com/
Re: How about using proper change control ?
“ Once an update is committed to the upload server of the supplier, there could be a mechanism to ensure that that file is properly identified (MD5 and signature, or something similar). As soon as the file changes, ”
What if the update is fully signed etc and approved but contains the malicious payload that no one has spotted?
As I understand things, the project owners update open source to the repositories and it’s then signed. So anyone pulling the code is sure it’s how the maintainers intended. Absolutely no use of the code was intentionally compromised to look legit and has all the correct signing etc.
Re: How about using proper change control ?
That works well with linux repositories (possibly even better with things like BSDs) who are (relatively) selective about maintainers. Unmaintained packages get dropped after a while. The package maintainers are not typically the project owners, if by the latter you mean the people who write the software.
It will not work for things like npm and pypi who are more concerned with making it easy to package stuff, and the authors are usually the package maintainers and probably less willing to jump through hoops.
Re: How about using proper change control ?
Some organisations do require that every update is checked by two humans, so nothing is released until two people verify the changes and click the button for the build to go out. It's a pain, but sometimes necessary.
Of course it is not entirely fool proof. If these people, for example, are tired and not paid adequately for their responsibility and act carelessly.
Linux proves that doesn’t work
Ask GKH about them commits he had to revert due to them being part of a study on supply chain attacks which the Linux kernel project didn’t defend against. The truth is that businesses need to stop buying large, bulky “solutions” for every problem they have and instead actually have their talented employees sort things out properly.
Supply chain attacks can and will happen; the goal is not to embrace every single new fad under the sun and have people who thoroughly understand the software they are working with, The Trusted Computing Base should be as small and as simple as possible to keep things secure and everything else should be running with as little authority as is feasible, with the assumption it could already be compromised.
Also, make sure the stuff you use has been independently vetted. Don’t use npm or pip or the like and don’t trust bundled libraries, stick to vetted, system-wide libraries instead.
Re: Linux proves that doesn’t work
That sounds like a dozen of large IT organizations I know and where hardly anything manages to happen any more while the competition is smoking their asses, getting away with the incidental incident. Perhaps the suggested might work for government and banking as it can be endlessly financed by other people's funds and savings. Or at least the market mechanism is less punishing there.
Trusting the builders who trust their suppliers
“ It would be better to have robust mechanisms in place to verify that software packages are legit, and released and fetched as intended by their maintainers, and in a way that if build systems are infiltrated, as we saw with SolarWinds, unauthorized changes are still apparent”
If we all had the skills to verify the work supplied by vendors then surely we’d not need the vendors.
Over the years there have been found many exploits in open source software. I remember one was traced to an update between Christmas and New Years years before hand. Most code is complex and understood by only a few people. Lots of code relies on code libraries from others that they themselves have not verified and may auto update.
Let’s hope for a return of in house coders to build and analyse this stuff instead of farming out..
Herculean task
Software is only getting more and more complex with more lines of code and third party components and contributors. Short of having an in house trusted group of programmers to wade through hundreds of thousands of lines of source code, I can't see this problem going away. What company is realistically going to employ such a team anyway? The problems are not just malicious code sneaking in but the endless bugs resulting in zero day exploits.
Miscreants only need to find one exploitable bug in software but those trying to make the software safe and secure need to find and fix every exploitable bug. It just isn't going to happen.
How about using proper change control ?
Once an update is committed to the upload server of the supplier, there could be a mechanism to ensure that that file is properly identified (MD5 and signature, or something similar). As soon as the file changes, if there is not the proper declaration in the records, shutdown the Internet connection for the server, send an alert mail and wait for the admins to come and check.
I'm pretty sure implenting this kind of procedure wouldn't break the bank, and it seems to me that it could be rather efficient in keeping customers safe.