Semana de la seguridad 34: No es tan fácil parchar…

Puede haber miles de razones para no parchear un bug de forma inmediata, o en el próximo trimestre, o en algún momento. Sin embargo, este es un problema que hay que resolver.

Amigos, ésta ha sido una semana horrible para la industria de la seguridad informática. Tras una entretenida semana de descubrimiento de bugs, ataques de día-cero y otras curiosidades de investigadores codiciados, aquí vienen las dolorosas consecuencias de ver todo esto infiltrado en software vulnerable. Esto es muy importante, pero a su vez es algo aburrido. Cada vez que nuestro blog de ​​noticias, Threatpost, me provee de noticias frescas sobre la industria de la seguridad y aparecen los titulares de tres artículos sobre parches, se me ponen los pelos de punta. Este resumen es duro de digerir.

Bueno, ¡este es un tema muy importante! No es fácil encontrar una vulnerabilidad, pero es aún más difícil parcharla sin destrozarlo todo. Puede haber miles de razones para no parchar un bug de forma inmediata, o en el próximo trimestre, o en algún momento. Sin embargo, este es un problema que hay que resolver.

En los titulares de hoy aparecen tres noticias sobre bugs que desgraciadamente permanecen sin parchar. Una vez más, como cada semana, el equipo de Threatpost  ha elegido personalmente tres de las noticias más importantes y yo voy a comentarlas. Puedes encontrar las ediciones anteriores aquí.

<h3>Otro bug en Android, ahora en Google Admin</h3>

La noticia en Threatpost. Investigación de MWR.

<em>¿Qué se ha descubierto?</em>

¿Te has dado cuenta de que estas “fantásticas” noticias sobre bugs llegan en masa  últimamente? ¡Por dios! ¿Han hackeado un coche? ¡Vamos a buscar otras tantas brechas de seguridad en coches! Podemos observar el mismo patrón en las últimas noticias sobre Android. Primero sucedió lo de Stagefright, luego se descubrieron un par de pequeños bugs y ahora tenemos lo de Google Admin y Cadena Perpetua y la fuga de la sandbox.

security-week-34-kidGoogle Admin, una de las aplicaciones a nivel del sistema, puede aceptar enlaces URL de otras aplicaciones, y, al parecer, cualquier URL funciona, incluso aquellas que empiezan por “file://”. Como resultado, algo tan común en un entorno de trabajo como la descarga de páginas web, se desarrolla como una especie de administrador de archivos. ¿No están todas las aplicaciones de Android aisladas entre sí? ¡Pues no! Google Admin goza de mayores privilegios, y engañándola para que lea URL corruptas, una app puede escapar de la sandbox y acceder a los datos privados.

<em>¿Cómo se ha parcheado?</em>

En primer lugar, tengo que hablar sobre la forma en la que se divulgó esta vulnerabilidad. Fue descubierta sobre el mes de marzo, con su correspondiente advertencia a Google. Cinco meses después, los investigadores volvieron a analizar lo que ocurrido y vieron que el bug seguía sin ser parchado. Finalmente, el 13 de agosto se divulgó públicamente esta información, presionando a Google para que lanzara el parche.

Por cierto, Google cuenta con un equipo interno de investigadores que dedican su tiempo y esfuerzo a buscar bugs en todas partes, no sólo en su propio software. El Proyecto Cero de Google permite un margen de 90 días hasta hacer público un bug, aunque da qué pensar en si Google es capaz de parcharse con un margen de 90 días.

Pero con Google Admin, algo ha ido realmente mal: en primer lugar, algo en efecto no estaba bien; en segundo lugar, todos sabemos que parchando no se solucionan todas las vulnerabilidades en los dispositivos Android. Se habló de lanzar actualizaciones de seguridad mensuales, pero… ¿Y los seis meses que han estado trabajando en este parche? Oiga, oiga.

security-week-34-kitten

<h3>Vulnerabilidades abiertas en SCADA, de Schneider Electric</h3>

La noticia en Threatpost, la advertencia de  ICS-CERT.

¡Bienvenidos al fascinante mundo de las infraestructuras críticas! Por favor, siéntese, póngase cómodo, no toque ese alarmante botón rojo y manténgase alejado de esos cables que sobresalen de esa cosa. Sí, se supone que tienen que sobresalir, está bien, no pasa nada, han estado así durante años. En cuanto lo toque, estamos perdidos.

Los sistemas SCADA son una parte de las infraestructuras críticas y se encargan de cosas importantes como los calentadores de tu edificio o incluso de las centrales nucleares. Estos sistemas no están preparados para ser manipulados o desconectados, ni para restablecer su configuración. No juegues con ninguno de los parámetros, simplemente, ¡no toques nada!

Si tienes preguntas, lo mejor es que leas nuestro artículo sobre este tema, ¡no intentes hacerlo por tu cuenta!
A su vez, debemos admitir que, a pesar de que esos sistemas son muy críticos, se implementan con mucha frecuencia en ordenadores domésticos con versiones de Windows bastante anticuadas. A diferencia de las típicas empresas, que actualizan o reemplazan su hardware y software al menos una vez cada cinco años aproximadamente, un robot para instalaciones industriales o un centrifugador que sirva para mantener alejados los productos químicos mortales, podría operar con el mismo hardware las 24 horas del día, 7 días a la semana, durante décadas.

¿Qué se ha descubierto?

Se han encontrado una gran cantidad de bugs en el sistema Modicon M340 de Schneider Electric’s PLC Station P34 CPU (¡ah, qué romántico!). En pocas palabras, esta serie de vulnerabilidades permitiría a una persona externa tener el control de… bueno, básicamente, cualquier cosa que el sistema controle. Aquí se encontró un error muy corriente (y que se encuentran con frecuencia en una serie de routers y otras cosas relacionadas con el Internet de las Cosas) al que llamamos “credenciales de fuerte cifrado”.

