Nikto es una herramienta open-source escrita en perl cuya función es la de analizar servidores web basándose en una gran base de datos de plugins. No pretende ser competencia a productos comerciales de la talla de HP Webinspect, IBM Rational AppScan o Acunetix, si no que gracias a ella obtendremos un buen punto de partida para comenzar nuestras auditorias a sitios web.
Es "ruidosa", no posee una gran interfaz gráfica (aunque se que os encanta la consola...) y no contiene herramientas aparte para realizar otras tareas, pero es tremendamente efectiva y los resultados nos darán "pistas" de por dónde empezar el correspondiente análisis.
El 18 de Octubre, David Lodge anunció la liberación de la versión 2.1.0, con un buen conjunto de novedades, sobretodo en su programación y optimización. A continuación os dejo un resumen de su Changelog traducido al castellano:
Reescrito el motor de plugins y de reporting.
Gran revisión de la documentación para comentar los métodos incluidos y las variables
Añadido soporte de caché para reducir el número de llamadas realizadas a los servidores web, junto con la posibilidad de desactivar la función de control sobre los mensajes HTTP 404
Añadidas técnicas básicas para poder reconocer si el sistema analizado se trata de un dispositivo empotrado, dando detalles del tipo.
Plugin de utilización de los diccionarios de palabras de OWASP para realizar fuerza bruta de directorios contra el servidor web.
Plugin para realizar fuerza bruta sobre dominios
Posibilidad de obtención de usuarios utilizando un diccionario de palabras así como fuerza bruta
Soporte de autenticación NTLM
Arreglados varios fallos y comprobaciones de seguridad.
Está claro que la apuesta principal de esta versión es la posibilidad de realizar ataques de fuerza bruta en busca de posibles recursos no indexados, como por ejemplo directorios, además de usuarios válidos.
Sin duda, una herramienta básica que debería estar en tu directorio de /tools/ si te gusta buscarle las cosquillas a los servidores web...siempre con moderación y con el debido consentimiento.
De la mano del SANS, nos llega una recopilación de herramientas para realizar auditorías web.
En la lista, las hay desde el veterano y conceptualmente 'un poco' desfasado Nikto, hasta poderosas herramientas tipo Proxy como Burp que permiten hacer literalmente virguerías, sin olvidar el LiveCD Samurai WTF del que ya hablamos en su día.
Personalmente en esa lista echo de menos al gran Paros (que aun estando algo descontinuado, tiene cosas realmente buenas). También echo a faltar muchas de las extensiones para FF que nombramos aquí
A ver si saco tiempo para probar las que no conozco de la lista
Las principales características se pueden resumir en:
Multiplataforma real. Ha sito probado en Windows, Linux, *BSD y OS X.
No tiene dependencias de librerías nativas. Todo el framework está escrito completamente en python.
Rendimiento óptimo, en comparación con otros frameworks escritos en python.
Realmente fácil de usar.
Crear nuevos plugins es extremadamente sencillo.
El frameworks puede recopilar y unificar resultados de otras herramientas de seguridad populares, como: sqlmap, xsser, openvas, dnsrecon, theharvester...
Integración con estándars: CWE, CVE y OWASP.
Diseñado para funcionar en modo cluster, aunque todavía no está disponibles.
El punto marcado negrita creemos que es la mayor novedad y principal atractivo para usar GoLismero.
Además de sus propias pruebas, GoLismero ejecutará automáticamente por nosotros herramientas conocidas y populares (todavía no están todas integradas, estamos trabajando en ello) cogerá sus resultados, los unificará y realimentará las herramientas con los resultados obtenidos. Es decir: cogerá los resultados de un análisis con OpenVas y los enviará al SQLMap, XSSser, DNSrecon, etc. Y todo de forma automática, chulo, no?
Es una actualización de GoLismero 0.6.3?
GoLismero 0.6.3 (incluido en Backtrack y Kali Linux, por ejemplo) era un simple mapper con algunas funciones muy básicas de análisis. GoLismero 2.0 ha sido reescrito desde cero y de la versión inicial solo conserva en nombre :)
Cómo usar GoLismero?
Usar GoLismero 2.0 es muy fácil: A continuación se explican uno cuantos comandos básicos para poder empezar a usar GoLismero:
Instalación
Aunque próximamente liberaremos una modificación de la Kali Linux con todo lo necesario para ejecutar GoLismero, de comento lo podéis descargar así:
Descargamos https://github.com/golismero/golismero/archive/master.zip y extraemos el contenido donde queramos. GoLismero lleva todas las dependencias necesarias integradas (a excepción del intérprete de Python) con lo que no tendremos que hacer nada más.
También puede descargar la versión más reciente usando GIT:
Este comando lanzará GoLismero con todas las opciones por defecto y mostrará el informe por la salida estándar (habitualmente la consola):
python golismero.py <target>
También puede configurar el nombre de la auditoría:
python golismero.py <target> --audit-name <name>
GoLismero permite generar informes de diferentes formatos. El formato será reconocido automáticamente por la extensión del fichero de salida. Además, puede indicar varios archivos de salida en varios formatos diferentes a la vez:
Además, puede importar resultados de otras herramientas con la opción "-i". Puede usar "-i" tantas veces como resultados quiera importar. El siguiente ejemplo muestra como parsear los resultados de un escaneo de Nikto y generar un informe. Para evitar que GoLismero se realimente con los resultados de Nikto desabilitaremos todos los plugins:
python golismero.py www.example.com -i nikto_output.csv -o report.html -d all
Todos los resultados son automáticamente guardados en el fichero de base de datos. Puede evitar esto con la opción "-nd":
python golismero.py <target> -nd
Esto permite escanear el target en un momento dado y generar el informe después. Por ejemplo, para lanzar un scan sin generar el informe:
python golismero.py <target> -db database.db -no
En otro momento generamos el informe a partir de la base de datos (¡o en una máquina diferente!).
python golismero.py -db database.db -d all -o report.html
Plugins disponibles
Para mostrar la lista de plugins disponibles:
python golismero.py --plugin-list
También puede mostrar los detalles de un plugin específico:
Hemos tratado de que los informe no sean los típicos reportes "juacker", sino que sean visualmente agradables y útiles. Los informes generados en HTML siguen diseño responable, gráficas y buscador javascript integrado. Además, no tienen ninguna dependencia de css o javascript, todas las librerías van incrustadas en un solo fichero para que sea fácil de enviar/mover.
Así es cómo se generan los informes en HTML para una auditoría:
python golismero.py <target> -o report.html
Resumen:
Detalles:
Cuáles son los siguiente pasos?
Las siguientes funcionalidades serán:
Integración con Nmap, SQLMap, Metasploit y otras herramientas.
Interfaz web. Sabemos que los h4xx0rs solo utilizan la consola, pero a veces el copy&paste está bien ;)
Exportar los resutlados a PDF.
Y muchas cosas más, por supuesto!
Quiénes somos?
Y ya por último, presentarnos:
GoLismero 2.0 ha podido ver la luz gracias al apoyo incondicional de Buguroo, que ha sido quien ha subvencionado el desarrollo y ha permitido que sea publicada como software open source.
Nmap no es sólo un escáner de puertos, es una de las herramientas de seguridad y administración más potentes y populares que existen, y cuenta con una enorme comunidad de usuarios y desarrolladores.
Debido a la popularidad, versatilidad y potencia de la herramienta son varios los proyectos que la han llevado a la Web, haciéndola accesible a través de un navegador de forma remota.
En primer lugar tenemos algunos servicios que permiten escanear nuestra propia dirección IP, muy útiles para saber cómo nos ven desde fuera.
- Nmap Online: Uno de los más populares. Podemos lanzar escaneos predeterminados (Quick y Full) o personalizar uno, dentro de lo que nos permite el portal. Funciona realmente bien y es rápido. Actualmente versión 4.75 de nmap.
- Free Online-Portscanner: Parecido al anterior pero con opciones mucho más reducidas. Sólo un tipo de escaneo sin opción a modificaciones. Actualmente versión 3.77 de nmap.
- Self Audit My Server: Enfocado a trabajar con servidores web. Además de nmap lanza Whois, Nikto y SQLiX para auditar el servicio web. A diferencia de los anteriores, se puede lanzar contra otra IP o dominio que no sea el nuestro. Actualmente versión 5.00 de nmap y 2.03/2.04 de nikto. Podemos ver un ejemplo de escaneo a microsoft.com
Por otro lado tenemos proyectos que proporcionan el software para instalar el servicio en nuestra infraestructura.
- nmap-cgi: Muy completo, despliega un portal para realizar, guardar y administrar nuestros escaneos. Permite cuentas de usuario independientes, separar privilegios, escaneos avanzados de nmap, programar escaneos, etc ...
- Inprotect: Al igual que el anterior despliega una completa infraestructura para realizar y administrar escaneos. Destaca su generador de reportes y la cuidada interfaz.
- nmap-web: Si no nos interesa mucho la interfaz y queremos algo rápido de instalar y usable, nmap-web nos lo proporciona. Las opciones son reducidas y la interfaz es básica, pero cumple su función. Algunos ejemplos (1, 2, 3).
Dradis, para el que no lo conozca, consiste en una herramienta que permite el compartir y recopilar la información que se va obteniendo durante auditorías de seguridad en sistemas y en aplicaciones web, así como en tests de intrusión.
A modo de repositorio, nos permite además importar ficheros de herramientas tan conocidas como Nessus, Nikto, Nmap, Burp, Nexpose, OpenVAS, w3af, ZAProxy, NSS...y un largo etc, ya que permite la creación de más plugins para importar cualquier tipo de información y organizarla dentro del proyecto basándose en la salida de las pruebas realizadas.
La información se organiza y registra vía un interfaz web tras la instalación, en la cual se comienza con la creación de carpetas o nodos, incluyendo posteriormente los sistemas y anotaciones pertinentes, apoyándose en la información obtenida de herramientas y así organizar en un mismo punto todo lo que se vaya avanzando durante las pruebas de seguridad. La aplicación no distingue a los usuarios (se accede con un nombre de usuario pero no se registra previamente en el sistema), valiéndose únicamente de una contraseña establecida a modo de servidor para consultar la información que se encuentre disponible y volcada en los proyectos.
El motor de importación de resultados de herramientas, analiza las salidas según el tipo de herramienta y los procesa, para incluir dentro del framework toda la información, separándola por sistema y puerto.
Gracias a Dradis, podremos olvidarnos de recopilar información en simples .txt o .doc sin formato, teniendo toda la información centralizada en un punto, en la que además se pueda trabajar de forma colaborativa por un equipo de personas.
Lección 5 - Seguridad Perimetral. Contribución de Alex al proyecto Intypedia, presentándonos herramientas básicas a tener en cuenta para comenzar a diseñar una red segura: DMZ, cortafuegos, detectores de intrusos y honeypots.
Publicado el estudio sobre la seguridad de las comunicaciones móviles e inalámbricas en los hogares españoles (del 3er trimestre de 2010) en PDF por Inteco.
Un nuevo bug en BIND (CVE-2011-0414) que permitiría la denegación de servicio de forma remota.
Se presentaron nuevos Macbooks Pro por parte de Apple, siendo una de sus principales novedades la introducción del nuevo Thunderbolt (que pretende sustituir al USB). Aparecen las primeras especulaciones por suponer una posible amenaza para estos equipos.
OWASP anuncia oficialmente la AppSec USA 2011 para Minneapolis, que tendrá lugar en Septiembre de este año. Todavía queda, pero está abierto el proceso de Call For Papers yCall For Trainers.
Aprovechando uno de los días sin IVA de Mediamarkt, y teniendo en mente un cambio de TV (la anterior no tenía ni TDT integrada), volvimos a casa con una LG más moderna. Ya puestos, esta es algo más grande que la anterior, y como le confesé a Chema Alonso en la entrevista que me hizo, este año estará genial seguir la temporada de Fórmula 1 en el salón!
Según miraba la TV en Mediamarkt, me preguntaba a mí mismo para qué valdría el conector RJ-45 que se le veía detrás, y ya me picaban los dedos por conectarla en casa a ver qué habían dejado los ingenieros de LG a disposición de todo el mundo
Así, después de ver que todo funcionaba, configuré la red cableada de la TV con la IP 192.168.52.50 y con default gateway y DNS 192.168.52.254 (la máquina de casa que hace de UTM). Os doy estos datos para poneros en situación de lo que veréis que ocurre después.
Así pues… siguiendo el capítulo 0 del "Manual del buen auditor" el primer sencillo nmap lanzado (nmap -v -sT -sV -A -O -p1-65535 -P0 192.168.52.50) devuelve que no hay puertos abiertos. Leyendo el manual (esta vez el de la TV), se dice que puede reproducir contenidos digitales compatibles con DLNA (Digital Living Network Alliance) que estén en la misma red. DLNA funciona como UPnP, es decir, que los dispositivos "se anuncian" que existen en la red mediante el puerto 1900 UDP a una IP de Multicast… Curioso es que al buscar contenidos por la red desde el menú de la TV, al lanzar el siguiente nmap apareciera lo siguiente:
[root@Carmen ~]# nmap -v -sT -sV -A -O -p1-65535 -P0 192.168.52.50
Interesting ports on 192.168.52.50:
Not shown: 65534 closed ports
PORT STATE SERVICE VERSION
33255/tcp open unknown
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
SF-Port33255-TCP:V=4.20%I=7%D=2/19%Time=4D5EFE64%P=i686-redhat-linux-gnu%r
SF:(GetRequest,F4,"HTTP/1\.1\x20500\x20Internal\x20Server\x20Error\r\nSERV
SF:ER:\x20Linux/2\.6\.31-1\.0\x20UPnP/1\.0\x20DLNADOC/1\.50\x20INTEL_NMPR/
SF:2\.0\x20LGE_DLNA_SDK/1\.5\.0\r\nCONNECTION:\x20close\r\nCONTENT-LENGTH:
SF:\x2060\r\nCONTENT-TYPE:\x20text/html\r\n\r\n
500\x20Internal\x20Server\x20Error)(HTTPOptions,E8,"HTTP/1\.
SF:1\x20501\x20Not\x20Implemented\r\nSERVER:\x20Linux/2\.6\.31-1\.0\x20UPn
SF:P/1\.0\x20DLNADOC/1\.50\x20INTEL_NMPR/2\.0\x20LGE_DLNA_SDK/1\.5\.0\r\nC
SF:ONNECTION:\x20close\r\nCONTENT-LENGTH:\x2054\r\nCONTENT-TYPE:\x20text/h
SF:tml\r\n\r\n
501\x20Not\x20Implemented
MAC Address: 00:E0:91:VV:XX:ZZ (LG Electronics)
No exact OS matches for host (If you know what OS is running on it, see http://insecure.org/nmap/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=4.20%D=2/19%OT=33255%CT=1%CU=38930%PV=Y%DS=1%G=Y%M=00E091%TM=4D5E
OS:FECD%P=i686-redhat-linux-gnu)SEQ(SP=BB%GCD=1%ISR=C4%TI=Z%II=I%TS=A)SEQ(S
OS:P=BB%GCD=1%ISR=C5%TI=Z%II=I%TS=A)OPS(O1=M5B4ST11NW5%O2=M5B4ST11NW5%O3=M5
OS:B4NNT11NW5%O4=M5B4ST11NW5%O5=M5B4ST11NW5%O6=M5B4ST11)WIN(W1=16A0%W2=16A0
OS:%W3=16A0%W4=16A0%W5=16A0%W6=16A0)ECN(R=Y%DF=Y%T=40%W=16D0%O=M5B4NNSNW5%C
OS:C=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%
OS:T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD
OS:=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=4
OS:0%TOS=C0%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUL=G%RUD=G)IE(R=Y%DFI
OS:=N%T=40%TOSI=S%CD=S%SI=S%DLI=S)
Uptime: 0.117 days (since Fri Feb 18 21:32:27 2011)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=187 (Good luck!)
IPID Sequence Generation: All zeros
OS and Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap finished: 1 IP address (1 host up) scanned in 119.277 seconds
Raw packets sent: 126 (9832B) | Rcvd: 66 (6092B)
Ahora sí que tienes un puerto abierto TCP??? ¿Qué correrá en él?
[root@Carmen ~]# telnet 192.168.52.50 33031
Trying 192.168.52.50...
Connected to 192.168.52.50 (192.168.52.50).
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.1 400 Bad Request
SERVER: Linux/2.6.31-1.0 UPnP/1.0 DLNADOC/1.50 INTEL_NMPR/2.0 LGE_DLNA_SDK/1.5.0
CONNECTION: close
CONTENT-LENGTH: 50
CONTENT-TYPE: text/html
400 Bad Request
GET / HTTP/1.0
HTTP/1.1 500 Internal Server Error
SERVER: Linux/2.6.31-1.0 UPnP/1.0 DLNADOC/1.50 INTEL_NMPR/2.0 LGE_DLNA_SDK/1.5.0
CONNECTION: close
CONTENT-LENGTH: 60
CONTENT-TYPE: text/html
500 Internal Server Error
GET / HTTP/0.9
HTTP/1.1 500 Internal Server Error
SERVER: Linux/2.6.31-1.0 UPnP/1.0 DLNADOC/1.50 INTEL_NMPR/2.0 LGE_DLNA_SDK/1.5.0
CONNECTION: close
CONTENT-LENGTH: 60
CONTENT-TYPE: text/html
500 Internal Server Error
^[^]
telnet> quit
Connection closed.
Un servidor web?! Se comporta diferente dependiendo de la versión HTTP que usemos (0.9, 1.0 ó 1.1). Por la respuesta, sólo soporta peticiones HTTP 1.1, pero no permite ni una simple petición GET. ¿Tendrá vulnerabilidades? Googleando aparecen entradas sobre las capacidades DLNA (el plugin DLNADOC/1.50 que aparece en la cabecera). He de decir también que en sucesivas pruebas, el puerto abierto detectado cambiaba, en general a 33031 TCP. Aquí referenciaré siempre 33255 para mantener la coherencia.
El sentido común dice que un servidor web, si tiene alguna vulnerabilidad, la fantástica herramienta Nikto, lo sabrá. [DISCLAIMER] Esta prueba fue lanzada mientras mi novia veía la tele, por lo que, el comportamiento que vais a leer/ver ahora lo detecté por casualidad, pero mi cara fue algo así :O [/DISCLAIMER]
Ejecutando perl nikto.pl -host http://192.168.52.50:33255 -C all, el programa empieza a probar vulnerabilidades conocidas indicándonos si ha tenido éxito o no en cada una de ellas.
Mientras se ejecutaba esta herramienta, mi novia, muy aficionada a hacer zapping con el mando, llegó un momento en el que, al cambiar de canal, la TV mostraba durante unos 2 segundos la imagen, y se quedaba sin señal. He reproducido varias veces la situación y la podéis ver bajo estas líneas:
Aunque se pare la ejecución de la herramienta, hasta que no se reinicia la TV, no volverá a su comportamiento normal. Es decir, ¿el funcionamiento de la TV puede verse afectado dependiendo de lo que le hagas a su interfaz de red? Por ello, quise probar si era capaz de hacer algún otro tipo de denegación de servicio basado en estresar la tarjeta de red. ¿Qué pasaría si por ejemplo utilizara las capacidades de Flooding de Hping? Si no os acordáis de todas las opciones que tiene hping, podéis echar un vistazo al cheatsheet que comentamos aquí.
Una vez lanzado a ejecución la línea "hping -p 33255 --flood -a 192.168.52.254 -S 192.168.52.50" la TV empezará a recibir una inundación de paquetes por su interfaz de red que la estresará tanto que seará incapaz de reproducir correctamente el video!! El audio se oye bien, pero el video no se decodifica como tiene que ser. Lo podéis ver en el siguiente video:
En este caso, si paramos la ejecución de Hping, la TV hará su trabajo correctamente, sin perder fotogramas, sin necesidad de reinicios.
Buscando otros vectores de ataque
Netcast es la aplicación de LG que nos presenta el portal de acceso a los contenidos digitales desde la TV permitiéndonos ver videos Youtube, conectarnos a Facebook, Twitter, el informe meteorológico con Accuweather, Google Maps, etc,… Dicho portal ofrece la posibilidad de hacer que, en su momento de carga, presente la temperatura de una ciudad y la hora de la medición. Podéis ver un ejemplo de esto en la siguiente imagen:
La idea ahora es analizar el funcionamiento y personalizar aún más ese portal. Siguiendo el "manual del buen juanker" nuevamente, procedemos a analizar el tráfico de red que efectúa la TV desde que la encendemos y accedemos al menú Netcast. Para ello, utilizando la herramienta Tshark (la utilidad de línea de comandos de Wireshark) analizamos el tráfico de red que intercambia la TV con el exterior para obtener la información meteorológica.. Mediante la línea: "tshark -i eth1 host 192.168.52.50 -V -w /tmp/tsharklg" obtendremos un fichero pcap que luego podremos analizar cómodamente con Wireshark (si alguien quiere que le envíe el pcap, que me lo pida).
Os cuento las conclusiones obtenidas de ese análisis:
Lo primero que hace la TV es intentar resolver por DNS la dirección www.lge.com
Una vez que resuelve, se conecta a esa IP al puerto TCP 80 y si obtiene una respuesta satisfactoria "detecta que tiene conexión a Internet".
Una vez que entramos en el menú Netcast con el mando, se conecta a http://lgtv.accu-weather.com/widget/lgtv/weather-data.asp… con un montón de parámetros que devuelve un XML que posteriormente la TV parseará y mostrará en pantalla.
Bueno, pues ya tenemos las condiciones necesarias para el caldo de cultivo de una bonita inyección que genere un panel diferente.
Es increible que la TV necesite conectarse periódicamente a www.lge.com para saber si tiene o no Internet. Hice la prueba a nivel de firewall saliente (en 192.168.52.254) y bloqueé la IP a la que intenta conectarse la TV. Efectivamente, la LG se queja en un mensaje de error que no hay acceso a Internet y que verifique la conexión. El día que el servidor web de lge.com no esté accesible, para todos los dispositivos LG mundiales que ejecuten NetCast, no habrá Internet!
Analizando la petición web que hace a accu-weather.com y la respuesta en un XML, para llevar a cabo la inyección tendremos que disponer de un servidor web accesible por la TV y modificar la resolución DNS de accu-weather.com por la del servidor web propio. Si nuestro servidor DNS nos permite añadir entradas (no hace simplemente de relay/caché de DNS) lo haremos así. Para ello deshabilité en la máquina 192.168.52.254 el servicio DNS caché y utilicé una implementación de servidor DNS hecha en Perl muy sencillita que permite añadir manualmente qué queremos que se resuelva:
En mi caso, quedó así:
[root@Carmen ~]# more /tmp/dns.pl
#!/usr/bin/perl
use Net::DNS::Nameserver;
use strict;
use warnings;
sub reply_handler {
my ($qname, $qclass, $qtype, $peerhost,$query,$conn) = @_;
my ($rcode, @ans, @auth, @add);
print "Received query from $peerhost to ". $conn->{"sockhost"}. "\n";
$query->print;
if ($qtype eq "A" && $qname eq "lgtv.accu-weather.com" ) {
my ($ttl, $rdata) = (3600, "192.168.52.17"); #SI ALGUIEN NOS PIDE RESOLUCION DE LGTV.ACCU-WEATHER.COM DEVOLVEMOS LA IP DEL WEBSERVER
push @ans, Net::DNS::RR->new("$qname $ttl $qclass $qtype $rdata");
$rcode = "NOERROR";
}elsif( $qname eq "www.lge.com" ) {
my ($ttl, $rdata) = (3600, "93.188.132.129"); #Importante añadir la resolución de www.lge.com porque si no dirá que no hay acceso a Internet!!!!
push @ans, Net::DNS::RR->new("$qname $ttl $qclass $qtype $rdata");
$rcode = "NOERROR";
}else{
$rcode = "NXDOMAIN";
}
# mark the answer as authoritive (by setting the 'aa' flag
return ($rcode, \@ans, \@auth, \@add, { aa => 1 });
}
my $ns = Net::DNS::Nameserver->new(
LocalPort => 53,
ReplyHandler => \&reply_handler,
Verbose => 1,
) || die "couldn't create nameserver object\n";
$ns->main_loop;
Así pues en la IP 192.168.52.17 levanté un servidor web, que devolvería en /widget/lgtv/weather-data.asp el siguiente XML:
[root@Test ~]# more /var/www/html/widget/lgtv/weather-data.asp
CKMKPHkPaMMFailLandSpain40.4-3.6801:001False
http://www.accuweather.com/m/en-us/EUR/ES/SP013/Madrid/current.aspx?p=lgtvSecurityByDefault tenemos 2858 Followers en Twitter212030%Sunny0144SW0.0Low
…..
SNIP
De esta manera, la siguiente vez que entráramos en el menú Netcast de la TV, nos sorprendería de la siguiente manera:
Conclusiones
La TV LG es increible en cuanto a capacidades y prestaciones. Se ve y oye genial y estoy seguro que disfrutaré como un vikingo de las carreras de Fórmula 1!
Los ingenieros de LG han hecho un buen trabajo en la securización de la misma, al menos "de serie", puesto que hay que dedicarle un buen rato para encontrarle "cosillas"
Quizá sería interesante no haber incluido procesadores autónomos para la decodificación de la señal de TDT y el procesamiento del tráfico de red, a fin de evitar que una inundación de paquetes influyera en la decodificación o el refresco de pantalla.
Una pista falsa que seguí fue el intentar meterle mano a la funcionalidad DLNA. Desde un PC con un servidor DLNA, detecta que la TV está en la red, pero no permite ejecución de comandos ese dispositivo DLNA.
Para conseguir inyectar el texto deseado en el portal de entrada de Netcast hay que tomarse unas cuantas molestias, aunque oye siempre es divertido el tener un servidor que te genere un XML con información personalizada y acutalizada en el campo "observationtime" y enterarte en la TV cuando quieras.
Ahora ya sé qué medidas tomar cuando mi novia monopolice el mando a distancia de la TV y no compartamos el gusto por lo que estén dando en ese canal. Hping es mi amigo!
He visto las etiquetas de "Warranty void if this seal is broken", sin embargo, en ningún sitio pone que se invalide la garantía por darle un poco de caña al interfaz de red, ¿verdad?
Después de que sustituyeran CNN+ en español por Canal Gran Hermano pensé que la tele sería un coñazo… ¿Quién dijo ahora que la TV es aburrida?
Siguiendo la estela de mi anterior post, hoy hablaré de HoneyTokens, un concepto que he visto muy pocas veces comentado y prácticamente en ningún sitio implementado.
Cualquier organización con un equipo de seguridad, tarde o temprano tiene que elaborar informes y tratar de definir de una forma mas o menos precisa métricas que indiquen aspectos como el grado de exposición ante ataques del exterior o el famoso 'nivel de riesgo'. El problema a la hora de abordar esa tarea es que resulta complejo discernir un riesgo real del simple ruido.
Cualquiera que tenga un servidor web expuesto en Internet se puede pasar divertidas horas ojeando los ficheros de logs viendo toda clase de ataques, da igual que la maquina sea un simple servidor web casero o www.google.com, los ataques se suceden día tras día y van desde escaneos buscando una aplicación especifica generados desde algún host comprometido, hasta barridos masivos con herramientas tipo nikto.
Basar el nivel de riesgo en el numero de ataques de este tipo es bastante irreal, porque el 99,9% son búsquedas de aplicaciones que no tenemos instaladas o buscando versiones realmente vetustas. Tratar de implementar una política de anticipación basada en el numero de ataques recibidos es una tarea fútil.
Una forma bastante efectiva de saber cuando hay que poner en rojo todas las alarmas es la implementación de HoneyTokens como sistema de anticipación. Un HoneyToken, básicamente, es una información aparentemente valiosa, que se encuentra escondida para que no pueda ser descubierta fortuitamente, pero a la cual se puede llegar con algo de hacking. La información que contiene el token conduce a un sitio monitorizado para que, cuando el atacante haga uso de esa información, tengamos certeza absoluta de que algo importante está sucediendo.
Un ejemplo de HoneyToken sencillo de entender y de implementar podría ser esconder dentro de la infraestructura web de la organización un fichero en formato excel con un nombre revelador, tipo contraseñas-servicio.xls al cual no se pueda llegar mediante navegación normal pero que si se encuentre indexado por Google. Es importante que ese fichero aparezca en Google si alguien realiza una consulta del tipo: site:www.organizacion.com filetype:xls
Si alguien se está planteando atacar en serio nuestra organización, es casi seguro que recurrirá al famoso "Google Hacking" para recabar información, y normalmente las cosas que se suelen buscar van en la linea de documentos tipo bases de datos access o ficheros excel
En ese fichero, además de poner varios pares usuario/contraseña se le añade como encabezado algo al estilo "Usuarios soporte Callcenter https://callcenter.organizacion.com" para que el atacante sepa donde debe dar el siguiente paso. Este ejemplo es bastante efectivo pero obvio, la forma en la que cada cual lo implemente varía en función de la imaginación y grado de dificultad que se le quiera dar al "reto".
El siguiente punto es implementar una pequeña aplicación-señuelo en la URL que hemos puesto en el fichero excel simulando una aplicación de soporte a usuario. No es necesario implementar la aplicación en si, basta con un frontal donde introducir usuario/contraseña y que en caso de ser correcto, muestre un mensaje de error tipo "No se pudo contactar con la base de datos". Con eso, suficiente. La siguiente parte es montar el sistema de monitorización, en este supuesto bastaría con hacer que la aplicación web, al realizarse un login satisfactorio, envíe un mail avisando.
Versiones mas complejas de esta idea pasan por simular una aplicación web vulnerable a un ataque de tipo SQL Injection en el que se puedan obtener los usuarios para acceder a algún panel de gestión (Se puede tomar como ejemplo WebGoat). El hecho en si de que alguien se tome la molestia de hackear la aplicación, construir las sentencias sql, sacar la lista de usuarios y contraseñas e intentar usarlas, ya debería ponernos en la pista de que algo fuera de lo común está sucediendo sobre lo que debemos actuar urgentemente.
nginx es un popular servidor web y proxy inverso libre y gratuito que ya aloja más de 43 millones de dominios, entre los que se encuentra Wordpress, Dropbox, Facebook o TechCrunch.
En esta entrada vamos a ver algunos aspectos a configurar para que su instalación sea más segura.
Lo primero es eliminar información que identifique la versión de nginx todo lo que se pueda. Esto no hace el servicio más seguro, pero pone trabas a la hora de intentar buscarle fallos.
Para eliminar la cadena "nginx" de la cabecera Server, es necesario modificar el código fuente, en concreto del fichero src/http/ngx_http_header_filter_module.c siguientes líneas:
Si únicamente se desea eliminar el número de versión, dejando tan solo "nginx", o no se puede recompilar, en la configuración se puede especificar con la directiva:
server_tokens off;
Una vez instalado, hay que asegurarse de que no se ejecuta con un usuario con privilegios de administración. En su configuración ha de figurar el usuario y grupo son distintos de root.
user nginx nginx;
La identificación de la versión también es posible si se observan los mensajes de error del servicio. Para asegurar que no se reporta en ningún momento lo mejor es modificar las siguientes líneas del fichero src/http/ngx_http_special_response.c:
También se puede especificar en el fichero de configuración, dentro de server {}, cuáles serán las páginas de error personalizadas para cada una de los errores. En este ejemplo se redirige a error.html:
Una vez modificado el código fuente, se compila deshabilitando todos los módulos que no se usen. La web de nginx facilita una lista completa con su descripción. Especialmente interesante de eliminar es el autoindex. Para deshabilitar se utiliza una línea como la siguiente:
Como se gestionan los recursos dependerá más de las necesidades de rendimiento que de la propia seguridad, salvo se detecte y conozca algún fallo concreto. Si es posible y no impacta a este factor, se especifican tamaños de buffer pequeños donde sea más difícil explotar una vulnerabilidad.
Otra directiva interesante es activar la opción para ignorar todas las cabeceras invalidas:
ignore_invalid_headers on;
Para deshabilitar métodos HTTP, la mejor opción es usar listas blancas, marcando únicamente aquellos que se vayan a utilizar. Esta configuración también afecta al rendimiento, ya que procesar la expresión regular es costoso. También es importante destacar que nginx no soporta el método TRACE, ni PUT/DELETE/MKCOL/COPY/MOVE siempre y cuando no se compile con soporte Webdav
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 500;
}
Otras características interesantes son la posibilidad de devolver un código de error en base al user-agent o al referer con una expresión regular, tal y como se muestra en el siguiente ejemplo, que además no hace distinción entre mayúsculas y minúsculas al haber especificado: ~*
if ($http_user_agent ~* (acunetix|nikto) ) {
return 500;
}
if ($http_referer ~* (porn|webcam|bing) ) {
return 500;
}
También es posible evitar que enlacen directamente a las imágenes (hotlinking) desde la configuración de nginx:
Aprovechando la salida de la última versión de Sandcat quería hacer una pequeña recopilación de las aplicaciones más populares y potentes para el análisis de seguridad web gratuitas.
En alguna ocasión he leído comparaciones de estas herramientas con otras que únicamente hacen sus análisis en base a firmas, como por ejemplo Nikto o la versión gratuita de N-Stalker Esta comparación es un error, ya que el enfoque es completamente distinto. Ambas están enfocadas a detectar vulnerabilidades pero las aplicaciones basadas en patrones generalmente tienen bases de datos más amplias y actualizadas que las herramientas comprensivas y por lo tanto son complementarias.
Las características son muy similares en todas ellas, hacen una navegación previa y posteriormente lanzan el banco de pruebas. Exceptuando las dos últimas, scrawlr y acunetix, que únicamente detectan SQL Injection y XSS respectivamente, todas las demás buscan las vulnerabilidades más comunes.
No, no es que nuestra querida Seat, víctima de la crisis en la venta de automoviles, se haya adentrado en el mundo de la seguridad informática. SEAT es el nombre que la gente de Midnight Research Labs le ha dado a una de las herramientas mas completas y elaboradas para hacer Google Hacking.
Para empezar, no solo se queda en Google como motor de búsqueda, añade los motores de búsqueda de: Yahoo, MSN, A9, AltaVista, AllTheWeb, AOL y DMOZ
Como 'alimento' para realizar las querys usa las bases de datos de: GHDB, NIKTO, GSDB, WMAP, URLCHK y NESTEA
Otro punto a su favor es la no dependencia de Keys para usar los motores de búsqueda vía API, (hace llamadas como si fuera un navegador y parsea la salida) evitando lastrar la herramienta a los caprichos de las modas. (No olvidemos que casi todas las herramientas para hacer Google-hacking quedaron 'obsoletas' cuando Google congeló su api SOAP).
El único punto negro que yo le veo a la herramienta es que está demasiado orientada a Linux, no obstante, yo he conseguido hacerla funcionar en Windows usando ActivePerl y buscando los repos donde obtener Gtk2.
Se puede ver un vídeo demostración de la herramienta aquí
Bueno, una SECmana más que ha pasado, en la que hemos tenido muchas detenciones, muchas versiones nuevas de nuestras herramientas favoritas, y ya se van calentando motores para los próximos congresos que están a punto de celebrarse en verano, y que seguro que nos traen muchos titulares. De momento, empezamos con el recopilatorio de lo que ha dado de sí esta semana tan post-futbolera:
José Selvi de Pentester.es nos anuncia el Curso de Seguridad GSM/UMTS por parte de Taddong que tendrá lugar en Noviembre en Valencia. Aquí los detalles.
Actualización del Metasploit Framework, versión 3.4.1. Cuenta ya con 567 exploits y 283 módulos auxiliares. En este enlace, las notas de esta nueva versión.
Detienen al KAo Team, formado por Ca0s, K41S3R, xassiz y kr0no. Culpables de los defaces "con chispa" a la web de Sálvame y del defensor del menor en madrid, y muchas más.
Ayer comenzó el reto de Pandalabs 2010, con su primera prueba. El primero que la resuelva, ¡se llevará un iPad! Tenéis hasta mañana antes de las 17h (GMT+2)
Nada más, pasad buena SECmana, y si estáis ausentes, tranquilos: volveremos el domingo que viene!
Fue en Ekoparty 2012, cuando tuve por primera vez el honor de ir a tierras gauchas, a estrenarme en el escenario del mayor Congreso de Seguridad de Latinoamérica, cuando conocí a Francisco Amato, uno de los organizadores de dicho evento.
Fue el propio Francisco quien me contó, cuando asistí a la edición de Ekoparty 2014, que en Infobyte, la empresa de la que es CEO, estaban desarrollando una herramienta de seguridad, que me pareció muy interesante a la hora de llevar a cabo cualquier auditoría. Se llama Faraday, tiene una versión community, y dos versiones comerciales, la Professional y la Corporate.
Desarrolada en Python, ya se encuentra en su versión 1.0.7, aunque las versiones publicadas “vuelan”, debido al esfuerzo por dejarla lo más fina y con mayor funcionalidad posible, cuanto antes.
A grandes rasgos, cuando ejecutas Faraday en un sistema operativo Linux, se te abre un IDE con una shell, desde la que puedes ejecutar herramientas típicas de cualquier proceso de auditoría como nmap, nikto o theharvester por ejemplo, que automáticamente son interceptados por Faraday y añaden los flags necesarios para que el resultado del análisis de la herramienta se deje en formato XML, en una ruta dentro del home del usuario que la lanza.
Según se van lanzando diferentes herramientas, se va viendo el resultado de los hosts identificados, puertos abiertos, etc,… en un frame a la derecha.
Incluso han publicado en las últimas versiones, una opción en la que permite la ejecución en un entorno Linux sin ventanas, es decir, en modo consola:
Además de herramientas interceptables, se puede importar el resultado de otras como Nessus y OpenVAS, copiando el report en XML que se genera por éstas en el Workspace de Faraday, dentro del home de ese usuario y Faraday lo interpretará y añadirá al frame de resultados.
Y luego hay conectores para otras herramientas como Burp, Metasploit o BeEF, que permiten incluir los resultados de estas en el proyecto de auditoría que se esté llevando a cabo.
Toda esta información queda almacenada en una base de datos apoyada en CouchDB, por lo que a partir de aquí, permite generarse un informe que aglutina los resultados de todas las herramientas, sirviéndote de muy buena ayuda a la hora de llevar a cabo el informe. Igualmente, la herramienta se define como IDE colaborativa, por lo que diferentes auditores pueden ir haciendo diferentes tareas dentro de la auditoría y aunar los resultados en Faraday, de manera que mediante el interfaz web que renderiza la base de datos en CouchDB, se puede ir siguiendo la evolución del proyecto.
Evidentemente, quien piense que, únicamente gracias a Faraday, lanzará todas estas herramientas, importará los resultados en Faraday, le dará al botón imprimir y ya hecha la auditoría de seguridad, está claro que estará profundamente equivocado. Pero sí que es cierto que a la hora de categorizar vulnerabilidades existentes, prioridad e impacto de las mismas, en una auditoría de varios hosts de un mismo proyecto, resulta de gran utilidad.
A la hora de generar el documento ejecutivo, en el que se suele hacer un resumen con gráficos y estadísticas sobre el estado de los hosts auditados, Faraday nos entregará parte de ese trabajo ya hecho.
Que mejor homenaje al título de nuestro blog que enumeraros en un post las que, por lo menos para mí, son los mejores sites cuyo fin es recopilar usuarios y contraseñas por defecto tanto de dispositivos de red (quién no necesita ciertas credenciales de ciertos routers en concreto mientras realiza una "auditoria wifi" a su vecino...), como de servidores de aplicaciones ("¿anda, y este formulario de login en este puerto tan raro de esta aplicación web? vamos a probar..."), etc etc.
Lista en Cirt.Net - Igual por el nombre no os suena al principio, pero ¿y si os digo que de este sitio sale una herramienta muy utilizada para auditorias de servidores web? Si, exacto, es el hogar del Nikto. Pues no sólo nos debemos dirigir a su sección dedicada a tal script, en ella también nos podemos encontrar una de las mejores listas de cuentas de usuario y contraseñas por defecto, todas ellas catalogadas por fabricante ("vendor"), contando con más de 1700 contraseñas en su base de datos.
Lista en Cyxla - A simple vista podría parecer una de las múltiples páginas que se dedican a realizar este tipo de recopilaciones, pero hay dos cosas que me atraen mucho de esta en concreto... Lo primero, su fecha de última actualización, que corresponde al 17 de Octubre de 2008 en el momento en el que se está escribiendo este post. La página lleva operativa desde 2004 nada más y nada menos. Lo segundo, la posibilidad de poder aportar cada uno con más credenciales en el caso de no encontrarse ya registradas, todo ello, mediante previa aprobación por el administrador, y con este formulario.
Lista en Default-Password.info - Página con diseño más bien minimalista pero con una gran recopilación en ella. También separada y catalogada por fabricante, en la que predomina sobretodo la gran cantidad de cuentas por defecto de dispositivos de red.
Hay multitud de ellas, quizás la más conocida y en la que primero miramos cuando nos enfrentamos a un router wifi al que "queremos abrir los puertos" es esta de fondo negro y fuente naranja, pero siempre es más cómodo disponer de un buscador y no tener que buscar desde el propio navegador. en un html kilométrico. Para gustos los colores, como se dice, y si creéis que alguna más merece especial mención, los enlaces a modo de comentarios siempre son bien recibidos.
