Daboweb | Seguridad y ayuda informática | Cibercultura » Seguridad Informática

Comprueba si el password de tu Router ADSL es visible vía web

Dabo — Sun, 12 Feb 2012 02:08:29 +0000

Se están reportando por la red desde diferentes medios, la posibilidad de que algunos Routers ADSL (sobre todo de Telefónica) podrían estar afectados por una vulnerabilidad que revela en texto plano la contraseña de administración del dispositivo, con las consecuencias que este hecho podría tener.

De hecho, ya se sabe de routers que están siendo usados como “pasarela” para realizar todo tipo de ataques hacia otros sistemas, siendo en ese caso sin saberlo, parte de una “botnet” o red troyanizada y controlada por terceros.

El problema viene dado por la opción de administración remota vía web (WAN) del Router. Tal y como informan desde INTECO, el método para saber si efectivamente tu Router es vulnerable, es navegando a cualquier servicio que te muestre la IP pública de tu sistema (por ejemplo desde What is my IP) y una vez hecho, hay que teclear en el navegador web: http://tu-ip-pública/password.cgi

Caso de que se vea tu contraseña, obviamente el Router es vulnerable y hasta que no haya alguna alguna actualización de firmware por parte del fabricante u otra solución, hay que desactivar en el dispositivo esa opción.

* Nota del redactor; En el momento de escribir estas líneas, mi Router, un Comtrend MULTI-DSL CPE de Jazztel no es vulnerable.

Publicado en Daboweb, Enero de 2012

Redacción — Thu, 02 Feb 2012 12:02:00 +0000

Un mes más, os recomendamos el recopilatorio de entradas publicadas en Daboweb en Enero de 2012 por si en el día a día de la publicación alguna que pudiera interesarte, se te ha pasado por alto.

Todos los comentarios los vamos recogiendo en el foro de noticias que hemos creado para opinar sobre ellas. También te invitamos a participar en nuestros foros para exponer tus dudas o ayudar a despejar las que tengan otros. (Te recomendamos ver nuestro archivo de contenidos publicados).

Enero 2012;

Problema de seguridad en sudo

vlad — Tue, 31 Jan 2012 17:25:29 +0000

A través de Hispasec nos enteramos de la detección de un fallo de seguridad que afecta a varias distribuciones linuxeras que hacen uso del comando sudo para ejecutar aplicaciones o tareas de mantenimiento como otro usuario o como administrador del sistema. Concretamente la vulnerabilidad radica en un error de formato de cadena en la función “sudo_debug de sudo.c” cuando procesa el nombre del programa que se le pasa por parámetro.

Un usuario malintencionado podría realizar un enlace a nivel de sistema de ficheros del binario del comando sudo hacia un archivo, con un nombre manipulado y que contuviera caracteres especiales de cadena. Cuando ejecutase ese nuevo enlace lo haría con privilegios de root. Este problema no solo afecta a GNU/Linux, sigo que sistemas operativos también basados en UNIX, como BSD o Mac también se han visto afectados. Se ha publicado un parche que lo soluciona.

Herramientas para la interpretación de capturas de red. (9/10) Parte 2

Alfon — Thu, 26 Jan 2012 17:31:55 +0000

En anteriores entregas:

Afterglow, InetVis, TNV, Argus, INAV.

Seguimos con las herramientas que nos proporcionarán una visión gráfica de nuestras capturas. En esta Parte 2 vamos a ver InetVis.

InetVis es una herramientas diferente ya que la representación gráfica del tráfico de red se realizará a través de una representación tridimensional 3D mediante un cubo. Lo vemos…

Qué es InetVis.

InetVis está basado en el concepto de Spinning Cube of Potencial Doom. Se trata de una herramienta de visualicación tridimensional del tráfico de red que, además, puede visualizarse reproduciéndose a lo largo del tiempo.

Su objetivo principal es el análisis de tráfico anómalo y scan de puertos a través de una serie de patrones.

InetVis está disponible tanto para sistemas Linux como windows y lo podemos descargar desde:

Windows: inetvis/0.9.5/InetVis-0.9.5.1-w32.zip
Linux: inetvis/0.9.5/inetvis-0.9.5.1-linux.tar.gz

En esta ocasión vamos a usarlo desde un entorno Windows.

Introducción a InetVis.

Cuando cargamos InetVis tenemos una ventana de visualización con un cubo que representa lo siguiente:

el eje z en color rojo representa las IP direcciones cuyo origen están en internet.
el eje x en color azul representa para red interna las IP o direcciones de destino.
el eje y en color verde representa los puertos de destino tanto tcp como udp.
el plano inferior en color gris representa el tráfico icmp.

La representación del tráfico de red la realiza a partir de archivos .pcap (.cap).

También a través de la interface de red que tengamos por defecto.

