Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/speakup-il-trojan-invisibile-agli-antivirus_80810.html

Check Point ha identificato SpeakUp, un nuovo malware che attacca sistemi Linux per installare cryptominer e aprire la strada ad altri trojan. Il problema è che a oggi non è rilevabile ad alcun antivirus.

Click sul link per visualizzare la notizia.

"Mariaaaa.... i popcorn e la birra!"

"SpeakUp attacca macchine Linux e si diffonde tramite vulnerabilità del tipo Command Injection over HTTP"

Quindi utilizzano una falla di apache? di nginx?


"Dal momento che Linux è ampiamente utilizzato nei server aziendali, ci aspettiamo una grande crescita di Speakup nel corso dell'anno"

Grande crescita che vuole dire?
Al massimo sono a rischio i server che utilizzano appunto un servizio httpd e che sono esposti direttamente su internet e senza uno straccio di firewall/proxy.
PEr esperienza, a parte piccole realtà che non conosco, i server web si piazzano dentro dmz blindate per evitare appunto attacchi dall'esterno e se anche un server dovesse essere compromesso l'infezione resterebbe isolata ai soli server abilitati a parlarci secono le regole definite sui firewall.

Diciamo che in un'architettura classica web->app->db al massimo il trojan puo' replicarsi su due server, non su tutta la rete.

qualche info più precisa che era il caso di includere nell'articolo: https://research.checkpoint.com/speakup-a-new-undetected-backdoor-linux-trojan/

qualche info più precisa che era il caso di includere nell'articolo: https://research.checkpoint.com/speakup-a-new-undetected-backdoor-linux-trojan/


quindi oltre ad un servizio http sulle macchine deve esserci installato pure php e perl.

Tra l'altro una buona regola di sicurezza é montare /tmp senza i diritti di esecuzione, cosi' anche nel caso in cui ci fossero tutti i prerequisiti necessari l'exploit non funzionerebbe.

quindi oltre ad un servizio http sulle macchine deve esserci installato pure php e perl.

Tra l'altro una buona regola di sicurezza é montare /tmp senza i diritti di esecuzione, quindi anche nel caso in cui ci fossero tutti i prerequisiti necessari l'exploit non funzionerebbe.

non ho poi capito se solo certe versioni di php/perl sono vulnerabili o meno.
potrebbe anche essere che versioni più recenti siano state patchate e magari questa vulnerabilità non sia sfruttabile.:stordita:

Una buona sintesi la trovate qui https://debuglies.com/2019/02/05/speakup-new-cryptocurrency-malware-hits-linux-mac-devices/

p.s. attacca pure macOS e non solo Linux

Spaventoso e totalmente indifendibile... Linux è totalmente bucato!

Spaventoso e totalmente indifendibile... Linux è totalmente bucato!

Quindi Windows è una groveria, visto che c'è un'intera industria che fa miliardi sul malware per Windows?

E perchè non citi macOS, che pure è vittima di questa campagna malevola?

Solita trollata?

No, voglio solo dire che il mito di Linux sicuro decade...

