31 diciembre 2010

[Cine de Hackers] 23 Nada es lo que parece

Vamos a escribir sobre algunas películas y documentales de temática de seguridad o ciberpunk, pese a que muchas de ellos son muy populares, seguro que muchas otras no tanto.

Empezamos por un clásico que casi todo el mundo ha visto y conoce, pero oye, ahora que acaba de finalizar el CCC, no viene mal recordarla o incluso volver a verla.

23 Nada es lo que parece narra la historia de Karl Koch, un hacker alemán conocido como  Hagbard Celine, que en los años 80 vendió información al KGB en plena guerra fría. Sufría adicción por la cocaína y al que se le volaron los patos con el número 23 (tan recurrente en el cine y los paranoicos).

El resumen es así de triste para animaros a volver a ver la película y que posteriormente vengáis a comentarla.
En la historia se puede ver como el protagonista se relaciona con el Chaos Computer Club, el momento en el que decide escribir un troyano (que muchos consideran el primero de la historia) o como su compañero David, que por cierto, realmente representa a dos personas, Hans Huebner alias Pengo y Markus Hess, programa una aplicación de fuerza bruta, llamada "Sesam öffne dich (c) by Goliath", Abrete Sesamo en español.


La película tiene muchas escenas con terminales donde se observan algunas acciones, como por ejemplo el minuto 52 donde se lee el código del troyano:

echo-n "WELCOME TO MILNET-GW.ARMY.MIL UN
IX 4 COMPUTER"
echo-n "Please Login"
echo-n "Login"
echo-n "Enter Password
(stty-echo;/
read password
stty-echo;/
echo"";/
echo$account_name$password>> /tmp/.pub)
echo"Sorry, try again."

save"Trojanisches Pferd"

El ezine Phrack en su número 25 de marzo de 1989, incluyó varias noticias sobre lo ocurrido, donde se puede ampliar lo sucedido con comentarios de Pengo, incluida la respuesta al documento de Clifford Stoll Stalking the wily hacker, que posteriormente daría paso al libro El huevo del cuco, que narra cómo se descubrió a uno de estos hackers y todo el entramado alemán. También tiene algunas traducciones de las múltiples noticias publicadas en la prensa alemana.



FICHA:
Rigor técnico: 4/5
Historia: 4/5
Calificación general: 4/5
Leer más...

30 diciembre 2010

Inocentadas 2.0

Recuerdo con alegría los tiempos de niño, cuando se celebraba el día de los Inocentes, gastando alguna que otra broma que no degeneraba más que en unas risas para la víctima y los que lo rodean.

Las típicas en esa época eran pegar un muñeco de papel en el abrigo, colgar con hilo de pescar un billete (falso) por la ventana, fijar al suelo con loctite una moneda de cierto valor y ver cómo la gente se esfuerza en despegarla, etc,…

Con el tiempo y los adelantos tecnológicos, las inocentadas fueron evolucionando gracias a nuevas herramientas que así lo posibilitaban. Por ejemplo el teléfono. Es típica la escena del bar de Moe en los Simpsons donde suena el teléfono y una voz desconocida pregunta por alguien con nombre creativo. Sin embargo, cuando los teléfonos empezaron a detectar el Caller ID, se fastidió el poder hacer este tipo de  inocentes bromas "en claro" utilizando un teléfono propio.

Con los móviles y su "posibilidad" de llamar con número oculto, se abrió otro universo de creatividad. En algunos casos, el que ve "número oculto" en la pantalla o sospecha o, muchos conocidos míos, ni siquiera lo cogen.

Sin embargo, sigue habiendo otro tipo de bromas que se pueden llevar a cabo gracias a la "modernidad de nuestros días". De hecho en diversos blogs, e incluso nosotros mismos, al igual que hicimos otros años, publicamos también un post acorde al día 28 de Diciembre.

Sin embargo, hay otras ideas que pueden dar lugar a unas risas, pero que  también pueden tener consecuencias desagradables. No obstante, queremos compartirlas aquí.

Disclaimer: Desde SbD NO nos hacemos responsables del uso inocente/malicioso que se pueda hacer de lo expuesto más adelante, así como de las consecuencias que puedan derivarse, tanto con las víctimas como con los participantes.

Por ejemplo:
  • Servicios tipo BromaSMS.com, en el que envías un SMS a un número, modificando el número origen por el que tú quieras. De esta manera, el que lo recibe, si tiene en su agenda el número origen que hemos solicitado "spoofear" parecerá que es ese contacto quien se lo envía. Podéis imaginar que los cacaos que se montan pueden ser descomunales. Otra modalidad de este tipo de ataque/broma, es si tenéis acceso físico al dispositivo de la "víctima". Así, simplemente con cambiar en el móvil el nombre de nuestro contacto/móvil, por el que queremos suplantar, podemos tener el control completo de la comunicación, enviando y recibiendo SMS con la "víctima", que creerá que está dirigiéndose a otra persona.  Sí, sé que no tiene nada de tecnológico pero, el engaño es la técnica de ataque más eficiente. Hace muuuuchos años tuve oportunidad de asistir a una broma de estas características en un entorno muy controlado y fue bastante divertido (en realidad ni siquiera era 28 de diciembre).
  • Correo suplantando el origen: Una idea que se me ocurrió hacer para este día de los inocentes, pero que finalmente no llegué a ejecutar, era el envío de un correo electrónico a un compañero de trabajo "víctima", utilizando como origen el de alguien importante de la empresa. Se puede hacer de varias maneras, pero la más creible es contando con una cuenta de correo en el mismo servidor desde el que pretendemos enviar los correos manipulados. Para poder hacer pruebas, lo más sencillo crear un script en Perl

#!/usr/bin/perl
use Mail::Sender;

