Linux.Darlloz è un worm che attacca i router

Linux.Darlloz è un worm che attacca i router

È stato individuato un nuovo malware che ha per target i router e sfrutta una vulnerabilità già risolta da parecchi mesi. È però necessario che il produttore abbia rilasciato un apposito update mentre a cura dell'utente rimane l'installazione del firmware aggiornato.

di pubblicata il , alle 12:31 nel canale Sicurezza
 
34 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
WarDuck30 Novembre 2013, 15:38 #21
Originariamente inviato da: s0nnyd3marco
La frammentazione di linux e' sfavorevole ai malware per il fatto che non puoi dare per scontato di poter sfruttare un certo exploit su una macchina (chissa' che versione del kernel, che librerie, che configurazione, se compilata con che use flag ecc).


Non puoi mischiare le carte, devi dire a che livello ti metti.

Se la vuoi vedere al livello kernel, allora saranno colpite tutte le distribuzioni che hanno la specifica versione del kernel con gli appositi flag compilati (es. se voglio attaccare Ubuntu 12.04LTS so per certo che la maggioranza di queste distribuzioni avrà kernel 3.2, così come Debian 7, volendo posso anche andarmi a leggere il config per vedere quali sono i flags di default).

Se la vuoi vedere a livello applicativo allora già non ti interessa più la frammentazione di Linux (in quanto kernel), ma saranno interessati tutti i sistemi che hanno quella specifica versione dell'applicativo.

Se la vuoi vedere a livello di librerie allora saranno colpite tutte le distribuzioni e le applicazioni che ci girano sopra che usano quella specifica versione di libreria.

Ovviamente ci può anche essere una dipendenza incrociata per generare una falla, questo si, ma questo può prescindere dal sistema.

Inoltre da questo punto di vista si può ribaltare la frittata e dire che gli aggiornamenti di sicurezza potrebbero non essere distribuiti nello stesso momento tra tutte le piattaforme, come invece avviene su Windows.

E' chiaro che ogni cosa ha i suoi pregi ed i suoi difetti.

Originariamente inviato da: s0nnyd3marco
La parte in assembly spiegala, perche' non vedo cosa ha a che fare con il discorso delle librerie.


Era per dire, anche perché in realtà non è neanche più necessario: si possono creare eseguibili standalone C senza dipendere da alcuna libreria esterna.

Comunque il succo del discorso è che bisogna vedere di che tipo di falla stiamo parlando.

Ogni falla fa storia a se.
WarDuck30 Novembre 2013, 15:43 #22
Originariamente inviato da: Piccioneviaggiatore
Cosa c'entra tutto cio' con il firmware di un modem/router?
per l voro mi occupo di queste problematiche e se si parla di sicurezza di un SISTEMA OPERATIVO non consiglierei Win nenache al mio piu' feroce e antipatico nemico!.


Puoi consigliare quello che vuoi a chiunque tu voglia.

Basta che siamo d'accordo che la sicurezza del sistema operativo è una cosa mentre la sicurezza delle applicazioni un'altra cosa.

Altrimenti non si sta capendo di cosa si parla.

Originariamente inviato da: Piccioneviaggiatore
Conosci per caso un router che abbia un firmware basato su windows?
A memoria non ne conosco.
Qui non si parla di impenetrabilita' ma di sicurezza....
Se vuoi qualcosa i decente,come sistema operativo,usa BSD...ma...cristo...windows proprio NO !!!!


L'utilizzo di Linux è dovuto principalmente ad un discorso di modularità/apertura e personalizzazione. Se Windows avesse queste caratteristiche (e non le ha semplicemente perché è pensato per tutt'altro), nessuno lo vieterebbe in teoria.

Hanno messo il kernel di Windows 8 su un cellulare (WP8 di fatto), quindi tecnicamente lo possono mettere tranquillamente su un router.

Il discorso di sicurezza nel caso dei router è affidato interamente al produttore del router, inoltre bisogna vedere con quali modalità vengono rilasciati eventuali aggiornamenti.

