Windows crash MONDIALE CrowdStrike

[woddy68]

Interessante articolo....https://www.miamammausalinux.org/2024/0 ... -successo/

Nessun sistema operativo è immune dal rischio di BSOD, perchè in tutti i SO moderni se crasha uno o più moduli del kernel questo porta inevitabilmente al Bsod. Crowdstrike gira in kernel mode su Windows e credo pure su Linux, perchè è l'unico modo conosciuto per analizzare a basso livello tutto ciò che accade nella memoria e quindi idenfiticare eventuale malware. Il giorno che troveranno un metodo diverso, cioè passando in userspace, questo problema si risolverà da sé.

"Crowdstrike's model seems to be 'we push software to your machines any time we want, whether or not it's urgent, without testing it'," lamented the team member.

Qui c'era proprio un problema di metodo. E come dicevo precedentemente la mancanza di test è la cosa più grave, ancor più grave del bug in sé.

... è quello che è spiegato nel link...tuttavia ci sono differenze e anche questo è spiegato nel link.

[danilo_g]

Interessante articolo....https://www.miamammausalinux.org/2024/0 ... -successo/

Nessun sistema operativo è immune dal rischio di BSOD, perchè in tutti i SO moderni se crasha uno o più moduli del kernel questo porta inevitabilmente al Bsod. Crowdstrike gira in kernel mode su Windows e credo pure su Linux, perchè è l'unico modo conosciuto per analizzare a basso livello tutto ciò che accade nella memoria e quindi idenfiticare eventuale malware. Il giorno che troveranno un metodo diverso, cioè passando in userspace, questo problema si risolverà da sé.

"Crowdstrike's model seems to be 'we push software to your machines any time we want, whether or not it's urgent, without testing it'," lamented the team member.

Qui c'era proprio un problema di metodo. E come dicevo precedentemente la mancanza di test è la cosa più grave, ancor più grave del bug in sé.

... è quello che è spiegato nel link...tuttavia ci sono differenze e anche questo è spiegato nel link.

Differenze in merito a cosa?

[woddy68]

Interessante articolo....https://www.miamammausalinux.org/2024/0 ... -successo/

Nessun sistema operativo è immune dal rischio di BSOD, perchè in tutti i SO moderni se crasha uno o più moduli del kernel questo porta inevitabilmente al Bsod. Crowdstrike gira in kernel mode su Windows e credo pure su Linux, perchè è l'unico modo conosciuto per analizzare a basso livello tutto ciò che accade nella memoria e quindi idenfiticare eventuale malware. Il giorno che troveranno un metodo diverso, cioè passando in userspace, questo problema si risolverà da sé.

"Crowdstrike's model seems to be 'we push software to your machines any time we want, whether or not it's urgent, without testing it'," lamented the team member.

Qui c'era proprio un problema di metodo. E come dicevo precedentemente la mancanza di test è la cosa più grave, ancor più grave del bug in sé.

... è quello che è spiegato nel link...tuttavia ci sono differenze e anche questo è spiegato nel link.

Differenze in merito a cosa?

...non ho capito, lo hai letto l' articolo ? L' articolo prende spunto da quello che è accaduto, per capire se sarebbe potuto succedere anche su Linux e ovviamente la risposta è si, ma con alcune differenze che l' articolo tenta di esporre.

[danilo_g]

Interessante articolo....https://www.miamammausalinux.org/2024/0 ... -successo/

Nessun sistema operativo è immune dal rischio di BSOD, perchè in tutti i SO moderni se crasha uno o più moduli del kernel questo porta inevitabilmente al Bsod. Crowdstrike gira in kernel mode su Windows e credo pure su Linux, perchè è l'unico modo conosciuto per analizzare a basso livello tutto ciò che accade nella memoria e quindi idenfiticare eventuale malware. Il giorno che troveranno un metodo diverso, cioè passando in userspace, questo problema si risolverà da sé.

"Crowdstrike's model seems to be 'we push software to your machines any time we want, whether or not it's urgent, without testing it'," lamented the team member.

Qui c'era proprio un problema di metodo. E come dicevo precedentemente la mancanza di test è la cosa più grave, ancor più grave del bug in sé.

