Durante los últimos años los servidores web se han convertido en una
excelente fuente de diversión para piratas: cualquier empresa que se precie,
desde las más pequeñas a las grandes multinacionales, tiene una página
web en las que al menos trata de vender su imagen corporativa. Si hace
unos años un pirata que quisiera atacar a una empresa (y no a todas, ya que
muy pocas tenían representación en la red) tenía que agenciarselas
para obtener primero información de la misma y después buscar errores de
configuración más o menos comunes de sus sistemas (o esperar al próximo
bug de sendmail), hoy en día le basta con teclear el nombre
de su objetivo en un navegador y añadir la coletilla `.com' detrás
del mismo para contactar con al menos una de sus máquinas: su servidor web.
Los ataques a las páginas web de una organización son casi siempre
los más `vistosos' que la misma puede sufrir: en cuestión de minutos piratas
de todo el mundo se enteran de cualquier problema en la página web
principal de una empresa más o menos grande pueda estar sufriendo, y si se
trata de una modificación de la misma incluso existen recopilatorios de
páginas `hackeadas'. Por supuesto, la noticia de la modificación
salta inmediatamente a los medios, que gracias a ella pueden rellenar alguna
cabecera sensacionalista sobre `los piratas de la red', y así se consigue
que la imagen de la empresa atacada caiga notablemente y la del grupo de piratas
suba entre la comunidad 'underground' nacional o internacional.
La mayor parte de estos ataques tiene éxito gracias a una configuración
incorrecta del servidor o a errores de diseño del mismo: si se trata de
grandes empresas, los servidores web suelen ser bastante complejos (alta
disponiblidad, balanceo de carga, sistemas propietarios de actualización de
contenidos...) y difíciles de administrar correctamente, mientras que
si la empresa es pequeña es muy posible que haya elegido un servidor web simple en su instalación y administración pero en el cual es casi
(>casi?) imposible garantizar una mínima seguridad: sí, hablamos de
Microsoft Internet Information Server, un sistema que reconocidos expertos
en seguridad han recomendado públicamente no utilizar en entornos
serios. Sea por el motivo que sea, la cuestión es que cada día es más
sencillo para un pirata ejecutar órdenes de forma remota en una máquina, o
al menos modificar contenidos de forma no autorizada, gracias a los servidores
web que un sistema pueda albergar.
Cualquier analizador de vulnerabilidades que podamos ejecutar contra nuestros
sistemas (NESSUS, ISS Security Scanner, NAI CyberCop
Scanner...) es capaz de revelar información que nos va a resultar útil
a la hora de reforzar la seguridad de nuestros servidores web; incluso
existen analizadores que están diseñados para auditar únicamente este
servicio, como whisker. Ejecutando este último contra una máquina
podemos obtener resultados similares a los siguientes:
anita:~/security/whisker$ ./whisker.pl -h luisa
-- whisker / v1.4.0 / rain forest puppy / www.wiretrip.net --
= - = - = - = - = - =
= Host: luisa
= Server: Apache/1.3.19 (Unix) PHP/4.0.4pl1 mod_ssl/2.8.2 OpenSSL/0.9.5a
+ 200 OK: HEAD /docs/
+ 200 OK: HEAD /cgi-bin/Count.cgi
+ 200 OK: HEAD /cgi-bin/textcounter.pl
+ 200 OK: HEAD /ftp/
+ 200 OK: HEAD /guestbook/
+ 200 OK: HEAD /usage/
anita:~/security/whisker$
Podemos ver que el servidor nos proporciona excesiva información sobre su
configuración (versión, módulos, soporte SSL...), y que la herramienta
ha obtenido algunos archivos y directorios que pueden resultar interesantes
para un atacante: en el caso de los CGI no tiene más que acercarse a
alguna base de datos de vulnerabilidades (especialmente recomendables son
http://www.securityfocus.com/ o http://icat.nist.gov/) e introducir en
el buscador correspondiente el nombre del archivo para obtener información
sobre los posibles problemas de seguridad que pueda presentar. El caso de los
directorios es algo diferente, pero típicamente se suele tratar de nombres
habituales en los servidores que contienen información que también puede
resultarle útil a un potencial atacante.
>Cómo evitar estos problemas de seguridad de los que estamos hablando? Una
medida elemental es eliminar del servidor cualquier directorio o CGI de
ejemplo que se instale por defecto; aunque generalmente los directorios
(documentación, ejemplos...) no son especialmente críticos, el caso
de los CGIs es bastante alarmante: muchos servidores incorporan programas
que no son ni siquiera necesarios para el correcto funcionamiento del software, y que en ciertos casos - demasiados - abren enormes agujeros de
seguridad, como el acceso al código fuente de algunos archivos, la lectura de
ficheros fuera del DocumentRoot, o incluso la ejecución remota de
comandos bajo la identidad del usuario con que se ejecuta el demonio servidor.
Otra medida de seguridad básica es deshabilitar el Directory Indexing
que por defecto muchos servidores incorporan: la capacidad de obtener el
listado de un directorio cuando no existe un fichero index.html o similar
en el mismo; se trata de una medida extremadamente útil y sobre todo sencilla
de implantar, ya que en muchos casos un simple `chmod -r' sobre el
directorio en cuestión es suficiente para evitar este problema. A primera
vista esta medida de protección nos puede resultar curiosa: a fin de cuentas,
a priori todo lo que haya bajo el Document Root del servidor ha de
ser público, ya que para eso se ubica ahí. Evidentemente la teoría
es una cosa y la práctica otra muy diferente: entre los ficheros de cualquier
servidor no es extraño encontrar desde archivos de log - por ejemplo,
del cliente FTP que los usuarios suelen usar para actualizar remotamente
sus páginas, como WS/SMALL>_FTP.LOG - hasta paquetes TAR con el
contenido de subdirectorios completos. Por supuesto, la mejor defensa contra
estos ataques es evitar de alguna forma la presencia de estos archivos bajo el
Document Root, pero en cualquier caso esto no es siempre posible, y si un
atacante sabe de su existencia
puede descargarlos, obteniendo en muchos casos información realmente útil
para atacar al servidor (como el código de ficheros JSP, PHP, ASP...o simplemente rutas absolutas en la máquina), y una excelente
forma de saber que uno de estos ficheros está ahí es justamente el Directory Indexing; por si esto no queda del todo claro, no tenemos más que
ir a un buscador cualquiera y buscar la cadena `Index of /admin', por
poner un ejemplo sencillo, para hacernos una idea de la peligrosidad de este
error de configuración.
Además, en cualquier servidor web es muy importante el usuario bajo
cuya identidad se ejecuta el demonio httpd: ese usuario no debe ser nunca el root del sistema (evidente), pero tampoco un usuario genérico
como nobody; se ha de tratar siempre de un usuario dedicado y sin acceso
real al sistema. Por supuesto, las páginas HTML (los ficheros planos,
para entendernos) nunca deben ser de su propiedad, y mucho menos ese
usuario ha de tener permiso de escritura sobre los mismos: con un acceso de
lectura (y ejecución, en caso de CGIs) es más que suficiente en la
mayoría de los casos. Hemos de tener en cuenta que si el usuario que
ejecuta el servidor puede escribir en las páginas web, y un pirata
consigue - a través de cualquier tipo de error (configuración, diseño del
demonio...) - ejecutar órdenes bajo la identidad de dicho usuario, podrá
modificar las páginas web sin ningún problema (que no olvidemos, es
lo que perseguirá la mayoría de atacantes de nuestro servidor web).
Igual de importante que evitar estos problemas es detectar cuando alguien
trata de aprovecharlos intentando romper la seguridad de nuestros servidores;
para conseguirlo no tenemos más que aplicar las técnicas de detección de
intrusos que veremos en el capítulo siguiente. Una característica
importante de los patrones de detección de ataques vía web es que
no suelen generar muchos falsos positivos, por lo que la configuración de la
base de datos inicial es rápida y sencilla, al menos en comparación con la
detección de escaneos de puertos o la de tramas con alguna característica
especial en su cabecera.
© 2002 Antonio Villalón Huerta
