Wireshark sobre http, encriptación

[loureed4]

Buenos días

Me gustaría haceros una pregunta porque estoy estudiando unos temas de auditoría informática, de seguridad informática:

Me acabo de logar en una web , el caso es que es http y no thttps , pero Wireshark no coge la contraseña, y me dice esto:

user= Imaginario1975 & passwrd=&cookiele​ngth=10080&hash_passwrd=92f066​3 14233f740a5856hyhj7ujkydcffbe​ac346bb5 .

En Wireshark veo claramente que el destino es el puerto 80, con lo que no hay https (http con SSL 443) , sino que la encriptación de la contraseña se ha hecho a otro nivel. El nombre de usuario no se ha encriptado, pero el campo "hash_passwrd" me hace pensar que se ha aplicado un hash sobre la contraseña, sin hacer falta https, ¿esto es posible? . Me ha parecido interesante la medida de seguridad que han puesto, no sé si es muy robustat y esa contraseña o hash es ya conocido, PORQUE SI TENGO EL HASH PODRÍA APLICAR PWDUMP O ALGÚN SOFTWARE PARECIDO ?

Lo que quiero decir con esto es que en las intranet o extranet que yo tengo, aplico https para aportar encriptación SSL, pero esta web en la que me he logado, quería ver si Wireshark cogería mi contraseña, y esperaba que si, pero para mi sorpresa me he encontrado con encriptación a otro nivel.

[moeb]

¿Como?

¿Como y cuando genera ese "hash"?

Es decir... Si tú tienes que escribir tu password en una página tienes que enviar ese password o preprocesarlo si no lo envías (es decir, el hash no se genera en servidor dado que debes enviar el password para que se genere ese hash).

Si tienes que preprocesarlo, ese preprocesado se realiza en tu ordenador... Ya sea mediante javascript, o un applet java, o action script...

Si se trata de javascript, tendrás el código fuente que genera el hash (el algoritmo de la función hash) en tu equipo (muy mala idea).

Programas como pwdump intentan sacar los passwords a partir de hashes contenidos en la SAM (son hashes generados por el sistema windows para mantener las passwords de sistema encriptadas en la SAM)... Por eso pwdump NO VALE para cualquier tipo de función hash. Tendrías que saber el algoritmo utilizado para obtener el hash si quieres saber de que forma uedes atacar ese hash. Por eso es mala idea tener el algoritmo en los PCs de los clientes (sobre todo si es en javascript)...

Sigo pensando que SSL es mejor opción. Sin un keylogger, y si eres precavido para no caer en un MitM, tu password estará bastante seguro. Aunque... siempre podrán capturar tu sesión una vez autenticado, claro.

[loureed4]

Hola, muchas gracias por responder.

Pwdump y OphCrack, hasta donde sé, son para romper hashes LM (muy débiles dicen), NTLM, y NTLMv2 (Windows 7 y 2008 llevan éste según he leido).

Yo quería decir si existía algún programa que pasándole el hash pueda indicarte si es MD5, LM, etc, esstoy googleando para ver si existe tal posibilidad, ya que el hash lo tengo (es mi propia contrasñea, así que tendría ambas cosas, contraseña y hash) .

Miraré si hay Javasript en el código fuente.

Lo de Man in the middle, sé algo y sé que por ejemplo Cain te lanza un falso certificado si te quieres logar en páginas https para así capturar tus credenciales, por lo que ya sé que eso es un mitm . También creo que te cambia las tablas ARP para hacerte ARP Spoofing, pero aquí la contramedida o cómo averiguar si estoy en un mitm no la conozco. También sé que hay dns spoofing, osea, te mando a un facebook falso, o a un banco falso, que tengo en mi servidor web como atacante, y te saco una página de error, luego entras ya en la verdadera , ya tengo las credenciales y él creerá que se equivocó al teclear. He estudiado algunas cosas al respecto aunque quiero implementar Snort para este tipo de cosas.

También he leido sobre poner entras ARP estáticas , por ejemplo la MAC del router, para evitar que alguien lo suplante (spoofing al fin y al cabo es suplamntación de identidad). No sé si esta es buena medida, o insuficiente, y por otro lado no sé cómo implementarla en una red de 80 equipos.....¿un script de inicio de sesión en Active Directory para esa entrad estática de ARP?