Disponemos, además, de 4 paneles / ventanas:

ventana de visualización: visualización gráfica del tráfico
panel de control: para reproducir el tráfico, escalas de tiempo y filtros BPF.
plotter setting: para establecer rangos de red local y externa (internet). Rangos de puertos y esquemas (luego lo veremos)
reference frame setting: opciones de visualización del cubo, tamaños e los puntos, etc.

Los abriremos todos desde el panel de control > View

Podemos manejar el cubo para ir cambiando de perspectiva principalmente de la siguiente forma:

con el ratón y botón izquierdo para rotar el cubo
con la rueda central del ratón par hacer zoom
con el botón derecho para desplazamientos
Control+l, r, t, b para las vistas.

Hasta aquí una visión muy rápida de la herramienta. El resto lo vamos a ver con ejemplos.

Carga de fichero .pcap y opciones.

InetVis está preparado para grandes archivos de tráfico de red. En mi caso he llegado a cargar archivos de hasta 3 Gb. sin problema alguno. Al principio cuando cargamos un archivo, es posible que nos de un error para avisarnos que tenemos que indicar al menos, el rango de red local. Lo vemos ahora.

El uso de InetVis es muy sencillo. Aquí lo importante es interpretar los datos gráficos obtenidos.

Una vez que cargamos Inetvis nos aseguramos que estamos en el Panel de control en Mode > Replay capture file y cargamos el fichero. También podemos ir directamente a n File > Open. Una vez cargado el archivo .pcap con extensión .cap, es posible que nos salga un error que solo es un aviso para que introduzcamos el rango de red local, así pues, en el panel Plotter Setting > Destination Home Network Range introducimos las datos del rango de red interna o red local. Tenemos que darle al botón OK. (V) para aplicar:

En este mismo panel, y en Color Mapping usamos el schema Destination port. Elegimos el tamaño de puntos (2). suavizado, y fondo negro. Poco más si no queremos establecer rango acotado de red internet.

En Control Panel elegimos escala de tiempo adecuada al tamaño de nuestro fichero .pcap para la velocidad de reproducción y pulsamos a play. También podemos desplazarnos por la línea de tiempo o ajustar time range a un valor mayor para que barra de línea de tiempo se desplaze a mayor velocidad.

En la ventana InetVis Display veremos como, dependiendo del tamaño de fichero .pcap y densidad del tráfico, como se van rellenado de puntos conformando una serie de líneas, agrupaciones de puntos etc, a través de los ejes del cubo. Una vez terminado este proceso podemos comenzar a interpretar los datos obtenidos.

Interpretando los datos.

Ahora vamos a ver unos ejemplo para entender la filosofía y e interpretación de los datos con InetVis. Aunque InetVis está pensado para detectar los potrscan provenientes de la red internet, los ejemplo los voy a realizar dentro de la red local del laboratorio. Una vez entendido su funcionamiento iremos a casos ya reales.

Vamos a usar en el panel Plogtter Setting y Colour Mapping diferentes esquemas de color. Por defecto tenemos Destination port pero si aplicamos Source IP addres vemos lo siguiente:

La fecha y hora que se aprecia arriba se refiere al archivo de captura .pcap.

Vemos, dentro del círculo blanco, una serie de 5 puntos rojos en línea a través del eje z que corresponde a direcciones de origen provenientes de Internet. Como están en línea suponemos que usan el mismo puerto, además es un puerto bajo, son cinco puntos (hosts). Podría ser, de hecho es así, comunicaciones http desde 5 hosts distintos hacia un solo host en la red interna.

Lo más llamativo es una línea vertical a lo largo del eje (y) que corresponde a los puertos de destino. Al ser una línea se trata de un solo host y muchos puertos. La gama de colores (de rojo a amarillo, verde, etc) se refiere al nivel de actividad que supone que los puertos bajos son los más usados y activos. En este caso se están usando como puertos de destino la mayoría de ellos, con lo cual lo tenemos claro, se trata de un scan de puertos. Este patrón siempre se va a repetir para estos casos.

Otro ejemplo para aclarar ideas.

Aquí he acotado el rango de puertos desde el 15000 a 16000 (eje y). Vemos en el eje x (en azul) un solo host de la red interna que tiene tráfico com varios hosts (vemos la distribución de puntos a lo largo del eje z) usando puertos muy cercanos y aproximados a 15600. Si aplicamos el esquema de mapa de color de direcciones IP de origen, se torna de varios colores. Si aplicamos Puerto de destino, se aprecia muy poca variación: desde azul a morado pero poco apreciable (puertos muy consecutivos y cercanos en ango pequeño) Se trata de una comunicación entre un solo host de la red interna con varios hosts de la red internet. Los host internet usando un solo puerto origen y el destino contra host interno a varios puertos. En la imagen de abajo he aplicado el esquema IP origen.

