Anonymous presente en los Goya 2013 y candidato a mejor Inyección SQL

Un año más, Anonymous se hace un hueco en los Goya. Esta vez no han sido protagonistas por organizar una manifestación cerca de la alfombra roja, o por saltar al escenario al más puro estilo Jimmy Jump. 

Directamente y como es habitual, bajo acciones de lo que han llamado #OpGoya, han explotado supuestamente una inyección SQL en el portal encargado de presentar las candidaturas de la vigésimo-séptima edición de los Premios Goya de la Academia de las Artes y las Ciencias: premiosgoya.academiadecine.com

En este portal, se pueden consultar noticias sobre los premios, candidaturas, finalistas, información sobre la gala, etc.

Pues bien, a eso de las 9 de la noche, desde la cuenta de twitter @Lulz_Es se anunciaba el volcado de una base de datos "peliculas" perteneciente al dominio de la academia, con un total de 78 tablas en su interior, con nombres tan descriptivos como ACADEMICOS, DISTRIBUIDORAS, USUARIOS, VOTACIONES...

Esta vez, los lulzers se decantaron por el servicio de intercambio de información anonpaste.me, en vez de pastebin como suele ser habitual. Como decíamos, se volcaron algunas de las tablas más características de la base de datos, con información de distribuidoras, actores, productoras, profesionales del medio...incluyendo correos electrónicos, números de teléfono,...

Puede que las prisas en lanzar este sitio informativo para la gala ocasionaron un descuido al no validar correctamente los parámetros de los ficheros php que utiliza la página. Lo que está claro es que si bien la información dentro de premiosgoya.academiadecine.com podría resultar de poca importancia, el compartir la base de datos con otros servicios hace que el impacto de la vulnerabilidad sea mayor. La página de academiadecine.com podría ser la más segura del mundo, pero por culpa de este portal y por no crear otra base de datos únicamente para la información de los premios, y limitar los permisos del usuario a dicha base de datos, se ha conseguido acceder a información sensible de usuarios que seguro que no quieren ver sus WhatsApp o buzones de correo ardiendo en llamas. 

Una simple búsqueda en Google con el sitio, seguido del motor de base de datos utilizado por la página, muestra una pista de la grave vulnerabilidad aprovechada para la obtención de esta información.

Leer más...

Enlaces de la SECmana - 162

• En SeguridadApple nos comentan el método para evadir el bloqueo de PIN en dispositivos iOS versión 6.1
• Acción conjunta entre Policia e Interpol para acabar con el grupo encargado de la estafa Ransomware por excelencia: el virus de la Policia, que te hacía pagar por desbloquear el PC. Diez sospechosos detenidos en la Costa del Sol, ucranianos, rusos y georgianos. ¿Será el fin del virus de la policia?
• Facebook Security descubre que varios de sus empleados visitaron páginas que contenían malware, comprometiendo así sus equipos, gracias a un 0day que se saltaba la Sandbox de Java. En principio, los datos de usuarios de Facebook estarían a salvo y sin problemas aún tras este incidente.
• Corregidas vulnerabilidades en Ruby On Rails con las versiones 2.3.17, 3.2.12 y 3.1.11 
• Interesante post de Frans Rosén en Detectify sobre el proceso de descubrimiento y posterior recompensa de un Cross-Site Scripting en Mega gracias al Bug Bounty iniciado hace semanas.
• Pronto se publicará la agenda completa de las charlas para la próxima HackInTheBox Amsterdam 2013. Entre los ponentes ya se encuentra confirmada la asistencia de Hugo Teso con la ponencia Aircraft Hacking: Practical Aero Series. ¡Enhorabuena!
• Advisory de VMWare acerca de la escalada de privilegios en los productos VMware ESX, Workstation, Fusion y View, tras una manipulación de memoria a través de código WMIC (Virtual Machine Communication Interface)
• En Hack-a-day presentan un proyecto de Raspberry Pi por #madsec que al ser conectado, vuelca los hashes de contraseñas de Windows de los sistemas conectados a la red, utilizando WPAD (Web Proxy Autodiscovery Protocol

Leer más...

Talleres GsickMinds 2013.

