Este es mi passaporte, ¿te gusta?

La verdad es que no deja de sorprenderme la cantidad de gente que está pidiendo a gritos meterse en problemas. Si ya me parecía una subnormalidad que alguien publique su tarjeta de crédito en las redes sociales para que se la vacíen en compras por Internet, enredando un poco he visto que la gente publica los documentos oficiales para que cualquiera pueda falsificarlos. 

Buscando no se qué - que realmente si que se qué, pero no os lo voy a decir - en Twitter, me topé con que la gente publica cuál es la foto de su pasaporte o el passaporte completo, para que puedas hacerte  tú también uno como el suyo usando el Photoshop, y pueda ser enviado a algún sitio de esos que los requieren por fax para confirmar alguna apertura de cuenta o cancelación de algo, e incluso entrar en los USA mostrándolo en un iPad ¿}8O?

Figura 1: Foto del pasaporte publicada en Twitter

En Instagram también hay muchos, algunos con el documento entero, otros parciales, y algunos simplemente la foto.

Figura 2: Foto de pasaporte publicada en Instagram

Pero mi favorito sin duda ha sido Flickr, donde la gente publica pasaportes antiguos, nuevos, fotos, datos parciales, etcétera. Parece que es una moda. Estos son dos ejemplos de pasaportes de USA y México de los muchos que salen. Creedme cuando os digo que los cuadros en negro los he puesto yo.

Figura 3: Pasaporte Americano publicado en Flick

Figura 4: Pasaporte de Mexico publicado en Flickr

En fin, que los que necesiten de verdad una identidad, seguro que saben cómo robar una para cargar compras de teléfonos móviles pre-pago, o abrir cuentas bancarias a nombre de otras personas, etc... No vendas tu vida por tener más followers.

Saludos Malignos!

DefCON 20: Crónica maligna de una muerte anunciada

Hay miles de DefCon en una sola DefCon. Tantas, como experiencias personales que viven los miles y miles de personas que asisten año tras año a estas conferencias. Dentro de mi DefCon, una de las cosas más chulas que pude vivir es ver como Moxie Marlinspike daba una charla para matar MS-Chap-v2 en conexiones VPN y WPA2-Enterprise. Todo empezó tal que así...

La noche antes de que comenzara DefCon había una fiesta para los speakers en el hotel Rio. Ese día yo tenía que hacer el cambio del hotel Caesar's Palace y me entretuve con RomanSoft y compañía tomando una cerveza, lo que hizo que llegara tarde para recoger mi badge de speaker con el que conseguir el acceso a la fiesta. No obstante, después de cinco años hablando pensé que podría intentar entrar en la fiesta sin identificación, así que de todas formas fui.

Al llegar a la entrada una chica me dijo que sin badge no podía entrar porque no sabía si yo era speaker o no. Estuve un poco tentado a utilizar el truco de Moxie en la RSA ese de "Google me!", pero no hizo falta. Uno de los Goons estaba allí, y me dijo: "Ah!, tu eres el speaker de BlackHat, te reconocí por por el gorro, pasa". Así que, en lugar de entrar por el morro, conseguí entrar por el gorro, cosas de la vida.

Una vez arriba, tras pedir una copichuela, me fui a la terraza, para encontrarme con Renderman "Hey man, look at me!", me dijo. Renderman se había cortado el pelo, y estaba tan sonriente y divertido como siempre. Junto a él estaba Moxie, "Chema is working, Chema is working", me dijo, y comenzamos a charlar un rato. 

- "¿A qué hora hablas Moxie?"

- "A las 10:00 el sábado".

- "Vaya, yo hablo a las 11:00, no vas a poder venir a mi charla, y sales en mis diapos".

- "No creo que pueda Chema, tengo el Q&A".

- "¿De qué vas a hablar? Yo tengo que ir a las 10:20 a la speaker room, pero me gustaría ver aunque fuera el comienzo de tu charla.

- "Cracking MS-Chap-v2 in VPN con PPTP y WiFis con WPA2-Enterprise".

- "Dictionary attack?"