Lo comprobamos:

Patrones de scan de puertos.

Usando scapy.

Vamos a usar para los siguientes ejemplos la herramienta scapy.Podeís ver más sobre scapy aquí: http://seguridadyredes.wordpress.com/category/scapy/

Realizamos un scan de la siguiente forma:

send(IP(src=RandIP('213.96.0.0/16'), dst='192.168.1.5')/TCP(sport=53,dport=(1024,4096)), loop=1)

Construimos y enviamos un paquete IP. Usamos RandIP() para que las IP de origen sean aletorias pero dentro del rango que indicamos. El puerto de origen es el 53 y los puertos de destino serán los comprendidos en el rango 1024-4096. Con loop=1 indicamos que el proceso se realice en un bucle infinito hasta que lo paremos manualmente (Control+Z).

El resultado es:

Lo que vemos es lo siguiente:

el eje de color rojo z que representa las IP direcciones cuyo origen están en Internet está cubierto en todo su rango. Acotando con Inetvis, vemos que el barrido de scan proviene de 213.96.0.0/16.
el eje de color verde y que corresponde a los puertos indica un rango de puertos de destino. En este caso 1024-4096.
si nos situamos perpendicularmente al eje azul x de IP internas, vemos que el objetivo es solo una IP. En este caso 192.168.1.5.

Ahora vemos otro patrón que corresponde a varias IPs de destino de scan de puertos. Lo hacemos de la siguiente forma y usando RandShort() para indicar un puerto aleatorio.:

send(IP(src=RandIP('213.96.0.0/16'), dst=['192.168.1.5','192.168.1.136','192.168.1.92'])/TCP(sport=RandShort(),dport=(1024,4096)), loop=1)

El resultado:

Podéis apreciar las tres bandas indicando 3 IP de destino distintas de la red interna en eje x.

Seguimos con los patrones de distintas configuraciones de scan de puertos. Tenemos la siguiente imagén InetVis:

Este patrón corresponden a un scan usando el siguiente código scapy:

ans,unans = sr(IP(src=RandIP('213.96.140.0/24'), dst='192.168.1.5')/UDP(dport=[(1,1024)]),inter=0.5,retry=10,timeout=1)

Lo que hacemos es usar la opción sr para envió de paquetes, que ya sabemos envía y recibe paquetes en la capa 3. Usaremos también las siguientes opciones:

inter intervalo, en segundo, entre paquetes enviados
retry reintentar de nuevo si los paquetes que no obtuvieron respuesta
timeout tiempo de espera máximo desde el último paquete

Qué vemos:

He acotado el rango de puerto de destino, eje y (verde) para mostrar desde los puertos 1 a 2000. Observad la dispersión de los puntos.

He acotado también el eje z (rojo) con un rango de 213.96.140.0/24. Así pues, se observa mejor la dispersión de los puntos debido a las opciones indicada más arriba para scapy.

En esta caso vemos que solo hay un plano, además muy cercano al origen de ordenadas. Esto es así porque se trata de un solo host de destino del scan y con IP 192.158.1.5.

Vamos ahora a obtener mayor densidad de los puntos de forma casi uniforme. Lo hacemos de la forma:

ans,unans = sr(IP(src=RandIP('213.96.140.0/24'), dst='192.168.1.5')/UDP(dport=[(1,1024)]))

Las opciones on las mismas que en el caso anterior pero eliminando RandIP():

Podéis observar que, como he comentado más arriba, no existe la dispersión de puntos (representación de los paquetes). Es todo uniforme. Las opciones de un escaneo también cuentan y la representación es distinta.

Seguimos.

Ahora vamos a usar solo un pequeño rango de máquinas (192.168.1.90-100), las cuales está casi todas activas. Vemos como la “nube” en InetVis se hace más densa y obtiene grosor que corresponde al rango de IPs internas del eje x:

He usado el siguiente código scapy:

>scan = IP(src=RandIP('213.96.10.0/24'),dst='192.168.1.90-100')/TCP(sport=56, dport=(0,1024), flags=2)
>sr(scan,timeout=3)

Usando nmap.

Vamos a usar algunas de las opciones de optimización de tiempo, rendimiento, etc, que nos ofrece nmap. Un poco forzado y redundante pero sirve para ilustrar el ejemplo:

nmap -sS 192.168.1.0/24 -e eth0 -T5 –host-timeout 5m –max-retries 0 –initial-rtt-timeout 25ms –max-rtt-timeout 250ms –max-scan-delay 250ms –scan-delay 10ms –min-hostgroup 32 –max-hostgroup 32 -D 213.96.169.1,213.96.xxx.xxx,213.96.xxx.xx,213.96.xx.xxx,213.96.xx.x

