13 agosto 2010

Retos forenses, practicar para avanzar.

Los análisis forenses son un tipo de trabajo que requiere personal altamente cualificados y preparado para que su ejecución sea satisfactoria y su resultado favorable.

Pese a que existe mucha literatura en libros y blogs lo mejor es practicar con casos lo más reales y variopintos posibles que hagan enfrentarse a cada uno de los problemas que vayan surgiendo. De esta forma será difícil olvidar lo que se sudó y cuando una situación similar se presente, será sencillo dar con la solución.

Con este propósito distintas organizaciones, blogs y compañías publican concursos y retos de análisis forense en los que se puede participar. Generalmente se descarga una imagen o archivo y se solicita la solución en un documento técnico y otro ejecutivo.

A continuación hemos recopilado algunos de los más populares, en muchos casos ya resueltos... ¡¡pero no hagáis trampa!!
Leer más...

12 agosto 2010

A las BlackBerry le huele el aliento, pero todos la besan

No, la imagen no es de la ferretería-café de Luke, hace referencia al culebrón que tienen montados los canadienses de RIM y sus BlackBerry con la seguridad en sus dispositivos móviles o mejor dicho, en el diseño de la arquitectura de comunicaciones y la centralización de sus sistemas en países no controlados por gobiernos que desean controlar (y espiar)  las comunicaciones.

Ya hace cuatro años se podían ver análisis profundos de esta plataforma en la Blackhat, y algún ataque en Defcon. Pero las alertas empezaron a sonar cuando la mismísima NSA le prohibió al recién elegido honoluluense utilizar el terminal BlackBerry que tanto le gustaba y que  le deberían "arrancar de las manos" como si fuese el rifle Winchester de Charlton Heston.

Aunque al final, he can, y se salió con la suya. Imagino que por la falta de imaginación y las esperpénticas alternativas de las que se hablaba.

Desde ese momento no se pone en duda la seguridad de los servicios de Blackberry, más bien lo que desean los gobiernos es poder acceder a la información que transmiten.

El siguiente capítulo es en el 2008 cuando la India exige a RIM las claves para descifrar tráfico y mensajes electrónicos, aunque finalmente no lo ven necesario. Por lo menos, hasta la semana pasada, donde sus antiguos miedos volvieron a surgir levantando nuevamente la reclamación.

Otro asalto exactamente igual ésta ocurriendo con Arabia Saudí, Emiratos Arabes e Indonesia este mes de Agosto, y del que esperamos noticias, ya que por el momento solo se ha acordado instalar un servidor en Arabia Saudí, evitando más conflictos en este país.

El último golpe que ha recibido Research In Motion es el gobierno Alemán que no permite a sus ministros el uso de esta tecnología (tal y como hizo la NSA) sustituyendola por el terminal movil SiMKo 2 (la M bien podría ser de Merkel, por la publicidad que les hace). Aunque aquí no parece haber discusión.

¿Qué opináis? No, aún no, primero deberíamos entender bien cómo funciona su sistema, aquí unos enlaces por dónde empezar:


Leer más...

11 agosto 2010

Pirateando al pirata: Televisión de pago "by the face"

La información descrita a continuación está pensada con fines académicos
Si haces mal uso de ella, será tu responsabilidad, no nuestra.

Cardsharing es el método por el cual receptores independientes obtienen acceso simultáneo a una red de televisión de pago, usando una tarjeta de abonado de acceso condicional legítima. Típicamente, la tarjeta legítima está adjunta a un ordenador personal o Dreambox el cual está conectado a Internet, y está configurado para proporcionar la palabra de control legítimamente descifrada a otros receptores que piden información. Esta palabra de control descifrada es entonces usada para descodificar un servicio de acceso condicional codificado, como si cada uno de los otros receptores estuviera usando su propia tarjeta de abonado. (http://en.wikipedia.org/wiki/Card_sharing)

Para poder comenzar necesitaremos de una antena de satélite en nuestro domicilio. La mayoría de viviendas ya tienen una preinstalada, y si nos encontramos en Europa puede estar orientada a cualquiera de los tres satélites Hispasat 30º Oeste (1B, 1C y 1D) o a los ocho de Astra 19’2 Este (1B, 1C, 1E, 1F, 1G, 1H y 2C). En nuestro caso usaremos este ultimo ya es donde están los servicios que queremos visualizar. Si necesitas instalar una tu mismo (recomendado) por unos 30€ puedes tener una antena con un plato de 80cm, LNB universal y herrajes. Si quieres facilitarte la vida puedes comprarte una antena motorizada.


No es nuestra intención centrarnos en la orientación de la misma ya que hay bastante documentación sobre esto. Sí recomendaremos una aplicación disponible para Android y iPhone que nos hará la vida más fácil para instalar correctamente la antena.


El software mostrado en el video anterior, DishPointer, podréis encontrarlo en esta dirección, y una pequeña guía en este enlace.

Una vez finalizamos con la antena necesitaremos instalar un descodificador. Normalmente se utilizan los famosos clones de Dreambox. Este ultimo se utiliza frecuentemente por fabricar hardware de bajo coste (Procesador PowerPC ~250Mhz, 96Mb RAM, 32 Mb Flash) corriendo un sistema operativo GNU/Linux, con la flexibilidad que esto nos aporta para poder actualizarlo, usar firmwares personalizados, etc. También es posible utilizar descodificadores basados en tarjetas PCI (ya hablaremos más adelante sobre estas en hacking de satélites donde se usará una tarjeta Hauppauge WinTV HVR 4000).

Con el equipo necesario ya podemos empezar a entender un poco más como funciona el Cardsharing y cuales son sus protocolos:
  • Radegast : De los primeros protocolos, bastante inseguro.
  • Gbox : Usado sobre todo en PC.
  • Mbox : Es algo más nuevo y aporta mejoras de otros protocolos.
  • Newcamd : Uno de los más usados por la mayoría de servidores sobre todo los que no son GNU/Linux (tipo Mvision).
  • CCcam : Sin duda el más famoso y potente.
Aunque hay bastantes más (Sbox, Evocamd, MGcamd, RQCam, IncubusCam, SCam, VizCam, Hypercam, etc) estos son los más usuales. Podemos ver un ejemplo sencillo de conexión, donde en resumidas cuentas el CCcam Server dispone de la tarjeta de Abonado y mediante Internet comparte esta como una tarjeta virtual en el cliente Dreambox 500. Otros protocolos permiten usar nuestro cliente también como servidor de claves para poder distribuir el servicio ya que normalmente y de forma recomendada un servidor de claves suele tener de media unos 15/20 clientes.

 

Toda esta información nos permite conocer a grandes rasgos como están montadas estas redes de pago por visión. Como es habitual se suelen montar por personas no muy cualificadas que desconocen como implementar las medidas de seguridad necesarias para evitar que se usen bajo su consentimiento. La gran mayoría de ellos siguen funcionando con claves por defecto, sin cifrar las comunicaciones y sin monitorizar a los clientes.

Por lo tanto solo necesitamos conocer que satélite utiliza el servidor de claves que normalmente va asociado a los servicios que ha contratado. Acceder a la configuración del Servidor/Cliente añadir/copiar el usuario de acceso, instalar la lista de canales o realizar una búsqueda bajo dicho satélite y listo. ¿Como podemos encontrar estos servidores? Una forma rápida es usando Shodan (Compute Search Engine):


Realizamos una búsqueda con el banner “dreambox” y probamos con algunos de los resultados con la clave por defecto root/dreambox. En unos pocos intentos conseguimos acceso a varios de ellos como el siguiente:


Una vez dentro podemos ojear un poco que proveedores de TV están configurados e incluso con este firmware ver online o mediante VLC un canal seleccionado como vemos en la siguiente imagen.


Ahora solo queda ver la configuración del Cliente y en este caso vamos a copiarla. Hay que tener en cuenta que dependiendo del protocolo solo podremos usar una sesión por lo que dejaríamos sin servicio al otro descodificador, pero bueno solo es una prueba para ver que funciona correctamente. Accedemos mediante telnet/ssh según este habilitado con la clave por defecto y accedemos al fichero de configuración:


En este cliente no se están usando saltos, el host xxxx.dyndns.org es el servidor y el usuario/clave ‘dec400aa’. Por lo que solo tendriamos que configurarlo en nuestro decodificador en el fichero de configuración Cccfcam.cfg que normalmente se encuentra en /var/etc, reiniciar el servicio. Tener la antena orientada al satélite correcto, una lista de canales o buscar directamente los mismos de forma automática y a disfrutar de los mismos.

Si eres de los que no se quiere complicar la vida, ya hay sitios que ofrecen servidores de forma libre, aunque normalmente son servidores que han sido pwneados y que suelen publicados cuando hay eventos importantes (Futbol, Baloncesto, NFL..), algunas :
Entrada escrita por ReverseSkills
Leer más...

10 agosto 2010

No todo son md5 o sha1 en este mundo

Estamos acostumbrados a que todas las aplicaciones web utilizan siempre los mismos tipos de hash y que sea lo que sea lo que rompamos, al final se podrá utilizar los tropecientos gigas de tablas rainbow para obtener la contraseña en "un rato".

Desgraciadamente para unos y afortunadamente para otros, esto no siempre es así y últimamente los productos más conocidos utilizan distintos algoritmos para generar sus hash.

Sirva también como ejemplo para todos aquellos que desarrollan aplicaciones web o almacenan usuarios y contraseñas en bases de datos y ficheros a los que en algún momento alguien podría acceder.

En la siguiente tabla se muestra algoritmos y aplicaciones representativas de lo comentado anteriormente:


Aplicación Algoritmo
e107 md5(md5($pass)
EyeOS v1.8.5.3 md5($pass.md5($pass))
Invision Power Board 2.x.x md5(md5($salt).md5($pass)
Joomla 1.5.15 (default salted) md5($pass.$salt)
MediaWiki >= 1.1.0 md5($salt.md5($pass)
osCommerce md5($salt.$pass)
phpBB > 3.0.0RC5 phpass($pass)
SMF 2.0.x / 1.1.x sha1($username,$pass)
vBulletin md5(md5($pass).$salt)
WordPress > 2.5 phpass($pass)


Para ejecutar fuerza bruta sobre estos hashes se han diseñado múltiples herramientas en las que profundizaremos en otra entrada y que pueden hacer uso de las GPU de la tarjeta gráfica o no, como son hashcat, oclhashcat (GPU), Lightning Hash Cracker (GPU), PasswordsPro, Extreme GPU Bruteforce (GPU) o IGHASHGPU (GPU).

Mediante un pequeño script en php me he creado algunos de estos hashes para probar la herramienta hashcat y tomar algunas mediciones, usando como parámetros el hash de "12345", con el salt "abcdefghij" (para aquellos algoritmos que lo necesiten) y el nombre de usuario "admin":

<?php
require 'PasswordHash.php';
$pass="12345";
$salt='abcdefghij';
$username='admin';
$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($pass);
echo 'md5(md5($pass): '.md5(md5($pass))."\n";
echo 'md5(md5($salt).md5($pass): '.md5(md5($salt).md5($pass))."\n";
echo 'md5($pass.$salt): '.md5($pass.$salt)."\n";
echo 'md5($salt.md5($pass): '.md5($salt.md5($pass))."\n";
echo 'md5($salt.$pass): '.md5($salt.$pass)."\n";
echo 'sha1($username,$pass): '.sha1($username.$pass)."\n";
echo 'md5(md5($pass).$salt): '.md5(md5($pass).$salt)."\n";
echo 'phpass($pass): '.$hash."\n";
?>

Una alternativa al script es utilizar la magnífica página: Hash Generator.

La ejecución se realizó mediante un ataque de fuerza bruta de 1 a 5 caracteres con un juego de caracteres amplio:

./hashcat-cli.bin -a 3 --bf-cs-buf \
 'ABCDEFGHIJKLMNÑOPQRSTUVWXYZ-_@\!$abcdefghijklmnñopqrstuvwxyz01234567890' \
--bf-pw-min=1 --bf-pw-max=5 -m MODO -n 4 ARCHIVO

Los resultados muestran una orientación de que algoritmos serán más lentos de atacar:



Algoritmo hash/sec Tiempo Hash
md5(md5($pass) 3.48M 6m27s 1f32aa4c9a1d2ea010adcf2348166a04
md5($pass.md5($pass)) no sop

md5(md5($salt).md5($pass) 2.32M 8m52s 380208ca0107157c64d25b23ee588d5d
md5($pass.$salt) 4.28M 5m22s bdb0f53fdd087dd9be9ca316a22ae83f
md5($salt.md5($pass) 2.81M 7m15s 99c2ec6d581dae0c04a02124790273fb
md5($salt.$pass) 4.22M 5m10s f304c3e7226f0284f0d5f7c4a384e6e2
phpass($pass) 4.51k 6745m $H$9abcdefghHix3FIPIQhE2AkCoctFaC/
sha1($username,$pass) 3.83M 5m43s d4e8e6deaa7b1f8381e09e3e6b83e36f0b681c5c
md5(md5($pass).$salt) 2.94M 7m36s b5e8fe63ed242468b7834289f3024955


Lo que lleva que el que mejor aguanta el ataque es PHPASS, desarrollado por la gente de OpenWall (conocidos por ser los creadores de john the ripper), aunque desgraciadamente esta función no está disponible nativamente en PHP y será necesario instalar la clase.
Leer más...

09 agosto 2010

Fortificación de MySQL - 1/3

Parte 1 de 3
Parte 2 de 3
Parte 3 de 3
 
MySQL se ha convertido en el motor de bases de datos más usado y potente del mundo opensource. Pero debido a la versatilidad que ofrece,  la configuración por defecto en los paquetes de distribución y el suyo propio no considera todos los aspectos de seguridad que se han de contemplar en un entorno controlado.

Las siguientes entradas pretenden enumerar brevemente cuales son los puntos más importantes que se deberían revisar en una implantación segura de esta aplicación.

El archivo de configuración de MySQL se encuentra en el archivo: "C:\Program Files\MySQL\MySQL Server 5.x" en el caso de Windows o /etc/mysql/my.cnf en el caso de sistemas Linux.

1.- Restringir o deshabilitar el acceso mediante red: si el servicio se encuentra en el mismo equipo que la aplicación que realiza las consultas no es necesario que mysql escuche peticiones en todos los interfaces de red. Una de las medidas más importantes es dejar únicamente el puerto abierto en aquellas IPs donde sea estrictamente necesario. Para efectuar este cambio y que solo se pueda conectar localmente, en la sección [mysqld] indicar:
[mysqld]
bind-address=127.0.0.1
Si por el contrario queremos deshabilitar por completo el acceso mediante un socket de red, basta con añadir la directiva skip-network:
[mysqld]
skip-networking

Por último, si se ha de utilizar el servicio en remoto, todos los usuarios de las aplicaciones que conecten deben estar limitados mediante su dirección de origen (host). Desde el prompt de mysql:
mysql> GRANT SELECT, INSERT ON basededatos.* TO 'usuario'@'host';

2.- Eliminar el acceso a la tabla "user" de la base de datos a todos los usuarios excepto los de administración: de esta forma otros usuarios del motor no podrán consultar las contraseñas y accesos que contiene MySQL.

Para ver los privilegios de un usuario:
mysql> SHOW GRANTS FOR 'usuario'@'host';
Para eliminar privilegios:
mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM usuario;

3.- Deshabilitar el uso de LOCAL INFILE: mediante estos permisos se pueden leer ficheros del sistema operativo desde la base de datos, algo común cuando se explota una inyección de código SQL. Para deshabilitar esta función se configura la variable local-infile a 0:

En MySQL  anterior a 5.5
[mysqld]
set-variable=local-infile=0

Para MySQL 5.1 o superior:
[mysqld]
local-infile=0

4.- Cambio de nombre de usuario root y su contraseña: al igual que en los sistemas operativos, se recomienda que el administrador de la base de datos no sea el usuario root y mantenga una contraseña segura. Si MySQL es una versión superior a 5.0.2
mysql> RENAME USER root TO r00tz

En caso de que la versión de MySQL sea inferior:
mysql> use mysql;
mysql> update user set user="nuevousuario" where user="root";
mysql> flush privileges;

Para modificar la contraseña de un usuario se puede utilizar el comando mysqladmin o se puede hacer mediante SQL:
mysql> use mysql;
mysql> SET PASSWORD FOR 'username'@'%hostname' = PASSWORD('newpass');
5.- Eliminar la base de datos "test": que se distribuye con el servicio y no es necesaria. Para hacerlo directamente en SQL:
mysql> drop database test;
O mediante línea de comandos:
shell> mysqladmin -u username -p drop test 

6.- Eliminación de cuentas obsoletas y acceso anónimo: que son creadas en algunas instalaciones de MySQL, para comprobar si existen este tipo de usuarios:
mysql> select * from mysql.user where user="";
Si se muestran usuarios, se pueden eliminar mediante DROP USER (en MySQL 5)
mysql> DROP USER "";

Si la versión de MySQL es inferior a 5.0:
mysql> use mysql;
mysql> DELETE FROM user WHERE user="";
mysql> flush privileges;


Referencias:

Leer más...

08 agosto 2010

Enlaces de la SECmana - 31

Hoy domingo, ¿cómo de ético es que me coma unos churros y me quede toda la mañana encerrado con el aire acondicionado mientras leo? Para que luego digan que en verano la cosa no se mueve... aqui van unos cuantos enlaces:


    Leer más...

    07 agosto 2010

    Cheat Sheets de prevención y protección


    El proyecto OWASP no sólo se dedica a sacar una guía de pruebas, tiene a su vez multitud de proyectos diferentes, tanto de desarrollo, con herramientas, plugins, librerias...como de documentación en otros ámbitos (siempre relacionados como no, con la seguridad en aplicaciones web), buenas prácticas, informes, y un larguísimo etc.


    Uno de los apartados o categorías que parecen pasar desapercibidas en este proyecto, pero que deberían tenerse muy en cuenta si se es desarrollador, auditor, etc, son las Cheat Sheets, tanto de prevención como de protección, creadas y mantenidas por la comunidad OWASP.

    Aunque algunas de ellas todavía sean borradores o primeras versiones, contamos con 6 "chuletas" muy completas y que nos pueden ayudar a la hora de asegurar nuestras aplicaciones web para tener todos y cada uno de los frentes controlados a la perfección.
    • Cheat Sheet de Autenticación - En esta hoja veremos reflejadas tanto las buenas prácticas para un proceso de autenticación como gestión de sesiones. Puntos como la implementación de un adecuado mecanismo de recuperación de contraseña, mensajes de error provocados por una autenticación fallida ("si me dices que X usuario no puede registrarse porque ya existe en base de datos...hmm..."), cifrado de las comunicaciones...
    • Cheat Sheet para prevención de ataques CSRF - El famoso Cross-Site Request Forgery, que últimamente tanto se usa, pero que suele llevar a equívocos sobre su concepto y relación con los Cross-Site Scriptings (XSS). En esta hoja además se enumeran aquellas medidas que realmente no consiguen prevenir los CSRF.
    • Cheat Sheet sobre almacenamiento criptográfico - Hay que tener cuidado con los datos que almacenamos, tanto por la confidencialidad como por la integridad de la información sensible que maneje nuestra aplicación. Se proponen una serie de reglas a tener en cuenta a la hora de implantar una solución de tratamiento de la información. Es un buen resumen, aunque se recomienda en primer lugar también la Guía de Criptografía también dentro del proyecto OWASP.
    • Cheat Sheet para prevención de inyecciones SQL - Poco hace falta comentar sobre esta técnica, el juego que da y los resultados que nos puede regalar. No hay que quedarse únicamente con la recomendación de validar todos los valores de entrada que proporcionen los usuarios, hay otras medidas que se recomienda encarecidamente llevar a cabo, como es el uso de procedimientos almacenados y peticiones SQL previamente parametrizadas.
    • Cheat Sheet de protección de la capa de transporte - Este documento está bastante ligado también al de almacenamiento criptográfico. Las reglas que se nos proponen están enfocadas a las comunicaciones de nuestra aplicación web, que partes deben asegurarse y cómo, seguridad en los certificados del servidor, etc. Punto muy importante, cuando todavía a día de hoy seguimos encontrando formularios de login, registro y demás que siguen siendo válidos si los utilizamos mediante HTTP.
    • Cheat Sheet para prevención de Cross-Site Scripting - Que decir del Cross-Site Scripting, una vulnerabilidad en muchas ocasiones infravalorada, pero con un poco de astucia puede hasta hacerte salir en los periódicos. En esta ocasión, a diferencia de las inyecciones SQL, aquí lo más importante es validar correctamente los parámetros. Documento que si acompañamos de la famosa cheat sheet de RSnake, podremos estar mucho más tranquilos.
    Uniendo estas chuletas a las propias de SecurityByDefault y las que os ponemos en bandeja, yo creo que es hora de empezar a empapelar alguna que otra pared.

    ACTUALIZACIÓN: Añadida la cheat sheet de XSS, ¡gracias a vierito5 por el aviso!
    Leer más...