Probando nuestro firewall

Hace ya mucho tiempo escribí en este blog un artículo sobre la herramienta hping3 en el que hablaba de como falsificar la dirección IP desde la que se enviaba un paquete a través de la red. Dada la gran versatilidad de esta herramienta hoy os voy a hablar de otra de las tareas para las que se suele utilizar esta herramienta, en este caso, probar las reglas de nuestro firewall.

Una parte muy importante del bastionado de nuestros sistemas, es la de que nuestros firewall estén bien configurados para, de esta forma, solo permitir el acceso a aquellos servicios que nosotros ofrecemos al exterior e impedir el acceso a todo lo demás. Para esto, lo más habitual suele ser tener extensas (o no tan extensas) listas de reglas a aplicar en nuestro firewall. Después de aplicar estas reglas un paso básico, muchas veces olvidado, debería ser el de probar estas reglas, ya sea por despiste, descuido o por la existencia de otras reglas en conflicto, muchas veces nos podemos llevar desagradables sorpresas que no queremos que sea un cliente quien nos notifique o peor aún, que lo descubramos tras el resultado de un ataque.

En este escenario en el que necesitamos probar las reglas dadas de alta en nuestro firewall es cuando la herramienta hping3 nos puede ser de gran utilidad, ya que nos permite crear paquetes de diferentes tipos para poder probar nuestras reglas.

En general, en el artículo, estoy hablando de probar las reglas de un firewall, pero también nos puede servir en el mismo modo para probar nuestros sistema IDS (Intrusion Detection System). Pero bueno, en el ejemplo que voy a poner a continuación, nos vamos a centrar en la prueba de una regla del firewall.

Para ver la información general sobre el comando, bastará con ejecutar en la consola el comando:

hping3 -h

Este nos mostrará las diferentes opciones de las que disponemos.

A modo de resumen y que nos sean útiles para este artículo, tenemos:

Definir protocolo

No.    Abrev.    Largo            Descripción
0                                           Por defecto se envía un paquete TCP
1        -0           –raw-ip         Envía paquetes RAW IP
2        -1           –icmp           Envía paquetes ICMP
3        -2           –udp             Envía paquetes UDP
4        -8           –scan           Establece el modo escáner
5        -9           –listen          Establece el modo escucha

Paquetes TCP

No.    Option    Flag name
0                       Paquete TCP por defecto
1        -S           syn
2        -A           ack
3        -R           rst
4        -F           fin
5        -P           psh
6        -U           urg
7        -X           xmas: flags fin, urg, psh set
8        -Y           ymas

 

Pero bueno, vamos a empezar con un pequeño ejemplo. Yo para las pruebas he utilizado una máquina virtual con linux en la que he definido las siguientes reglas en el firewall:

  • Aceptar paquetes TCP al puerto 22 (SSH).
  • Denegar todo lo demás.

Tras esto, vamos a probar la regla:

Primero probaremos el caso que debería funcionar. Para ello mandaremos un paquete TCP SYN al puerto 22:

hping3 192.168.1.82 -c 1 -S -p 22

Esto nos tendría que devolver que nuestro paquete ha sido recibido

Ahora vamos a probar los casos en los que deberíamos ser rechazados.

Primero probaremos con un mensaje ICMP:

hping3 -1 192.168.1.82 -c 1

Tras ejecutarlo, deberíamos ver que nuestro paquete se ha perdido.

El siguiente paquete que debería ser rechazado que vamos a probar es un paquete como el TCP pero utilizando UDP:

hping3 -2 192.168.1.82 -c 1-S -p 22

Como vemos, si todo ha ido bien con nuestra nueva regla, este paquete es rechazado también.

En este sentido, podemos crear y probar tantas reglas como queramos, incluso podemos crear nuestros propios scripts para probarlas teniendo scripts para diferentes configuraciones o entornos.

Bueno, hasta aquí hemos llegado, el ejemplo ha sido bastante simple, pero creo que tenéis la suficiente información como para lanzaros a jugar un rato con hping3 y a utilizarlo seriamente. Nos vemos.

Probando nuestro firewall

SGSI: Sistema de Gestión de Seguridad de la información

