Asshley Modison

(Nota del futuro 2020

En el marco de #quedateencasa me puse a revisar notas viejas no publicadas y no recuerdo bien por qué no lo había hecho con esta, así que el "Un poco tarde" de abajo, escrito en 2015, es más que apropiado)


Un poco tarde, noticia vieja, perdón por no estar en la cresta de la ola. Es que hacer esto me llevó un buen rato, tanto hacerlo en sí como hallarle un momento entre otras cosas.


Continuando con la decadencia de este blog, hoy miro un rato el dump de asshley modison. No avisés, ya sé que está mal escrito, lo que pasa es que no quiero aparecer en la primera página de ningún buscador, hay gente a la que le molesta que se haga leña del árbol caido.

Como de costumbre voy a repetir la recomendación de no repetir credenciales para evitar que al ser comprometido un sitio caigan todas tus cuentas en los otros sitios.

No voy a repetir la recomendación de vivir en el mundo real.

Como dice la publicidad, no uses el celular cuando estés conversando.


Como siempre, no uses los servicios online para verificar si estás en el dump, no tenés manera de saber si es buena gente o están recolectando mails para spam [adobe], si es de tu interés, busca el torrent y divertite.

Al grano

Complica el análisis que AM no verifique los mails.


En relación a la estafa que puede ser este sitio se menciona que en la proporción 30 a 5 de mujeres subscriptas declaradas, apuesto a que hay que ajustar a una inmensa cantidad de falsas cuentas femeninas.

En una nota [gizmodo] muestran como analizando el mail y la IP se descubren decenas de miles de cuentas falsas, pero no alcanzan para el 9 a 1 de la declaración de Impact Team[reddit]. Luego, analizando los campos mail_last_time, chat_last_time y reply_mail_last_time llega a que la relación es 1000 a 1.

Sin embargo, hay casos de mujeres que le avisan a la autora que si existen.

Para mi hay que analizar la fecha de alta del primer uso en relación a la fecha de not null de esos campos. Como desarrolladores bien sabemos que las bases de datos evolucionan y eso hace aparecer nules no significativos.

Lo mejor sería cargar en una base y hacer las consultas con sql, pero para qué tenemos grep si no lo usamos, ¿no?

tr "," "\n" < aminno_member_email.dump | grep "@" | grep -v " SET " | cut -d"@" -f 2 | sed -e "s/'//" > mails.txt

esto convierte cada coma en un salto de linea, toma cada linea con @ y quita cada linea con " SET ", parte cada linea en la arroba, toma el segundo campo, elimina la comilla y pone el resultado en mails.txt


Algunos números interesantes:



Hay una noticia cuyo título menciona a 150 argentinos [clarin]. En el cuerpo de la noticia dice que 148 y sólo de organismos .ar, pero a mi me da otra cosa...


grep -e "go[vb].ar'$" mails.txt  | sort | uniq | wc -l
144

quizas me faltan?

grep -e "mil.ar'$" mails.txt  | sort | uniq | wc -l
2


mmmh, la primera consulta sin el uniq me da

grep -e "go[vb].ar'$" mails.txt  | wc -l
156

¿Habrá sido esta la lista reportada tras borrar algunas direcciones?


No se puede confiar en las computadoras.


Los argentinos no importantes somos un poquito más, sin incluir gmail.com, yahoo.com y otros dominios que no son .ar:

grep -e ".ar'$" mails.txt  | sort | uniq | wc -l
69974


Me gustó un comentario en [reddit], aunque no representa mi visión:


I don't agree with your methods. Say we have 3 interested parties here. The company A..... M....., people cheating on their spouse (possibly hurting them) and people just looking for fun because sex is fun (not hurting anyone). I'm pretty sure you've hurt the most innocent people worst of all because now their names are on your list despite never hurting anyone. A.... M.... will move on. Cheaters will move on. You haven't really accomplished much of anything, besides maybe forcing me to explain to my girlfriend that I signed up before I met her.

(No estoy de acuerdo con vuestros métodos. Hay tres protagonistas aca. AM, los tramposos y los que se quieren divertir sin molestar. Han lastimado a los últimos pues AM va a seguir sus negocios, los tramposos seguirán trampeando y los que sólo nos queriamos divertir ahora tenemos que explicarle a nuestras novias que nuestra cuenta es anterior a ellas)





[boxeadores] http://seguridad-agile.blogspot.com/2015/07/boxeadores-en-la-cabina-de-un-avion.html


[adobe] http://seguridad-agile.blogspot.com/2013/11/leak-adobe.html

[clarin] http://www.clarin.com/sociedad/argentinos-escrachados-escandalo-Ashley-Madison_0_1415858680.html

[gizmodo] http://gizmodo.com/almost-none-of-the-women-in-the-ashley-madison-database-1725558944

[reddit] https://www.reddit.com/r/AnythingGoesNews/comments/3h71ar/we_are_the_impact_team_we_are_releasing_the/

Leak Adobe - english

Leak Adobe

During last month, some whitehats seized a rotten server full with juicy data from adobe like user source code, account and credit card information.

For the technical aspects there are some links below  [1], [2], [3] being [4] the best one. There is some weak analysis about impact [5] [6]. The best analysis consist of getting a copy of users.tar.gz and run some greps and wc.

Adobe reacted fine, there is no leak on the password recovery process and there is even a security alert on the landing page, a hard hit to marketing.

The fact that the users reuse passwords among accounts it's not adobe fault. But encrypting instead of hashing is another thing. This failure opens the door to statistical analysis and the use of the hint field to recover a pretty nice top 100 [7] and somebody says the recovered password list climbs to six millons.

When it started, they say 3 millons, then 38 millons active accounts. The fact is that the list comprises 130 millons of mail/encrypted password/hint.

An attacker can gain some insight in the victim's way of choosing passwords in the best case and using the very same password if the victim reuses it in the worst case.

The best thing to do now as an user is to stop repeating passwords, change them if you are repeating. There is no gain in using a check system like [8], as we already know that all the database is stolen.

If someone decrypts the password by brute force or because they got it with the rest of the leak, it will be the worst attack, ever.



[0] spanish version http://seguridad-agile.blogspot.com.ar/2013/11/leak-adobe.html

[1] http://7habitsofhighlyeffectivehackers.blogspot.com.ar/2013/11/can-someone-be-targeted-using-adobe.html

[2] http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

[3] http://www.hydraze.org/2013/10/some-information-on-adobe-135m-users-leak/

[4] http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

[5] http://www.welivesecurity.com/2013/11/05/tom-hanks-and-donald-trump-among-850000-victims-as-limo-firm-hack-leaks-addresses-and-amex-numbers/


[6] http://blogs.wsj.com/cio/2013/10/08/adobe-source-code-leak-is-bad-news-for-u-s-government/



[7] http://stricture-group.com/files/adobe-top100.txt

[8] http://adobe.cynic.al/

Leak Adobe

En el último mes, gracias a que unos white hats se apoderaron de un servidor comprometido que se estaba usando para almacenar información ilegal, salió a la luz un espectacular y exitoso ataque contra adobe, que paulatinamente involucra un número cada vez mayor de credenciales, datos de tarjetas de crédito y código fuente.

Con respecto a los aspectos técnicos, hay varios artículos [1], [2], [3] y el mejor que he hallado es [4], nada agregaré. Hay varios artículos medio flojos acerca de las organizaciones afectadas [5] [6] ; sólo diré que hay 2300 direcciones relacionadas a gov.ar o gob.ar y 11000 que son @banco.* o @bank.*. El mejor análisis es obtener users.tar.gz y correr los greps y wc necesarios.

Como siempre, lo que más me interesa es el asunto de como afecta al usuario.

Adobe, por su lado, ha reaccionado desde el punto de vista técnico del modo correcto que hay que copiar. Cuando te logueas, independientemente de que tengas la clave correcta o no, te manda un password reset via mail. Además puso en la landing page el alerta, duro para los de marketing.

Volviendo al usuario, no es culpa de adobe que se usen claves repetidas, no hay nada que hacer. Pero el encriptar en lugar de hashear provoca que se pueda ver cuales claves son repetidas, lo cual permite hacer un análisis estadístico al que se suma el que muchas personas ponen una ayuda para recordar la clave demasiado explícita cuando no la misma clave.

Esta situación nos lleva a tener un top 100 [7] y según dicen unos seis millones de claves recuperadas.

Al comienzo se decía 3 millones, luego que eran 38 millones de cuentas activas. Pero eso carece de importancia. Lo fundamental es que está hay 130 millones, si MILLONES de entradas tipo "mail/clave encriptada/ayuda recuperación". Aunque no sean cuentas activas nos está proveyendo una clave candidata para probar frente a 130 millones de personas.

¿Cuál es mi ventaja como atacante? Si estoy atacando a una organización o una persona, tengo ya algunos mails y algunos con contraseñas. Los que se han descubierto hasta ahora son los más fáciles y seguramente los usuarios cometen el mismo error en los demás sitios. Ponele que alguno puso "jupiter" en adobe. En yahoo pruebo "jupiter", "zeus", "saturno" y así. En adobe puso "adobe2012", en yahoo pruebo... "yahoo2012", "yahoo2013" y así.

Para saber si tu cuenta de adobe fue comprometida o si no recordás si tenés cuenta, lo mejor es ir directamente al sign in de adobe. Como siempre, evitá usar los servicios como [8] que te ofrecen hacerlo por vos. Mucho más en este caso, donde se puede considerar comprometida la base completa.

Si alguien logra encontrar la clave que se ha usado para encriptar las claves, si es que ya no fue hallada como parte del leak o por fuerza bruta, este pasa a ser el ataque más exitoso que haya habido.

Lo peor de todo es que parece que la base era o un backup o un sistema de backup, ya que el sistema actual, según dicen, está correctamente implementado.

Lo más importante es que si reutilizás claves, abandones tan mala costumbre y cambies en breve las que puedas repetido en adobe.

[0] english version http://seguridad-agile.blogspot.com/2013/11/leak-adobe-english.html

[1] http://7habitsofhighlyeffectivehackers.blogspot.com.ar/2013/11/can-someone-be-targeted-using-adobe.html

[2] http://www.zdnet.com/just-how-bad-are-the-top-100-passwords-from-the-adobe-hack-hint-think-really-really-bad-7000022782/

[3] http://www.hydraze.org/2013/10/some-information-on-adobe-135m-users-leak/

[4] http://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

[5] http://www.welivesecurity.com/2013/11/05/tom-hanks-and-donald-trump-among-850000-victims-as-limo-firm-hack-leaks-addresses-and-amex-numbers/


[6] http://blogs.wsj.com/cio/2013/10/08/adobe-source-code-leak-is-bad-news-for-u-s-government/



[7] http://stricture-group.com/files/adobe-top100.txt

[8] http://adobe.cynic.al/

Leak mortal

Hace años que las bases de datos de los sitios web son hackeadas y suponemos que gracias a la información obtenida, hay personas y empresas que pierden cuentas, valores en Internet, imagen, privacidad y dinero. Han habido leaks que quizás llevaron a que soldados, agentes encubiertos o informantes fueran apresados o muertos, pero son personas que actuan por convicción o dinero y al participar deberían aceptar o al menos conocer las reglas.

El último leak interesante fué contra la policía en Sudáfrica[1], donde se pueden ver las denuncias de víctimas e informes de delatores.


Supongo que ahora esperarás que haga la crítica habitual a los diseñadores, desarrolladores y administradores por no haber protegido el sitio de sqli, por no haber encriptado los datos. Bueno, ya está, ahí lo hice.

En esta ocasión me interesa más el punto de vista del que está en la lista.


Como se puede apreciar a ojo, dos de cada tres de las denuncias asociadas a palabras interesantes no tiene nombre, probablemente se trate de denuncias anónimas. ¿Y el tercio restante?

	total	con nombre
drugs	285	120
murder	252	173
kill	565	402
kidnap	32	25
gang	129	94
rape	216	151
total	15796	12501

El escenario que yo imagino es este: algún criminal que fué apresado por una denuncia pero no supo nunca quien lo denunció, la encuentra en el leak, con el nombre, teléfono, ciudad y mail del denunciante. ¿Sigo?

Reflexioná. Si sos informático, no seas el responsable de esto.

(actualización: de paso nos enteramos de quién ha sido víctima de violación y otras cosas que a la gente le encanta que difundan sin permiso)

Y no olvides que cada palabra que pongas acá en Internet, vivirá por siempre[2] y si no la usa algún criminal informático antes, irá a un data warehouse y el año que viene o dentro de diez años cuando cambie lo que es "políticamente correcto", será correlacionada con algún pecado y la vas a pagar.


[1] http://www.itweb.co.za/index.php?option=com_content&view=article&id=64268:SAPS-hack-spells-negligence&catid=265

[2] http://en.wikipedia.org/wiki/Big_data

more linkedin

He utilizado un diccionario de 53 millones y no he hallado ni una clave nueva, así que el diccionario del atacante original es más grande que el mio (probablemente) o me estoy equivocando en el proceso (probablemente) Para ejecutar todo esto es conveniente cerrar xwindows y abrir tres terminales. Para alivio sicológico se puede tener un top y un watch ls -l El problema de usar estos scripts sencillos y batching es que no se pueden aprovechar los multicores. Para la generación de los hashes, que es lo que hace hashes_and_pairs.rb tengo por ahi una solución con un cierto costo de setup, que no justifica ante los cinco minutos de unicore. Comencemos:  a partir de un diccionario, genera dos archivos, uno con cada hash y otro con el password y el hash	As I've used a 53 millon entries dictionary with no results, it seems that the original attacker has a bigger one (probably) or I am making a mistake (probably too) As this process is memory hungry, it's wise to close xwindows and work with three naked terminal. You can use top and watch ls -l to monitor the process These simple scripts do not make use of multicore capabilities. For the hash generation there is a setup that can help. First step: generate two files, one with hashes from our dictionary and the other with the hash and the password
ruby hashes_and_pairs.rb #(5 min) #!/usr/bin/ruby require "digest/sha1" dict="full_list_uniq.txt" input = File.new(dict, "r") hashes = File.new("dict_hashes.txt", "w") pairs = File.new("dict_pairs.txt","w") while (pass = input.gets)     pass = pass.chomp     hash = Digest::SHA1.hexdigest(pass || "")     hashes.puts "#{hash}"     pairs.puts "#{hash} #{pass}" end hashes.close pairs.close
Tomamos la lista de hashes de linkedin junto a la lista de hashes del diccionario y obtenemos los duplicados. Es vital que el diccionario original no tenga duplicados.	Find duplicates between the linkedin hashes and our hashes. It's very important that there are no duplicates in our hashes
cat remaining.txt dict_hashes.txt | sort | uniq -d > found_hashes.txt #(6 min)
Luego buscamos los hashes encontrados en found.txt dentro de dict_pairs.txt...	Search found hashes in our hash/password list
grep dict_pairs.txt -F -f found_hashes.txt > found_pairs.txt
No olvidar el -F, hace mucha diferencia Si found_hashes.txt fuera muy largo, se podria hacer	Don't forget the -F, it makes a big difference If the found list is too big, you can split it
split -l 10000 found_hashes.txt chunk_ for patterns in chunk_*; do     grep dict_pairs.txt -F -f $patterns >> found_pairs.txt done
Como ya habia mencionado, no he conseguido ningún resultado nuevo.	As I've said before, there were no results

Leak Linkedin English

Download the dump file from http://bit.ly/KGTusG and execute the code below, based upon https://gist.github.com/2884354, with a second test to find unknown hashes.

It seems that linkedin does not salt the stored password, allowing dictionary and rainbow table attacks.

The file has 6.5 million hashes, with a half of them "tagged" with 000000 at the beginning. If you try common passwords they are found.

The author original logic is to verify hashing the password and replacing the first six chars with 0. I've added looking for untagged hashes too.

Asi que, a ejecutar y cambiar el password si hace falta.
Please add a comment below if you find your linkedin password and if its not used in any other account, the better. If is does not reveal anything about your password schema, please write it down too.


"""
Check if your password is in the linkedin password dump.
You'll need to download the dump from here: http://bit.ly/KGTusG and unzip it to combo_not.txt
"""

import hashlib
import getpass

pw = getpass.getpass('Enter your LinkedIn password: ')
sha1 = hashlib.sha1(pw).hexdigest()
hash = '00000' + sha1[5:]

found = False
with open('combo_not.txt') as f:
    for i, line in enumerate(f):
        h = line.strip()
        if hash == h:
            print "Found it decrypted on line %d" % i
            found = True
        if sha1 == h:
            print "Found it but encrypted on line %d" % i
if not found:
    print "password %s not found" % (pw)


Here there is an analysis:

http://cyberarms.wordpress.com/2012/06/07/analysis-of-passwords-dumped-from-linkedin/

Leak linkedin

Sabiendo que hay muchas personas ágiles con linkedin, pienso que amerita dedicarle un ratito. Sólo hay que bajar el dump de http://bit.ly/KGTusG y ejecutar el programa, que he sacado de https://gist.github.com/2884354, pero agregándole el segundo if, para verificar si está el password de uno está pero no habia sido aun descifrado.


Parece que linkedin no usa salts en sus passwords, lo cual facilita enormemente hacer ataques de diccionario y rainbow tables.

El archivo consiste en 6.5 millones de hashes, de los cuales más de la mitad tienen reemplazados los primeros caracteres por 000000. Si se prueba con los passwords comunes, se hallan, lo cual suguiere que quien perdió este archivo ya rompió esos hashes.

La prueba del autor original es verificar si el password de uno ha sido descifrado o no. Es altamente probable que si lo encuentra, sea, pero tambien puede ser una colisión producida por los ceros, difícil, muy difícil.

La prueba que agrego es por si el password de uno es bueno y no ha sido roto, está en la lista, esperando a ser roto por alguien con más tiempo.

Asi que, a ejecutar y cambiar el password si hace falta.

Agradeceré que cualquiera que encuentre su password en la lista deje un comentario, sobre todo si es detectado por la segunda prueba. Tambien mencionar si es un password que es sólo de linkedin.


En caso de que sea un password que sea compartible, por favor dejarlo tambien, asi puedo verificar si la prueba es correcta. Mientras voy a correr mis crackers, a ver si encuentro algo.

Con "compartible" me refiero a que no tenga relación con otros passwords.


"""
Check if your password is in the linkedin password dump.
You'll need to download the dump from here: http://bit.ly/KGTusG and unzip it to combo_not.txt
"""

import hashlib
import getpass

pw = getpass.getpass('Enter your LinkedIn password: ')
sha1 = hashlib.sha1(pw).hexdigest()
hash = '00000' + sha1[5:]

found = False
with open('combo_not.txt') as f:
    for i, line in enumerate(f):
        h = line.strip()
        if hash == h:
            print "Found it decrypted on line %d" % i
            found = True
        if sha1 == h:
            print "Found it but encrypted on line %d" % i
if not found:
    print "password %s not found" % (pw)


Además acá hay un lindo análisis:

http://cyberarms.wordpress.com/2012/06/07/analysis-of-passwords-dumped-from-linkedin/