¿Mi firewall es seguro? pt1

Dada la reciente paranoia que se ha desatado en el trabajo debido a los ataques conocidos como phishing de los que hemos sido víctimas. Eh decidido publicar un pequeño trabajo que me encargaron cuando realice mi servicio social en el Sistema de Administración Tributaria. Se trata de una humilde traducción que hice de los productos del sitio http://www.matousec.com/ que nos permitirá conocer la seguridad que nos proporciona nuestro Firewall. Les advierto desde ya que el asunto puede ser un poco tanto mucho muy técnico, pero nada que Google (o su buscador favorito) no pueda solucionar. Aunque es obvio que si nuestro “Cortafuegos” no supera más de la mitad de las pruebas entonces es más que necesario cambiar el programa. Si se quieren ahorrar todas las pruebas e ir a probar directamente un Firewall 99.9998% recomendable googleen por Comodo Firewall Pro, del cual publicaré un pequeño manual en estos días. De acuerdo a MatouSec (y a mi propia experiencia) supero todas las pruebas y además es gratuito.

Sin más les dejo el enlace para descargar la suite de prueba (necesitamos un poco de conocimiento de MS-DOS para ejecutar las pruebas)

http://www.matousec.com/downloads/

Y desde aquí el firewall

http://personalfirewall.comodo.com/

Prueba 01: Leaktest

Se ha demostrado que si un programa dañino se renombra con el nombre de una aplicación autorizada es posible que burle el Firewall. Las últimas versiones de los firewalls personales incluyen una suma de verificación para las aplicaciones

Significado.

Si el resultado es exitoso, significa que el firewall confía en las aplicaciones por su nombre en lugar de una huella cifrada por md5.

Prueba 02: Tooleaky

Abre el navegador web predeterminado con la siguiente línea de comando

iexplore.exe http://grc.com/lt/leaktest.htm?PersonalInfoGoesHere

Esto ejecuta una ventana escondida. Si el navegador tiene acceso al puerto 80, toda la información será enviada a una dirección remota, en este caso GRC.COM. Esta información podría ser contraseñas, o números de tarjeta de crédito.

Significado

Si la prueba es exitosa, significa que el firewall no revisa las aplicaciones que son ejecutadas por otras.

Prueba 03: Firehole

Utiliza el navegador para transmitir datos a un host remoto. Para hacer esto, instala una DLL (con una función de intercepción en ella) en la computadora del usuario. Después de esto la DLL se carga a si misma en el mismo espacio del proceso de la aplicación objetivo, que es de confianza, con lo que existe una gran posibilidad de que Firehole pueda acceder al Internet sigilosamente.

Significado

Si la prueba es exitosa puede significar dos cosas: que el firewall no tiene un control sobre las aplicaciones que otras aplicaciones ejecutan y que es vulnerable a una inyección de DLL.

Si la prueba falla, significa que el firewall controla el primer punto, pero no siempre significa que no sea vulnerable a una inyección de DLL.

Prueba 04: Yelta

Yelta tiene dos pruebas: una prueba clásica y una prueba avanzada.

La prueba clásica intenta envía paquetes UDP a través de puertos que están comúnmente abiertos, como el 53 (DNS), 21 (FTP), esperando que tengan autorización para enviar información.

La prueba avanzada utiliza un controlador para enviar sus paquetes directamente a la interfaz de red bajo la capa TCP/IP, pero solo funciona bajo Windows 9x o Millenium

Significado

Si la prueba es exitosa, significa que el firewall permite varios tipos de tráfico en los puertos pre-configurados.

Prueba 05: OutBound

OutBound envia paquetes directamente a la interfaz de red intentando burlar al firewall.

OutBound es diferente de otras pruebas ya que utiliza paquetes TCP con algunas banderas habilitadas, intentando hacerlas ver como una conexión establecida.

Significado

Si la prueba es exitosa significa que el firewall no verifica las capas mas bajas que la capa IP de Windows y/o solo verifica las nuevas conexiones en lugar de todo el tráfico.

Prueba 06: PCAudit

Utiliza una inyección de DLL para inyectar su código (como DLL) en una aplicación autorizada en lugar de lanzar su objetivo de manea directa.

Si la aplicación inyectada tiene un acceso completo, pcaudit trabajará sin problemas.

Para que PCAudit funcione de manera correcta, proporcione un acceso completo cuando el firewall pregunte por los permisos de Explorer.exe. Intente de nuevo y si el firewall no muestra una alerta de pcaudit.exe, significa que es vulnerable.

Significado

Si la prueba es exitosa significa que el firewall es vulnerable a una inyección de DLL. 