Ya sabéis que no me suele gustar poner directamente enlaces de contenido sin al menos analizarlo o hablar de él, pero la verdad es que hoy he estado viendo un interesante curso / manual / material sobre SGSI publicado por INTECO. Así que como me ha gustado bastante os dejo el enlace aquí. Ya hablaremos algún día sobre todo este tipo de cosas, pero al menos, como pequeña introducción me ha parecido muy útil e interesante.

SGSI: Sistema de Gestión de Seguridad de la información

Nos vemos.

SGSI: Sistema de Gestión de Seguridad de la información

Detectando Sniffers

Una de las herramientas más utilizadas en el campo de la seguridad y de la administración de sistemas es el “Sniffer”. Para el que no lo sepa, un sniffer es una herramienta de monitorización de redes y captura de paquetes que circulan por dichas redes.

Este tipo de herramientas nos permiten:

– Analizar el tráfico de una red: Congestión, cuellos de botella, intrusiones, …

– Detectar fallos de paquetes: Paquetes corruptos, duplicados, errores de sincronización, …

– Nos permiten realizar filtros para analizar nuestro tráfico.

– Creación de estadísticas del tráfico.

– Capturar datos que circulan por la red tanto cifrados como sin cifrar.

Para poder ejecutar este tipo de herramientas se necesitan permisos de administración en una máquina, con lo cual son utilizadas por administradores de red para supervisar estas.

El problema es que igual que las pueden utilizar usuarios autorizados, pueden ser usadas por usuarios no legítimos que han accedido a nuestra red, o que utilizan de forma autorizada nuestra red, pero no deberían tener permisos de administración.

El sniffer es un herramienta que actúa en modo pasivo con lo cual no es fácil detectar la existencia de uno de ellos en nuestra red, ya que la única señal que deja visible es la activación del modo promiscuo de la tarjeta de red en el equipo donde se usa.

En el presente post vamos a intentar conocer algunos métodos que pueden ser utilizados para detectar estos sniffers en nuestras redes.

El primero de los métodos es el más rudimentario y menos técnico de todos, pero para redes pequeñas (quizás 4 o 5 equipos) en las que tengamos acceso físico o remoto a las máquinas puede servir. Es simplemente listar los procesos que se están ejecutando en cada una de las máquinas y ver que encontramos. Otra de las formas mediante el mismo método sería consultar el registro a ver si existen sniffers instalados en la clave “HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft”. Obviamente, este método no es muy efectivo, ya que en mayor medida depende del conocimiento que el administrador tenga sobre los varios sniffers existentes. Además, pueden ser sniffers caseros, o desconocidos, con lo cual serían más difíciles de detectar.

El segundo método, ya más técnico consiste en hacer pruebas mediante paquetes ICMP, ya sabéis, el típico ping. Para llevar a cabo este método realizaríamos un  ping a la máquina que queramos probar, tras esto, generaríamos gran cantidad de tráfico TCP en la red en poco tiempo y volveríamos a realizar el ping a la misma máquina. Si entre las latencias de respuesta de uno y otro hay mucha diferencia (3ms frente a 20ms por ejemplo), podemos estar casi seguros de que hay un sniffer activado. La diferencia de latencias se debe a que el equipo está procesando todas las conexiones TCP y no ha podido responder inmediatamente al ping.

El tercer método, es la utilización de ARP’s. Este método consiste en hacer un ping a una dirección IP que queramos, pero con una MAC incorrecta. Para esto, podemos añadir una entrada en la tabla ARP con la IP correcta y una MAC incorrecta. Al ser la dirección MAC incorrecta, el paquete no debería llegar a su destino, pero en algunos sistemas, si hay un monitor de red activado, el sniffer atenderá el paquete y enviará una respuesta.

El cuarto y último método que vamos a ver es el de pruebas de DNS. Algunos sniffers, realizan búsquedas inversas de DNS, es decir, dada una IP, intentan averiguar el nombre de dominio al que corresponde, y nosotros podemos utilizar esta característica para localizarlo. El método consiste en crear una gran cantidad de tráfico TCP con peticiones de dominios que no existan obligando al sniffer a realizar peticiones de resolución de IP y dominio. De esta forma solo tendremos que ver cual de nuestras máquinas es la que realiza estas peticiones de resolución, y así, sabremos en cual está el sniffer.

