La letra pequeña de la CIA (y II)

Hace algo más de un mes hablábamos en la primera parte de este texto acerca de la inmensa cantidad de información que se está perdiendo continuamente debido a los problemas inherentes a los medios digitales: soportes vulnerables, formatos de vida fugaz y escaso interés en la compatibilidad hacia atrás.

Todo ello representa un peligro para la disponibilidad de información y es por tanto un problema de seguridad. Desde muchos puntos vista la pérdida de información valiosa puede resultar crítica incluso para la supervivencia de entidades o de individuos.

Por ello, al terminar el artículo, planteábamos la pregunta de qué posibilidades existían para hacer frente a este problema.

Hasta donde he podido investigar, la solución más seria al respecto la da la Fundación del Largo Ahora (The Long Now Foundation). Una organización privada establecida en el año 01996 con intención de presentar una alternativa al tipo pensamiento actual, obsesionado con el “más rápido/más barato”, enfrentándolo a un pensamiento a largo plazo “más lento/mejor”. Su esperanza es fomentar la responsabilidad humana en el marco de los próximos 10.000 años. Por ese motivo, escriben los años con cinco dígitos, con un cero a la izquierda, de manera que psicológicamente el lector abra una ventana temporal mucho más amplia. Una manera sutil de decir que no estamos en el último año, sino en el comienzo de los muchos más que quedan por venir. Intentando actuar en escalas de tiempo más naturales.




Entre los varios proyectos de la organización, llama especialmente la atención el disco (duro) de Rosetta. Consiste en un disco de aproximadamente 7cm de radio, que puede almacenar hasta un máximo de 200.000 páginas en cada una de sus caras.

Las características del soporte (un disco de una aleación de níquel, dentro de un elegante diseño de acero inoxidable y vidrio magnificador) lo hacen resistente al agua, a las altas temperaturas y a las radiaciones electromagnéticas. El formato, diminutas imágenes grabadas sobre la superficie, es completamente analógico; es decir, independiente de cualquier tipo de codificación digital y, por tanto, legible por cualquier ser humano. Dibujos y letras. Muy pequeñas, pero letras al fin y al cabo.


Para su uso actual el tamaño de cada página grabada es bastante superior al mínimo soportable, por lo que están grabando unas 30.000 páginas por disco. Lo prefieren así para que pueda ser leído con un buen microscopio óptico (tecnología del siglo XVIII) antes que con uno electrónico (tecnología del siglo XX).

¿Y cuál es ese uso? Por el momento, salvaguardar aquellos lenguajes existentes y para los que existe riesgo real de desaparecer en los próximos 100 años (entre el 50 y el 90% de los idiomas actualmente hablados en la tierra). De ahí su nombre. En referencia a la inestimable piedra de Rosetta.

Tal vez sea inocente por mi parte, pero me pregunto si no tendrían cabida soluciones de este tipo dentro del mercado de seguridad de la información actual. ¿Existirían organizaciones interesadas en adquirir “discos duros de Rosetta” -aunque fueran de “baja gama”- para almacenar indefinidamente aquella información que sea lo suficientemente relevante?

En mi opinión, al menos los Estados deberían considerarlo para guardar registros de su historia. Y, ¿por qué no?, oficinas de patentes, bibliotecas, universidades, ¿tal vez particulares?… El mercado potencialmente interesado en algo así quizá sea mayor de lo que pueda parecer en un principio.

Quizás las compañías encargadas de ofrecer seguridad de la información podríamos comenzar a dar algún paso en esa dirección. Y es que, de las tres letras que identifican los componentes de la seguridad (recordemos: CIA Confidentiality, Integrity, Availability); puede que para garantizar la última, la más pequeña, quizá la clave esté en usar, irónicamente, letra pequeña. Muy pequeña.


Luis Tarrafeta
S21sec labs

Malware en dispositivos móviles: los origenes

De un tiempo a esta parte, los dispositivos móviles tales como smart-phones, PDAs etc. han ido cobrando cada vez más importancia en nuestras vidas, hasta tal punto que para algunos, se han convertido en accesorios indispensables en su vida cotidiana.

Si bien, el usuario medio, hoy en día es consciente de las amenazas en forma de virus y troyanos (malware en general) que existen alrededor de equipos informáticos, como ordenadores personales, no ocurre lo mismo con los dispositivos móviles. Los teléfonos móviles, al igual que los ordenadores, también pueden ser atacados.

Todo empezó en junio del año 2004, con una "inocente" prueba de concepto llamada "Cabir".

"Cabir" era un virus tipo gusano, que se propagaba a través de conexiones bluetooth entre dispositivos móviles. En su primera versión, Cabir.A, el gusano solo se podía propagar a un único dispositivo por cada reinicio de este último. En diciembre de 2004, las versiones Cabir.H y Cabir.I superaron esa limitación, y por cada reinicio del dispositivo, se podían propagar a un número ilimitado de dispositivos. Si bien, este virus es inofensivo, afectaba a
la duración de la batería del móvil debido al uso
del bluetooth.

Otro virus "pionero" fue el denominado "Skull". Apareció en Noviembre de 2004 y no tuvo demasiado impacto. Cambiaba todos los iconos de la pantalla del telefono por calaveras y dejaba el teléfono practicamente inutilizable (ni si quiera se podían mandar SMSs).El virus fue encontrado en sitios "shareware" para Symbian bajo el nombre "Extended Theme Manager.sys" y "Tee-222.sys".

