Roban 100 mil dólares a usuarios por malas prácticas en sus contraseñas

octubre 23, 2013 § Deja un comentario

Hace unos días, un grupo de delincuentes realizó un ataque a un proveedor de servicios de Internet en Estados Unidos, logrando acceso a los nombres de usuario y contraseña de los clientes. Las contraseñas obtenidas fueron utilizadas para ingresar a sistemas bancarios de algunas de las víctimas y transferir alrededor de 100 mil dólares, según afirman los cibercriminales en su cuenta de Twitter.

Mediante la utilización de la técnica SQL injection, un servidor vulnerable del proveedor de servicios de Internet Sebastian, de California, fue atacado para obtener los datos de sus usuarios. El ataque pudo ser perpetrado en cuestión de minutos gracias a la automatización con la herramienta SQLmap, la cual busca posibles ataques y los aplica, volcando la estructura y contenido de las bases de datos. Posteriormente el grupo subió un video demostrando no sólo el ataque al ISP, sino también el acceso a las cuentas bancarias de algunos clientes.

La captura corresponde al comando sqlmap con la opción “dbs”, que muestra las bases de datos disponibles en el servidor. En la parte superior de la imagen se ha resaltado el servidor que está siendo atacado, y también puede observarse información como el tipo de ataque y el motor de base de datos. En base al conocimiento de esta información, los cibercriminales pueden buscar las tablas con información de los usuarios, lo cual se muestra en la siguiente imagen:

Se han ofuscado los nombres de usuario y direcciones de correo electrónico, pero los valores resaltados corresponden a las contraseñas. Con esto queremos mostrar una falla grave de seguridad, más bien a nivel conceptual, por parte de los administradores: las contraseñas estaban almacenadas en texto plano y pueden ser usadas en forma directa si caen en manos equivocadas. En este caso, a nivel de seguridad, la buena práctica sería que las contraseñas estuvieran almacenadas como un valor resultante de aplicar una función de hash (como MD5 o SHA1), además de la utilización de “granos de sal”.

Otro factor fundamental en el ataque, que excede la responsabilidad de este proveedor de servicios de Internet y que tiene que ver con los usuarios, es que para algunos de los clientes, la contraseña utilizada era la misma que la de otros servicios de correo electrónico, redes sociales o entidades bancarias. Si bien es cierto que puede ser difícil recordar muchas contraseñas, nunca debe utilizarse la misma contraseña para todos los servicios. En la siguiente imagen puede verse cómo los cibercriminales ingresan al sistema de transacciones bancarias de uno de los usuarios:

En resumen, a partir de una contraseña robada en el servidor del ISP se ha logrado acceso a la cuenta bancaria de un usuario, puesto que la contraseña era la misma. El video luego muestra cómo se puede llevar a cabo un movimiento de fondos, con lo cual los criminales proclaman que han ganado cientos de miles de dólares. Por ello debemos insistir en que nunca debe utilizarse la misma contraseña para distintos servicios.

Fuente: ESET Latinoamérica

Anuncios

SQL Injection en Oracle

mayo 24, 2013 § Deja un comentario

Les sonará un post llamado SQL Injection hasta la cocina – MS SQL Server que fue publicado hará algo más de dos años, y en el que usábamos diferentes herramientas para comprometer una base de datos Microsoft SQL Server a través de una SQL Injection.

En este caso, vamos a intentar repetir el proceso pero esta vez con una base de datos Oracle 11g. Al contrario de lo que sucede con MS SQL Server, en Oracle no existe un comando equivalente a “xp_cmdshell” que nos permita directamente ejecutar comandos del sistema operativo, pero sí que existen algunas funciones y procedimientos de las que podemos abusar para conseguir nuestro objetivo.

Para este primer post vamos a suponer que tenemos una inyección sql con un usuario con todos los privilegios del mundo, y veremos como conseguiríamos ejecutar comandos. En el próximo post veremos como podemos elevar privilegios en el caso de que no seamos tan afortunados de encontrar unos privilegios tan mal asignados.

Contenido completo en fuente original Pentester I y II

Vulnerabilidad de SQL Injection en Yahoo!

abril 26, 2013 § Deja un comentario

Ebrahim Hegazy (@Zigoo0) un asesor de seguridad de la información egipcio encontró una vulnerabilidad de Blind SQL Injection basada en tiempo en las aplicaciones de marketing Yahoo!. Esta es la segunda vez que le pasa a Yahoo! en menos de un año y, como reconocimiento,Yahoo! le envío una camiseta al investigador.

La inyecciónfue descubierta en el servicio oficial de solicitud de comercialización de Taiwan y permite a los atacantes remotos inyectar comandos SQL y obtener acceso a los datos sensibles de los usuarios y control total de la base de datos.

La vulnerabilidad se encuentra en el index.php al procesar el parámetro SCID y puede ser explotada por un atacante remoto sin cuenta de usuario y sin necesidad de interacción del usuario.

The time-based sql injection web vulnerability can be exploited by remote attackers without privileged application user account and without required user interaction. Una PoC publicada por el investigador es la siguiente:

http://tw.ysm.emarketing.yahoo.com/soeasy/index.php?p=2&scId=113; select SLEEP(5)--

La vulnerabilidad fue solucionada por Yahoo! corrigiendo el manejo del parámetro SCID pero, ¿no habrá quedado otro?

Cristian de la redacción de Segu-Info

SQL Injection "a mano"