my $sender = new Mail::Sender{smtp => 'X.X.X.X', 
from => 'Responsable RRHH <rrhh@empresapoc.com>', 
replyto => 'inocenteinocente@empresapoc.com'};

$sender->MailMsg({to=> 'Compañero Víctima <victima@empresapoc.com>', 
to => 'A mi mismo <atacante@empresapoc.com>', subject =>"Reunión urgente", 
msg => "Estimados empleados,\n\n
Por la presente os convoco a una reunión para el día 5 de Enero en 
nuestras oficinas centrales donde discutiremos 
vuestras condiciones laborales para el año 2011\n\n
Sin otro particular, se despide atentamente\n\n
Perico Pérez - Responsable de Recursos Humanos EmpresaPoC\n
rrhh\@empresapoc.com\n
+33 12 34 56 789\n\nEnviado desde mi iPhone"});



A tener en cuenta:
  • El subject, cuerpo y firma del correo ha de ser lo más parecido en el lenguaje que usa la persona a la que se suplanta.
  • Se puede "hablar" directamente al servidor de correo con los comandos SMTP adecuados pero, para tener flexibilidad y poder probar cómoda y rápidamente, Perl nos aporta lo necesario.
  • Si hiciera falta utilizar autenticación en el servidor, el módulo Mail::Sender nos proporciona mecanismos para llevarlo a cabo sin problemas, eso sí, con nuestro usuario/contraseña.
  • Hemos añadido una cabecera replyto: inocenteinocente@empresapoc.com para evitar que nuestra víctima conteste al suplantado y se organice un problema serio para alguien. Precaución con la suplantación de identidades por correo que en algunos países está considerado como delito, aparte de que en la empresa no darás una buena imagen, aun siendo 28 de Diciembre.
  • Si no tenemos acceso al servidor del origen que queremos "spoofear", podemos utilizar un servidor de correo cualquiera, con el requisito que no compruebe los dominios permitidos como originadores de correos. Si el servidor correo destino dispone de un mínimo mecanismo de filtrado antispam, comprobará que el correo viene de una dirección IP que no corresponde a un registro MX asociado al dominio indicado en el correo y lo rechazará o lo considerará SPAM.
¿Cómo detectar que el correo no es real?
  • Lo más normal es sospechar de algo con tan mala baba un 28 de Diciembre. Estar ojo avizor un día así y desconfiar más de la cuenta puede ayudar en un día así.
  • Análisis de las cabeceras del correo. En general, los clientes de correo, muestran por defecto los campos más comunes e interesantes de un correo: Origen, destino, subject, Fecha y hora de envío, etc,... De ahí que a simple vista, nuestro correo trampa/broma puede ser perfectamente creíble a primera vista. Sin embargo, todos los clientes de correo (al menos, no webmails) permiten ver todas las cabeceras que manda el servidor de correo al cliente. En este caso, comparando cabeceras con uno que tengamos confianza que es verdadero, podríamos ver diferencias que nos permitan tratarlo como corresponde en un día así. 
¿Y tú, te animas a contarnos qué inocentadas 2.0 hiciste el pasado 28 de Diciembre?
      Leer más...

      29 diciembre 2010

      Microsoft Security Essentials, impresiona

      Desde hace algún tiempo se lleva escuchando el run-run del nuevo antivirus de Microsoft, lo cierto es que la mayoría de cosas que he leído sobre el tema son acerca de si es moralmente reprobable que Microsoft sea a la vez, plataforma y solución o últimamente, sobre si es correcto que saque 'el rodillo' regalando y 'ofreciendo' el producto.

      Dejando a un lado todo eso, le he dado una oportunidad para ver in situ de lo que es capaz y evaluarlo pura y llanamente como lo que es: Un antivirus.

      De entrada, instalarlo es sumamente fácil, no tiene 'opciones Ninja' ocultas que puedan generar desconcierto.


      Una vez instalado, el rendimiento es bastante bueno, a mi particularmente me resulta imprescindible que un Antivirus no sea un 'traga-recursos' ya que uno de los hábitats mas frecuentes suele ser Vmware. Doy FE que MSE funciona con bastante soltura y sin crear cuellos de botella.

      La interface de administración sigue el concepto de la instalación: 'Nada de cosas complejas' y resulta bastante intuitiva para cualquier perfil de usuario


      Una de las opciones que mas me ha gustado es la posibilidad de programar las revisiones globales del sistema indicando cuanta CPU se le va a asignar.


      La gente de Microsoft ha cuidado los detalles estéticos pero ... ¿Que hay de la efectividad? no olvidemos que las diferencias se marcan 'parando' ataques. Voy a tomar como ejemplo el último 0day para Internet Explorer del que no existe parche todavía. Permite ejecutar código en el sistema con tan solo visitar una web. La anterior solución AV que tenía instalada lo veía pasar sin decir nada. ¿Que hará MSE?


      Detecta perfectamente el ataque vía metasploit y lo detiene


      Bravo por MSE ! Este tipo de cosas son las que espero de un Antivirus, proactividad y defensa real. Sin duda MSE es una magnífica solución y además gratuita. +1 para Microsoft
      Leer más...

      28 diciembre 2010

      0day XSS persistente en Blogger.com y Meneame.net

      ACTUALIZACIÓN


      Efectivamente, se trataba de una broma. Las evidencias se han realizado mediante la extensión de Firefox Web Developer, su funcionalidad de "Editar HTML", que permite editar el código fuente de la página con el fin de mostrar como quedaría en caso de modificarla realmente en los ficheros de la web. En ningún momento se edita el contenido, sólo lo que se muestra en el navegador local. 

      Tampoco es necesario crearse una copia local de la página ni nada por el estilo.

      Sobre los alerts Javascript mostrados, puedes hacerlo si, en cualquier página, escribes el siguiente código en la barra de direcciones de Google Chrome o Mozilla Firefox:

      javascript:alert("TEST SBD")
      --------------------------------------------------------------------------------

      En caso de que este post se llegase a publicar, quiero dar las gracias a SecurityByDefault.com por dejarme un "hueco" <:-D

      Os explico, hace unas semanas se hacía público, por parte de Google, un programa para ofrecer recompensas a cambio de vulnerabilidades web en alguno de sus dominios importantes. Por ello, me puse al lío y de purísima casualidad, me topé con lo que comienzo a relatar a continuación.

      En primer lugar, y aunque ya lo sabréis, paso a definir que es un XSS de tipo persistente o permanente. Todos sabemos que un Cross-Site Scripting es una de las vulnerabilidades web más famosas y extendidas, si bien en múltiples ocasiones resulta muy dificil aprovechar su explotación, puede dejar en evidencia a según qué tipos de webs (sobretodo si son de presidencias europeas y esas cosas jaja). Aún así, muchos consideran que no son muy importantes, ya que es necesario que un usuario haga click en un enlace que le pase otro usuario maloso que quiera, por ejemplo, robarle su sesión o redirigirle a un phishing. Pero...¿y si conseguimos que el código que incrustamos  se muestre siempre, y para todos? Nos haríamos con un buen conjunto de sesiones, y encima, ¡sin tener que hacer picar a nadie!

      Pues de eso os escribo, al hilo del programa de Google, me encontré un XSS de este tipo permanente en el sistema de comentarios de Blogger! No quería ir a por vosotros :-P, así que aproveché e hice las pruebas sobre un blog conocido por muchos (es más, gracias a dicho blog conozco a SbD :-) ). Se trata del blog del maligno, Chema Alonso (www.elladodelmal.com), que está hospedado en blogger (y eso que es de Microsoft o algo así!).

      Os paso una captura y un script para reproducirlo en cualquier blog que esté en blogspot.com!

      AVISO DE SecurityByDefault: la captura enviada por el usuario era de mala calidad, por lo que reproducimos lo realizado por el contribuidor en un post de que publicó nuestro compañero Chema el día 27 de Diciembre (ayer). El código utilizado por dicho usuario se ha omitido, y se ha escrito directamente al equipo de seguridad de Google.


      Ejemplo de alert en Javascript incrustado en uno de los comentarios, mostrando una cadena de texto.

      Captura del comentario que incluye el código Javascript, saltándose la protección HTML de Blogger mediante una secuencia de carácteres determinada.
      ¡Todavía no me lo creo la verdad! Perdonad la calidad, pero bueno, yo os mando el código para que veais que es verdad, probadlo en cualquier blogger.

      Bueno, espero que os haya gustado y sería un enorme placer aparecer en vuestro blog con este humilde post. Antes de nada, y ya que estoy con el tema, os mando otro de estos Cross-Site permanentes en el botón de meneos de Meneame. Sólo he conseguido reproducirlo si voto anónimamente cualquiera de las noticias en portada, fijaros en la noticia con los 499 meneos!:


      Artículo por Anón1mo



      Leer más...

      27 diciembre 2010

      Comienza el 27th Chaos Communication Congress

      Uno de los congresos internacionales más importantes del año, con más historia y con una reputación increible. Todas las navidades desde hace un buen puñado de años, se celebra el Chaos Communication Congress (también conocido como C3). Este año se realizará del 27 al 30 de Diciembre en Berlín, y cuenta con diferentes tramos de conferencias de distintas temáticas: Sociedad, Hacking, Ciencia, Comunidad, Cultura y Creación. Además, tenemos la gran suerte de contar con un despliegue de medios de lujo, que nos permitirán disfrutar del evento sin movernos de casa.

      Aunque durante el día de hoy, la página oficial del congreso ha estado varias veces caída, si que contamos con un conjunto de enlaces de streaming del evento, para cada uno de sus 3 salones (Saal), tanto el video del estrado donde se realizan las ponencias como de las propias presentaciones o slides. 

      Recopilación de enlaces multimedia del 27c3

      Otro enlace en el que se podrán ver los streamings del 27c3 es http://27c3.iphoneblog.de/index.html (página adaptada para iphone, pero accesible desde cualquier dispositivo).

      Como anunciamos por twitter hace unos minutos, este año entre sus ponentes destacamos a Hector Martín, que junto con otras dos personas ofrecerán la charla "Console Hacking 2010" el día 29. Hector Martín fue el primero en hackear el sensor de movimiento del Kinect, como parte del programa de Adafruit que ofrecía 3.000 dólares por esta hazaña.

      Ficha de la ponencia Console Hacking 2010
      Podréis seguir el evento por twitter mediante el hashtag #27c3, o estando atentos a las actualizaciones de las cuentas @27c3 y @c3streaming

      Leer más...

      26 diciembre 2010

      Enlaces de la SECmana - 51


      Leer más...

      24 diciembre 2010

      Primeros ponentes confirmados para Rooted CON 2011

      A punto de finalizar el año, y entre todas las tareas previas a poner el broche a este año 2010 tan movidito, ya podemos ir preparando la agenda para el próximo año, en el que aunque haya previsión de que estaremos peor que en el que nos encontramos, por lo menos podemos ir marcando en nuestras agendas citas que no nos deberíamos perder y que nos harán salir de nuestra monotonía diaria.

      Esta semana se anunciaron los primeros ponentes para Rooted CON 2011, incluso antes de que finalice el Call-For-Papers, vigente hasta el 31 de Diciembre de 2010, y el cual deberíais aprovechar para presentar vuestros trabajos, artículos, técnicas y herramientas. Esas cosas que hacéis a las tantas de la madrugada, conectados a la red del vecino (que os ha autorizado previamente), doce proxys, TOR y 30 VPNs encadenadas. Si tuvisteis ocasión de asistir a la pasada edición, o por lo menos echar un vistazo al material, os daréis cuenta de que hay hueco para cualquier temática, cualquier tipo de ponencia, técnica o no tan técnica, pero lo importante es que gire en torno a este mundillo como es el de la seguridad informática que tanto nos apasiona, y que cada día debería ser más tenido en cuenta. Aprovechad, animaos y podréis formar parte de un gran conjunto de ponentes que estamos seguros que serán protagonistas de la próxima Rooted CON.

      De momento, ya tenemos los primeros nombres seleccionados, elegidos por encontrarse entre los mejor valorados de Rooted CON 2010 por parte de los asistentes: Joxean Koret (con una charla titulada Database Security Paradise), Pedro Sánchez y Eduardo Abril (charla titulada Hospital Central - tus datos son mis datos) y Chema Alonso (de su charla aún no tenemos título).


      Joxean KoretPedro SánchezEduardo AbrilChema Alonso

      Ponentes y personas de lujo, y estamos seguros que el resto de charlas seleccionadas tras el proceso de selección también serán de traca. Recordad que todavía puedes registrarte para asistir a este congreso, en este enlace tenéis más información sobre el proceso a seguir. ¡Se acaban las plazas!

      [+] Página web de Rooted CON
      [+] Registro Rooted CON 2011
      [+] Envío de propuestas de ponencias para Rooted CON 2011
      Leer más...

      23 diciembre 2010

      Así pasó en 2010… y así te lo contamos!

      Estamos acostumbrados a ver en TV generalmente, resúmenes del año, noticias que nos recuerdan sucesos que pasaron hace meses y que, en unas ocasiones nos parecen lejanas y en otras, parece que haya sido ayer. 

      Depende de cada uno recordar el año de una forma u otra, con mayor o menor alegría: Los españoles recordaremos con alegría 2010 por haber sido el año en que "La Roja" se proclamara Campeona en el Mundial de Fútbol de Sudáfrica. Los chilenos posiblemente lo recuerden como el año en el que sufrieron uno de los terremotos más devastadores de su historia. En SbD nos quedará grabado como el año en que ganamos el premio al mejor blog de seguridad en los Premios Bitácoras 2010.

      Desde el punto de vista de seguridad informática, no podemos decir que 2010 haya sido un año vacío de emociones. Sin duda, a lo largo del año, el trending topic sobre liberación de datos "altamente sensibles", que ha generado una gran revolución, tanto mediática como política, ha sido el fenómeno Wikileaks

      Hoy, hacemos un stop y revisamos, mes a mes, a lo largo de los posts de SbD los hechos más relevantes para nosotros de este año que en breve se despide.
      • Marzo:  Detención de varios responsable de una enorme botnet formada por 13 Millones de PCs comprometidos en la operación Mariposa
      • Agosto: La seguridad de los últimos sistemas operativos de Microsoft cada vez es mejor y mejor. Sin embargo, este mes se publicó una grave vulnerabilidad que afecta a todos los Windows permitiendo escalar privilegios y ejecutar código a nivel de kernel
      • Octubre: Me vais a perdonar pero no puedo dejar de recordar tres noticias importantes:
        1.  El ataque DDoS de 4chan Anonymous a la SGAE y cómo evitó ACENS (la empresa de hosting) que se denegara el servicio del resto de sus clientes
        2. Si no quieres recibir publicidad, apúntate a la lista Robinson. Eso sí, puede que tus datos si estás en La lista Robinson queden al descubierto
        3. Premios Bitácoras 2010: SbD ganador en la categoría de blogs de seguridad!!! ¿Lo había dicho ya ;D ?
      • Diciembre: Difícil va a ser de superar en lo que queda de mes, que la grandísima sorpresa que fue la puerta trasera descubierta, en el código fuente de la implementación IPSEC, del sistema operativo OpenBSD (Secure By Default).En SbD además publicamos una recopilación de las puertas traseras más escandalosas tanto en software de código abierto como cerrado.
      Leer más...

      22 diciembre 2010

      Internet, tal y como lo conocemos, está pasando por un momento que, según opinan muchos, marcará un antes y un después en la red. Por ello, debemos prepararnos generando y desarrollando nuevas ideas.

      La idea que vamos a ver llegó a mi en una conversación con Román, algún comentario suyo, o incluso puede que una mezcla de ambas. Me pareció tan potente que quería, al menos, demostrar que era posible llevarla a cabo.

      Pensemos en Internet como en un flujo continuo y gigantesco de todo tipo de datos. Estos datos pueden estar clasificados según contenido, protocolo, etc. Para un censor que implante un mecanismo de censura habrá datos permitidos y datos que están prohibidos. Pero, ¿que pasa si metemos datos prohibidos de forma oculta en datos permitidos para que pasen por el filtro sin problema? Hace poco veíamos algunas herramientas de esteganografía que hacían algo parecido, incrustaban datos dentro de otros sin modificar a simple vista el contenedor.

      Si combinamos ésto con la creciente cantidad de servicios de compartición de contenidos multimedia, tenemos la ecuación completa.

      La herramienta SYND(E) [Share your nasty docs (eyeless)], made in SbD, nos permite hacer ésto de forma automática. Está pensada para enviar un fichero de un punto a otro (u otros) incrustándolo en fotografías y subiéndolo a un depósito público como es Imageshack. El receptor solo tendrá que descargar las fotos y extraer el contenido. El funcionamiento es el siguiente:

      1. El usuario A selecciona una lista de fotografías (en formato JPEG), una clave de cifrado y el fichero a enviar.
      2. El programa hace las verificaciones pertinentes, fragmenta el fichero en pedazos ajustados a lo almacenable en cada foto, los cifra con la clave de cifrado y el algoritmo AES de 128 bits, los incrusta en las fotografías y las sube a Imageshack.
      3. Después de ésto genera un fichero de configuración con la contraseña cifrada (con doble SHA512) y la lista de fotos. Este fichero deberá ser enviado al receptor (preferiblemente por un canal seguro).
      4. El usuario (usuarios) B usa el programa con el fichero de configuración generado, inserta la clave de cifrado (debe de ser comunicada por un canal seguro) y si coincide procede a descargar las fotos, extraer los datos, descifrarlos y recomponerlos en el fichero a recibir.

      Ya que dicho así puede sonar un tanto abrumador, vamos a ver una demo de cómo funciona.

      El programa tiene el objetivo de demostrar que la idea es posible, por lo que algunos errores no están controlados y depende de programa externos. Está pensado para entornos tipo Unix, es software libre, programado en Ruby, utiliza curl para la interacción con la API de Imageshack, wget para descargar y steghide para trabajar con las fotos.

      Necesitamos estas dependencias, en Debian o sus derivados (como Ubuntu) se instalarían con el siguiente comando (con permisos de root):

      apt-get install ruby curl wget steghide

      En las primeras líneas de código del programa (editable con un editor de texto sin formato) encontrareis algunas opciones de configuración. La más interesante es poder configurarle un proxy HTTP para la subida, con lo que podemos mejorar la privacidad.

      Teniendo todo preparado, vemos las opciones del programa.


      El programa se maneja mediante ficheros de configuración. El de descarga lo genera él, por lo que solo tendremos que preocuparnos por el de subida. El formato es el siguiente:

      clave_de_cifrado
      /ruta/del/fichero/secreto.zip

      /home/yo/foto01.jpg
      /home/yo/foto02.jpg
      ...

      Para el ejemplo he elegido como fichero secreto La Declaración Universal de los Derechos Humanos en formato PDF. El fichero de configuración queda así:

      clave_cifrado_sbd
      derechos.pdf

      demo/watchmen.jpg
      demo/world.jpg
      demo/sc1.jpg
      demo/sc2.jpg

      Para verificar que todo está bien y que las fotos tienen la capacidad suficiente para albergar el PDF vamos a utilizar la opción -s.



      Perfecto, ahora con la opción -u pondremos a funcionar el programa, los datos quedarán almacenados  en Internet (el contenido y las fotos subidas a Imageshack) y generaremos el fichero de configuración de salida.



      La estructura del fichero de configuración de salida es la siguiente (clave de cifrado cifrada en un doble SHA512 y lista de links a las fotos).

      77d708398595708f184a7f99009938aef4915a218862e05d025dc84264b61d9e91638958241ca570c540d3e9e660f3df61dff848e889c75a86ca84edaef19198
      http://img832.imageshack.us/img832/7497/watchmenk.jpg
      http://img37.imageshack.us/img37/7074/worldrw.jpg
      http://img832.imageshack.us/img832/6682/sc1o.jpg
      http://img716.imageshack.us/img716/9112/sc2rg.jpg

      Como curiosidad podéis visitar la dirección de cualquiera de las fotos y veréis que es visible, como una foto cualquiera. Para recuperar el fichero, con la opción -d solo tendremos que pasarle el fichero de configuración, la clave de cifrado y el fichero donde guardar la descarga (si queréis probar a descargarlo vosotros aquí tenéis la configuración de salida, la clave de cifrado ya sabéis que es "clave_cifrado_sbd").



      Como podemos ver el fichero ha llegado intacto y el SHA1 es el mismo, por lo que no ha cambiado nada.



      Preguntas que pueden surgir:

      - ¿Que ventajas tiene esto?

      Nuestro fichero secreto va a ser troceado, cifrado (AES de 128 bits), incrustado de forma oculta en fotografías y éstas van a ser subidas a un almacén público gigantesco. Las posibilidades de recuperar el fichero íntegro son muy remotas ya que está fragmentado (y un atacante no debería saber el orden ni la localización de los fragmentos), cifrado y entre muchísimas mas fotos.

      Además, el canal está permitido por un posible censor, por lo que podríamos compartir cualquier tipo de datos por esa vía, por muy fuerte que fuera la censura.

      - Alguna desventaja tendrá, ¿no?

      Si, por ejemplo que aumenta mucho el tráfico generado. Tenemos que enviar los datos y las fotos. Además, dependemos de un tercero, y al haber muchos fragmentos la disponibilidad puede caer en cuanto uno de ellos deje de estar disponible. Esto último se solucionaría copiando los datos en varios servicios diferentes para crear redundancia.

      - Pero, ¿y si bloquean Imageshack?

      No hay problema, ésta misma implementación de puede portar a cualquier servicio que no modifique los datos cuando se suben. Para imágenes tenemos muchos más servicios del estilo de Imageshack, Flickr, etc. Y no solo eso, también podemos usar como contenedor vídeo, texto (comentarios en foros, blogs, pastebin, etc), audio, etc ...

      - No me gusta, la herramienta me resulta muy arcaica.

      La herramienta pretende demostrar que la técnica es posible, usable y enseñar como funciona. Cualquiera es libre de hacer una herramienta de botón gordo, integrarlo con algún programa de compartición de ficheros, etc ...

      Descargar SYND(E) desde nuestro repositorio de software: Descargar
      Leer más...

      21 diciembre 2010

      Cuando "read" implica "write"

      En este artículo voy a hablar de una experiencia que he tenido hace poco con una de las redes de mi universidad, a la que tuve acceso y al ver ciertos temas que no me convencieron me dispuse a ver cómo de fácil podría llegar a ser hacerse con el control de la misma. Lo más interesante es hacerlo sin necesidad de tener ya una cuenta del sistema (que era mi caso), a pesar de que ya se ha dicho innumerables veces que un porcentaje más que considerable de los ataques a una red provienen del interior y que por tanto, cada usuario ha de tener sólo los privilegios que le corresponden, ninguno más.

      Normalmente suelo dar todos los datos, pero en este caso no diré exactamente qué red se veía afectada pues aún no se han tomado todas las medidas que deberían y sigue estando expuesta. Aun así, por describir la red un poco, decir que es un servicio para los estudiantes, en la cual hay registrados muchos datos confidenciales (como nombres y DNIs, becas otorgadas), un servicio de impresión prepago, etc. Todos sus servicios se llegaron a ver comprometidos, sin excepciones.

      ¡Comencemos!

      Disclaimer:

      No me hago responsable del mal uso que pueda darse a esta información.
      En ningún momento la intención del artículo es el incitar a que se produzcan ataques sobre dicha red siga estando, o no, vulnerable al ataque que se expone a continuación.

      1. Introducción

      La finalidad del ataque es conseguir la contraseña del usuario root para poder acceder a todos los host (lo normal es que se comparta) y por tanto comprometer todos los servicios de la red.

      Como he dicho anteriormente, el ataque se va a realizar sin una cuenta de acceso, por lo que habrá que comprometer de algún modo uno de los servidores con acceso desde el exterior para poder empezar.

      Cabe decir que, como se irá viendo a lo largo del artículo, se irán consiguiendo progresos debido a una mala administración, es decir, que nos aprovecharemos de las malas asignaciones de permisos y de sistemas de backup mal configurados.

      El proceso que más tiempo nos llevará será el data mining, es decir, explorar concienzudamente una serie de directorios en busca de la información que nos interesa, en nuestro caso cualquier tipo de credencial que nos permita avanzar y/o obtener datos interesantes.

      Por lo tanto, ya queda explicado el título del artículo ‘cuando read implica write’ que quiere dejar patente que si no nos preocupamos seriamente de los permisos y pensamos que la lectura (read) no constituye un problema si la información no es “crítica”, podemos encontrarnos con un serio peligro
      pues dejamos abierta cierta información para que alguien la encuentre, explote y obtenga los privilegios suficientes para hacerse con el control (implica write).

      2. Obteniendo los usuarios de la red

      En nuestro caso obtendremos la lista de usuarios de la red a través de un LDAP mal configurado que tiene permitido el acceso (en modo lectura) al usuario anónimo. También hubiéramos podido conseguir los usuarios de otro modo (tienen un listado de los usuarios como contacto en los que se publica su nick, o a través de la cuenta de correo, también pública, etc). Aun así, es más cómodo el LDAP porque podremos ver que hay cuentas de prueba que seguramente sean más fáciles de comprometer.

      ¿Cómo accedemos a LDAP?
      Si escaneamos los host públicos veremos que ninguno tiene LDAP de cara al exterior pero siempre podremos comprobar si tienen un manager para administrarlo.
      Probando con los dos más conocidos (LAM y PHPLDAPADMIN) nos topamos con que tienen accesible sin ninguna restricción el phpldapadmin. Por lo tanto, nos conectamos como usuario anónimo y accedemos cómodamente al listado (y más información, como hosts, etc).


      Una vez dentro, al menos nos percatamos que el usuario anónimo tendrá el access en auth puesto que no podemos ver las contraseñas de los usuarios. Simplemente nos interesará exportar los nombres/nicks de los usuarios para poder ejecutar el ataque, destacando las cuentas de prueba. Además, podemos comprobar que hay otros dos cn, además del admin, que tienen pinta de tener más privilegios.

      Aprovecho para enlazar al último artículo que publiqué sobre servidores VPN PPH en el que adjunté algunos consejos para securizar LDAP. Podéis acceder al PDF aquí o al post aquí.

      3. Obteniendo acceso a la red

      Una vez que tenemos el listado de acceso a la red podríamos realizar el ataque sobre el servicio SSH, pero es muy probable que tengan instalado denyhost/fail2ban o algún otro que nos bloquee en cuanto hagamos un número determinado de intentos. Por lo tanto sería interesante encontrar alguna forma más transparente de ataque.

      Siempre he dicho que las autenticaciones de un servicio web son la mejor forma de atacar pues rara vez registran los intentos fallidos, como mucho queda constancia en los logs de conexiones. En nuestro caso tenemos varios frentes, uno podría ser el correo pero si investigamos un poco más veremos que hay más servicios que requieren autenticarse, por lo que atacaremos a estos otros.


      Como comprenderéis, todo depende de la fortaleza de las contraseñas de los usuarios. En este caso concreto, siendo estudiantes y con escasos conocimientos de seguridad o buenas prácticas, sabía que las contraseñas iban a ser fáciles de comprometer (del estilo fechas de nacimiento, DNIs, palabras fáciles de recordar) y por tanto que estén en wordlists, etc. Además, recordar que teníamos cuentas de prueba.

      Para el ataque, programé un pequeño script que iba autenticándose y procesando la respuesta. En el momento en el que el hash de la respuesta cambiara se daría por correcto el par usuario/contraseña. El script era capaz de realizar algo más de 35 peticiones por segundo (con 10 threads activos) por lo que era capaz de procesar 126k contraseñas por hora y usuario. Aprovechando el cloud computing, utilicé
      25 instancias durante 2 horas cada una para cubrir el mayor número de usuarios, dando a cada uno más de una instancia. Por lo tanto por 50 céntimos logré comprometer relativamente rápido una cuenta, aunque las instancias no se lanzaron todas a la vez para evitar que saltara alguna alarma (no en el servicio atacado sino en algún mecanismo de protección de la universidad).

      Por lo tanto, como podéis ver, fue relativamente sencillo hacerse con los credenciales de una cuenta del sistema y no levantamos muchas sospechas al utilizar un servicio web. Ya utilicé algo parecido para las cuentas de usuario de la UPM (el artículo lo podéis encontrar aquí) y también pasó inadvertido (no se dieron cuenta hasta que se les reportó).

      4. Data mining

      Una vez que nos encontramos en la red (en el host al que podemos conectarnos por SSH) procedemos a buscar cualquier información que nos sea de utilidad para poder ir escalando privilegios.

      En este caso, una vez que estamos dentro podríamos ver si podemos utilizar algún exploit para la escalada de privilegios. En este caso podíamos haber utilizado este, pero supondremos que todos los servicios que corren en él están parcheados y por tanto es necesario el data mining (pues fue el procedimiento que utilicé).

      En primer lugar, lo que hice fue comprobar si podía acceder a las carpetas home de los demás usuarios (muchas veces se permite la lectura por cualquiera). Hice la prueba y funcionó por lo que uno de los toDo’s serán las homes. Además, siempre es interesante buscar en la carpeta etc (en concreto en las configuraciones de los servicios/aplicaciones a ver si alguna tiene mal asignados los permisos y podemos ver credenciales en texto plano) y en la carpeta /var/www por si desde ese servidor se está sirviendo la página web y, por tanto, ver también los archivos de configuración o de conexión a bases de datos.

      Mirando en la carpeta /var/ no encontré ninguna información interesante aunque cual fue mi sorpresa al encontrarme una carpeta con nombre backup en la que se encontraban copias periódicas (cada 10 días) del servidor web y de todas las bases de datos. Claramente los permisos estaban mal asignados y podía leer la mayoría de la información.


      Tras unas horas haciendo el barrido de todos los directorios (esta vez manualmente), me hice con credenciales de LDAP (era de solo lectura aunque ya podía ver los hashes de las contraseñas de todas las cuentas) y de muchas bases de datos.

      En realidad los credenciales de las bases de datos no me hacían falta (salvo que quisiera alterarlas) pues en la carpeta de backup teníamos exportadas todas en formato SQL y con acceso de lectura.

      5. Comprometiendo una cuenta con privilegios

      A través del data mining realizado a las carpetas home y a los usuarios que aparecían en los archivos de los servicios web, etc pude hacerme una idea de quienes eran los que podrían estar incluidos en el sudoers y por lo tanto el que sus contraseñas fueran el principal objetivo.

      ¿Cómo podría obtener sus contraseñas?
      Una de las bases de datos era la de la página web, por lo que la aproveché para cruzar los que tenían en ella más privilegios con los usuarios que yo creía administradores, y sacar los hashes de sus contraseñas.

      En principio iba a utilizar las GPU de Amazon para crackear los hashes pero como vi que iba a tardar demasiado me hice un script, por quemar todas las posibilidades sencillas antes, que me comprobaba en Google los hashes a ver si ya alguien los había crackeado. En la mayoría de los casos no hubo resultados y en otros la contraseña de la web no era la misma que la de la cuenta de la red, por lo que lo dejé ahí y empecé a montar lo de Amazon. Me acordé que había una página que te comprobaba los hashes en muchas bases de datos y además estaba enlazada con opencrack, así que decidí crear un script que comprobara en ella todos los hashes y cuál fue mi sorpresa cuando fue capaz de comprometerme más de los que pensaba y
      algunos de 10 caracteres alphanuméricos con especiales, increíble. Por cierto la página es
      HashKiller, ha estado caída una semana pero es altamente recomendable.


      En el caso de que no hubiéramos tenido la suerte de obtener los hashes de la base de datos, recordar que había conseguido un usuario de LDAP con lectura del campo contraseña, por lo que de ahí podía obtener los hashes, más incómodos pero igualmente válidos.

      6. Obteniendo la contraseña de root

      Una vez que hemos conseguido comprometer una cuenta incluida en el sudoers podemos terminar el data mining leyendo aquellos archivos que tenían los privilegios bien asignados además de ver el historial por si había utilizado alguna contraseña en claro o la carpeta de .mozilla (entre otras muchas posibilidades) para acceder a sus contraseñas guardadas.

      A partir de este momento ya me había hecho con los credenciales de todas las bases de datos y podía acceder a la gran mayoría de la información. El problema era que necesitaba la contraseña de root para acceder a otros host donde se encontraban servicios más interesantes como las impresiones, los datos personales, etc.

      Como podéis ver en ningún momento utilicé ningún exploit ni nada, simplemente data mining y cracking de hashes (que por suerte fue muy cómodo).

      ¿Cómo podemos obtener la contraseña de root?
      Lo primero que hice fue acceder a los archivos shadow/passwd y utilizar el John para crackearlos. Al ver que tardaba demasiado me decidí por echar un vistazo a todas las contraseñas que había obtenido y me percaté que una de las que tenía era del cn=admin de openLDAP. Normalmente suelen compartirse así que la probé haciendo un simple "su" y funcionó, ya tenía la contraseña de root.
      Para comprobar que tenía acceso a los demás host fui conectando a cada uno de ellos sin fallo alguno. Además en cada uno hice un pequeño data mining para determinar cuántos credenciales se podían ver comprometidos.


      ¡Hasta aquí todo! Ya para terminar...

      Como podéis ver, ha sido extremadamente sencillo acceder a la red y en poco tiempo obtener el control total de la misma.

      Independientemente de la facilidad que haya tenido por los descuidos de los administradores quería que con este artículo quedara claro lo importante que es el control de los permisos y que un par de descuidos (en este caso todo ha sido, principalmente, por la carpeta backup) hacen que sea extremadamente sencillo comprometer toda la infraestructura.

      Como dije al principio del tema, ya ha sido reportado pero al no disponer de ningún tipo de mecanismos de seguridad (ni un simple "generador de alertas de logs" como explicó hace poco tiempo Lorenzo aquí), no quiero pensar que exista la posibilidad de que yo no haya sido el primero y que alguien haya podido acceder de una forma tan sencilla a nuestros datos.

      Artículo cortesía de: Luis Delgado J.
      Leer más...

      20 diciembre 2010

      Hardening de Mod_SSL

      Después de haber explicado como optimizar mod_ssl para conseguir mucho desempeño -a costa de sacrificar la seguridad- ahora vamos justo con lo contrario. El objetivo es configurar mod_ssl de la forma mas segura posible sacrificando el desempeño.

      Esta configuración es ideal para entornos donde las comunicaciones deban ser muy seguras y el tipo de datos a los que se acceden sean críticos.

      Certificados digitales de 2048, o mas: Es importante que nuestro certificado para mod_ssl sea como poco de 2048, lo ideal sería de 4096 pero no estoy seguro si existen muchas CAs reconocidas que firmen esos certificados. En cualquier caso si estamos creando un certificado auto-firmado o firmado por una CA que controlemos, mejor emplear 4096.

      Deshabilitar SSL v2: Es importante deshacernos de SSL v2 y emplear al menos v3 o TLS, para ello editamos ssl.conf y configuramos la directriz SSLProtocol de la siguiente forma:

      SSLProtocol -ALL +SSLv3 +TLSv1

      Emplear solo algoritmos robustos: mod_ssl soporta un buen número de algoritmos, algunos de bastante baja calidad (en parte como legado de la época donde EEUU restringía el uso de algoritmos fuertes). Para emplear solo algoritmos de alta calidad debemos configurar la directriz SSLCipherSuite de la siguiente forma:

      SSLCipherSuite HIGH:MEDIUM

      Ampliar el tamaño de la semilla aleatoria: Para mejorar la calidad de la semilla aleatoria debemos configurar SSLRandomSeed de la siguiente manera:

      SSLRandomSeed startup file:/dev/urandom 1024

      Habilitar 'HTTP Strict Transport Security': Uno de los ataques mas dañinos a un recurso SSL es el que se realiza con la herramienta sslstrip, para hacer frente a el podemos activar HSTS de forma que cuando un navegador se conecte al recurso SSL, será notificado que siempre debe acudir a el por ese protocolo y no por HTTP. Para activar esta opción debemos editar el httpd.conf y en la sección del vhost que tengamos configurada para SSL añadir:

      Header add Strict-Transport-Security: "max-age=15768000;includeSubdomains"

      Es necesario tener activado mod_headers

      Referencias:


      Leer más...

      19 diciembre 2010

      Enlaces de la SECmana - 50


      Leer más...

      18 diciembre 2010

      Kaminsky hackea el Daltonismo

      En una ocasión, alguien me comentaba que, leyendo los típicos papers donde alguien expone una nueva técnica de hacking o algunos 'hackeos memorables' se planteaba si toda esa gente de enorme talento en el mundo informático podrían hacer lo mismo en otros campos como la medicina.

      Concluía que, probablemente todos esos ninjas del IDA, TCP/IP etc probablemente serian capaces de curar un montón de enfermedades.

      He recordado esa conversación cuando ha caído en mis manos una noticia que me ha sorprendido mucho. La noticia tiene que ver con el gran Dan Kaminsky al que todos conocemos por sus hallazgos en materia de seguridad como por ejemplo el affaire del DNS.

      Por lo visto Dan tiene un amigo que padece Daltonismo, esa enfermedad que impide procesar correctamente los colores, y cuenta que, un día viendo Star Trek, quedo sorprendido por como su amigo era incapaz de percibir que uno de los personajes tenia la piel verde.

      A raíz de eso el bueno de Dan se puso a pensar como podía afrontar esa limitación y 'bypasearla', después de 14 meses trabajando en el tema, Kaminsky dio con una solución muy creativa: Una aplicación para Iphone / Android que, empleando técnicas de 'realidad aumentada', permite procesar a través de la cámara del móvil una imagen y cambiar los colores problemáticos (verde-rojo) de forma que un daltonico sea capaz de 'ver' las diferencias. Impresionante ¿verdad?

      La aplicación ya está disponible públicamente en los respectivos markets y se planean versiones para Symbian, RIM y Windows

      Un enorme aplauso para Dan !
      Leer más...

      17 diciembre 2010

      Libro: DNI-e tecnología y Usos

      Hace unos años presentaba en la NcN una introducción al DNI electrónico en el que desde SIA habíamos participado implantando una de las PKI que lo componen. Así que cuando me enteré de que Rames Sarwat, CEO de SmartAcess y especialista en smartcards, PKI y biometría iba a publicar un libro integro sobre esto mismo encargue mi copia. Ahora que ya he leído "DNI-e tecnología y Usos", estos son mis comentarios.

      Si soy sincero, no imaginaba que fuera a ser un libro fácil de leer cuando lo compré, la criptografía y las smartcards, pueden ser un hueso si no te gusta ese campo. Pero me equivoqué por completo. Rames ha conseguido plasmar muchísimo conocimiento en nueve capítulos didácticos. Comienza con una introducción al DNI electrónico, luego profundiza en la tecnología; con una introducción a la criptografía, las bases de una infraestructura de clave pública y finalmente el hardware criptográfico. De ahí, a las características propias de nuestro documento nacional de identidad, la normativa legal y firma electrónica y finaliza con aplicaciones y servicios útiles para sacarle provecho.

      Tiene dos grandes aciertos, por una parte consigue llegar a cualquier lector sea cual sea su nivel y le lleva a lo más profundo del "chip" como si fuese pasear por un parque con el perro, y por otra, cubre todos los aspectos como por ejemplo como está diseñado o que implicaciones legales tiene su uso  y no meramente lo útil que puede llegar a ser.

      Si tuviera que buscarle un pero, echo en falta algún ejemplo de código simplón para una mini-implantación, lectura de alguno de los certificados o algo similar, aunque la realidad es que detalla hasta los comandos APDU de la tarjeta.

      El libro tiene un coste de 20€ y podéis consultar su índice para conocer cuál es todo su contenido. ¿Regalo de reyes? :-)
      Leer más...