En Marzo de 2005 se descubrió otro virus tipo gusano llamado "CommWarrior". Este fue el primer virus que se propagaba a través de mensajes MMS (con el consiguiente gasto para el usuario del móvil). También tenía la capacidad de propagarse a través de bluetooth y guardaba una copia de si mismo en las tarjetas de memoría extraibles, de manera que si se usaba esa tarjeta en otro teléfono, este tambien quedaba infectado.

Los ejemplos hasta ahora citados son solo una muestra de los primeros pasos que se dieron en la creación de malware para dispositivos móviles. A estos les siguieron "Doomboot" (descubierto en Marzo de 2005), que te hacía creer que te estabas instalando Doom 2, el juego, pero en realidad te instalaba Cabir y CommWarrior, y "RedBrowser" (descubierto en Febrero de 2006), aplicación Java que mandaba mensajes a un número de telefono de Rusia, entre otros.

Una característica que llama la atención de estas primeras versiones de malware es, que en vez de sacar provecho de alguna vulnerabilidad existente en el dispositivo móvil, se hacía uso de lo que se conoce como "ingeniería social", es decir, engañar al usuario para que este último acceda a la instalación de programas maliciosos.

Hoy día, el problema del malware en dispositivos móviles, si bien no ha alcanzado el mismo impacto que en los ordenadores, es algo que se debe tener en cuenta y de lo que hay que estar concienciado.

Aunque existen productos comerciales tipo antivirus específicos para dispositivos móviles, cara a mantener nuestros dispositivos a salvo es recomendable seguir unas pautas mínimas de seguridad:

- Asegurarnos que todos los dispositivos a los que sincronicemos nuestro móvil estén protegidos con software antivirus actualizado. En algunos casos, es posible que estas aplicaciones detecten el archivo infectado antes de que este sea instalado en el teléfono.

- Usar bluetooth solo cuando es necesario, y el resto del tiempo tenerlo apagado, o por lo menos, en modo oculto. Nunca dejo de sorprenderme cuando estando en un sitio público al hacer un escaneo de la zona con mi móvil, siempre aparece mas de un dispositivo. Además de proteger nuestro móvil, de esta manera ahorraremos batería.

- Como siempre, usar el sentido común y no instalar aplicaciones de dudoso origen en nuestro móvil.

- Mantener siempre una copia de seguridad de los datos de tu móvil. El malware es una amenaza para los móviles, pero también lo son el hurto o la perdida de estos últimos.




Asier Marruedo
S21sec labs

No subestimes tus Cross-Site Scriptings

Los ataques tipo Cross-Site Scripting (XSS, conocidos con este acrónimo para no confundirlo con el de las hojas de estilo CSS) son una vulnerabilidad que afecta típicamente a las aplicaciones Web, y que se basa en la inserción de código Web malicioso aprovechando las carencias de filtrado de la Web afectada.

Para conocer datos técnicos sobre esta vulnerabilidad, hacemos referencia al siguiente documento, o bien a la propia entrada de la wikipedia.

Este tipo de ataque ha ido ganando importancia a lo largo del tiempo, hasta situarse en el puesto número uno dentro del ranking de amenazas Web más comunes.

A pesar de la frecuencia de esta vulnerabilidad, son muchos los que la infravaloran debido a que en la gran parte de los casos, es necesario que el usuario acceda al enlace especialmente formado para poder explotarla.

Sin embargo, y debido al gran desconocimiento de muchos usuarios, existen numerosas técnicas para que, tanto de forma directa como indirecta, se acabe accediendo a la URL infectada.

Como muestra del alcance de esta vulnerabilidad, en el siguiente vídeo se ven algunos ejemplos de hasta que punto se puede tomar el control de un ordenador que ha sido víctima de un Cross-Site Scripting, y como utilizando BeEF (Browser Explotation Framework) se puede llegar a controlar todo una botnet.

Muy conocido fue el caso del gusano Samy que afectaba a la red social MySpace y que aprovechaba un Cross-Site Scripting para infectar a todos los usuarios de esta red.

A modo de resumen final, se listan algunos ataques que pueden utilizar un Cross-Site Scripting como vector de ataque:

• Phishing

• Hijacking de sesiones

• Robo de credenciales

• Defacements

• Escaneo de redes

• keylogging

Jonathan Barajas

S21sec Auditoría

Storm: ingenieria social aplicada

Desde hace ya varios días, Storm ha cambiado su mensaje en su objetivo de infectar máquinas para que pertenezcan a su botnet. Esta vez, intentando motivar a sus posibles victimas con dos temas bastantes actuales: el terremoto que sufrió China, y los futuros juegos olímpicos de Beijing 2008 (se descarga un fichero llamado beijing.exe).

Como siempre, aprovechando cualquier desastre, o incluso evento mundial (como por ejemplo e-mails con el motivo de la Eurocopa que se han visto recientemente, pero ahora empezaremos a ver más correos relacionados con los Juegos Olímpicos), se busca la participación y engaño de las personas con motivos atractivos, siempre con el mismo resultado, principalmente la infección del equipo o el fraude económico.

David Barroso

S21sec e-crime

Wear-levelling y la privacidad de tus datos

Ya hemos hablado largo y tendido sobre el peligro asociado al ciclo de vida de un dispositivo de almacenamiento cualquiera como un disco duro o una memoria flash en nuestro ordenador. Os quería comentar por qué debemos tener sumo cuidado con la información sensible que almacenamos en ellos, y por qué un cifrado de volumen podría no ser suficiente protección.

