sábado, 12 de abril de 2014

heartbleed





Cuando al que te ataca sólo le interesa obtener resultados sin entender nada, se lo llama "script kiddie". Es una subcategoría despreciada por los hackers, tanto white hat como black hat ("buenos" y "malos")[1].



Se qué estamos todos apurados y que sólo nos interesa arreglar el problema sin entender nada, pero yo no soy nadie para juzgar, así que primero voy a dar las recetas y luego podés elegir dejar de leer.

Si sos un usuario final, el ataque pudo haber obtenido tus contraseñas en algunos sitios como:

  • facebook
  • instagram
  • pinterest
  • tumblr
  • twitter
  • google (incluyendo gmail)
  • yahoo (incluyendo yahoo mail)
  • dropbox
  • minecraft
  • netflix


Al final de la entrada hay un link a una lista. Quizás sea menos trabajo simplemente cambiar todas las contraseñas, algo que de todos modos es una buena práctica hacer periódicamente.

Si sos webmaster, desarrollador, TI, podés seguir el siguiente procedimiento:

  1. hay encriptación?
  2. la provee openssl?
  3. con version 1.0.1?
  4. tiene activado heartbeat?
  5. ejecutar algún script de comprobación web o cli
  6. actualizar openssl
  7. reiniciar los servidores que utilizan openssl
Si el paso 5 dió positivo, hay que renovar los certificados (gracias JP por el ojo atento).

Si no tenés ganas de pensar, comenzá directo en 5). Si evaluás que lo vas a corregir inmediatemente, podés usar las herramientas web. Si realmente no tenés ganas de pensar, elegí según tu distro y reiniciá a la windows:

  • apt-get update && apt-get upgrade ; # debian y derivados (ubuntu, mint)
  • yum update ; # red hat y derivados (fedora, centos)
  • zypper update ; # suse


Si compilaste por tu cuenta es que tenés ganas de pensar y no necesitás que te diga que tenés que obtener la versión actualizada de OpenSSL, recompilar lo que haga falta y reiniciar lo que haga falta.

¿Por qué prefiero las herramientas cli? Mera desconfianza, aunque estoy casi seguro de que confiar sería seguro, ¿cómo  podés saber que tu consulta no es utilizada para armar una base de datos de sitios vulnerables?


Con mayor profundidad...

He intentado hacer bloques con títulos que reflejen la complejidad y a quién está dirigido.

Descripción de la vulnerabilidad


OpenSSL es una librería criptográfica muy utilizada para encriptar las comunicaciones. Encriptar las comunicaciones significa hacerles un proceso mediante el cual los que no participan no pueden entenderlas. Esto no quita que quienes esten afuera no puedan saber quienes se comunican (anonimato) ni que no puedan hacer un análisis de tráfico.

Estar dentro de la comunicación significa tener la clave con la cual se encripta y desencripta la comunicación. Esta clave es distinta de la que se usa para que uno se autentique, la que la persona escribe. Hay otra clave más que tiene que ver con el establecimiento de la comunicación y que es muy especial, pues son dos claves, una pública y otra privada. Como la clave pública es pública ya la tenemos, nos interesaría obtener la privada. Con ella, podríamos obtener la clave con la que se encripta y desencripta la comunicación (que es distinta para cada comunicación) y de ahí la clave de la autenticación del usuario, por ejemplo al home banking. Esto no se limita a la comunicación actual si no a cualquiera que pueda haber sido capturada en el pasado.

La clave privada tambien es interesante pues nos permite meternos en el medio o incluso hacernos pasar por un sitio de modo indetectable.

Apache y Nginx son servidores web que usan OpenSSL pero no hay que excluir cualquier otro servicio como mysql, postgres, postfix, imap, pop3 que pueda estar usando criptografía en las comunicaciones.

Heartbeat[2] es una extensión a los protocolos TLS y DTLS para mantener una conexión y evitar tener que estar reconectando. La idea es que establecer una conexión segura implica bastante trabajo e intercambio de mensajes para los participantes. Con esta extensión se puede mantener abierta la comunicación sin que haya tráfico permantente.

En los mensajes de Heartbeat, hay una parte que tiene longitud variable y la vulnerabilidad de OpenSSL en las versiones afectadas consiste en no controlar que la longitud declarada corresponda con la real. Esto permite producir un error en la librería y obtener un volcado de partes de la memoria de trabajo. En ese volcado pueden haber partes de los mensajes con cookies de sesión o la clave de encriptación, ambas con valor efímero, pares user/password o lo mejorcito que son las claves privadas utilizadas por la aplicación.