... è quello che è spiegato nel link...tuttavia ci sono differenze e anche questo è spiegato nel link.

Differenze in merito a cosa?

...non ho capito, lo hai letto l' articolo ? L' articolo prende spunto da quello che è accaduto, per capire se sarebbe potuto succedere anche su Linux e ovviamente la risposta è si, ma con alcune differenze che l' articolo tenta di esporre.

Bene, e io ti richiedo: differenze in merito a cosa?

[woddy68]

Interessante articolo....https://www.miamammausalinux.org/2024/0 ... -successo/

Nessun sistema operativo è immune dal rischio di BSOD, perchè in tutti i SO moderni se crasha uno o più moduli del kernel questo porta inevitabilmente al Bsod. Crowdstrike gira in kernel mode su Windows e credo pure su Linux, perchè è l'unico modo conosciuto per analizzare a basso livello tutto ciò che accade nella memoria e quindi idenfiticare eventuale malware. Il giorno che troveranno un metodo diverso, cioè passando in userspace, questo problema si risolverà da sé.

"Crowdstrike's model seems to be 'we push software to your machines any time we want, whether or not it's urgent, without testing it'," lamented the team member.

Qui c'era proprio un problema di metodo. E come dicevo precedentemente la mancanza di test è la cosa più grave, ancor più grave del bug in sé.

... è quello che è spiegato nel link...tuttavia ci sono differenze e anche questo è spiegato nel link.

Differenze in merito a cosa?

...non ho capito, lo hai letto l' articolo ? L' articolo prende spunto da quello che è accaduto, per capire se sarebbe potuto succedere anche su Linux e ovviamente la risposta è si, ma con alcune differenze che l' articolo tenta di esporre.

Bene, e io ti richiedo: differenze in merito a cosa?

Ora che la tempesta CrowdStrike pare essersi calmata (e risolta, basta riavviare fino a quindici volte) è bene cominciare ad interrogarsi con lucidità su quanto accaduto. OK, il problema ha riguardato solamente le macchine (reali o virtuali che fossero) Microsoft Windows, ma siamo sicuri che un disastro del genere non possa accadere anche con Linux?

La premessa a tutto questo ragionamento poi è doverosa: non si sta scrivendo che Linux sia immune da queste problematiche, tanto che la questione CrowdStrike (proprio lei) effettivamente aveva già colpito i sistemi Debian e Rocky Linux mesi fa. Leggete questo articolo di Neonwin per capire come il modello di sviluppo usato da CrowdStrike fosse già stato criticato dagli sviluppatori Debian e di come in realtà avesse avuto una rilevanza molto bassa.

Perché? Perché è successo in Linux, ed in Linux le cose sono diverse.

Quindi da dove nasce la certezza che Linux sia immune da apocalissi tipo CrowdStrike?

Fermo restando come non sia una certezza, poiché ovviamente le affermazioni assolute sono fatte per essere smentite, ecco quattro ragioni per cui la questione è, a mio giudizio, altamente improbabile.

Quindi da dove nasce la certezza che Linux sia immune da apocalissi tipo CrowdStrike?

Fermo restando come non sia una certezza, poiché ovviamente le affermazioni assolute sono fatte per essere smentite, ecco quattro ragioni per cui la questione è, a mio giudizio, altamente improbabile.

Il motivo principale del BSOD è stata l’installazione dell’aggiornamento del software Falcon Sensor di CrowdStrike, specificamente di un file .sys che ha bloccato l’avvio dei sistemi a causa di un errore.

L’approccio unattended upgrades (ossia gli aggiornamenti senza supervisione) può avere una valenza in contesti di sicurezza (ad esempio nell’ambito della recente problematica regreSSHion), ma in Linux questa prassi è poco seguita, a meno di non trattare le installazioni come istanze effimere, dove quindi il problema nemmeno si pone poiché l’aggiornamento è sostanzialmente l’avvio di un intero nuovo sistema.

Perché è quello che l’approccio cloud-native dovrebbe prevedere, giusto? In realtà no, ma rimane il fatto di come non sia pratica diffusa avere unattended upgrades abilitati di default sui sistemi Linux.

