[Seguridad] Las plantas también pueden vacunar

December 27th, 2010 | Posted by bios in Uncategorized - (0 Comments)

Hasta ahora cuando se habla de plantas transgénicas (polémicas
estériles e infundadas aparte) normalmente nos referimos a plantas
capaces de tolerar herbicidas o plagas, es decir plantas que
producen más comida, hoy por hoy, las únicas variedades disponibles
al público. Ya existe una segunda generación en las últimas fases
de evaluación con las propiedades nutricionales mejoradas (es
decir, plantas que producen mejor comida).

, , , , ,

[Seguridad] Usando la última vulnerabilidad de Internet Explorer con Metasploit

December 27th, 2010 | Posted by bios in Uncategorized - (0 Comments)

Como ya se sabe se encuentra in-the-wild un exploit para una vulnerabilidad 0-day para todas las versiones de Internet Explorer. A continuación detallo la utilización de este exploit al utilizarlo con Metasploit, quien ya ha publicado el código desde hace algunos días.

Lo primero que debe hacerse es actualizar la herramienta con msfupdate y se verá que se descarga el código del exploit mencionado: exploit/windows/browser/ms11_xxx_ie_css_import.rb (MS11-XXX indica que la actualización saldrá en algún momento del 2011).
A partir de ahora ya lo podremos utilizar con el comando use y también se deberá seleccionar el payload preferido, como puede ser alguna shell o meterpreter:

Luego se configuran los parámetros obligatorios del exploit y del payload seleccionado. En este caso la dirección del servidor y el localhost, que se corresponden con la IP de nuestro equipo atacante:

Se ejecuta el exploit normalmente y Metasploit nos entrega la URL a la cual la víctima deberá ingresar:

Si se utiliza alguna técnica de ingeniería social para convencerlo, la víctima terminará ingresando a la URL mencionada, explotando la vulnerabilidad, ocasionando una denegación de servicio en el explorador e inyectando un proceso en el mismo. En este caso, para la prueba se utilizó Internet Explorer 8.0:

Nota: al intentar este procedimiento sobre Internet Explorer 6.0 que también es vulnerable, sólo he logrado el cuelgue del navegador pero la inyección del proceso no se lleva a cabo. Por supuesto, si se realiza sobre un navegador distinto de Internet Explorer, no se obtiene ningún resultado.

Cuando el usuario abre la URL en su navegador, desde Metasploit podremos seguir dicho comportamiento y ver la inyección del proceso (llamado notepad.exe) en Internet Explorer:

A partir de ese momento ya se tiene activa la sesión en el equipo víctima, con los mismos permisos que el usuario afectado y por eso la permanente necesidad de utilizar el sistema con permisos restringidos, sobre todo si se trata de un entorno corporativo.

Si se observa los programas activos, efectivamente se ve el Internet Explorer con el proceso inyectado (en este caso notepad.exe con ID 4428):

Y a partir de este momento se puede utilizar la sesión establecida en el equipo víctima, por ejemplo para realizar un listado de archivos:

Hay que tener en cuenta que la mayoría de los antivirus ya detectan el exploit utilizado por Metasploit (el original) por lo que si el cliente ingresa a la URL con el antivirus habilitado es posible que se percate del ataque.

Más allá de ese detalle, Metaesploit nos facilita mucho el trabajo de explotar una vulnerabilidad cualquiera y permite acceder a equipos que no han sido actualizados y, peor aún en este caso, cuando la actualización ni siquiera existe aún.

Cristian de la Redacción de Segu-Info



, , , , , , , , , , , , , , ,

[Seguridad] Pruebas de intrusión sobre aplicaciones

December 27th, 2010 | Posted by bios in Uncategorized - (0 Comments)

