Wazuh – Scovare e reagire ad un attacco Shellshock

Published by Lello on

Shellshock è una vulnerabilità che permette esecuzione di comandi remoti all’interno di script bash (o perl, php, ….); si sfruttano vulnerabilità sul passaggio di variabili di ambiente all’interno dello script per eseguire comandi esterni allo script stesso.

Il vantaggio principale dell’utilizzo dei sistemi HIDS per il rilevamento degli attacchi web è che il sistema HIDS non analizza il traffico HTTPS (criptato), ma analizza i files di log generati dal web server; questo fa sì che un sistema come Wazuh si dimostri insostituibile in una strategia di sicurezza aziendale.

    In questo articolo, analizzaremo un attacco di tipo Shellshock verso un server su cui risulti installato:

    • un web server apache con mod-cgi attivo
    • wazuh agent

    L’attacco di tipo Shellshock viene individuato tramite le regole 31166, 31167, 31168 e 31169; nel casonostro caso verrà attivata la regola 31168: 

    <rule id="31168" level="15">
       <if_sid>31108</if_sid>
       <regex>"\(\)\s*{\s*\w*:;\s*}\s*;|"\(\)\s*{\s*\w*;\s*}\s*;</regex>
       <description>Shellshock attack detected</description>
       <mitre>
          <id>T1068</id>
          <id>T1190</id>
       </mitre>
       <info type="cve">CVE-2014-6271</info>
       <info type="link">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271</info>
       <group>attack,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
    </rule>

    Verifichiamo che la configurazione dell’agent includa i file di accesso e di errore del webserver:

    <localfile>
       <log_format>apache</log_format>
       <location>/var/log/httpd/*access.log</location>
    </localfile>
    
    <localfile>
       <log_format>apache</log_format>
       <location>/var/log/httpd/*error.log</location>
    </localfile>

    Per testare tale tipo di attacco, utilizzeremo curl:

    # ShellshockTarget="192.168.0.100"
    # curl --insecure $ShellshockTarget -H "User-Agent: () { :; }; /bin/cat /etc/passwd"

    Una volta eseguito il comando, verifichiamo cosa è successo in Wazuh; nei file di log del manager troveremo le seguenti righe:

    ** Alert 1605623461.120325299: mail  - web,accesslog,attack,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
    2020 Nov 17 15:31:01 (Hostname) 192.168.0.100 ->/var/log/httpd/access_log
    Rule: 31168 (level 15) -> 'Shellshock attack detected'
    Src IP: 192.168.0.101
    192.168.0.101 - - [17/Nov/2020:15:31:00 +0100] "GET / HTTP/1.1" 302 210 "-" "() { :; }; /bin/cat /etc/passwd"
    

    Su Kibana troveremo la seguente riga:

    Wazuh Shellshock - 1

    Pertanto l’attacco è stato correttamente rilevato; a questo punto possiamo creare una regola di active-response per bloccare l’indirizzo IP da cui proviene la richiesta.

    Utilizzeremo il comando firewalld-cmd per bloccare l’accesso al nostro webserver all’indirizzo IP da cui proviene l’attacco. Apriamo il file di configurazione di Wazuh ed inseriamo la seguente:

    <active-response>
        <disabled>no</disabled>
        <command>firewall-drop</command>
        <location>local</location>
        <rules_id>31168</rules_id>
        <timeout>300</timeout>
    </active-response>

    Dopo aver riavviato Wazuh manager, se la regola 31168 dovesse venire attivata, sul web server (la direttiva active-response è stata creata per essere attivata sull’host che ha attivato la regola) verrà bloccato l’indirizzo IP sorgente.

    Potremmo bloccare l’accesso a tutta la nostra rete in 2 modi:

    • sostituendo la direttiva
      • <location>local</location> (esecuzione solo sulla macchina che ha generato l’evento) con la regola
      • <location>all</location> (esecuzione su TUTTE le macchine su cui è installato Wazuh agent – operazione abbastanza rischiosa e da valutare accuratamente)
    • nel caso in cui avessimo come firewall OPNsense (come si è già visto), sostituendo il comando
      • <command>firewall-drop</command>
      • <command>opnsense-ban</command>

    ← Wazuh – Scovare e prevenire attacchi ransomware – Part 3