Se l'aggiornamento è a carico del cliente, allora possiamo stare freschi, e non mi venissero a parlare di sicurezza.

La maggior parte dei report annuali di sicurezza dimostra che se tutti aggiornassero i propri sistemi (mac, linux o windows che sia) la maggioranza delle falle non avrebbero effetti.

La verità è che c'è chi non aggiorna, anche per scelta, specie quei sysadmin che per paura di sputtanare tutto NON aggiornano (e succede anche in ambiente Linux purtroppo).
s0nnyd3marco30 Novembre 2013, 20:40 #23
Originariamente inviato da: WarDuck
Non puoi mischiare le carte, devi dire a che livello ti metti.

Se la vuoi vedere al livello kernel, allora saranno colpite tutte le distribuzioni che hanno la specifica versione del kernel con gli appositi flag compilati (es. se voglio attaccare Ubuntu 12.04LTS so per certo che la maggioranza di queste distribuzioni avrà kernel 3.2, così come Debian 7, volendo posso anche andarmi a leggere il config per vedere quali sono i flags di default).

Se la vuoi vedere a livello applicativo allora già non ti interessa più la frammentazione di Linux (in quanto kernel), ma saranno interessati tutti i sistemi che hanno quella specifica versione dell'applicativo.

Se la vuoi vedere a livello di librerie allora saranno colpite tutte le distribuzioni e le applicazioni che ci girano sopra che usano quella specifica versione di libreria.

Ovviamente ci può anche essere una dipendenza incrociata per generare una falla, questo si, ma questo può prescindere dal sistema.

Inoltre da questo punto di vista si può ribaltare la frittata e dire che gli aggiornamenti di sicurezza potrebbero non essere distribuiti nello stesso momento tra tutte le piattaforme, come invece avviene su Windows.

E' chiaro che ogni cosa ha i suoi pregi ed i suoi difetti.


La maggior parte delle distribuzioni principali, quando esce una nuova vulnerabilita', fanno uscire piu' o meno tutte una patch nello stesso periodo. Le altre seguono a ruota. Chiaro che se guardi linux pinco pallo mantenuto da due ragazzetti chissa' quando e se patchano.