Un año más se celebrará en la Universidad de A Coruña  (Facultad de Informática, Campus de Elviña s/n) los talleres de seguridad organizados por GSICKMINDS, (antiguo GSIC), pese a que el congreso se retrasará hasta octubre, la formación intensiva en seguridad y desarrollo web se hará los días 1 y 2 de Marzo.

Los laboratorios serán a cargo de los inagotables expatriados Ángel Prado y Diego Ferreiro. Las plazas suelen agotarse rápido, así que no lo dejéis para el último momento y registraros cuanto antes. Además hacen descuentos para estudiantes y desempleados.

El curso de Ángel  de 12 horas se centrará en seguridad web con un temario bastante ninja:

Introductory Web Security:

• Cross Site Scripting 
• Cross Site Request Forgery 
• Inyección SQL 
• Open Redirection Data URIs 
• Ataques de repetición 
• Ataques de lógica de negocio 
• Webshells, File Inclusion 
• Herramientas - Burp, Fiddler, Wireshark, Malzilla...Seguridad en clientes de correoTesting en aplicaciones móviles (iOS)Metadata extraction, Pastebin and Google/Bing hacking 

Advanced Penetration Testing:

• Password Cracking
• CAPTCHA OCR
• HackingAdvanced SQL Injection & Exfiltration
• PDF malware reverse engineering 
• Kiosk sandboxes 
• Windows Authentication & NTLM 
• Ataques a SSL (SSLStrip, Crime...)

El de Diego, experto en desarrollo web, con otras 12 horas de duración, de javascript:

JavaScript (Parte I)

• Introducción a JavaScript 
• Funciones
• Objetos
• Core: prototyping, scope, and OOP
• Manipulación de DOM
• Plugins y librerias 
• Debugging
• Eventos: bubbling y delegación
• AJAX, SOP, JSONP
• HTML5 APIs

JavaScript Parte (II) (Algunos temas pueden ser opcionales) 

• Progressive enhancement y graceful degradation
• Modulabilidad y escalabilidad de aplicaciones (NPM, packaging)
• Optimación de código (rendimiento, jslint, mimification, cdn)
• Arquitecturas MVC
• NodeJS y V8
•  APIs y comunicación AJAX2, CORS, JSON, JSONP
• Caching avanzado, LocalStorage, Cookie Management
• WebSockets

Leer más...

Fuerza bruta mecánica: Ganando al Mezcladitos jugando de verdad

Disclaimer: Desde Security By Default, no nos hacemos responsables de los malos usos que se puedan extraer de la información explicada en el presente artículo.

El mes pasado, nuestro amigo Lorenzo Martínez nos enseñó como ganar siempre a Mezcladitos interceptando las comucaciones entre el juego y el servidor.

Como soy de ciencias, y en este tipo de juegos llevamos las de perder contra los de letras, y como no me gusta hacer trampas para ganar, decidí buscar una forma de jugar el juego utilizando mis conocimientos técnicos:

Bueno, quizá si sean trampas, pero al menos no estamos hackeando el sistema ;)

Esto es solo una inocente demostración de lo que es la fuerza bruta mecánica. Cuando escuchamos hablar sobre fuerza bruta, la mayoría de las veces nos viene a la cabeza el "ensayo y error" software para atacar contraseñas cifrando y comprobando si son válidas. Sin embargo podemos aplicarla mecánicamente a todo tipo de cosas: teclados virtuales, teclados físicos, roscas, etc.

En esta demostración he jugado al Mezcladitos de Facebook, sin embargo me hubiese gustado disponer de unos cuantos servos y un arduino para jugar directamente sobre la pantalla del iPhone (haciendo un sencillo "tecleador" mecánico).

Lo primero fue crear un algoritmo que resuelve el casillero, buscando por fuerza bruta todas las palabras que contiene basandome en un diccionario con todas las palabras del idioma español.

Dado que tenemos solo dos minutos para jugar, necesitamos calcular las palabras en el menor tiempo posible, así que ademas de optimizar el algoritmo, lo lanzamos en 16 threads (uno por cada casilla) para aprovechar todos los núcleos de nuestra CPU. Dicho algoritmo recorre todos los caminos posibles desde una casilla y comprueba si la palabra resultante en cada uno de ellos existe en el diccionario.

Una vez tenemos todos los resultados, hacemos un hook a bajo nivel del ratón con SetWindowsHookEx, de ese modo puedo moverlo y hacer clicks automatizados para cada palabra.

Como se puede ver en el video, antes de iniciar se hace una calibración haciendo click sobre las dos primeras casillas y el "Enter", para conocer las coordenadas de todas las casillas del tablero.

Hemos hecho fuerza bruta para ganar a un juego, pero podría utilizarse para cosas más serias como ganar acceso no autorizado tanto a sitios web como a lugares físicos, si no utilizan medidas extra de seguridad.

En este caso estamos utilizando el ratón como método de entrada automatizado. Algunos sitios web emplean teclados virtuales para hacer login (incluso algunos bancos) utilizando el ratón. A veces incluso cambian aleatoriamente el orden de las letras o números (nada que no se pueda saltar con un algoritmo OCR). Con ese método muchas veces creen equivocadamente que añaden una capa de seguridad, pero si no limitan el número de intentos se puede hacer fuerza bruta fácilmente (y si te están pidiendo un PIN de 4 números, no tardaría más que unos minutos).

Sin embargo como comentaba antes, disponiendo de un arduino y unos cuantos motores, podemos hacer fuerza bruta sobre prácticamente cualquier cosa de forma muy sencilla y barata siempre y cuando no nos limíte en número de intentos, lo que nos hace preguntarnos cuán seguros son los dispositivos que utilizamos habitualmente, y como muchas veces obvian ciertas medidas de seguridad al pensar que obligando a alguien a introducir datos manualmente no probarán todas las combinaciones. O cuantas veces quitamos nosotros mismos ese número de intentos "por miedo a bloquear nuestro dispositivo nosotros mismos".

En plena era digital, existe mucha gente (especialmente gente mayor, o con pocos conocimientos informáticos) que piensa que lo analógico es más seguro que lo digital, sobretodo cuando cada vez hay más noticias en la prensa generalista sobre incidentes de hacking; así que aquí van unos cuantos ejemplos para romper esa leyenda urbana (Nota: Algunos de estos ejemplos se bloquean despues de un número de intentos, pero los pongo para hacer un muestrario del tipo de cosas que se pueden atacar físicamente):

Moraleja: Si estais implementando algun tipo de mecanismo para restringir accesos, nunca olvideis limitar el número de intentos (el cual en muchas ocasiones es visto como "innecesario" o engorroso), y procurad incluir algún elemento extra como un tarjeta, una llave,...

Si disponeis de algún mecanismo de acceso que limite el número de intentos y os permita deshabilitarlo, nunca lo hagais por comodidad o miedo.

Os dejo el código fuente del programa para los que querais echarle un vistazo (no incluyo los diccionarios). https://github.com/moebiuz/mezclaPWNr

----------------------------------------

Artículo cortesía de Antonio Rodríguez (@MoebiuZ)

Leer más...

Nmap 6: Network Exploration and Security Auditing Cookbook

Que levante la mano quien NO conozca Nmap!!! 

En uno de nuestros primeros posts lo definimos como: LA herramienta de análisis de seguridad remota por excelencia!

En mis asiduas visitas a diversas librerías, he identificado diferentes libros que referencian Nmap por montones; Guías completas dedicadas que podrían valer para una certificación, otros escritos por el propio Fyodor … pero, libros escritos por uno de los desarrolladores/contribuidores de Nmap, y que además aparezca yo junto a un montón de amigos profesionales de la seguridad informática de Latinoamérica en la dedicatoria inicial….. eso hasta ahora no lo había visto nunca en ninguna estantería! 

Así pues, es para mí un honor y un placer, hacer la crítica de este libro, que el autor y amigo Paulino Calderón tuvo a bien enviarme, firmado y dedicado, desde Mexico a Madrid.

La obra está estructurada en 9 capítulos, que explican, como es de imaginar desde cómo se compila e instala Nmap en un sistema operativo, hasta el desarrollo de plugins propios para integrarlos con la herramienta.

Desde el capítulo 2 hasta el 6, se enfoca el desarrollo de una auditoría utilizando únicamente Nmap como plataforma de análisis. Desde la fase de Descubrimiento o exploración de red, se explican los tipos de escaneos posibles en base a los flags utilizados en los paquetes enviados por Nmap, indicando los parámetros a habilitar para cada uno de ellos. 

Posteriormente, se detalla cómo obtener más información sobre los diferentes servicios encontrados, fingerprinting de versiones, integración con servicios de Geolocalización, búsqueda de datos de la organización en registros whois, búsqueda de direcciones válidas de correo electrónico pertenecientes a los dominios analizados, etc,… 

En capítulos siguientes se especifica qué hacer ante servidores web, servidores de bases de datos y servidores de correo electrónico. En un capítulo para cada tipo de servidor, se exponen diferentes tipos de scripts NSE (Nmap Scripting Engine) para llevar a cabo un análisis detallado dependiendo del rol a auditar. 

En el capítulo 7 se sugieren las pautas a tener en cuenta al enfrentarse al escaneo de redes extensas. Asimismo se presenta la herramienta Dnmap para poder efectuar auditorías de redes muy grandes, o cuando simplemente no se dispone del ancho de banda necesario en un mismo nodo de análisis, para llevar a cabo los escaneos de forma distribuida. 

El capítulo 8 habla de los diversos formatos en los que permite Nmap generar la información de una forma ordenada para poder ser reutilizada o post-procesada: normal, XML, SQLite o formato "grepable". 

El colofón del libro, es un detallado capítulo que explica con varios ejemplos cómo desarrollar nuestros propios plugins NSE, que como muchos sabréis, se hace en el lenguaje de scripting LUA.

En definitiva, un libro hecho para públicos con diferentes skills técnicos y de seguridad, puesto que la densidad técnica va incrementándose conforme avanzan los capítulos, pero haciéndose en una lectura rápida y amena, que permitirá a algunos lectores, tanto asimilar muchos de los conceptos que le suenan, aprender cosas nuevas a otros, y pensar en nuevas ideas (me incluyo) a otros.

Quizá si tuviera que destacar algo muy personal, es el modelo cookbook, en el que cada "receta" puede extraerse de forma directa, sin tener que leerse el libro completo. Esto hace que, si te lees el libro del tirón, haya partes repetidas que hay que saltarse…. Supongo que será cuestión de acostumbrarse. 

Recomendable tener a mano boli y papel (yo es que soy un romántico y clásico) para tomar notas, y hacerte tu propio resumen de los diferentes plugins a utilizar/probar en cada momento. 

Lo podéis comprar en la página web de la propia editorial Packtpub o en Amazon. Y sí, en los enlaces podréis elegir entre la versión física en papel o la versión electrónica para vuestro e-book favorito.

Leer más...

Diagnosticando ataques de red

Existen muchas herramientas 'todo en uno' a modo de HIPS para detectar ataques de red, Patriot NG o Marmita -para Windows- son ejemplos de herramientas que simplifican la detección de ataques.

En el post de hoy vamos a realizar nuestro propio sistema de detección de amenazas de red codificando nuestras propias herramientas.

Para realizar los ejemplos me planteé dos opciones: Scapy (Python) o Net::RawIP + Net::Pcap (Perl)

Desde mi punto de vista (totalmente subjetivo y basado en mi apreciación personal) me da la impresión que la opción Perl es mucho mas elegante, la forma en la que está diseñada es coherente en cuanto a las funciones y parámetros y se nota que ha habido una planificación en el desarrollo. En el caso de Scapy, no puedo evitar tener la sensación de que se han ido añadiendo funcionalidades según se iban detectando necesidades y eso, a la postre, hace que emplear esa librería resulte mucho más caótico e incoherente. No puedo evitar cierta sensación de anarquía a la hora de desarrollar con Scapy

Además (y esto es genérico a casi todos los proyectos en Python) creo que a la hora de documentarlos se abusa excesivamente del uso del interprete interactivo. Coincido en que probablemente sea la forma más pedagógica de enseñar, pero me gusta mucho más como se hace en Perl: Un montón de ejemplos + un listado de funciones y parámetros.