Muchas gracias por tu rápida respuesta !

[moeb]

También he leido sobre poner entras ARP estáticas , por ejemplo la MAC del router, para evitar que alguien lo suplante (spoofing al fin y al cabo es suplamntación de identidad). No sé si esta es buena medida, o insuficiente, y por otro lado no sé cómo implementarla en una red de 80 equipos.....¿un script de inicio de sesión en Active Directory para esa entrad estática de ARP?

Sí. No es una mala medida. Con eso evitas un ARP spoofing en los PCs, que llevaría a un MitM. Lo que no puedes evitar es un arp spoofing sobre el mismo router (con lo que, al menos las respuestas, si podrían capturarlas)... Salvo que tu gateway tambien admita entradas arp estáticas (y quieras meter 80 en él).

Tambien, muchos cortafuegos personales son capaces de detectar tormentas ARP, habituales en los arp spoofing.

Y... No. No conozco ningún programa que te diga de que tipo de hash se trata. ¿Por qué? Pues porque una función hash da como resultado una cadena de caracteres (habitualmente)... Saber que función ha generado una cadena concreta no es posible. Puedes generar una cadena a mano, si quieres... O interpolando caracteres, u ofuscando otra, o aplicando un algoritmo cualquiera de encriptación, o... El caso es que el resultado es una cadena de caracteres consecutivos que no sabes de dónde han salido ni como han sido generados, mirando simplemente esa cadena.

Puedes tener pistas por la longitud de la cadena, por ejemplo... Pero en ningún caso puedes decir que función se aplicó a una cadena para obtener otra... Salvo que sepas de donde salió esa cadena y que algoritmo se usó.

[loureed4]

Gracias de nuevo Moeb,

En mi red tengo ISA y ahora estoy en implementación de pruebas con IPTables, sin ningún frontend. No es tan difícil como me dijeron IPTables, yo lo tengo con política por defecto DROP y con varias políticas todas funcionando, eso si, tengo que añadir funcionalidades o contramedidad o reglas que actúen contra ataques smurf, spoofing, etc. He visto muchas de esas reglas por internet.

También estoy configurando Snort en el mismo equipo en el que tengo iptables e ISA (no los dos a la vez, ahora tengo el ISA, linux con iptables lo tengo en un dominio de laboratorio).

Snort , a diferencia de IPTables, lo encuentro sumamente dificil, hay que adentrarse mucho en TCP/IP creo yo.

Por cierto, la web tenía efectivamente un javascript en el que se le pasa el hash, lo tengo guardado en un archivo .pcap que genera Wireshark.

También comentar que no permito en mi dominio que se guarden los hashes LM, hay una política de GPO al respecto, creo que esta medida es muy útil, sólo permito que los servidores envíen respuesta NTLMv2.

También firmo los paquetes SMB en otra GPO para todos los equipos del dominio, con esta firma evitamos modificación de los paquetes sino he entendido mal la política.

Estoy viendo otra política o parámetro de GPO que dice:

"Network security: Minimum session security for NTLM SSP based (including secure RPC) clients" y "Network security: Minimum session security for NTLM SSP based (including secure RPC) servers" pero no lograo aclararme para que sirven dicha configuración.

Crees que ISA o IPtables + Cain + entradas estáticas en los equipos mediante script de inicio de sesión está bien? Pero es como todo, un firewall es tan fuerte como bien esté configurado, sino es una puerta más.

También obligo a los usuarios a cambiar contraseña cada 30 días y que tengan complejidad: Mayusculas, minúsculas, algún número, algún simbolo, no palabras de diccionario, que sean de más de 7 caracteres.

No he entendido cuando dices:
"Sigo pensando que SSL es mejor opción. Sin un keylogger, y si eres precavido para no caer en un MitM, tu password estará bastante seguro. Aunque... siempre podrán capturar tu sesión una vez autenticado, claro. " . Es decir, si estás con https , ¿pueden capturar como sugieres, la sesión?

Gracias de nuevo por tu tiempo !

[moeb]