e sì MacOS ad usare Unix come kernel (o meglio ad avere la "compatibilità" con l'ecosistema Unix / Linux) alla luce di sto cose non è che sia stata una grande idea.

Dico di più ci sono 60'000'000 di PS4 con kernel Unix e browser completamente bacato che ne sappiamo che non stiano minando criptovalute come ossesse?

Quindi Windows è una groveria, visto che c'è un'intera industria che fa miliardi sul malware per Windows?

E perchè non citi macOS, che pure è vittima di questa campagna malevola?

Solita trollata?

/whoosh!

No, voglio solo dire che il mito di Linux sicuro decade...

e sì MacOS ad usare Unix come kernel (o meglio ad avere la "compatibilità" con l'ecosistema Unix / Linux) alla luce di sto cose non è che sia stata una grande idea.

Dico di più ci sono 60'000'000 di PS4 con kernel Unix e browser completamente bacato che ne sappiamo che non stiano minando criptovalute come ossesse?hai visto troppi film di fantascienza...
torna a guardare Uomini e Donne che è meno impegnativo

No, voglio solo dire che il mito di Linux sicuro decade...

e sì MacOS ad usare Unix come kernel (o meglio ad avere la "compatibilità" con l'ecosistema Unix / Linux) alla luce di sto cose non è che sia stata una grande idea.

Dico di più ci sono 60'000'000 di PS4 con kernel Unix e browser completamente bacato che ne sappiamo che non stiano minando criptovalute come ossesse?

Perché sulle PS4 girano i vari servizi indicati nei link (postati da noi, non dalla redazione)? C’è installato php e perl?
Vabbè dai, sai trollare meglio di così.

No, voglio solo dire che il mito di Linux sicuro decade...

e sì MacOS ad usare Unix come kernel (o meglio ad avere la "compatibilità" con l'ecosistema Unix / Linux) alla luce di sto cose non è che sia stata una grande idea.

Dico di più ci sono 60'000'000 di PS4 con kernel Unix e browser completamente bacato che ne sappiamo che non stiano minando criptovalute come ossesse?

beh si é pieno di gente che mette su un server apache con php sulla ps4 per farci girare l'intranet aziendale o il sitarello con wordpress per postare i blog :asd: :asd: :asd:
mi rendo conto che forse il tuo post non meritava manco risposta, ma vabbè ormai é fatto

quindi oltre ad un servizio http sulle macchine deve esserci installato pure php e perl.

Tra l'altro una buona regola di sicurezza é montare /tmp senza i diritti di esecuzione, cosi' anche nel caso in cui ci fossero tutti i prerequisiti necessari l'exploit non funzionerebbe.
/tmp senza x?
di default lo è, non c'è un motivo perchè lo sia? :confused:

/tmp senza x?
di default lo è, non c'è un motivo perchè lo sia? :confused:

evidentemente non hai mai lavorato in ambienti dove la sicurezza ê un argomento all'ordine dell giorno e se avessi letto il rapporto di checkpoint capiresti di cosa parlo.
Nelle aziende i parametri di default non si lasciano nemmeno sulle macchine di sviluppo.

Leggendo qui (https://research.checkpoint.com/speakup-a-new-undetected-backdoor-linux-trojan/) è un problema noto fino da novembre 2018 (https://nvd.nist.gov/vuln/detail/CVE-2018-20062#vulnCurrentDescriptionTitle) relativo a una libreria PHP (https://github.com/nangge/noneCms/blob/master/thinkphp/library/think/App.php).
Non è un problema del sistema operativo GNU/linux il quale è utilizzato come veicolo di infezione...

beh si é pieno di gente che mette su un server apache con php sulla ps4 per farci girare l'intranet aziendale o il sitarello con wordpress per postare i blog :asd: :asd: :asd:
mi rendo conto che forse il tuo post non meritava manco risposta, ma vabbè ormai é fatto

Sinceramente per quanto ami il marchio Sony non sono molto attenti alla sicurezza... si sono dimenticati le chiavi GPG in chiaro sulla Plastation Classic, quindi perché non PHP o Perl o Python?

Lo sai vero che PS4 non è altro che un PC con hardware un po' particolare in cui gira Net BSD?

Lo stesso modo in cui si fa il jailbreak della PS4 (usando javascript a un bug risolto da 10 anni!) usando l'online potrebbe essere un veicolo d'infezione...

Sinceramente per quanto ami il marchio Sony non sono molto attenti alla sicurezza... si sono dimenticati le chiavi GPG in chiaro sulla Plastation Classic, quindi perché non PHP o Perl o Python?

Lo sai vero che PS4 non è altro che un PC con hardware un po' particolare in cui gira Net BSD?

Lo stesso modo in cui si fa il jailbreak della PS4 (usando javascript a un bug risolto da 10 anni!) usando l'online potrebbe essere un veicolo d'infezione...

e questo che c'entra con la news?
Ma se non sai di cosa si parla non é meglio tacere?
Comunque per tua informazione BSD non é manco linux tecnicamente.

evidentemente non hai mai lavorato in ambienti dove la sicurezza ê un argomento all'ordine dell giorno e se avessi letto il rapporto di checkpoint capiresti di cosa parlo.
Nelle aziende i parametri di default non si lasciano nemmeno sulle macchine di sviluppo.
linux ce l'ho a casa sulla mia macchina, quindi come viene gestito un server aziendale non m'interessa.
chiedevo chiarimenti su come si può migliorare la sicurezza su una macchina casalinga, visto che ho notato che /tmp è x per tutti.
Se vuoi fornire chiarimenti bene, oppure me ne farò una ragione :)

Lo sai vero che PS4 non è altro che un PC con hardware un po' particolare in cui gira Net BSD?

FreeBSD.

FreeBSD.

quindi fatemi capire... il porting dei giochi su linux &C è un gioco da ragazzi...

linux ce l'ho a casa sulla mia macchina, quindi come viene gestito un server aziendale non m'interessa.
chiedevo chiarimenti su come si può migliorare la sicurezza su una macchina casalinga, visto che ho notato che /tmp è x per tutti.
Se vuoi fornire chiarimenti bene, oppure me ne farò una ragione :)

Una cosa del genere ( in /etc/fstab )

tmpfs /tmp tmpfs defaults,nodev,nosuid,noexec 0 0

Il noexec elimina ogni possibilità di eseguire roba da /tmp. tmpfs la mette in ram, così viene flushata ad ogni riavvio.

Però io preferisco una soluzione nettamente migliore. Questa

/dev/nvme0n1p2 on /run/miso/bootmnt type ext4 (ro,relatime)
cowspace on /run/miso/cowspace type tmpfs (rw,relatime,size=262144k,mode=755)
overlay_root on /run/miso/overlay_root type tmpfs (rw,relatime,mode=755)
/dev/loop0 on /run/miso/sfs/livefs type squashfs (ro,relatime)
overlay on / type overlay (rw,relatime,lowerdir=/run/miso/sfs/livefs,upperdir=/run/miso/overlay_root/upper,workdir=/run/miso/overlay_root/work)


In parole povere, l'intero root filesystem è montato read-only a partire da un'immagine squashfs. La parte write è un overlay in ram.

Non aiuta in generale ad evitare infezioni, elimina però qualsiasi possibilità di persistenza del malware. Cioè ad ogni riavvio si è sicuri che il sistema sia 100% pulito. E' una buona soluzione per un sistema da usare per l'home banking, magari su una pendrive.

quindi fatemi capire... il porting dei giochi su linux &C è un gioco da ragazzi...

Non credo. E' come per Android. C'è il kernel Linux ma un userland completamente differente.

Non è nemmeno dato sapere che PS4 e precedenti implementano le specifiche OpenGL o qualcosa di simile ma diverso e proprietario.

Orbis ( l'OS di PS4 ) ha il kernel FreeBSD, una serie di librerie utili ( tipo OpenSSL ), forse qualche comando dell'userland ( tipo mount, ip, ecc... ), ma il resto è roba proprietaria Sony. Soprattutto la parte che riguarda la grafica 3D e il suono.

Ovviamente il driver per la GPU è proprietario, ma comunque sì è possibile far girare Linux su PS4 eccome se è possibile, gli emulatori fino al N64 vanno (quello dello Wii per ora va a 20 FPS), Steam funziona e persino Wine!

Il driver Linux ha pure accelerazione hardware facendo un "porting" dai driver opensource di X...

https://www.youtube.com/watch?v=02fx1Zhs-c0&vl=en

Ovviamente il driver per la GPU è proprietario


Ed è la parte comica. Un driver FreeBSD per GPU Radeon, che non è mai arrivato nell'ecosistema FreeBSD. Tant'è che FreeBSD ancora oggi si sbatte per fare il porting ( alla meno peggio ) dei driver Radeon per Linux.

Sono queste le situazioni che mi hanno fatto propendere per la GPL. Sarà virale e rompiscatole per le multinazionali, ma almeno segue la logica del "'ca nisciun è fess".

linux ce l'ho a casa sulla mia macchina, quindi come viene gestito un server aziendale non m'interessa.
chiedevo chiarimenti su come si può migliorare la sicurezza su una macchina casalinga, visto che ho notato che /tmp è x per tutti.
Se vuoi fornire chiarimenti bene, oppure me ne farò una ragione :)

Nel tuo precedente post piu' che porre una questione avevo l'impressione che stessi rispondendo ...
Comunque nessun problema, te lo spiego molto semplicemente.

Lo /tmp é di fatto un porto franco dove spesso le applicazioni vanno a scrivere e ad eseguire procressi perché, appunto, é un FS che si presta a questo e ti evita di avere errori di permission denied quando vuoi installare o lanciare qualcosa senza parametrare la directory di lavoro.
Ora cio' che succede nella normalità é che /tmp é accessibile a tutti, quindi un utente qualsiasi se esegue un codice o installa un'applicazione che ha bisogno di un'area "tampone" per eseguirsi o installarsi andrà in /tmp.
Cio' che puo' succedere é che un software malevolo puo' utilizzare tmp per eseguire codice senza che l'utente se ne accorga e sui server é buona regola montare lo /tmp senza permessi di esecuzione.
Su un pc montare/tmp in noexec é fattibile ma piu' complicato da gestire perché rispetto ad un server sei piu' soggetto ad installare applicazioni e quindi ti tocca ogni volta parametrarle e cambiare il percorso di default da /tmp a $HOME/tmp per esempio, ma non é manco detto che tutte le appllicazioni che installi abbiano questa opzione.
Ad ogni modo dubito che sul computer di casa ci metti su un webserver con php ;)

Una cosa del genere ( in /etc/fstab )

tmpfs /tmp tmpfs defaults,nodev,nosuid,noexec 0 0

Il noexec elimina ogni possibilità di eseguire roba da /tmp. tmpfs la mette in ram, così viene flushata ad ogni riavvio.
ok, capito. però non basta "pulire" /tmp anche se è su disco e non in ram?


Però io preferisco una soluzione nettamente migliore. Questa

/dev/nvme0n1p2 on /run/miso/bootmnt type ext4 (ro,relatime)
cowspace on /run/miso/cowspace type tmpfs (rw,relatime,size=262144k,mode=755)
overlay_root on /run/miso/overlay_root type tmpfs (rw,relatime,mode=755)
/dev/loop0 on /run/miso/sfs/livefs type squashfs (ro,relatime)
overlay on / type overlay (rw,relatime,lowerdir=/run/miso/sfs/livefs,upperdir=/run/miso/overlay_root/upper,workdir=/run/miso/overlay_root/work)


In parole povere, l'intero root filesystem è montato read-only a partire da un'immagine squashfs. La parte write è un overlay in ram.

Non aiuta in generale ad evitare infezioni, elimina però qualsiasi possibilità di persistenza del malware.
qua capisco meno.... monti TUTTO il fs in ram?!?:eek: :confused:
e quanti terabyte di ram devi installare?!? :confused:
penso di aver capito male...:(


...Lo /tmp é di fatto un porto franco dove spesso le applicazioni vanno a scrivere
...
Ora cio' che succede nella normalità é che /tmp é accessibile a tutti, quindi un utente qualsiasi se esegue un codice o installa un'applicazione che ha bisogno di un'area "tampone" per eseguirsi o installarsi andrà in /tmp.
Cio' che puo' succedere é che un software malevolo puo' utilizzare tmp per eseguire codice senza che l'utente se ne accorga e sui server é buona regola montare lo /tmp senza permessi di esecuzione.

Su un pc montare/tmp in noexec é fattibile ma piu' complicato da gestire perché rispetto ad un server sei piu' soggetto ad installare applicazioni e quindi ti tocca ogni volta parametrarle e cambiare il percorso di default da /tmp a $HOME/tmp per esempio, ma non é manco detto che tutte le appllicazioni che installi abbiano questa opzione.
Ad ogni modo dubito che sul computer di casa ci metti su un webserver con php ;)
ah, ecco. mi pareva che andasse bene per server dove aggiorni solo un pacchetto alla volta ogni mese... ma non per un homepc dove ogni giorno l'updater scarica ed installa decine di librerie, applicazioni, office, browser, client vari, X, mesa e compagnia cantando... :)
in queste situazioni impedire l'esecuzione in /tmp mi sa che inchioderebbe tutto in meno di 5 minuti.
ok, quindi per un caso "normale" è corretto che /tmp sia x. Eventualmente è utile che lo sia solo per utente e gruppo, e non per altri? O ci si cerca rogne lostesso?

ah, ecco. mi pareva che andasse bene per server dove aggiorni solo un pacchetto alla volta ogni mese... ma non per un homepc dove ogni giorno l'updater scarica ed installa decine di librerie, applicazioni, office, browser, client vari, X, mesa e compagnia cantando... :)
in queste situazioni impedire l'esecuzione in /tmp mi sa che inchioderebbe tutto in meno di 5 minuti.
ok, quindi per un caso "normale" è corretto che /tmp sia x. Eventualmente è utile che lo sia solo per utente e gruppo, e non per altri? O ci si cerca rogne lostesso?

in realtà i pacchetti installati via yum, apt, ecc non hanno bisogno dello /tmp, sono piu' che altro applicazioni di terze parti, tipo i programmi java che pero' nel 90% dei casi sono configurabili e puoi modificare la temp dir.
Comunque ripeto, qua si parla di un exploit che sfrutta l'httpd+php, nessun pc con linux, a parte qualche macchina di sviluppo, avrà un demone http installato e attivo.
Come al solito i rischi sulla sicurezza sono piu' teorici che reali e la psicosi dell'utente medio fa bene solo alle software house che vendono gli antivirus e soluzioni complementari e sono spesso le stesse software house che sviluppano questi malware/trojan

in realtà i pacchetti installati via yum, apt, ecc non hanno bisogno dello /tmp, sono piu' che altro applicazioni di terze parti, tipo i programmi java che pero' nel 90% dei casi sono configurabili e puoi modificare la temp dir.
Comunque ripeto, qua si parla di un exploit che sfrutta l'httpd+php, nessun pc con linux, a parte qualche macchina di sviluppo, avrà un demone http installato e attivo.
Come al solito i rischi sulla sicurezza sono piu' teorici che reali e la psicosi dell'utente medio fa bene solo alle software house che vendono gli antivirus e soluzioni complementari e sono spesso le stesse software house che sviluppano questi malware/trojan

che l'articolo parli di "linux" ma in realtà il problema sia di altro, mi è chiaro.
quel che non ho capito è se serve, su una macchian domestica, disabilitare x su /tmp o se si rischia solo di far incastrare qualche sw o script che si aspetta una configurazione standard. che apt già non abbia problemi mi solleva, ma altri?
guardando la mia /tmp ora c'è una cartella dell'updater che contiene una specie di log, una cartella mozilla, una ssh, un po' di systemd-private (cui non fa accedere :mbe: ) un paio di temp con dentro roba di mesa:confused: , una decina di file xpi... :confused: