29 noviembre 2013

¿Quién descubrió las inyecciones de código SQL?

Hoy vamos a hablar de las inyecciones de código SQL (SQL Injections), una de las típicas vulnerabilidades que nos podemos encontrar en cualquier auditoría web. Ha llegado un punto que ya no nos sorprenden toparnos con ella en todo tipo de aplicaciones, sean críticas o no, y lo que está claro es que no sólo permite la obtención de información de la base de datos, si no la ejecución de comandos en el sistema operativo y el total compromiso del sistema afectado.

Lo más curioso de todo es que ¡lleva entre nosotros más de 15 años! Es de las vulnerabilidades más conocidas y siempre protagonista del Top 10 de amenazas OWASP, en cuya última edición las inyecciones de código se encuentran en primer lugar.

A continuación, vamos a remontarnos a sus orígenes para demostrar que no es una técnica avanzada, compleja, de difícil solución o novedosa. No veáis lo siguiente como un ejemplo básico...se sigue encontrando hoy en día. Quizás se descubriese antes, pero por lo menos, hablaremos de la primera vez que se publicó esta información en Internet.

¿Quién mencionó por primera vez una inyección de código SQL?

El protagonista de hoy es Rain Forest Puppy, cuyo nombre real corresponde con Jeff Forristal (@j4istal)

Jeff Forristal durante su última charla sobre Android en Black Hat USA 2013
Jeff es un investigador de seguridad que lleva más de una década dedicado al mundo de la seguridad en diferentes vertientes, y que actualmente se encuentra trabajando en Bluebox Security con el fin de investigar vulnerabilidades en dispositivos móviles. Entre sus aportaciones destaca, entre otras, la herramienta Whisker, de las primeras aplicaciones para análisis de vulnerabilidades web. En su sección de Packetstorm (lleva dado de alta desde 1999) veréis scripts y herramientas que ha compartido para la detección y explotación de vulnerabilidades sobre multitud de sistemas.

Durante una auditoría a un sistema NT, se encontró un servicio web que interactuaba con una base de datos MS SQL Server 6.5, y revisando la posibilidad del motoro SQL, se percató de que era posible ejecutar sentencias encadenadas (batch). Debido a que se encontró una página web que permitía introducir valores en parámetros para la realización de búsquedas, pensó en encadenar sentencias SQL para provocar la ejecución de consultas una vez la aplicación concatenase dicha consulta con la original en el código fuente. Además, como no podía ver el código fuente de la sentencia en sí, pensó en incluir caracteres guión para evitar la ejecución del código posterior a lo que él introdujese. ¿Os suena? Inyección SQL en toda regla y que evidenció con todo lujo de detalles y paso por paso, en el número 54 de la revista online PHRACK, publicada el 25 de Diciembre de 1998.

Dentro de su contribución como Rain Forest Puppy (pseudónimo que utilizó sin revelar su verdadera identidad durante muchísimos años....) con todo el proceso de intrusión sobre sistemas NT, se encuentra un apartado denominado "ODBC and MS SQL server 6.5" en el que comienza el proceso mencionado previamente:

Sección en el artículo de Rain Forest Puppy de Phrack 54
Curiosamente, uno de sus compañeros contactó con Microsoft para informar acerca de este nuevo abanico de posibilidades que ofrecía la aplicación vulnerable y la base de datos MS SQL Server. Microsoft no lo consideró un problema, y lo dejó estar.

Como colofón a su artículo, en el que escribe recomendaciones tras las vulnerabilidades descubiertas, una de ellas es la siguiente:

- Don't assume user's input is ok for SQL queries.

Que traducido quiere decir:

- No asumas que los valores introducidos por el usuario son siempre adecuados en sentencias SQL.

Recomendación que aún a día de hoy, no se tiene en cuenta ni por la cual se toman medidas, propiciando además de ataques por inyección de código SQL, los también famosos Cross-Site Scriptings y otras muchas vulnerabilidades causadas por una incorrecta validación de parámetros.

