31 marzo 2012

Crónica de la ACK Security Conference: Día 3

 
Teensy board para pentesters y locos por Pedro Joaquín
Pedro Joaquín nos demostró las capacidades de un dispositivo llamado Teensy. Básicamente el dispositivo que simula ser un teclado, por lo que cualquier sistema operativo de los más comunes (Windows, Linux o Mac) por defecto lo autodetectan y lo instalan por defecto (no se considera un medio extraible que tenga un autorun.inf, sino un teclado externo), leyendo las "pulsaciones" por teclado. La gracia del dispositivo es que permite programar una serie de comandos/pulsaciones a enviar al ordenador al que se conecta, permitiendo ejecutar comandos a través del "teclado".

Nos dio varios ejemplos, utilizables para la Playstation, control de un dron, integraciones con Arduino que permiten incluso troyanizar un ratón/mouse, o incluso la creación de un ratón con unas células fotosensibles, de manera que ni siquiera haya que tocarlo. Existe además integración con SET para generar directamente scripts que se pueden copiar a un Teensy para ser utilizados con fines maliciosos. Estos dispositivos se pueden adquirir en pjirc.com por unos 18 dólares.

Después Giovanni Cruz nos enseñó diversos ataques a teléfonos VoIP mediante inundaciones UDP que hacía que, incluso dispositivos con firewall incorporado, se reiniciaran remotamente. Demostró además, diferentes herramientas de ataque a VoIP, como Juno para hacer un Syn Flood a Elastix, el servidor web de gestión de Asterisk, la centralita VoIP, y así dejaba fuera de combate además el servicio de VoIP. Además, con RTPInject por ejemplo, haciendo un MiTM entre la centralita y la víctima, inyectaba audio a la extensión deseada en cuanto descolgara una llamada.


Aplicaciones Web bajo la Lupa por Álvaro Andrade 

En este caso, Álvaro nos dio una interesante introducción sobre cómo las organizaciones añaden montones de dispositivos para dotar de diferentes mecanismos de seguridad a la infraestructura, creyendo que sólo por tenerlos, ya estaba 100% protegida.
Fue una charla bastante académica sobre cuáles son los riesgos de las organizaciones simplemente por tener una cara pública abierta a Internet. Abordó las diferentes fases de análisis de vulnerabilidades en una fase de auditoría web y de sistemas.
Además, hizo varias demostraciones de vulnerabilidades de sitios muy conocidos, incluso reportadas, pero que siguen activas.
Al final, la conclusion fue: "Se necesita una sola vulnerabilidad para desvalorizar la infraestructura completa"


Hackeando con Facebook por Matías Katz

El ponente argentino nos metió el miedo en el cuerpo con su charla hablando de 9 vulnerabilidades encontradas por ellos MKIT, en un servicio tan extensamente utilizado como la red social Facebook. Todas estas vulnerabilidades han sido reportadas a Facebook y se les ha contestado que son funcionalidades y no bugs. Entre otros, enumeración de usuarios, bypass de la privacidad de muros (incluso estando con máximos niveles de privacidad permitidos por Facebook), la inseguridad de las redirecciones en los enlaces publicados en Facebook , modificación de los mismos, cómo suplantar identidad en el envío de mensajes privados a usuarios e incluso a grupos y páginas de fan!!!! (estos últimos hicieron que se me pusieran los pelos como escarpias)…. Sólo diré que es posible a través del envío de correo!
Es absolutamente increible que Facebook siga diciendo que varias de estas vulnerabilidades presentadas tome la postura de: "It's a feature, not a bug!"




El Peligro de la Red Por Roberto Olaya

El ecuatoriano Roberto, habló de Sistemas Informáticos de Inteligencia… Empezó hablando de la red Echelon, mecanismos de interceptación de comunicaciones, nodos que componen la infraestructura, etc,… asimismo otras derivadas como Enfopol, Promis (espionaje financiero), Carnivore (Actividad de correo electrónico y actividad en internet), Linterna Mágica (troyano creado por el FBI que captura pulsaciones de teclado, incluso sin instalar un keylogger). A partir de ahí, y sobre todo del 11-S, la evolución de los sistemas pasó por la creación de la llamada Homeland Security… 
Aparecieron varios proyectos: Rapid Multilingual Support embebido en el casco de los soldados sirve de traducción en tiempo real,  para entender lo que le dicen en cualquier idioma; o Communicator para ver lo que hacen los propios soldados y retransmitirlo a un centro de mando,…  HumanID, para detección de reconocimiento facial, WAE (Wargaming the Asymetric Environment) que son sistemas predictivos de profiling de personas que puedan pertenecer a grupos terroristas,… entre otros programas para la "seguridad nacional".
Después de esta charla, no es que den ganas de cambiarse de país, sino de planeta!


Leer más...

30 marzo 2012

Crónica de la ACK Security Conference: Día 2

Top 10 OWASP vs Sitios Web de Colombia por David Moreno 
Inaugurando este segundo el día, el colombiano David Moreno, especialista en pentesting y con un gran dominio sobre seguridad web, nos ilustró sobre el estado del arte de los Top 10 ataques OWASP y nos demostró la mala protección de varias organizaciones/web con ejemplos de todos y cada uno de los ataques descritos en el Top 10 de OWASP. La conclusión a la que llegamos es que realmente, las medidas de seguridad y malas configuraciones de webs importantes colombianas, es tan relajada como en el resto de los países.  



Welcome to your secure /home, $user! por Lorenzo Martínez
En esta charla el sexy orador español… es decir, yo mismo :D conté las capacidades de Skynet, como programa capaz de integrar diferentes elementos domóticos de manera que me haga la vida más fácil: Roomba, alarma, estación meteorológica, termostatos, webcams, etc,… asimismo, conté cómo crear un sistema de reconocimiento de caras en imágenes, y utilizarlo como elemento de seguridad para detectar intrusos en una casa cualquiera.


Vulnerabilidades en Modems por Pedro Joaquín
Uno de los ponentes que más gratamente me ha sorprendido ha sido Pedro Joaquìn. El mexicano, creador de la herramienta RouterPwn, mostró la realidad de la inseguridad de los diferentes routers que los ISPs distribuyen a sus clientes. Es increible la base de datos de exploits de routers que la propia web www.routerpwn.com te permite lanzar.  Esta herramienta ha sido diseñada como un framework de exploiting, que permite configurar los exploits antes de lanzarlos. Fue programada en HTML puro y Javascript con el propósito de funcionar en cualquier dispositivo. Incluso existe una version en Google Play disponible para Android. El principal problema de las vulnerabilidades en routers caseros es que aùn cuando los fabricantes de los dispositivos ya han corregido las vulnerabilidades, en muchos casos depende del ISP enviar las actualizaciones.