abril 25, 2013 § Deja un comentario

Seguramente cualquiera que esté leyendo este post ya abrá leído esto, esto y esto pero ninguna de esas guías dan un ejemplo definitivo sobre cómo encontrar, enumerar y explotar los diferentes inyección a mano.

Básicamente este tipo de pruebas permite explicar cómo ejecutar manualmente una inyección SQL y mostrar ejemplos de los diferentes tipos de inyecciones y la forma de enumerar y obtener las diferentes piezas de información crítica en un ataque SQLi.

Así que aquí dejo algunas referencias rápidas:

Cristian de la Redacción de Segu-Info

    El ataque a Bit9 empezó por un SQL Injection

    febrero 27, 2013 § Deja un comentario

    Bit9 ha ofrecido una actualización de su investigación sobre el incidente reciente que permitió atacar su organización y productos antivirus. La investigación todavía está en curso y dicen que compartirán todo lo que conozcan siempre y cuando no pongan en peligro la seguridad o confidencialidad de sus clientes.

    Según dicen, el ataque fue parte de una gran campaña para infiltrarse en organizaciones muy selectas de Estados Unidos y un espacio de mercado muy estrecho. Si bien no se revelan los nombres o naturaleza de esas organizaciones, aseguran que el ataque no fue contra empresas de infraestructuras críticas (por ejemplo, empresas de servicios públicos, la banca, la energía), ni contra entidades gubernamentales. Creen que el ataque no fue motivado financieramente, sino para acceder a la información. La motivación y la intención de los atacantes es importante porque ayuda a explicar el limitado alcance del compromiso.

    Según su evaluación, pudieron identificar tres clientes que fueron afectados y el compromiso inicial del sistema se produjo en julio de 2012. Confirman que los atacantes entraron a través de una falla de SQL Injection presente en un servidor web y eso les permitió instalar un troyano en la máquina virtual que almacenaba algunos certificados digitales (ya revocados) utilizados para firmar sus herramientas. Lamentablemente esa máquina virtual fue apagada tiempo después y eso no permitió detectar el ataque hasta enero de 2013 cuando la máquina se volvió a encender. Adicionalmente se menciona a ciertas IP registradas en Taiwan y archivos creados en China.

    Si se desea conocer más detalles de la metodología utilizada se puede leer el post publicado por la empresa.

    Cristian de la Redacción de Segu-Info

    Vulnerabilidad de inyección SQL en Ruby on Rails

    enero 10, 2013 § Deja un comentario

    Los desarrolladores de Ruby on Rails advierten de una vulnerabilidad de inyección SQL que afecta a todas las versiones actuales del framework web. Las nuevas versiones de Ruby on Rails, 3.2.10, 3.1.9 y 3.0.18 ya están disponibles. Se recomienda que todos los usuarios se actualicen inmediatamente.

    El problema, de acuerdo con el aviso, es que debido a la forma dinámica en que se extraen las opciones desde el método “params”, un parámetro puede ser usado como un campo de aplicación y se podría inyectar un SQL arbitrario. Los buscadores dinámicos utilizan el método “name” para determinar qué campo se está buscando, por lo que una sentencia del tipo:

    Post.find_by_id (params [: id])

    sería vulnerable a un ataque y se podría inyectar:

    User.find_by_id({:select =>"* from users limit 1 --"})

    User Load (0.5ms) SELECT * from users limit 1 -- FROM "users" WHERE "users"."id" IS NULL LIMIT 1

    El problema original se dio a conocer en el blog Phenoelit a finales de diciembre, donde el autor aplica la técnica para extraer las credenciales de usuario de un sistema de Ruby on Rails, eludiendo el marco de autenticación Authlogic.

    Fuente: Seguridad UNAM

    SQLMap desde Dump a Shell

    enero 6, 2013 § Deja un comentario

    SQLMap es una herramienta muy completa y flexible. Fue creada por Bernardo Damele Assumpcao Guimaraes y Miroslav Stampar. Se caracteriza por permitir la realización de ataques de SQL Injection automatizados contra un sitio web vulnerable y, debido a su gran variedad de opciones, se podrá personalizar las técnicas usadas dependiendo del objetivo.

    SQLMap agrupa sus comandos por categorías, denominadas de la siguiente forma: Target, Request, Optimization, Injection, Detection, Techniques, Fingerprint, Enumeration, Brute force, User-defined function injection, File system access, Operating system access, Windows registry access, General y Miscellaneous. Todas estas categorías se encuentran detalladas en el manual de esta herramienta, que esta disponible en el siguiente enlace [PDF].

    A pesar de las múltiples funciones que trae consigo SQLMap, el comando mas usado y conocido por muchos es dump, con el cual se podrá bajar o dumpear la base de datos. En esta ocasión haré caso omiso de dump, y “jugaré” con otras opciones que también me parecen interesantes; sin embargo, no hablaré de todas, puesto que no pretendo realizar un manual. Mirando el –help de esta herramienta podremos encontrar todos los comandos que nos permitirán personalizar las técnicas usadas dependiendo de la aplicación en que nos encontremos.

    Tomaré como ejemplo un sitio vulnerable a SQL Injection para la realización de esta practica. Con el fin de proteger la identidad y los datos sensibles que puedan ser expuestos, algunas imágenes y consultas han sido modificadas.

    Contenido completo en fuente original AmphiSec

    ¿Dónde estoy?

    Actualmente estás explorando la categoría sql injection en Seguridad Informática.