Las aplicaciones son hoy en día uno de los activos principales de cualquier empresa. Tanto si dan servicio a usuarios finales (por ejemplo aplicaciones de ebanking o ecommerce) como si se trata de aplicaciones corporativas (una intranet), las aplicaciones manejan información cuya confidencialidad, disponibilidad e integridad es fundamental para las empresas.

Las Auditorías de Seguridad sobre Aplicaciones se han vuelto imprescindibles para evaluar la seguridad de los desarrollos (propios o realizados por terceros). Estas auditorías o evaluaciones deben realizarse periódicamente y tendiendo en cuenta tanto la parte interna (accesos desde la red corporativa) como la parte externa (accesos con origen Internet) de los aplicativos.

Uno de las metodologías con más reconocimiento internacional a la hora de realizar auditorías de seguridad sobre aplicaciones es la OWASP Testing Guide que alcanza ya su tercera versión. La OWASP (Open Web Application Security Project) lanzó este proyecto con el objetivo de crear un marco que incluyera las mejores prácticas en el desarrollo de tests de intrusión en aplicaciones. La ultima versión (v3) de la Testing Guide fue publicada en Diciembre de 2008 y esta previsto que se la v4 de la guía se publicada en Enero de 2011.

A lo largo de más de 300 páginas, la OWASP Testing Guide hace un repaso de las principales técnicas de auditoría de seguridad en aplicaciones relacionando estas técnicas con las amenazas que sufren hoy en día de aplicativos. A grandes rasgos las pruebas de intrusión sobre aplicaciones desarrolladas en la OWASP Testing Guide son las siguientes:
1.- Recopilación de información
Esta primera fase de la Auditoria de Seguridad consiste en recopilar toda la información que se pueda sobre la aplicación cuya seguridad está siendo auditada.
Los tipos de análisis a realizar en este punto son los siguientes:

  • Spiders, robots y crawlers:
  • Reconocimiento mediante motores de búsqueda.
  • Identificación de puntos de entrada de la aplicación.
  • Pruebas de firmas de aplicaciones Web.
  • Descubrimiento de aplicaciones.
  • Análisis de código de error.

2.- Pruebas de gestión de configuración de la infraestructura
En esta etapa se realiza un análisis de la infraestructura tecnológica sobre la que se encuentra desplegada la Aplicación que se desea auditar.
Las pruebas a realizar en esta segunda etapa son las siguientes:

  • Pruebas de SSL/TLS.
  • Pruebas del receptor de escucha de la Base de Datos.
  • Pruebas de gestión de configuración de la infraestructura.
  • Pruebas de gestión de configuración de la aplicación.
  • Gestión de extensiones de archivos.
  • Archivos antiguos, copias de seguridad y sin referencias.
  • Interfaces de administración de la infraestructura y de la aplicación.
  • Métodos HTTP y XST.

3.- Comprobación del sistema de Autenticación
Comprobar el sistema de autenticación significa comprender como funciona el proceso de autenticación y usar esa información para eludir el mecanismo de autenticación.
Las pruebas que se realizan para evaluar el sistema de Autenticación son las siguientes

  • Transmisión de credenciales a través de un canal cifrado.
  • Enumeración de usuarios.
  • Pruebas de fuerza bruta.
  • Saltarse el sistema de Autenticación.
  • Comprobar Sistemas de recordatorio/restauración de contraseñas vulnerables.
  • Pruebas de gestión del Caché de Navegación y de salida de sesión.
  • Pruebas de CAPTCHA.
  • Múltiples factores de autenticación.
  • Análisis de condiciones de carrera.

4.- Pruebas de gestión de sesión
Ataques a la gestión de sesiones de una aplicación pueden ser utilizados para obtener acceso a cuentas de usuario sin necesidad de proporcionar credenciales correctos.
Para validar una correcta gestión de sesiones, la OWASP Testing Guide propone las siguientes verificaciones:

  • Pruebas para el esquema de gestión de sesiones.
  • Pruebas para atributos de cookies.
  • Pruebas para fijación de sesión.
  • Pruebas para variables de sesión expuestas.
  • Pruebas para CSRF