Aventuras y desventuras del análisis de malware por Sebastián Bortnik
Tengo que decir que esta charla, lamentablemente (no me mates Sebas), me la perdí. Sin embargo el encantador y diligente ponente Giovanni Cruz que sí que pudo asistir, tomó notas del resumen para Security By Default. Bajo estas líneas os pego lo que me envió:

"Sebastián nos contó la cantidad de archivos infectados con los que trabajan en los laboratorios de ESET alrededor del mundo diariamente (aprox 200.000 muestras). Dentro de estas revisiones, algunas veces, pueden encontrar interesantes muestras de malware.

Dentro del análisis también es bastante obvio que el malware actualmente desarrollado, se encuentra relacionado con ánimo de lucro, un aspecto netamente economico y que las mayoria de las veces se encuentra relacionado con un delito informatico. Con una muestra especifica de malware, pudieron evidenciar que los creadores de malware, generan restricciones que propagan infecciones dentro de su propio país, con el fin de evitar algún tipo de proceso legal que se pueda generar para ellos.

Una de las grandes conclusiones de esta charla, que fue documentada mediante diferentes demostraciones, fue que mediante ataques relativamente sencillos (phishing, rogueware), es posible obtener información o lucro (o ambas cosas). Además, se evidenció que la necesidad de sensibilización cada vez es más latente.

Otra interesante conclusión fue la utilización de binarios con pequeñas modificaciones, para hacer cambios (sobre todo estéticos) a piezas de malware con el fin de engañar a sus víctimas.

Por último... y, como una gran conclusión que se conoce a gritos, es la utilización de permisos elevados en equipos Windows, que dan mayor facilidad a un atacante para poder usar una máquina a su antojo como el ejemplo de la botnet más grande en latinoamerica: Dorkbot" 

Muchas gracias Giovanni!




Wi-fi: Un mal karma! por Andréz Lamoroux
El simpático colombiano introdujo su charla con diversos tipos de ataques de red, aplicables a tráfico wireless.
Casi toda la charla fue práctica, utilizando backtrack y pineapple, simuló un punto de acceso falso, con un nombre conocido… Por otra parte, mediante SSLStrip, Hamster, URLSnarf, Driftnet,... era muy divertido ver a lo que la gente se conectaba (en general, porno).
Como digo, una charla eminentemente práctica, que educó a la audiencia sobre lo peligroso que pueden resultar las redes públicas inalámbricas



Detectando intrusiones en la Red. Más allá del IDS por Roberto Martínez 
Muy en la línea del taller que impartí en el primer día de ACK, titulado "Buenas Prácticas de Seguridad en entornos corporativos", el mexicano Roberto Martínez comenzó mentando compromisos en empresas de seguridad, haciendo hincapié en una de las protagonistas de los escándalos más sonados del 2011: RSA. En unas cuantas transparencias evidenció los pasos utilizados para el APT del que dicha organización fue víctima. La parte de Demo que llevó a cabo Roberto, explicó cómo combinar ingeniería social, para lograr engañar a un usuario, mediante un ataque APT, que ejecute un sencillo "juego" para que ejecute una conexión HTTPS contra una máquina que espera con Metasploit,... y a partir de ahí, abrir una sesión que permita acceso total al sistema de la víctima.
La conclusión fue bien clara: no importa cuántas soluciones se incluyan en la seguridad perimetral de una organización, al final el eslabón más débil sigue siendo el sentido común (o la falta de éste) por parte de los usuarios.




Leer más...

29 marzo 2012

Crónica de la ACK Security Conference: Día 1

Benefits of making a Good Impresion por Deviant Ollam

Deviant Olle nos dio una charla de seguridad física. Nos contó que su compañía vende servicios de auditoría de seguridad física. Nos preocupamos mucho sobre la protección de los accesos remotos mediante la red…. pero, si alguien es capaz de acceder físicamente a nuestos equipos, porque la protección mediante llave/RFID/banda magnética, la seguridad de los datos se ve comprometida. Deviant explicó, con gran esfuerzo en hablar español, el funcionamiento genérico de las cerraduras, y cómo están formadas por diferentes pines y cómo con una ganzúa se van subiendo de uno en uno todos los pines para hacer que la cerradura se abra. 

Su amigo "Babak" nos demostró cómo clonar una tarjeta RFID, a cierta distancia, mediante una placa opensource, y una antena de alta y baja frecuencia, que permite leer una tarjeta RFID, memorizar la información y reproducirla para poder abrir una cerradura.



Reversing Malware por Alfonso de Luque

En este caso, un brillante estudiante de matemáticas de 22 años recién cumplidos, empezó diferenciando diversos tipos de malware: Virus, Gusanos, Troyanos, etc,... Continuó su charla pasando a una ventana con OllyDbG para explicarnos cómo analizaba cierto tipo de malware realizado por él, que era invisible a cualquier antivirus. De hecho, descargó las últimas versiones de McAfee y Panda, y activando los módulos heurísticos incluso, ninguno de ellos lo detectaba como malicioso.




Amenaza no tripulada por Leonardo Pigñer

Muy interesante charla en la que Leo nos contó muy amenamente, las deficiencias existentes en diversos Drones o aviones no tripulados. Comenzó el argentino contándonos los diversos tipos de drones que existían: RQ-170, el sistema Predator, Globalhawk, etc,... y nos sorprendió con información que todos pensaríamos que sería clasificada, referente al funcionamiento de los diferentes sistemas implicados en los drones, funcionamiento de mira láser, protocolo de comunicaciones de red en los sistemas de los drones, etc,... Hizo especial hincapié en que esta información está accesible para cualquiera que sepa buscar a través de Internet.

Fue una charla muy divertida que me recordó bastante a la de Hugo Teso en RootedCon2012.



Informática Forense como Herramienta de Apoyo contra los Delitos Informáticos por Álvaro Andrade

Este simpático abogado informático boliviano, nos introdujo en un tema que da para un Congreso completo hablando de ello: Informática Forense. Fundamentalmente, Álvaro nos contó cómo trabaja para poder traducir o simplificar la recogida de evidencias forenses para que sean válidas en un caso judicial.

Para demostrarnos los procedimientos correctos para llevar a cabo la extracción de pruebas incriminatorias en un juicio, nos contó un caso real, en el que un hombre, colgó en Internet videos con contenido sexual explícito mantenido con su ex-pareja. Acto seguido, el individuo, envió por SMS a un montón de amigos, la dirección donde estaban accesibles los videos. La víctima, claro está, denunció a su ex-pareja, y se encargó el análisis pericial a la empresa de Álvaro.



Leer más...
Introducción

