Semana de la seguridad 33: Puertas sin cerraduras, Microsoft invulnerable, desensamble y dolor.

En esta publicación hay dos noticias sin aparente relación; sin embargo, tienen algo en común: y no es que en algún lugar haya alguien sensible a un ataque, sino que esa vulnerabilidad a veces surge de la aversión a adoptar medidas de seguridad disponibles.

Bienvenidos al resumen semanal de noticias en seguridad, primera temporada. Segundo episodio. En la serie anterior aprendimos de los nuevos hackeos de coches, la crónica de Stagefright en Android y cómo evitar que te vigilen en Internet (de hecho lo fuimos).

En esta publicación hay dos noticias sin aparente relación; sin embargo, tienen algo en común: y no es que en algún lugar haya alguien sensible a un ataque, sino que esa vulnerabilidad a veces surge de la aversión a adoptar medidas de seguridad disponibles. Y la tercera noticia no es sobre seguridad en absoluto, sino que más bien se refiere en particular a las relaciones dentro de la industria. Estos tres son lo suficientemente divertidos como para ser tan diferentes de lo que parecen

Deja que te recuerde las reglas: los editores de Threatpost escogen tres noticias de las más importantes, a las que yo agrego un comentario amplio y despiadado. Podrás encontrar todos los episodios de la serie aquí.

Hackear puertas de hoteles
La publicación de Threatpost

Dicen que no hay dicotomía entre ciencias y humanidades, y los adeptos a estos dos enfoques difícilmente puede entenderse. Y hay una fuerte creencia de que ningún intelectual humanista puede convertirse en un científico o un ingeniero.

Este estereotipo fue desafiado por John Wiegand, un músico de profesión. En la década de 1930 fue pianista y director de orquesta de un coro de niños, hasta que se interesó por el diseño de amplificadores de audio. En la década de 1940 trabajó en la novedosa grabación de casetes. Y en 1974 (a la edad de sus tantísimos 62 años) hizo su gran descubrimiento.

La interface de Wiegand, como actualmente se conoce, es un alambre de hierro, cobalto y vanadio de aleación magnética tratado de tal manera que conforma un tejido duro exterior alrededor de un núcleo suave interior. Los campos externos magnetizan fácilmente la capa exterior, que también resiste a la desmagnetización, incluso cuando se eliminan los campos externos. Una característica llamada alta coercertividad. Dentro del alambre suave, este tiene un comportamiento diferente, no es magnetizado hasta que la cubierta lo hace.

El momento en que la cubierta del alambre se magnetiza totalmente y el núcleo finalmente obtiene su propia porción de magnetización, tanto el núcleo como la cubierta se polarizan. El interruptor genera cierto voltaje que puede ser aprovechado para todo tipo de aplicaciones de detección y movimiento, haciendo este efecto útil, por ejemplo, en las llaves de hotel.

A diferencia de las tarjetas actuales, el código de “unos y ceros”, no es registrado en el chip, sino en la secuencia del cableado especial establecido. Es imposible re-programar dicha clave o código y el esquema general de la misma no es como la de las actuales tarjetas de proximidad del transporte público por tarifas o las tarjetas bancarias, pero es similar a las de banda magnética, sólo que más confiables.

¿Entonces debemos descartar las tarjetas de proximidad? Aún no. Wiegand dio su nombre, no sólo por el efecto descubierto, sino también por el protocolo de intercambio de datos, el cual es bastante antiguo. Todo en este protocolo es nefasto. En primer lugar, nunca ha sido debidamente estandarizado, y hay muchas implementaciones que varían entre sí.

En segundo lugar, el ID de la tarjeta puede almacenar o guardar hasta 16 bits, dando muy pocas combinaciones posibles. En tercer lugar, el diseño de las tarjetas de proximidad, inventadas mucho antes de saber siquiera cómo poner un ordenador completo en una tarjeta de crédito, limita la longitud de la clave a sólo 37 bits con la certeza de que no aceptará claves mucho más largas.

Así que, la semana pasada los investigadores de Black Hat, Eric Evenchick y Mark Baseggio mostraron un dispositivo (no cifrado) para interceptar las secuencias de claves, durante la verificación de autorización. El detalle más interesante aquí es que las tarjetas no tienen nada que hacer, ya que la información es robada durante la transmisión de datos desde el lector de tarjetas al controlador de puertas, dónde se utiliza la interface de Wiegand históricamente.