Todo el problema radica en un algoritmo que consigue que nuestros dispositivos de almacenamiento, principalente de memoria flash, tengan una durabilidad aceptable de acuerdo a los estándares industriales. Hasta ahora han existido dos tecnologías de NAND flash, la Single Level Cell (SLC) y la Multi Level Cell (MLC). La primera es fundamentalmente mejor, logrando mejores tasas de lectura y escritura, una vida de las celdas 10 veces mayor (100.000 ciclos de borrado/escritura frente a los 10.000 de los MLC) y un menor consumo de energía. El problema es que su menor densidad hace que para lograr las mismas capacidades que con chips MLC sea necesario meter más puertas lógicas, con el consecuente encarecimiento del semiconductor. Es por ello que de momento los discos duros de estado sólido (SSD) tengan un precio tan desorbitado, y la industria esté creando unidades híbridas o 100% MLC para abaratar costes.

Los dispositivos de almacenamiento cada vez son más inteligentes, con SoC basados en arquitecturas ARM, como este de Marvell. Es en estos y en las controladoras de memorias flash donde se embebe wear-levelling, una técnica que logra maximizar la vida útil de las celdas/partes móviles de los dispositivos gracias al uso eficiente de su espacio, siendo además posible detectar y marcar los sectores que van quedando inutilizados para no perder información. El problema radica en que cuando nosotros borramos algo, incluso sobreescribiendo los sectores ocupados por la información mediante el algoritmo Gutmann de 35 pasadas, lo más probable es que a nivel físico los datos sigan ahí, ya que prima más la durabilidad del medio y su eficiencia, que la seguridad de los datos que residen en él.

Bien, vamos más allá. Según compro mi disco duro SSD o dispositivo de memoria flash USB opto por cifrarlo por completo mediante Truecrypt o dmcrypt. Esta claro que la información reside cifrada por lo que salvo por rotura del algoritmo de cifrado o que averigüen la contraseña, los datos permanecerán a buen recaudo. Pero ¿qué pasa si alguien, empleando ingeniería social, consigue nuestra clave, o si perdemos de vista nuestro preciado "pincho USB" por unos días? Podríamos proceder a cambiarla e inmediatamente se reescribiría la cabecera de volumen acorde a la nueva contraseña. Pero de nuevo wear-levelling entra en acción, escribiendo la nueva cabecera en un bloque distinto, dejando la antigua intacta. Un atacante avezado podría lograr localizar dicha cabecera (recordemos que conoce la contraseña) y ha podido tener acceso al dispositivo de memoria y haber hecho una imagen binaria del mismo, logrando abrir el volumen con ella.

¿La solución? Desconfía de los dispositivos de almacenamiento (sobre todo de las memorias flash) cifrando todos tus datos sensibles, y procura mantener a muy buen recaudo tus claves de cifrado. Y cuando llegue el momento de deshacerse del medio de almacenamiento, nada mejor que un "crusher" de discos duros o un horno que caliente nuestro dispositvo USB a más de 1500 grados kelvin ;)

Álvaro Ramón
S21sec labs

Seguridad en protocolos de enrutamiento dinámico (II)

Pasadas ya unas cuantas semanas desde que hablé de la seguridad en protocolos de enrutamiento IGP, me he decidido a retomar el hilo del asunto. En esta entrada trataré algunos mecanismos de seguridad relacionadas con el protocolo BGP. Como ya sabéis BGP (en concreto la versión 4) es un protocolo de enrutamiento dinámico, de hecho el único, que se utiliza como EGP entre los distintos sistemas autónomos (AS) que conforman Internet.

A continuación listo a modo de repaso los aspectos más importantes del protocolo:

• Es un protocolo vector-camino (muy similar a los protocolos vector-distancia)
• Por lo tanto, el cálculo de las rutas que conforman la tabla de enrutamiento se hace de manera distribuida (el conocimiento del camino está distribuido)
• Para ello, los nodos informan a sus vecinos de las redes que alcanzan {red, siguiente salto, [lista AS]}. Véase figura.
• Los mensajes de protocolo se envían sobre conexiones TCP al puerto 179
• Finalmente, notar que permite el intercambio de información de subredes classless (CIDR)

Un primer sistema para proporcionar seguridad en el intercambio de mensajes BGP es la autenticación de los mismos. Como ya se ha mencionado, BGP hace uso de sesiones TCP para el intercambio de mensajes. La solución viene de la mano de la RFC 2385: “Protection of BGP Sessions via the TCP MD5 Signature” que propone utilizar el campo de opciones de la cabecera TCP, para incluir en cada segmento de este protocolo un hash MD5 que complique los ataques de spoofing y man-in-the-middle. Este MD5 se calcula utilizando una clave previamente compartida entre los nodos finales de la conexión TCP.

Con el objetivo de minimizar los ataques de redirección de tráfico, de secuestro de prefijos mediante publicación malintencionada de los mismos, y de DoS de los routers BGP, resulta de vital importancia realizar un filtrado de prefijos adecuado en los routers BGP del AS, para lo que muchas veces basta aplicar el sentido común. A continuación listo algunos aspectos a tener en cuenta, aunque existen más:

• Evitar la publicación hacia otro AS de prefijos de red asociados con el espacio de IP privadas, cualquier otro de propósito especial o incluso no asignadas aún por la IANA.
• Los prefijos de red utilizados para direccionamiento interno del AS nunca deberían ser publicados hacia otros AS aún cuando estén dentro del rango de IP públicas.
• En caso de que el AS sea un ISP, éste no debería publicar rutas hacia redes de las que no sea responsable.
• Todo ISP debería descartar como mínimo prefijos de red mayores de 24 bits de longitud puesto que éste es el tamaño mínimo asignado por las entidades de registros de Internet.

Con esto me despido hasta el próximo post, en el que probablemente os hablaré de las nuevas líneas de I+D que se están llevando a cabo para mejorar la seguridad de nuestros queridos protocolos de enrutamiento.