Prueba 07: AWFT
Ofrece seis pruebas.
Prueba 7.1: Intenta cargar una copia del navegador y parcharla en memoria antes de que se ejecute. Derrota a los Frirewalls más débiles
Prueba 7.2: Crea una copia del navegador preferido, si esta cargado, es un truco viejo, pero aún hay firewalls que fallan.
Prueba 7.3: Crea una copia del Explorador de Windows. Otro viejo truco, pero muchos firewalls aun caen.
Prueba 7.4: Intenta cargar una copia del navegador desde el Explorador de Windows y lo parcha en memoria antes de su ejecución. Derrota a los firewalls que requieren autorización para que una aplicación cargue otra, el explorador de Windows por lo general esta autorizado. Esta prueba es exitosa, a menos que el navegador tenga bloqueado el acceso a Internet.
Prueba 7.5: Realiza una búsqueda heurística de proxy y otros programas autorizados para acceder al puerto 80, carga una copia y la parcha en memoria antes de su ejecución desde un hilo en el explorador de Windows.
Prueba 7.6: Realiza una búsqueda heurística de proxy y otros programas autorizados para acceder al puerto 80, pide al usuario que seleccione uno de ellos y crea un hilo en el proceso seleccionado.
 

Prueba 08: Thermite
En lugar de inyectar código utilizando DLLs Thermite inyecta directamente su código dentro del mismo proceso de manera directa, creando un hilo adicional dentro del proceso, totalmente invisible a algunos firewalls actuales.
Significado
Si la prueba es exitosa significa que el firewall es vulnerable a una inyección de proceso.

Prueba 09: CopyCat
Al igual que thermite copycat.exe utiliza inyección directa de código (sin crear un hilo adicional) dentro de un navegador para prevenir que sea detectado por el firewall.
Significado
Si la prueba es exitosa significa que el firewall es vulnerable a una inyección de proceso.


Prueba 10: MBTest
Envía directamente al NIC sus paquetes para intentar burlar al firewall. Para hacer esto envía diferentes tipos de paquetes de diferentes tamaños, protocolos y tipos. Utiliza las librerías de Winpcap, en teoría el programa copia los archivos necesarios (que son dos) por si mismo sin necesidad de reiniciar el equipo.
Significado
Si la prueba es exitosa significa que el firewall se atasca en el nivel alto de la red y no vigila el bajo nivel.

XSS

Bien, pues ahora que estoy haciendo el servicio social como tramite para la titulación de mi carrera eh tenido que hacer algunas investigaciones, que planeo publicar aquí y en Wikipedia, ya que algunos temas no son tan comunes, y otros son muy comunes, pero casi todo esta en ingles, y lo que hay en español esta algo confuso.

Así que empecemos con la mas extensa XSS

Los sitios Web de la actualidad son más complejos que nunca, contienen una gran cantidad de contenido dinámico, haciendo que la experiencia del usuario sea más agradable. El contenido dinámico se logra a través del uso de aplicaciones Web que pueden enviar diferentes salidas a sus usuarios dependiendo de su configuración y necesidades. Los sitios dinámicos sufren de una amenaza que no afecta a los sitios estáticos, llamada Cross Site Scripting (XSS)

Este tipo de ataques se hacen cada vez más populares entre los hackers ya que es relativamente sencillo encontrar agujeros que permiten explotar esta vulnerabilidad Cada mes se descubren entre 10 y 25 agujeros XSS en productos comerciales.

Los sitios Web que utilizan SSL (para https) NO tienen mayor protección que aquellos sitios que carecen de esta protección, ya que las aplicaciones Web trabajan de la misma manera que antes, excepto que el ataque se realiza en una conexión cifrada.

Es una vulnerabilidad que muchos desarrolladores dejan pasar por alto, quizás por falta de un planeamiento de análisis de riesgos en el proceso de diseño, desarrollo e implementación de sus aplicativos, o simplemente no lo vean como una falla que les va a presentar problemas en su aplicación, incluso por desconocimiento de esta vulnerabilidad.

Sea cual sea el motivo por el cual no se ejecuten medidas de prevención con respecto a esta vulnerabilidad, es necesario saber, que es un tipo de ataque que se extiende cada día mas, hoy en día es muy común encontrar sitios y usuarios afectados por este tipo de agresión. Sitios como FBU.gov, CNN.com, Time.com, Ebay.com, Yahoo, entre otros han tenido una forma u otra de vulnerabilidades XSS. En los últimos meses, en México, se detecto esta vulnerabilidad en los routers del mayor proveedor de Internet de México, Telmex, que permitió redireccionar a los usuarios de cierto portal bancario.

Para ejecutar este tipo de ataque no es necesario ser un guru en el campo de la programación, ni desarrollar o utilizar herramientas complejas, basta con manejar un poco de las etiquetas de HTML y algún lenguaje de Scripting.

La clave primordial en el campo de la seguridad es no confiar en la entrada de datos de ningún usuario, ya que en algún momento estas entradas se puede convertir en una inserción de código malicioso, es por ello que la aplicación debe de validar cada uno de los campos en donde el usuario pueda o le sea requerido el ingreso de datos y dejar de lado la política de confianza al usuario.

Definición de Cross-Site-Scripting

El Cross-Site-Scripting es una vulnerabilidad que aprovecha la falta de mecanismos de filtrado en los campos de entrada y permiten el ingreso y envió de datos sin validación alguna, aceptando el envió de scripts completos, pudiendo generar secuencias de comandos maliciosas que impacten directamente en el sitio o en el equipo de un usuario. El Cross-Site-Scripting es una vulnerabilidad que puede causar un impacto tanto a una aplicación web como a usuarios que de manera inconsciente activen dicha secuencia de comandos.