Hay una ilustración bien gráfica en http://xkcd.com/1354/ (gracias Gloria B.)

Ahora, ya estás en condiciones de entender Heartbeat -> HeartBleed

El alcance como usuario final


Como usuario final nos interesa saber si nuestras credenciales han sido comprometidas. Eso es una ruleta y hay alguna probabilidad si tras haberse uno autenticado ha habido un ataque.

Menos ruleta es que si hubo un ataque mientras uno estuvo comunicándose, nuestros mensajes pudieron haber sido vistos. Pero a la vez es menos riesgoso, pues es muy difícil rearmar una comunicación probablemente incompleta.

Si la clave privada ha sido comprometida y el atacante tiene la capacidad de ver todo el tráfico, listo, perdiste tus claves y toda la privacidad con respecto a esa aplicación o servicio. Si no tiene esa capacidad pero te está atacando a tí, puede hacerte MITM, pero, ¿quién se tomaría tanto trabajo en atacarte?

Con respecto a las listas que hay de servicios vulnerables, es importante tener en cuenta que la vulnerabilidad existe desde hace dos años y que puede haber evidencia de explotación desde noviembre del 2013[3], asi que las listas representan el estado en un momento determinado, algunos de los sitios que ahora figuran ok pudieron haber estado vulnerables en algún momento.

ACTUALIZACIÓN: a las seis horas que pasaron desde que publiqué esto, ya apareció algo nuevo[4].

Un caso extremo es yahoo y lo sé por que me fijé si era vulnerable y me dió que sí, a la media hora quise corroborar y ya estaba corregido.

El alcance como proveedor, web master, desarrollador


Como proveedor, en fulldisclosure hay un muy buen consejo: "As a general rule of thumb for this vulnerability, any binary/service dynamically linked to libssl.so should be considered compromised"[5], que yo lo extendería a compilado estático y a cualquier script que haya usado la versión vulnerable.


Para saber qué openssl hay, lo mejor es preguntarle:

$> openssl version

Para saber quienes usan openssl enRed Hat/SuSE y derivados (Fedora, Centos), tendría que haber algo sencillito pero no lo pude hallar, así que hice esto:

rpm -qa | while read package ; do
    rpm -q $package --requires | grep ssl > /dev/null
    if [ $? -eq 0 ]; then
        echo == $package ==
        rpm -q $package --requires | grep ssl
         echo
    fi
done


(puede ser que esté mal, lo hice en un SuSE y ahora no tengo donde probarlo, quizás el grep sea openssl o libssl en lugar de ssl)



Con respecto a Debian y derivados (Ubuntu, Mint), es parecido pero peor y no lo he podido hacer andar. Si alguien tiene la gentileza de enviarlo, lo pondré. Se parece a:


# NO FUNCIONA
dpkg --get-selections | \
sed -e "s/[ \t]\+/ /g" | \
cut -d" " -f 1 | while read package; do
    apt-cache showpkg $package | grep ssl > /dev/null
    if [ $? -eq 0 ]; then
        echo == $package ==
        apt-cache showpkg $package | grep ssl
        echo
    fi
done

#NO FUNCIONA



Un problema que ocurre es que el ataque a nivel aplicación es indetectable. No aparece en el log de la aplicación. Podría aparecer en logs de firewalls, pero no sé cual es la retención habitual.

Consecuencias para proveedores, web masters, desarroladores.


Si la vulnerabilidad fue introducida a propósito, el que lo hizo dice que no[6], o fue descubierta al poco tiempo, hay que renovar todos los certificados de cualquier sitio que haya sido vulnerable. Esto es algo que se irá determinando en los próximos días a medida que se exploren los logs.
Alguien podría decirme (y lo ha hecho) que las agencias gubernamentales seguramente tengan copias de todos las claves privadas importantes y ¿qué le podría decir? Es desalentador, pero sigamos jugando como si no fuera así.

Hay un aspecto que sólo he leido mencionado superficialmente al pasar en un solo lugar y aún no le han prestado suficiente atención por que todo el mundo está corriendo detrás de los servidores, que es que la vulnerabilidad no es de los servidores, es de la librería. Esto implica que si el navegador o aplicación que uno usa se conecta a un sitio malicioso, este podría obtener volcados tambien. El verificador ssl de cliente que uso (aún) no verifica[7] o al menos nada dice.
Pero a medida que pasan las horas, hay nuevas noticias [8]

Aprendizaje para quienes saben programar


Como es costumbre, vamos a aprender algo de este desastre.