Os recomiendo leer el artículo completo de Rain Forest Puppy "NT Web Technology Vulnerabilities" pero sobretodo, tened en cuenta que se escribió hace casi 15 años....y lo poco que han cambiado las cosas.

[+] How Was SQL Injection Discovered? (eSecurityPlanet.com)
Leer más...

28 noviembre 2013

¿Quién es el creador de Bitcoin?




Supongo que si os hablo de Bitcoins, os vienen a la cabeza varias palabras: P2P, PKI, privacidad, pago online. La verdad es que la divisa virtual, tiene como una de sus premisas proteger la privacidad de aquellos que realizan las transacciones. Es decir, que efectivamente, no se puede saber quién es poseedor de una cuenta (basada en criptografía de clave pública) que se almacena en una cartera electrónica (o electronic wallet), pero sí conocer las transacciones realizadas entre identificadores de cuentas, aunque no se puedan asociar a una identidad física.

Y si menciono Silk Road, los tags serían: ilegal, drogas, underground, deep web y TOR. Nuestro compañero Yago ya nos dio detalles sobre la existencia del portal Silk Road que además de comerciar con un amplio surtido de productos, sustancias, servicios ilegales, documentación falsa de todo tipo, etc,… tenía la peculiaridad de aceptar únicamente Bitcoins como medio de pago.

Los orígenes de Bitcoin se remontan a 2008 cuando un tal "Satoshi Nakamoto" seudónimo que se asumía asignado a una persona, aunque también se especulaba que fuese un grupo de ellas, y que creó dicha moneda. En base a estas premisas, los israelíes, Dorit Ron y Adi Shamir, del Instituto de Ciencia Weizmann, han llevado a cabo una investigación por la que sugieren que Satoshi Nakamoto, en realidad es (o tiene una estrecha relación con) Ross William Ulbricht AKA Dread Pirate Roberts, el individuo que detuvo el FBI por ser el dueño/administrador de Silk road, el portal de venta de todo tipo de productos, sustancias y servicios ilegales, accesible únicamente desde la red TOR.

¿Cómo se atreven a afirmar esto?

Según hemos dicho, no es posible asociar una dirección Bitcoin a una persona física (si no se realiza la conversión a dinero físico), sin embargo se pueden conocer las transacciones o los bitcoins "minados" por una cuenta. Según indican los investigadores en este paper, se remontaron a los principios del Bitcoin y evidenciaron que en la primera semana de creación de la moneda virtual, una cuenta minó 77600 Bitcoins. Se asume que con una semana de vida, el único que pudo haber minado tal cantidad de Bitcoins era el inventor, "Satoshi Nakamoto".  

Para poder comprar en Silk Road era necesario precargar bitcoins en una cuenta y a partir de ahí añadir al carrito tus sustancias psicotrópicas favoritas. Por cada venta que se hacía, el administrador cobraba una comisión, que obviamente se movía a una dirección o cuenta en Bitcoins. Cuando el FBI detiene a un individuo llamado Ross William Ulbricht, acusado de ser Dread Pirate Roberts, se encuentran unas cifras astronómicas en la cartera electrónica de este individuo. A lo largo del paper, se explica como el FBI, movió un montón de Bitcoins de esta y otras cuentas a una única con 144336 Bitcoins, en transferencias fraccionadas de 324 BTCs y una restante de 156 y cómo tirando del hilo hacia atrás, los investigadores habían determinado que de la cuenta primigenia que minó 77600 BTCs en la primera semana, hubo varios movimientos que, varios saltos después, terminaron en la cuenta de las comisiones de Dread Pirate Roberts. 

La investigación no es rotunda demostrando ni concluyendo nada, pero sí que abre la puerta a la posibilidad de que Satoshi y DPR tengan relación o incluso hasta pudieran ser la misma persona, en contra de los que dicen que Satoshi murió hace tiempo. 




La historia de Dustin D. Tramell

Ante la investigación de Ron y Shamir, Dustin D. Tramell, un entusiasta de la criptografía y de divisas alternativas, ha querido desmentir acusaciones que se han hecho contra él en las que se le atribuía la identidad de Satoshi. Una de las cosas que dice es que cuando nació Bitcoin, él se entusiasmó con la idea y que incluso se descargó el primer cliente Bitcoin que hubo. Incluso llego a intercambiar correos con "Satoshi Nakamoto", por lo que, por lógica, él no puede haber sido Satoshi "porque no tiene múltiple personalidad" (o eso, o es una muy buena tapadera y con eso ya ha lavado su identidad).

Por otra parte, Dustin dice también que en el paper de Ron y Shamir, no se especifican las direcciones Bitcoin a las que se hacen referencia. Sin embargo, obviamente es trivial buscar en webs como blockchain.info las diferentes transacciones (que son públicas) e ir tirando del hilo.

En este caso, Dustin buscó las transacciones que se refieren los investigadores israelíes y dio con que, la dirección a la que hacen referencia, es suya. Además indica que la dirección destino a la que se hacía esa transacción de 1000 BTCs, pertenecía a Mt. Gox, un sitio web de intercambio de moneda virtual. Varios hops después, desde esas cuentas se harían movimientos que derivarían en la cartera electrónica de Dread Pirate Roberts, pero él quiere dejar claro que no tiene nada que ver con las especulaciones hechas por Ron y Shamir.


Entonces,... ¿Quién es Satoshi?

Me llamó mucho la atención este post, en el que se preguntan exactamente lo mismo: ¿Quién es Satoshi? y, haciendo un ejercicio de análisis en profundidad, indagando sobre las horas a las que contestaba los correos en la lista de criptografía, el tipo de lenguaje empleado (inglés con palabras de slang americano), la información declarada en su perfil, en el que dice que es un hombre de 37 años (aunque no es para nada vinculante), etc,... se plantean diversas opciones.

Apuntan a diversos individuos estrechamente relacionados con Bitcoin, como Gavin Andresen (uno de los líderes de desarrollo del proyecto) o Jed McCaleb (uno de los fundadores del portal de intercambio de moneda Mt Gox, curiosamente en Japón, que además fundó la red P2P Edonkey en el 2000), Shinichi Mochizuki (un genio matemático japonés),... varios grupos de personas, o incluso hasta se baraja hasta que sea algún gobierno o agencia de seguridad (¿os suena?),...

Lo que está claro, es que sea quien sea Satoshi, si es que algún día existió como persona física y no como ente, que quiere cumplir con una de las premisas y paranoias de Bitcoin, el anonimato del poseedor de los mismos...

Por si acaso, yo tampoco soy Satoshi,... "Y si lo fuera, tampoco te lo diría"
Leer más...

27 noviembre 2013

10+10 Herramientas de monitorización de ancho de banda en Linux

No me gustaría entretenerme con una larga introducción y como creo que el título lo dice todo, hoy vamos a enumerar 10 herramientas de monitorización del consumo de ancho de banda para consola y otras 10 herramientas que muestran los mismos resultados en web. Dejaremos fuera otras más complejas que tienen esta capacidad pero están orientadas a la supervisión y gestión de servidores y sus servicios, como son Nagios, Zabbix, Ganglia, Observium, Zenoss, Opennms...

Para consola:
  1. vnstat: se ejecuta como servicio o mediante tareas programadas, su ventaja es que es útil para controlar en tiempo real el tráfico enviado y recibido y también hacerlo en un periodo de tiempo. Una de mis favoritas, está paquetizada en casi todas las distribuciones.
  2. iptraf: al igual que la anterior es un clásico, se caracteriza por su interfaz ncurses desde el que se configura interactivamente. Ampliamente distribuida.
  3. iftop: últimamente es una de la que más veo usar. Trata de ser el 'top' de cpu para las conexiones de red. Su interfaz es sencilla y se incluye en la gran mayoría de distribuciones. Otra indispensable.
  4. bwm-ng: es más simple que otras herramientas similares, su gran ventaja es que además de funcionar en modo interactivo, permite exportar la salida a un archivo CSV o html
  5. ibmonitor: en concepto es parecida a bwm-ng o vnstat, muestra el tráfico total por interfaz, tanto el enviado como el recibido.
  6. nload: herramienta interactiva que muestra el consumo acumulado y además dibuja en modo texto gráficas (en ASCII claro).
  7. dstat: tiene formato similar a los conocidos iostat, vmstat con soporte de colores. Está incluida en múltiples distribuciones.
  8. tcptrack: aplicación que muestra el consumo por conexión. No está tan extendida como otras. herramientas similares.
  9. ipband: también orientado a obtener datos por conexión. 
  10. speedometer: más gráficas en ASCII para ver el tráfico en grandes números, permite obtener estadísticas de velocidad en la red.
