Contraataques, Evitando la identificación de nuestro servidor

kasper11@masterhacks.net

Como dice el títutlo del capítulo hemos llegado a la parte del contraataque, siempre es bueno

aprender a hacer algo, pero también es esencial saber como se ha echo y como deshacerlo. Así

mismo esta vez hemos aprendido a utilizar tecnicas como Banner Grabbing y Http Fingerprinting

pero también vamos a aprender a protegernos de ambas.

Comenzaremos con la protección ante banners grabs dado que es la técnica más sencilla de las

dos que hemos mencionado anteriormente.

Existen 3 maneras de evitar el banner grab en Apache, la primera editando un fichero de apache

antes de instalarlo, y las otras dos mediante mods de este mismo. Sin embargo solo mostraré 2.

Una vez bajado y descomprimido nuestro apache abrimos la carpeta include y localizamos el

archivo ap_release.h dentro de este buscamos algo como esto:

#define AP_SERVER_BASEVENDOR "Apache Software Foundation"

#define AP_SERVER_BASEPROJECT "Apache HTTP Server"

#define AP_SERVER_BASEPRODUCT "Apache"

#define AP_SERVER_MAJORVERSION_NUMBER 1

#define AP_SERVER_MINORVERSION_NUMBER 3

#define AP_SERVER_PATCHLEVEL_NUMBER 41

#define AP_SERVER_DEVBUILD_BOOLEAN 0

Este archivo define los datos de la versión, producto etc... Entonces ahora vamos a proceder a

modificarlo.

#define AP_SERVER_BASEVENDOR "Tito Lix Server fundation”

#define AP_SERVER_BASEPROJECT "Knight Force HTTP Server"

#define AP_SERVER_BASEPRODUCT "Knight"

#define AP_SERVER_MAJORVERSION_NUMBER 2

#define AP_SERVER_MINORVERSION_NUMBER 0

#define AP_SERVER_PATCHLEVEL_NUMBER 0

#define AP_SERVER_DEVBUILD_BOOLEAN 8

Ahora lo instalamos y, probamos nuestra modificación:

[Lix@Fedora ~]$

nc localhost 80

HEAD / HTTP/ 1.0

200 OK

Connection: close

Date: Thu, 10 Jan 2008 11:25:14 GMT

Server: Knight Force HTTP Server//2.0.0.8 (Unix)

Content-Type: text/html

Client-Date: Thu, 10 Jan 2008 13:36:24 GMT

Client-Peer: 127.0.0.1:80

Client-Response-Num: 1

Otra forma mucho menos tediosa seria bajar el paquete mod_headers. Se trata de un módulo de

apache, que permite modificar las cabeceras devueltas por el servidor. Por ejemplo una vez

instalado, añadiendo al fichero de configuración de apache la siguiente línea:

Ya hemos visto como evitar el banner grab, pero ahora vamos a intentar defendernos del

fingerprinting. Nosotros hemos usado 4 test para conseguir identificar el servidor con máxima

certeza, sin embargo existe una herramienta muy usada para el fingerprinting, su nombre se llama

httprint[8]. Dicha herramienta está cruzificada dentro de las reglas de mod_security

Cuando instalemos mod_security[9] deberemos editar el fichero

/etc/modsecurity2/modsecurity_crs_10_config.conf

Sustituyendo la línea:

Por:

Elegimos el nombre que mas nos apetezca. Ahora obligamos a Apache a recargar sus ficheros

de configuración:

.

/etc/init.d/apache2 force-reload

0x06: Ataques con Metodos

Como vimos al inicio de este paper sobre el protocolo HTTP existen diversos métodos

que sirven para el manejo remoto de archivos, tales como PUT, COPY o DELETE. Estos métodos

si están permitidos en un servidor puede jugar muy malas pasadas, ya que mandando una

cabecera PUT con el código fuente de una shell podríamos tener control casi total del servidor,

subir un exploit, etc…

En este capítulo nos centraremos en el manejo de estos métodos “peligrosos” para los

webmasters, así como aprender a desactivarlos para evitar males mayores.

/.0x09 Creación y borrado de ficheros (Put y Delete)

Cuando encontramos un servidor con los métodos PUT y DELETE admitidos podemos

considerarnos muy afortunados, puesto que tenemos casi todo el trabajo hecho. Vamos a

empezar hablando de PUT.

PUT es un método que funciona a la inversa que GET, es decir, en vez de leer el

contenido de un fichero lo que hace es escribir sobre él, como ya vimos al inicio de este paper.

Esto nos da una gran ventaja puesto que podemos subir una shell al servidor. Pero… ¿Cómo

Header set Server Knight Force HTTP Server

SecServerSignature "Apache/2.2.9 (Fedora)"

SecServerSignature "Knight Force HTTP Server"

ServerTokens Full

funciona PUT?. PUT necesita de unos parámetros básicos, que si lo pensamos bien resultan

lógicos. Lo que necesita es primero hacer la petición al fichero sobre el que deseamos

sobrescribir. En caso de que el archivo al que le hacemos PUT no exista, se creará. Bajo nuestro

punto de vista vemos con mejores ojos a la hora de hacer un “buen asalto” el aprovechar ficheros

ya creados, porque así nuestra shell pasará desapercibida en el servidor.

Otro parámetro que necesita PUT es la longitud (número de caracteres) que tendrá el

source del archivo, es decir, cuanto mide el código que vamos a escribir. Para indicar esto, existe

un campo llamado Content-Length, el cual deberemos de rellenar con el número exacto de

caracteres.

Entonces una posible petición sería la siguiente:

Como vemos el uso de PUT es sencillo, pero hay veces que la cosa se complica puesto que

pide alguna forma de autentificación para poder llevar a cabo esta petición con éxito. Cuando se

usa PUT, el mensaje de que las negociaciones han sido perfectas viene definido por un código

201. Este 201 indica que el archivo ha sido subido/sobrescrito perfectamente.

Volviendo a lo de la autentificación, deciros que este tema se tocará en el siguiente capítulo.

Como anécdota de PUT, decir que en los servidores IIS 5.0 viene activado por defecto[7], con lo

que depende del dueño del servidor el deshabilitad este método, lo que da pie a una alta

probabilidad de encontrar este método permitido en servidores antiguos.

El gran problema de PUT es que dejan unas huellas en los logs que son increíblemente

sencillos de analizar y de ver el fallo, ya que en los logs se recogen las peticiones que habeis

realizado.

Por contrapartida a PUT encontramos DELETE. Este método, como su propio nombre indica,

tiene la función de eliminar el archivo al que le hace la petición.

PUT /index.html HTTP/1.1

Host: Ficticio.com

Content-Length: 47

<script>alert(“Testeando método PUT”);</script>

DELETE /index.html HTTP/1.1

Host: <host>

User-Agent:

-----Demás campos----

Como podemos ver, DELETE es un método fácil de usar, pero que al igual que put suele aparecer

deshabilitado, y deja también unos rastros enormes en los logs. Tanto DELETE como PUT

necesitan en muchos casos de rellenar el campo “Authorization”, y esto es lo que vamos a ver en

el siguiente capítulo.