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.

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.

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.

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.

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.

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.

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.

Presentaciones Rooted CON

Supongo que como la mayoría sabréis, los días 18, 19 y 20 de Marzo de este año, tuvo lugar en Madrid (España) la Rooted CON. Para todos aquellos que no pudisteis asistir, aquí os dejo un enlace a las presentaciones que se pudieron ver allí.

Presentaciones Rooted CON

Yo personalmente no pude estar, así que ya tengo algo que mirarme estos días. Un saludo a todos. Nos vemos.

Empezando a practicar

Hola todos, hoy vamos a hacer un post un poco diferente. Lo normal suele ser que escriba un post sobre alguna herramienta o similar sobre la que hemos aprendido su uso básico, pero en esta ocasión, lo que os propongo son varios entornos sobre los que probar un poco vuestras habilidades de pentesting de forma legal. Así que como se suele decir, “A andar se aprende andando“, pues vamos allá.

La primera página esta más enfocada a los test de penetración de servidores. La página, o mejor dicho el proyecto provee de imágenes de sistemas montados con determinados servicios levantados y, de forma deliberada, estos sistemas son vulnerables. La idea es encontrar y explotar estas vulnerabilidades. La página del proyecto es Sec-track donde podéis encontrar los entornos:

- De-Ice I

- De-Ice II

- De-Ice III

Personalmente me están gustando mucho. Están ordenados por orden de dificultad, así que os recomiendo empezar por el primero y continuar después con los otros dos. Además, como veréis cuando lleguéis a la página, existe una gran cantidad de material que podéis ojear e investigar.

La segunda recomendación de hoy es un blog que está en mi blogroll, y que además de ser un excelente blog, con unos contenidos muy interesantes, aunque un poco pro-microsoft (maligno, sin mala intención eh), tiene una sección de retos muy interesantes. Están enfocados a la pentesting de webs. Me parecen unos retos excelentes donde poder practicas. La dirección del blog es esta: Un informático en el lado del mal, y los retos los podéis encontrar en el menú de la izquierda, en su parte inferior.

A disfrutar y practicar. Espero que los retos y entorno os gusten tanto como me están gustando a mi y que aprendáis mucho, que la teoría está muy bien, pero siempre es más entretenido practicar. Nos vemos.

Cambiando nuestra MAC

Como la mayoría sabréis, las tarjetas de red tienen asociado un número MAC que las identifica, y que a su vez identifica la máquina en la que está. Sino cambiamos la tarjeta de ordenador claro.

Una de las ventajas de existir este número es que podemos hacer filtrados en nuestra red con su ayuda, ya que nosotros conocemos esos números y el resto de gente a priori no. Por ejemplo, aunque siempre acompañado de otros métodos, podemos restringir la función de nuestro servidor DHCP a la hora de suministrar IP’s. Si no se reconoce la MAC, no se le da IP o, en entornos donde hace falta que las máquinas mantengan una misma IP, se les puede asignar estas en función de su MAC.

Ahora seguro que os estaréis preguntando – y si es tan útil, ¿para que quiero cambiarla? Os voy a proponer un par de ideas y a partir de aquí ya lo dejaré a vuestra imaginación.

Pongamos por ejemplo que un día tenemos que enganchar nuestro portátil a una red donde solamente se dan IP’s a unas MAC concretas. Al enchufar el portátil no obtendríamos IP con lo cual no podríamos conectar. Una forma de poder hacer esto sería asignando al portátil una MAC que no este en uso en ese momento y que sepamos que pertenece a la red.

Otro ejemplo sería, por ejemplo, el tener una máquina para gestionar las reglas de un Firewall, de modo que solo desde esa máquina con una MAC concreta podamos modificar dichas reglas. Ahora bien, esa máquina, por lo que se deja de estar operativa, con lo cual dejaríamos de poder gestionar nuestro Firewall. La solución, sería tan fácil como modificar la MAC de otro máquina para poder administrar desde ella. Para mas ideas como ya he dicho, os lo dejo a vosotros.

Vamos a ello. El primer método que vamos a ver es para hacerlo manualmente y que el resultado dure durante la sesión. Como siempre, yo lo voy a hacer sobre Ubuntu, aunque esto es aplicable a todos los sistemas adaptando el procedimiento al sistema sobre el que queramos realizar el cambio.

¿Cuál es mi MAC? Para averiguarla bastará con ejecutar la instrucción:

# ifconfig

La cual nos mostrará algo como esto:

Link encap:Ethernet  direcciónHW 12:34:56:78:90:AB

…

La cadena con el siguiente formato es la dirección MAC: xx:xx:xx:xx:xx:xx

Para cambiarla, lo primero que tendremos que hacer es tirar abajo el interfaz de red del cual queremos cambiar la dirección MAC, en nuestro caso “eth0”:

# ifconfig eth0 down

Tras esto asignaremos una nueva dirección MAC a este interfaz:

# ifconfig eth0 hw ether 00:00:00:00:00:00

Y volveremos a levantar nuestro interfaz:

# infonfig eth0 up

Con esto tendremos nuestra dirección MAC cambiada.

Recordemos algo muy importante, las direcciones MAC siguen un sistema de numeración hexadecimal. Ya sabéis de [0 – F]

Pero claro, si queremos que este cambio permanezca en el sistema a pesar de reiniciar o apagar la máquina, tendremos que escribir esto en algún sitio. Y ese sitio es el fichero /etc/init.d/bootmisc.sh.

En el, tras abrirlo, escribiremos en el final de este, las tres instrucciones que hemos ejecutado manualmente antes. De esta forma el cambio será permanente mientras no las borremos del fichero.

Con esto tendremos una dirección MAC a nuestro gusto. Por Internet podéis buscar direcciones de MAC más o menos reales, ya que los primeros números de las tarjetas identifican el vendedor y está información está al alcance de todo el mundo.

Así como apunte rápido y para aquellos que utilizáis máquinas virtuales, no es necesario que hagáis nada de lo anterior, ya que en la configuración de estas, normalmente da la opción de asignar una dirección MAC.

Como siempre, animaros a preguntar y comentar si tenéis alguna duda, o por ejemplo, si se os ocurren más caso para los cuales sería interesante cambiar la dirección MAC. Eso si, legales por favor. Nos vemos.