El nombre de este dispositivo es BLEkey: una pequeña pieza de hardware que necesita ser integrada en un lector de tarjetas; por ejemplo, en las puertas de un hotel. Los investigadores demostraron que esta operación tarda alrededor de varios segundos. Entonces todo es muy simple. Leemos la llave, esperamos a que el dueño salga y abrimos la puerta. O no esperamos. O nunca abrimos. Sin entrar en detalles técnicos, el diálogo entre la puerta y el lector sucede de la siguiente manera:

“¿Quién está ahí?“

“Soy yo.“

“Oh, eres tú. ¡Entra!“

Todo parece ser bastante claro, pero hay un pequeño matiz. Bueno, como siempre, no todos los sistemas de control de acceso son vulnerables a este ataque. E incluso aquellos que lo son pueden ser protegidos sin tener que ser reemplazados. Según los investigadores, los lectores tienen medios para protegerse de estos hackeos, pero esas características suelen ser, claro está, inhabilitadas.

Algunos incluso siguen el Protocolo abierto de Dispositivos Supervisados, lo que permite cifrar la secuencia de llaves. Estas “funcionalidades” ya no se utilizan. Nunca dejaremos repetir, porque descuidar las medidas de seguridad es barato y fácil.

Aquí hay otro interesante estudio del 2009 sobre el tema, con detalles técnicos. Al parecer la vulnerabilidad de las tarjetas (no los lectores) se puso de manifiesto en 1992, pero luego se sugirió que las tarjetas deben ser desensambladas o examinadas por medio de rayos X. Para conseguirlo, tenían que quitárselas al dueño. Y ahora la solución está en un pequeño dispositivo del tamaño de una moneda. ¡Eso es lo que llamamos progreso!

Inmunidad de Microsoft. Los entresijos corporativos de Windows Server Update Services.

La Historia de Threatpost y las investigaciones originales del libro blanco

Los servicios de actualización en Windows Server permiten a las grandes empresas centralizar la instalación de actualizaciones en sus ordenadores mediante un servidor interno, en lugar de una fuente externa. Y, este es un sistema muy fiable y sobradamente seguro. En primer lugar, todas las actualizaciones deben ser firmadas por Microsoft. En segundo lugar, la comunicación entre el servidor de actualización de la compañía y el servidor del proveedor es cifrado por SSL.

Este sistema es bastante simple. El servidor de la compañía recibe un listado de actualizaciones en un archivo XML, el cual indicaba qué, cómo y dónde descargarlo. Y resultó que esta interacción inicial se envía en texto plano. No, de hecho está mal decirlo de esa manera. Este debe ser cifrado y al implementarlo en WSUS, es muy recomendable un administrador para habilitar el cifrado. Pero este se desactiva por defecto.

No es algo terrible porque el reemplazar las “instrucciones” no es fácil, pero si un atacante ya tiene la capacidad de interceptar el tráfico (a través de la estrategia “man-in -the-middle”), entonces es posible. Los investigadores Paul Stone y Alex Chapman se dieron cuenta que mediante la sustitución de las instrucciones, se puede ejecutar un código arbitrario con privilegios elevados en las actualizaciones del sistema. No, Microsoft sí verifica certificados digitales; sin embargo, este acepta el certificado de cualquier compañía. Por ejemplo, puedes introducir clandestinamente utilidades PsExec desde los kits SysInternals, y con su ayuda, podrías lanzar cualquier cosa.

¿Por qué sucede esto? La cuestión es que a la hora de habilitar un SSL, se necesita generar un certificado para la implementación de WSUS y estos no pueden ser automatizados. Como señalaron los investigadores en este caso, Microsoft simplemente no puede hacer nada sino instar a la activación de SSL. Por lo tanto, parece como si hubiera vulnerabilidad y no la hubiera a la vez. Y no existe ayuda. Y la culpa no es de nadie sino del administrador.

Además, Kaspersky Lab descubrió Flame: un spyware que entra en Windows Update para infectarlo, aunque de una manera diferente. Un proxy falso, interceptaba peticiones al servidor de Microsoft, y los archivos de respuesta enviados eran un poco diferentes, de hecho, algunos de ellos fueron firmados por el proveedor.

Ingeniería inversa y dolor

La publicación de Threatpost. La publicación original de Oracle CSO (el cache de Google y la copia – Internet nunca olvida)