Per quanto sia globalmente accettato che un aggiornamento in autonomia riavvii il sistema non è, o almeno non dovrebbe essere la prassi. Di sicuro in ambito Linux questa non è indicata come best-practice

.

Le distribuzioni Linux, anche solo considerando quelle di classe enterprise usate nei server e non quelle dei client, sono molte e variegate. I cicli di release delle stesse sono diversi e, per quanto ci sia il dominio di Linux sul cloud non è mai UN SOLO Linux di cui si sta parlando.

C’è poi l’aspetto open-source da tenere presente nella valutazione: Linux non è un’azienda. Sebbene la community che sviluppa il Kernel Linux funziona come tale rimane il fatto che il codice è pubblico. I contributi lo sono allo stesso tempo e, come recita la Linus law “given enough eyeballs, all bugs are shallow“.

E qui finisce questa veloce disamina. È quindi impossibile che si verifichi un CrowdStrike anche in Linux? È quindi impossibile che otto milioni e mezzo di sistemi possano essere colpiti contemporaneamente da un problema come quello del Falcon Sesor?

Assolutamente no, perché impossibile in informatica non si dice, ma certamente improbabile.

Diverso se fosse capitato su Linux.

[danilo_g]

@woddy68 non era assolutamente necessario riportare tutto l'articolo. La mia domanda era chiara, mentre la tua risposta ancora latita.

Io l'articolo l'ho letto, e ho ampliato il discorso fornendo dei dettagli non riportati nell'articolo (ma in uno di quelli linkati dall'articolo), a cui tu ha risposto "... è quello che è spiegato nel link... tuttavia ci sono differenze e anche questo è spiegato nel link. "

Ma in realtà nel link non è spiegato. Differenze in merito a cosa? Alle conseguenze? Al modo in cui sarebbe stata gestita la situazione? Al suo impatto? L'articolo non lo dice. E nemmeno tu lo dici, nonostante te l'abbia chiesto chiaramente.

L'articolo, che è più che altro un post di un blogghettino di provincia, solleva solo alcuni dubbi legati al fatto che di Linux non ce ne sia uno ma diversi, che gli unattended upgrades non siano la norma e il fatto che il codice è pubblico.

