slacky.eu

Devo controllare se sono vulnerabile ad un exploit di Signal Handling di OpenSSH
CVE-2006-5051 e CVE-2006-4924

vedere la versione di ssh non è sufficente.
Ho un openssh 4.3 (la fix è implementata nella 4.4) ma è un ssh che contiene backport di alcune patch di sicurezza.

Esiste uno script che mi può effettuare il test o tentare l'attacco?


Per esempio con il bug di apache (riguardo il ByteRange) esiste uno script che tenta l'attacco e ti dice se sei vulnerabile o meno.
Per il bug in oggetto invece non sono ancora riuscito a trovarlo.

CVE-2006-4924: http://www.securityfocus.com/bid/20216/exploit

per l'altro invece,da una veloce ricerca,non mi pare ci siano proof-of-concept

grazie.
lo cercavo ma non lo trovavo.
Mi restituisce

[*] OpenSSH Pre-Auth DoS PoC by taviso@google.com
[*] Attacking localhost...
[*] remote server identifies as SSH-2.0-OpenSSH_4.3.
[*] IP spoofing cookie was 61 6a 6f 72 20 76 65 72.


da notare comunque che se non erro è affetto il protocollo sshv1, mentre io ho nel mio sshd_config

Protocol 2

comunque sono riuscito a trovare il changelog della versione ssh che ho installata:

* Tue Oct 03 2006 Tomas Mraz <tmraz@redhat.com> - 4.3p2-10
- improve gssapi-no-spnego patch (#208102)
- CVE-2006-4924 - prevent DoS on deattack detector (#207957)
- CVE-2006-5051 - don't call cleanups from signal handler (#208459)

(redhat 5)

in pratica tutto questo è perchè mi sono stati fatti, al lavoro, i penetration test, e mi hanno segnalato questa vulnerabilità e marcata come alta priorità. Ma a quanto pare si sono limitati a vedere che il banner gli diceva openssh 4.3 e non hanno fatto il vero e proprio test di attacco.

i VA (perlomeno in Italia) si fanno così (a differenza dei pentest); tramite tool precotto (nessus o altro tool proprietario) fanno uno scan, senza testare la vulnerabilità; il che è comprensibile, l'exploit può portare disservizio o casini vari su roba in produzione, il problema poi è far capire al service manager di turno che su nessun sistema operativo serio gli update di sicurezza innalzano la versione dei pacchetti (perchè una nuova versione potrebbe portare casini di retrocompatibilità, funzionalità non più supportate, ecc..), ma si limitano a far backporting del fix sulla versione corrente.
Purtroppo ad ogni VA tocca andare su redhat network, cercare i pacchetti, pigliare il changelog ed andare di CTRL+f

il che,se baro tutti i banner,significa che sono ultrasicuro a prescindere

notsafe ha scritto:il che,se baro tutti i banner,significa che sono ultrasicuro a prescindere

anche a questo dovrebbero servire gli ambienti di collaudo (che in Italia, quando esistono, sono spesso diversi da quelli di produzione, quindi inutili), in modo da poter fare un vero pentest (e se qualche servizio crepa a causa di un exploit chissenefrega, tanto non siamo in produzione) anzichè un controllo dei banner dei servizi o poco più.

masalapianta ha scritto:i VA (perlomeno in Italia) si fanno così (a differenza dei pentest)

dici che quando mi hanno fatto i pentest (si, mi hanno fatto, in tempi distinti, sia VA che pentest; ora ci stiamo occupando dei VA) hanno proprio fatto l'attacco? (beh, in effetti l'hanno fatto sulle macchine di collaudo e non su quelle di produzione). Inizialmente sembrava che pure là si erano limitati a vedere la versione, ma ora che ci penso io la versione di apache (per il byterange) l'ho camuffata in fase di compilazione (è utile, anche se un hacker di professione non lo ferma ).

Purtroppo ad ogni VA tocca andare su redhat network, cercare i pacchetti, pigliare il changelog ed andare di CTRL+f

ho appena scoperto il parametro --changelog di rpm. comunque si, è una scocciatura comunque, anche perchè nel VA non ti dicono mica "CVE-xxxxx" ma te lo devi scoprire tu su google, ammesso che esiste.
Per esempio:
http://pastebin.com/9mPj1Tts

CVE ID: -