Las citas anteriores presentadas en las conferencias de Black Hat están relacionadas, ya que los autores de estos estudios (los expertos en seguridad), descubrieron fallos en algunas tecnologías o productos desarrollados por otros. Publicaron sus investigaciones y en el caso de BLEKey también presentaron el código completo y el hardware de libre acceso. Esto en general, es la manera más estandarizada de interacción con el mundo exterior en seguridad IT pero no a todo el mundo le gusta esta situación.

No me gustaría valorar, por lo que sería suficiente con decir que este es un tema muy delicado. ¿Está bien analizar el código de otros y en qué condiciones sería correcto? ¿Cómo debemos revelar información vulnerable para no hacer daño? ¿Podemos recibir dinero por los fallos que encontramos? Las restricciones legislativas, el código penal y las leyes aún no escritas en la industria nos afectan a todos.

Una reciente publicación creada por la Directora de Seguridad de Oracle, Mary Ann Davidson creó el efecto de un elefante en una cacharrería. Se titulaba “No, realmente no puedes” y fue dedicado totalmente a los clientes de la empresa (no a la industria en general), quienes enviaron información acerca de la vulnerabilidad en los productos de la compañía.

El texto entero del 10 de agosto de 2015 publicado en el blog de Oracle vale la pena citarlo, pero os dejo lo más importante: si un cliente pudiera aprender sobre vulnerabilidad por ingeniería inversa, entonces el cliente violaría el acuerdo de licencia, y sería un error.

security-week-33-sobchak

Cita:

Un cliente no puede analizar un código para ver si hay un procedimiento que evita un ataque del que la herramienta de escaneo le está avisando (es muy probable que de un falso positivo). Un cliente no puede producir un parche para resolver el problema. Sólo el vendedor puede hacerlo. Un cliente estará violando el acuerdo de licencia al usar una herramienta que hace el análisis estático (que opera en contra del código).

La reacción del público resultó así:

https://twitter.com/nicboul/status/631183093580341248

O así:

O incluso así:

En resumen, la publicación no duró más de un día y se retiró debido a las “inconsistencias en los puntos de vista [oficiales] sobre la interacción con los clientes” (pero Internet no olvida). Recordemos que Oracle desarrolla Java, y sólo los más vagos no explotarían sus vulnerabilidades. Hace tres años te contamos sobre las vulnerabilidades ocurridas de Java durante 12 meses. ¡Encontramos 160!

Quizás en un mundo ideal la búsqueda de vulnerabilidades de software y sus soluciones deberían hacerse exclusivamente por proveedores de software. Pero en un mundo real, ¿no sucede a veces eso de que los responsables de mover los hilos siguen el principio de hacer justo lo contrario?

Pero veamos el otro lado de la historia.

La semana pasada, el fundador de Black Hat, Jeff Moss, habló sobre los proveedores de software como los responsables de las fallos en los códigos. Dijo que es hora de deshacerse de “EULA” (acabar con las políticas de licencia) y de todo aquello dónde se dice que la empresa no tienen ninguna responsabilidad hacia sus clientes. La declaración es interesante, pero no menos pretenciosa que la declaración: “Hay que prohibir desensamblar”. Hasta ahora sólo hay algo claro: si los usuarios (empresas y particulares), proveedores e investigadores no pueden entenderse entre sí, esto no se llevará a cabo por declaraciones llamativas y bromas de Twitter.

¿Qué más sucedió?:

Otra conferencia de Black Hat sobre hackear Square Reader, aquello que conectas en tu smartphone para pagar a un repartidor de sushi. Requiere soldadura.

Rootkit de otro proveedor encontrado en ordenadores portátiles Lenovo (no todos, pero sí algunos). Sobre la historia anterior.

Oldies

La “pequeña” familia del malware

Generalmente los llamados “Virus Residentes” son añadidos al final de los archivos .com (a excepción de Small-114, -118, -122, los cuales aparecen al inicio) cuando se cargan los archivos en la memoria. La mayoría de las familias de virus, utilizan comandos como POPA y PUSHA en procesadores de 80×86. SMALL-132, -149 infecta ciertos archivos de forma incorrecta. Pertenecen a diferentes autores. Al parecer, el origen de la familia “SMALL” puede ser vista como competencia de los “virus residentes” en memoria más corta para los MS-DOS. Sólo queda decidir quién es el ganador.

Citas del libro “Computer viruses in MS-DOS” de Eugene Kaspersky, 1992, página 45.

Legales: Este artículo refleja únicamente la opinión personal del autor. Usted puede coincidir con la posición de Kaspersky Lab, o no. Depende de la suerte.

Consejos
Suscríbete para recibir nuevas publicaciones en tu buzón
  • Para el resto de países