¿Cómo se ha parchado?

No lo ha sido. Ya han pasado dos semanas desde que el investigador Aditya Sood presentó esta vulnerabilidad en la conferencia DEF CON, sin embargo, el lanzamiento de un parche no está próximo. Es bastante comprensible: los proveedores se enfrentan a una tarea complicada, ya que no es nada fácil parchear software vulnerable, y se vuelve aún más difícil teniendo que compensar a los clientes por las pérdidas significativas provocadas por el tiempo de inactividad que, muchas veces, no se pueden permitir.

Por lo tanto, ¿cuánto se tardaría en lanzar el parche? ¿Por cuánto tiempo se suspenderían las operaciones? ¿Funcionará bien tras el parche? ¿Se han considerado todas las peculiaridades de los dispositivos Endpoint? Todo esto produce un verdadero dolor de cabeza, sin embargo, se trata de una sola excusa para no parchar los bugs/fallos. Se ha probado en numerosas ocasiones que desconectar de Internet la infraestructura crítica o protegerla mediante un firewall no es una solución.

security-week-34-keynote[Nota al pie: Los desarrolladores en la presentación]

Un bug sin parchear en Mac OS X

La noticia de Threatpost.

Otra vez volvemos al tema de la responsabilidad de divulgación. En el caso del bug de Google, los investigadores esperaron cinco meses antes de hacerlo público, a pesar de que el propio Google limita el tiempo de divulgación de esta información a 90 días. Realmente, ¿cuánto tiempo se debería esperar? ¿Cuánto tiempo deberíamos conceder a los desarrolladores para que puedan solucionar una brecha considerable?

¿No sería contraproducente darles demasiado tiempo a los desarrolladores para que puedan seguir retrasando el lanzamiento del parche? ¿No encontrarían mayor motivación los desarrolladores para lanzar rápidamente un parche si se publicara la vulnerabilidad de forma inmediata? De todos modos, no hay un tiempo determinado para hacerlo, aunque todo el mundo está de acuerdo en que no está bien divulgar el bug sin previo aviso al desarrollador.

¿Qué se ha descubierto?

He aquí un buen ejemplo de un caso en el que no se le notificó a los desarrolladores, o se hizo, pero a muy corto plazo, por lo que no tuvieron el tiempo suficiente para reaccionar…. Luca Todesco, un investigador de 18 años, publicó información sobre una vulnerabilidad grave en Mac OS X Yosemite y Mavericks (10.9.5 – 10.10.5), que permite obtener privilegios de administrador en el dispositivo expuesto.

No se puede ejecutar el bug de forma remota: el hacker debe atraer al usuario  para que se descargue y ejecute el exploit, algo que sin duda debería ser capaz de hacer. También está disponible la prueba de concepto disponible, simplemente tómala y úsala.

¿Cómo ha sido parcheado?

Bueno, aún no lo ha sido. Según el investigador, aunque lo intentó varias veces, no obtuvo respuesta de Apple. No le preocupa el hecho de haber hecho pública la vulnerabilidad: según afirma, él sólo exploró una nueva forma de jailbreaking (realizar modificaciones no autorizadas de iOS), eso es todo. No es gran cosa.

https://twitter.com/qwertyoruiop/status/632966294804017153

Bueno, ésta no es una buena comparación: jailbreaking es algo a lo que los usuarios, que son conscientes de lo que están haciendo, se exponen voluntariamente. No se puede forzar a un usuario de iPhone a que haga jailbreak en su dispositivo, a menos que el usuario lo consienta. Esto no siempre ocurre, como en el caso del bug de Todesco. No es de extrañar que haya chocado con las duras críticas de sus compañeros:

No está claro si el bug recién descubierto afecta al nuevo Mac OS X El Capitán. Estoy deseando que llegue el parche.

¿Qué más?

Microsoft parcheó un bug en Internet Explorer (bueno, al menos alguien ha arreglado algo) mediante la emisión urgente de un parche fuera de banda, el segundo de este este mes.

Unos hackers han robado la información privada de Ashley Madison, la página web de citas para personas casadas, y ahora circulan por la red, como prometieron los que se proclamaron como artífices del hackeo.

https://twitter.com/kaspersky/status/634349398198218752

Kaspersky Lab descubrió Blue Termite, una importante campaña de inteligencia cibernética que ya ha dejado un gran número de víctimas en Japón. No ha pasado desapercibido el hecho de que los ciberespías, que llevan en funcionamiento durante más de dos años, han  intensificado su actividad este verano, en cuanto han tenido acceso a un exploit de Flash que se ha filtrado junto a algunos datos robados de The Hacking Team.

Oldies:

“Justicia”

Muy peligroso; afecta a los archivos .COM relacionados con las funciones DOS 43h DOS, 4Bh, 3Dh yinfosec-digest-32-book1-234x300 56h. El malware se escribe al final de los archivos y alterna 5 bytes al principio (NOP; NOP; JMP Loc_Virus). El proceso de compromiso COMMAND.COM utiliza el mismo método que el virus Lehigh. Con frecuencia, extrae información escrita en el disco y la reescribe en otra parte. Contiene el texto: “And Justice For All”. Robos int 13h y 21h int.

Citas del libro “Computer viruses in MS-DOS” de Eugene Kaspersky, 1992, página 72.
Legales: Este párrafo 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 y recibe nuestras publicaciones en tu correo
  • Para el resto de países