- "No, 100 % success attack con cracking"

- "What? No lei nada de eso"

- "Ya, fue una charla de última hora".

- "Moxie, publicamos un libro de ataques de red, y enseñamos cómo hacer un ataque de cracking VPN PPTP por Diccionario.  Me vas a obligar a hacer una segunda edición!".

Figura 0: Update. Fotograma de vídeo pirata que grabó esa conversación.

Tras la conversación, seguimos con la fiesta, pero ahí me quedó marcada la noche del jueves, y quise recordarla con un tweet que puse sobre el tema...

Figura 1: Tweet sobe la conversación que mantuvimos

El día D

Llegado el sábado, decidí pasarme a ver la charla de Moxie aunque fuera solo los 20 primeros minutos, pero cuando llegué, la cola era inmensamente enorme. En mitad de ella estaba Pedro Laguna, que nos invitó a unirnos a él, pero se lo decliné: "Voy a saludar a Moxie, y le pido que me meta con él en la sala, a ver si puedo coger un buen sitio para irme pronto".

El auditorio donde Moxie iba a hablar es de unas 3.000 personas, y aún así hubo gente que se quedó fuera para ver la charla, así que por si acaso tenía un mal sitio, me encaminé a la sala de speakers. "Morning Moxie, necesito que me metas contigo". Moxie, no puso ningún problema, me hizo el favor, y por el camino, algo así como 800 metros, fuimos hablando de su charla. "Moxie, solo tengo 20 minutos, así que cuenta lo bueno al principio". "Sure".

Una vez dentro, conseguimos acoplarnos en una de las zonas centrales. Guardé unos sitios para Pedro Laguna y Kevin Mitnik, junto a nuestro amigo Gonzalo, y allí nos quedamos todos preparados para ver la charla. La foto de Ezequiel Salis, deja claro que el ambiente no era para menos. Si consigues localizarme, habrás resuelto este "Donde está Wally".

Figura 2: Aspecto del teatro desde el nivel 2. Hay tres niveles. Encuéntrame con Pedro Laguna

Tenía poco tiempo, y Moxie comenzó su charla hablando de ... delfines que protegen a los barcos, y de cómo uno de ellos le atacó porque un marine le estaba haciendo una demo mientras un soldado de frontera le apuntaba con un arma para que levantara su mano con un cepillo de dientes. Sí... Moxie contó esa historia y tuvo a todo el mundo muerto de risa durante 5 minutos.

Luego comenzó, y en menos de 15 minutos acabó con MS-Chap-v2. Tras explicar el algoritmo, con una presentación magistral, resumió lo no-disponible cuando grabas un handshake MS-Chap-v2 a solo:

- MD4(HashUserPassword)

- DES(HashUserPasswrod)+ DES(HashUserPasswrod)+ DES(HashUserPasswrod)

Figura 3: Generación de la respuesta en el handshake

Hasta el momento seguía vigente el trabajo de Bruce Schneier y Mudge, donde se muestra que se puede romper MS-Chap-v2 con un ataque de diccionario en el handshake, pero Moxie empezó a matarlo siguiendo el trabajo publicado aquí:

Paso 1) No es triple DES, es DES+DES+DES, así que será más fácil que lo imaginado. 24 bytes.
Paso 2) Claves DES son de 7 bytes, así que hemos de quitar uno de los bytes de cada una. 21 bytes.
Paso 3) El DES se hace con el Hash MD4, que es solo de 16 bytes de longitud y Microsoft rellena con ceros hasta 21. Así que el problem se reduce a crackear un DES de los 7 bytes del hash, un DES de los 7 segundos bytes del hash,  y un DES de los últimos 2 bytes. Este último paso es trivial, así que solo debemos resolver los dos primeros. 14 bytes.
Paso 4) Como no están anidados los DES, se pueden hacer en la misma iteración, con lo que sería hacer un único 2*57.

Con ese espacio, algo ya bastante más crackeable, Moxie decidió utilizar un servicio externo de HPC y listo a CloudCracker.com. En menos de 24 horas,  descifra cualquier clave MS-Chap-v2. No habían pasado los 20 minutos, y Moxie ya se lo había cargado. Impresive...

Saludos Malignos!

Un pequeño apoyo para HackStory

La periodista Merçé Molist (@mercemolist) está creando una recopilación de la historia hacker vivida desde España, en un proyecto llamado HackStory del que ya os he hablado con anterioridad. Hacer un libro de estas características no es tan sencillo como hacer un libro técnico, en el que uno se puede sentar y plasmar desde el principio hasta el final, con más o menos trabajo, lo que uno ya conoce. Aquí hay que hacer mucha labor de investigación, de recolección de detalles y entrevistas con personas, que requiere un trabajo mucho mayor.

Merçé Molist está invirtiendo su tiempo en hacer este libro, y para poder sacarlo adelante ha organizado un sistema de donaciones en su web, en el que puedes colaborar desde ahora mismo, y aportar tu granito de arena para que todo lo que pasó quede plasmado para la posteridad.

Como una pequeña aportación desde Informática64, hemos decidido hacer una donación del 20% de las ventas de todos los libros de nuestra colección que se hagan durante el mes de Agosto de este año. Así, del dinero que pagan los compradores por tener estos libros, nosotros entregaremos el 20% al proyecto de la HackStory. 

De esta forma, o bien yendo directamente a la web de HackStory y donando, o bien a través de la compra de cualquiera de nuestros libros, podrás ayudar este proyecto, que esperemos que tenga un resultado más que satisfactorio, porque saldremos ganando todos. Desde aquí quiero darle a Merçé Molist la enhorabuena por la iniciativa y desearle mucha suerte con el resultado.

Saludos Malignos!

Ataque dirigido con JavaScript Botnet

Una de las cosas curiosas que tienen las JavaScript Botnets, es que puedes hacer ataques dirigidos a webs cuando aún está conectada la víctima al payload, para que una vez que se desconecte, la web que visite esté infectada. Esa es una demo de las realizadas en las charlas de BlackHat y Defcon, y éste es el paso a paso de la demo - que lo realicé por si algo iba mal -.

Paso 1: Configurar un nuevo ataque pre-configurado para el banco californiano. Con este panel decidimos qué ficheros vamos a cargar en todos los bots infectados con la botnet.

Figura 1: El panel de la JavaScript Botnet con los preset attacks

Paso 2: Analizamos la web en busca de ficheros javascript cargados de forma estática. Esto se puede hacer con cualquier fichero, incluso htm o html, pero nosotros hemos decidido hacerlo con JavaScript, para no cambiar el formato. En este caso, en la web de este banco de California vamos a seleccionar el fichero gatag.js para ser infectado.

Figura 2: Ficheros JS cargados por la web objetivo

Paso 3: Se configura el payload adecuado para que descargue a la caché este fichero JavaScript. Como estará utilizado el Proxy, nos garantizamos que el fichero quedará infectado en la caché, una vez se desconecte del servidor.

Figura 3: El fichero se fuerza en cualquier web visitada

Paso 4: La víctima se conecta al servidor Proxy porque así lo ha querido.

Figura 4: La víctima se conecta al Rogue Proxy Server

Paso 5: Visita cualquier página, y el fichero infectado queda descargado e infectado con el payload en la caché del navegador.

Figura 5: El fichero gatag.js con el payload copiado al final del archivo

Paso 6: La víctima se desconecta del servidor Proxy, para continuar con su navegación normal.

Figura 6: La víctima se desconecta

Paso 7: Un tiempo en el futuro, decide conectarse a la web de su banco, para realizar las gestiones pertinentes.

Figura 7: La víctima se conecta al banco un tiempo en el futuro

Paso 8: Con el fichero JavaScript gatag.js es cargado en esa pestaña desde la caché del navegador, y este está infectado, se capturan los datos enviados en el formulario.

Figura 8: Los datos enviados en el formulario quedan grabados en panel