5.- Pruebas de Autorización
La Autorización es un proceso posterior a la Autenticación por lo tanto el auditor necesitará de credenciales para realizar las pruebas correspondientes a este módulo.
Se comprobará si es posible evadir la autorización de la aplicación, si existe una vulnerabilidad en el traspaso de rutas o si es posible realizar un escalado de privilegios.
Las pruebas a realizar para evaluar la seguridad del sistema de Autorización son las siguientes:

  • Pruebas de path transversal.
  • Pruebas para saltarse el esquema de autenticación.
  • Pruebas de escalado de privilegios.

6.- Comprobación de la lógica del negocio
La principal técnica para detectar errores en la lógica de la aplicación es “pensar de forma no convencional”; por ejemplo, intentar saltarse uno de los 3 pasos del proceso de registro de una aplicación.
Las vulnerabilidades de este tipo pueden ser de las más graves de la aplicación y encontrarlas se basa únicamente en la habilidad y creatividad del auditor.

7.- Pruebas de validación de datos
La vulnerabilidad más común en las aplicaciones es la falta de validación de los parámetros introducidos por los usuarios. Esta vulnerabilidad provoca que usuarios malintencionados inyectan comandos o sentencias en vez de simples datos, con el peligro que esto conlleva para la normal ejecución de la aplicación.
Las pruebas de evaluación a realizar durante la comprobación de validación de datos en la aplicación auditada son las siguientes:

  • Pruebas de cross site scripting.
  • Inyección SQL.
  • Inyección LDAP.
  • Inyección ORM.
  • Inyección XML.
  • Inyección SSI.
  • Inyección XPATH.
  • Inyección IMAP/SMTP.
  • Inyección de código.
  • Inyección de comandos de sistema operativo.
  • Pruebas de desbordamiento de buffer.
  • Pruebas de vulnerabilidad incubada.
  • * Pruebas de HTTP Splitting/Smuggling

8.- Pruebas de denegación de servicio
El objetivo fundamental de un ataque de denegación de servicio es lograr que la aplicación objeto del ataque se vea desbordada (ya sean sus funciones de red, su memoria, su espacio de disco, etc.) hasta conseguir que deje de funcionar adecuadamente.
Las pruebas de DoS que se tratan en la OWASP Testing Guide son las siguientes:

  • Denegación de servicio mediante ataques SQL Wildcard.
  • Bloqueando cuentas de usuarios.
  • Desbordamiento de búfer.
  • Reserva de Objetos Especificada por Usuarios.
  • Pruebas de Escritura de Entradas Suministradas por Usuario a Disco.
  • Fallar en la liberación de recursos.
  • Pruebas de Almacenamiento Excesivo en la Sesión.

9.- Comprobación de servicios Web
Los servicios web suelen utilizar el protocolo HTTP junto con tecnologías como XLM, SOAP, WSDL y UDDI; por lo que las pruebas de seguridad sobre servicios web deben centrarse en las búsqueda e identificación de las vulnerabilidades en dichas tecnologías.
Las pruebas a realizar en esta fase de la auditoría son las siguientes:

  • Obtención de información en Servicios Web.
  • Pruebas de WSDL.
  • Pruebas estructurales de XML.
  • Comprobación de XML a nivel de contenido.
  • Comprobación de parámetros HTTP GET/REST.
  • Adjuntos SOAP maliciosos.
  • Pruebas de repetición.

10.- Pruebas de AJAX
Las aplicaciones basadas en tecnologías AJAX han tenido una rápida expansión debido a la gran interactividad y facilidad de uso que proporcionan. Sin embargo, al aumentar la superficie de ataque y al procesar instrucciones tanto en el lado cliente como en el lado servidor, las vulnerabilidades de seguridad de las aplicaciones AJAX son tantas o incluso más que las de las aplicaciones desarrollados con otras tecnologías.

