¿Cómo podemos analizar estas posibles conexiones?
El proceso es muy sencillo y lo explico a continuación...Ejecutamos Símbolo del Sistema como Administrador
SeguridadDelMal
miércoles, 19 de septiembre de 2012
Analizando posibles conexiones secretas
Analizando posibles conexiones secretas:
Como saben, Windows lleva a cabo conexiones en segundo plano a sitios, software que trabaja en segundo plano y, en el peor de los casos, de virus o troyanos. Esto último, ocasiona que nuestra conexión a Internet se reduzca aunque tengamos cerrados los programas que normalmente requieren un gran ancho de banda. Ejemplo: FTP, P2P, etc.
¿Cómo podemos analizar estas posibles conexiones?
El proceso es muy sencillo y lo explico a continuación...Ejecutamos Símbolo del Sistema como Administrador
Dentro de la Línea de Comandos, escribimos "netstat -b 5 > activity.txt" (sin comillas)
Esperamos unos minutos (3 o 4), para que pueda guardar la actividad y presionamos "CTRL+C"
Y escribimos "activity.txt", se abrirá un archivo donde existe un registro de los procesos que estaban haciendo conexión a Internet en los minutos que esperábamos (3 o 4 minutos).
Por último, nos toca revisar el registro para comprobar la existencia de algo sospechoso... Esperemos no tener nada jajaj....
SeguridadDelMal
¿Cómo podemos analizar estas posibles conexiones?
El proceso es muy sencillo y lo explico a continuación...Ejecutamos Símbolo del Sistema como Administrador
SeguridadDelMal
CRIME: el nuevo ataque a SSL/TLS sucesor de BEAST
CRIME: el nuevo ataque a SSL/TLS sucesor de BEAST:
Juliano Rizzo y Thai Duong ya tuvieron una enorme repercusión cuando anunciaron en 2010 el ataque Padding Oracle (CBC) que afectó ampliamente ASP.NET y en 2011 el ataque a TLS 1.0/SSL 3.0 mediante BEAST que era capaz de descifrar las peticiones cliente 'al vuelo' y secuestrar sesiones hacia sitios tan sensibles como los de la banca on-line.
Ahora en la Ekoparty 2012, han presentado otra nueva técnica bautizada como CRIME para comprometer la integridad de las sesiones HTTP protegidas por SSL. Atentos que la explicación es un poco densa...
La técnica
SSL/TLS opcionalmente soporta compresión de datos. En el mensaje ClientHello, el cliente establece la lista de algoritmos de compresión que conoce, y el servidor responde, en el ServerHello, con el algoritmo de compresión que se utilizará.
Los algoritmos de compresión son especificados por identificadores de un byte y TLS 1.2 (RFC 5246) define únicamente el método de compresión nula (es decir, sin compresión). También hay otros documentos que especifican métodos de compresión. En particular, RFC 3749 define el método de compresión 1, basado en DEFLATE, el derivado de LZ77 que es el núcleo del formato gzip y también de los archivos Zip modernos. Cuando se utiliza la compresión, se aplica en todos los datos transferidos, como un stream largo. En particular, cuando se utiliza con HTTPS, la compresión se aplica en todas las sucesivas peticiones HTTP en el stream, la cabecera incluida. DEFLATE funciona mediante la localización de subsecuencias repetidas de bytes.
Supongamos que el atacante es un código javascript que puede enviar peticiones arbitrarias a un sitio destino (por ejemplo, un banco) y se ejecuta en la máquina atacada; el navegador enviará dichas solicitudes con la cookie del usuario del banco - el valor de la cookie que el atacante tiene después. Además, vamos a suponer que el atacante puede analizar el tráfico entre el ordenador del usuario y el banco (para ello, el atacante debe tener acceso a la misma LAN o al punto de acceso WiFi de la víctima, o se ha apropiado de un router de entre medias, posiblemente cerca del servidor del banco).
Para este ejemplo, supongamos que la cookie en cada solicitud HTTP es la siguiente:
> Cookie: secret=7xc89f+94/wa
El atacante conoce la parte "Cookie: secret =" y desea obtener el valor secret. Entonces, programa su código Javascript para emitir una petición que contenga en su cuerpo la secuencia "Cookie: secret = 0". La solicitud HTTP se verá así:
POST / HTTP/1.1 Host: thebankserver.com (…) Cookie: secret=7xc89f+94/wa (…)
Cookie: secret=0
Cuando DEFLATE vea que, hay repeticiones de secuencias "Cookie: secret =" y representan la segunda parte con un token muy corto (uno que dice "la secuencia anterior tiene una longitud de 15 y se encontraron n bytes anteriormente), DEFLATE tendrá para emitir un token adicional para el '0'.
La solicitud va al servidor. Desde el exterior, el atacante ve un blob opaco (SSL cifra los datos), pero puede ver su longitud (con una granularidad de bytes cuando la conexión utiliza RC4; con cifrado de bloques que hay un poco de relleno o padding pero puede ajustar el contenido de las peticiones por lo que, en la práctica, puede conocer también la longitud de las peticiones comprimidas).
Ahora, el atacante lo intenta de nuevo con "Cookie: secret=1" en el cuerpo de la petición. Luego, "Cookie: secret=2", y así sucesivamente. Todas estas peticiones se comprimen con el mismo tamaño (o casi porque hay matices con códigos de Huffman que se utilizan en DEFLATE), excepto el que contiene "Cookie: secret = 7", que comprime mejor (16 bytes de subsecuencia repetida en lugar de 15), y por lo tanto será más corta. El atacante ve eso. Por lo tanto, en unas pocas docenas de peticiones, el atacante habrá adivinado el primer byte del valor secreto.
A continuación, sólo tiene que repetir el proceso ("Cookie: secret = 70", "Cookie: secret = 71", y así sucesivamente) y obtener, byte por byte, el secret completo.
Impacto
Por lo tanto, para que el ataque CRIME tenga éxito, se requieren algunos aspectos:
- Que la compresión SSL/TLS se utilice en ambos extremos
- Que el atacante pueda ejecutar un agente Javascript en la víctima
- Un sniffer que tenga acceso a la sesión cifrada cliente-servidor
Otros factores facilitarían además el ataque:
- El uso de RC4 en lugar de cifrado de bloques como CBC (irónicamente se recomendó el uso de RC4 como una solución temporal contra BEAST...)
- La proximidad del sniffer al punto final del agente de la víctima podría proporcionar información más rápidamente, acortando el tiempo requerido para completar el ataque.
Contramedidas
Basándose en la información actual, parece que la principal contramedida sería desactivar la compresión SSL/TLS, una verdadera lástima en escenarios de conexiones con poco ancho de banda, especialmente en aquellos sitios que contienen muchas imágenes pequeñas o con Ajax pesados que requieren muchas peticiones pequeñas.
También y debido a que el ataque se centra en descifrar las credenciales de sesión, las mejores prácticas estándar para la protección de estas tokens también podrían limitar el impacto:
- Invalidar las credenciales de sesión al salir/idle para limitar la duración de la exposición.
- Invalidar y volver a emitir tokens de sesión periódicamente para limitar la duración de la exposición.
- Tokens de sesión asociados a una IP de origen específica para evitar su reutilización en otros lugares.
- Regenerar los tokens de sesión enlazados a un origen cuando esa fuente envía una solicitud con un token no válido. Esto limita la capacidad de un atacante de realizar fuerza bruta o adivinar tokens.
- Monitorizar los logs del servidor para identificar a un ataque en curso: al intentar enumerar los tokens de sesión, el agente de la víctima generará un gran número de peticiones al servidor web. Un IPS podría además detener el ataque de una forma proactiva.
- Las actualizaciones de software podrían hacer frente a este ataque y probablemente estarán disponible pronto, y hay algunos indicios de que muchos fabricantes ya han actualizado sus productos de forma silenciosa.
Referencias
- Rizzo, Juliano. "The CRIME attack." http://www.ekoparty.org//2012/juliano-rizzo.php
- Duong, Thai. "The CRIME attack." http://www.ekoparty.org//2012/thai-duong.php
- New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions https://threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512
- How can you protect yourself from CRIME, BEAST’s successor? http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/
Ahora en la Ekoparty 2012, han presentado otra nueva técnica bautizada como CRIME para comprometer la integridad de las sesiones HTTP protegidas por SSL. Atentos que la explicación es un poco densa...
La técnica
SSL/TLS opcionalmente soporta compresión de datos. En el mensaje ClientHello, el cliente establece la lista de algoritmos de compresión que conoce, y el servidor responde, en el ServerHello, con el algoritmo de compresión que se utilizará.
Los algoritmos de compresión son especificados por identificadores de un byte y TLS 1.2 (RFC 5246) define únicamente el método de compresión nula (es decir, sin compresión). También hay otros documentos que especifican métodos de compresión. En particular, RFC 3749 define el método de compresión 1, basado en DEFLATE, el derivado de LZ77 que es el núcleo del formato gzip y también de los archivos Zip modernos. Cuando se utiliza la compresión, se aplica en todos los datos transferidos, como un stream largo. En particular, cuando se utiliza con HTTPS, la compresión se aplica en todas las sucesivas peticiones HTTP en el stream, la cabecera incluida. DEFLATE funciona mediante la localización de subsecuencias repetidas de bytes.
Supongamos que el atacante es un código javascript que puede enviar peticiones arbitrarias a un sitio destino (por ejemplo, un banco) y se ejecuta en la máquina atacada; el navegador enviará dichas solicitudes con la cookie del usuario del banco - el valor de la cookie que el atacante tiene después. Además, vamos a suponer que el atacante puede analizar el tráfico entre el ordenador del usuario y el banco (para ello, el atacante debe tener acceso a la misma LAN o al punto de acceso WiFi de la víctima, o se ha apropiado de un router de entre medias, posiblemente cerca del servidor del banco).
Para este ejemplo, supongamos que la cookie en cada solicitud HTTP es la siguiente:
> Cookie: secret=7xc89f+94/wa
El atacante conoce la parte "Cookie: secret =" y desea obtener el valor secret. Entonces, programa su código Javascript para emitir una petición que contenga en su cuerpo la secuencia "Cookie: secret = 0". La solicitud HTTP se verá así:
POST / HTTP/1.1 Host: thebankserver.com (…) Cookie: secret=7xc89f+94/wa (…)
Cookie: secret=0
Cuando DEFLATE vea que, hay repeticiones de secuencias "Cookie: secret =" y representan la segunda parte con un token muy corto (uno que dice "la secuencia anterior tiene una longitud de 15 y se encontraron n bytes anteriormente), DEFLATE tendrá para emitir un token adicional para el '0'.
La solicitud va al servidor. Desde el exterior, el atacante ve un blob opaco (SSL cifra los datos), pero puede ver su longitud (con una granularidad de bytes cuando la conexión utiliza RC4; con cifrado de bloques que hay un poco de relleno o padding pero puede ajustar el contenido de las peticiones por lo que, en la práctica, puede conocer también la longitud de las peticiones comprimidas).
Ahora, el atacante lo intenta de nuevo con "Cookie: secret=1" en el cuerpo de la petición. Luego, "Cookie: secret=2", y así sucesivamente. Todas estas peticiones se comprimen con el mismo tamaño (o casi porque hay matices con códigos de Huffman que se utilizan en DEFLATE), excepto el que contiene "Cookie: secret = 7", que comprime mejor (16 bytes de subsecuencia repetida en lugar de 15), y por lo tanto será más corta. El atacante ve eso. Por lo tanto, en unas pocas docenas de peticiones, el atacante habrá adivinado el primer byte del valor secreto.
A continuación, sólo tiene que repetir el proceso ("Cookie: secret = 70", "Cookie: secret = 71", y así sucesivamente) y obtener, byte por byte, el secret completo.
Impacto
Por lo tanto, para que el ataque CRIME tenga éxito, se requieren algunos aspectos:
- Que la compresión SSL/TLS se utilice en ambos extremos
- Que el atacante pueda ejecutar un agente Javascript en la víctima
- Un sniffer que tenga acceso a la sesión cifrada cliente-servidor
Otros factores facilitarían además el ataque:
- El uso de RC4 en lugar de cifrado de bloques como CBC (irónicamente se recomendó el uso de RC4 como una solución temporal contra BEAST...)
- La proximidad del sniffer al punto final del agente de la víctima podría proporcionar información más rápidamente, acortando el tiempo requerido para completar el ataque.
Contramedidas
Basándose en la información actual, parece que la principal contramedida sería desactivar la compresión SSL/TLS, una verdadera lástima en escenarios de conexiones con poco ancho de banda, especialmente en aquellos sitios que contienen muchas imágenes pequeñas o con Ajax pesados que requieren muchas peticiones pequeñas.
También y debido a que el ataque se centra en descifrar las credenciales de sesión, las mejores prácticas estándar para la protección de estas tokens también podrían limitar el impacto:
- Invalidar las credenciales de sesión al salir/idle para limitar la duración de la exposición.
- Invalidar y volver a emitir tokens de sesión periódicamente para limitar la duración de la exposición.
- Tokens de sesión asociados a una IP de origen específica para evitar su reutilización en otros lugares.
- Regenerar los tokens de sesión enlazados a un origen cuando esa fuente envía una solicitud con un token no válido. Esto limita la capacidad de un atacante de realizar fuerza bruta o adivinar tokens.
- Monitorizar los logs del servidor para identificar a un ataque en curso: al intentar enumerar los tokens de sesión, el agente de la víctima generará un gran número de peticiones al servidor web. Un IPS podría además detener el ataque de una forma proactiva.
- Las actualizaciones de software podrían hacer frente a este ataque y probablemente estarán disponible pronto, y hay algunos indicios de que muchos fabricantes ya han actualizado sus productos de forma silenciosa.
Referencias
- Rizzo, Juliano. "The CRIME attack." http://www.ekoparty.org//2012/juliano-rizzo.php
- Duong, Thai. "The CRIME attack." http://www.ekoparty.org//2012/thai-duong.php
- New Attack Uses SSL/TLS Information Leak to Hijack HTTPS Sessions https://threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512
- How can you protect yourself from CRIME, BEAST’s successor? http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/
jueves, 13 de septiembre de 2012
Solucionario de SAURON Hard (Dificultad Alta), CTF Challenge por @killr00t ganador del reto
Solucionario de SAURON Hard (Dificultad Alta), CTF Challenge por @killr00t ganador del reto:
Solucionario propuesto por @killr00t al reto SAURON nivel Hard. @killr00t cumplió con el objetivo del desafío: Realizar un solucionario diferente a los publicados en internet (aunque en este solo había público uno para el nivel fácil), hacerse root del server y mostrarlo de manera didáctica.
Como siempre animar y recordar a los recién iniciados y expertos a participar de estos desafíos, pues no hay mejor manera de aprender que enseñando…
Felicitaciones a @killr00t quién se convierte en el ganador de una tarjeta Amazon gift por un valor de $30 usd. Además que fue el único que envió solucionario de los 33 que descargaron el entorno… Se concluyen varias cosas… Entre ellas que el entorno no estaba fácil, y que muchos acostumbran a realizar los solucionarios basados en los ya publicados (no está mal del todo) Pero el ideal es intentarlo por si mismo… Como vimos que hizo Killr00t 
Mucho ánimo, pues en unos días presento otro reto igualmente premiado gracias a la corporación ElHackLab.
Ver en línea:Julian Assange, el antiguo hacker que sigue desafiando a los grandes poderes
Julian Assange, el antiguo hacker que sigue desafiando a los grandes poderes:
Pese a enfrentar un juicio de extradición, creador de WikiLeaks continúa divulgando información que pone en aprietos a gobiernos y empresas
El enigmático informático australiano Julian Assange sigue desafiando a los Gobiernos y poderes fácticos pese a estar sometido a un duro proceso judicial que él atribuye a una persecución política.
Desde su arresto domicilia...
El enigmático informático australiano Julian Assange sigue desafiando a los Gobiernos y poderes fácticos pese a estar sometido a un duro proceso judicial que él atribuye a una persecución política.
Desde su arresto domicilia...
miércoles, 12 de septiembre de 2012
¿Bing poisoning?
¿Bing poisoning?: Las técnicas de Google poisoning o Google image poisoning son más que conocidas. Consisten en comprometer una página y hacer que se comporte diferente según de donde venga la visita. Los atacantes añaden código en la web para comprobar el "Referer". Si el visitante viene de Google, es redirigido a alguna página de spam o malware. Si no, la página se muestra sin problemas. De esto ya hablé en el artículo con el celebrado título Elefantes que defecan malware. Lo curioso es que esta mañana me he encontrado con un caso que creía "Bing poisoning"... pero al final no. Buscando en estos momentos "economía for dummies" en Google, acabas en esta web:
La página está comprometida. En este caso, en vez de un script en JavaScript, parece que le han introducido un 302 que lleva a la web maliciosa. Como ya sabemos, estas páginas suelen fijarse en el Referer como condición para redirigir, así que lo comprobamos con la cadena "google".
No funcionaba. Devolvía la página original. Extraño. Después de varios intentos infructuosos, comprobamos que, con Bing y otros buscadores, sí que funciona la redirección.
¿Estamos ante un "Bing poisoining"? ¿Se ha vuelto tan popular el buscador de Microsoft que han obviado a Google y se han centrado solo en Bing? No, evidentemente. Después de inspeccionar el tráfico, comprobamos que, para la redirección, los atacantes no solo tienen en cuenta el dominio google, sino también un parámetro concreto. "sa". Solo con ese parámetro, más "google.com" en la cadena de Referer, se produce la redirección.
Investigando, comprobamos la utilidad del parámetro. Al parecer controla el "Search engine results page", o sea, cómo se usa la página de resultados de búsqueda. Esto quiere decir que solo funciona si de verdad has buscado esos términos en Google, y se ha elegido uno de los resultados. Parece que no sirve para GoogleBot o cualquier otro uso en el que se incluya solo "google" en el Referer.
Fuente: http://www.blueglass.com/blog/google-search-url-parameters-query-string-anatomy/
Así que en realidad, se trata de un pequeño refinamiento en el comportamiento con (y solo con) el buscador de Google y no un cambio de tendencia...
La página está comprometida. En este caso, en vez de un script en JavaScript, parece que le han introducido un 302 que lleva a la web maliciosa. Como ya sabemos, estas páginas suelen fijarse en el Referer como condición para redirigir, así que lo comprobamos con la cadena "google".
No funcionaba. Devolvía la página original. Extraño. Después de varios intentos infructuosos, comprobamos que, con Bing y otros buscadores, sí que funciona la redirección.
¿Estamos ante un "Bing poisoining"? ¿Se ha vuelto tan popular el buscador de Microsoft que han obviado a Google y se han centrado solo en Bing? No, evidentemente. Después de inspeccionar el tráfico, comprobamos que, para la redirección, los atacantes no solo tienen en cuenta el dominio google, sino también un parámetro concreto. "sa". Solo con ese parámetro, más "google.com" en la cadena de Referer, se produce la redirección.
Investigando, comprobamos la utilidad del parámetro. Al parecer controla el "Search engine results page", o sea, cómo se usa la página de resultados de búsqueda. Esto quiere decir que solo funciona si de verdad has buscado esos términos en Google, y se ha elegido uno de los resultados. Parece que no sirve para GoogleBot o cualquier otro uso en el que se incluya solo "google" en el Referer.
Fuente: http://www.blueglass.com/blog/google-search-url-parameters-query-string-anatomy/
Así que en realidad, se trata de un pequeño refinamiento en el comportamiento con (y solo con) el buscador de Google y no un cambio de tendencia...
Kylin OS (Sistema Operativo del Gobierno de China) basado en FreeBSD
Kylin OS (Sistema Operativo del Gobierno de China) basado en FreeBSD:
Después de la reciente escalada de ciberataques producidos en territorio Estadounidense y las posteriores acusaciones al Gobierno Chino de estar creando un caldo de cultivo para una inminente Ciberguerra, ha surgido información que indica que el Gobierno Chino ha desplegado un un nuevo Sistema Operativo de nombre Kylin, que en teoría sería invulnerable ante cualquier forma conocida de ataque, ya sea que provenga de los Estados Unidos, o de cualquier otra fuente. Si bien no han comenzado a lanzarse misiles virtuales, las medidas de defensa adoptadas por ambas potencias arrojan un velo de preocupación sobre la comunidad digital mundial.
DESCARGAR Kylin OS:
INFORMACIÓN DEL SISTEMA:
Kylin es un Sistema Operativo que se centra en el rendimiento de alta disponibilidad y seguridad. Su desarrollo inicial fue financiado y patrocinado por el Gobierno Chino de Investigación y Desarrollo (R&D) en el 2002. La primera versión pública de Kylin fue lanzado en 2007.
Kylin se basa en FreeBSD 5.3 con algunas extensiones de seguridad propias para añadir un nivel adicional de seguridad para ese sistema operativo. Kylin, el nombre de Qili, una bestia mítica, se ha organizado en un modelo de jerarquía, incluyendo la capa de núcleo básico, que es responsable de la inicialización del hardware y proporcionando la gestión de memoria básica y la gestión de tareas, la capa de servicio del sistema que se basa en FreeBSD proporciona UFS2 y los protocolos de red de BSD, y el entorno de escritorio que es similar a Windows. Se ha diseñado para cumplir con los estándares de UNIX y es compatible con los binarios de Linux.
Kylin está aprobado para su uso por el Ejército Popular de Liberación y al parecer ha sido desplegado en el ejército Chino, la Defensa Nacional y las organizaciones sensibles del gobierno desde 2007. Kylin también se está utilizando en finanzas, gobierno y educación.
EMPRESAS QUE USAN Kylin:
CAPTURAS DEL SISTEMA:
- Instalación del Sistema (Virtual Box)
- Pantalla para logearse:
- Escritorio de Kylin OS
- http://www.findthatfile.com/search-587720-fISO/software-tools-download-kylin-2-1-1a-iso.htm
- http://www.findthatfile.com/search-587721-fISO/software-tools-download-kylin-2.1-1b.iso.htm
SITIO OFICIAL:
Contribución gracias a Caleb Bucker de [In]Seguridad Informática
Suscribirse a:
Entradas (Atom)