¿Es seguro mi Joomla o mi WordPress?

En muchas ocasiones, tras acabar alguna de las demos que solía hacer hace mucho tiempo - tanto que hasta si alguna de ellas infringía alguna ley a día de hoy ha prescrito - alguien se acercaba y me decía:

"Yo tengo en mi web un {Wordpress o un Joomla o un loquesea}, ¿es seguro?"

Lo cierto es que nuestro trabajo cuando hay que hacer la auditoría de seguridad es buscar todas las configuraciones inseguras, pero decirlo a la primera es siempre difícil. De cualquier modo, lo que nosotros hacemos es inventariar lo que hay en un sitio, separando lo que ha sido hecho a mano, es decir, programado sólo para esa web, y lo que es utilizado de un software común.

Una vez inventariado, en los códigos artesanos intentamos encontrar las vulnerabilidades nosotros, haciendo auditoría de caja negra, pero en los códigos comunes, antes de hacerlo, buscamos a ver si hay exploits ya publicados por otros. Uno de los trucos que aparece en el libro de Hacking con Buscadores: Google, Bing y Shodan, es utilizar directamente Shodan para buscar los exploits de los componentes utilizados en los sitios web.

Así, si llegamos a un sitio donde hay un Tomcat, basta con irse a Shodan Exploits y buscar por allí a ver que vulnerabilidades/exploits están disponibles. Shodan está indexando las bases de expedientes de seguridad de muchos sitos para centralizar el proceso de búsqueda.


Figura 1: Búsqueda de exploits para Tomcat
En el caso de aplicaciones Web con CMS, lo más fácil es revisar la lista de plugins y buscar si hay bugs conocidos para ellos. Así, si nos enfrentamos a una web con Joomla, se hace inventario de componentes y luego se busca esta lista.


Figura 2: Exploits para componentes Joomla (aunque no creo que esté el nuestro)
Y pasa exactamente lo mismo con la lista de plugins en Wordpress, para ver si alguno de los que está en la web a analizar está sin parchear y se puede hacer uso de algún XSS, un SQL Injection o un lindo y simpático RFI/LFI.


Figura 3: Búsqueda de exploits para plugins de Wordpress
¿Por que hacemos esto? Pues porque suelen ser los puntos menos controlados de estos CMS. Normalmente, por necesidad, se busca algún componente que haga algo que se quiere poner en el sito, pero luego se suele quedar fuera de los procesos de actualización.

Si tienes un CMS, sea del color que sea, te recomiendo que hagas un inventario de los plugins/componentes que has puesto en él, y busques a ver si hay bugs/exploits conocidos. Te aseguro que los "malos" van a hacer esto mismo.

En el caso de Wordpress y Joomla! aquí tienes algunos recuersos que te pueden ayudar a mejorar su seguridad:

- Listar los plugins de WordPress
- Fortificar WordPress frente a ataques de fuerza bruta
- Instalar Latch en WordPress
- Regístrate en WordPress y evalúa su seguridad
- Cómo robarle las contraseñas a los Administradores de WordPress con XSS haciendo Phishing con Unfiltered HTML
- Guías detalladas de instalación de Latch en Wordpress, Joomla, Drupal, PrestaShop y RoundCube
- Activa o desactiva el acceso al frontend o backend de Joomla 2.5.x y 3.x con Latch
- Hardening GNU/Linux

Saludos Malignos!

No cON Name 2011 - Solo para ti

Queda 1 día, solo 1 día, para que se te pase el plazo del precio super-reducido de las entradas de la No cON Name 2011 de Barcelona. El año pasado estuvo genial, y este año lo va a estar también, por lo que deberías darte prisa y sacar tu entrada ASAP.


¿Por qué?

Pues porque es una oportunidad genial para mezclarte con un montón de profesionales del área de seguridad. Porque hay unas ponencias chulisimas de un montón de buenos ponentes como Yago Fernández Hansen, José Selvi, Pedro Sánchez, Pablo González y Juan Antonio Calles, Iñaki Rodriguez, Rafael Rodríguez Martín que hablará de la inseguridad de los casinos online, Pedro Fortuny o Sebastián Guerrero entre otros. Porque también contaremos Juan Garrido "Silverhack" y yo una charla de Terminal Hackplications. Porque además habrá un reto forense que montará Juanito para que os dejéis los sesos en él. ¿Te parece poco?

Pues además hay unos cursos, y Silverhack, que va a estar a pico-pala en la NCN 2011, además de dar la charla conmigo y de hacer el reto forense, impartirá un training de Análisis Forense de Dispositivos móviles - el más barato de todos "¡hoyga!" - y te incluye la entrada al congreso.

Y si todo esto no te parece suficiente, además estarás en Barcelona rodeado de mucha gente como tú, loca por estas cosas de la seguridad, y podrás salir a cenar, de cachondeo, intercambiar tus 0days y los chistes malos con lo peor de lo peor de toda España, que se juntará allí a pasar unos días de fun&hacking.

Puedes realizar la inscripción por la web, por solo 30 € antes del día 1 de Julio, es decir, hoy o mañana, y luego ya te buscas compañero de habitación, de borracheras y de conexión a Internet para pasar una semana en Barcelona, disfrutando de la NCN 2011 (@noconname #ncn2k11).

Saludos Malignos!

El comentario 20.000 fue...

Como ya os había avisado, el número de comentarios en El lado del Mal estaba cercano a los 20.000. Pues bien, el viernes pasado se publicó dicho comentario.

Yo le iba a dar un premio, pero como ha sido en anónimo... me lo tendré que quedar yo... en fin. Eso sí, como premio lo voy a publicar en un post. Como ha sido un comentario crítico hacia mí, denotando que tiene poco sentido del humor, me alegro de que se quede sin libro };)

El texto del comentario 20.000 fue:

Anónimo dijo...

Y en las series de telecinco desayunan Pascual...Sí, es marketing, ¡que hay que explicartelo todo!

Por cierto, si sólo hay 3 SOs (en realidad uno con el 97% de cuota) en el mercado ¿es monopolio?

¿Será ese el motivo porque MS se ha sacado a Apple de la manga?

¿Es Appel una marca "blanca" de MS?

La verdad es que cuando me pongo a pensar soy único.

24/6/11 12:16 AM

Amigo anónimo, no me como a nadie, podías haber elegido un pseudónimo para que intentara reconocerte. Sé que has puesto varios comentarios ya en este blog, por esa última frase que ya has dicho varias veces, pero de verdad... ¡que yo te quiero aunque me critiques!

Saludos Malignos!

Tineye: Un ojo de lata para detectar perfiles falsos

El año pasado, cuando coincidí con Roelof en la Ekoparty, estuvimos hablamos de qué cosas nuevas añadir a FOCA y a Maltego. En la cafetería del hotel, desayunando con facturas, me habló de un servicio que él estaba pensando si añadir para analizar fotografías, llamado TinEye.


Figura 1: Tineye
El servicio permite buscar fotografías en Internet, para descubrir otros lugares donde está siendo publicada una determinada imagen. Cuando lo probamos, aun no tenía una gran base de datos creada y no me acabó de convencer.

El otro día, en el curso de A Coruña, Juan Garrido "Silverhack", volvió a hablar de él, y le volví a dar un vistazo para ver si había mejorado el número de resultados. Lo cierto es que, probado con una de las fotos mías que más he utilizado, sale solo una coincidencia. Sin embargo, sale la coincidencia aplicando toda la potencia del algoritmo de TinEye, que le permite detectar partes recortadas de la misma. Así, dentro un montaje, detecta la parte de la foto que he utilizado.


