Semana de la seguridad 39: XcodeGhost, el filtrado de certificados D-Link, 1 millón de dólares por los bugs en iOS9

El resumen de noticias semanal cubre las historias de diversos errores de codificación y cómo éstos pueden ser utilizados para distintos propósitos, entre los que se incluye ganar dinero.

Me gustaría comenzar con esta nueva edición de la Semana de la seguridad  con algunas noticias que no tienen mucho que ver con los sistemas de seguridad de la información. Ha aparecido la noticia de que los coches diesel de Volkswagen emiten más gases contaminantes de lo que dicen los tests.

No voy a ponerme demasiado crítico antes de que conozcamos el panorama completo. Esta historia demuestra que el papel del software en el mundo actual es de suma importancia: al parecer, una ligera modificación del código es suficiente para alterar una característica clave sin que nadie se diera cuenta.

De acuerdo con la revista Wired, fue bastante fácil esconder los altos niveles de emisión. ¿Sabes cómo se llevan a cabo las pruebas de laboratorio? El coche se coloca en un dispositivo que imita la conducción por carretera, presiona el acelerador, gira las ruedas y analiza la emisión de gases.

¿Cuál es la diferencia entre estas pruebas de laboratorio y la conducción real? El volante no está en acción. Esto significa que se podría programar con una sola condición: cuando nadie está al volante, eso significa que el vehículo se encuentra en la estación de la ITV. Este truco podría descubrirse por accidente, y así es como creo que ocurrió.

De nuevo, a menos que esto se aclare, la diferencia en el análisis de emisiones de gases puede considerarse tanto intencional, culpando al fabricante de coches (o a un grupo de personas responsables del código), como involuntario. ¿Podría haber sido un error? Desde luego. En el resumen semanal de hoy de Threatpost.com trataremos historias sobre diversos errores de código y cómo éstos pueden ser utilizados para varios propósitos, entre los que se incluye ganar dinero. Pincha aquí para leer otras historias.

D-Link revela sus propios certificados digitales por error

La noticia. Tweakers.net, una página web holandesa, publica una investigación detallada, adornada con mucho Google Traductor.

Imagina que eres productor de diversos dispositivos de red, desde routers hasta cámaras de vigilancia. Acompañas tu equipo con firmware, controladores, software, software de actualización del firmware, software de actualización del controlador, etc. Todo se almacena en alguna carpeta de “flujo de trabajo” en un servidor secreto. Todo se actualiza, se distribuye, se sube a servidores actualizados según lo programado, luego los cambios se marcan, y por últimos los usuarios obtienen sus actualizaciones. Sencillo, ¿eh?

 

No hace falta decir que no se puede gestionar manualmente todo el inventario de hardware, esto lo hacen los scripts. Bien, tenemos un nuevo código, ejecutamos un archivo .bat (Shell script, o Python, o el que sea), entonces el código se distribuye entre las carpetas designadas, todo se archiva, y todos contentos.

Y este es Jack el ingeniero, quien decidió mejorar radicalmente el script probándolo en un par de casos con resultados satisfactorios. Y este es el error que creó Jack. Sólo una línea, del código responsable de seleccionar los archivos o carpetas de actualización apropiados, que simplemente no incluía un guión o un paréntesis adicional. Y ahora los datos que recopilabas querido amigo, se han filtrado pasando a formar parte del dominio público y se han enviado por correo electrónico a innumerables usuarios.

Bueno, por supuesto, no puedo afirmarlo al 100 %. Puede que no sea exactamente así. Pero esto es lo que sucedió: un usuario cauteloso, que acababa de descargar la actualización del firmware de su cámara D-Link, se dio cuenta de que el archivo contenía las claves privadas para acceder al software del proveedor. Había diversos certificados en el archivo, algunos obsoletos, pero uno de ellos expiraba el día 3 de septiembre, no hace mucho tiempo.

Pero antes de esa fecha, la clave había estado expuesta durante seis meses y podría haber sido utilizada para introducir cualquier software, y, por consiguiente, malware. Fue un error evidente, vergonzoso y peligroso. Ahora estamos viviendo en una época en la que una secuencia de 512 números puede incluir cualquier cosa: una clave necesaria para infectar millones de ordenadores, un montón de dinero en divisas virtuales o un código de acceso a la información clasificada.