En este caso se ha hecho la demo con un fichero JavaScript, pero se podría realizar el mismo ataque con ficheros HTML o incluso CSS, pudiendo hacerse uso no sólo de JavaScript, sino de side-channel attacks como los contados por Mario Heiderich en Got Your Nose! How attackers steal your precious data without using scripts.

Saludos Malignos!

Pwnie Awards en BlackHat 2012

Nada más terminar mi charla en Black Hat 2012 encaminé mi ruta hacia la entrega de los Pwnie Awards, uno de los momentos más divertidos de todos los años, y que tiene momentos muy especiales. Además este año tenía especial implicación por la nominación de Joxean Koret y Fermín J. Serna para los mejores bugs Server-Side y Client-Side. Una pasada. Así que allí me pasé un buen rato siguiendo las coñas de Dino Dai Zovi, Alex Sotirov, HD Moore, Dave Aitel y compañía.

Los premios fueron cayendo para el bug de MySQL y la no validación de la contraseña por estrés, para los creadores del Onwage hecho por Flame - que entre bromas acabaron recordando a Microsoft que ya en el año 2008 Alex Sotirov había dejado claro que usar MD5 para cosas serias como Windows Update no era posible -, para el trabajo de Travis de "Packets on Packets" premiado como mejor investigación en seguridad, para los bugs de Pwnium y sus miles de bugs combinados - según palabras de Dino }XD -, y el most EPIC Fail para Big-IP F5 por su bug de clave estática SSH.  Tenéis la lista de todos los ganadores publicada en la web.

Además, de todo esto, el evento estuvo amenizado por el Pwnie a la mejor canción, que se llevó Control, de DualCore, pero he de reconocer que nos echamos unas risas geniales con Click Me, versionando a Cramberris. Atentos a la letra... }XD

Después, fiestas, fiestas, fiestas, y una Cena "futa-madre" en Capo's, el restaurante italiano que debes conocer en Las Vegas, sentados en la misma mesita del vídeo que puedes ver en la web. La ambientación es genial...

Saludos Malignos!

Drop Box Public Folder y Mac OS X en la Caesar's WiFi

Para preparar la charla que he dado ayer en BlackHat, he necesitado conectarme a la red WiFi con más miedo que vergüenza. Es cierto que BlackHat es un poco menos agresiva que Defcon, donde se nota al instante que los hax0rs han llegado, pero aún así no voy con mucho cuidado y con mi VPN por delante. Sin embargo, mientras que preparo la máquina con el Windows 8, aprovecho para ir haciendo cosas en paralelo en el Mac OS X, y en una de esas me sorprendió ver que algunos otros ponentes estaban también conectados.

En este caso, algunos de los nombres que aparecen se debe a la manía que tiene Apple de poner los nombres de los iPhone, iPad o MacBook como el nombre del dueño, por lo que podemos reconocer a quién está en el hotel solo por los nombres de los Macs en la red.

Figura 1: Equipos Macs en la red con AFP habilitado

Sin embargo, si ponemos atención, lo que vemos es que estos equipos están compartiendo, por defecto, servicios por AFP, en los que hay carpetas públicas. ¿WTF?. Estos recursos compartidos por AFP pueden ser la risa en Internet, y en hoteles han llegado a que pederastas compartan material pedófilo en la WiFi y fueran denunciados. En este caso, la carpeta Public Folder es creada por Drop Box, y si analizamos los permisos, no se puede entrar en ella o lista el contenido, pero sí que se puede escribir en ella archivos.

Figura 2: Configuración de permisos de una carpeta compartida por AFP

Esto de que se pueda escribir un archivo en una carpeta en Mac OS X, es perfecto para poner un malware con señuelo en cada una de las carpetas compartidas, para ver si alguno pica y nos regala su shell en el sistema, o robar alguna contraseña. Nada, vamos a probar a ver si podemos crear un archivo en una de esas carpetas de algún equipo que no sea de un hacker, que ya que son públicas se supone que están para esto. No voy a hacer nada malo, solo un fichero de un par de bytes con el cat "for testing purposes".

Figura 3: Creando un archivo en un recurso AFP de la red