Elyoenai Egozcue
S21sec labs

Rica miel

Hasta ahora no hemos hablado de los honeypots. La idea es muy sencilla. Poner una trampa, un cebo fácil. Cuando se recibe un ataque, se obtiene información e incluso muestras de malware. También sirve para conocer el origen de los ataques, que pueden provenir de otros ordenadores que ya han sido víctima de un ataque.

El ejemplo más sencillo de honeypot es un ordenador que se deja conectado a Internet o a una red. Más temprano que tarde será objetivo de ataques y en caso de ser vulnerable resultará infectado. Si realizamos un análisis forense podemos conocer detalles del ataque y el malware que se haya podido ejecutar. Esta solución no es muy recomendable. El mantenimiento y los análisis forenses son bastante costosos. Además, al infectarse puede convertirse en un origen de ataques, por lo que debería aislarse adecuadamente para no afectar a las máquinas del resto de la red.

Seguro que a muchos se os ha venido a la cabeza la virtualización. En este caso puede sernos muy útil el poder recuperar el estado de una máquina virtual. La única pega es que cada vez más especímenes comprueban si están siendo ejecutados en un entorno virtual y en caso de ser así, se detienen. Es decir, puede que obtengamos una información parcial, a cambio de un mantenimiento más sencillo. De todas formas el riesgo de que troyanicen nuestra máquina (virtual) y la necesidad de realizar análisis forenses siguen existiendo.

Eso no es todo. Los honeypots anteriores son los llamados "de alta interacción". En realidad hay muchos otros que tienen un nivel de interacción menor. La información que se consigue es más limitada, pero a cambio son mucho más sencillos de implementar y mantener. El funcionamiento básico es muy simple. Simulan servicios vulnerables y responden a las peticiones siguiendo diferentes estrategias, como intentando que se parezca lo más posible a la respuesta que daría el servicio simulado, enviando respuestas aleatorias o incluso devolviendo como respuesta la misma petición que se ha recibido.

Hay honeypots de este tipo que no solo simulan los servicios, sino que simulan toda una red de ordenadores con diferentes servicios cada uno, también con una interacción limitada.

En un nivel aún más bajo de interacción, se puede anunciar en el DNS una serie de direcciones IP que en realidad no están en uso. Examinando el tráfico dirigido a estas direcciones, podemos detectar oleadas de ataques automáticos o medir el 'backscatter' de los ataques de DoS distribuidos.

En los repositorios de muchas distribuciones de GNU/Linux hay paquetes con honeypots de baja interacción, por lo que cualquiera puede instalar uno fácilmente para probar que tipos de ataques y malware se ve por internet. Si lo pruebas, recuerda configurar bien tu firewall o tu router y comenta que encuentras. ;)

Patxi Astiz
S21sec labs

¿Realidad o ficción?

Interesante viñeta que nos dejan los compañeros de Ikarus Software. ¿Realidad o ficción?

David Barroso

S21sec e-crime

S21SEC-044-en:OpenDocMan Cross Site Scripting (XSS)

##############################################################
                     - S21Sec Advisory -
##############################################################

Title: OpenDocMan Cross Site Scripting (XSS)
ID: S21sec-044-en
Severity: Low
History: 15.Apr.2008 Vulnerability discovered
16.Apr.2008 Vendor contacted
27.May.2008 Patch available
Scope: Cross Site Scripting XSS
Platforms: Any
Author: Sergi Roselló (srosello@s21sec.com)
URL: http://www.s21sec.com/avisos/s21sec-044-en.txt
Release: Public


[ SUMMARY ]

OpenDocMan is a free document management system (DMS) designed to
comply with ISO 17025 and OIE standard for document management. It
features web based access, fine grained control of access to files,
and automated install and upgrades.


[ AFFECTED VERSIONS ]

This vulnerability has been tested in version v1.2.5 (March, 2nd 2007).


[ DESCRIPTION ]

An insufficient input validation allows code injection in the
parameter 'last_message'. 

Example:
http://server/opendocman-1.2.5/out.php?last_message=%3Cscript%3Ealert(document.cookie)%3C/script%3E


[ WORKAROUND ]

There is patch available in the following url:
https://sourceforge.net/tracker/index.php?func=detail&aid=1975163&group_id=69505&atid=524753


[ ACKNOWLEDGMENTS ]

This vulnerability has been found and researched by:

- Sergi Roselló S21sec


[ REFERENCES ]

* OpenDocman
http://opendocman.com/

* S21sec
http://www.s21sec.com

* S21sec Blog
http://blog.s21sec.com

Los cementerios están llenos de buenas intenciones

Esta semana hemos tenido un buen ejemplo de cómo en seguridad a veces una combinación de buenas intenciones y casualidad o despiste puede llevarnos a tener un incidente de seguridad.

Ejemplo de buena intención 1: SNMPv1 y v2 no ofrecen seguridad suficiente, migremos a SNMPv3.

SNMPv3 se define de forma bienintencionada para mejorar varios aspectos de seguridad de los que carecían sus predecesores. Una buena medida para mejorar la seguridad de nuestra red podría ser utilizar siempre SNMPv3.

Ejemplo de buena intención 2: Eliminemos las funciones inseguras del código.

Supongamos que un desarrollador, bien por propia iniciativa o bien por consejo de un analista bienintencionado decide eliminar las funciones inseguras de su código C, para evitar los molestos warnings de seguridad.

Pongamos por ejemplo que hace uso de la función "strcmp() "o una similar para comparar 2 contraseñas en una proceso de autenticación. La "contraseñaA" que es la que recibe del cliente y la "contraseñaB" que es la clave actual:

"comparacion=strcmp(contraseñaA, contraseñaB);if(comparacion==0)Padentro();"

Si la "contraseñaA" es igual a la "contraseñaB", permitimos el acceso.

Como todo el mundo bienintencionado sabe "strcmp()" es insegura porque no comprueba el limite de las cadenas comparadas. Así que es necesario reemplazarla por su alternativa segura "strncmp()" que si compara las cadenas hasta un limite. El código quedaría:

"comparacion=strncmp(contraseñaA,contraseñaB, len(contraseñaA));
if(comparacion==0) Padentro();"

Pero qué pasa si la longitud de "contraseñaA" es 1. Sólo se compararía el primer carácter de la contraseña. Y si sólo se compara un carácter, no tendría más que unas pocas combinaciones de acceso posibles, que en el caso alfanumérico no serían más de 64 posibilidades. Estaríamos ante una vulnerabilidad importante.

Este tipo de vulnerabilidades que podríamos llamar de “comparación de pocos caracteres” (few-chars-comparison) no tiene una categoría propia, pero ya se han documentado situaciones similares, como por ejemplo en Avaya Argent Office o en MySQL.

INCISO – VULNERABILIDAD 10: Vulnerabilidades 10 son aquellas perfectas, hermosas, las que cualquier auditor desearía encontrar.El 10 no es arbitrario, viene del criterio de clasificación de vulnerabilidades CVSS (Common Vulnerability Scoring System) que nos permite clasificar de forma objetiva el riesgo de cada vulnerabilidad en función de una serie de factores: rango de acceso (local o remoto), complejidad del ataque, necesidad de autenticación, impacto, etc.

Si os interesa este tema ya hablaré más profundamente en otro post.

A lo que íbamos, esta semana tenemos una vulnerabilidad 10 que combinada con unas buenas intenciones como las del ejemplo 1, podría llevar a muchos administradores de red a una situación delicada.Resulta que la autenticación en SNMPv3 se realiza utilizando un hash HMAC que es calculado combinando una función criptográfica y una clave secreta. Pero, ¿qué pasaría si para comparar el HMAC que envía un cliente SNMPv3 que intenta conectar y el HMAC correcto se utiliza una función "memcmp()", de forma similar a la que hemos visto en el ejemplo 2? Pues que tendríamos un serio problema:

SNMPv3 Authentication Bypass Vulnerability

Y que pasaría si por "casualidad" el mayor fabricante de equipos de networking, también hiciese algo parecido en su código:

CISCO SNMP Version 3 Authentication Vulnerabilities

Pues sí, tenemos una vulnerabilidad 10: Remota, fácil de aprovechar y que permite evitar totalmente el mecanismo de autenticación. Hoy estoy orgulloso de ser auditor.







Así que, cuando alguien con buena intención os diga que toméis alguna medida adicional de seguridad. Tomarla, pero tener en cuenta que cualquier cambio puede generar una cadena de casualidades o despistes que provoquen un efecto contrario al deseado. Ya sabéis, las buenas intenciones nos pueden llevar a la tumba...

Ramón Pinuaga
Departamento de Auditoría

Las nuevas amenazas, ¿hacemos lo que podemos?

Desde hace ya varios años, nos dedicamos a presentar en público el escenario de las nuevas amenazas que existen en Internet. Poco a poco hemos ido visitando numerosos países (Alemania, México, Argentina, EEUU, Holanda, Francia, Inglaterra, ...) donde hemos comentado, de una forma práctica, a qué nos estamos enfrentando en la actualidad.

En todos estos sitios hemos ido conociendo gente que comparte nuestras ideas, y también gente que piensa de manera distinta, pero que realmente argumentan con razones de peso sus ideas y nos hacen ver las cosas de manera diferente. Los perfiles del público han sido de todo tipo: universitarios, directivos, técnicos, periodistas, ... y hemos tenido que cambiar el contenido para transmitir nuestro mensaje sobre estas amenazas, originadas principalmente por bandas de crimen organizado que operan en Internet.

Generalmente las conversaciones más interesantes ocurren después de las presentaciones, y últimamente hay dos preguntas que siempre se formulan en esos instantes posteriores:

• ¿Qué podemos hacer para que mi ordenador no sea controlado remotamente por nadie? Tipo botnets, click fraud, pay per install, spam, etc etc.
• ¿Por qué aparece España como uno de los países con más ordenadores infectados en relación con su población?
  

Realmente las respuestas a ambas preguntas no son sencillas, puesto que no hay una respuesta simple. En el caso de la primera, cada día me sorprende más la sensación generalizada entre los usuarios de Microsoft Windows de querer seguir con Windows XP, y no migrar a Windows Vista (ojo, no digo que sea mejor o peor, ni que si Linux o MacOSX es mejor o peor). Como todas las cosas, los sistemas operativos evolucionan, y los mecanismos de seguridad que se implementaron en XP allá a finales de 2001, no tienen nada que ver con los implementados en Vista a finales de 2006. Durante esos cinco años hubo un cambio sustancial de las amenazas que sufrimos (la famosa época romántica vs crimen organizado), y por supuesto, un cambio sustancial en las arquitecturas de Seguridad de estos sistemas operativos.

Poniendo la famosa analogía con el mundo del automóvil, creo que si todos pudieramos, tendríamos un coche nuevo con las últimos avances en Seguridad, en vez de usar coches antiguos, puesto que eliminaríamos riesgos innecesarios y mitigariamos muchos de ellos. Por supuesto, luego también depende de la pericia del conductor para no sufrir ningún tipo de daño.

