Ho alcuni server Linux, che da quello che posso dire non sono vulnerabili al vettore di attacco shellshock, ma sono curioso di sapere come appare l'attacco nei log. Che aspetto ha un attacco di successo nei log di appache2? Che aspetto avrebbe un attacco di successo nel registro di sistema?
Che aspetto hanno i tentativi falliti? Mi piacerebbe estendere la mia lista nera per attacchi di tipo shell-shock.
Questa è una voce dal mio access_log di ciò che il mio collega ha fatto alla mia macchina di prova ...:
10.11.12.13 - - [25/Sep/2014:16:00:00 -0400] "GET /cgi-bin/testing.cgi HTTP/1.0" 200 1 "-" "() { test;};echo \"Content-type: text/plain\"; echo; echo; /bin/rm -rf /var/www/"
Nel mio registro degli errori ho visto molto di questo:
[Thu Sep 25 16:00:00 2014] [error] [client 10.11.12.13] /bin/rm: cannot remove '/var/www/icons/pie0.png': Permission denied
Bastardo: -)
Un server web ben configurato non sarà in grado di sovrascrivere i suoi registri, e in tutti gli ambienti tranne quelli più piccoli, dovresti utilizzare la registrazione centralizzata per proteggerti dalla perdita di questo tipo di voci di registro.
Se sei sfruttato con successo, potresti vedere molti errori nel file error_log che mostrano tentativi falliti di accesso alle risorse, esecuzione di programmi o cancellazione di file. Se riescono ad aumentare i privilegi e non hai la registrazione off-site, non puoi vedere alcuna prova.
Se si dispone di un server Web Apache con una configurazione standard e di uno script cgi che fa uso di bash, la voce di registro per una richiesta può apparire identica nei seguenti tre casi:
bash che disabilita la funzionalità vulnerabile. L'unica differenza necessaria per trasformare una richiesta legittima in un attacco è la modifica di una delle intestazioni della richiesta, che viene inserita in una variabile di ambiente.
Se l'intestazione User-agent viene utilizzata per eseguire l'attacco, sarà abbastanza visibile nel registro di accesso al registro, poiché tale intestazione viene registrata. Ma ci sono altre intestazioni che possono essere utilizzate per eseguire l'attacco, che non sono registrate di default.
Se un tentativo di attacco non è riuscito a causa del fatto che bash è stato aggiornato alla versione intermedia che ha corretto il bug ma ha comunque permesso di specificare le funzioni attraverso l'ambiente, si vedrebbero gli avvisi nel log degli errori. Potrebbero assomigliare a questo:
[Thu Sep 25 20:46:51.483207 2014] [cgi:error] [pid 26424] [client 10.82.90.125:55631] AH01215: /bin/bash: warning: HTTP_ACCEPT_LANGUAGE: ignoring function definition attempt
[Thu Sep 25 20:46:51.483316 2014] [cgi:error] [pid 26424] [client 10.82.90.125:55631] AH01215: /bin/bash: error importing function definition for 'HTTP_ACCEPT_LANGUAGE'
La maggior parte delle cose che si possono notare al momento sono sonde, scansione di server casuali per possibili vettori di attacco, quindi è consigliabile eseguire patch.
Un possibile "attacco" o almeno un assegno potrebbe sembrare un po 'come questo:
egrep "};|}\s*;" /var/www/logs/access* xxx.xxx.xxx.xxx - -
[25/Sep/2014:12:12:12 +0100] "GET /cgi-sys/defaultwebpage.cgi
HTTP/1.0" 404 168 "-" "() { :;}; /bin/ping -c 1 xxx.xxx.xxx.xxx"
Dove xxx.xxx.xxx.xxx è l'indirizzo IP.
Ho visto il CISO di Mandiant parlare di recente, ha detto quando gli viene chiesto se c'è sempre un modello di comportamento che distingue un attaccante (malware) da un'attività valida, egli risponde che se l'aggressore si comportava esattamente come un lavoratore valido dovremmo ringraziarli per aver lavorato gratuitamente per noi. Chiaramente, l'aggressore si comporterà in un modo diverso da un lavoratore valido. Ciò implica che, se monitoriamo il comportamento / l'attività su un sistema, dovremmo essere in grado di rilevare se si sono verificate attività malvagie. Sfortunatamente i registri di sistema possono essere manomessi da un aggressore avanzato così come spedire a syslog e tutti i metodi usuali, è necessario monitorare l'intero comportamento del sistema in qualche modo per cercare le anomalie piuttosto che raschiare solo un registro. Scusate se questa è una risposta scomoda ma gli APT sono piuttosto scomodi ... Apprezzo che questo post non risponda effettivamente alla domanda postata originale e che quindi non sia al 100% utile, ma voglio che le persone si ricordino di non focalizzarsi troppo da vicino su uno specifico voce del registro e non dimenticare di monitorare / analizzare anche il comportamento generale
Leggi altre domande sui tag logging bash vulnerability shellshock