Quedan fuera por estar un poco más viejas (y para que salgan 10 que mola más): cbmbmon y pktstat


Con interfaz web:
  1. vnstati: es la herramienta de vnstat para generar archivos png que poder visualizar vía web. Muy muy sencilla. Como pega, no es dinámica.
  2. collectd: realmente versátil y potente. Permite medir muchos otros parámetros además de la red con distintos plugins. Funciona en modo cliente/servidor, por lo que puede monitorizar redes de sistemas.
  3. munin: conceptualmente similar al anterior, permite, mediante plugins, monitorizar varios servicios. También funciona en modo cliente/servidor.
  4. cacti: archiconocido y muy usado para adquirir datos vía snmp de sistemas remotos. Permite diseñar y crear las gráficas usando su propio interfaz web.
  5. bandwidthd: pese a que cumple sus funciones de pintar gráficas de consumo de ancho de banda, no permite configurar demasiadas opciones.
  6. ntopng: versión "ng" del clásico ntop. Personalmente no me gusta la forma de presentar los datos.
  7. mrtg: otro clásico, permite pintar gráficas obteniendo datos vía snmp. 
  8. orca: pinta gráficas estilo mrtg. Al igual que mrtg, son versiones no adaptadas a estos tiempos modernos.
  9. bwbar: genera una única barra muy sencilla, incluso más que vnstati, con los datos de entrada y salida.
  10. Graphite: realmente no es para dibujar gráficas de tráfico, pero permite dibujar gráficas de cualquier tipo de una forma realmente sencilla y bonita. Requiere que se le pasen los datos mediante algún script, por ejemplo, usando alguna herramienta de las vistas en la sección anterior. 

Leer más...

26 noviembre 2013

Fruity-WiFi, como la WifiPineApple pero sin la Mark IV



Hace muchos años conocí a un gran profesional que ha aportado herramientas y conocimiento a la comunidad de diferentes formas, y a quien además considero un amigo.  Tiempo atrás, me ayudó a conseguir en uno de mis viajes, mis preciadas Raspberry-Pi ya que no podía adquirirlas directamente desde mi país.  Ese día tuvimos una charla interesante en el tren Madrid-Toledo sobre el potencial de esos aparatos, pero sobre todo charlamos de muchas otras cosas, como por ejemplo de la WifiPineApple.   Sin duda, se quedó con alguna inquietud en su cabeza y desde hace tiempo se puso a trabajar en su tiempo libre sobre la idea de hacer que la R-Pi pueda usarse como la WifiPineApple.   


Imagen 1: Instalación exitosa. Librerias descargadas e instaladas.
He tenido la oportunidad de ver correr y testear las versiones betas, con la grata sorpresa de que cada vez que descubría algo, su creador ya tenía una solución implementada en un nuevo release por el afán de probar y mejorar el producto a un ritmo increíble.   

Sé muy bien que él mismo publicó un post con la idea de este producto y de su desarrollo en 2 oportunidades en el foro de Hak5 y tristemente fueron eliminados en muy corto plazo, cosa que al día de hoy no comprendo (o no quiero comprender).

El proyecto denominado Fruity-Wifi (no me imagino a qué se debe ;p), a cargo de @xtr4nge se encuentra definido como: 

FruityWifi is a wireless network auditing tool based in the wifi Pineapple. The application can be installed in any Debian based system adding the extra packages.