En los sistemas operativos ocurre igual. Muchas veces no migramos a un sistema operativo más nuevo por problemas de hardware (nuestro hardware no es capaz de soportar ese nuevo operativo) pero la sensación actual es que compramos máquinas nuevas y hacemos un downgrade a Windows XP por la razón X. ¿Pero, cuál es esa razón? A día de hoy, no he encontrado ninguna que realmente justifique ese downgrade (es verdad que en Internet hay numerosos documentos, pero realmente, según a quién preguntes te dirá una cosa u otra). Por supuesto, como para todo, hay gente a favor y gente en contra, pero utilizar un Windows XP a día de hoy es como usar una Debian Woody, o un MacOSX Puma. Y también, la pericia del usuario influye.

Para más inri, todos los kits de infección funcionan en Windows XP, pero no todos funcionan en Windows Vista. Dentro de unos días, el 30 de Junio, Microsoft dejará de dar licencias nuevas de Windows XP, aunque el soporte extendido durará hasta el 8 de Abril de 2014!!!

En definitiva, hay razones para seguir o no con Windows XP (de hecho, es el sistema operativo más usado), pero ¿cuáles son esas razones? Porque esas razones están haciendo que la infección de máquinas con Windows XP (y por ende, de máquinas del mundo) sea relativamente sencilla.

Respecto a la segunda pregunta, la dejamos para el siguiente post :)

Disclaimer: este post no fue escrito desde un Windows XP

David Barroso

S21sec e-crime

Asegurando Imágenes

Muchas veces vemos imágenes en páginas de internet que ya hemos visto en otras páginas o revistas o libros. Cuando se almacenaban de forma analógica existían albums de fotos de profesionales donde constaba su nombre, para saber quién la había hecho. Dichos albums circulaban de mano en mano o por "snail-mail". Actualmente es mucho más complicado. El número de personas es mucho mayor e internet permite una velocidad de difusión varios órdenes de magnitud superior. Cualquier persona puede hacer una buena fotografía y publicarla en la red.

Uno de los problemas a los que se enfrentan los profesionales de la fotografía es asegurar que su trabajo no es usado de forma fraudulenta, después de todo ellos viven de la fotografía. Para ello se usan varios métodos:

• albums digitales
• firmado digital
• marcas de agua
• metadatos
  

En esta entrada me voy a centrar en las técnicas de marcas de agua. Obviamente no voy a contar lo último de lo último pero si técnicas conocidas y accesibles. Existen dos tipos de marcas de agua que se pueden hacer a las fotografías. Visibles e invisibles.

Las visibles son imágenes que se superponen a la fotografía original con información que identifica al autor o dónde se puede encontrar la original sin la marca. Se puede hacer a mano con gimp o con cualquier otra aplicación de tratamiento de imágenes, pero normalmente se suele automatizar con scripts o si estamos en un servidor on cgi o php usando a librería imagemagick.

Las invisibles son marcas digitales que se añaden a la propia información de la imágen. No se pueden eliminar sin perder calidad en la imágen, haciendola inservibles. El formato de la imágen es importante, suelen ser formatos con pérdida como jpeg, para que cualquier intento de modificar la marca de agua conlleve la pérdidad de la imágen. Hay varios parámetros de la imágen que pueden ser usados,

• modificar coeficientes dct que forman una imágen jpeg
  
• pequeños cambios en el histograma de la imágen
• pasar un filtro, aplicar la marca de agua y deshacer el filtro

Estos métodos permiten añadir la marca de agua de forma invisible, aunque son métodos sensibles a cambios de la imágen como redimensionado, recompresión, o similares.

Por supuesto, los métodos más modernos permiten saltarse estas limitaciones pero eso queda para reuniones técnicas y eventos especializados.

Eduardo Morrás
S21secLabs

No tardes cuando vayas al baño

Hace unos días se armó cierto revuelo en internet cuando salió a la luz un vídeo donde se vulneraba la seguridad de Windows Vista. En muchos sitios se ponía en tela de juicio la novedad de lo mostrado. De hecho, dentro de nuestras propias listas de discusión también salió el tema y también tuvo cola. La prueba de concepto consistía únicamente en la sustitución del archivo utilman.exe (Windows Utility manager) por el intérprete de comandos de Windows, cmd.exe. Eso sí, si le añades la música de Misión Imposible y obtienes la shell en 2 minutos impresiona bastante más.

El tema es que como se ha dicho por ahí, esto no es nada nuevo. El ataque se basa en el acceso físico al equipo en cuestión, y con acceso físico y sin las medidas de seguridad apropiadas, tienes control total sobre el equipo. Este mismo ataque se puede reproducir de muchas maneras, tanto en Windows Vista, como XP, 2000, y usando otras aplicaciones. Uno de estos ejemplos es el de las sticky keys, sethc.exe, comentado por uno de mis compañeros en nuestras listas. Al igual que la anterior, se basa en la posibilidad de lanzar una aplicación a través de un atajo de teclado antes incluso de hacer login en el sistema. De esta forma, si sustituimos estos ejecutables por el intérprete de comandos obtendremos shell con permisos de SYSTEM con sólo pulsar las teclas apropiadas. Como estas cosas hay que probarlas, he aquí la prueba del delito, que funciona a la perfección:


Esta “vulnerabilidad” no sólo afecta a los sistemas operativos de la familia Windows, sino que es igualmente válida para otras plataformas, como nuestro querido Linux. ¿Quién no conoce la opción single del lilo/grub? ¿no basta con añadir init=xxxx y ejecutar lo que se desee? Incluso ya hace mucho que es posible modificar archivos de Linux desde Windows. Ya no es un tema de seguridad del sistema operativo en sí, sino de la seguridad física del equipo.