Evidentemente, existen varias herramientas que se encargan de implementar todos estos métodos de forma automática, como serían:

– Antisniff: Creada tanto para Windows como UNIX. Esta herramienta se encarga de probar si alguno de los dispositivos de la red está en modo promiscuo. Implementa el segundo, tercer y cuarto métodos vistos anteriormente.

– Sentinel: Herramienta de funcionamiento muy similar a Antisniff que utiliza las librerías libpcap y libnet. Implementa el segundo, tercer y cuarto métodos vistos anteriormente.

– CMP: Otra herramienta que se encarga averiguar si hay máquinas en modo promiscuo en nuestra red.

– NEPED: Herramienta que implementa el tercer método visto más arriba.

– SniffDet: Otra herramienta similar a Antisniff y Sentinel.

Bueno, hasta aquí todo lo relacionado con la detección de sniffer en nuestras redes. Buscando algo de información sobre las herramientas he llegado a una página del dominio maestrosdelweb que me ha parecido muy interesante, así que os dejo el enlace aquí. Hace un poco menos referencia a explicaciones teóricas, y un poco más a las herramientas que el presente artículo, así que lo he visto como un buen complemento.

Espero que os sea de utilidad artículo, y ya sabéis, animaos a dejar dudas y comentarios. Nos vemos.

Detectando Sniffers

Fases de un test de penetración

Personalmente, no me dedico aunque me gustaría al mundo de la seguridad, las auditorías o los test de penetración. Más bien soy un aficionadillo al que de vez en cuando le dejan algún servidor de verdad en el que jugar un rato, y por supuesto, practico todo lo que puedo en entornos que me monto yo, o que haya por ahí en Internet.

Una de las cosas que no te planteas cuando haces las cosas así, es decir, sin normas, sin restricciones, sin tener que entregar informes a nadie, ni formalizar los resultados, es el utilizar una metodología concreta e inflexible que le de mayor fortaleza a tus resultados.

Algunas de estas metodologías que existen al alcance de todo el mundo son, la que lleva a cabo el proyecto OWASP y la OSSTMM, pero en general, hoy, voy a describir las fases habituales que debería seguir, a mi entender, cualquier ataque que tengamos que hacer de una forma más formal que el típico “solo por aprender”.

Lo vamos a dividir en cinco fases:

–       Fase de recopilación de información: En ella utilizaremos los buscadores, herramientas de análisis de DNS, whois y demás herramientas para obtener información de nuestra victima. Además, podemos hacer una exploración de metadatos de los documentos, imágenes y otros tipos de archivos que tengamos a nuestro alcance navegando.

–       Fase de enumeración: En ella trataremos de conseguir direcciones IP de nuestra victima, nombres de usuarios y contraseñas válidas de su entorno y nombres de servicios y aplicaciones accesibles, y todo aquello que luego nos pueda ayudar a lanzar nuestro ataque. Dejar claro que esta fase al igual que la primera, solo es de investigación, no se llevará a cabo ningún ataque, será más bien la realización de un checklist de elementos existentes.

–       Fase de análisis: En ella empezaremos a actuar sobre los sistemas encontrados, los analizaremos en busca de vulnerabilidades, ya sea en la infraestructura, los sistemas operativos, los servicios disponibles o las aplicaciones existentes.

–       Fase de explotación: En esta fase realizaremos la intrusión en el sistema y obtendremos evidencias de nuestra intrusión para la posterior documentación o la demostración de que hemos realizado la intrusión.

–       Fase de documentación: En esta fase plasmaremos de forma entendible y accesible todos nuestros descubrimientos. Lo de entendible y accesible, es porque luego nuestros resultados probablemente den muchas vueltas por despachos y caigan bajo los ojos de gente que no tiene porque tener un perfil técnico. Registraremos todo lo que hemos descubierto sobre los sistemas, realizaremos informes de nuestras intrusiones y las evidencias de estas, realizaremos una presentación concisa y resumida de resultados, y señalaremos aquellos puntos que creamos que requieren especial importancia o que provocan los problemas más graves o inmediatos.