Actualmente es posible ejecutarlo no solo en una R-Pi (probado en Raspbian, Pwnpi y en Kali Linux ARM) , sino también en Debian, en Kali Linux, Bugtraq, Pwnpi basados en x86/x64

Muy característico de @xtr4nge , la simplicidad del uso es importante, por lo cual su instalación en un equipo con Kali, es tan sencilla como descargarlo, descomprimirlo y ejecutar el script de instalación: install-FruityWifi.sh

root@kali:~# unzip master.zip
root@kali:~# cd FruityWifi-master/
root@kali:~/FruityWifi-master# chmod a+x install-FruityWifi.sh
root@kali:~/FruityWifi-master# ./install-FruityWifi.sh


Imagen 2: inicio de FruityWiFi

Al instalarlo de esta manera descargarán todas las dependencias y librerías necesarias, por lo cual tardará aproximadamente unos 10 minutos.  Finalmente ya estamos listos para acceder a http://localhost/FruityWifi con usuario y clave admin/admin 
(Demás esta decir que en un ambiente productivo debería ejecutarse bajo HTTPS y la clave de usuario debería cambiarse, no?)

Esta compuesta principalmente por módulos, entre los que se encuentran:

Imagen 3: Dashboard principal de FruityWiFi

  •  Module_Squid
  • Module_urlsnarf
  • Module_Kismet
  • Module Captive Portal
  • Module mdk3
  • Module ngrep
  •  Module_nmap
  • Module_sslstrip
  • Module_dnsspoof

(los últimos 3 basados en las conocidas “infusiones” del proyecto wifipineapple creadas por whistlemaster)




Imagen 4: Panel de instalación y administración de los módulos.




La herramienta es muy sencilla pero a la vez muy potente, los módulos se inician simplemente seleccionando la opción de “start” y sus parámetros de configuración son sumamente sencillos como podemos ver en la imagen 3.    En la última versión publicada, los módulos pueden actualizarse (instalar, desinstalar y administrar) directamente desde la solapa “modules” sin necesidad de reinstalar la aplicación completa cada vez que aparece uno nuevo.



En el menú podemos ir a los Logs, los cuales se encuentran ordenados por módulos haciendo mucho más sencillo para nosotros su seguimiento, e ir evaluando qué fue sucediendo en cada ataque ejecutado.



Algunos detalles interesantes:

Imagen 5: Modulo SSLstrip (opciones Inject y Tamperer para inyectar código).
  • La implementación de SSLStrip en realidad es un fork de la original de Moxie, y la misma posee algunas opciones extra para inyectar código HTML y Javascript.

Demás esta decir, que probar esto en una R-Pi con algunos suplementos como por ejemplo:     
  • 1 placa ALFA (Atheros)
  • 1 GPS USB
  • 1 Conector USB como Wi-Fi supplicant  compartiendo internet
además de la batería externa y el hub USB, es como un juego para niños que redescubren sus juguetes después de un tiempo sin jugar con ellos.

Realmente es muy interesante todo lo que se puede hacer con ella, con la R-Pi o sin ella.
Ya esta en sus manos, la herramienta promete más actualizaciones, en realidad nuevos módulos para divertirse, así que: a jugar!  

Saludos.

Claudio Caracciolo
CSA at ElevenPaths
@holesec
Leer más...

25 noviembre 2013

Hackeos memorables: Las hazañas de Dmitry Sklyarov


En 2001, ElcomSoft sacaba al mercado Advanced eBook Processor (AEBPR), un software que, resumiendo (mucho), convierte documentos con un formato eBook, con protecciones para evitar que se hagan copias o modificaciones, en un PDF "normal", sin ningún tipo de restricción.

Esto no le gustó demasiado a la gente de Adobe, que reaccionaron enviando una nota a ElcomSoft pidiendo que quitasen el programa de la web, ya que consideraban que estaba diseñado para eliminar las restricciones de copyright y violar los derechos de autor, y por lo tanto, era ilegal. No contentos con esto (imagino que porque no les hicieron ni caso), contactaron con el ISP de ElcomSoft (Verio) para pedirles que les cerrasen la web. En ElcomSoft lo solucionaron rápidamente cambiando de ISP.