Pero, al mismo tiempo 512 bytes son pequeños granos de arena en el océano de tu disco duro, susceptibles de ser expuestos al dominio público. La única esperanza que tenemos es que nadie se haya dado cuenta del error, que es lo que suele pasar. Pero a veces alguien localiza el error, como en este caso, aunque aún no se ha encontrado ningún malware que se haya aprovechado de ninguna de las claves expuestas.

XcodeGhost un marcador en el entorno de desarrollo integrado de Apple

La noticia. La investigación de Palo Alto. La lista de las aplicaciones afectadas. La declaración oficial de Apple (en chino, por desgracia).

Imagina que eres un desarrollador chino de aplicaciones para iOS. Nada especial, ya que los kits y las herramientas de desarrolladores son iguales para todos ellos independientemente del país. Sólo añade alguna que otra peculiaridad geográfica. Por ejemplo, imagina que compras un nuevo Mac, instalas un marco Xcode y empiezas a programar.

Esto está bien, excepto por un detalle: si lo descargas desde la página web oficial de Apple, el marco Xcode gratuito se descarga muy lentamente, ¡gracias a la Gran Muralla! La manera más rápida y sencilla de descargarlo es desde una página web local, de todas formas, ¿cuál es la diferencia? Es gratuito de todos modos.

Entonces, como salidas de la nada, algunas aplicaciones (tanto las populares como las que no lo son tanto) tienen una inyección de código malicioso, que (¡por lo menos!) envía los datos sobre el dispositivo a un servidor C&C remoto. En el peor de los casos, el dispositivo acepta las órdenes del servidor, que comprometen al usuario y explotan las vulnerabilidades de iOS.

Resulta que el malware estaba oculto en las versiones locales de Xcode y afectó a varios lanzamientos. Eso significa que alguien lo creó a propósito. Aún puede ser peor: no se trata solamente de que algunas aplicaciones populares como WeChat IM o la versión local de Angry Birds estén comprometidas, se trata de un código malicioso que ha conseguido burlar los controles de la App Store.

Por supuesto, todas las aplicaciones infectadas ya han sido eliminadas y el código malicioso en sí es bastante fácil de encontrar por los nombres de dominio de los servidores C&C (que también han sido bloqueados). Pero sin conocimiento previo, el malware es bastante difícil de encontrar: estaba escondido de forma muy inteligente en las bibliotecas estándar de Apple, que se utilizan en el 99,9 % de las aplicaciones.

Hay otro dato curioso. La revista The Intercept, especializada en la información secreta disponible tras las revelaciones de Snowden, declara que el método usado por XcodeGhost para infiltrarse en los dispositivos de Apple, coincide con los métodos descritos en los planes secretos del gobierno. Los periodistas afirmaron, presumiendo de ello, que revelaron esta información el pasado marzo.

Pues bien, nosotros también podemos alardear, pues fuimos los primeros en saberlo, en el 2009, incluso antes de que ocurriera lo de Snowden. Por ejemplo, encontramos malware que infectó el entorno de desarrollo integrado de Delphi e insertó un código malicioso en todas las aplicaciones compiladas. La idea es obvia. Pero, una vez más, en cuanto eres consciente del problema, puedes deshacerte de él fácilmente, simplemente hay que confrontar la integridad de la herramienta de desarrollo con la versión principal.

De todas formas, aquí va una sencilla recomendación: no descargar software de fuentes cuestionables. Suena algo extraño ya que aquí estamos hablando de desarrolladores experimentados. ¿Pueden cometer realmente estos errores? Bueno, resulta que sí pueden.

Un broker anuncia una recompensa de 1 millón de dólares por los bugs en iOS 9

La noticia.

Hay un interesante tema sobre la historia del Jailbreak de varios dispositivos iOS. A diferencia de Android o los sistemas operativos de escritorio, en los que el control integral sobre el sistema, por lo general, se activa por defecto, por lo que se puede explotar fácilmente, los smartphones de Apple, tablets, (y ahora también los decodificadores o receptores de televisión y los smartwatches) tienen permisos de usuario limitados por naturaleza.

Ya han pasado siete años desde que el conocido proveedor han estado intentando cercar proteger sus dispositivos por un lado y los entusiastas intentando eludir esta protección, por otro lado. Al final, a la mayoría de los dispositivos de Apple se les ha hecho Jailbreak (excepto Apple TV v3, y, al menos por ahora, Apple Watch). Por lo general, el tiempo varía de un día a seis meses desde que el producto llega a las estanterías.