A la hora de avanzar rápido resulta más práctico tomar un ejemplo, adaptarlo, y buscar en la lista de funciones lo que falte. Como decía, probablemente sea una forma peor de enseñar, pero es a la que más acostumbrado estoy (y probablemente cualquiera que venga de C o similar también)

Tras estas deliberaciones, ¿Cual ha sido la opción que he elegido? Scapy

¿Motivo? Windows. Creo que hoy día (año 2013) es innegociable que cualquier librería de propósito general tenga soporte para Linux y Windows, casi seguro que dentro de poco se una el requisito de MacOS.

Net::RawIP, aun siendo excelente, NO tiene soporte para Windows, así que, mi querida Net::RawIP, nos hemos querido mucho, hemos hecho cosas muy interesantes, pero nuestro amor toca a su fin, has envejecido mal y no te has sabido adaptar a los nuevos tiempos.

Detectando servidores DHCP Piratas con Scapy

Una de las formas más efectivas de realizar un ataque masivo a una red es emplear un servidor DHCP 'pirata' que envíe configuraciones ad-hoc para nuestros intereses. Chema lo explicó bastante bien en este post.

Tomando como ejemplo base el código publicado en este post, he creado un sencillo script que permite detectar cuando aparece un nuevo servidor DHCP en la red, lo que hace es ir periódicamente enviando 'discovers' y detectando cuando aparece un nuevo servidor.

Tips: Para evitar los molestos mensajes de error sobre IPV6 he añadido:

import logging
logging.getLogger("scapy.runtime").setLevel(logging.ERROR) 

Para eliminar los mensajes de tipo 'Sent 1 packets' basta con añadir:

conf.verb = 0

Detectando ataques de tipo ARP-SPOOF

Los ataques 'MitM' son ya todo un clásico de las maldades que se pueden hacer en una red local, basta con realizar un ataque 'ARP Spoof'.

Para detectarlo, es tan fácil como monitorizar el tráfico ARP en busca de respuestas maliciosas que busquen suplantar al router.

Este script toma como parámetros la IP del router y su MAC (fácilmente conseguibles usando el comando arp)

python arp.py 192.168.0.1 00:50:56:f9:77:cb

Leer más...

El curioso caso de Google y Jazztel

Como muchos otros hallazgos, el que voy a relatar hoy sucedió por casualidad. Estaba configurando una nueva máquina y como probablemente muchos de vosotros, la prueba definitiva de conectividad la hice contra www.google.com (sería genial que algún día Google publicase las estadísticas de tráfico ICMP contra www.google.com ...) 

Apunté el comando ping contra www.google.com y obtuve una respuesta tal que así:

$ ping www.google.com
PING www.google.com (212.106.221.21) 56(84) bytes of data.
64 bytes from 21.221.106.212.dynamic.jazztel.es (212.106.221.21): icmp_req=1 ttl=128 time=19.9 ms
64 bytes from 21.221.106.212.dynamic.jazztel.es (212.106.221.21): icmp_req=2 ttl=128 time=19.0 ms
64 bytes from 21.221.106.212.dynamic.jazztel.es (212.106.221.21): icmp_req=3 ttl=128 time=19.0 ms
64 bytes from 21.221.106.212.dynamic.jazztel.es (212.106.221.21): icmp_req=4 ttl=128 time=18.9 ms

¿Disculpa? ¿ dynamic.jazztel.es ? ¿Cómo es esto posible?

Movido por la curiosidad hice la resolución DNS completa:

$ nslookup www.google.com
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   www.google.com
Address: 212.106.221.26
Name:   www.google.com
Address: 212.106.221.25
Name:   www.google.com
Address: 212.106.221.24
Name:   www.google.com
Address: 212.106.221.23
Name:   www.google.com
Address: 212.106.221.27
Name:   www.google.com
Address: 212.106.221.21
Name:   www.google.com
Address: 212.106.221.22
Name:   www.google.com
Address: 212.106.221.20

Nótese que siempre uso el servidor DNS de Google (8.8.8.8) por lo que en teoría la respuesta ha de ser mucho más fiable.

