RV: [HACK] Mas: inseguridad accesos externos a Intranets
J.A. Gutierrez
spd at gtc1.cps.unizar.es
Tue Feb 13 17:52:46 CET 2001
>
> Escribo a la lista porque supongo que el resto tambien estareis
> interesadas/interesados. Oye, Kamborio, porque dices que NT el password es
> mas dificil de romper con 7 que con 8 cars? Es la primera vez que oigo algo
> asi; si sabes de algun documento que lo documente, valga la redundancia, se
> te agradeceria.
OJO: Refrito de mensajes antiguos (que no salen en los archivos):
---------------------------------------------------------------------------
aviso, esto supongo que es conocido (de hecho, me suena haber
leido algo al respecto; aunque no preste mucha antencion)
La cosa son los 'hash' LM y NTLM que se guardan en el servidor
samba (cuando se usa encriptacion) en el fichero smbpasswd
(y lo mismo en un servidor NT).
Bueno, leyendo un poco la documentacion, es evidente; pero
como no me habia dado cuenta, me sorprendio bastante, mientras
hacia un programa para a~nadir entradas con comodidad al
private/smbpasswd, descubrir que para un mismo password se
genera siempre la misma cadena encriptada. (esto es, no existe
la 'sal' aleatoria de los ficheros passwd/shadow de unix)
Bien, en la documentacion de Samba ya dice (por otras razones,
en concreto que con muchos conocimientos se podrian usar estos
hashes para autentificarse sin necesidad de disponer del password
original) que el fichero private/smbpasswd hay que tratarlo como
si contuviera los passwords sin encriptar; pero aun asi sorprende
un poco que uno pueda coger un diccionario, generar todos los
hashes y luego con un simple grep encontrar passwords...
De hecho, me he hecho un nt-crack en media pagina de sh, que
con un volcado de hashes de NT real consigue unos resultados
aceptables...
Mas cosas curiosas que se observan tras encriptar de esta forma
un */dict/words:
- El hash LM se puede usar para acotar la longitud de password.
para todas las passwords de 7 o menos el hash lm acaba
en AAD3B435B51404EE
Esto juraria que si que lo he leido antes, ahora que lo
pienso, me parece recordar que lo que ocurre es que los
caracteres de 8 p'arriba se codifican independientemente en
la segunda mitad del hash...
en efecto:
54EFEFAB69696C074A3B108F3FA6CB6D:58E3BA06D49015C64476B18E77477B1C abhorred
4A3B108F3FA6CB6DAAD3B435B51404EE:9B75CF9A3FCC498E03EEDA4387BB5277 d
54EFEFAB69696C0718136FB05F77A0BF:F8CE0736AD35BA2BBB0A09E2982AED69 abhorrent
18136FB05F77A0BFAAD3B435B51404EE:AF7C003BB0917BC28E37F1785E2B9018 nt
lo que significa que si encontramos una coincidencia de
tan solo la mitad del hash ya tenemos 7 caracteres del password.
- El hash de LM se obtiene pasando todo a lowercase ->
Para hacer login en un servidor samba que use encriptacion,
cuela igual el password en mayusculas que en minusculas.
Supongo que falla la autentificacion NTLM y entonces prueba
la LM; como me suena que hace el NT pre SP4
La documentacion de samba habla del parametro "password level"
pero yo diria que eso solo afecta a cuando se usa solamente
el fichero de passwords de unix, no el smbpasswd.
Entre estas dos cosas, diria que si hacemos un diccionario
con solo caracteres en minusculas, numeros y simbolos; y ademas
para passwords de 1 a 7 caracteres (69 caracteres en total si
nos limitamos al ascii de 7 bits; lo que nos da un total de
aprox 7.5 millones de passwords, y un fichero encriptado de unos
53 Gb, probablemente comprimibles al 50% y a otro 50% menos si
no almacenamos el hash ntlm) podemos tener un crackeador
instantaneo de passwords.
En fin, que todo esto no es nuevo (si acaso, lo de que el
samba con encriptacion trague passwords en cualquier 'CaSe',
no me suena haberlo visto comentar, y tambien me ha sorprendido),
pero no esta de mas recordarlo...
---------------------------------------------------------------------------
Todos los unix usan passwords de max 8 caracteres, con la
posible excepcion de algunos raros configurados para usar
algoritmos basados en md4 o md5 (me suena, p.e. S/Key,
alguna variante rara de BSD, algunas configuraciones de
DGUX y recientemente algunas distribuciones de Linux).
Es decir; que como otro indicaba por ahi, mas caracteres
no necesariamente implica password mas seguro. NT p.e.,
admite passwords mas largos, pero recuerdo haber leido
que passwords de mas de 8 caracteres en NT eran, de hecho,
mas faciles de crackear que los de menos.
Por otra parte, segun algunos, si que se deberia extender
el maximo num. de caracteres. Probablemente usando PAM o
algun tipo de parche de libcrypt se podria hacer eso en linux.
referencias:
* crypt(3c) (Solaris 2.x)
The key argument points to a string to be encoded (for exam-
ple, the user's password.) Only the first eight characters
are used; the rest are ignored.
* bigcrypt(3C) (HP-UX 11)
bigcrypt() acts like crypt(3C), but handles much larger strings.
bigcrypt takes the segments of cleartext and encrypts them
individually, at first using the salt passed in, and then using the
first two characters of the previous encrypted segment as the salt for
the next segment. This avoids duplicated ciphertext chunks when the
password characters are repeated, so that the encryption of a segment
involves the encryption of all the previous segments.
Each chipertext segment is concatenated, with the salt at the
beginning, to form the entire encrypted string.
(por mi experiencia, la gente que usa passwords largos en
HP-UX se pasa de los 8 caracteres en dos o tres, y estos
dos o tres se los cepilla el crack en nada. a veces de esa
terminacion se puede deducir la primera parte)
* http://hub.org/softdocs/FreeBSD-handbook/handbook56.html
6.1.1. Recognizing your `crypt' mechanism
It is fairly easy to recognize whether a particular password string was
created using the DES- or MD5-based hash function. MD5 password strings
always begin with the characters `$1$'. DES password strings do not have
any particular identifying characteristics, but they are shorter than
MD5 passwords, and are coded in a 64-character alphabet which does not
include the `$' character, so a relatively short string which doesn't
begin with a dollar sign is very likely a DES password.
* http://www.tartumaa.ee/doc/HOWTO/Shadow-Password-HOWTO
Additionally, the Shadow Suite adds lots of other nice features:
[...]
· Double length passwords (16 character passwords) NOT RECOMMENDED
[...]
Most Shadow Suites contain code for doubling the length of the
password to 16 characters. Experts in des recommend against this, as
the encoding is simply applied first to the left half and then to the
right half of the longer password. Because of the way crypt works,
this may make for a less secure encoded password then if double length
passwords were not used in the first place. Additionally, it is less
likely that a user will be able to remember a 16 character password.
* http://bart.aero.psu.edu/~anirudh/Docs/FAQ/unix_programming_FAQ.html
4.2.3 How do I verify a user's password?
----------------------------------------
The fundamental problem here is, that various authentication systems exist,
and passwords aren't always what they seem. Also with the traditional one
way encryption method used by most UNIX flavours (out of the box), the
encryption algorithm may differ, some systems use a one way DES encryption,
others like the international release of FreeBSD use MD5.
* Thread "passwd hashing algorithm" en http://www.geek-girl.com/bugtraq/
[mu largo...]
---------------------------------------------------------------------------
--
finger spd at gtc1.cps.unizar.es for PGP / So be easy and free
.mailcap tip of the day: / when you're drinking with me
application/ms-tnef; cat '%s' > /dev/null / I'm a man you don't meet every day
text/x-vcard; cat '%s' > /dev/null / (the pogues)
More information about the hacking
mailing list