Lo curioso es que, con solo revisar las carpetas en el Finder, se puede ver el espacio disponible en todos los discos de todos los usuarios, con lo que podemos intentar borrar ficheros - si acertamos con el nombre - o dejar todos los documentos incriminatorios que se quieran en esas carpetas, y luego hacer una llamada anónima a los cuerpos de seguridad del estado para hacerle pasar un rato divertido en el aeropuerto a cualquiera de los conectados a la red.

Figura 4: Espacio disponible para crear archivos en las carpetas públicas

Pero para que sea aún mucho más divertido, si consigues robarle una password o crearte un usuario, puedes hasta conectarte al escritorio remoto, para que no te canses con los comandos, que algunos están compartidos.

Figura 5: Escritorio remoto compartido

Creo que no todos tienen las mismas paranoias que yo cuando vienen a BlackHat y Defcon, pero es que no me gustaría acabar en el Wall of Sheep }:S.

Saludos Malignos!

Error 404 en aplicaciones ASP migradas a IIS 7.X

Ya os he contado muchas veces que FOCA analiza los errores 404 de JSP, ASPX, TCL en WebDNA, etcétera, para extraer información valiosa de fingerprinting. Estos errores suelen dar datos que te pueden ayudar a dibujar la red interna, o conocer mejor la estructura de seguridad del sitio. Este es el caso de este error de IIS 7.X que es bastante común encontrar aplicaciones ASP migradas a esta versión.

Figura 1: Error 404 en IIS 6

El Error 404 que aparece en tiene una aplicación ASP sobre IIS 6 suele dar pocos detalles, tal y como se ve en la captura anterior, ya que es bastante sobrio. Pero esto cambió.

Figura 2: Error 404 descubierto buscando aplicaciones asp migradas

Sin embargo, buscando por aplicaciones ASP, y forzando un Not Found, si el sitio ha sido migrado a IIS 7 o IIS 7.5, es probable que el administrador de la aplicación no se haya acordado de fortificar el mensaje de error, por lo que es bastante común encontrar estos mensajes.

Figura 3: Error 404 en otro IIS 7 con una aplicación ASP

Como se puede ver son muy descriptivos, y permiten encontrar la estructura de permisos con los que está corriendo el application pool, el nombre de la aplicación, o rutas locales de acceso a los ficheros del servidor.

Figura 4: Error 404 en un IIS 7.5 con almacenamiento en red y direcciones locales

Por supuesto, esto funciona igual en IIS 7 como en IIS 7.5, así que hay que darle una revisión a las opciones de fortificación si migras una aplicación legacy ASP a un servidor IIS sobre Windows Server 2008 o Windows Server 2008 R2.

En una auditoría de seguridad, siempre revisamos bien todos los mensajes de error, así que si no quieres que tu servidor haga data leak por ellos, revísalos.

Saludos Malignos!

Robots en el sofá del Bank of América avistados en Google

Aunque el título suene algo extraño, lo que pone en el él es justo de lo que habla este post. Preparando una de las demos para esta semana en Las Vegas, estaba yo revisando los javascript del Bank Of America, cuando en uno de ellos salió un servidor con nombre bastante curioso:

Figura 1: Servidor en fichero JavaScript del Bank Of America

Por supuesto, la curiosidad me tenía que llevar a hacer un GET a ese servidor, a ver qué aparecía por allí, para descubrir que hay un servicio que está devolviendo el nombre de otro servidor.

Figura 2: Respuesta del servidor sofa.bankofamerica.com

Este tipo de servicios se utilizan en sistemas de reparto de carga, donde hay un controlador que redirige las llamadas al servidor menos ocupado o disponible en este momento. Por supuesto, quise saber si había algo más por allá, así que no me pude resistir a hacer una petición al robots.txt, por si podríamos estar ante un entorno vulnerable a un hacking driven by robots.txt tan común por desgracia.

Figura 3: Robots.txt en sofa.bankofamerica.com