La OWASP Testing Guide v3.0 describe los siguientes temas:

  • Vulnerabilidades AJAX.
  • Como probar AJAX.

Fuente: Boletín Noviembre ISECAuditors



, , , , , , , , , , ,

[Seguridad] Recomendaciones contra la última vulnerabilidad en Internet Explorer

December 27th, 2010 | Posted by bios in Uncategorized - (0 Comments)

Metasploit ha creado y hecho público un exploit que permite aprovechar una de las vulnerabilidades que Internet Explorer sufre en estos días y no ha corregido aún. En realidad ya existía un exploit público para este fallo, solo que ahora Microsoft lo ha reconocido. Ofrecemos algunas recomendaciones para mitigar el problema hasta que exista parche.

El día 8 de diciembre se hacía público un fallo en el procesamiento de Cascading Style Sheets (CSS) que permitía provocar una denegación de servicio (que Internet Explorer dejase de responder) de forma sencilla con sólo visitar una web. En principio, las denegaciones de servicio en navegadores no son del todo graves, sino más bien una incomodidad para el usuario. Además, son fáciles de provocar con JavaScript.

El problema con ciertas denegaciones de servicio es que a veces pueden ir más allá, y acabar en ejecución de código (no es la primera vez que ocurre). El hecho de que una aplicación deje de responder puede ser el indicio de que existe alguna forma de controlar el flujo de instrucciones. Si es así, el problema es muy grave. Y esto precisamente es lo que ocurrió el día 14. Algunos investigadores descubrieron cómo ir más allá y ejecutar código arbitrario en lo que parecía una simple denegación de servicio. Afectaba a Internet Explorer 6, 7 y 8.

Muy poco después, Nephi Johnson de breakingpointsystems.com, publicaba el código necesario para aprovechar la vulnerabilidad. El día 23 de diciembre el fallo se añade al popular Metasploit. La diferencia con respecto al anterior, es que ahora el exploit podía eludir DEP y ASLR en Vista y 7. Esto es relativamente sencillo últimamente, debido a la carga dinámica en Internet Explorer de librerías que no están marcadas para utilizar ASLR (en este caso mscorie.dll) y el uso de RoP (return oriented programming).

Ese mismo día Microsoft reconoce el fallo y comienza a trabajar en él para solucionarlo. No se tiene constancia de que esté siendo aprovechado por atacantes aún para instalar malware (aunque sin duda es lo más probable).

Damos algunas sugerencias para mitigar el fallo. En realidad, los consejos son válidos para intentar mitigar cualquier vulnerabilidad:Utilizar las zonas de seguridad de Internet Explorer. Si se eleva a “alta” el nivel de seguridad de la zona de Internet del navegador, se evitarían muchísimos de los ataques actuales. Esta posibilidad está disponible en las opciones del navegador. Si se tienen problemas para visualizar páginas legítimas, basta con añadirlas a la lista de confianza.

  • Utilizar Enhanced Mitigation Experience Toolkit (EMET) de Microsoft. Esta herramienta permite que todas las DLL cargadas por un programa sean obligadas a usar ASLR. Esto quiere decir que serán colocadas en lugares aleatorios de la memoria y el exploit que intente apoyarse en ellas para funcionar, no lo hará.
  • Ahora que están de moda las sandbox desde que Adobe la implementa en su lector, cabe recordar que existen programas que permiten “encapsular” en una sandbox otras aplicaciones. En concreto, por ejemplo sandboxie (gratuito) permite ejecutar el navegador dentro de un entorno virtual. Cualquier ataque no pasaría al entorno “real” del sistema.
  • Existen aplicaciones como WehnTrus (gratuita) que permiten implementar ASLR en los sistemas operativos de Microsoft que no lo soportan, como Windows XP y 2003.

Fuente: Hispasec



, , , , , , , , , , , ,