–host-timeout 5ms para abandonar el objetivo cuando pase el tiempo especificado.
–max-rtt-timeout 250ms tiempo que toma en enviar un paquete desde un host cliente a un host servidor y viceversa. Aquí establecemos un máximo.
–max-scan-delay 250ms / –scan-delay 10ms aquí ajustamos un rango de tiempo de retraso
–min/max-hostgroup 32 escanear en paralelo en grupos de 32
-D uso de decoys o direcciones spoofeadas
-sS para TCP-SYN scan.
-T5. Establecemos una plantilla específica para la tasa de envío de paquetes para el control de tiempos y rendimiento. Esta plantilla tiene implícita una serie de opciones tales como max-rtt-timeout, etc. En nuestro caso algunas las hemos modificado.

El resultado:

Vemos lo siguiente:

como en el eje azul x vemos unas bandas que corresponden a las direcciones IP consecutivas que están activas en la red interna del rango 192.168.1.0/24.
existen zonas intermedias del eje x que corresponden a IP que no están activas.
en el eje rojo, que correspondiente a las IP externas de origen, vemos que hay 4 hosts (los activos )que corresponden con cada una de las IP que indicamos con -D en nmap.

Y hasta aquí la segunda parte de (9/10) Herramientas para la interpretación de capturas de red. Hasta la próxima.

Navegador web Opera (11.61) solventa dos bugs, uno de ellos catalogados como crítico.

Dabo — Thu, 26 Jan 2012 04:39:11 +0000

Según podemos leer en H-Online, (ENG) el equipo de Opera ha liberado la versión 11.61 de su navegador web. Se han solventado dos vulnerabilidades, siendo una de ellas catalogada de un impacto crítico para el sistema.

Concretamente, un XSS (Cross-site scripting), puede hacer que un atacante pueda traspasar las políticas original de seguridad del software, comprometiendo su integridad. El segundo fallo, catalogado como “leve”, puede hacer que páginas remotas detecten ficheros locales en el sistema del usuario. Hay acualizaciones para Windows, Mac OS X, GNU/Linux, FreeBSD y Solaris. Descargas.

Vulnerabilidades en Apache Tomcat 5, 6 y 7

vlad — Mon, 23 Jan 2012 17:53:52 +0000

A través de Hispasec nos hacemos eco de las vulnerabilidades remotas localizadas en el contenedor de servlets Apache Tomcat, desarrollado por la Apache Software Foundation, las cuales han sido consideradas como de importancia por sus mantenedores, con lo que se recomienda a aquellos administradores que lo usen en su servidor procedan a comprobar si su versión de Tomcat es una de las afectadas. En concreto se trata de los siguientes fallos:

Denegación de servicio remota relacionada con las colisiones en las tablas hash. Las versiones afectadas son la 5, 6 y 7
Revelación de información sensible debido a un error en el reciclado de objetos que podría volver visibles datos como IPs remotas o cabeceras HTTP a través de peticiones especialmente manipuladas. Las versiones afectadas son la 6 y 7.

Más información y solución en Hispasec

Vulnerabilidades severas en phpMyAdmin. Debian Security (DSA-2391-1).

Dabo — Sun, 22 Jan 2012 22:24:43 +0000

Se han reportado por parte de Debian dos vulnerabilidades en el gestor de bases de datos phpMyAdmin. Se recomienda su actualización a la mayor brevedad posible debido al impacto de las mismas en el sistema caso de ser explotadas.

La versión “oldstable” (lenny) no está afectada por estos problemas, para la rama actual estable (Squeeze), hay que actualizar phpMyAdmin a la versión 4:3.3.7-7., en la de pruebas “Whezzy” hay que actualizar a la 4:3.4.7.1-1.:

Referencias sobre los bugs (entre ellos un XSS).

In the Debian bugtracking system: Bug 656247.
In Mitre’s CVE dictionary: CVE-2011-1940, CVE-2011-3181, CVE-2011-4107.

Sobre la responsabilidad de la (IN) Seguridad. Interesante reparto / repaso

Dabo — Thu, 19 Jan 2012 12:34:07 +0000

Muchas veces ejercemos eso de “echar balones fuera” hablando de quién tiene realmente la responsabilidad de que un sistema, entorno web o infraestructura tenga una brecha de seguridad, la verdadera realidad es que es algo de todos…

Os recomendamos leer una entrada muy interesante en Sec-Track que se presentó en el BarCampSE en Medellín en la que paso a paso, se va desgranando la responsabilidad que cada eslabón de la cadena de la seguridad puede tener, para que bien no se rompa, o caso de que así sea, saber por dónde pueden venir “los tiros”. Un trabajo de meses en un magnífico post.

Acceso a; “Finalmente… ¿Quiénes son los responsables de la (In)seguridad?“