Pero no, como era de esperar, habían tenido la precaución de prohibir a todos los buscadores la indexación de cualquier URL de este servidor, para evitar que alguien practicando el hacking con buscadores pudiera sacar petróleo. Bien por ellos.

Sin embargo, como me fio yo de los incomprendidos robots.txt más o menos lo justo, decidí hacer una búsqueda en Google a ver qué había indexado de este sitio, y la sorpresa - o no - fue que tenía un buen número de enlaces con un buen número de parámetros.

Figura 4: Enlaces de Sofa.bankofamerica.com indexados en Google

¿Por qué los indexa Google? 

Google descubre esas URLs con el mismo Google Chrome o cualquier barra de Google que esté instalada en algún otro navegador. Todas esas URLs son reportadas a los servidores, pero deberían ser filtradas. Esa fue parte de la discusión entre Google y Bing de que el segundo copiaba al primero.  Sin embargo, lo que más llama la atención es que al final Google no compruebe un fichero robots.txt tan explícito como éste. ¿Lo hará Bing.com? 

Figura 5: Bing.com no indexa nada de sofa.bankofamerica.com

Como se puede ver en la imagen de arriba Bing.com no indexa nada del Sofá del Bank Of America, como quiere el Bank Of America que suceda. Así que, voy a añadir el cumplimiento de los robots.txt como la quinta cosa que Bing hace mejor que Google... aunque para usar los buscadores como arma de destrucción masiva venga mucho mejor este comportamiento de Google.

Saludos Malignos!

No Lusers 141: Back to the future?

A 10 minutos de comenzar el embarque para mi vuelo a Las Vegas he visto las noticias de cómo está España, y casi se me da por llorar de pena. Que mi país esté llegando a estas situaciones me apena profundamente. Triste, triste, que al final los que han montando esto se vayan de rositas, y la gente lo sufra para toda su vida....

Hace un mes o así, cuando el año 2012 se dejaba ver en la economía de España, viendo una reposición de Regreso al Futuro, pensé que si Marty hubiera tenido que volver a este año  en España en la parte en que visita el futuro, la película hubiera sido, más o menos, como os he dibujado. 

Saludos Malignos!

Ligero de equipaje

Hoy estoy de viaje a Las Vegas, así que no esperéis mucha actividad mía por aquí. Como podéis ven en la foto, llevo unos calzoncillos limpios, un montón de pasta para jugármela en los casinos y comprar cosas, una petaca de alcohol para cuando esté en las fiestas privadas, la camiseta de España para ganar la HackCup, el pasaporte usado, la primera camiseta de la FOCA que se hizo, adaptadores y ladrones para los cacharros eléctricos, y un gorro de rayas recién lavado para no pasar frío con el aire acondicionado de los hoteles. El resto, lo compro allá.

Saludos Malignos!

Encontrar servidores DNS con registros PTR usando Robtex

Para hacer una prueba necesitaba encontrar un servidor DNS que tuviera configurados los registros PTR de un segmento de red. Localizar uno de estos servidores no suele ser siempre fácil, ya que los registros PTR a veces los mantiene el Primary Name Server - y este es interno - o directamente no están publicados en Internet, o puede que ni estén configurados.

Estos registros no son localizables con el esquema normal del  servicio DNS, es decir, no es tan fácil como poner una consulta PTR a un servidor DNS con la dirección IP que te interesa y que te devuelva el nombre que es apuntando por ella. Esto obliga que haya que localizar qué servidor mantiene un conjunto de ellos y hacer las preguntas de las direcciones IP adecuadas.

Como tenía prisa por encontrar un servidor DNS con registros PTR, se me ocurrió que podía utilizar el truco de buscar servidores temáticos con Robtex, pero en lugar de buscar por un rol de DNS, que seguro que me salían mucho, buscando por servidores indexados, en cuyo nombre apareciera la famosa cadena de las zonas inversas in-addr.arpa.

Figura 1: Buscando en Robtex por servidores con in-addr.arpa en el nombre