Hay unas cuantas medidas de seguridad a tener en cuenta para que no nos pase nada parecido y nos cuelen un backdoor o un keylogger. Si se dispone de un menú de arranque tipo grub, éste debería estar protegido con contraseña, evitando la modificación de los parámetros de arranque de los sistemas operativos instalados. Además, es importante proteger también la BIOS con password y configurarla para que sólo se pueda arrancar desde el disco, evitando así la ejecución de sistemas operativos alternativos en caliente. También es verdad que en los equipos de sobremesa, y ya que tenemos acceso físico, es posible extraer la pila de la placa base para resetear las opciones de la BIOS, quedando ésta totalmente desvalida. Es por ello que deberemos complementar lo citado anteriormente con el cifrado completo del disco, para que si acceden a él no haya ninguna información visible y útil para los atacantes. Aunque puede que esto no sea del todo cierto...Por si acaso, será mejor que no tardes mucho cuando vayas al baño;)


Jose Miguel Esparza
S21sec labs

¿Mi PC?¿Quién lo va a querer?

Volviendo a los post de concienciación que nos puso en su día nuestro compañero Jose Miguel Esparza (1 y 2), vamos a pensar un poco en motivos comunes por los que alguien puede estar interesado en infectar un (tu) ordenador personal.

Vamos a dar respuestas a todos aquellos que dicen:
- ¿Para qué va a querer alguien infectar mi ordenador?

Veamos que se nos ocurre:

1.- Robarte datos bancarios: Por ejemplo, para poder permitirse un capricho a tu cuenta.

2.- Envío de SPAM: Luego te llega una carta de tu operador diciendo que no paras de mandar spam, y tu quejándote de que tu aDSL va lento.

3.- Utilizar tu ordenador como zombie: Te utilizarán como proxy, como miembro de una red fast-flux, para escanear en busca de más ordenadores vulnerables... Cualquier cosa que ellos no quieran hacer desde su propio ordenador.

4.- Instalarte un bot IRC: Siepre viene bien tener un bot en tu canal IRC favorito que se encarge de mantener el orden, tener el trivial preparado...

5.- Buscar datos personales: Un amigo puede estar interesado en ver fotos curiosas que no le vas a enseñar por las buenas, espiar tu conversación del messenger...

6.- Alojar programas de computación distribuida: Si, por el motivo que sea, alguien dispone de un fichero rar con contraseña que quiere descubrir, será mucho mejor utilizar 100 ordenadores que uno solo.

7.- Servidor FTP: Tal vez en tu casa vaya lento. ¿Y en tu trabajo?

8.- emule: He visto a gente instalar el emule en sus víctimas, dejarlo activo las 24 horas, y despues subirlo todo a otro servidor más rápido para poder bajarlo a la máxima velocidad que le permita su conexión.

9.- Instalar un servidor de Quake "neutro": Así evitamos que cuando ganemos a nuestro amigo, éste nos diga que tenemos ventaja por alojar el servidor y no tener lag.

10.- Ego: Hay quien se siente realizado cuando tiene 237000 ordenadores zombies activos...

11.- Hosting: Serás un servidor web que albergarás páginas de phising o incluso cosas peores (pornografía infantil... :( )

12.- Estar en una red de click-fraud pinchando banners como loco sin darte cuenta.

1,2,3, responda otra vez...

Ah!, y no todo es ver la parte negativa, próximamente veremos cómo evitar ser infectado o cómo detectar e intentar "matar los bichos"

Mikel Gastesi
S21sec labs

Servicios de Seguridad en Extremadura

La próxima semana, en concreto el día 12, vamos a tener la oportunidad de contar a los empresarios y administraciones públicas de Extremadura nuestro modelo de servicios de seguridad de la información en el marco del Forum de la Innovación y las Nuevas Tecnologías (ENTER).

Nuestra sesión se titula "Desde la planificación estratégica a la gestión integral de la seguridad de la información" y en ella queremos destacar los aspectos claves de nuestra forma de prestar servicios:

1. Enfoque centrado en la estrategia corporativa, es decir, en el negocio.
2. Planteamiento integral de la seguridad (lógica, física, reputacional...).
3. Innovación (BITACORA)
4. Y, por último, basado en 'servicios' (ya sabéis, SaaS)

¡Nos vemos en Don Benito!

Antonio Ramos
Director de Unified Managed Security Services

Mal uso de servicios web

Una de las cosas más preciadas para un spammer es poder controlar cuentas de correo web para realizar el envío masivo de mensajes. Muchos lo consiguen rompiendo los Captchas cuando se crean cuentas de correo (en este blog se ha hecho mención recientemente a este tema).

Un spammer se evita muchos filtros consiguiendo una cuenta de correo "limpia", ya que estas cuentas proceden de webs con una reputación de seguridad normalmente contrastada. Uno de los ejemplos más claros es el de Google y su cuenta Gmail, dada la implicación que tiene actualmente en la sociedad, por la multitud de servicios que ofrece.

Algunos de estos servicios son los usados actualmente por los spammers para conseguir su fin. Por ejemplo, usan Google Calendar para, en teoría, acordar citas con el usuario de google, en lo que acaba convirtiéndose en envío de spam. El uso de Google Docs también está extendiéndose, siendo utilizado para integrar en los documentos links a sus Webs, como se explica en esta Web. Podemos ver un ejemplo en la siguiente imagen.

La pregunta que queda en el aire es: ¿cómo se puede impedir esto? La primera medida la deben tomar las propias webs (google, yahoo, hotmail), y para ello actúan con medidas que evitan en gran medida el spam y la creación de cuentas mediante bots. Pero, ¿se puede hacer algo más? ¿Todos los servicios ofrecidos permiten la opción de aceptar invitaciones?


Miguel López-Negrete
S21sec labs

Vulnerabilidad Snort

Snort es un completo sistema de detección de intrusiones más utilizados por una serie de razones de peso, es gratuito, tiene bases de datos de patrones de ataques conocidos, además de poder incorporarle una serie de reglas personalizadas por el usuario.

Pues bien, esta completísima herramienta ha presentado una vulnerabilidad que curiosamente afecta a las últimas versiones y no a las antiguas. Las versiones afectadas son la 2.8 y 2.6, mientras que la 2.4 no sufre de la vulnerabilidad.

El problema consiste a la hora de re-ensamblar los paquetes fragmentados. Cuando estos paquetes son recibidos, snort compara los diferentes TTL's y si dicha diferencia sobrepasa un valor predeterminado son descartados y no se aplicarán ningún filtro sobre ellos. Por ello un usuario podría modificar los paquetes enviados en su campo TTL para poder saltarse las restricciones de seguridad de Snort.

Para solucionarlo, basta con configurar el fichero de configuración de Snort (snort.conf) añadiendo la línea:

preprocessor frag3_engine: ttl_limit 255

Así se aumenta el tamaño de diferencias en el TTL de los paquetes hasta su valor máximo.

En caso de que se quiera actualizar la versión, también está corregido en la última versión de Snort 2.8.1.


José María Arce Guillén
S21sec labs

CAPTCHAS. ¿seguridad anti-spam del pasado?

Un CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) es una prueba o reto que trata de determinar cuando un usuario es o no humano. Un ejemplo son las típicas imágenes de texto distorsionadas que se muestran en infinidad de páginas web a la hora registrar una nueva cuenta o incluso a la hora de ingresar en una cuenta ya existente.