EMET es una herramienta que mejora la protección de aplicaciones de terceros y binarios propios de Windows mediante siete técnicas de mitigación. Funciona inyectando una DLL (de 32 o 64 bits) en cada proceso de la aplicación protegida.

En este texto se habla varias veces de compilar con un cierto flag los fuentes de una aplicación. Aunque se utiliza ese término, la fase exacta sería la de enlazado y no de compilación.

Mitigaciones de seguridad


- DEP

Solución hardware y software para prevenir la ejecución de código en páginas de memoria que que no han sido marcadas explícitamente como ejecutables, ya que típicamente se usan para datos (stack, heap). Para esto marca como no ejecutables la pila y el heap, de forma que cualquier intento de ejecución de código en estas zonas será denegado a nivel de procesador. Para utilizar DEP la CPU debe soportar la desactivación de ejecución (XD en Intel y NX en AMD).

En principio sólo se podía hacer uso de DEP si una aplicación había sido compilada con el flag correspondiente /NXCOMPAT. EMET posibilita su uso sin necesidad de recompilar la aplicación; para esto llama a SetProcessDEPPolicy desde el proceso en cual se inyectó la DLL de EMET. En CPUs de 64 bits sobre Windows de 64 bits siempre está activo y no se puede desactivar. Por lo tanto si se invoca a SetProcessDEPPolicy en estas CPUs se produce un fallo.

Se puede evadir mediante una técnica llamada return-to-libc, en la cual se sobreescribe la pila para apuntar a código de librerías (por ejemplo, system en glibc). En este caso no se ejecuta código en la propia pila, y por eso se puede bypassear. Sucede algo parecido con la técnica ROP, donde tampoco se busca ejecutar código en la pila.

Para realizar la técnica ROP es necesario tener el control de la pila. La idea es aprovechar pequeños trozos de código (instrucciones) que ya están en memoria para construir el payload deseado. Para ello se escriben en la pila las direcciones de las instrucciones que interesan. A esto se le llama ROP-gadgets. Éstas instrucciones se ejecutan sin problemas, ya que están ubicadas en páginas de memoria marcadas con permisos de ejecución (NX=0). Finalmente se escribe la shellcode en una zona ejecutable, que previamente estaba en la pila, y se salta a ella. Se puede escribir sobre la sección de código en JIT, ya que requiere que los permisos que se utilicen sean rwx. Sino, se puede hacer uso de VirtualAlloc para establecer todos los permisos o dar permisos de ejecución con VirtualProtect.

Se podría hacer que todo el exploit funcionara a base de ROP puramente, pero típicamente se hace uso de él solo durante la primera fase. Es decir, se persigue como objetivo ejecutar el código que hemos copiado en la pila y no construirlo mediante ROP-gadgets.

Visto que existen técnicas para evitar DEP, es conveniente además hacer uso de otras técnicas de mitigación (ASLR, SHEOP, MIC) para convertirlo en realmente efectivo. Por ejemplo, mediante ASLR el atacante no podrá encontrar las posiciones de memoria donde están situados los ROP-gadgets.

DEP se puede configurar de cuatro maneras diferentes:

  • optIn: sólo afecta a binarios de Windows y a aplicaciones que explícitamente lo indiquen. Los binarios de 64 bits son la excepción, ya que siempre serán protegidos a menos que se indique lo contrario mediante optOut.

  • optOut: afecta a todos los binarios, tanto de Windows como de terceros. Se puede indicar explícitamente que algunos binarios no se vean afectados.

  • AlwaysOn: se aplica a todo el sistema haciendo caso omiso de las excepciones optOut.

  • Disabled: se desactiva totalmente haciendo caso omiso de las excepciones optIn.


- ASLR

En Windows los ejecutables (EXE y DLL) en principio se cargan en memoria en la dirección base establecida en tiempo de compilación que consta en el propio fichero. Para prevenir la explotación de vulnerabilidades mediante ASLR se aleatoriza esta dirección, de forma que no se utiliza la indicada en el ejecutable.

Es necesario distinguir dos implementaciones de ASLR. La que realiza el propio Windows trabaja con módulos que han sido compilados con un flag específico (IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE), y aleatoriza la dirección base con hasta 256 posibilidades. La segunda implementación es la ofrecida por EMET donde no se necesario indicar nada en tiempo de compilación, y por lo tanto no hace falta recompilar la aplicación. Esto es, si un ejecutable no soporta ASLR de forma nativa, mediante EMET se asigna la dirección de memoria base donde se carga el ejecutable de forma que el cargador de imágenes tenga que buscar una nueva dirección. A esto se le llama Mandatory ASLR (pseudo-ASLR), y tiene una menor entropía que ASLR real: 4 bits frente a 8 en ASLR nativo.

Mandatory ASLR usado conjuntamente con la técnica de mitigación Bottom Up Randomization, implementado en la versión 2.1 de EMET, ofrece una gran protección. La entropía obtenida es la misma que con ASLR real, y además la dirección base cambia cada vez que se inicia la aplicación. Con ASLR nativo esto no ocurre, y además es necesario un reinicio.

En EMET la mitigación Mandatory ASLR fuerza la relocalización de DLLs que han sido cargadas posteriormente a EMET.DLL. Por lo tanto no se aleatoriza con EMET ni la propia imagen core ni las librerías estáticas empotradas en él. Cuando EMET se carga hace un hook a LdrLoadDll y comprueba por cada módulo que se vaya a cargar el bit IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE. Si no está presente implica que la DLL no ha sido enlazada con el flag ASLR, por lo tanto se fuerza pseudo-ASLR preasignando una página de la dirección base para que el operativo la cargue en otra dirección.

Para comprobar si EMET está funcionando correctamente con ASLR podemos usar Process Explorer de la suite Sysinternals. Primero hay que tener en cuenta que los módulos que marca como ASLR son los que han sido compilados específicamente para ello; es decir, aquellos con los que trabaja Windows y no EMET. Para poder ver los que EMET ha forzado la relocalización hay que ir a Options-Configure Colors y activar Relocated DLLs. Después indicaremos que queremos que se muestren las DLLs mediante View-Show Lower Pane y finalmente View-Lower Pane View-DLLs. Entonces al pinchar sobre un proceso protegido con ASLR en EMET, si no utiliza DLLs compiladas con dynamic base, veremos que han sido relocalizadas mediante EMET (las mostrará de amarillo si se utiliza el color por defecto).

Artículo cortesía de David Montero  
Leer más...

28 marzo 2012

Cómo detectar quién juega con tu RDP


Ha sido uno de los bugs que marcarán el 2012: El bug del protocolo RDP que permite comprometer remotamente cualquier sistema Windows. Esta vulnerabilidad, para la que hay varios exploits públicos y que está siendo activamente explotada, es sin duda una de las vulnerabilidades más crítica que ha sido publicada recientemente para sistemas Windows.