Como podéis ver, hay algo más de 800.000 registros con estos datos, lo que seguro que me daba alguno con los PTR configurados. Elegí uno al azar, y seleccionando la vista DNS de ese registro se puede ver cuáles son los servidores que mantienen a esa dirección IP, por lo que me llevaría con alto grado de probabilidad a un server manteniendo una zona arpa. Para tener más éxito busqué el Primary Name Server del dominio en el registro SOA, y me conecté a él ya que estaba publicado en Internet.

Figura 2: Vista DNS Information en Robtex

Así que nada, conexión al server, selección de registros PTR, y una consulta a localhost PTR para probar a ver si tocaba la flauta. Et voilá. Ahí tenemos un PTR curioso.

Figura 3: Registro PTR de localhost en este servidor DNS

Para comprobar que este servidor mantiene la zona in-addr.arpa, basta con hacer un escaneo de PTR manual de algunas direcciones del segmento, para poder descubrir algunos registros.

Figura 4: Respuesta a 64.65.233.1

Figura 5: Respuesta a 64.65.233.3

Es una forma rápida que se me ocurrió para encontrar servidores DNS con registros PTR, por si alguna vez os viene bien la idea.

Saludos Malignos!

Plan Vegas 2012

Los Planes de Trabajo

Ya queda nada para que me suba en el avión y vaya camino de Las Vegas, donde espero pasármelo fetén. Tengo mi agenda de trabajo, a pesar de que todo el mundo piense que me voy de fiesta, y aquí tenéis los vídeos de las charlas que he dado como prueba de que trabajo de verdad. La agenda es la siguiente:

- Miércoles 25 de Julio, a las 17:00 charla en BlackHat USA 2012
- Viernes 27 de Julio, de 09:00 a 11:00 recogida de trofeo en HackCup 2012
- Sábado 28 de Julio, a las 11:00 charla en Defcon 20
- Sábado 28 de Julio, a las 16:00 charla en Skytalks con Luís Delgado

Pero es cierto que no todo es trabajar....

El relax

Por supuesto, una de mis aficiones favoritas es apalancarme en el bar del hotel de las conferencias y tomar cervezas con todo el que pasa por allí. Ese espíritu único a CON se respira especialmente en DefCON, donde todos vienen con sus mejores galas, y están como locos por pillar a otros hackers con WiFis falsas, ataques de Juice Jacking o hacking de red para acabar en el Wall of Sheep.

Por supuesto, el sábado por la noche se organizará la típica cena en el Palms con los españoles y españoles-friends, para luego subir a la Moon.... Pero siemprevitando los problemas...

Precaución

Una de las charlas que más me llamó la atención fue la de "Qué hacer si eres detenido en DefCON". El estado de Nevada, y en especial Las Vegas, tienen una legislación curiosa. Yo ya casi fui detenido una vez por navegar por Internet donde no se debía - que ironía que me hubieran acabado deteniendo por eso }:S -, pero lo cierto es que allí las bromas no existen.

Yo le he querido hacer un homenaje a los retrasados que publican sus tarjetas de crédito en las redes sociales - junto a la ministra Bañez y el pobre Cañizares -, pero que sirva de ejemplo para recordar que allí hay tolerancia cero. Toma nota, y nos vemos en Las Vegas.

Saludos Malignos!

100 libros de "Una al día: 12 años de Seguridad Informática"

Desde que anunciamos que se acabó la tirada que hicimos del libro "Una la día: 12 años de Seguridad Informática" he tenido muchas peticiones y correos con lamentaciones por no haber tenido la oportunidad de comprarlo. Tanto es así, que hasta mi copia personal del libro la acabé regalando a un amigo que la quería mucho, mucho, mucho. Como esto no podía ser así, hemos decidido hacer una reimpresión de solo 100 unidades, que puedes comprar desde ya y lo tendrás en 24 horas en tu casa.

Hacer una reimpresión tan pequeña es un poco más caro de lo habitual, pero lo hemos hecho solo para que los que realmente quieran tener la biblioteca completa puedan conseguirlo. El coste seguirá siendo el mismo de solo 12 €, y esta será la última vez que lo podáis comprar, así que, si lo quieres, no lo dejes escapar para luego me envíes un correo de lamentación.