Comprobando esas IPs 'de google' vía MaxMind se puede ver que todas las direcciones IPs son de Jazztel.

Decidí cambiar de servidor DNS, en este caso usé los de OpenDNS, y si bien en el caso de www.google.com la respuesta parecía ser satisfactoria, estuve probando varios servicios de google y obtuve en varias ocasiones la siguiente respuesta de OpenDNS

$ nslookup www.youtube.com 208.67.222.222
Server:         208.67.222.222
Address:        208.67.222.222#53

Non-authoritative answer:
www.youtube.com canonical name = youtube-ui.l.google.com.
Name:   youtube-ui.l.google.com
Address: 212.106.221.26
Name:   youtube-ui.l.google.com
Address: 212.106.221.23
Name:   youtube-ui.l.google.com
Address: 212.106.221.20
Name:   youtube-ui.l.google.com
Address: 212.106.221.27
Name:   youtube-ui.l.google.com
Address: 212.106.221.24
Name:   youtube-ui.l.google.com
Address: 212.106.221.22
Name:   youtube-ui.l.google.com
Address: 212.106.221.25
Name:   youtube-ui.l.google.com
Address: 212.106.221.21

¡¡ Otra vez las IPs de Jazztel !!

En este punto, lo primero que quise averiguar es si era 'mi' problema o el problema de mas gente. Googleando las direcciones IPs extrañas, encontré este post de bandaancha en el que, si bien el tema que se tocaba no era el mismo, un usuario pasteaba un lookup de www.google.com y obtenía las mismas direcciones IP extrañas que yo.

Así mismo encontré tweets de @Germinen donde mencionaba el mismo tema. Me puse en contacto con el vía twitter y estaba en las mismas que yo.

Comenté el asunto en twitter y encontré a varias personas que obtenían esas mismas respuestas cuando resolvían google.com (la mayoría clientes de Jazztel)

En este punto uno piensa en las posibles 'contramedidas' que, en caso de que esto fuese un ataque, le hubiesen podido salvar: Búsquedas de Google bajo SSL

Es más que conveniente tenerlas activadas. Todas las IPs 'extrañas' tienen un servicio https en el puerto 443, me bajé el certificado que devolvían en la comunicación empleando:

$ openssl s_client -connect 212.106.221.24:443

y ¡ Sorpresa ! El certificado que me devolvía era perfectamente válido y de Google. También pueden hacer verificaciones de certificados empleando el servicio SSL Checker de sslshopper.

Si hacemos la verificación para esa IP:

Podemos ver que es perfectamente 'legal'

Entonces, o bien esa máquina tiene la clave privada del certificado (poco probable) o está redirigiendo la petición hacia alguna máquina de Google.

¿Y qué esta pasando? Bien, aquí va la solución más plausible, aunque deja varias dudas en el aire. De entrada, casi podemos descartar que alguien esté haciendo 'envenenamiento' de DNS o algún tipo de hijack, uno puede pensar que es cosa de Jazztel, pero -y aquí va la parte que mas dudas genera- resulta que yo NO soy cliente de Jazztel, y mi ISP no tiene ninguna relación con el.

La pista mas realista la puso sobre la mesa @Guillermo quien me pasó un enlace hacia la 'Google Global Cache' del que cito:

'User resolves content_host.google.com. (example only)

If the ISP DNS doesn’t already know the IP address, it queries Google DNS for the IP address of content_host.google.com.

Google DNS server knows that this ISP has a Google Global Cache node that should be able to service the request, so it replies with that IP address'

Así que:

1- Asumimos que Jazztel tiene nodos de la Google Global Cache 

2- Damos por hecho que, pese a la fisonomía de las IPs 

(dynamic.jazztel.es), no son ADSLs de usuarios

3- Por algún motivo ¿mala configuración? Google está redireccionándome a mi, que no soy de Jazztel hacia los nodos de dicha compañía

Aunque claro, salvo que alguien confirme por parte de Jazztel eso, sigue siendo todo un tanto oscuro

PD: ¡¡ Muchas gracias a toda la gente que colaboró conmigo en Twitter dando pistas y haciendo pruebas !!

Leer más...