NTLMSSP es una extensión de seguridad para la autenticación NTLM. Se usaba bastante para mejorar la seguridad del IIS (porque tambien sirve para la autenticación web de Microsoft y para los servicios que usan el rpc o remote procedure call).

Se trataba de una mejor forma de autenticar via NTLM, sobre todo si disponías de servicios diversos con autenticaciones más débiles, aunque ahora creo que lo han quitado (al menos yo no lo he visto en windows 2008 server...) Están apostando mucho más fuerte por kerberos (que es bastante mejor, la verdad).

"Sigo pensando que SSL es mejor opción. Sin un keylogger, y si eres precavido para no caer en un MitM, tu password estará bastante seguro. Aunque... siempre podrán capturar tu sesión una vez autenticado, claro. " . Es decir, si estás con https , ¿pueden capturar como sugieres, la sesión?

La mayor parte de las sesiones se mantienen mediante cookies que pasas al servidor en cada llamada... Cualquiera que robe esas cookies podría engañan al server haciéndose pasar por tí. Generalmente, las conexiones HTTPS se usan sólo en el momento de la autenticación para no enviar el password en claro (para no sobrecargar a los servidores), y a partir de ese momento te autenticas con tu cookie (generalmente ya via HTTP). La cookie podría ser capturada si tienen acceso troyanizado a tu disco duro o incluso "on the fly".

Recuerda... La seguridad no existe. Lo único que existe es la capacidad de ir poniendo trabas y mantener tus muros "defendidos" en la medida de lo posible (actualizaciones), además de una buena higiene informática (cuidado al navegar, con los correos, los usbs, etc...).

La verdad es que me gusta como lo estás montando. Se ve que te preocupas por estas cosas y eso siempre habla bien de un administrador de sistemas... Ánimo :)

[loureed4]

Muchas gracias por contestar Moeb, una vez más !.

1. La verdad es que en el curso de seguridad al que asiste online, nos comentaron la política "Minima Seguridad de sesión para clientes/servidores basados en NTLM SSP" , pero no me quedaba claro, aún tu respuesta tendré que investigar más ,porque en la definición de la política dice "autenticar" y luego "sesión" , entonces me llama a confusión.

Me refiero: un equipo se autentica en un controlador de dominio con kerberos v5 sino me equivoco (2003 Enterprise y XP SP3).

Sin embargo, estoy con pruebas de laboratorio donde tengo en VMWare 2 pc´s en la misma trama , en la misma red (192.168.56.x/24) pero que no tiene el mismo grupo de trabajo. El caso es que snifo con Cain, por averiguar las contraseñas de ambos equipos cuando hago \\equipo1 y \\equipo2 desde el equipo contrario. Efectivamente Cain coge el usuario pero en las credenciales es cuando me dice "AuthType: NTLM Session Security (NTLMSSP)" donde AuthType es Tipo de Autenticación imagino.

Lo que trato de saber es si autenticación es sólo autenticarte contra un Servidor kerberos Controlador del dominio o también lo es cuando haces una petición SMB o CIFS mediante \\nombre-netbios-equipo o \\IP-Equipo .....¿En este caso me estoy autenticando? . De alguna manera, Cain me ha cogido las credenciales, en realidad sólo el usuario, pero no la contraseña aunque tengo los hashes que cojo Cain y podría aplicarles unas tablas que tengo creadas con Winrtgen (nos lo recomendaron en el curso).

Ese es mi lío, mi confusión, cuando se habla de autenticar , que yo tengo entendido que es un cliente del dominio contra un controlador del dominio, aquí hay autenticación............pero en un equipo en el que escribo \\servidor-ficheros ...¿hay autenticación y por tanto son válidas las políticas de NTLM SSP?

Perdón por explicarme tan mal, es por el lío que tengo con dicha política.



2. No sabía que al estar yo en un sitio HTTPS sólo se usaba para autenticar y luego no, yo tenía entendido que era un "punto a punto" seguro, con SSL, sin que nadie pudiera ver nada, con certificado. Esto si que lo tengo que investigar bastante, lo que comentas de las cookies, de que luego el cliente se autentica por HTTP con su cookie.


Me das mucha información, espesa para mi porque estoy en la fase "newbie" jejej. No sabes cuanto lo agradezco !

Gracias Moeb por tu tiempo !!