Saludos Malignos!

Regístrate en Wordpress y evalúa su seguridad

Cuando hacemos una auditoría de seguridad a una web o a una aplicación móvil, una de las cosas que hacemos es mirar los paneles de login para evaluar si es vulnerable a ataques de fuerza bruta, a ataques al sistema de recuperación de contraseñas o si es posible saltarse el proceso de verificación, por supuesto.

En algunos entornos en los que el sistema es multi-usuario por naturaleza, el crearse un usuario es obligatorio, para ver qué opciones se pueden configurar por defecto, o si aparecen algunas aplicaciones más que se pueda atacar. En el caso de sistemas de blogs o herramientas comunitarias, los hombres que practica las técnicas de Black SEO aprovechan para crearse perfiles falsos y promocionar sus famosas pastillas de colores.

Figura 1: Un registro de usuario en Moodle como un anuncio de Viagra

En los sistemas WordPress, a día de hoy se pueden configurar múltiples sistemas de autenticación de usuarios, pudiendo usar Twitter, Facebook, OpenID, OAuth, etc... para crear una lista de usuarios autenticados de la plataforma, pero también te puedes registrar desde el panel login si está habilitada la opción.

Figura 2: Opción de registro en WordPress habilitada

Una vez dentro, cuando llegas al Dashboard del usuario, a veces solo puedes ver algo de información, como la versión de la plataforma, pero en otros puedes encontrarte con plugins que permiten visualizar muchas opciones del sistema, como por ejemplo conocer todas las estadísticas del sitio.

Figura 3: Dashboard de un usuario registrado de WordPress

Por supuesto ese usuario que te creas no suele ser muy privilegiado, pero en otros casos se llega a poder crear posts en los blogs, o si el sitio tiene un módulo de publicación de perfiles, crear páginas con enlaces masivos para generar tráfico, hundir el pagerank del blog hackeado, o preparar ataques a aquellos usuarios que visiten esos perfiles.

No hay registro de usuarios

Si el sitio no permite el registro de usuarios, entonces la única forma que tienes de entrar dentro es atacando la password de algún usuario que exista. Si los artículos del blog están firmados por el autor, entonces podrás sacar la lista de algún usuario e intentar romper la password con un diccionario, pero quizá la forma más sencilla sea otra.

Utilizando las llamadas ?author=id en los sitios con WordPress, podrás acceder al archivo de publicaciones de un determinado autor. Normalmente el author=1 es el primer usuario que se ha creado en un sitio, y te llevará a ver su nombre en la URL. Este, por supuesto suele ser un usuario jugoso.

Figura 4: Author=1 redirige a author/admin

Haciendo un escaneo de valores de id, por ejemplo usando WPScan con la opción enumerate, es posible encontrar muchos usuarios del sistema. Una vez que tengas una buena lista, piensa una contraseña a la que algún usuario no podría resistirte y prueba en la parte de login, a ver si hay suerte.

Otra alternativa es la de utilizar ?author_name=nombre, y probar un diccionario, evaluando las respuestas vas a saber si el usuario existe y publica, si el usuario existe pero no ha publicado, o si el usuario no existe.

Figura 5: El usuario admin existe y muestra su archivo

Figura 6: El usuario chema existe, pero como no puede publicar no hay archivo

Figura 7: El usuario aaa no existe

Por supuesto, si el sitio con WordPress está fortificado y los errores controlados esto no va a ser tan sencillo siempre, pero... así es nuestro trabajo, tocar muchas puertas para ver cuál está mal cerrada. Si te encuentras una URL con wp-content, busca wp-admin y haz estas pruebas. Si tienes un WordPress, asegúrate de que todos tus usuarios tengan buenas passwords y de evitar el registro de indeseables si no te interesa que vean nada.

Actualización: Para evitar la enumeración de usuarios en WordPress puedes utilizar la configuración del NiceName y para evitar que alguien consiga romper una contraseña nada mejor que configurar Latch en tu WordPress.

Saludos Malignos!