19-09-2011, 13:40
Buenos días,
Estoy intentando sacar mi usuario y contraseña a traves del software cain & abel y no puedo, me lo saca con números. Puede hacerse con este programa?o es mejor con otros?. Queria probar si hay algun programa que intalandolo en mi equipo me saque el usuario y contraseña que meto por ejemplo al entrar en hotmail en el mismo equipo, se puede?cómo puedo hacerlo
Muchas gracias y saludos a todos ls foreros
¿Tu usuario y contraseña de qué? ¿No te conviene más un keylogger si son servicios web?
Antes de contestar... por curiosidad, ¿para qué quieres sacar tu propia clave?
Un saludo.
Mirando la cabezera http, no digo mas.............
Incluso si va por SSL?...Mirando la cabezera http, no digo mas.............
Hay otros métodos, pero primero quiero saber cual es el objetivo de obtener "tu propias" credenciales.
Sabes que acabo de mirar la cabezera post de login en este foro y la contraseña esta encriptada en md5 jeeje, en msn no se como ira, ya sabes qe a mi no me gusta meterme en la vida privada de las personas.
Me gusta mucho la informatica y estoy probando, haciendo cosas. Y ver si me saca el usuario y la clave, y ver si la cambio y y pongo una alfanumerica si la sacaría, o si pongo otra con más caracteres. Vamos que es por ir haciendo pruebas y ver la seguridad y ese tipo de cosas.
Y si se puede con el cain por saber como, o si es con otro tipo de programa verlo y conocerlo.
Gracias, un saludo.
Antes de nada de lo que mecionas, aprende algo sobre protocolos http y como se conpone su cabezera, ademas de ssl y sus metodos de encriptacion. También, se podría hacer más facilmente creando un keylogger...
Si, lo del keylogger está muy bien, siempre y cuando no te lo detecte un antivirus claro... jejeje, pero como solución es totalmente válida. Pero creo que pasaca está más interesado en saber la seguridad de hotmail, más que en la seguridad del sistema operativo de su equipo, o por lo menos esa es mi impresión.
Las cabeceras http también es buena solución, pero sólo en casos en los que la información no vaya codificada, por ejemplo mediante el propio protocolo https, y sólo tendría sentido si se hace desde la misma máquina o mediante un MITM (Man In The Middle), lo cual implica también hacer sniffing a la red, y vuelvo a decir, sólo es aplicable si la información no está cifrada.
Una aplicación web es segura cuando no logra encontrarse un método para robar la sesión (session poisoning). Y no encontrar dicho método no demuestra que sea invulnerable...
Hay muchos factores a tener en cuenta, desde una buena administración del hosting en donde se ejecuta la aplicación, hasta la propia aplicación. Así por ejemplo en hosting compartidos (shared hostings), los datos de sesión son almacenados en recursos compartidos por otras aplicaciones, por lo que el desarrollador ha de tener en cuenta este factor y "securizar" su aplicación ante esta "advertencia" y hacerlo durante el análisis de requisitos... es decir, "SEGURIDAD DESDE EL PRINCIPIO", y no al final como suele pasar.
Para aplicaciones corporativas y de grandes empresas, como el caso de hotmail, es poco probable que se alojen en hostings compartidos, por lo que los vectores de ataque suelen enfocarse a la propia aplicación (desde fuerza bruta hasta un SQL injection o XSS entre los más populares).
Otra cuestión a la hora de ver "cuánto de segura" es la aplicación es comprobar cuánto de resistente es ante el phishing, ya que si alguien logra emular la aplicación, puede engañar a los usuarios y con técnicas tan simples como enviar un simple email a la víctima, a nombre "hotmail" indicando que tienes nuevos mensajes sin leer, e insertando un enlace titulado "inciar sesion" el cual te redirige a la aplicación del atacante totalmente idéntica, alojada por ejemplo en el dominio "hotmial.com", sólo habría que esperar a que el usuario introdujera sus credenciales y listo, o hasta técnicas como el tabnabbing o los payloads...
Un saludo.
A que te refieres con lo de recursos compartidos, algun ejemplito jiji.Hay muchos factores a tener en cuenta, desde una buena administración del hosting en donde se ejecuta la aplicación, hasta la propia aplicación. Así por ejemplo en hosting compartidos (shared hostings), los datos de sesión son almacenados en recursos compartidos por otras aplicaciones, por lo que el desarrollador ha de tener en cuenta este factor y "securizar" su aplicación ante esta "advertencia" y hacerlo durante el análisis de requisitos... es decir, "SEGURIDAD DESDE EL PRINCIPIO", y no al final como suele pasar.
Corrigeme si me equivoco pero creo que los crypters, todabia siguen siendo utiles, tambien si el antivirus no es muy bueno (su heuristica), igual tienes suerte y al crear tu propio algoritmo cuela jeje.siempre y cuando no te lo detecte un antivirus claro... jejeje
PD: perdon por el doble comentario, que estoy cansado de tanto dar clases xd.
Aquí te lo explican muy bien... http://phpsec.org/projects/guide/5.html.A que te refieres con lo de recursos compartidos, algun ejemplito jiji.
En concreto donde dice:
One particularly vulnerable aspect of shared hosting is having a shared session store. By default, PHP stores session data in /tmp, and this is true for everyone. You will find that most people stick with the default behavior for many things, and sessions are no exception. Luckily, not just anyone can read session files, because they are only readable by the web server
Exacto!, los "crypters" o "ciphers", compresores, empaquetadores, y demás, de ficheros binarios o ejecutables son una tarea dura para los antivirus...Corrigeme si me equivoco pero creo que los crypters, todabia siguen siendo utiles, tambien si el antivirus no es muy bueno (su heuristica), igual tienes suerte y al crear tu propio algoritmo cuela jeje.
Aunque aquí entra un concepto dual: programa y proceso.
Programa: código que se puede ejecutar, pero que aún no se ha cargado en la memoria principal (RAM).
Proceso: código que YA está ejecutándose, y que se encuentra en memoria RAM.
Cuando tú codificas o encriptas con tu cipher, empaquetador o compresor tu aplicación, lo que encriptas es el PROGRAMA. Cuando ejecutas el programa, tu sistema operativo lo carga en la RAM y se convierte en PROCESO.
La diferencia está en que el proceso no está codificado, ya que si lo estuviera, el procesador ejecutaría instrucciones incoherentes... esto es lo que ocurre por ejemplo cuando intentas debuggear tu PROGRAMA con tu Debugger favorito (OllyDBG, SoftIce, etc...). El proceso de descompresión lo lleva a cabo el sistema operativo, leyendo la cabecera del ejecutable (PE para archivos EXE de Windows por ejemplo).
Un antivirus "malo" sólo escanea PROGRAMAS, es decir, ficheros ejecutables, mientras que un antivirus "bueno" debería escanear además los PROCESOS en la RAM. Si encuentra alguna firma, algún patrón de instrucciones, o una combinación de llamadas a funciones "sospechosas" en memoria, salta la alarma (que salte no quiere decir que se trate de un malware). Toda esta información además la tiene almacenada en su base de datos, y aquí es donde está la competencia entre antivirus.
Para que un PROCESO pase desapercibido ante un antivirus, debe utilizar además de la encriptación del PROGRAMA, técnicas más "macabras", como lo es el polimorfismo, es decir, que el proceso vaya cambiando su código a medida que se ejecutan instrucciones de su propio código (en la ezine hay un artículo que trata este tema, por si te interesa).
Y un sin fín de cretividad... como cargar el proceso por partes, o utilizar técnicas de download (los llamados downloaders).
Un saludo.
Que bien explicado, da gusto leer asi.
Exacto hystd, y Microsoft Security Essentials analiza programas y procesos
P.D.:Microsoft me paga para que haga publicidad
Que yo sepa todos hacen eso, lo que no sé es cómo se meten a leer en la memoria de otro proceso, seguramente HySTD me lo pueda decir.
Todos no, hay algunos que ya les vale... y es tan fácil como llamar a ReadProcessMemory();
En la ezine se habla sobre este asunto... y con un ejemplo sencillo de cómo no sólo leer, sino inyectar código externo dentro de cualquier proceso, teniendo en cuenta la protección de segmentos de memoria de Win.
Un saludo.
Esto supone que el proceso leído debe permitirlo ¿no?
La restricción en Windows se basa en los dos modos de ejecución en anillos que posee (usuario y kernel). Cualquier proceso de usuario puede acceder al espacio de memoria (código, datos y pila) de cualquier otro proceso en modo usuario.
Si un proceso de usuario intenta leer un proceso del kernel, no podrá. Sólo sería posible desarrollando un driver.
Un saludo.
Última edición por hystd; 22-09-2011 a las 15:46
Lo del kernel lo daba por sentado, pero pensaba que un proceso no podía meterse a leer en la memoria de otro así porque sí, me parece un problema de seguridad.
Si... Aunque un proceso de usuario por defecto tiene el bit de escritura de cada página de su espacio de memoria desactivado para que sólo sea de lectura. Pero igualmente, haciendo uso de VirtualProtectEx(), puedes cambiar este bit de control y ala, a escribir.
Es decir, que por defecto, los procesos en Win están "protegidos" contra escritura, por si otro proceso, "erróneamente", por ejemplo, debido a una excepción o un puntero mál referenciado, intenta escribir pues no "tire" o manipule a otro. Pero si el proceso en vez de por error, lo quiere hacer intencionadamente, sólo tiene que activar el bit de escritura para la página del proceso que quiere "manipular", y listo.
Un saludo.
Marcadores