Este tipo de mecanismos de identificación de usuarios humanos surgieron, fundamentalmente, como protección anti-spam de los servidores de correo gratuitos contra bots que podían crear de forma automática infinidad de cuentas de email en sus servidores y que posteriormente podían ser utilizadas para realizar envíos masivos de spam. No obstante, las cuentas de correo gratuito se han venido utilizando desde siempre para enviar spam. Ante medidas de protección como los captchas, una de las soluciones adoptadas por los grupos de spamers es pagar a usuarios humanos por la resolución de estos captchas. Como muestra un botón: la siguiente imagen corresponde a una captura de una web en la que se ofrece un servicio automático de resolución de captchas pero también trabajo a usuarios reales que obtienen dinero por resolver captchas.

Presumiblemente, alguien contrata estos servicios para, por ejemplo, crear automáticamente cuentas de correo en servidores gratuitos. Al intentar crear una cuenta de correo, el captcha es enviado a este servicio de resolución automática en el que un usuario humano (que cobra por resolverlo) devuelve la respuesta de dicho captcha y así permite que el proceso pueda hacerse con éxito. Otra alternativa curiosa es lo que podríamos denominar como pago en especies. Se ha observado el uso de sitios porno donde, para poder ver las imágenes, es necesario resolver un captcha. El sistema funciona igual que el que hemos descrito antes, sólo que el usuario humano que resuelve el captcha no está cobrando nada, o al menos no está cobrando dinero. Por otra parte, no es nada nuevo que el sistema de protección mediante captchas tiene debilidades que pueden ser explotadas para resolverlos mediante algoritmos inteligentes. Aunque estos sistemas de protección han ido ganando en complejidad hasta el punto de que a veces se hace difícil para un usuario humano descifrar su contenido, también es cierto que de la misma forma los métodos de reconocimiento de imágenes también han ido mejorando. Sin duda estas técnicas se aplican a la resolución automática de captchas. Recientemente investigadores de la universidad de Newcastle (Reino Unido) han publicado sendos estudios en los que presentan como han logrado romper los captchas de Microsoft y de Yahoo con un alto porcentaje de acierto. De los estudios recientes sobre la evolución del spam, como por ejemplo las estadísticas publicadas por la compañía MessageLabs, se desprende que ha habido un significativo incremento del mes de Enero al mes de Febrero de 2008 en el spam enviado a través de cuentas de servidores de correo gratuito como Hotmail, Gmail y MSN.

Este hecho parece apuntar al uso de sistemas automáticos que permiten romper los captchas de los diferentes servidores. No obstante, estos sistemas automáticos aun tienen un porcentaje de acierto bastante bajo (entre el 20-30%), pero sin duda, a medida que se cuenta con más captchas resueltos de los que los sistemas automáticos puedan aprender, los porcentajes de acierto irán mejorando y el aumento de spam enviado desde servidores gratuitos también puede aumentar. De hecho, los sistemas que comentabamos anteriormente que resuelven los captchas mediante usuarios humanos pueden ser utilizados para entrenar los sistemas automáticos y mejorar así su capacidad de romper nuevos captchas. Ante esta problemática de le resolución automática de captchas, se presentan nuevas alternativas que compliquen el problema. Una de estas alternativas es ASIRRA de Microsoft, que muestra una serie de fotografias en las que aparecen perros y gatos y el usuario debe seleccionar todas aquellas en las que aparecen uno de estos dos animales. De forma anecdótica, una posibilidad para resolver este tipo de problemas puede salir de la misma Microsoft ya que ellos mismos investigan en potentes algoritmos que permiten identificar la presencia de determinados objetos en las imágenes.

Guzmán Santafé
S21sec labs