Dado que a día de hoy es uno de los bugs que más interés despierta (y una vez añadido el exploit a metasploit, con más razón) viene bien monitorizar quien está 'jugando' con el.

Para ello, vamos a usar Patriot NG y su característica de monitorización de intentos de conexión a puertos.

El primer paso es detener Patriot, para ello buscamos el tray


Con el botón derecho del ratón seleccionamos 'stop'



El siguiente paso es añadir el puerto del RDP (3389) a la lista de puertos calientes, para ello nos situamos en:

C:\Archivos de programa\Patriot NG

Donde podemos localizar un fichero llamado 'destports.ini'


Una vez ahí, editamos el fichero con notepad y vemos que la estructura del fichero es bastante sencilla: [puerto]

Por tanto, añadimos el puerto al final del fichero:


Salvamos y desde el tray, volvemos a arrancar Patriot:


Con esto ya tenemos configurado Patriot para detectar intentos de conexión a ese puerto, cada vez que alguien lo intente, podremos ver el intento y bloquear la IP

Leer más...

27 marzo 2012

Agresión a la libertad de expresión

Cuando se habla de libertad de expresión, es bastante común asociar ese concepto al periodismo y en general al mundo de las letras. De lejos, no parece algo que pueda afectar a un colectivo con inquietudes técnicas.

Nada mas lejos de la realidad, la libertad de expresión es mucho más que eso. Es tu libertad para poder contar tus hallazgos e investigaciones sin el miedo a recibir 'un aviso' de índole legal para que omitas los detalles de algo que, en la mayoría de los casos, son negligencias de una empresa.

En este blog se han publicado demoledores artículos sobre muchos productos y siempre nos ha gustado el poder expresarnos sin cortapisas, con la posibilidad de explicar las cosas pudiendo dar nuestra opinión, en muchos casos adjuntando código o detalladas explicaciones sin miedo al 'toque de atención'

Y todo esto viene a colación de la ridícula demanda que ha interpuesto  Promusicae a Enrique Dans, persona que como todo el mundo sabe, lleva mucho tiempo comprometido con la defensa de los derechos de los internautas frente a ciertos 'lobbys' que abogan por un Internet mucho mas estrecho.

La demanda viene por lo dicho en este párrafo:

'porque muchos de los participantes en el turbio entramado de la propiedad intelectual en España actúan de manera completamente inadecuada, vulnerando las leyes de la competencia o las prácticas razonablemente exigibles a toda empresa. Promusicae, por ejemplo, vulnera abiertamente las leyes antimonopolio creando un sistema, RitmoNet, que da lugar a un entorno donde solo las discográficas pertenecientes a la asociación pueden de hecho tener llegada a un canal de promoción tan importante como la radio… y no solo no pasa nada, sino que el gobierno lo sabe, lo ampara y hasta lo financia parcialmente'

Sirva esta cita como suscripción plena de lo dicho en ella.
Leer más...

26 marzo 2012

¿Arruinamos a WhatsApp?

Después de los distintos post sobre la inseguridad de esta aplicación que han venido haciendo los compañeros de SecurityByDefault, hago este pequeño artículo que explica la posibilidad de realizar envíos masivos de SMS empleando la plataforma que brinda WhatsApp.

El mantener una plataforma de mensajería abierta y gratuita, cuesta mucho dinero. Si a esto se le suma provocar un gasto no contemplado de manera constante, podría acabar con el modelo de negocio que tienen a día de hoy.

Cuando un cliente se instala por primera vez la aplicación, o bien cambia de terminal, este tiene la obligación de solicitar un código de seguridad para verificar que ese número de teléfono es el correcto y prevenir un ID Spoofing.


La URL empleada para la solicitud del código es la siguiente:
https://r.whatsapp.net/v1/code.php?method=sms&to=34600000000&in=600000000&cc=34&mcc=000&mnc=000 

Se especifica en la primera variable "to=" el número de teléfono con el prefijo internacional (34 para España), y en la segundo "in", sin el prefijo. En "cc=" volvemos a poner el prefijo, y las variables "mcc/mnc" son datos de la operadora telefónica y las dejaremos a cero-cero-cero.

Con la creación de un script muy básico, se puede realizar un envío a los 10 millones de teléfonos móviles españoles que tienen WhatsApp instalado.

Empresas como esta, emplean pasarelas de envío de SMS a un precio mucho más bajo del establecido por las operadoras de telefonía, con lo que si el precio que paga esta empresa por SMS lo situamos en 0,01€, cada vez que ejecutemos el script, provocaríamos un gasto de 100.000 euros. En realidad, seguro que pagan mucho menos dinero por SMS, pero también tenemos la posibilidad de enviar muchos más SMS de manera global a otros países, tan sólo valdría con cambiar el prefijo...

Código del script realizado por @chencho:



Este script nos generará un fichero DATA, donde veremos a qué teléfonos les ha llegado el SMS con el Status "success-sent" o bien han fallado por demasiados intentos en un corto espacio de tiempo y no se enviará.

No se ha llegado a probar sobre un escenario real, ya que posiblemente se banearía la dirección IP. Esto no deja de ser una prueba de concepto, y por tanto me exonero de toda responsabilidad por su mal uso, ya que podría haber serios problemas legales.

De hecho, antes de la publicación de este artículo, se ha informado debidamente al Grupo de Delitos Telemáticos de la Guardia Civil,  que ha trabajado de manera impecable dando a conocer a WhatsApp este problema en tiempo récord para una solución lo más rápida posible.

A día de hoy la vulnerabilidad sigue existiendo, por lo que una vez más, la seguridad de esta aplicación y  su gestión de incidencias quedan en evidencia.

Al final van a tener que poner el WhasApp de pago...
------------------------------------------------------------------------------------------------
Artículo cortesía de Omar Benbouazza Villa
Leer más...

25 marzo 2012