Figura 2: Coincidencia de imagen
Este servicio no lo añadimos a FOCA porque a día de hoy no tiene una base de datos tan grande como para dar resultados espectaculares. Sin embargo, tiene un plug-in para Firefox que puede ayudar a los usuarios "más curiosos" a detectar, entre otras cosas, perfiles falsos creados a partir de fotos de Internet.

Así que, si vas a crearte un perfil falso, comprueba que no aparezca ninguna de las fotos que vas a utilizar en esta base de datos - y a ser posible tampoco en Google o Bing - y si sospechas de alguien... pasa sus fotos por aquí, a ver qué sale.

Saludos Malignos!

1997

Hace calor. El sudor me moja todo el cuerpo. Vuelvo a pasarme la muñequera sucia por la frente intentando evitar que las gotas nublen mi visión. Estoy asustado. Desde detrás de esta caja en la oscuridad lamo mis heridas. Sangro un poco en el brazo. ¿Qué era eso? ¿De dónde vino? El ruido ensordecedor de esta fábrica nubla mis sentidos. En una situación normal hubiera podido detectarlo, pero aquí el ruido suena más fuete que antes. Aviso a Rodol con un mensaje por el comunicador: “Estoy herido y perdido ¿Dónde estás tú?”. No he sabido de él nada durante la última media hora, desde que salimos del edificio. ¿Cómo ha pasado esto? ¿Cómo hemos llegado a esta situación? Me aferro al cuchillo como si fuera mi última esperanza. Nunca he sido una persona violenta. Odio la violencia y a los violentos. Sin embargo, aquí me encuentro. Atrapado en la oscuridad y aferrando un cuchillo como si no hubiera nada más en el mundo que pudiera salvarme. Otra vez ese ruido. Sin respuesta de Rodol. ¡Joder, si a mí lo que me gusta es programar, ¿por qué estoy metido en esto?!

Los segundos parecen minutos, los minutos parecen horas. He de salir de aquí, el tiempo se acaba. Me asomo a ver si hay alguien. Sigo herido, mis movimientos son más lentos. Nadie. Solo el ruido, que golpea sin cesar en mi cerebro. He de salir de aquí, es de lo único de que estoy seguro. Cuando salga, mataré a Rodol. Le atraparé y le mataré por haberme metido en esto. Avanzo despacio, intentando no hacer ruido ni ser visto. Miro a la izquierda, miro a la derecha. Una puerta cerrada al frente. ¿Será esa la salida?

De repente recibo un mensaje de Rodol: “Estoy bien, ven al laboratorio, creo que es por aquí.” ¿Al laboratorio? ¿Hay un laboratorio? ¿Cómo voy a ir a una cosa que no sé ni que existe? El corazón me late a tres mil. El recibir el mensaje de Rodol me ha hecho darme cuenta de que estoy solo. ¿Cómo me dejé engañar para entrar aquí? No importa. Hay que salir. Abre la puerta. Sin miedo. Ábrela. Estoy asustado, sé que puede encontrarse el final de mi vida tras esa puerta. Me acerco a ella. El corazón se me sale por la boca. Me acerco a la puerta. Bum-bum, bum-bum, bum-bum. Oigo mi corazón en las sienes. El sudor. Solo tengo un cuchillo. Me acerco más a la puerta. Despacio. Mi cuerpo está en tensión. Oigo algo al otro lado. No tengas miedo Chema, ¡joder!. Acércate. Abre la puta puerta. Avanzo. ¡Joder, hay algo, seguro, al otro lado! Echo el cuchillo para adelante. Probándolo en el aire. Hace calor. Abro la puerta.

Los ruidos se disparan. No veo nada, pero oigo gritos. Gritos y disparos. No estoy solo. Entro en la habitación, buscando un rincón seguro donde agazaparme sin ser visto. Pero de repente… se abalanza sobre mí. Joder. Corre Chema. Dale con el cuchillo. Es un monstruo con brazos mecánicos. Y yo solo con el cuchillo, si al menos tuviera un railgun…

[clic] Se enciende la luz de la habitación. Giro la cabeza y me quito los cascos. Mi madre.

“Josemari, cariño, ya llevas casi dos horas jugando con Rodol por el teléfono. Va a costar mucho dinero y es muy tarde… ¿por qué no cortáis ya?”

“Es que aún no he llegado al laboratorio, y dice Rodol que es por allí, y…”

“Hijo, mañana hay que ir a clase, no puedes pasarte tanto tiempo jugando. Anda, dile a Rodol que mañana jugáis más”.

“Vale, ya corto”.

Abro el chat:

“¿Rodol? Tengo que cortar el RRAS, mi madre me manda a acostar, ya es tarde, ¿ok?”

“OK. Mañana seguimos, que yo tengo examen y nos vamos a gastar una pasta.”

Uff. Casi me siento aliviado de salir de la partida. Yo no estoy hecho para este tipo de juegos. Este Quake II va a acabar conmigo, y más si echamos la partida en red con el servicio este del RAS en Windows NT, yo creo pierdo años de vida cada vez que juego a esto…

Saludos Malignos!

La agenda de Tony Blair

Tony Blair siempre sale en mis charlas sobre metadatos por su "brillante" historia de las armas de destrucción masiva y el documento en word con metadatos que "ninguno de sus chicos" había manipulado. Es una historia divertida de metadatos dentro de una fea historia de guerra.

Este motu ha sido el tema elegido por el grupo de hackers TeamP0isoN_ para hacer el disclosure de la agenda de contactos de de Tony Blair, obtenida tras hackear - aun no se sabe cómo - el servidor webmail que usaba el ex-primer ministro inglés en diciembre de 2010.


El ASCII ART que acompaña el disclosure
No se ha hecho disclosure de los correos, pero si de la agenda de direcciones, teléfonos, contactos y algún documento, lo que hace pensar en el hackeo de un frontral webmail y la obtención de páginas y adjuntos cacheados.

Toda la información se ha hecho pública, avisando por el twitter del grupo @TeamP0isoN_ y poniéndola disponible en Pastebin. - Por favor, recoradad que si os bajáis el fichero a vuestro equipo y sois españoles deberéis reportarlo a la agencia de protección de datos, o estaréis incumpliendo la LOPD al guardar una base de datos sin reportarla -.

Este grupo ya saltó a la fama por haber "hecho amigos" con otros grupos de hackers, como con Crypto o Lulzsec, y, por supuesto, por tener sus propias Black-Ops con sitios web en Internet.

Me gustaría recordarle a los que se emocionan con más facilidad, que este tipo de actividades, en muchos países, están siendo premiadas con bonitas y entretenidas vacaciones pagadas en hospedías de todo incluido, durante periodos que van de 1 a 5 años y 1 día, y que por ejemplo los hackers de AT&T están a punto de retirarse a reflexionar a un sitio sombrío durante un buen periodo de tiempo. Para todo lo demás: VPNs, Tor y WiFis "públicas".

Saludos Malignos!

Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
Autores: Juan Garrido "Silverhack" y Chema Alonso
**************************************************************************************************

Remote Desktop Protocol

Es un protocolo propietario de Microsoft, gracias al cual se puede proveer a un usuario de un escritorio remoto. La primera versión de este protocolo, se gestó gracias a las negociaciones que realizaron en su día Microsoft y Citrix, para que este último, autorizase a Microsoft a incluir librerías de Citrix, para la publicación de escritorio en servidores basados en NT. A día de hoy, el protocolo se encuentra en su versión 7.0, y se incluyen algunas novedades, como son las siguientes:

• Publicación de aplicaciones (RemoteAPP)
• Cifrado en las comunicaciones
• Publicación a través de puerto 443 (HTTS Redirect)
• Publicación de servicios virtualizados

Por defecto, el puerto principal por el que opera Terminal Server, a la hora de ofertar servicios de publicación de aplicaciones y escritorio remoto, es el 3389, por lo que puede ser utilizado para descubrirlo con un escaneo nmap en la red, tal y como se vio en la parte anterior.

Para conectarse a un servidor de Terminal Services, el cliente utiliza un fichero en formato RDP en el que se configuran los parámetros de la conexión. Este fichero puede ser descubierto por su extensión utilizando Google, al igual que hacíamos con ICA.


Figura 13: Descubrimiento de ficheros RDP en Google
Utilizando BING se puede hacer algo similar, pero para este buscador es tomado como un fichero de texto, por lo que tenemos que utilizar como ancla algún parámetro dentro del fichero RDP. Si nos fijamos en el contenido del mismo, se pueden ver algunos bastante interesantes.


Figura 14: Ejemplo de fichero RDP
Remoteapplicationprogram, remoteapplicationmode, remoteapplicationname o remoteapplicationcmdline son parámetros en los que se configura, de manera distinta, el programa que se tiene que ejecutar una vez que el usuario se autentique correctamente en el servidor, y puede ser utilizado para descubrir los ficheros en BING y para descubrir algunas aplicaciones en el mismo.


Figura 15: Descubrimiento de ficheros RDP con BING
Algunos de ellos vienen ya configurados con el usuario y la contraseña, cifrada con las funciones CryptProtectData y CryptUnProtectData de crypt32.dll. Esto hace que la contraseña solo pueda ser descifrada desde el servidor, y no en el cliente, ya que la clave de cifrado y descifrado está en el servidor de Terminal Services y no en la máquina del cliente. Esto está muy bien explicado un artículo de Remko Weijnen, que además ha hecho una pequeña tool para que compruebes cómo genera los hashes con este mecanismo tu propio equipo. Probado en dos equipos distintos, los hashes son distintos.


Figura 16: RDP Password Hassher
Aunque no es posible crackear la contraseña, sí que es posible conseguir acceso con un sesión de ese usuario en el equipo remoto, para que se ejecute alguna de las aplicaciones configuradas en los parámetros vistos antes. En Internet, es posible descubrir muchos de ellos con la password cifrada configurada en el fichero.


Figura 17: Ficheros RDP con passwords en BING
Los servicios de Terminal Services pueden ser embebidos en aplicaciones web que, una vez autenticado, permiten ver la configuración de la conexión que se va a realizar, o la lista de aplicaciones disponibles, tal y como se puede ver en esta página web publicando el TSGateway.


Figura 18: Configúración de TSGateway embebida en código HTML
Por supuesto, estas búsquedas para encontrar servidores web que publican aplicaciones por Términal Services también se pueden realizar utilizando Shodan o Google. Búsquedas sencillas como pueden ser las siguientes:

• “RemoteAPP”
• “RDWEB”
• “inurl:"RDWeb/pages/" ext:aspx”

Con los ejemplos vistos en este artículo, es bastante sencillo descubrir si una organización está haciendo uso de una de estas tecnologías para publicar aplicaciones o escritorios remotos utilizando Terminal Services o Citrix, que nosotros incorporamos en FOCA 2.7. En el siguiente artículo de esta serie veremos cómo hacer fingerprinting de las aplicaciones internas de un servidor, cómo saltarse políticas de seguridad y cómo hacer elevación de privilegios.