Ya se le ha hecho Jailbreak al nuevo iOS 9, pero, al mismo tiempo, no. No se ha hecho del todo. El encargado de cuidar de este problema es Zerodium que ha anunciado una recompensa de 1 millón de dólares por el método que explote iOS 9, siempre que:

  • El exploit sea remoto (por lo que funciona automáticamente cuando un usuario visita una página web modificada o lee un SMS o un MMS malicioso);
  • El exploit permita la carga lateral de aplicaciones arbitraria (como en el caso de Cydia);
  • El exploit sea lo suficientemente persistente y continúe operativo tras el reinicio;
  • El exploit sea “fiable, discreto y no necesite que el usuario realice ninguna acción”

Esta lista muestra que Zerodium no tiene en mente desperdiciar 3 millones de dólares (cantidad total de la recompensa) sólo para complacer a los entusiastas. Chaouki Bekrar, el fundador de Zerodium, fue inicialmente el fundador de VUPEN. Esta última compañía está especializada en la venta de las vulnerabilidades y exploits para los actores estatales. Es una zona oscura del mundo de la seguridad de la información, tanto desde el punto de vista legal como del punto de vista moral: los buenos persiguen a los malos usando sus propias herramientas.

Mientras VUPEN (al menos oficialmente) no se mete con la caza de bugs, Zerodium fue creado inicialmente con ese objetivo. Eso significa que alguien ganará el premio gordo, alguien se dedicará a introducirse en los dispositivos mediante la compra de exploits y sin revelar detalles de las vulnerabilidades (de lo contrario, ¿qué sentido tiene ofrecer una recompensa?).

Pero ya sabemos lo que ocurre cuando los propios brokers de bugs son hackeados. Recordemos el Hacking Team, cuando varios ataques de día cero terminaron siendo de dominio público, además del descubrimiento de algunos negocios sucios entre la empresa y varios estados del Medio Oriente, vamos, un gran fiasco.

La moraleja aquí es que si alguien tiene ganas de hacer Jailbreak a su smartphone, es libre de hacerlo (o, igual no tanto). Pero hacer Jailbreak a un dispositivo ajeno sin el consentimiento de su propietario no es nada bueno y, en cuanto se descubre una posibilidad de hacerlo, se debe compartir esta información con el proveedor para que sea parcheado. No hay ninguna excusa para lanzar exploits, aunque sea por una buena casa.

Qué más ha ocurrido:

Adobe parcheó 23 vulnerabilidades en Flash Player. En agosto se parchearon 30 bugs más.

La OPM informó sobre consecuencias aún más graves de la brecha masiva que tuvo lugar este año: las huellas dactilares de más de 5,6 millones de empleados de agencias federales se vieron comprometidas. Los analistas señalan que la huella dactilar no es tan fácilmente reemplazable como una contraseña que se ha visto comprometida, y donde el número de combinaciones es muy limitado. Ahora, ya no se puede hacer casi nada respecto a esta brecha, pero nadie sabe de qué será capaz la tecnología del futuro.

https://twitter.com/jpluscplusm/status/646811379312279552

Oldies:

“Imprimir pantalla”

Un virus muy peligroso, que ocupa 512 bytes (un sector) e infecta el sector de arranque de los disquetes y discos duros al leerlos (int 13h). El antiguo sector de arranque, escribe a la dirección 1/0/3 (lado/pista/sector) en una unidad de disco flexible, y en la dirección 3/1/13 del disco duro. Puede corromper uno de los sectores FAT o de los datos almacenados (dependiendo de la capacidad de la unidad). Al infectar un disco duro, su sector de arranque se almacena en la dirección de 0/1/1 (mostrando el poco dominio del codificador que creó el virus).

También se introduce en int 13h. A juzgar por la lista del virus cuando infecta la unidad con una tasa de probabilidad del 1/256 (en función del valor de su contador interno), el virus debe llamar a int 5 (Imprimir pantallainfosec-digest-32-book1), pero debido a un error del nuevo valor del contador no se guarda.

Citado de “Virus informáticos en MS-DOS”, de Eugene Kaspersky, 1992. Pág. 102. 

Aviso legal: 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