Ocurre cuando la aplicación web acepta datos maliciosos de un usuario. Estos datos son por lo general enviados a través de un hipervínculo que contiene el código maligno. El usuario puede hacer clic en un enlace desde otro sitio Web, un mensajero instantáneo o simplemente al leer un tablero de mensajes o un e-mail. Usualmente el atacante cifrara la porción dañina del link en código HEX (o con algún otro método de cifrado) así que la petición se ve menos sospechosa para los usuarios. Después de que la información fue recabada por la aplicación Web, se crea una página de salida para el usuario que envió el código, pero de manera que parece la página válida del sitio. Muchos foros y libros de visitas permiten a los usuarios publicar entradas con html y javascript en él.

Un atacante puede usar XSS para enviar scripts maliciosos a un usuario ingenuo. El navegador del usuario no tiene forma de saber que no debe confiar en un determinado script y lo ejecutará. Ya que piensa que viene de una fuente confiable, pudiendo acceder a los cookies, tokens de sesión o cualquier información retenida por el navegador y que es usada por el sitio. Los scripts pueden incluso reescribir el contenido de la página.

Los ataques XSS son divididos por lo general en dos categorías: almacenados y reflejados. Los ataques almacenados son aquellos donde el código inyectado se almacena permanentemente en el servidor, como en una base de datos, en un foro de mensajes, libros de visita, etc. Los ataques reflejados se refiere a aquellos donde el código inyectado es reflejado por el servidor Web, como en un mensaje de error, o en los resultados de una búsqueda. Estos ataques son enviados a la victima usando otras vías como un e-mail, o algún otro servidor Web. Cuando un usuario cae en la trampa el código inyectado viaja al servidor Web vulnerable, que a su vez refleja el ataque hacia el navegador del usuario. El navegador ejecuta el script, ya que viene de un servidor “confiable”.

¿A quien Afecta?

El Cross-Site-Scripting es una vulnerabilidad que puede causar un impacto tanto a una aplicación web como a usuarios que de manera inconsciente activen dicha secuencia de comandos. Dicho código malicioso se compone de cadenas de datos cuyo contenido son scripts completos contenidos en enlaces o ejecutados desde formularios.

En caso de que sea ejecutado el script se ejecutara en el equipo del usuario con todos los privilegios permitidos por las políticas de seguridad configuradas en el navegador del usuario o del sitio visitado, pudiendo realizar acciones diversas como la captura de cookies de usuario o la activación de servicios y componentes del sistema operativo del usuario victima.

La mayor problemática es que estas cadenas de código se encuentran ocultas a la sombra de vínculos, de los cuales, el usuario normalmente no revisa el código y lo ejecuta con una política de confianza total, dicha ejecución se realiza de una manera indirecta, ya sea por una activación vía hipervínculo o por la ejecución al momento de la carga de un sitio afectado por este tipo de ataque, el atacante no realiza su acción pensando en un usuario en especifico si no que actúa de manera de que afectan a cualquier usuario que inocentemente caiga en dicha trampa, las formas mas comunes de realizar dicha agresión es por medio de correos electrónicos, vínculos falsos o ataques directos a sitios no preparados para este tipo de ataque.

Podemos encontrar una clasificación simple:

1. Ataque al usuario.

2. Ataque al Aplicativo.

Ataque al Usuario

Este es el ataque mas frecuente, debido al potencial de la información que se puede obtener mediante este tipo de agresión, ya que dependiendo del nivel de ingenio del atacante puede obtener información importante de un usuario victima extrayendo sus cookies y consiguiendo información almacenada en ellas o robando su sesión de usuario en un sitio web especifico.

Dentro de las diversas formas de ataque veremos dos de las más comunes.

Ataque vía correo electrónico:

Se basa en el envió de un correo electrónico a un usuario con un script oculto en un link a una dirección web, el atacante buscando motivar a su victima a seguir el enlace le ofrece un premio, regalo u oferta si visita dicho vinculo, al verse atraído por la información en el correo electrónico el usuario hace clic en el vinculo sin darse cuenta de que esta activando una secuencia de comandos que se ejecutaran en su equipo local, que podrían extraer sus cookies, eliminar archivos y en el caso mas fatal formatear su disco duro, mediante la invocación de programas con parámetros aleatorios.

Ataque vía publicación en Sitios Vulnerables:

Esta segunda forma se basa en la publicación de datos en blogs, foros, libros de visitas o sitios que permiten reflejar información enviada por un usuario y que no es validada por el servidor, donde podremos esconder secuencias de comandos detrás de un vinculo o imagen, este ataque tiene la misma finalidad que el anterior, pero con un mayor alcance de usuarios afectados.

Esta vulnerabilidad puede estar de forma directa (foros, mensajes de error, etc) o indirecta (redirecciones, frame sets, etc)