**************************************************************************************************
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (1 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (2 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (3 de 4)
- Hacking Remote Apps: Fingerprinting con Terminal Services & Citrix (4 de 4)
**************************************************************************************************

Los villanos usan tablets con Windows

Como muchos ya sabéis, soy uno de esos tipos rarunos adicto a los tios cachas con mallas y calzoncillos por fuera. Esto me lleva a pasar horas viento capítulos de series como Flash, Superman de los años 50, Spiderman en dibujos animados o el gran Batman. Y como buen enfermo, me fijo en los detalles rarunos, como que Robocop utiliza MS-DOS, y en las nuevas versiones de Robocop seguían con código Legacy.


Robocop, que es bueno, usa DOS
Dicho esto, confieso que estaba viendo el otro día un capítulo de SmallVille, ya sabéis, esa serie que nació como una mezcla de Superman y Sensación de Vivir, como la definió un amigo mio, cuando la villana de ojos de dos colores, utilizó un tablet para analizar unos datos, y la sorpresa fue:


Tess Merkel, que es mala, utiliza Tablet con Windows 7
Sí, no es un iPad, es un tablet con Windows 7 original, como el que usan mis compañeros para programar las aplicaciones multitouch para niños (PuzzleAnimal o Piano) que están publicando. Visto esto, está claro que solo los villanos usan Windows para tablets...

UPDATE: El día 30 de Junio hay un Webcast gratuito sobre cómo hacer aplicaciones para tablets Multitouch con Windows 7.

Saludos Malignos!

Cursos de Verano para to's

Hoy da comienzo al I Curso de Verano de Informática Forense de la Universidad de A Coruña, donde aprovecharé para pasar la noche de San Juan. Éste será el primero de la no demasiada lista de cursos que tenemos para este verano, así que os dejo la agenda de lo que tenemos previsto por si os apetece apuntaros a alguno:

El día 24 da comienzo el Módulo II del FTSAI, dedicado a Seguridad y Auditoría de Servidores y Clientes. Te puedes apuntar a este módulo de forma independiente, y enganchar con el resto de sesiones.

La semana que viene, última de Junio, tendremos el IV Curso de Verano de Seguridad y Auditoría Informática en la Universidad Europea de Madrid. Allí estará una lista enorme de buenos ponentes, como Pedro Sánchez, Igor Lukic, Rubén Santamarta, José Selvi, los chicos de Taddong, Silverhack, Sergio de los Santos, etc... vamos, como para perdérselo.

Ya en Julio, primero iré al Curso de Verano de Televisión 2.0, en la Universidad del País Vasco, donde daré una charlita, y luego me pasaré por le II Congreso de Internet del Mediterraneo en Alicante, a dar una conferencia.

Por otro lado, mi compañero Silverhack dará el II Curso de Análisis Forense de Dispositivos Móviles en Madrid, los días 8 y 15 de Julio, para después de esto, irnos los dos juntitos de la mano a Las Vegas.

Si queréis hacer algo más online o en Madrid, durante los meses de Junio y Julio continuarán las Hands On Lab y los Virtual Hands On Lab, pero en Agosto haremos vaciones, como está mandado.

Saludos Malignos!

Lisbeth, ¿que has hecho qué?

En el DISI 2009 tuve la suerte de estar entre los ponentes y en el debate. Me lo pasé genial. Además, la gente podía hacer preguntas y hubo una que me pilló.

- “Chema, ¿lo que hace la hacker de la trilogía Millenium es verdad?”

No pude contestar porque no me había leído el libro, pero decidí leérme el primero de la trilogía: Los hombres que no amabana a las mujeres. Y he de reconocer que el autor me enganchó en ese pacto de ficción con la historia.

Muy entretenida. Me enganché, me lo bebí en unos días. Ya estaba enamorado de Lisbeth cuando llegué, en las últimas páginas del libro, a la explicación de cómo había hackeado la computadora del malo. Con lo fácil que hubiera sido hacer un spoofing de una dirección de correo de un compañero de trabajo y meterle un troyano con un PDF, la explicación que da en el libro es la siguiente…

-Lisbeth, ¿cómo es posible que puedas controlar, prácticamente, su ordenador?

- Es un pequeño invento de mi amigo Plague. Wennerström tiene un portátil IBM en el que trabaja tanto en casa como en su oficina. Eso quiere decir que toda la información está en un único disco duro. En su casa tiene banda ancha. Plague ha inventado una especie de manguito que se sujeta alrededor del propio cable de la banda ancha y que yo estoy probando para él; todo lo que ve Wennerström es registradro por el manguito, que envía la información a un servidor instalado en algún lugar.

Nota Maligna: Asumimos que tiene un sniffer que envía los datos a un servidor.

- ¿No tiene cortafuegos?

Lisbeth sonrió.

- Sí, tiene uno. Pero la idea es que el manguito también funciona como una especie de cortafuegos. Por eso piratear el ordenador lleva su tiempo. Pongamos que Wennerström recibe un mensaje de correo electrónico; primero va a parar al manguito de Plague y puede ser leído por nosotros antes de que ni siquiera haya pasado por su cortafuegos.

N. M.: Vale, aceptamos manguito como un sniffer para leer el correo…o eso parece.

Pero lo ingenioso es que el correo se reescribe y recibe unos bytes de un código fuente. Esto se repite cada vez que él se baja algo a su ordenador. Funciona aún mejor con las fotos. Wennerström navega muchísimo por Internet. Cada vez que descarga una imagen porno o abre una nueva página web, le añadimos unas líneas al código. Al cabo de un tiempo, unas horas o unos días, dependiendo de lo que use el ordenador, se ha descargado un programa entero de unos tres megabytes en el que cada nuevo fragmento se va añadiendo al anterior.

N. M.: Joder con la banda ancha, unos días para tres megabytes. Y claro, lo de sacar el porno en este contexto es un recurso superhacker. Osea, que estás metiendo basura al final de los archivos que sale sola y se empalma sola en un archivito. No te olvides de bindear algún programa completo al final de un ejecutable que si no, no sé como vas a unir todos esos bytes desperdigados. Además espero que hayas hecho una buena lista de donde has ido poniendo los bytes para que los encuentres a la hora de montar el programa completo.

- ¿Y?

N. M.: Eso digo yo, ¿y?

- Cuando las últimas piezas están en su sitio, el programa se integra en su navegador de Internet.

N.M.: ¿Qué apostáis a que sale Internet Explorer en esta película para que sea más creible?

A él le da la impresión de que su ordenador se queda colgado y debe reiniciarlo.

N.M.: Será para que cobre vida la unión de piezas o la compilación del código fuente ese que iba a cachitos en los correos electrónicos y las fotos porno.

Durante el reinicio se instala un programa completamente nuevo. Usa Microsoft Explorer.

N.M.: Uys… casi acierta con el nombre…

La siguiente vez que Explorer se pone en marcha, lo que en realidad está arrancando es otro programa, invisible en su escritorio; se parece a Explorer y funciona como él, pero también hace muchas otras cosas.

N.M.: Sorpréndeme más.

Primero asume el control de su cortafuegos y se asegura de que todo parezca funcionar perfectamente. Luego empieza a escanear el ordenador enviando fragmentos de información cada vez que navega y hace clic con el ratón.

N.M.: ¡Coño!, ¡Con lo fácil que hubiera sido meter un Zeus…!

Al cabo de un tiempo – depende de lo que navegue por Internet-, nos hemos hecho con un espejo completo del contenido de su disco duro en un servidor que se encuentra en algún sitio [debe ser la nube]. Así llega la hora del HT.

N.M.: ¿Del cualo?

- ¿HT?

N.M.: Eso ya lo dije yo.

- Sorry. Plague lo llama HT: Hostile Takeover.

N.M.: Perdona Lisbeth... ¿qué has hecho qué?

Saludos Malignos!

Tuenti Security Issues (III de V)

************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************

Issue 10: Hijacking en “redes inseguras”

Tras el análisis en el issue 9 de lo que es una “red insegura” o no en un entorno como el de Tuenti, hay que hablar del clásico del robo de la sesión o hijacking de una cuenta en Tuenti. Para que sea entendible por todos, baste decir que cuando un usuario se autentica contra una aplicación web, esta genera un conjunto de variables en el servidor que le identifican de forma única, y que se entregan al usuario en forma de cookie. Esa cookie se convierte en un token que le permite entrar en todas las partes de su cuenta, y debe ser enviada en cada petición.

Si esta cuenta se envía por HTTP, es decir, sin cifrar, cualquier persona con acceso a la red podrá acceder a ella, copiarla y utilizarla para entrar en su cuenta.
Estos ataques de hijacking se han hecho de forma “artesanal” habitualmente, o con herramientas personales, como el caso de nuestra Grifa, pero desde que se presentó en ToorCON la herramienta Firesheep, esto se convirtió en un juego de niños. En Seguridad Apple publicamos un ejemplo de cómo realizar hijacking a cuentas de Tuenti con Firesheep.

Figura 9: Uso de Firesheep con Tuenti

Redes sociales como Facebook y Twitter, desde la aparición de herramientas automatizadas como Firesheep permiten a los usuarios que todas las conexiones vayan cifradas con HTTPS, eliminando muchos de los issues que aparecen en esta serie.

Issue 11: No firmado de parámetros en cookie

El uso de Firesheep a la hora de robar una sesión, siempre suele ir asociado a un ataque en la misma red. Sin embargo, si la cookie es robada por una vulnerabilidad de XSS, tal y como ya se ha visto en muchas ocasiones, haría que el ataque de hijacking se hiciera remotamente, es decir, desde otra red remota. Para evitar esto, las aplicaciones web utilizan firmado de parámetros de cookie que identifican la posición de la conexión original, para identificar cuando ha sido robada.

Por ejemplo, un cambio en la dirección IP de una conexión puede producirse por muchas causas, tales como una renovación en el DHCP o un cambio en la configuración del operador de servicios de Internet durante la conexión, pero también puede significar un robo de la cookie y una conexión fraudulenta.

Debido a esto, muchos de los servicios web en Internet optan por restringir las cookies a las direcciones IP de las conexiones, o incluso cifran características propias del navegador que se usa en la conexión. De esta forma, aunque no se reduce el riesgo total, sí que se consigue que los ataques de Hijacking se limiten a zonas de ataque cercanas.

En el caso de Tuenti esto no es así, y basta con robar la conexión para poder crear una cookie que permita el acceso desde cualquier sitio. Se podría poner una sonda en cualquier “red insegura” capturando las cookies de Tuenti. Luego enviar esas cookies a otra ubicación y crear una nueva sesión con ella.

Figura 10: Captura de cookie de Tuenti con Wireshark

Con cualquier complemento para gestión de cookies, como por ejemplo Cookie Editor para Google Chrome o Firefox, se crea una nueva cookie con el nombre sid, en el campo valor se copia el valor capturado en sid, el dominio será .tuenti.com y el path /.

Figura 11: Cookie Editor haciendo cociando una galleta de Tuenti
Una vez añadida la cookie es suficiente con ir a la página de tuenti.com y se entrará directamente en la cuenta de la víctima. El resultado es el siguiente:

Figura 12: Dentro de la cuenta
Esta demo es cortesía de mis amigos de Flu-Project }:)). Como curiosidad, las cookies del tuenti móvil, aunque se llaman de forma distinta, permiten realizar exactamente lo mismo, y se pueden usar en las conexiones desde equipos de escritorio.

Issue 12: Imágenes de perfiles estáticas

Tuenti utiliza servidores de la red Tuenti.Net para almacenar las fotos que los usuarios suben a la red. No hay ninguna protección extra más allá que saberse el nombre del fichero de la foto, con lo que basta con saber el nombre de la foto como para hacerla pública a todo el mundo. En este ejemplo, el link a una foto de un amigo mío en Tuenti.

Issue 13: Configuración insegura de robots.txt frente a Google

En teoría, la mayoría de los servidores de Tuenti.net tienen configurados los servidores web con un robots.txt que prohibe la indexación de los contenidos. Sin embargo, saltarse el fichero robots.txt no es complicado, y a veces, es tan sencillo como poner links de forma correcta. Así, a pesar de que tengan configurado ficheros robots.txt restrictivos, como el caso de del servidor http://ll3.images.tuenti.net/robots.txt, resulta que sus contenidos acaban indexados.

Figura 13: Contenidos de tuenti.net indexados

Además, esto pasa con muchas fotografías que quedan indexadas en Google. Es por esto que sería necesario utilizar un dispatcher de fotos que compruebe la sesión del visitante de la foto. En este caso, subir una foto a Tuenti es hacerla pública.

Google ofrece herramientas para Webmasters para eliminar de la caché todo lo que no deba ser indexado. En esta captura se ven imágenes, aplicaciones y servidores web con configuraciones por defecto.

Por último sobre este tema, es curiosa la protección contra el Http-referer de Google, es decir, que si alguien viene desde Google no se le deja ver la página, pero basta con recargar la página para evitar el HTTP-Referer y la imagen sale. No entiendo bien la protección que han puesto ya que Http-referer no es necesario para hacer un GET.

Figura 14: Referer prohibido

************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************

Apple jodida por la Viagra por enésima vez en la web de itunes.apple.com

La web de Apple no es que sea un dechado de preocupación por la seguridad. Al igual que las grandes compañías, con una presencia descomunal en Internet, el número de sistios y páginas web expuestas es ingente y, hasta cierto punto, es hasta normal que se les escape alguna cosa, pero lo de Apple con la web de iTunes no tiene nombre.

Ya en Agosto del año pasado la cazaron en una campaña de búsqueda de SQL Injection automático, inyectando scripts que distribuían malware.


Figura 1: En Agosto de 2010 itunes.apple.com servía scripts rusos
Volvió a ser pillada en la campaña Lizamoon, que se hizo para distribuir un Rogue AV entre los visitantes.


Figura 2: En Marzo de 2011 itunes.apple.com servía rogue AVs
En estas dos ocasiones anteriores, esto significaba que bastaba con que un usuario navegase por la web de itunes.apple.com para que desde este sitio se le intentara infectar.

Pasado ya casi un año, era de esperar que ya hubieran sido capaces de dar con el "cómo se la metieron", pero parece que siguen estando en sus trece, y pasan de arreglar nada, así que, a día de hoy, la web de itunes.apple.com está jodida por las farmaceúticas, y basta con hacer la prueba de ver si estás jodido por la viagra en Apple para obtener más de 1.500 páginas web vulneradas.


Figura 3: La extraña relación de Apple y la Viagra
Lo gracioso es que el lugar de la inyección no es visible a primera vista, ya que está en la descripción de los podcasts, pero basta con hacer clic en la i de información para ver todo el mensaje.


Figura 4: Los mensajes de las farmaceúticas en los podcasts
Y digo yo, viendo todo lo que le está cayendo en Internet a todas las grandes, ¿no debería hacer de una vez los deberes en seguridad en este sitio?

Saludos Malignos!

DUST en la RootedCON 2011: El nacimiento

Decidimos que la RootedCON era el sitio ideal para publicar DUST, así que no publicamos nada en ningún sitio sobre esta herramienta hasta que llegara el día del congreso. Sé que a muchos les pilló con el pie cambiado, pues las caras que yo veía desde el escenario eran curiosas. Aún no estaba muy avanzado el desarrollo de DUST, pero ya teníamos un piloto que funcionaba, así que enseñamos una demo de él. Ayer publicaron ya todos los vídeos de la RootedCON 2011, así que, para los que no tuvieron ocasión de ver la primera presentación en sociedad de DUST, os la dejo aquí mismo.

Alejandro Martín & Chema Alonso - Pulveriza tus publicaciones con Dust (Rooted CON 2011) de RootedCON.

Saludos Malignos!

Los backups de Joomla y las passwords en MD5

Para la charla de ayer en La Red Innova, que ya puedes ver en Youtube, no tenía mucho tiempo, pero quería hacer algo que la gente pudiera ver, así que preparé varias demos de Google Hacking, que me permitieran mostrar cosas sin incumplir ningún precepto del nuevo código penal (creo!)

Así que, entre otras preparé alguna con backups de bases de datos, tal y como cuenta Enrique Rando en su libro de Hacking con Buscadores, ya sabéis, buscando ficheros con extensiones SQL o DUMP, muy comunes en las copias de seguridad de bases de datos.


Figura 1: Buscando backups en ficheros SQL
Haciendo esas búsquedas salen muchos archivos, pero aún así la demo me obligaba a buscar en varías páginas, abrir varios links para encontar "carnaza" que enseñar. Había que afinar más la query.

Como ya habíamos estado mirando Joomla, por aquel bug que reportamos en un componente - y que luego se lo parcheamos y todo -, sabía que la tabla de los usuarios de Joomla, por defecto, se llamaba jos_users, así que para afinar más la búsqueda podría pasar a hacer algo como esto: ext:sql jos_users.


Figura 2: Buscando backups de Joomla

En ese punto ya salen los resultados de sitios que tienen backup de esa tabla en concreto, lo que hace que salgan muchos sitios con sus usuarios y sus contraseñas. Sin embargo, muchas salen en Hashes, que hay que crackear - sí, también podemos utilizar Google para ello y ver si ya están crackeados - pero para simplificarlo, me di cuenta que en algunos ficheros se utiliza la función md5() para indicar que lo que se va a introducir en ese campo es el hash md5 de lo que se le pase por parámetro. Es decir, que como parámetro de la llamada a la función md5() va la password en texto claro. Así que es suficiente con buscar algo como: ext:sql jos_users "md5(" y leer las passwords en texto claro. Sencillo, ¿no?


Figura 3: Buscando backups de Joomla con passwords en texto claro

Saludos Malignos!

No olvides Dusterizarte y Super-Vitaminarte

Durante esta semana hemos tenido también la buena noticia de que DUST, la herramienta para distribución de feeds RSS por medio de fuentes redundates HTTP/P2P-PGP ha sido aceptada también para ser presentada en la Defcon 19 de este año en Las Vegas.

DUST es un proyecto al cuál le tengo un cariño especial, ya que tiene un trasfondo académico y social por detrás que me gusta mucho. Así que, desde que se fraguó la idea, ha habido una persona en Informática64 trabajando todo el tiempo en él, para dejarlo muy fino. David (ole!) que está picandose el código, esta semana estaba suficientemente satisfecho con él como para que se publicara, así que lo haremos.

En estos días estamos montando un nodo de DUST permanente en Informática64 para los que necesiten ayuda inicial en la conexión de su cliente a la red P2P y hacer mucho más fácil la transición a este cliente.

Por supuesto, El lado del Mal será el primero que se publique por DUST, y vamos a hacer una lista piloto de bloggers que quieran publicar por DUST, a los que vamos a dar soporte personalizado a la instalación y preparación del entorno.

Así que, si tienes un blog, y quieres que te pasemos el código fuente de DUST antes que a nadie, que te ayudemos a configurarlo, y que te resolvamos todas las dudas que tengas para que puedas ponerlo fino y andando, ponme un correo electróncio con el asunto DUST TEST y nos pondremos en contacto contigo.

