Il malware gestito da un utente senza privilegi di amministratore o sudo può danneggiare il mio sistema? [chiuso]


30

Dopo una recente penetrazione su una macchina che esegue Linux, ho trovato un file eseguibile nella cartella home di un utente con una password debole. Ho ripulito quello che sembra essere tutto il danno, ma sto preparando una pulizia completa per essere sicuro.

Cosa può fare il malware gestito da un utente NON sudo o non privilegiato? Sta solo cercando i file contrassegnati con il permesso scrivibile dal mondo di infettare? Quali cose minacciose può fare un utente non amministratore sulla maggior parte dei sistemi Linux? Potete fornire alcuni esempi di problemi del mondo reale che questo tipo di violazione della sicurezza può causare?


14
Può fare qualsiasi cosa tu possa fare come utente non privilegiato, che potrebbe essere un sacco di cose.
Faheem Mitha,

1
Dipende dalla configurazione e se la macchina è ben mantenuta. Può variare dal solo invio di malware o dall'essere parte di una botnet, dall'escalation dei privilegi, dal fare tutte quelle cose e compromettere ulteriormente la macchina e la sicurezza della tua rete.
Rui F Ribeiro,

9
Se il malware è abbastanza sofisticato, può sfruttare le vulnerabilità per ottenere l'accesso come root. Un sistema violato deve sempre essere considerato completamente rotto e deve essere immediatamente disconnesso.
Runium,

2
Nota: di solito gli exploit sono inattivi per mesi. Lo sfruttatore venderà la capacità di fare cose cattive agli altri.
Giacomo Catenazzi,

Risposte:


29

Gli utenti più normali possono inviare posta, eseguire utility di sistema e creare socket di rete in ascolto su porte più alte. Questo significa che un attaccante potrebbe

  • inviare mail di spam o phishing,
  • sfruttare qualsiasi configurazione errata del sistema visibile solo dall'interno del sistema (si pensi ai file della chiave privata con permessi di lettura permissivi),
  • impostare un servizio per distribuire contenuti arbitrari (ad es. porno torrent).

Cosa significa esattamente dipende dalla tua configurazione. Ad esempio, l'aggressore potrebbe inviare posta apparentemente proveniente dalla tua azienda e abusare della reputazione della posta dei tuoi server; ancora di più se sono state impostate funzionalità di autenticazione della posta come DKIM. Funziona fino a quando il rappresentante del tuo server non è contaminato e altri server di posta iniziano a inserire nella lista nera IP / dominio.

In entrambi i casi, il ripristino dal backup è la scelta giusta.


17
L'attaccante può crittografare tutti i dati degli utenti e richiedere un pagamento per ottenere la chiave privata per esso
Ferrybig

1
@Ferrybig Possono solo crittografare la versione corrente, non i backup. La domanda diventa quindi: l'insieme dei backup non è vuoto?
PyRulez

Conosciamo tutti la solita risposta a questa domanda, @PyRulez: O
TheBlastOne

L'invio di e-mail da un server implica che puoi utilizzare gli indirizzi e-mail @ il tuo dominio, in un modo più distinguibile rispetto all'utilizzo di un server completamente irrilevante?
user23013

1
@ user23013 Non necessariamente, ma con molti sistemi, lo fa. I postmaster possono configurare tecnologie come SPF , DKIM e DMARC che consentono ai server remoti di convalidare la legittimità della posta in arrivo. Alcuni mailer (ad esempio Gmail) offrono un'opzione per evidenziare i messaggi validati in questo modo. Un utente malintenzionato potrebbe abusare di questo per inviare messaggi di phishing apparentemente affidabili.
tarleb,

19

Alla maggior parte delle risposte mancano le due parole chiave: escalation di privilegi .

Uno che un utente malintenzionato ha accesso a un account senza privilegi, è molto più facile per loro sfruttare i bug nel sistema operativo e nelle librerie per ottenere un accesso privilegiato al sistema. Non dovresti presumere che l'attaccante abbia usato solo l'accesso non privilegiato che aveva originariamente ottenuto.


2
Stavo aspettando di postare per vedere se qualcuno ha notato questo particolare rischio reale. Buffer trabocca, l'amico perpetuo di tutti i malcreati, lol. Avresti dovuto avere più di 1 perché questo è il vero rischio reale, non uno spyware a livello di utente, il che è fastidioso, ma questo è tutto. Escalation di privilegi, che porta all'installazione di rootkit, che porta a una macchina totalmente di proprietà, con exploit essenzialmente non rilevabili che corrono felici dietro le quinte.
Lizardx

15

Una rm -rf ~o qualcosa di simile sarebbe abbastanza catastrofica, e non hai bisogno dei privilegi di root.


15
Cari nuovi arrivati ​​UNIX, non provateci! (cancellerà i tuoi file personali)
AL