Lo que Dmitry Sklyarov -empleado de ElcomSoft y creador del AEBPR- contó en DefCon 9 en julio de ese mismo año (eBook's Security - Theory and Practice) es que ninguna protección para libros electrónicos basada en PDFs era segura, ni Adobe eBook Reader ni ninguna otra. La premisa es que si puedes abrirlo, puedes quitarle la restricción: da igual las modificaciones que se hagan o la protección que utilicen, al final todo se resume en una clave que el lector de ebooks tiene que tener para poder leerlo, y si la clave está ahí, se puede utilizar para quitar las restricciones.

Un claro ejemplo de por qué Dmitry afirmaba esto es eBook Pro compiler. Para que os hagáis una idea tendremos que tirar de archive.org, porque la página hace ya tiempo que no existe. Pero internet no olvida, y esto es lo que rezaba en la cabecera de su página web en aquella época:

Announcing "eBook Pro", the only software in the universe that makes your information virtually 100% burglarproof! It comes with a lifetime, money-back guarantee, and it's available for a short time at less than 1/40th of its original cost... 
"At Last, You Can Sell Information Online (And Make Thousands Of Sales Per Day) - Without The Danger Of Having Your Information Stolen And Resold By Others"

Me imagino la cara de Dmitry cuando leyó que este software era el único en el universo a prueba de ladrones:


El sistema a prueba de ladrones consistía en comprimir las páginas con el algoritmo deflate de zlib, y cifrar estos datos comprimidos usando un XOR con el string "encrypted".

El cifrado que utilizaba el Adobe eBook Reader era un pelín más complejo, según explicó Dmitry, en la activación se creaban un par de claves RSA: la pública se registraba en el servidor y la privada se quedaba en el Reader. La clave del documento está cifrada por la clave pública y almacenada en el certificado. Este certificado está firmado con HMAC y contiene información sobre los permisos del documento.

El problema es que la clave privada se guarda en local, con ella se puede calcular la clave del documento, y con ésta se pueden cambiar los permisos.  

Al terminar la DefCon a Dmitry lo arrestó el FBI en el hotel en el que se alojaba en Las Vegas por haber violado la Digital Millennium Copyright Act, (DMCA). Hubo mucho movimiento para su liberación, se organizaron protestas y crearon páginas como freesklyarov.org. Adobe inicialmente apoyaba el arresto pero, después de reunirse con Electronic Frontier Foundation, emitieron un comunicado de prensa donde "recomendaban" su liberación, aunque seguían con la causa contra ElcomSoft.

Mientras tanto, Dmitry pasó del North Las Vegas Detention Center, al Oklahoma City Federal Prisoner Transfer Center, finalmente fue trasladado al edificio federal de San José (California) donde, después de pagar una fianza de 50.000 dólares, fue puesto en libertad en agosto de 2001, aunque no podía abandonar el estado.

En diciembre de ese mismo año, y con la condición de que declarase contra su empresa, Sklyarov pudo volver a Moscú. Finalmente, el 17 de diciembre, un jurado federal declaró a ElcomSoft no culpable de la violación de la DMCA.

Pero la historia de Dmitry Sklyarov no termina aquí ni por asomo. En 2010, consigue demostrar que el sistema que utilizaba Canon para probar si una foto había sido modificada o no, era defectuoso.
Este sistema consistía en que la cámara añadía ODD (Original Decision Data) en los metadatos de la imagen con el fin de detectar cualquier modificación.

Las cámaras utilizaban una clave HMAC, que era la misma para todas las de ese modelo (aunque cada modelo tenía una clave diferente) y se podían extraer de las cámaras.

De esta forma, consiguió que el sistema de verificación de Canon considerase que las siguientes fotografías no estaban retocadas:

La bandera de la URSS en la Luna

Stalin con el primer iPhone de la historia

Ojalá no tengamos que esperar otros 9 años para el siguiente pwned de Dmitry Sklyarov.

Artículo cortesía de Yoya Silva
Leer más...