Para los que no sepan en qué consiste DUST, la presentación que hicimos en la RootedCON 2011 la tienes aquí, y trascrita a un artículo en la serie DUST: Tu feed RSS es tuyo. Además tienes, una breve introducción, un vídeo de cómo funcionan las fuentes redundantes en DUST y en el evento Asegúr@IT 9 se presentó y tienes la charla disponible online.

¿Por qué usar DUST? Si después de ver los artículos anteriores no te ha quedado claro, aquí te dejo un par de motivos más:

- Wikileaks: la nube es mía y tu no juegas
- Más motivos para ser polvo
- Con Dust nunca mas(t)

Y ya sabes, no olvides dusterizarte y supervitaminarte!

Saludos Malignos!

Un iPhone, un iPad, un rogue AP y un error de seguridad histórico

Una de las características más destacables que tiene el sistema iOS de Apple es su sencillez de uso. Esta manera de ser hace que para muchos usuarios sea una herramienta perfecta, que pueden aprender a utilizar de forma rápida, lo que es parte de la popularidad que ha adquirido el teléfono iPhone y el popular Tablet iPad.

Sin embargo, esta simplicidad, en muchos casos está reñida con la seguridad los usuarios y así se ha visto en varias ocasiones. El no poder configurar una política de carga de imágenes o no en los correos electrónicos personalizada por mensaje, el no poder ver el código original de un mensaje de correo electrónico o el que una página web pueda quitar la barra de direcciones en el navegador, abren vectores a los atacantes. Vectores, que en sistemas operativos con más solera, hace tiempo que son conocidos, por tener mucha historia ya tras de sí, y se configuran con cuidado.

Hoy voy a hablaros de otro vector de ataque clásico que ya es conocido, pero que iOS no configura correctamente, y es la política de conexión a redes conocidas, que puede dar como resultado un ataque Man in The Middle en WiFi por medio de un rogue AP, es decir, por un falso punto de acceso WiFi que simula ser la red “habitual” de la conexión.

El primer fallo: La lista de redes conocidas

Hay que destacar que la primera característica de falta de seguridad es la no posibilidad de ver cuál es la lista de redes que conoce un iPhone o un iPad. Esta lista se encuentra almacenada en un fichero que se encuentra en la ruta /private/var/Keychains/keychain-2.db, pero que no puede ser visualizada desde ninguna opción del dispositivo, lo que deja al usuario “ciego” ante esta configuración.


Figura 1: Conectar automáticamente a las redes conocidas
La única forma de eliminar una red conocida es encontrase cerca de ella, y mediante una opción “olvidar esta red”. En cualquier caso, frente a un ataque de Rogue AP, esto sería inútil, ya que utilizaría el nombre de una red que el usuario sí quiere tener en su configuración, lo que no ayuda en mucho.

La opción de "Preguntar al conectar" es una de las menos entendibles opciones de la WiFi, ya que, se seleccione preguntar o no, siempre hace referencia a nuevas redes y no, a las redes conocidas, a las que se conectará de forma automática.


Figura 2: En cualquier caso, conectar automáticamente a las redes conocidas
El segundo Fallo: ¿Cuál es la política de conexión a las redes conocidas?

Esta es una de las preguntas con la que más hemos estado jugando. Supongamos un entorno en el que nuestro usuario tiene un alto movimiento geográfico y se conecta a 20 redes conocidas con asiduidad.. ¿cuál es la política de conexión de redes que sigue iPad? En el caso de clientes Wifi de Ubuntu en la versión 8.0.4 utilizaba una política de orden alfabético, mientras que en Windows y las nuevas versiones de Linux se puede elegir el orden manualmente. En el caso de iOS hemos visto que aplica una política LIFO, es decir, la última red conectada es la que tiene prioridad, pero en ningún caso el usuario puede configurar esta política.

El tercer fallo: y más importante ¿Cómo reconoce a una red conocida?

Pues hemos podido constatar que esta política ha cambiado en las diferentes versiones, pero sigue siendo mala. En las versiones probadas inferiores a iOS 4.2.1, el reconocimiento de una red se hace solo por el SSID, es decir, únicamente por el nombre de la red. Esto abre muchos vectores de ataque, ya que bastaría con saber cuál es el nombre de la red utilizada en un entorno para crear una con el mismo nombre totalmente abierta, para que los usuarios de iPad, iPod Touch o iPhone con versiones anteriores se conecten automáticamente a ellas.

Lo curioso es que, ante la existencia de las dos redes en el mismo entorno físico, prevalece la que tiene más potencia de señal. Así, como se puede ver en este entorno, tenemos un iPad con 4.2.1 conectado a una red WPA2-PSK, en la que se puede ver el candadito.


Figura 3: iPad conectado a red segura
Creamos una red abierta, sin cifrado alguno ni autenticación, y lo que se consigue es iOS se desconecte de esa red y pase a conectarse al falso Rogue AP.


Figura 4: iPad se desconecta de la segura y se conecta a la insegura
Para iOS en versiones 4.3.1, hemos podido hacer las mismas pruebas, y esto no funciona de la misma manera, sin embargo, sigue abriendo un vector de ataque.

El cuarto Fallo: Reconocimiento de la red por nombre y descripción, pero no por el ESSID.

Una red puede identificarse por el SSID (nombre), el BSSID ( solo para un único punto de acceso) o el ESSID (Extended SSID), para aquellas redes que tiene más de un AP que da servicio al mismo SSID. Es por ello que si en un edificio hay muchos AP con el mismo nombre para la red WiFi, el equipo puede ir saltando de uno a otro con normalidad. Si una red es de infraestructura debe ser reconocida por su ESSID, sin embargo iOS en la versión 4.3.1 (la que hemos podido probar) permite conectarse a cualquier AP que tenga el mismo SSID y la misma configuración de cifrado y autenticación. Y esto es un fallo de seguridad.

¿Por qué?

Pues es un fallo porque cualquier miembro conectado conoce la configuración de la red, por lo que puede crear un rogue AP con la configuración esperada por un iPhone o un iPad y hacer un man in the middle perfecto.

¿Solución?

El primer paso, evidentemente es actualizar a la última versión de iOS todos los dispositivos, ya que el funcionamiento en 4.3.1 es mejor que en el resto de los casos. En el caso de las empresas, utilizar sistemas NIDS para detectar los AP que se conectan en los alrededores y en el resto de los entornos (aeropuertos, cafés, hogares)… tener mucho cuidadito, ya que, al no poderse ver las redes WiFi conocidas, es muy probable que alguna vez se haya conectado a alguna red Default, Public, Wifi, o similar, que pueda ser fácilmente suplantada.

Saludos Malignos!

Limpieza segura con Don Limpio

Ya hemos visto el cambio de papeles entre los partidos políticos salientes y entrantes de los nuevos equipos de gobierno, - y las consiguientes discusiones públicas por "quiteme usted estas mierdas" - y esta foto, que se tomó cerca del ayuntamiento de Oviedo justo antes del cambio de uno de ellos podría ser solo una casualidad, o muy fácil de explicar con lo que os conté de la Temporada de Políticos...


Saludos Malignos!

Españoles por el mundo: Int3Pids en Las Vegas