Enlaces de la SECmana - 116


    Leer más...

    24 marzo 2012

    ¡¡ Ya somos 10.000 !!



    We are SecurityByDefault, we are a legion!

    Como muchos ya habéis notado, hemos añadido un pequeño contador de gente inscrita a nuestro feed de RSS en el menú lateral, que según Feedburner, ronda las 10.000 personas desde hace un par de semanas. A este número redondo hay que sumar las 1.500 personas inscritas por correo electrónico, con una media de visitas de lunes a viernes de 7.000, con picos de 10.000 que entran a vernos a diario usando la página web y los 7.000 followers de twitter. 

    Este contador dinámico, pese a ser una imagen horrible, se ha convertido en nuestro orgullo y hemos querido dedicar toda una entrada para compartirlo con vosotros, celebrarlo y agradecéroslo, ya que todo el mérito es vuestro, por referenciarnos en el boca a boca y en las redes sociales, mandarnos mails con ideas, enlazarnos desde vuestras páginas webs, escribirnos comentarios y mandarnos artículos.

    Sabemos que solo son números, pero en cierto modo es nuestro termómetro para saber que lo vamos haciendo bien y que el contenido os gusta. Seguro que es mejorable en muchos aspectos y seguimos intentandolo. Estamos hasta en la sopa y lo seguiremos estando mucho más tiempo.

    Una vez más: gracias a todos

    NOTA: No os preocupéis que el inscrito número 10.000 no  ha recibido un correo electrónico avisándole de que le ha tocado un nuevo iPad si pinchaba en un enlace corto que llevaba a una página que descargaba un ejecutable. 

    Leer más...

    23 marzo 2012

    Desarrollando para Metasploit (II) : Módulos auxiliares

    Buenas otra vez, en nuestro post anterior hicimos una breve introducción al desarrollo de módulos de Metasploit programando el típico “Hola mundo”, en éste vamos a profundizar un poco más en el tema centrándonos en los módulos “Aux” (auxiliares). Recordamos que este tipo de módulos sirve para implementar casi cualquier cosa debido a la flexibilidad en la definición de sus interfaces.

    Un tema del que no hablamos y es muy importante son los “Mixins”, su finalidad es evitar la duplicidad del código que se comparte entre módulos, los hay que ayudan en la implementación de escáneres para distintos protocolos ("Msf::Auxiliary::Scanner"), para exploits de fuerza bruta ("Msf::Exploit::Brute") e incluso para exploits remotos de un protocolo específico ("Msf::Exploit::Remote::Ftp"). Esto supone un claro aumento en la velocidad de desarrollo por apoyarse en un número cada vez mayor de módulos probados. Como siempre, en la guía del desarrollador y en la documentación de la API tenemos una referencia mucho más precisa sobre los mismos.

    En esta ocasión vamos a comentar el código de un “flooder” típico para el protocolo UDP, es muy sencillo también pero utiliza “Mixins” y tiene algunas funciones definidas. Con esto tenemos lo necesario para comprender la estructura general de los módulos auxiliares, a partir de aquí se pueden complicar en mayor o menor medida dentro de la función “run()” dependiendo del vector de ataque que esté siendo implementado.

    Código:
    -----------------------------------------------------------------------------------------

    -----------------------------------------------------------------------------------------
    Diferencias a señalar respecto al código de nuestro Hola mundo anterior:

    - Al inicio tenemos dos “include” para cargar los “Mixins”, en un principio podemos verlo como la típica librería de cualquier lenguaje de programación, si necesitamos una función que implementa debemos de cargala antes de usarla. En nuestro caso necesitamos el “Msf::Auxiliary::Dos” para poder usar la función “capture_sendto(p,rhost)” en el método “run()” y en el caso de “Msf::Exploit::Capture” no se carga porque necesitemos ninguna función pero sí por ser necesario para indicar que se trata de un módulo auxiliar de tipo DOS. ¿Con que objetivo? Pues por ejemplo para evitar que se ejecute este módulo durante procesos automáticos, lo cual suele ser una buena idea para los “flooders”.

    - El método “initialize()” es similar al módulo de la vez anterior pero encontramos que se utiliza el “deregister_options('FILTER','PCAPFILE','SNAPLEN')”. Los “Mixins” resgistran automáticamente algunas opciones, en algunos casos necesarias para la ejecución del módulo, por lo cual si no les damos ningún valor éste no se ejecutará. Si nos fijamos vemos que la opción “RHOST” no la creamos, ésto es porque ya lo hace el “Mixin”. “Msf::Exploit::Capture” registra automáticamente las opciones “FILTER”, “PCAPFILE” y “SNAPLEN” debido a que normalmente se utiliza para implementar ataques que precisen alguna captura de red, en este caso no son necesarios así que los desregistramos.

    - A continuación se definen varias funciones que convierten el tipo del valor asignado a cada opción o le asignan uno aleatorio si no se le proporcionó al llamar al módulo.

    - El código termina con el método run(), echándole un vistazo a la documentación del método “UDPPacket()” de la librería PacketFu de Ruby vemos que se codificaría como cualquier otro programa escrito en este lenguaje. Usamos ésta en lugar de abrir un socket UDP porque en este caso no queremos establecer una conexión completa si no crear un paquete manipulado para enviarlo y si no recibimos la respuesta mejor (para eso spoofeamos la dirección IP de origen, entre otras cosas), ya que si no nos podríamos “floodear” a nosotros mismos xD.

    Para terminar, en las imágenes siguientes podemos ver una muestra de su funcionamiento, vemos que envía un paquete UDP del tamaño especificado (256 bytes) con la dirección spoofeada. También se observa que aleatoriza la dirección Ip de origen entre peticiones así como el puerto de salida mientras que el servidor, como especifica la definición del ataque, responde con un “ICMP Unreachable” a cada petición.





    Pues nada más por esta ocasión, en las siguientes implementaremos una PoC que dispare un DoS y otra que explote un stack buffer overflow. Hasta la próxima. :)

    Artículo cortesía de Jesús PérezRoi Mallo
    Leer más...

    22 marzo 2012

    Vuestros "ETHERNET EXPOSED" - XI


    Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

    En esta ocasión, hablaremos de 4 nuevas contribuciones, enviadas por David Noci, Fernando Corvalan, Victor Fernández y un usuario anónimo.

    En primer lugar, David Noci nos cuenta los siguiente:

    "He aquí una posible aportación... de un banco con nombre de capital cántabra en el centro comercial SPLAU! en Cornella, el que está en el campo del Español y en el que ese mismo dia había partido.


    El cajero está justo a la salida del parking.


    Me atrevo a decir que han hecho strike y de los buenos, ya que parece haber una línea principal con un RJ45 (sea ETH o RDSI), con su correspondiente backup típico conmutado (RJ11) e incluso el RJ11 de la alarma del cajero desplazado, en fin... muy chulo para un centro comercial con cines abierto hasta la noche."


    Cada vez es más típico encontrarse cajeros con sus tomas de red de manera externa, en vez de incluir toda su instalación y cableado dentro de la propia "caja" del cajero no permitiendo el acceso a las bocas (y por consiguiente a su red interna).

    Es el turno del Ethernet Exposed que nos envía Fernando Corvalan, con la siguiente descripción de la foto que mostramos a continuación:


    "Aqui les mando un Ethernet Exposed desde Rosario, Argentina para  http://www.securitybydefault.com/2011/04/ethernet-exposed-encuentra-tomas-de-red.html

    Esta en un supermercado "Jumbo" en uno de los centros comerciales mas concurridos de la ciudad."

    Estamos ante un nuevo caso de dispositivo para comprobar los precios mediante código de barras, que necesita realizar la consulta, seguramente, contra un servidor de la red de supermercado para recuperar los datos que se deben mostrar al usuario. Quizás ese bañador nos permitiría esconder algo, poniéndolo encima, durante un período determinado de tiempo, que se conectase a la red y descubriese a que se tiene acceso...arriesgado pero no imposible.

    Victor Fernandez nos envía el siguiente correo electrónico a nuestra cuenta de contacto:

    "En la planta baja de la biblioteca de la facultad de ciencias economicas de la universidad de Vigo se puede encontrar esta cajita. No existe ninguna vigilancia en la sala, no suele haber gente y la caja esta abierta. Se puede mejorar? Pues si, los profesores suelen tener una pegatina en la pantalla de los ordenadores con toda la información para conectarse a la red lo cual a más de uno le seria util."




    En esta ocasión, lo que nos manda Victor es más que un ethernet exposed. Esta electrónica de red al parecer está bastante disponible, no sabríamos realmente si su configuración dejaría poder utilizar otras bocas, si existe algún control en las interfaces, etc, pero no deja de resultar curioso tener un dispositivo así tan al alcance de cualquiera, cuando debería encontrarse en un sitio un poco más...recogido.

    Por último, terminamos con la última aportación de hoy, por parte de un usuario anónimo, que se ha encontrado lo siguiente en la propia calle....no tiene desperdicio:

    "Me gustaría compartir con Ustedes una imágenes que capturé con mi Iphone, MAKRO es un hipermercado de mi ciudad, tiene bastante vigilancia, cámaras de seguridad, personal de civil, vigilancia privada, sin embargo los ingenieros de sistemas dejan al descubierto los puntos de red en el parqueadero."





    La instalación es bastante peculiar, poco que comentar la verdad quizás no se vean las tomas ethernet como tal, y la vigilancia que hay por la zona deje jugar poco, pero la colocación, sujeción y cableado del dispositivo es de traca, ingeniería punta.

    Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos!
    ---------------



    Leer más...

    21 marzo 2012

    Construyendo un sistema firewall/antispam telefónico

     
    ¿Cuántas veces os ha sonado el teléfono fijo interrumpiendo la comida, despertándoos de la siesta, o incluso hecho salir del baño porque un sistema de telemárketing "avanzado" llama aleatoriamente tu número para ofrecerte un mejor ADSL, cobertura de noseque seguro, una tarjeta de crédito nueva, o vaya usted a saber?

    Bueno pues a mí unas cuantas. Además, desde que tengo la oficina en mi propia casa, es un coñazo soberano la cantidad de molestas llamadas "spam" personas o bots. Antes, tenía un pool de actitudes a tomar cuando recibía estas llamadas, pero ahora, todo esto ha cambiado.

    En el móvil, ya instalé una aplicación como la que comentamos tiempo atrás para evitar el Spam via SMS, y para casa, desde que monté una centralita con Asterisk con el ATA Linksys con el que simulaba hacer llamadas como si estuviera en mi casa/oficina, quien contesta las llamadas es el propio Asterisk. He de decir, que lo de las centralitas VoIP es todo un mundo y me ha sorprendido, muy gratamente, la cantidad de cosas que se puede hacer con ellas.

    En el briconsejo de hoy, vamos a ver cómo se puede hacer para que sea la propia centralita quien filtre las llamadas, blacklisteando números de teléfono origen de los que no queremos oir hablar.

    Dentro del propio interfaz con FreePBX, hay una sección Blacklist, donde se pueden ir añadiendo aquellos números que consideremos molestos.




    Incluso, podemos habilitar el check para que bloquee directamente aquellas llamadas con número oculto (ojo si recibís llamadas internacionales, que a veces entran con CallerID oculto).

    Por otra parte, y con fines más dinámicos, puede que quiera añadir un número a la blacklist, simplemente usando la línea de comandos que tanto me gusta, o delegarlo como un comando más a mi bot GTalk.

    Así que me hice un script, en Perl, que interactúa con el módulo de gestión de la centralita, de manera que pueda pasarle el número de teléfono origen que quiero bloquear.


    #!/usr/bin/perl
    use Asterisk::AMI;
    
    #Vars Asterisk
    my $IP_asterisk="192.168.52.47";
    my $peerport_asterisk="5038";
    my $username_asterisk="admin";
    my $secret_asterisk="esperasentadoqueteladigoeh";
    #/Vars Asterisk
    
    
            my $astman = Asterisk::AMI->new(PeerAddr => $IP_asterisk,
                                            PeerPort => $peerport_asterisk,
                                            Username => $username_asterisk,
                                            Secret => $secret_asterisk
                                    );
    
            die "Unable to connect to asterisk" unless ($astman);
    
            my $quehacer=$ARGV[0];
            my $phone=$ARGV[1];
    
            my $lecommand=undef;
    
            if ($phone)
            {#Hay un telefono leido
                    if ($quehacer eq "block")
                    {
                            $lecommand="database put blacklist $phone 1";
                    }
                    elsif ($quehacer eq "unblock")
                    {
                            $lecommand="database del blacklist $phone";
                    }
                    else
                    {
                            die "Usage: $0 <block || unblock> <phone>";
                    }
    
                    my $action = $astman->send_action ({ Action => 'Command',
                                                     Command => $lecommand
                                                     });
    
                    my $response1 = $astman->get_response($action);
    
                    print "$response1->{'CMD'}[0]\n";
                    #printamos la respuesta
            }
            else {die "Usage: $0 <block || unblock> <phone>";}   
    
    

    En mi caso, llamando con oculto, el Linksys SPA3102 (recordad que es el dispositivo que me reenvía la señal de línea analógica convertida en VoIP a mi Asterisk) lo que mi centralita ve es SPA, que es el alias que le configuré, por lo que tampoco vale la opción "block" que introducía FreePBX. Si intentas añadir manualmente una entrada identificada con letras, FreePBX comprueba mediante Javascript que sea un número y lo bloquea. Sin embargo la API de Asterisk sí que lo permite.

    Hasta ahora, cada vez que me llamaban (e importunaban) apuntaba el número, lo googleaba el número de teléfono y lo guardaba en un fichero de texto. Casi todos hasta ahora han sido de una empresa contratada por Jazztel (pesados!) y Citibank. Investigando por listas de spam telefónico, hay incluso una especie de ranking con teléfonos de mala reputación, al estilo de las listas de reputación IP como las ofrecidas por Alienvault.

    Me he hecho otra herramienta que parsea diariamente el listado de "Top spam" ofrecido por la web  http://www.listaspam.com que, diariamente parsea el Top 10 y, si son números de teléfono de España, los blacklistea directamente en mi Asterisk:


    #!/usr/bin/perl
    use strict;
    use LWP::UserAgent;
    use Asterisk::AMI;
    
    #Vars Asterisk
    my $IP_asterisk="192.168.52.47";
    my $peerport_asterisk="5038";
    my $username_asterisk="admin";
    my $secret_asterisk="esperasentadoqueteladigoeh";
    #/Vars Asterisk
    
    
    my $astman = Asterisk::AMI->new(PeerAddr => $IP_asterisk,
                                    PeerPort => $peerport_asterisk,
                                    Username => $username_asterisk,
                                    Secret => $secret_asterisk
                             );
            die "Unable to connect to asterisk" unless ($astman);
    
    
    
    sub blacklistea
    {
            my $lecommand="database put blacklist $_[0] 1";
            my $action = $astman->send_action ({ Action => 'Command',
                                             Command => $lecommand
                                                     });
    
            my $response1 = $astman->get_response($action);
    
            print "$response1->{'CMD'}[0]\n";
    }
    
    #MAIN
    
    my $url="http://www.listaspam.com";
    
    my $browser= LWP::UserAgent->new;
    my $response = $browser->get($url);
    
    if ($response->is_success)
    {
            my $web=$response->content;
    
            my @cachos=split (/Top spam<\/p>/,$web);
            my @trozos=split (/\<\/a\>\\<\/ul\><\'item_top\'\>/,@cachos[1]); 
            my @mascachos= split (/Telefono=/,@trozos[0]); 
            @mascachos[0]=undef;
            foreach (@mascachos) 
            { 
                  my @trocitos=split(/>/,$_); 
                  if ($trocitos[0] =~ /^[6-9]\d{8}/)                 
                  {
                      print "$trocitos[0]\n";               
                      blacklistea ($trocitos[0]);                 
                  }
            }
     }

    Si además queremos poner una grabación personalizada de bienvenida a este tipo de llamadas, podemos hacerlo modificando en el fichero /etc/asterisk/extensions_additional.conf en la sección siguiente

    [app-blacklist-check]
    include => app-blacklist-check-custom
    exten => s,1,GotoIf($["${CALLERID(number)}" = "Unknown"]?check-blocked)
    exten => s,n,GotoIf($["${CALLERID(number)}" = "Unavailable"]?check-blocked)
    exten => s,n,GotoIf($["foo${CALLERID(number)}" = "foo"]?check-blocked:check)
    exten => s,n(check-blocked),GotoIf($["${DB(blacklist/blocked)}" = "1"]?blacklisted)
    exten => s,n(check),GotoIf($["${BLACKLIST()}"="1"]?blacklisted)
    exten => s,n,Set(CALLED_BLACKLIST=1)
    exten => s,n,Return()
    exten => s,n(blacklisted),Answer
    exten => s,n,Wait(1)
    exten => s,n,Zapateller()
    exten => s,n,Playback(ss-noservice)
    exten => s,n,Hangup
    
    ; end of [app-blacklist-check]
    

    En este bloque cambiar la línea  "exten => s,n,Playback(ss-noservice)" por "exten => s,n,Playback(ss-spam)"

    Además deberemos tener en formato .sln en el directorio /var/lib/asterisk/sounds/ el fichero "ss-spam.sln".
    Para ello, convertir el .wav mediante "sox" así:

    sox ss-spam.wav -t raw -r 8000 -s -2 -c 1 ss-spam.sln
    

    Os dejo el que he creado yo para cuando me llama algún pesado desde un número que está en la blacklist:


    Leer más...

    20 marzo 2012

    Exploit de Joomla paso a paso

    En esta entrada voy a tratar de explicar cómo hacer un exploit paso a paso para Joomla 2.5.0-2.5.1 o 1.7.0-1.7.5, de la forma más sencilla posible y explicando  conceptos básicos de inyecciones de SQL y alguno un poco más avanzado, ya que en este caso se hace el ataque basado en tiempo.

    Para este ejercicio lo ideal es que montéis un Joomla versión 2.5.1 por defecto en vuestro sistema y podáis acceder localmente para ir haciendo las pruebas.

    Hasta la fecha no hay exploit para este fallo del 29 de febrero, aunque la vulnerabilidad se conoce gracias a la nota de seguridad de Colin Wong.

    Lo que me ha dejado completamente K.O., es como una vulnerabilidad tan gorda y estúpida, se ha podido colar en el código. Me ha sorprendido muchísimo que no haya sido descubierta antes, coño, si es que hasta el Acunetix, la detecta.


    El primer paso es buscar donde está el bug comparando el código de la versión vulnerable: 2.5.0 ó 2.5.1, con el de la versión que lo soluciona: 2.5.2

    Se descargan ambos ficheros y se descomprimen para ver que líneas han sido modificadas. Afortunadamente no hay demasiadas y es muy sencillo detectar las líneas que están afectadas por el sql injection con un simple comando "diff" (línea 8)



    ¡Vaya! En las dos últimas líneas del diff se ve que la variable "$current" en la nueva versión es llamada usando $db->quote() y no directamente. Sospechoso ;).

    Lo siguiente es tratar de encontrar en que momento este código es ejecutado para averiguar donde se ha de inyectar el código SQL y hasta dónde se puede llegar.

    Toca revisar el fichero dónde está esa línea: j-2.5.1/plugins/system/redirect/redirect.php


    Tan solo por la cabecera se puede observar que es un componente del Core de Joomla que está encargado de hacer redirecciones y viendo el panel de administración, te haces una rápida idea de que función hace este plugin.


    Básicamente permite hacer redirecciones en caso de que solicite una página web que no existe. Gestionando los errores y evitando que un visitante llegue a una página muerta de la web.

    Ahora a leer el código del fichero más en detalle y lentamente. Por lo menos la parte más crítica:


    Al margen del primer comentario (hay que ver ahora quien es el idiota). En el código se aprecia que la sentencia SQL vulnerable (línea 24) es llamada cuando no existe una redirección publicada y permanente creada para esa página (el if de la línea 18). Es decir, si por ejemplo se solicita la URL: http://localhost/joomla/index.php/AAAAA y el administrador del CMS no ha creado un redirect para esta página, mostrará un error 404 estándar de Joomla.

    El siguiente paso  que da el aplicativo (de la línea 26 a la 45) es añadir la URL a la base de datos para que el administrador pueda ver que páginas se han solicitado y no existen, pero esta parte es indistinta, ya que la inyección se ha generado antes y por lo tanto es irrelevante.

    ¿Entonces cómo se explota? Pues tan solo hay que llamar una página del tipo: http://localhost/joomla/index.php/AAAAAA' union select ... y el código que se quiera insertar. Lo sé, parece imposible que un producto tan popular y con esta madurez aún tenga un sql injection TAN estúpido.

    "El problema" para hacer uso de la vulnerabilidad es que el resultado de la inyección no es mostrado por pantalla, ni errores, ni resultados positivos/negativos y conseguir algo útil es un poco más complejo, ya que la sentencia vulnerable es usada internamente por el aplicativo y no para generar la página resultante.

    Solo queda una alternativa y es hacer inyecciones basadas en tiempo. Es decir, si al solicitar la página no existente tarda 1 segundo en responder normalmente, provocar que tarde 10 según el resultado de la inyección.

    El ejemplo más sencillo para detectar esta vulnerabilidad es llamar a la página de la siguiente forma: http://localhost/joomla/index.php/AAAAAA' union select sleep(10) union select '1 y observaríamos que tarda 10 segundos en devolver la página ya que la sentencia SQL vulnerable se quedará 10 segundos esperando e impidiendo la ejecución normal que devolvería la página normalmente en 1 ó 2 segundos. 

    La ejecución en base de datos y completando la sentencia que se obtiene de la línea 24 con los parámetros que se han pasado, queda de la siguiente forma:

    select id from tabla where old_url='http://localhost/joomla/index.php/AAAAAA' union select sleep(15) union select '1'

    Ahora no queda más remedio que estudiar funciones de MySQL y ver cómo usar este comportamiento, para extraer datos. Las más importantes:
    • database(): devuelve el nombre de la base de datos: select database()
    • sleep(): ejecuta una demora de tiempo: select sleep(10)
    • length(): devuelve la longitud de una cadena: select length(database()) 
    • ascii(): devuelve el valor ascii de una cadena: select ascii("A")
    • substring() ó mid(): recorta una cadena de caracteres: select mid(database(),1,1)
    • load_file(): devuelve el contenido de un fichero: select load_file("/etc/hosts")
    • ord(): devuelve el código del valor si es multibyte o su ascii: select ord("2")
    • if(): permite devolver valores en base a los resultados de otras consultas: select if(database()="hola","yes","no") en este caso "no", ya que se llama "joomla" y no "hola"
    Mezclando estas funciones se puede llegar al objetivo final. Por ejemplo, en mi base de datos que se llama "joomla":
    1. select substring(database(),1,1) devuelve el primer carácter de "joomla", es decir, la "j".
    2. select ascii(substring(database(),1,1)) devuelve el primer carácter del nombre "joomla", la "j" y luego lo convierte a su decimal ascii: 106
    3. select ascii(substring(database(),2,1)) devuelve el segundo carácter de "joomla", la "o" y luego lo convierte a su decimal ascii: 111
    4. select if(database()="joomla","si","no") comprueba si el resultado de database() es "joomla", en caso de que correcto devuelve "si", en caso de que no sea así devolverá "no".
    5. select if(ascii(substring(database(),2,1))=106,sleep(10),null) comprueba si el decimal ascii del primer carácter de database(), "106", es igual a 106, si es así, ejecuta un sleep de 10 segundos y si no, no devuelve nada.
    Lo mejor, verlo en funcionamiento directamente sobre MySQL


    Pues después de esto solo queda automatizar todo el proceso del ejemplo 5 para ir recorriendo cadenas de caracteres con substring() y comparar con la tabla ascii, calculando cuánto tarda la web en responder, 10 segundos o tan solo 1 ó 2.

    Con estas peticiones se averigua el primer carácter de "database()":

    select if(ascii(substring(database(),1,1))=1,sleep(10),null)
    select if(ascii(substring(database(),1,1))=2,sleep(10),null)
    select if(ascii(substring(database(),1,1))=3,sleep(10),null)
    ...
    select if(ascii(substring(database(),1,1))=105,sleep(10),null)
    select if(ascii(substring(database(),1,1))=106,sleep(10),null)    <-- en esta se ejecutará el sleep, ya que el ascii de "j" es 106 y la condición se cumple.

    Una vez se detecta el retardo de 10 segundos, se pasa al siguiente carácter, modificando el substring:


    select if(ascii(substring(database(),2,1))=1,sleep(10),null)
    select if(ascii(substring(database(),2,1))=2,sleep(10),null)
    select if(ascii(substring(database(),2,1))=3,sleep(10),null)
    ...

    Anidando un par de bucles y calculando el tiempo se puede sacar el resultado de cualquier consulta sql. Por ejemplo con: select table_name from information_schema.tables where table_schema = "joomla" and table_name like "%_users" se obtiene el nombre de la tabla donde se almacenan los usuarios y con: select password from zzzz_users limit 1, el hash de la contraseña del usuario administrador.

    Si el usuario que se conecta a la base de datos tiene privilegios suficientes, también podría ejecutar load_file(), cargando un fichero del sistema, que se yo, por ejemplo el /etc/passwd

    El exploit tan solo ha de automatizar este proceso, incluso puede que alguna herramienta ya desarrollada se pueda configurar para este propósito. El funcionamiento incluyendo peticiones tendría este flujo:
    1. Se obtiene la fecha del sistema
    2. Se hace petición HTTP GET con la comprobación, por ejemplo:  http://localhost/joomla/index.php/AAAAAA' union  select if(ascii(substring(database(),1,1))=1,sleep(10),null) union select '1
    3. Se vuelve a obtener la fecha del sistema
    4. Si la diferencia de tiempo entre el punto 1 y el 3 es de 10 segundos, es que la condición del 'if' se cumple, por lo que se conoce el valor ascii correcto. 
    Pues eso es todo, ya solo queda optimizar y tirar línas de código que hagan el trabajo sucio.

    La optimización pasa por encontrar el menor tiempo posible de espera, reduciendo los 10 segundos que se han usado durante todo el artículo a uno inferior que no genere falsas alarmas. Otra mejora consiste en no hacer tantas peticiones web, evitando recorrer toda la tabla ascii buscando el carácter válido. Para determinadas sentencias, como database(), tan solo consultar desde el decimal 32 al 90.

    La última, un poco más compleja consiste en hacer una consulta con ord() y AND para averiguar los bits que compone cada byte. Con tan solo 8 peticiones se averigua el código ascii, pero si calculamos que la mitad de las peticiones tendrán como resultado un sleep(), puede tardar más que hacer hasta las 60  peticiones recorriendo la propia tabla, en la que solo un requiere un único sleep().

    ¡Fin! Espero que este ejercicio le haya servido a alguien. Este es el código que a mí me ha quedado:



    Para los más vagos, un vídeo que espero sea explicativo.

    Leer más...