Ni que decir tiene que como consejo os recomiendo escribirlo todo conforme vayáis haciéndolo. Primero por si rompéis algo, segundo para que los resultados sean reproducibles,  y tercero porque si tenéis que desandar vuestros pasos os será muy cómodo tener por escrito lo que habéis hecho.

Obviamente todo lo que aquí he comentado no es más que una generalidad, os recomiendo que acudáis a las metodologías antes nombradas para ver todo esto aplicado y explicado mucho más ampliamente.

Como siempre, para dudas, comentarios, o críticas constructivas, os animo a comentar y hacer del blog un pequeño foro de discusión. Nos vemos.

Fases de un test de penetración

Características de un servicio de seguridad

Hoy en día casi todo aquel que se dedica mínimamente al mundo de la seguridad o que tiene alguna relación con él, sabe que la seguridad sirve para proteger. Que para esto tenemos que implementar mecanismos de acceso, control, registro, …

Pero muchas veces cuando en entrevistas de trabajo, conferencias o entornos más serios (no, no me refiero a charlas tomando unas cervecitas) hace falta conocer los términos con los que referirse a esta “protección”. Por eso, hoy vamos a tratar de comentar formalmente que características debe tener un servicio de seguridad.

Identificación – ¿Quién es? Para todos los usuarios que quieran acceder a nuestros sistemas o instalaciones, tenemos que tener una forma de identificación que no de lugar a dudas de quien es el que está accediendo. Por ejemplo, nombres de usuario, DNI, tarjetas cifradas, …

Autenticación – ¿Es quien dice ser? A pesar de que alguien tenga unos credenciales válidos hay que comprobar que realmente son suyos. Se puede hacer por ejemplo, con contraseñas, envíos de SMS, certificados, …

Una de las cosas que se está proponiendo o intentando llevar al campo de la seguridad es identificar a alguien mediante “lo que es” (biometría), “lo que tiene” (móvil, tarjeta) y “lo que sabe” (algún tipo de pregunta).

Autorización – A pesar de que el usuario o persona pueda acceder a nuestros sistemas o zonas, no quiere decir que este pueda hacer todo lo que quiera, deben existir permisos y perfiles para actuar. Un amigo mío, decía que la mejor forma de saber que permisos necesita algo es no darle ninguno e ir dándoselos conforme aparecen cosas que necesita hacer y no puede. Quizás esto sea algo exagerado, pero si que esta bien tener perfiles para los diferentes usuarios.

Confidencialidad – Hoy en día los diferentes sistemas son utilizados por muchas personas, muchas de ellas ni siquiera tienen porque conocerse, y desde luego nuestros sistemas no tienen que ayudarles a que sepan de otras personas. Aquí es donde entra en juego la criptografía, las barreras físicas, la separación lógica de redes, …

Integridad – Cualquier acción que un usuario genere solo debe afectar a aquellas partes del sistema que esta previsto y a nada más. No deben haber acciones colaterales imprevistas. El sistema debe ser robusto. Y por supuesto, ningún usuario no autorizado podrá interferir o modificar las acciones de otro.

No repudio – Todas las acciones llevadas a cabo por un usuario deben quedar registradas en sistema, para poder identificarlas con posterioridad (usuario, acción, línea temporal). Existen procedimientos judiciales que se deben seguir para usar luego esta información como pruebas y existen técnicas de análisis forense que nos pueden salvar de más de un buen susto si todo está correctamente registrado.

Bueno, espero que os sirva de algo todo esto. Como siempre, si alguno tiene algún apunte que hacer o comentario que se anime. Nos vemos.

Características de un servicio de seguridad

Ejecutando código mediante LFI

Continuando un poco más con el tema de LFI que introdujimos ayer, vamos a ver ahora como es posible aprovechar esta vulnerabilidad para ejecutar código en el servidor donde se aloja la página vulnerable.

Para hacer esto vamos a insertar código en una imagen que subiremos al servidor mediante los mecanismos legítimos que nos ofrece la página web y después procederemos a ejecutarlo aprovechando la vulnerabilidad LFI comentada ayer.

Pero vamos a entrar en materia.

Lo primero será hacernos una imagen con el código que queremos ejecutar. Para este caso, la imagen será cualquiera que os guste y tenga formato de avatar (algo en .jpeg de pequeño tamaño) y el código de prueba será el siguiente:

<?php

phpinfo();

?>

El segundo paso será incrustarlo en una imagen. Existe varios programas que hacen esto, tanto para Windows como para Linux, pero para el caso yo voy a utilizar una herramienta básica que viene en la consola de Linux, “cat”. Utilizaremos el comando como se especifica a continuación:

cat codigoPhp.txt >> imagen.jpg

Para comprobar que todo ha ido bien, podéis hacer un cat de la imagen y veréis el código incrustado al final de esta.

Ahora procederemos a subir la imagen a la página afectada, por ejemplo, en el caso de un foro la subiremos como avatar, en el caso de otro tipo de páginas pues como parte de un mensaje o como se permita. Hoy en día muchas páginas permiten la subida de imágenes.

Finalmente el último paso es utilizar la vulnerabilidad para invocar este fichero, generalmente situado en “img/” o “images/” o similares y ver que pasa. Si tenemos éxito podremos observar la información sobre PHP de dicho servidor.

Una posible solución a esto es la siguiente (Sacada del manual de php.net):

$path = basename($page, 'php') . '.php';

if(file_exists($path))

     include $path;

Nos vemos.

Ejecutando código mediante LFI

LFI

Hoy vamos a hablar en concreto de un tipo de ataque contra servidores web, en concreto vamos a hablar de LFI (Local File Inclusion).

El objetivo del ataque es visualizar ficheros localizados localmente en dicho servidor. Por ejemplo, el “/etc/passwd, o ficheros similares que puedan ser de nuestro interés para profundizar en otro tipo de ataques.

El fallo se produce porque en el código de la página web que vamos a utilizar como trampolín para el ataque aparece algo similar a esto:

pagina.php

<?php
$pagina = $_GET(‘pagina’);
include($pagina);
?>

Como se puede ver el código recibe como parámetro a través de la URL un nombre de página e incluye esta para su visualización. Añadir que también se puede hacer esto a través de parámetros recibidos por peticiones POST, pero por no liar al lector, en este artículo solo veremos peticiones recibidas por GET (más adelante se escribirá el de peticiones POST).

Una vez que hemos descubierto que una página tiene un posible LFI, vamos a proceder a probarlo a ver si tenemos éxito.

En primer lugar tenemos la petición original, que sería de la siguiente forma:

http://www.example.com?pagina=paginaParaInclude

Para poder sacar provecho de esto la petición que nosotros vamos a inyectar será del siguiente tipo:

http://www.example.com?pagina=../conf/httpd.conf

Con esto estaremos solicitando que se muestre el fichero de configuración del servidor.

Ahora con un par de pruebas podremos llegar a ver ficheros mucho más interesantes alojados en servidor.

Espero que os sirva para practicar un poquito y hacer un poco más seguros vuestro código o vuestros servidores. Como siempre, os animo a preguntar dudas o hacer comentarios. Nos vemos.

LFI

OWASP Top 10

El proyecto OWASP publicó el día 19 de Abril la versión final de su documento “The Ten Most Critical Web Application Security Risk”, o lo que viene a ser lo mismo, un listado de los diez errores más importantes en aplicaciones web. El documento lamentablemente está en ingles, pero bueno, nada a lo que no estemos acostumbrados, además, no es muy extenso.

El documentos nombre los diez errores, en que consisten y como solucionarlos.

Desde luego un documento muy interesante y que merece la pena leer. Os dejo el enlace a la página del proyecto OWASP correspondiente y ademas los enlaces directos al documento.

Página del proyecto OWASP, categoría “Top Ten

OWASP_Top_10_-_2010.pdf (Google Code)

OWASP_Top_10_-_2010.pdf (Google Docs)

Espero que os sirva. Nos vemos.

OWASP Top 10

SecurityTube

Hablando últimamente con gente a mi alrededor, me ha sorprendido que nadie conocía la página SecurityTube. Es una página al estilo Youtube pero enfocada a seguridad y programación. Está claro que no va a ser la panacea ni nada por el estilo, pero tiene algunos vídeos interesantes. Si tenéis un ratillo, os recomiendo que le echéis un vistacillo aunque sea por curiosidad, quizás encontréis algo que os sirva.

Un saludo. Nos vemos.

SecurityTube