Aun recuerdo cuando Jeff Moss, en su charla en la Defcon 17, hablaba de un equipo que había hecho historia en el Capture the Flag de la historia de la competición: Los Sexy Pandas. Estuvieron varios años batiendose [Clasificación en Prequals 2009 el cobre en los juegos de la Defcon para intentar ganar un campeonato que se les resistía, a pesar de que siempre estaban encabezando las clasificaciones.



Figura 1: Los SexyPandas en la Defcon 17 preparando el CTF
En el año 2009 se coló también allí un equipo mitad español y mitad coreano, llamado Sapheads para que después de ellos en 2010 los PainSec se colaron para sorpresa de todos en la final de Las Vegas. Otro grupo también nacido desde España que tomó el relevo en la competición, y fueron año pasado por primera vez a pelear en una competicion que visitaban sin haber estado antes, y en la que consiguieron hacer un meritorio campeonato.

Hoy, RoMaNSoft, miembro de los Int3Pids, que vienen de ganar el CTF de la Swiss Cyber Storm 3 y un coche, anunciaba que han conseguido colarse en al final, en uno de las diez cotizadas posiciones de laz prequals que dan acceso a una mesa de combate en el CTF de las Vegas.



Figura 2: Clasificación de las prequals
Los Int3Pids es un equipo que está formado por Dreyer, Uri, Dani "The Doctor" Kachakil, RoMaNSoFt, Whats y Mario Ballano, en el core, pero tendrán que reclutar a más personas si quieren pelear duro en la competición de la Defcon19.

Lo que sí queda claro, es que en España hay buenos jugadores de CTF, y que es ya una lista de muchos años consecutivos sin que falte un equipo que defienda los colores de España en el CTF de la Defcon, en ese camino que abrieron los Sexy Pandas, y que ahora continúan los Int3Pids. Esperemos que se animen a sentarse en la competición y, por qué no, traerse de una vez para España el título de campeones. ¡Ánimo!

Saludos Malignos!

LulzSec: 26.000 cuentas porno exposed

Desde luego el grupo LulzSec quiere mantenerse en los titulares de Internet. Después de andar con la vara detrás Sony, Nintendo, etc... ahora ha querido atacar al mundo del porno... ¿para qué? pues porque les apetece, ya que, como dicen en su twitter... la improvisación rulez!.


Figura 1: Twitter de Lulzsec
Así que, mientras que todo el mundo esperaba que hicieran algún ataque más a Sony - del que ya habían publicado y todo algunos fallos en sus webs... van y sorprenden a todo el mundo publicando 26.000 cuentas de Pr0n.com, un sitio de contenido adulto - ya sabéis, el eufemismo que se usa para el porno -.

Entre las cuentas, militares, webmasters, etc... así que en breve seguro que tenemos algún escándalo sexual de algún congresista o senador americano... oh, wait... OJO a la cuenta de la whitehouse con password Karlmarx, que aquí van a llover ondanadas de hostias...


Figura 2: Cuentas publicadas de dominios del gobierno
El caso es que, además del reuso de contraseñas, proponen que se entre dentro de la cuenta de facebook (si usa la misma password) y se avise a todos los amigos. Para más INRI, han localizado algunas cuentas de militares, una en concreto de un piloto cuya contraseña es "mi esposa".

Lo cierto es que deja claro la poca seguridad del sitio, pero vamos, no me mola que a los pobres usuarios los crucifiquen por ver porno... con lo necesario que es para la humanidad la existencia del porno, joder...

Lo que si es de capullos, es usar cuentas militares y corporativas para registrarse en sitios así. Con lo fácil que es tener una cuenta de esas que se llaman "dama nocturna", "amante bohemio" o similares... en fin, otro pwned de Lulzsec. Pero que tengan cuidado, que a estos se les cae el pelo en cuanto pasen por España, que por aquí, una vez que se ha "terminado" con anonymous, queda tiempo para cazarles... (ay señor...)

Saludos Malignos!

Asegúr@IT 9 online

En el último evento, Asegúr@IT 9, se grabaron las sesiones en vídeo, para montarlas con las presentaciones y que pudieráis ver lo que allí se vio. No vais a tener el 100 % de la experiencia, pero sí esperamos que estas grabaciones os permitan acceder a los contenidos que allí se vieron.

Charla de Alex Rocha sobre PINsafe de la empresa Swivel.

Charla de Enrique Rando sobre Hacking ético con Google, Bing y Shodan.

Charla de Chema Alonso sobre Dust.

Charla de José Parada sobre Infraestructuras de seguridad en la Nube.

Charla de Sergio de los Santos sobre Malware hoy en día.

Saludos Malignos!

FOCA 2.7 Preview Parte 2

Además de las funciones nuevas que ya os conté en el artículo de FOCA 2.7 Preview Parte 1, también trae nuevas estas características.

Búsqueda de puertos de squid Proxy

Hemos añadido el puerto 3128 para la búsqueda de servidores proxy en los equipos de los dominios, ya que es el que habitualmente utiliza el servidor Squid Proxy, así que en las opciones de búsqueda de servidores Proxy ya se puede seleccionar.


Figura 1: Opciones para Squid Proxy
Uso de NetRange para descubir servidores

Ahora, por cada dirección IP que se encuentra, se realiza la pregunta a los registradores de IP, como ya habíamos anunciado, para obtener el tamaño del NetRange.


Figura 2: NetRange de la dirección IP
Por defecto, FOCA añadirá todas las direcciones IP del NetRange si este es menor de 255, y realizará las búsquedas de todos los servicios en esas direcciones, pero si se quiere hacer con un dominio más grande, se puede seleccionar el las opciones hacerlo para todos.


Figura 3: Scanneo solo de rangos de menos de 255 direcciones IP
Soporte para ficheros ICA y RDP

Cómo os puse ayer, Juanito y yo vamos a hablar en la Defcon de Terminal Services y Citrix, y por eso se ha añadido un módulo que aprovecha la información relativa a usuarios y servidores automáticamente en FOCA. Añadiremos una opción más elaborada para hacer el fingerprinting del software que os pondremos con el siguiente artículo de Terminal Services y Citrix.


Figura 4: Análisis de ficheros RDP e ICA
Saludos Malignos!

Tico y Rigodón de aventuras en la Defcón... y ¡olé!

Cuando era poco más que un niño mis padres compraron una enciclopedia que era el orgullo del salón, ese que solo se usaba cuando venían las visitas, almenos durante mis primeros años de vida. Junto con el diccionario enciclopédico venía una colección de libros de Julio Verne, de la que aproveché para leerme algunas historias bastante divertidas que me encauzarían en el camino de la lectura.

En esa época, Julio Verne estuvo muy presente en mi vida, no solo por las novelas, sino porque pude ver películas como 20.000 leguas de viaje submarino o Viaje el Centro de la Tierra, que me dejaron boquiabierto, o porque en la televisión española echaban la serie de La vuelta al mundo en 80 días, con Willy Fog, y un par de personajes que iban descubriendo el mundo con él.

Estos dos personajes eran Tico y Rigodón, un estirado mayordomo el segundo y el primero un ratón con acento andaluz de lo más divertido, que hacía las delicias de todos los niños de mi generación con sus comentarios. ¿Ya os he tocado la fibra sensiblona? ¿Ya te acuerdas de cómo eras tú en aquella época? ¿Y qué tiene que ver toda esta regresión infantil con la Defcon?

El meollo de esta historia, y de Tico y Rigodón, es que, como un flashback me han venido a la mente al imaginar a mi compañero Juanito y a mí en la próxima Defcon 19 dando una charla juntos. ¿Y por qué Tico y Rigodón? La respuesta no es nada más que porque Tico tenía un acento muy peculiar, que con el cachondeo que me traigo yo ahora con Juanito y su curso de inglés acelerado, no podía nada más que imaginármelo como si fuera Tico. Por otro lado, Rigodón no es que hablara tampoco nada bien, ya que tenía un acento francés, así que como yo tengo un acento fortísimo, pues me viene que ni pintada la comparación.

El caso es que, como si fuéramos Tico y Rigodón, vamos a irnos a la Defcon a dar, de momento, una charla sobre Terminal Services & Citrix, que aún no hemos tenido tiempo de publicaros por aquí. Además, impartiremos un Workshop de la FOCA e iremos a ver si el FOCA Team de este año consigue dar un poco más de juego a la Hack Cup, siempre que consigamos completar el equipo, que de momento estamos Juanito, Fermín J. Serna, Pedrito Laguna, el que suscribe, y un tal “Player 5” del que no sabemos cómo la tocará. Así que, si alguien más se viene a Las Vegas, que avise para “sincronizar” planes.

Y para terminar este post, y que podáis confirmar si somos Tico y Rigodón o no, aquí tenéis una secuencia en el Hotel de Las Vegas en la que Tico, al cual me he llevado de hurtadillas a la charla, está enfadado porque no le quiero presentar a Jeff Moss. Yo le estoy explicando que si no le hubiera ocultado nunca nos hubieran aceptado la charla, pero que se lo presentaré en su momento y en ese instante...


Y aquí tenéis una muestra de como se habla el inglés andalú, que es el que yo aprendí.


Saludos Malignos!

Tuenti Security Issues (II de V)

************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************

Issue 6: Registros PTR publicados en los servidores DNS

Dentro de los servidores DNS de Tuenti se puede ver que Primary Master es dns01.tuenti.com, uno de los servidores publicados en Internet, así que era muy probable que tuviera concentrada en él toda la información de los registros PTR. Haciendo uso de FOCA es bastante sencillo descubrir la infraestructura interna de servidores y máquinas que utiliza todo Tuenti con un PTR Scanning.



Figura 5: Infraestructura de servidores en Tuenti
El exponer la lista de cientos de servidores abre mucho más el abanico a un potencial atacante que quiera probar la seguridad, uno a uno, de todos ellos, complicando mucho más la vida de los equipos de seguridad.

Además esta lista de equipos de red se puede complementar con Shodan, ya que tienen indexados bastantes de los equipos de Tuenti en cada rango, y basta con utilizar el comando NET aplicado a los segmentos descubiertos, para tener una visión bastante completa de toda la red.

Issue 7: Servidores sin actualizar

La parte negativa de que se puedan descubrir muchos servidores con los registros PTR es que permite encontrar servidores perdidos, olvidados, o fuera de la política principal de seguridad porque son de pruebas, temporales, o, incluso, que son dispositivos IP. Mirando alguno al azar, era posible descubrir servidores Apache publicados en servidores accesible por Internet, en los que se muestran las versiones de los productos y, algunos, como en este caso, con vulnerabilidades conocidas, como esta de D.O.S. de fácil explotación con el CVE-2010-1452.



Figura 6: Servidor Sanson.tuenti.com con vulnerabilidades conocidas
Es suficiente con revisar el ChangeLog completo de Apache para ver todos los CVE que le afectan a la versión que estaba publicada.

Issue 8: Los metadatos

No podría dejar de mirar los servidores de Tuenti con la FOCA sin poner un ojo en la recomendación del Esquema Nacional de Seguridad sobre los Metadatos, para ver si estaban haciendo uso de alguna política de limpieza de documentos antes de publicarlos.



Figura 7: Metadatos en documentos publicados en Tuenti
Basta con buscar algunos de los documentos en PDF publicados en Internet, y descubrir nombres de usuarios, versiones del software que han comprado para utilizar en la organización, y quién lo usa, etcétera.

Issue 9: La transferencia de datos del perfil sin HTTPs

Una de las cosas que más problemas genera es la no posibilidad ni por defecto, ni configurándolo, de utilizar conexiones HTTP-s entre el usuario y los servidores de tuenti. Esto hace que cualquier cosa que se transmita pueda ser escuchada y capturada en una red insegura. Quiero centrarme en el término de red insegura, porque a veces los responsables de infraestructuras lo utilizan para pasar responsabilidades de la compañía al usuario – no he dicho que sea el caso de Tuenti -.

Una red insegura es aquella que no ofrece garantías a sus usuarios sobre la seguridad de sus comunicaciones porque no hay garantía que un atacante pueda capturar los datos o manipularlos.

Así, bajo esta definición de redes seguras nos quedarían un puñadito nada más, en las que, por ejemplo entrarían las redes TCP/IP que usan IPSec (con certificados digitales o Kerberos, no con PSK), las redes WiFi que no usan WPA/WPA2-Enterprise con EAP, las redes WIFI con WPA/WP2 con una contraseña no crackeable [WPA/WPA2 Craking] - ya que pueden ser atacadas con man in the middle [Atacar WPA/WPA2 PSK] - y las que se hacen con redes PPTP con SSTP, PPTP con passwords no crackeables y con L2TP/IPSec. El resto serían inseguras.

Eso sí, ésta red “segura” lo sería solo hasta el operador, ya que después no hay garantía ni control más allá de la red, y sucedería lo mismo con la conexión del servidor VPN a los servidors de Tuenti. Además tendríamos que quitar de la lista las conexiones VPN con L2TP/IPsec y PPTP en aquellas redes como hoteles, universidades, etcétera, donde los puertos de conexión estén bloqueados. Las 3G y GPRS deberíamos dejarlas también fuera por los problemas con GSM con A5/0 y A5/1, y por supuesto las redes WPA/WPA2-PSK en las que seamos más de 1 usuario, ya que se podrían hacer ataques de Mitm.



Figura 8: Gráfico de conexiones "seguras"
En este ejemplo, asumiento Internet como red Insegura, los datos del usuario pasarán siempre en abierto, una vez salga de la "red segura" del usuario o de la "red segura del servidor VPN" que usa el usuario.

Tras esta reducción de redes seguras nos queda:

a) Aceptar que el sistema no ofrece privacidad alguna, como en los correos SMTP/POP3, y eso debería dejarse claro cuando se solicitan datos de caracter personal o mensajes privados de los usuarios.

