Niente, sembra che io non riesca proprio a scrivere l’ultimo post che parla di #shellshock e del codice della bash che giace nei repository a testimoniare come si scriveva software negli anni settanta.

Non è stato un anno semplice per ssl, heartbleed prima ed ora poodle.

Thai Duong e Krzysztof Kotowicz. Potete quindi partire, se volete, con teorie complottiste a più non posso su #nsa che ci spia, #google che sapeva del bug da decenni ma non ci ha detto niente perché voleva spiare tutte le email che mandavamo e cose del genere. Il fondo di verità c’è, ma so che a voi piace esagerare con la cospirazione.

Per gli altri, il problema è nel protocollo ssl versione 3.0 che è vecchio e decrepito e soppiantato da anni dal TLS. Tuttavia, per assicurare quella retrocompatibilità che altrimenti non si sa mai, molti siti supportano ancora versioni vecchie dei protocolli ssl.

Subito la mitigazione

Purtroppo disabilitare SSLv3 potrebbe non essere possibile per ragioni di compatibilità. TLS per mitigare questo problema deve usare il meccanismo di fallback TLS_FALLBACK_SCSV

Un client che vuole chiedere un downgrade del protocollo deve includere, nella comunicazione, il valore 0x56, 0x00 (TLS_FALLBACK_SCSV) appunto. Il server, ricevendo questo messaggio, controlla la versione proposta dal client con quella più alta supportata dal server. Se il server supporta una versione più alta allora può rifiutare la connessione indicando al client a quale versione si deve uniformare se vuole instaurare una comunicazione sicura.

Questo meccanismo fa in modo che SSLv3 venga utilizzato solamente nelle implementazioni legacy, probabilmente client il cui codice non è più mantenuto da decenni.

Lato client, va disabilitato il supporto ad SSLv3 sui browser. Un JS malevolo, potrebbe sfruttare POODLE forzando il browser vittima a fare un downgrade del protocollo di comunicazione, quindi anche la propria postazione deve essere adeguatamente protetta.

Attacco al cifrario

Allora, non mi metterò qui a fare una traduzione del paper rilasciato e che descrive poodle. I dettagli matematici quindi che interessano la vulnerabilità li lascio a chi brillantemente l’ha scoperta.

Il problema è nei caratteri che vengono passati dal client al server come padding per ottenere i blocchi della dimensione corretta per l’applicazione degli algoritmi di cifratura.

POODLE sta appunto per Padding Oracle On Downgraded Legacy Encryption.

L’attacco consiste nel variare a piacimento il padding, ovvero il numero di caratteri che il browser accoda alla richiesta per aggiustare le dimensioni dei blocchi che poi dovranno essere usati dal server, copiandoci dati della richiesta che si vuole mettere in chiaro, ad esempio dei cookie.

Per come è disegnato il protocollo quando decifra il dato usando la modalità CBC (Cipher Block Chaining), i byte nel blocco di padding sono messi in XOR con i byte del blocco che li precede, sotto il controllo dell’attaccante.

L’attaccante quindi può capire se l’ultimo byte dell’ultimo blocco, usato per il controllo, è corretto se la sua richiesta viene ritenuta valida dal server. Le probabilità di indovinare il valore di un byte è di 1 su 256.

Questo porta l’attaccante a riuscire a mettere in chiaro n byte con in media 256xn richieste.

ciphersurfer

ciphersurfer è un tool in ruby che ho scritto un paio di anni fa per valutare la qualità della configurazione SSL di un server sulla base dei protocolli e dei cifrari supportati.

La teoria alla base del tool è il documento di SSLabs. Lo scopo era anche realizzare i controlli descritti nella Owasp Testing guide. In questo caso, i test sono quelli della guida v3.

Ieri ho modificato il tool affinché fosse disponibile il controllo se un server è vulnerabile a POODLE.

Testare se un host è vulnerabile a POODLE è veramente semplice. Basta creare una richiesta HTTP, forzando la versione del protocollo da usare ad SSLv3. Se il server risponderà alla mia GET allora significa che supporta SSLv3 e quindi è vulnerabile. Se ottengo un errore SSL allora non è vulnerabile.

def self.poodle?(host, port)
  request = Net::HTTP.new(host, port)
  request.use_ssl = true
  request.verify_mode = OpenSSL::SSL::VERIFY_NONE
  request.ssl_version = :SSLv3
  begin
    response = request.get("/")
    return true
  rescue OpenSSL::SSL::SSLError => e
    return false
  rescue
    return false
  end
end

Nello script, ho aggiunto il supporto al nuovo flag da linea di comando e poi questo codice per onorarlo.

if (options[:poodle])
  if Ciphersurfer::Scanner.poodle?(host, port)
    puts "[!] #{target} is vulnerable to POODLE attack. Please remove SSLv3 support"
  else
    puts "[*] #{target} does not support SSLv3"
  end
  exit
end

Per eseguire il test, basta specificare l’host da attaccare con il flag -P. In realtà attaccare è un po’ tirato come termine, visto che in fondo viene fatta solo una GET in HTTPS, quindi a conti fatti non è tutto questo grande attacco.

$ ciphersurfer -P gmail.com:443
[*] gmail.com:443 does not support SSLv3
$ ciphersurfer -P hubmiur.pubblica.istruzione.it:443
[!] hubmiur.pubblica.istruzione.it:443 is vulnerable to POODLE attack. Please remove SSLv3 support

Off by one

Questa volta i media nostrani ne hanno parlato poco, forse perché il logo di poodlebleed è meno affascinante di quello di heartbleed, anzi… è tutto sgranato, si vede che è una cosa fatta proprio alla buona.

In realtà SSLv3 è stato deprecato da una quindicina d’anni, quindi in teoria non dovrebbe avere un grosso impatto come vulnerabilità. Tuttavia sappiamo bene il mondo IT, tra un chi non fa non falla e un si ma se lo disabilito poi funziona? Meglio non rischiare, tutto è rimasto invariato per anni ed SSLv3 è ancora lì, configurato su alcuni web server in attesa di essere bucato.

Enjoy it!