A parte che ogni punto di questi è contestabile... Che il codice sia opensource non ha alcuna rilevanza: falcon sensor è un prodotto closed e quindi nessuno a parte i suoi dev può andare a revisionare il codice. Che ci siano più distro anche in ambito entrprise non impedisce che Crowdstrike "supporti" le 2-3 distro principali ma comunque possa mandarle in crash (com'è successo, infatti). Poi, che gli unattended-upgrades non siano diffusi è da vedere, alcune distro li hanno attivi di default.

Ma anche ritenendo corretti questi punti, il post non spiega. Fa alcune insinuazioni e si ferma lì... lasciando il resto al lettore. È un classico post esca-per-click, che non aggiunge nulla di particolarmente utile o rilevante alla disamina. Post a cui tu sei abboccato ampiamente.

Prima di insinuare, per ben due volte, che il tuo interlocutore non abbia letto, assicurati in primis di aver letto tu (e capito) quello che posti... Non è la prima volta che questo capita, quindi fai attenzione.

[danilo_g]

La differenza tra Linux e Windows, nel contesto di un eventuale bug di un EDR come Falcon sensor che possa mandare in crash il sistema operativo, è che Windows ha percentuali di diffusione molto più ampie sopratutto tra gli endpoint periferici. La differenza è che Linux viene usato per la maggior parte in ambito server, dove il monitoraggio degli aggiornamenti è molto più accurato e puntuale. Fine delle differenze.

Se non è successa un "apocalisse" come per Windows è semplicemente perché su Linux non si usa Falcon sensor quanto su Windows, oppure perché il numero di installazioni di Linux anche in ambito enterprise è estremamente più basso di quelle di Windows.

[woddy68]

Per farla breve... l' articolo cerca di ipotizzare l' impatto che avrebbe avuto su Linux e spiega che sarebbe diverso a causa di alcune differenze come la frammentazione delle distro, il metodo di aggiornamento ecc.
Pensavo fosse chiaro il contesto.

[danilo_g]

Per farla breve... l' articolo cerca di ipotizzare l' impatto che avrebbe avuto su Linux e spiega che sarebbe diverso a causa di alcune differenze come la frammentazione delle distro, il metodo di aggiornamento ecc.
Pensavo fosse chiaro il contesto.

Grazie per l'ulteriore spiegone... inutile, come se non avessi letto l'articolo. Davvero, mille grazie.

Tu sei molto bravo a cambiare discorso e a non rispondere nel merito. Questa è l'unica cosa chiara.

[korda]

La differenza tra Linux e Windows, nel contesto di un eventuale bug di un EDR come Falcon sensor che possa mandare in crash il sistema operativo, è che Windows ha percentuali di diffusione molto più ampie sopratutto tra gli endpoint periferici. La differenza è che Linux viene usato per la maggior parte in ambito server, dove il monitoraggio degli aggiornamenti è molto più accurato e puntuale. Fine delle differenze.

Se non è successa un "apocalisse" come per Windows è semplicemente perché su Linux non si usa Falcon sensor quanto su Windows, oppure perché il numero di installazioni di Linux anche in ambito enterprise è estremamente più basso di quelle di Windows.

Lasciando da parte un secondo CrowdStrike/Falcon Sensor (che non conosco/uso) l'EDR che usiamo qui attualmente è orientato pure verso smartphone ospitanti iOS e Android quali endpoint devices (oltre ai PC con sistemi MacOS e Windows). Considerando che non é del tutto infrequente che l'equipaggiamento di molti dipendenti sia composto da un doppio asset (laptop+smartphone) forse la soglia dell'improbabilità, menzionata dal blogger, si abbasserebbe un pochino.

Fun fact: l'EDR che ho menzionato è gestito da una grossa e nota compagnia mobile, non credo quindi sia un prodotto di nicchia da cercare con il lanternino. Il fun fact, tornando sulla questione Android, è che l'EDR è riuscito ad individuare un rootkit ma in questo caso sfortunatamente non riesce a far altro che segnalarlo sulla dashboard e basta (senza poter intraprendere alcuna azione ulteriore sull'endpoint colpito)

[danilo_g]

La differenza tra Linux e Windows, nel contesto di un eventuale bug di un EDR come Falcon sensor che possa mandare in crash il sistema operativo, è che Windows ha percentuali di diffusione molto più ampie sopratutto tra gli endpoint periferici. La differenza è che Linux viene usato per la maggior parte in ambito server, dove il monitoraggio degli aggiornamenti è molto più accurato e puntuale. Fine delle differenze.

Se non è successa un "apocalisse" come per Windows è semplicemente perché su Linux non si usa Falcon sensor quanto su Windows, oppure perché il numero di installazioni di Linux anche in ambito enterprise è estremamente più basso di quelle di Windows.

Lasciando da parte un secondo CrowdStrike/Falcon Sensor (che non conosco/uso) l'EDR che usiamo qui attualmente è orientato pure verso smartphone ospitanti iOS e Android quali endpoint devices (oltre ai PC con sistemi MacOS e Windows). Considerando che non é del tutto infrequente che l'equipaggiamento di molti dipendenti sia composto da un doppio asset (laptop+smartphone) forse la soglia dell'improbabilità, menzionata dal blogger, si abbasserebbe un pochino.

Ma qui il fattore scatenante è proprio l'EDR utilizzato. Se ne usi un altro, che usa altri meccanismi, dubito che i risultati sarebbero gli stessi.

Fun fact: l'EDR che ho menzionato è gestito da una grossa e nota compagnia mobile, non credo quindi sia un prodotto di nicchia da cercare con il lanternino. Il fun fact, tornando sulla questione Android, è che l'EDR è riuscito ad individuare un rootkit ma in questo caso sfortunatamente non riesce a far altro che segnalarlo sulla dashboard e basta (senza poter intraprendere alcuna azione ulteriore sull'endpoint colpito)

Mi vien da dire che non è un gran ché come EDR se non può intervenire attivamente alla rimozione del malware. È vero anche che Android ha un'architettura software molto diversa, e anche l'hardware su cui gira è diverso. Troppe variabili in gioco, non penso si possano fare paragoni diretti.

[woddy68]

Per farla breve... l' articolo cerca di ipotizzare l' impatto che avrebbe avuto su Linux e spiega che sarebbe diverso a causa di alcune differenze come la frammentazione delle distro, il metodo di aggiornamento ecc.
Pensavo fosse chiaro il contesto.

Grazie per l'ulteriore spiegone... inutile, come se non avessi letto l'articolo. Davvero, mille grazie.

Tu sei molto bravo a cambiare discorso e a non rispondere nel merito. Questa è l'unica cosa chiara.

Io onestamente non ho capito cosa mi stai chiedendo...io mi sono limitato a postare un link, che di per sé mi sembra esaustivo, dopodiché si può essere d' accordo o meno.

[danilo_g]

Per farla breve... l' articolo cerca di ipotizzare l' impatto che avrebbe avuto su Linux e spiega che sarebbe diverso a causa di alcune differenze come la frammentazione delle distro, il metodo di aggiornamento ecc.
Pensavo fosse chiaro il contesto.

Grazie per l'ulteriore spiegone... inutile, come se non avessi letto l'articolo. Davvero, mille grazie.

Tu sei molto bravo a cambiare discorso e a non rispondere nel merito. Questa è l'unica cosa chiara.

Io onestamente non ho capito cosa mi stai chiedendo...io mi sono limitato a postare un link, che di per sé mi sembra esaustivo, dopodiché si può essere d' accordo o meno.

Fa niente, lascia perdere. Non voglio crearti ulteriore turbamento.

[korda]

La differenza tra Linux e Windows, nel contesto di un eventuale bug di un EDR come Falcon sensor che possa mandare in crash il sistema operativo, è che Windows ha percentuali di diffusione molto più ampie sopratutto tra gli endpoint periferici. La differenza è che Linux viene usato per la maggior parte in ambito server, dove il monitoraggio degli aggiornamenti è molto più accurato e puntuale. Fine delle differenze.

Se non è successa un "apocalisse" come per Windows è semplicemente perché su Linux non si usa Falcon sensor quanto su Windows, oppure perché il numero di installazioni di Linux anche in ambito enterprise è estremamente più basso di quelle di Windows.

Lasciando da parte un secondo CrowdStrike/Falcon Sensor (che non conosco/uso) l'EDR che usiamo qui attualmente è orientato pure verso smartphone ospitanti iOS e Android quali endpoint devices (oltre ai PC con sistemi MacOS e Windows). Considerando che non é del tutto infrequente che l'equipaggiamento di molti dipendenti sia composto da un doppio asset (laptop+smartphone) forse la soglia dell'improbabilità, menzionata dal blogger, si abbasserebbe un pochino.

Ma qui il fattore scatenante è proprio l'EDR utilizzato. Se ne usi un altro, che usa altri meccanismi, dubito che i risultati sarebbero gli stessi.

Fun fact: l'EDR che ho menzionato è gestito da una grossa e nota compagnia mobile, non credo quindi sia un prodotto di nicchia da cercare con il lanternino. Il fun fact, tornando sulla questione Android, è che l'EDR è riuscito ad individuare un rootkit ma in questo caso sfortunatamente non riesce a far altro che segnalarlo sulla dashboard e basta (senza poter intraprendere alcuna azione ulteriore sull'endpoint colpito)

Mi vien da dire che non è un gran ché come EDR se non può intervenire attivamente alla rimozione del malware. È vero anche che Android ha un'architettura software molto diversa, e anche l'hardware su cui gira è diverso. Troppe variabili in gioco, non penso si possano fare paragoni diretti.

Condivido... io mi riferivo al post sul blog linkato da @woddy68 ipotizzando scenari analoghi circa eventuali paragoni

ma siamo sicuri che un disastro del genere non possa accadere anche con Linux?

In realtà l'EDR, TrendMicro distribuito da Vodafone, non è poi così malaccio. Certo non è possibile fare confronti diretti con prodotti dela portata di CrowdStrike (ho già menzionato Ivanti?), però il suo sporco lavoro lo fa.
Il fun fact era riferito al fatto che nella piccola realtà dove lavoro, è la prima volta che osservo un rootkit Android peraltro non eliminabile direttamente. Tutto qui...

[danilo_g]

Condivido... io mi riferivo al post sul blog linkato da @woddy68 ipotizzando scenari analoghi circa eventuali paragoni

ma siamo sicuri che un disastro del genere non possa accadere anche con Linux?

Se ho capito bene, intendi che includendo nello scenario oltre a Windows anche Android, la probabilità di un ulteriore blocco massivo di dispositivi aumenti.

In realtà l'EDR, TrendMicro distribuito da Vodafone, non è poi così malaccio. Certo non è possibile fare confronti diretti con prodotti dela portata di CrowdStrike (ho già menzionato Ivanti?), però il suo sporco lavoro lo fa.
Il fun fact era riferito al fatto che nella piccola realtà dove lavoro, è la prima volta che osservo un rootkit Android peraltro non eliminabile direttamente. Tutto qui...

Ti suggerisco di andare a fondo della questione, e capire se quello segnalato sia davvero un rootkit, perchè per installarsi un rootkit "vero" ha bisogno di privilegi root o di una falla da sfruttare che consenta l'escalation dei privilegi. O che non sia semplicemente un app malevola installata dall'utente, cosa secondo me più probabile, e in tal caso rimarrebbe confinata nella sua "application sandbox" di Android con molte meno possibilità di far danni.

[korda]

Condivido... io mi riferivo al post sul blog linkato da @woddy68 ipotizzando scenari analoghi circa eventuali paragoni

ma siamo sicuri che un disastro del genere non possa accadere anche con Linux?

Se ho capito bene, intendi che includendo nello scenario oltre a Windows anche Android, la probabilità di un ulteriore blocco massivo di dispositivi aumenti.

In realtà l'EDR, TrendMicro distribuito da Vodafone, non è poi così malaccio. Certo non è possibile fare confronti diretti con prodotti dela portata di CrowdStrike (ho già menzionato Ivanti?), però il suo sporco lavoro lo fa.
Il fun fact era riferito al fatto che nella piccola realtà dove lavoro, è la prima volta che osservo un rootkit Android peraltro non eliminabile direttamente. Tutto qui...

Ti suggerisco di andare a fondo della questione, e capire se quello segnalato sia davvero un rootkit, perchè per installarsi un rootkit "vero" ha bisogno di privilegi root o di una falla da sfruttare che consenta l'escalation dei privilegi. O che non sia semplicemente un app malevola installata dall'utente, cosa secondo me più probabile, e in tal caso rimarrebbe confinata nella sua "application sandbox" di Android con molte meno possibilità di far danni.

Oggi ho lanciato, dall'EDR, una scansione più aggressiva: minaccia, quale che fosse, debellata

[saxtro]

...cut...
Avevo capito si trattasse di un EDR, dando per scontato che ne fossero coinvolti direttamente pure gli endpoint su cui è installato l'agent, che l'aggiornamento fosse pure su di esso.

Per endpoint solitamente non si intendono solamente gli asset chiave per funzionalità (intesi quelli critici che hai menzionato), ma anche l'equipaggiamento delle PdL in dotazione ai dipendenti (ad es. portatili, tablet, smartphone, ecc.)

Praticamente Falcon Sensor sarebbe solamente il servizio lato server per il monitoraggio e l'azione sugli endpoint? L'aggiornamento interessa essi indirettamente quindi?

Cosa è Crowdstrike descritto da Dell: https://www.dell.com/support/kbdoc/it-i ... rowdstrike

Le tue affermazioni sembrano corrette per quanto ne so.
Io ho affermato che Crowstrike* sia installato sui server con funzioni chiave, perchè dove sto lavorando in questo periodo (grossa realtà, 60k impiegati), è installato sui server dove posso effettuare il login (tutti sul cloud), e non sulle postazioni utente (sia macchine fisiche, che postazioni virtuali), dove vengono utilizzati altri software di protezione.
Motivi economici di acquisto licenze? Perchè su cloud è una soluzione chiavi in mano integrata con i pannelli dei maggiori provider? non saprei, potrei solo speculare


*con un ruolo qualunque nel landscape