b) Asumir que el servidor se ha diseñado solo para unos pocos afortunados que tienen suerte de que ningún ataque a un Router mueva tráfico a China o algún insider de un operador tenga una tarde graciosa y publique en pastebin los datos de las sesiones de tuenti que pasen por su red.

c) Poner HTTPS con certificados de validación extendida y protocolos de cifrado robustos para extender la seguridad de la red hasta el usuario.

Es por eso, que lo más fácil para mejorara la seguridad es montar HTTP-s y que justificarlo con un “no te conectes desde una red insegura” es una falacia. Evidente, la falta de Http-s en la transferencia de datos no solo afecta a la privacidad de la información intercambiada, como fotos, mensajes, chats, comentarios en muros, etcétera, sino a los datos de la sesión del usuario, lo que hace que sea fácil perpetrar ataques a la cuenta del mismo.

El usuario debe por tanto tener extremado cuidado con la red que utiliza para conectarse, si valora su privacidad y qué datos envía. Este problema, lo han tenido la mayoría, si no todas, de las redes sociales, aunque muchas ya han optado y están optando por poner HTTP-s opcional, cuando menos, para los usuarios más preocupados, y Tuenti lo pondrá no tardando mucho, seguro.

************************************************************************************************
- Tuenti Security Issues (I de V)
- Tuenti Security Issues (II de V)
- Tuenti Security Issues (III de V)
- Tuenti Security Issues (IV de V)
- Tuenti Security Issues (V de V)
************************************************************************************************