Re: [nexa] explosive supply chain attack on Hezbollah pagers.
380° <g380@biscuolo.net> writes:
siccome ne ho lette di tutti i colori in merito a "hanno stati gli hacker col MALWARE" (anche da presunti espertoni), vale la pena analizzare i fatti cum granu salis e smetterla con la SUPERSTIZIONE.
mi stavo giusto chiedendo se ci fosse qualche precedente e a rispondermi è Christine Gadsbym, Cybersecurity CISO in BlackBerry. ...poi l'articolo si trasforma in uno SPROLOQUIO sulla "software supply chain" (con soluzioni ridicole tipo gli SBOM - Software Bill Of Material), quindi mi limito a citare le parti pertinenti al supply chain attack in oggetto. https://blogs.blackberry.com/en/2024/09/pagers-explode-supply-chain-security... «Supply Chain Lessons from Thousands of Exploding Pagers» 09.17.24, Christine Gadsby --8<---------------cut here---------------start------------->8--- But the conversation soon shifted to another possible scenario: the pagers must have been intercepted along the supply chain so someone could place explosives inside each pager with a method of remotely triggering the blasts. Attackers have utilized [[https://simple.wikipedia.org/wiki/Yahya_Ayyash][similar attacks]] before, although not to this scale. --8<---------------cut here---------------end--------------->8--- COMUNQUE: il precedente indicato è del 1996 e riguarda il sabotaggio di UN telefono cellulare nel quale furono introdotti 15 grammi di esplosivo con un sistema di detonazione remoto. --8<---------------cut here---------------start------------->8--- Kamal Hamad asked his nephew for the phone, which he later returned. It was almost certainly at this moment that the 2oz radio-controlled bomb was inserted. --8<---------------cut here---------------end--------------->8--- (https://www.independent.co.uk/news/world/how-the-phone-bomb-was-set-up-13230...) Quindi non certo un supply chain attack, ma la tecnica pare la stessa identica di circa 30 anni fa, non proprio una novità per le agenzie di "intelligence", insomma. Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Il 18/09/24 12:52 PM, 380° via nexa ha scritto:
380°<g380@biscuolo.net> writes:
siccome ne ho lette di tutti i colori in merito a "hanno stati gli hacker col MALWARE" (anche da presunti espertoni), vale la pena analizzare i fatti cum granu salis e smetterla con la SUPERSTIZIONE. mi stavo giusto chiedendo se ci fosse qualche precedente [...]
rispetto al tema della sicurezza/controllo della "supply-chain", mi sono tornati alla mente queste due episodi (il primo, suggeritomi da uno studente): * 2014: "Photos of an NSA “upgrade” factory show Cisco router getting implant" https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory... * 2018 "The Big Hack: How China Used a Tiny Chip to Infiltrate U.S. Companies" https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-us... Bye, DV -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
Damiano Verzulli <damiano@verzulli.it> writes: [...]
rispetto al tema della sicurezza/controllo della "supply-chain", mi sono
_hardware_ supply chain, che diversa da quella software perché condizione sine qua non è avere accesso _fisico_ al device, in qualsiasi punto della supply chain (mentre inserirsi nella supply chain software è possibile anche via rete, da remoto).
tornati alla mente queste due episodi (il primo, suggeritomi da uno studente):
* 2014: "Photos of an NSA “upgrade” factory show Cisco router getting implant" https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory...
* 2018 "The Big Hack: How China Used a Tiny Chip to Infiltrate U.S. Companies" https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-us...
ottimi riferimenti; a questo proposito cito un brano di questo articolo di Wikipedia: --8<---------------cut here---------------start------------->8--- Documents revealed from 2013 onwards during the surveillance disclosures initiated by Edward Snowden showed that the Tailored Access Operations (TAO) unit and other NSA employees intercepted servers, routers, and other network gear being shipped to organizations targeted for surveillance to install covert implant firmware onto them before delivery.[13][14] These tools include custom BIOS exploits that survive the reinstallation of operating systems and USB cables with spy hardware and radio transceiver packed inside.[15] --8<---------------cut here---------------end--------------->8--- quindi il /modus operandi/ è ben noto quello che non sono affatto noti sono /i dettagli/ di chi, come e perché utilizzava e utilizza questo modus operandi, considerato che una piccolissima percentuale dei documenti trafugati da Snowden è stata resa pubblica. [...] Saluti, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Il 18/09/24 12:52 PM, 380° via nexa ha scritto:
[...] ...poi l'articolo si trasforma in uno SPROLOQUIO sulla "software supply chain" (con soluzioni ridicole tipo gli SBOM - Software Bill Of Material)
Come tante medicine, la SBOM non è certamente la soluzione di tutti i mali (del software). Tuttavia, in una scala da: * "0" => nessuna idea sul software che si usa e si impianta nei propri prodotti/servizi, compresi quelli venduti a * "100" => controllo meticoloso e preliminare di ogni singola riga di codice utilizzato, incluse dinamiche di ripetibilita' delle build delle stesse e di tutti i tool utilizzati, anche a livello firmware ritengo che lo standard, oggi, da parte di chi utilizza, sviluppa o distribuisce software (in "media", nel nostro Paese) sia molto vicino a 0 (certamente inferiore a 5) e... la SBOM ci porterebbe piu' in la. Sensibilmente. Non a 100... ma almeno a 30/40 (che sarebbe gia' un risultato gigantesco, dato il punto di partenza attuale) Quindi, IMO, ben vengano le SBOM... Bye, DV -- Damiano Verzulli e-mail:damiano@verzulli.it --- possible?ok:while(!possible){open_mindedness++} --- "...I realized that free software would not generate the kind of income that was needed. Maybe in USA or Europe, you may be able to get a well paying job as a free software developer, but not here [in Africa]..." -- Guido Sohne - 1973-2008 http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html
Buongiorno, Damiano Verzulli <damiano@verzulli.it> writes:
Il 18/09/24 12:52 PM, 380° via nexa ha scritto:
[...] ...poi l'articolo si trasforma in uno SPROLOQUIO sulla "software supply chain" (con soluzioni ridicole tipo gli SBOM - Software Bill Of Material)
Come tante medicine, la SBOM non è certamente la soluzione di tutti i mali (del software).
[...]
la SBOM ci porterebbe piu' in la. Sensibilmente. Non a 100... ma almeno a 30/40 (che sarebbe gia' un risultato gigantesco, dato il punto di partenza attuale)
Quindi, IMO, ben vengano le SBOM...
alcuni, tra cui me, sostengono invece che gli SBOM sono _ingannevoli_ esempi di implementazioni di sistemi SBOM: 1. https://en.wikipedia.org/wiki/Software_Package_Data_Exchange esempi: https://github.com/spdx/spdx-examples/tree/master/software 2. https://cyclonedx.org/ 3. https://nvd.nist.gov/products/swid le _etichette_ date al software in modo del tutto analogo ai codici dei componenti fisici che compongono la "bill of material" (BOM) degli artefatti _fisici_ sono *solo* fuorvianti; quelle etichette danno l'illusione di avere sotto controllo la supply chain del sofware e _quindi_ sono pericolose non si deve /ridurre/ la sicurezza della software supply chain a una FATICOSA operazione _burocratica_ di /compilazione/ di documenti (JSON, XML, YAML...) pieni di etichette... senza /ricadute pratiche/; tra l'altro solo per "star dietro" a uno SBOM ci vogliono un sacco di risorse (sprecate) i motivi per cui sostengo quanto sopra sono illustrati in un articolo che segnalai su questa lista nel Marzo scorso [1]: «Identifying software» Ludovic Courtès, Maxim Cournoyer, Jan Nieuwenhuizen, Simon Tournier — March 4, 2024 https://guix.gnu.org/en/blog/2024/identifying-software/ il nocciolo super-sintetico della critica agli SBOM è questo: --8<---------------cut here---------------start------------->8--- The Common Platform Enumeration (CPE) standard has been designed to fill that role; it is used to identify software as part of the well-known Common Vulnerabilities and Exposures (CVE) process. But CPE is showing its limits as an extrinsic identification mechanism: the human-readable identifiers chosen by CPE fail to capture the complexity of what “software” is. [...] mere package name/version pairs such as gcc 11.3.0 fail to capture the breadth and depth elements that lead to a binary artifact. This is a shortcoming of systems such as the Common Platform Enumeration (CPE) standard: it fails to express whether a vulnerability that applies to gcc 11.3.0 applies to it regardless of how it was built, patched, and configured, or whether certain conditions are required. [...] Again, a software bill of materials (SBOM) written as a mere list of package name/version pairs would fail to capture as much information. The Artifact Dependency Graph (ADG) of OmniBOR (https://omnibor.io/), while less ambiguous, falls short in two ways: it is too fine-grained for typical cybersecurity applications (at the level of individual source files), and it only captures the alleged source/binary correspondence of individual files but not the process to go from source to binary. --8<---------------cut here---------------end--------------->8--- l'articolo ricalca quanto gli autori hanno scritto in un loro commento a seguito di una RFC (request for comment) [2] della CISA (Cybersecurity and Infrastructure Security Agency) in merito al loro documento intitolato «Software Identification Ecosystem Option Analysis» [3]; il commento non è arrivato in tempo per essere pubblicato, ma è disponibile negli archivi del progetto Guix in PDF [4]. detto in altre parole: un sistema /estrinseco/ (al processo di build) per (tentare di) identificare tutti i "componenti" di un software binario è inadatto allo scopo di garantire un «effective vulnerability management» (cit. da [3]); un «effective vulnerability management» è possibile solo utilizzando un sistema /intrinseco/ (al processo di build). Last BUT NOT least, il processo di build _deve_ includere il c.d. full-source bootstrap [5], altrimenti il «vulnerability management» è /ineffective/. --8<---------------cut here---------------start------------->8--- In other words, because Guix itself defines how artifacts are built, the revision of the Guix source coupled with the package name unambiguously identify the package’s binary artifact. As scientists, we build on this property to achieve reproducible research workflows, as explained in this 2022 article in Nature Scientific Data; as engineers, we value this property to analyze the systems we are running and determine which known vulnerabilities and bugs apply. --8<---------------cut here---------------end--------------->8--- (https://guix.gnu.org/en/blog/2024/identifying-software/) per approfondimenti segnalo il paper «Building a Secure Software Supply Chain with GNU Guix» pubblicato il 2022-06-15 su «The Art, Science, and Engineering of Programming, 2023, Vol. 7, Issue 1, Article 1» disponibile qui: https://programming-journal.org/2023/7/1/ saluti, 380° [1] Message-id: 87plvwsmkj.fsf@xelera.eu [2] https://www.regulations.gov/document/CISA-2023-0026-0001 [3] https://www.cisa.gov/resources-tools/resources/software-identification-ecosy... [4] https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/doc/cisa-2023-0... [5] https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-so... -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
participants (2)
-
380° -
Damiano Verzulli