[moeb]

Autenticación es autenticación. Es decir, le llame la gente lo que le llame, cada vez que te requieren unas credenciales te están pidiendo que te autentiques... Y cada vez que las suministres te estás autenticando (al margen del protocolo e incluso al margen de la informática... Lo mismo pasa cuando te piden el carné por la calle).

Sin embargo, estoy con pruebas de laboratorio donde tengo en VMWare 2 pc´s en la misma trama , en la misma red (192.168.56.x/24) pero que no tiene el mismo grupo de trabajo. El caso es que snifo con Cain, por averiguar las contraseñas de ambos equipos cuando hago \\equipo1 y \\equipo2 desde el equipo contrario. Efectivamente Cain coge el usuario pero en las credenciales es cuando me dice "AuthType: NTLM Session Security (NTLMSSP)" donde AuthType es Tipo de Autenticación imagino.

Haz la prueba con un servidor virtual... Dos XPs no necesariamente usan kerberos fuera de un dominio y una política concreta.

No es que el HTTPS SOLO SE USE para autenticar y luego, automáticamente, se cambie a HTTP.

Lo que decía, o trataba de decir, es que HABITUALMENTE todos los sitios utilizan HTTPS SOLO en el momento de la autenticación, por razones obvias de rendimiento y de saturación del servidor (con muchas peticiones simultáneas, si por cada una, además de "servirla", debes encriptarla/desencriptarla acabarás con una carga de servidor que te permitirá atender menos conexiones antes de colapsarlo, que si no hubiese encriptación.

Desde luego, si tu te montas un servidor web en el que sólo admites acceso vía HTTPS (SSL), TODO el tráfico será a través de https. Simplemente, eso no es lo habitual en Internet por las razones que te comenté arriba.

En un ambiente controlado por tí, con un número de clientes y conexiones máximas también controladas por tí, puedes (e incluso debes) montarlo todo a través de SSL, si la seguridad es crítica.

En ese caso, si nadie consigue hacerte un MitM, para robar tu sesión deberían troyanizar tu equipo y robar la cookie de tu equipo... O encontrar un bug en el servidor y robar la sesión allí. Lógicamente, el margen del atacante se estrecha, con lo que tu seguridad mejora.

[loureed4]

Muchas gracias por contestar, once again, jeje.

Muy buena la aclaración de HTTPS, y me has dado una pista para investigar temas de las cookies de sesión. Me pondré a ello, me interesa mucho el tema.

También me ha quedado muy claro que si escribo: \\pc2 , me tengo que autenticar, si estoy en el dominio con ticket Kerberos creo recordar, y si estoy en mismo grupo de trabajo con LM. NTLM o NTLMv2.

la verdad es que la pregunta de la autenticación ha sido un poco tonta, porque como dices, es lógico (ahora lo veo lógico) que si tú dices \\otro-pc , ese otro pc te va a pedir autenticación, y si estás en el mismo switch pero no en el mismo dominio, creo que interviene NTLM o NTLMv2 o NTLMSSP.

Hasta donde sé NTLMSSP hay que activarlo, no viene por defecto. Yo activo las cuatro políticas que incluye cuando se entra en el detalle de esa configuración:
Requerir integridad mensaje (no se ha cambiado nada por el camino), Requerir confidencialidad del mensaje (esto parece ser cifrado), Requerir NTLMv2 Seguridad de Sesión y Requerir 128 bits de cifrado.

Estas cuatro política suenan genial: integridad y confidencialidad y requerir 128 bits (esto de los 128 bits es confidencialidad también?).

Hay dos políticas al respecto, la del cliente y la del servidor, pero estoy atrancado proque las he deshabilitado, he hecho gpupdate en ambos equipos y cuando vuelvo a hacer \\otro-pc , Cain me dice que el Auth Method es NTLMSSP y aplico unas tablas NTLM que tengo creadas con WinRTGen, y me dice que no son hashes NTLM, cuando el mismo Caín te los cataloga como tal, de hecho no los cataloga como NTLMv2, sino como NTLM , los envío al apartado "Cracker" y es ahí donde me dice que no hay hashes NTLM en las tablas de WinRTGen.

Gracias por tu tiempo !