Le tue considerazioni sono tutte valide e le condivido; ma la frammentazione di linux (inteso come gnu linux e non solo il kernel) sta anche nelle librerie e nei applicativi (non e' che tutti le distro hanno la stessa versione di libre office, magari i mantainer la hanno patchata con qualcosa di non ufficiale ecc).

Ovviamente sono consapevole che la frammentazione non e' una reale sicurezza, ma solo un disincentivo ai malware writer.


Originariamente inviato da: WarDuck
Era per dire, anche perché in realtà non è neanche più necessario: si possono creare eseguibili standalone C senza dipendere da alcuna libreria esterna.

Comunque il succo del discorso è che bisogna vedere di che tipo di falla stiamo parlando.

Ogni falla fa storia a se.


Sarei curioso di sapere se c'e' una classifica sull'uso dei linguaggi nella scrittura dei malware.
LMCH01 Dicembre 2013, 01:19 #24
Originariamente inviato da: WarDuck
Quando un malware attacca Java/Flash/Adobe e vulnerabilità varie degli applicativi Windows si da la colpa al sistema operativo Windows.


Se la cosa dipende dall'applicazione si da la colpa all'applicazione, ma molta confusione in proposito è stata causata da Microsoft stessa quando durante la causa Antitrust riguardo i web browser ha dichiarato che IE era "parte integrante del sistema operativo".

IE per anni ha avuto un fottio di problemi a causa della sua architettura COM-based che lo rendeva estremamente vulnerabile ad attacchi.

In poche parole: chi è causa del suo mal pianga se stesso.
Piccioneviaggiatore01 Dicembre 2013, 02:17 #25

!

@antonio23
Vedo che le domande retoriche sono il tuo forte.
E per fortuna che la mamma ti giudica intelligente.
eraser01 Dicembre 2013, 02:26 #26
Originariamente inviato da: s0nnyd3marco
Sarei curioso di sapere se c'e' una classifica sull'uso dei linguaggi nella scrittura dei malware.


Dipende dalla categoria di malware. Se intendi i classici virus/worm/trojan/backdoor/rootkit sicuramente il C/C++ e il delphi sono tra i più diffusi (con diverse righe di Assembly per quanto riguarda alcuni rootkit specifici). Per infezioni più basilari vengono tranquillamente utilizzati - seppure con minore frequenza - anche linguaggi quali .NET, RealBasic e il Visual Basic
pabloski01 Dicembre 2013, 12:22 #27
Originariamente inviato da: LMCH
IE per anni ha avuto un fottio di problemi a causa della sua architettura COM-based che lo rendeva estremamente vulnerabile ad attacchi.


Hai fatto bene a citare COM. Quello che diceva Warduck è in parte vero, ma va valutato caso per caso.

Quando una vulnerabilità riesce ad eseguire codice remoto, la colpa può essere del singolo software, del sistema operativo o di entrambi. Un OS che non implementa tecniche per evitare l'esecuzione di codice dallo stack, è sicuramente corresponsabile.

MS ha prodotto, per anni, software scadente, a partire dal sistema operativo, cominciando con un OS ( xp ) in cui l'utente di default è amministratore. Insomma, hanno dimostrato di non conoscere ( o non voler implementare ) nemmeno l'abc delle misure di sicurezza, arcinote nell'ambiente da decenni.

Per cui la pessima reputazione se la sono meritata. C'è poco da piagnucolare e gridare al "gombloddo".
barzokk01 Dicembre 2013, 14:09 #28
Originariamente inviato da: pabloski
Insomma, hanno dimostrato di non conoscere ( o non voler implementare ) nemmeno l'abc delle misure di sicurezza, arcinote nell'ambiente da decenni.

lo sappiamo tutti che hanno sempre ignorato i problemi di sicurezza perchè per loro non era strategico
d'altra parte l'utonto vuole solo qualcosa che clicchi next-next-next e fa tutto da solo
si sono mossi (un pochino) solo quando hanno iniziato a perdere clienti


Originariamente inviato da: pabloski
Per cui la pessima reputazione se la sono meritata. C'è poco da piagnucolare e gridare al "gombloddo".

beh, più che meritata, è una feature, la insicurezza è intrinseca del progetto originale windows
eraser01 Dicembre 2013, 15:01 #29
Originariamente inviato da: pabloski
Hai fatto bene a citare COM. Quello che diceva Warduck è in parte vero, ma va valutato caso per caso.

Quando una vulnerabilità riesce ad eseguire codice remoto, la colpa può essere del singolo software, del sistema operativo o di entrambi. Un OS che non implementa tecniche per evitare l'esecuzione di codice dallo stack, è sicuramente corresponsabile.

MS ha prodotto, per anni, software scadente, a partire dal sistema operativo, cominciando con un OS ( xp ) in cui l'utente di default è amministratore. Insomma, hanno dimostrato di non conoscere ( o non voler implementare ) nemmeno l'abc delle misure di sicurezza, arcinote nell'ambiente da decenni.

Per cui la pessima reputazione se la sono meritata. C'è poco da piagnucolare e gridare al "gombloddo".


Linux ha implementato il supporto per l'NX bit con il kernel 2.6.8 nel 2004. Microsoft in Windows XP con il Service Pack 2 nel 2004.

Windows XP ha strumenti per la sicurezza del sistema operativo efficaci e ben funzionanti, tutto sta a volerli utilizzare.

Per quanto riguarda la responsabilità del sistema operativo nell'intercettare le falle delle applicazioni, allora Linux è responsabile del fatto che il server X non garantisca un corretto isolamento degli utenti nella stessa sessione, semplificando di non poco il lavoro di eventuali keylogger.

Mai mi sognerei di dire ciò, ma se queste cose vanno dette per Windows allora vanno dette anche per Linux
barzokk01 Dicembre 2013, 15:43 #30
Originariamente inviato da: eraser
Windows XP ha strumenti per la sicurezza del sistema operativo efficaci e ben funzionanti,

seems legit !

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^