1
Esattamente come dice AL. rm -rf /è molto più sicuro (jk non farlo. Uccide tutto: urbandictionary.com/define.php?term=rm+-rf+%2F. )
PyRulez

12

ransomware

Non si applica alla tua situazione, dal momento che l'avresti notato, ma per gli attacchi al giorno d'oggi un po 'popolari del ransomware (crittografia di tutti i tuoi documenti e offerta di vendita della chiave di decrittografia) è completamente sufficiente avere accesso senza privilegi.

Non è in grado di modificare i file di sistema, ma in genere ricostruire un sistema da zero è semplice rispetto al recupero di preziosi dati utente (documenti aziendali, foto di famiglia, ecc.) Da backup che spesso sono obsoleti o inesistenti.


11

Più comune (nel mio POV, dalla mia esperienza):

  • Invio di spam

  • Invio di più spam

  • Infettare altri computer

  • Installa siti di phishing

  • ...


2
Hai dimenticato altro spam.
Autar

4

Un virus può infettare tutte le macchine della rete LAN ed elevare il privilegio per ottenere l'accesso root wiki-Privilege_escalation

L'escalation dei privilegi è l'atto di sfruttare un bug, un difetto di progettazione o una supervisione della configurazione in un sistema operativo o un'applicazione software per ottenere un accesso elevato alle risorse che sono normalmente protette da un'applicazione o da un utente. Il risultato è che un'applicazione con più privilegi di quelli previsti dallo sviluppatore dell'applicazione o dall'amministratore di sistema può eseguire azioni non autorizzate.


0

Mi vengono in mente molte potenziali possibilità:

  • Denial of service: potrebbe essere sulla tua macchina o più probabile, usa la tua macchina per attaccarne una seconda a spese delle tue risorse.
  • I miei bitcoin. L'uso della CPU per ottenere denaro sembra abbastanza interessante
  • Se il browser è vulnerabile, proveranno a reindirizzarti verso ogni tipo di sito, installare barre o mostrare pop-up che daranno loro entrate. Fortunatamente questo sembra più difficile in Linux o gli spammer non sono così bravi in ​​questo.
  • Ottieni dati privati ​​per uso commerciale e vendili ad altri. Solo per l'utente compromesso: data di nascita, telefono, se si trova nella cache del browser.
  • Accedi ad altri file nel server leggibili.
  • Crea script dannosi che potrebbero richiedere la password di root. Ad esempio, nel tuo bash potrebbero provare a reindirizzare sudo ad altre cose per ottenere la tua password.
  • Ottenere le password memorizzate nel browser o provare a eseguire il keylog delle credenziali bancarie. Questo potrebbe essere più difficile, ma sicuramente sarà pericoloso. Con Gmail possono ottenere Facebook, rubare il tuo account Steam, Amazon, ecc.
  • Installa certificati dannosi validi per il tuo utente

Naturalmente questo è uno scenario peggiore, quindi non fatevi prendere dal panico. Alcuni di questi potrebbero essere bloccati da altre misure di sicurezza e non saranno affatto banali.


0

Informazioni [1]

IMHO una delle cose più spaventose che un exploit può fare è raccogliere informazioni e rimanere nascosto per tornare e colpire quando la tua attenzione sarà inferiore (ogni notte o periodo di vacanza sarà adatto).
I seguenti sono solo i primi motivi che mi vengono in mente, puoi aggiungere altri e altri ...

  • Informazioni sui servizi in esecuzione, sulla loro versione e sui loro punti deboli, con particolare attenzione a quello obsoleto che potrebbe essere necessario mantenere in vita per motivi di compatibilità.
  • Periodicità con cui li aggiorni e le patch di sicurezza. Sedersi di fronte a un bollettino e attendere il momento giusto per provare a tornare.
  • Le abitudini dei tuoi utenti, di sollevare meno sospetti quando sarà.
  • Le difese che hai impostato.
  • Se si ottiene anche un accesso root parziale alle chiavi ssh , agli host autorizzati e alle password su questa e altre macchine per ciascun utente (supponiamo che qualcuno abbia eseguito un comando con la password passata come parametro non è nemmeno necessario il privilegio di root). È stato possibile scansionare la memoria ed estrarla. Dico ancora: in entrambi i modi, alla tua macchina e dalla tua macchina. Con l'autorizzazione ssh fronte-retro tra due macchine possono continuare a rimbalzare dentro e fuori dall'account compromesso.

Quindi appiattisci quella macchina e monitora le password e le chiavi future, per questi motivi sopra e tutti gli altri che puoi leggere dalle altre risposte.


[1] Citando non letteralmente Hitchcock: "Un colpo di pistola dura un momento ma una mano che brandisce un'arma può durare un film completo"

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.