En días pasados corrían por la red reportes de ataques que aprovechan una vulnerabilidad en PHP, que permite que algunos sitios legítimos sirvan páginas web y anuncios fraudulentos, exponiendo a los visitantes a la instalación de malware en sus ordenadores. Estos ataques aprovechan una vulnerabilidad extremadamente crítica de PHP expuesta públicamente hace ya 22 meses y para la que se han liberado las actualizaciones correspondientes.
Algunos han comenzado a señalar con insistencia que una buena parte de los servidores comprometidos en estos ataques está corriendo versiones de GNU/Linux, pretendiendo cuestionar la seguridad de este Sistema Operativo, pero sin entrar en detalles sobre la naturaleza de la vulnerabilidad ni las razones por las cuales ha sucedido esto.
Los sistemas con GNU/Linux infectados, en todos los casos, están corriendo la versión 2.6 del kernel de Linux, liberado en 2007 o anteriores. En ningún caso se menciona la infección de sistemas corriendo kernels superiores o que hayan sido debidamente actualizados; pero claro, aún existen administradores que piensan “… si no está roto, no necesita arreglo” y luego pasan estas cosas.
Por otra parte, un reciente estudio de la firma de seguridad ESET, expone en detalle la llamada “Operación Windigo”, en la que mediante varios kits de ataque, entre ellos uno llamado Cdorked especialmente diseñado para Apache y otros populares servidores web de código abierto, así como otro llamado Ebury SSH, han sido comprometidos más de 26,000 sistemas GNU/Linux desde Mayo del pasado año, ¿Acaso significa esto que GNU/Linux ha dejado de ser seguro?
Primero que todo, poniendo las cosas en contexto, si comparamos los números anteriores con los casi 2 millones de equipos con Windows comprometidos por el bootnet ZeroAccess antes de ser cerrado en Diciembre del 2013, es fácil concluir que, en cuanto a seguridad, los sistemas con GNU/Linux siguen siendo más seguros que los que utilizan el Sistema Operativo de Microsoft, pero ¿Es culpa de GNU/Linux que 26,000 sistemas con ese SO hayan sido comprometidos?
Como en el caso de la vulnerabilidad crítica de PHP comentada anteriormente, que afecta a sistemas sin actualizaciones en su kernel, estos otros ataques involucran sistemas en los que no se cambió el usuario y/o contraseña por defecto y que mantenían los puertos 23 y 80 innecesariamente abiertos; entonces ¿Realmente es culpa de GNU/Linux?
Evidentemente, la respuesta es NO, el problema no es el SO que se utilice si no la irresponsabilidad y dejadez de los administradores de esos sistemas que no acaban de entender la máxima enunciada por el experto en seguridad Bruce Schneier que debería estar grabada a fuego en nuestrios cerebros: La seguridad ES un proceso NO es un producto.
De nada vale que instalemos un sistema probadamente seguro si luego lo dejamos abandonado y no instalamos las actualizaciones correspondientes tan pronto son liberadas. De igual manera, de nada vale mantener actualizado nuestro sistema si continúan en uso las credenciales de autenticación que aparecen por defecto durante la instalación. En ambos casos, se trata de elementales procedimientos de seguridad, que no por repetidos, son aplicados debidamente.
Si tienes bajo tu cuidado algún sistema GNU/Linux con Apache u otro servidor web de código abierto y quieres comprobar si ha resultado comprometido, el procedimiento es sencillo. Para el caso de Ebury, debes abrir un terminal y escribir el siguiente comando:
ssh -G
Si la respuesta es distinta a:
ssh: illegal option – G
y luego el listado de opciones correctas para ese comando, entonces tu sistema está comprometido.
Para el caso de Cdorked, el procedimiento es un poquito más complicado. Debes abrir un terminal y escribir:
curl -i http://myserver/favicon.iso | grep "Location:"
Si tu sistema estuviera comprometido, entonces Cdorked redireccionará la solicitud y te dará la siguiente salida:
Location: http://google.com
Caso contrario, no te retornará nada o una localización diferente.
La forma de desinfección puede parecer burda, pero es la única probada como efectiva: borrado completo del sistema, reinstalación desde cero y reseteo de todas las credenciales de usuario y administrador desde una terminal no comprometida. Si te parece trabajoso, piensa que, de haber cambiado oportunamente las credenciales, no hubieras comprometido el sistema.
Para un análisis mucho más detallado de las formas de operar de estas infecciones, así como las formas específicas utilizadas para expandir las mismas y las correspondientes medidas a tomar, sugerimos la descarga y lectura del análisis completo de la “Operación Windigo” disponible en el siguiente enlace:
Por último, una conclusión fundamental: No existe Sistema Operativo garantizado contra administradores irresponsables o descuidados; en cuanto a seguridad, siempre hay algo que hacer, pues el primer y más grave error consiste en pensar que ya la hemos alcanzado, ¿o acaso no lo crees así?
Continúar leyendo...
Algunos han comenzado a señalar con insistencia que una buena parte de los servidores comprometidos en estos ataques está corriendo versiones de GNU/Linux, pretendiendo cuestionar la seguridad de este Sistema Operativo, pero sin entrar en detalles sobre la naturaleza de la vulnerabilidad ni las razones por las cuales ha sucedido esto.
Los sistemas con GNU/Linux infectados, en todos los casos, están corriendo la versión 2.6 del kernel de Linux, liberado en 2007 o anteriores. En ningún caso se menciona la infección de sistemas corriendo kernels superiores o que hayan sido debidamente actualizados; pero claro, aún existen administradores que piensan “… si no está roto, no necesita arreglo” y luego pasan estas cosas.
Por otra parte, un reciente estudio de la firma de seguridad ESET, expone en detalle la llamada “Operación Windigo”, en la que mediante varios kits de ataque, entre ellos uno llamado Cdorked especialmente diseñado para Apache y otros populares servidores web de código abierto, así como otro llamado Ebury SSH, han sido comprometidos más de 26,000 sistemas GNU/Linux desde Mayo del pasado año, ¿Acaso significa esto que GNU/Linux ha dejado de ser seguro?
Primero que todo, poniendo las cosas en contexto, si comparamos los números anteriores con los casi 2 millones de equipos con Windows comprometidos por el bootnet ZeroAccess antes de ser cerrado en Diciembre del 2013, es fácil concluir que, en cuanto a seguridad, los sistemas con GNU/Linux siguen siendo más seguros que los que utilizan el Sistema Operativo de Microsoft, pero ¿Es culpa de GNU/Linux que 26,000 sistemas con ese SO hayan sido comprometidos?
Como en el caso de la vulnerabilidad crítica de PHP comentada anteriormente, que afecta a sistemas sin actualizaciones en su kernel, estos otros ataques involucran sistemas en los que no se cambió el usuario y/o contraseña por defecto y que mantenían los puertos 23 y 80 innecesariamente abiertos; entonces ¿Realmente es culpa de GNU/Linux?
Evidentemente, la respuesta es NO, el problema no es el SO que se utilice si no la irresponsabilidad y dejadez de los administradores de esos sistemas que no acaban de entender la máxima enunciada por el experto en seguridad Bruce Schneier que debería estar grabada a fuego en nuestrios cerebros: La seguridad ES un proceso NO es un producto.
De nada vale que instalemos un sistema probadamente seguro si luego lo dejamos abandonado y no instalamos las actualizaciones correspondientes tan pronto son liberadas. De igual manera, de nada vale mantener actualizado nuestro sistema si continúan en uso las credenciales de autenticación que aparecen por defecto durante la instalación. En ambos casos, se trata de elementales procedimientos de seguridad, que no por repetidos, son aplicados debidamente.
Si tienes bajo tu cuidado algún sistema GNU/Linux con Apache u otro servidor web de código abierto y quieres comprobar si ha resultado comprometido, el procedimiento es sencillo. Para el caso de Ebury, debes abrir un terminal y escribir el siguiente comando:
ssh -G
Si la respuesta es distinta a:
ssh: illegal option – G
y luego el listado de opciones correctas para ese comando, entonces tu sistema está comprometido.
Para el caso de Cdorked, el procedimiento es un poquito más complicado. Debes abrir un terminal y escribir:
curl -i http://myserver/favicon.iso | grep "Location:"
Si tu sistema estuviera comprometido, entonces Cdorked redireccionará la solicitud y te dará la siguiente salida:
Location: http://google.com
Caso contrario, no te retornará nada o una localización diferente.
La forma de desinfección puede parecer burda, pero es la única probada como efectiva: borrado completo del sistema, reinstalación desde cero y reseteo de todas las credenciales de usuario y administrador desde una terminal no comprometida. Si te parece trabajoso, piensa que, de haber cambiado oportunamente las credenciales, no hubieras comprometido el sistema.
Para un análisis mucho más detallado de las formas de operar de estas infecciones, así como las formas específicas utilizadas para expandir las mismas y las correspondientes medidas a tomar, sugerimos la descarga y lectura del análisis completo de la “Operación Windigo” disponible en el siguiente enlace:
Por último, una conclusión fundamental: No existe Sistema Operativo garantizado contra administradores irresponsables o descuidados; en cuanto a seguridad, siempre hay algo que hacer, pues el primer y más grave error consiste en pensar que ya la hemos alcanzado, ¿o acaso no lo crees así?
Continúar leyendo...