El objetivo del ejercicio es capturar un poco de tráfico de un sitio vulnerable y luego desencriptarlo.

Primero hay que hallar un sitio vulnerable y capturar un poco de tráfico, por ejemplo con wireshark. Se puede usar el siguiente filtro:

"tcp.port eq 443 and  ip.dst eq XX.XX.XX.XX"

Luego, no a la vez pues si no capturaremos el tráfico del ataque que no nos interesa, ejecutar alguno de los scripts que circulan por ahí, por ejemplo hb-test.py, que no sólo te dice si el sitio es vulnerable sino que hace el ataque y el vuelco de memoria en formato hexdump, al que luego hay que convertir en binario. Tambien se puede utilizar un script que salve en formato binario directamente o modificar hb-test.py.


De un modo u otro, hay que detectar que suite criptográfica se usa, como por ejemplo donde dice SSL-Session: -> Cipher tras ejecutar

openssl s_client -connect domain:port


y elegir la herramienta apropiada para extraer la clave. La idea es que las claves presentan un cierto patrón detectable.

Con una menor ambición, con el comando strings y grep se pueden obtener claves de la aplicación.

Mi experiencia fue obtener ~30k muestras y usé estos scripts para obtener el binario a partir de la salida de hb-test.py





[hex2bin.sh]
for file in dumps/*; do
  fn=$(basename $file .dump)
  ./hex2bin.py < $file > buffers/${fn}.hex
done


[hex2bin.py]
#!/usr/bin/python2
import fileinput
import sys
def translate(line):
  line = line[6:54]
  for i in xrange(0,48,3):
    sys.stdout.write(line[i:i+2].decode('hex'))
state = "seeking"
for line in fileinput.input():
  line = line.strip()
  if state=="seeking" and line=="Received heartbeat response:":
    state = "translating"
  elif state == "translating":
    if line == "" :
      break
    else:
      translate(line)

Luego, ejecuté

for file in buffers/*; do aeskeyfind $file; done > aeskeys.txt 2>&1 

y como no salió nada y tanto no sé:

for file in buffers/*; do rsakeyfind $file; done > rcakeys.txt 2>&1

Las búsquedas con string y grep tampoco fueron provechosas, pero era de esperar, ya que el sitio carece de autenticación.

Pude identificar que hay codeigniter, symfony, cosa que ya sabía pues mio es el sitio, quizás dos cookies de sesión, triste, quizás hagan falta más muestras o un sitio con otro tipo de tráfico.

ACTUALIZACIÓN: según un challenge que hubo[9], hacen falta muchas más muestras que las que tomé, así que es mejor hacerlo en una red local con un servidor dedicado y parece que que tomar las muestras cerca de un reinicio mejora las probabilidades, si es que no es indispensable.


ACLARACIÓN: he sido lo más cuidadoso posible, pero este no es un tema que domine particularmente y pude haber cometido algún error. En caso de ser así, por favor no dudés en señalarlo. Es más, hay un error pero lo voy a dejar como canario.

Recursos online

Listas, estadísticas y anuncios


  • http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/
  • http://googleonlinesecurity.blogspot.com.ar/2014/04/google-services-updated-to-address.html
  • http://news.netcraft.com/archives/2014/04/08/half-a-million-wid ely-trusted-websites-vulnerable-to-heartbleed-bug.html
  • https://github.com/musalbas/heartbleed-masstest/blob/master/top 10000.txt

Herramientas web


  • http://possible.lv/tools/hb/
  • https://github.com/FiloSottile/Heartbleed
  • https://www.ssllabs.com/ssltest
  • https://sslcheck.globalsign.com/en_US
  • https://lastpass.com/heartbleed/

Herramientas cli


  • https://gist.github.com/takeshixx/10107280
  • https://github.com/musalbas/heartbleed-masstest/blob/master/ssl test.py

Información general y análisis


  • http://heartbleed.com/
  • https://www.schneier.com/blog/archives/2014/04/heartbleed.html
  • http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

Referencias


  1. http://www.urbandictionary.com/define.php?term=script+kiddie
  2. https://tools.ietf.org/html/rfc6520 - Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension
  3. https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013
  4.  http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html
  5. http://seclists.org/fulldisclosure/2014/Apr/139
  6. http://www.smh.com.au/it-pro/security-it/man-who-introduced-serious-heartbleed-security-flaw-denies-he-inserted-it-deliberately-20140410-zqta1.html
  7. https://www.howsmyssl.com/
  8. http://www.bloomberg.com/news/2014-04-11/millions-of-android-devices-vulnerable-to-heartbleed-bug.html 
  9. http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge 

martes, 11 de febrero de 2014

Why lockpicking

What is the relationship between opening a lock and infosec? Why are you paying attention to that teenager activity? It is kind of an illegal kid's game!

Original spanish entry [0]

First answer


When you open a lock you can grab a device, open it and tamper with it or get keys stored in a drawer, access an unprotected terminal, sensible printed documention, install an usb keylogger, video splitter, network sniffer, take a backup tape, or, why not, steal a production disk. Not enough, too corporate.

Second answer


A key is an authentication factor [1][2], something I have.

The lock maker is in the same position as someone who implements an authentication algorithm. The one who installs the door, an authentication system.

Copying a key is like stealing passwords by means of shoulder surfing, keylogging or phishing.

You can ask a locksmith to copy them or take a photo or cast. Shoulder surfing is watching over someone else's shoulder while he is typing the password, keylogger is a program that captures every keystroke and send it to the attacker, phishing is asking someone to type his passwords in a fake web site under an attacker control.

To move the latch without moving the lock is like taking advantage of a crytographic system or web appliation design flaw, like CSRF or session fixation.

Can shim[3] of Devian Ollam is an example of the first, you use a can to open a padlock, like a credit card to open a door. To explain CSRF is not so easy, but it's kind of using the victim's session to make a transaction in a web application. Session fixation allows the attacker to get an authenticated session without getting the password.


Impressioning is the process of trying a blank key and filing where a mark appears until the lock opens and it is like a timing attack when you can recover a password from the variation of time in invalid login attemps.

I can not find a good comparisson for lifting. You open the lock pin by pin. It has some resemblance with a timing attack, but you open the door without getting the key.

Racking is brute lifting, like trying combinations, called brute force attack.With a combination padlock it is like trying every number. Racking is like a dictionary attack as it is trying common numbers in a combination padlock.

If a password is hashed and the attacker get it and find another password with the same hash value (it is called colission) it is like having a master key.

If someone has the same passwords in different accounts, if one of the sites get compromised, the attacker can attack all the accounts. It is like having the same key for all the doors.


Bumping is bumping the lock with an special key and it is like changing the execution flow of a program with a buffer overflow.

Vulnerabilities comparisson


avoids authentication mechanismsgot a copy of the key or the password
keyloggernoyes
shoulder surfingnoyes
phishingnoyes
csrfyesno
session fixationyesno
dictionarynoyes
brute forcenoyes
collisionin some wayin some way
buffer overflowyesno
timing attacknoyes
repetitionnoimplies that the first one has been captured
key copynoyes
can shimyesno
liftingnono (*)
impressioningnoyes
rackingnono
master keyin some wayin some way
social engineeringyesprobably
bumpingnono




Responsabilities and mitigations



responsiblemitigation
keyloggeruserdo not install malware
shoulder surfinguserget smart
phishinguserget smart
csrfprovidersecret toke
session fixationproviderdiscard session
dictionaryusercheck against dictionary
brute forcedestinystronger passwords(**)
collisionproviderimprove algorithm (***)
buffer overflowproviderdo not trust 0 as a string end
timing attackproviderfixed time comparissons
repetitionuseruse different keys and passwords
key copyuserdo not give key away
can shimproviderblock latch
liftingproviderimprove design (****)
impressioningproviderrounded pines
rackingproviderimprove design (****)
master keysharedasume risk
social engineeringuserget smart
bumpingprovidersprings with different strength

(*) I guess that someone with enough experience could imagine the key and build it.
(**) Stronger passwords mean longer with numbers, symbols, upper and lowercase characters.

(***) The attacker that does not know the algorithm, can not find colissions. The theory says that the algorithm is not secrect, but defense in depth say so.

(****) Includes using special pins, different strengh springs and a more contorted profile



Not enough, too academic.

Third answer

There is another answer related to mental state, attitude. The spirit of lockpicking is the same as the hacking spirit.

The feeling of opening a lock without the key is like hacking a system in a laboratory or ethical hacking, of course.

Disposable lockpicking at http://seguridad-agile.blogspot.com/2013/04/disposable-pick-tools-for-office.html

If you do not like my english, welcome aboard, please be kind.

[0] http://seguridad-agile.blogspot.com.ar/2013/09/por-que-lockpicking.html
[1] http://en.wikipedia.org/wiki/Multi-factor_authentication
[2] http://seguridad-agile.blogspot.com/2013/11/por-que-no-biometria.html
[3] http://deviating.net/lockpicking/media/can_shim.avi