Generalmente los criterios para asignar accesos a los distintos sistemas es los mismos, existen las que son aleatorias con y sin patrones, las típicas “dos letras iniciales del apellido seguido del año de nacimiento”, etc. Quizá el problema no está en asignarles claves por defecto fáciles a los usuarios, sino en los mismos usuarios que no las cambian o bien tardan una eternidad en ingresar por primera vez al sistema. Por esto mismo, pienso que la seguridad de los sistemas no debe depende de los usuarios, debe depender del sistema, a menos que tengamos muy acotado el tipo de usuarios que tendrá el sistema.
En este post hablaré sobre los tipicos accesos a universidades, cuentas de correo de empresas, cuentas de servidores ftp, ssh, web, etc.

En primer lugar, pienso que, el hecho de querer facilitarle las cosas al usuario final asignandole una password que sea “recordable”, es riesgoso. El hecho de que una password siga un patrón quiere decir que es altamente descifrable o descubrible por un atacante. Como patrónoes entendemos password como:

• usuarioYYYY: donde YYYY puede ser el año de nacimiento, el año que la persona ingreso a la institución u otra cosa que tenga relación.
• Primeros o últimos 3 o 4 digitos del rut: Por ejemplo si el rut de una persona es 6.714.870-9, la clave podría ser 6714 o bien 8709
• Nombre de usuario: aunque no lo crean, es muy comun tambien que se asigne como contraseña lo mismo que le entregan como nombre de usuario
• Juego con las iniciales de los nombres y/o apellidos y año de nacimiento o año de ingreso: Por ejemplo, para Juan Perez, una posible password sería jperez2009, juanp2009, jp2010, etc.

Quiza lo que acaban de leer pareciera ser algo muy estúpico o algo demasiado básico, pero es increible que suceda. Hace un par de semanas publiqué dos ejemplos muy claros al respecto, lo pueden ver en:

La poca importancia de la seguridad en la Universidad Mayor
Seguridad en accesos de ex alumnos del Instituto Profesional CIISA

El hecho de saber un patrón de asignaciones de contraseñas por defecto de una empresa o alguna institución les abre una puerta trasera enorme y, a mi criterio, es una vulnerabilidad que debe ser considerada critica si se desea proteger el robo de información y la privacidad de la institución y de los mismos usuarios.

La contraseña de un usuario puede comprometer el acceso a otros usuarios, por ejemplo si mi password por defecto corresponde a la primera inicial de mi nombre, seguido de mi apellido, luego un guión bajo (_) y finalmente mi año de nacimiento y es interceptada por algun atacante, sea como sea, independiente de que esa persona haya querido atacarme a mi o independiende de que si yo tengo informacion privada o si me interesa la seguridad o no, estoy dando el paso para que esa pesona pueda adivinar contraseñas de las demas personas.

Un caso muy comun es el hecho que cuando una persona ingresa a trabajar a una empresa generalmente le preparan un computador con todo listo, su cuenta de correo lista, configurada y lista para usarse por lo que el usuario jamás tendrá curiosidad de cambiarla, asi mismo todos o la gran mayoría de la empresa. Una persona sin muchos conocimientos podría probar el mismo patrón de contraseñas para ingresar como su compañero de trabajo, luego que ingresa al correo de esa persona exitosamente, lo gracioso sería intentar ingresar a otras cuentas por ejemplo al sistema de tickets u otros sistemas con el que podríamos hacer más daño. Según mi punto de vista, las contraseñas por defecto deberían ser por defecto aleatorias y obligar a que el usuario se loguee apenas es creada la cuenta y cuando ingrese por primera vez obligarlo a cambiar la contraseña.

Los desarrolladores o administradores pueden quejarse con la típica frase “es que son sistemas que acceder desde la red interna, desde la lan solamente”, pero la verdad es que uno nunca sabe desde que lado esta el atacante.

Aunque no lo crean, muchas veces esas mismas empresas que le asignan esas contraseñas por defecto a sus empleados, lo hacen tambien con sus clientes. Por ejemplo, una empresa de hosting o diseño web, en ambos casos, cuando le quieren dar acceso a ftp o bien acceso a algun sistema para que hagan el “testing”, cumplen el mismo patron, si no es “123456″ es, por lo general, el nombre del cliente. Puedo entender que es engorroso asignar contraseñas tan dificiles de recrodad a los clientes para que hagan simplemente un checkeo de una aplicación, pero aveces la seguridad requiere de un poco de esfuerzo.

Compartir/Guardar

Estimado Fernando:

Me dirijo a usted como representante de la Empresa E-Sign, en mi calidad de Gerente de Operaciones,  para comentarle algunos de los alcances que ha tenido para nosotros el  reporte de vulnerabilidad XSS que usted ha publicado a fines de la semana pasada.  Con su información hemos verificado los errores reportados, y nuestros programadores se encuentran trabajando en la revisión y corrección de otros posibles problemas. Específicamente, aquellos relacionados con el “contacto.php” se corrigieron el 30 de Abril en la tarde.

Le agradecería que, en el caso de detectar una nueva vulnerabilidad o la posibilidad de ella en nuestro sitio, lo informe directamente a mi correo particular o telefónicamente a la empresa. Asimismo, le solicitamos que nos dé un  espacio de tiempo suficiente para corregir el problema, antes de publicarlo en internet.

Finalmente, a nombre de E-Sign, quisiéramos agradecerle su nota y enfatizar que tomaremos todas las medidas necesarias para evitar que este tipo de problemas vuelvan a ocurrir.

Creo que es una buena respuesta y es la forma en que deberían actuar las empresas cuando se les informa sobre algún fallo, bug o vulnerabilidad que los afecta.
Podemos ver que el enlace vulnerable: https://www.e-sign.cl/contacto.php?prefilla=%22%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E ya no se ve afectado.

Compartir/Guardar

<script>alert(‘this.cookie’)</script>

Cuando los ataques XSS mediante tags no son posibles, existe la posibilidad de realizar el ataque usando las propiedades de cada tag. Puede ser usando el atributo style, src o algúnos gatilladores de eventos como onMouseOver, etc. Para poder realizar el ataque es necesario usar comillas (simples o dobles), aunque tambien en algunos casos existe la posibilidad de no usarlas, para poder agregar una nueva propiedad al tag en el cual hemos conseguido insertar el código.

En los ataques realizados mediante la propiedad style, podemos usar las siguientes funciones o métodos (en este caso, el código se ejecuta automáticamente al cargar la página):

1. Usando expression(), sólo funciona en Internet Explorer anterior a la versión 8.
2. Usando background:url() o background-img:url(), sólo funciona en Internet Explorer.
3. Usando -moz-binding:url(), sólo funciona en Mozila y en otros motores basados en Gecko (antes de Firefox 3).

Pueden ver un ejemplo de un ataque usando -moz-binding:url() y expression() en éste link (está en un idioma que seguramente no entenderemos pero los ejemplos se entienden sin problemas).

Los ataques vía eventos (handlers) son aplicables de la siguiente forma:

1. Eventos como onMouseOver, onFocus, onBlur, onSelect, onChange, onClick, etc.
2. Usando onError, onLoad y onUnload, para ejecutar código automáticamente al cargar o cerrar la página.

La posibilidad de usar onLoad, onUnload y onError no es muy amenudo y los otros eventos no se ejecutan automáticamente, siempre hay que esperar a que algo los gatille. Por ésto mismo, este tipo de ataque XSS no es muy popular, generalmente se ataca incrustando código en las propiedades tales como style, ya que se ejecuta automáticamente.
Cerca del 2008, la posibilidad de realizar un ataque XSS mediante -moz-binding fue removida (o bueno, fue parcialmente removida ya que aún es posible realizar ataques de éste tipo mediante ficheros xml en el mismo sitio). En el lanzamiento de Internet Explorer 8, a comienzos del 2009, se removió el soporte a la función o método expression(). Tambien fue removido el soporte de javascript o vbscript en background-image.
Con los arreglos que se hicieron en los distintos navegadores,  se dificuló el llevar a cabo  ataques Cross-Site Scripting mediante tags. Por otro lado, los navegadores como Opera y Chrome resisten ataques  de éste tipo mediante la propiedad style.
Podemos usar la técnica del MouseOverJacking. Con ésta técnica, se puede automatizar el ataque XSS. Es una solución que funciona en todos los navegadores, incluyendo IE8, eludiendo la protección anti-clickjacking que trae incorporada.
MouseOverJacking se puede usar en lugar de expression() y -moz-binding(). El ataque está automatizado, por lo que el ataque cumpliría el mismo objetivo que expression y -moz-binding y gracias al soporte multi navegador, es posible atacar a más usuarios.
Se puede realizar con MouseOverJacking lo mismo que con ClickJacking, con la diferencia que el MouseOverJacking es más efectivo, ya que no espera ninguna acción del usuario, no es necesario que el usuario haga click para gatillar el ataque. El ClickJacking espera un click por parte del usuario en cambio el MouseOverJacking simplemente espera el movimiento del ratón.

Ejemplos:

Reflected XSS

http://site/script?param=%22%20style=%22width:100%;height:100%;display:block;position:absolute;top:0px;left:0px%22%20onMouseOver=%22alert(document.cookie)%22

Persistent XSS

<a href=”#” style=”width:100%;height:100%;display:block;position:absolute;top:0px;left:0px” onMouseOver=”alert(document.cookie)”>&nbsp;</a>

Este artículo corresponde a una traducción al Español de la traducción al Inglés del original, extraído de WebSecurity.

Compartir/Guardar

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.

Compartir/Guardar

Cuando comencé a escribir sobre éste sitio web, existía una vulnerabilidad de descubrimiento del path (Full Path Disclosure) junto a un SQL Injection y un XSS, dentro de un “plugin” hecho para las votaciones lo que luego fue corregido, no logré sacar screenshot y ejemplos para demostrarlo. Que hayan corregido éstos errores es un punto a favor para la seguridad del sitio. Vamos a ver hasta qué punto podemos poner a prueba la seguridad.

Es un sitio hecho en WordPress, por lo cual ya sabemos las rutas de los archivos y las posibles vulnerabilidades que podría tener el sitio. Por ejemplo, podemos empezar probando con el clásico wp-login que es el script que nos permite iniciar la sesión, descubrir una lista de usuarios, hacer fuerza bruta, etc. Nos vamos a la URL

http://www.marco2010.cl/wp-login.php

Y como podemos ver, ya nos aparece el formulario para iniciar la sesión. Para éstos casos, existe un truco y es probar siempre con el usuario admin, para ver si lo tienen habilitado, ya que es el único usuario que viene por defecto.

Como podemos ver en el recuadro de “error“, nos dice que la contraseña es inválida, por ende, asumimos que el usuario está correcto. Ya sabemos que existe el usuario admin, ahora solo falta romper la password. Mientras dejamos un script de fuerza bruta corriendo, tambien podemos intentar averiguar más usuarios dentro del sistema, hasta llegar con alguno que tenga una password más fácil de romper con el cual podamos ganar acceso al dashboard del sitio.

Hay que tener en cuenta que ultimamente se han estado realizado muchos ataques por fuerza bruta a distintas instalaciones de wordpress. Pueden leer más sobre esto en el artículo titulado:

Distributed WordPress admin account cracking

Si bien la mayoría de los sitios en wordpress (incluyendo el mio) tienen este tipo de “fallo”, considero que es agujero de seguridad y que debería implementarse por último un htaccess.

Otra cosa que me llamó la atención es que los desarrolladores del theme marcoenriquezominami han desarrollado instalado un sistema de votacion o encuestas el cual lo han dejado dentro del directorio del theme. Toda la gente que ha desarrollado alguna véz en WordPress, sabrá que para éste tipo de cosas, debería crearse un plugin. El sistema que estos tipos descargaron e instalaron es el Advanced Poll 2.08, si  buscamos en google podemos ver que las versiones anteriores tienen diversas vulnerabilidades y que para descubrir alguna, basta con que descarguemos el codigo y sepamos como explotar algun fallo no reportado.
La URL para manejar las encuestas es:

http://encuestas.marco2010.cl/admin/

Si bien lo que les mostraré a continuación no es un “fallo de seguridad”, si nos va a permitir  ver cosas que quizá ellos no quieren que veamos, como la lista de archivos subidos, etc. Directory Listing:

• http://web.marco2010.cl/wp-content/uploads/
• http://web.marco2010.cl/wp-content/plugins/downloads-manager/upload/

Tambien tiene un wiki disponible en http://wiki.marco2010.cl.

Como conclusión, lo único que les puedo decir es que la seguridad del sitio va a depender de la seguridad de WordPress, Advanced Poll y de Wikimedia.
Si bien el sitio es “seguro”, será lo suficientemente vulnerable a medida que se vayan publicando bugs de las herramientas que nombré anteriormente.
Por ejemplo, cuando se publicó el DoS que afectaba al wp-trackback, éste sitio era completamente vulnerable. Yo mismo lo probé antes de que lo actualizaran.

Actualizado (10-12-2009) La persona encargada se contactó conmigo y acogieron mis recomendaciones.

Compartir/Guardar

d3m4s1@d0v1v0 escribió un artículo titulado “Cruzando Información, Cross-Site Scripting (XSS)” en el que, luego de aclarar el fín del artículo

ACLARACION: el artículo está dirigido a aquellos que quieran aprender programación web segura, gente dedicada a la seguridad que utiliza el hacking ético para descubrir problemas a solucionar y reportarlos. Para hacer este tipo de ataque deben contar con la aprobación del encargado de la web o quién corresponda.

explica detalladamente el por qué del nombre XSS, que es el XSS, cómo se puede “usar” el XSS, lograr que el usuario ejecute lo que queremos, entre otras cosas.
Recomiendo el artículo a quienes quieran informarse un poco más sobre el tema.

Compartir/Guardar

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.

Compartir/Guardar

Si bien todo esto podría ser usado indebidamente, no es el propósito. Antes de hacerlo público será necesario que generemos un disclaimer sobre los usos de la herramienta. Nosotros sólo estamos entregando una herramienta, el uso de ella va a depender de la ética de cada persona.

Lanzamiento …
Tenemos pensado lanzar al publico este proyecto en el Hackmeeting.

La herramienta …
La herramienta es super sencilla y consta de un pequeño formulario para reportar una vulnerabilidad.

Luego de esto, los distintos sitios web son almacenados en una base de datos y ordenados.

Compartir/Guardar

Las vulnerabilidades encontradas corresponden a las del tipo Local File Include (LFI), Remote File Include (RFI) y Remote Code Execution (RCE)

El script vulnerable es el index.php, el que soporte como parametro mediante la variable “contenido”, un fichero local o remoto.
Como primera prueba, intentaremos embedir google dentro del sitio, pasando como parametro la direccion de google:

Entonces es hora de incluir nuestra shell remota y ejecutar algunos comandos, para saber que control tenemos sobre el servidor:

$ whoami; pwd; id;
apache
/webhosting/mincyt/html
uid=48(apache) gid=48(apache) groups=48(apache)

Listado de directorios de la raíz:

Listado de directorio actual:

(click para imágen completa)

Este tipo de sitios se puede utilizar como proxy, es decir, navegar “anonimamente” usando la dirección IP del ministerio de tecnología de argentina, por ejemplo, ingresamos a un sitio que nos muestra información sobre nuestra IP, desde el servidor de mincyt:

Como podemos ver, la direccion de origen es goku.mincyt.gob.ar, que mejor, estamos navegando desde el ministerio de ciencia y tecnologia de argentina y ademas desde Goku!

Actualización (12/Ago/2009 – 21:33hrs): Debido a un artículo publicado en segu-info, me entro que ArCert (coordinación de emergencias en redes teleinformáticas) se hará cargo del asunto, intentando comunicarse a la brevedad con los responsables para solucionar el problema.

Actualización (13/Ago/2009 – 11:27hrs): Corrigieron el problema de Remote File Include y Remote Code Execution, la vulnerabilidad LFI aún persiste.

Actualización (13/Ago/2009 – 21:30hrs): Como pueden ver en los comentarios, la gente de ArCert se puso en contacto con Mincyt para solucionar el problema y al parecer ya lo han solucionado. Estas personas nunca se contactaron conmigo, sino que dejaron un comentario en el blog de segu-info.

Compartir/Guardar

Básicamente, ¿Qué es el phishing?

Definamos phishing como una tecnica de “pesca” para robar información privada/personal de personas y/o empresas.

¿Cómo se lleva acabo esta técnica?

Puede resultar tan sencillo como intentar engañar a un niño, pues hacemos creer a una persona algo que no lo es con la finalidad de que esta persona nos entregue datos confidenciales y/o privados, por ejemplo, mediante un formulario de login a un sistema (universidad, banco, etc) falsificado.

A las empresas parece importarle poco el tema de seguridad en este aspecto, segun mi experiencia y estudios realizados por mi (ver en este blog), la vulnerabilidad XSS es una de las más comunes y es la que nos permite robar informacion de muchas formas usando la identidad de la empresa/sitio web vulnerable.

Tomemos como ejemplo una de las páginas que he publicado con este vulnerabilidad, que aun no lo solucionan. Corresponde al sitio web de la “Direccion de bibliotecas, archivos y museos” DIBAM, la URI vulnerable es:
http://www.dibam.cl/error.asp?cadena=a&pagina=[XSS]

Podemos insertar cualquier código javascript o html, como prueba de concepto vamos a insertar un iframe apuntando a google:

http://www.dibam.cl/error.asp?cadena=a&pagina=%3Ciframe%20src=http://google.cl%20frameborder=0%20width=660%3E%3C/iframe%3E

De este mismo modo, pudimos haber hecho referencia a un sitio con un login modificado, haciendonos pasar por “dibam” y pidiendo informacion privada a usuarios. De esta misma forma, podemos hacer referencia desde el siti o”dibam.cl” a algun fichero infectado con algun troyano, virus, etc.

Respecto al javascript, todo codigo javascript ejecutado si bien se ejecuta en por el lado del cliente, lo que no significa ningun riesgo para el servidor, hay que dejar en claro que todo el código javascritp será ejecutado en el contexto del sitio web, por lo que será posible el acceso a cookies, etc lo que nos permitirá robar las cookies para logearnos en algún sistema.

Compartir/Guardar

Corresponden a las vulnerabildiades SQL Injection y XSS y los sitios son los siguientes:

• sirpachile.cl
• tardis.cl
• paihuen.cl
• dibam.cl
• balmacedartejoven.cl

Las URL vulerables:

http://www.sirapchile.cl/biblioteca.php?categoria_biblioteca=&Submit=Buscar&dat=[XSS]

http://www.tardis.cl/uf.php?ano=[SQL Injection]

http://www.paihuen.cl/socios/default.asp?mensaje=[XSS]

http://www.dibam.cl/error.asp?cadena=a&pagina=[XSS]

La siguiente URI tiene dos vulnerabilidades:

http://www.balmacedartejoven.cl/portada_sede.php?go_sede=[SQL Injection | XSS ]

Compartir/Guardar

- http://www.udec.cl
- http://www.ing-mat.udec.cl

De las cuales la primera tenía al menos dos scripts vulnerables
- http://www.udec.cl/exalumnos/registro_google/mensaje.php?mensaje=[XSS]
- http://www.udec.cl/egresados/mensaje.php?mensaje=[XSS]
Y la segunda al menos una
- http://www.ing-mat.udec.cl/biblioteca/buscar_libro_autor.php?autor=[XSS]
Según los encargados

Ya hemos desactivado el sitio http://www.udec.cl/egresados que estaba obsoleto.
También notificamos a los desarrolladores de las otras direcciones para que apliquen validaciones en los parámetros de los scripts a la brevedad. En el último caso esperan cambiar pronto la plataforma por una nueva.

Hasta el momento sólo la segúnda (egresados) ha sido fixeada, las continuan vulnerables.

Compartir/Guardar

Desde hoy en adelante, con el fin de ayudar y promover la seguridad de la información en Chile, comenzaré a publicar -en lo posible- todos los fines de semana una lista de al menos 5 sitios con fallas de seguridad de distintos tipos y, a fin de cada mes, haré un resumen de todos los
sitios publicados durante el mes.

Compartir/Guardar

Este sistema de inicio de sesion tiene dos vulnerabildiades que pueden ser explotadas muy facilmente, SQL Injection y Authentification bypass. La primera nos permitirá iniciar sesion como cualquier cliente o administrador y la segunda

Ejemplo, com un SQL Injection vamos a iniciar sesion como un usuario al azar:

La tercera vulnerabilidad la podemos encontrar si miramos la url de esta pantalla

Corresponde a una vulnerabilidad de stipo XSS, si cambiamos el contenido de la variable nom por algun codigo malicioso, podremos usar el sitio de caffarena para hacer phishing, robar cookies y otros datos de clientes, etc.

La vulnerabilidad numero cuatro corresponde a una del tipo authentificaction bypass, que nos permitirá ingresar al sistema de administración con tan solo escribir en la barra de direcciones el directorio donde se encuentra este sistema, sin un login ni nada. En este panel de administración podremos encontrar todos los documentos de los clientes y además, una lista de todos los clientes con sus respectivos passwords.

Como quinta y ultima vulnerabilidad, tenemos que al intentar subir algun fichero, el sistema no valida de que tipo es por lo que podemos subir algun script escrito en php con codigo malicioso que nos permita hacer las cosas que queramos realizar operaciones no permitidas en el servidor, ejecutar comandos, navegar por los directorios, etc.

Como conclusion, no me queda nada mas que decir que este sitio web esta tapado en bugs altamente explotables y es una de las paginas con los sistemas de seguridad y administracion mas malo que he visto.

Compartir/Guardar

CVE-2009-0028

    Chris Evans discovered a situation in which a child process can
    send an arbitrary signal to its parent.

CVE-2009-0834

    Roland McGrath discovered an issue on amd64 kernels that allows
    local users to circumvent system call audit configurations which
    filter based on the syscall numbers or argument details.

CVE-2009-0835

    Roland McGrath discovered an issue on amd64 kernels with
    CONFIG_SECCOMP enabled. By making a specially crafted syscall,
    local users can bypass access restrictions.

CVE-2009-0859

    Jiri Olsa discovered that a local user can cause a denial of
    service (system hang) using a SHM_INFO shmctl call on kernels
    compiled with CONFIG_SHMEM disabled. This issue does not affect
    prebuilt Debian kernels.

CVE-2009-1046

    Mikulas Patocka reported an issue in the console subsystem that
    allows a local user to cause memory corruption by selecting a
    small number of 3-byte UTF-8 characters.

CVE-2009-1072

    Igor Zhbanov reported that nfsd was not properly dropping
    CAP_MKNOD, allowing users to create device nodes on file systems
    exported with root_squash.

CVE-2009-1184

    Dan Carpenter reported a coding issue in the selinux subsystem
    that allows local users to bypass certain networking checks when
    running with compat_net=1.

CVE-2009-1192

    Shaohua Li reported an issue in the AGP subsystem they may allow
    local users to read sensitive kernel memory due to a leak of
    uninitialized memory.

CVE-2009-1242

    Benjamin Gilbert reported a local denial of service vulnerability
    in the KVM VMX implementation that allows local users to trigger
    an oops.

CVE-2009-1265

    Thomas Pollet reported an overflow in the af_rose implementation
    that allows remote attackers to retrieve uninitialized kernel
    memory that may contain sensitive data.

CVE-2009-1337

    Oleg Nesterov discovered an issue in the exit_notify function that
    allows local users to send an arbitrary signal to a process by
    running a program that modifies the exit_signal field and then
    uses an exec system call to launch a setuid application.

CVE-2009-1338

    Daniel Hokka Zakrisson discovered that a kill(-1) is permitted to
    reach processes outside of the current process namespace.

CVE-2009-1439

    Pavan Naregundi reported an issue in the CIFS filesystem code that
    allows remote users to overwrite memory via a long
    nativeFileSystem field in a Tree Connect response during mount.

Se publicaron dos exploits para explotar vulnerabildades de escalacion de provilegios local. Estos exploits se aprovechan de la funcion ptrace_attach() para ejecutar un codigo arbitrario que nos permita ejecutar una shell del tipo /bin/sh como root.
El primer exploit es el shoryuken, lo probé en distintas versiones del kernel de debian y archlinux, pudiendo ser explotada solo la version 2.6.26-1-686 de Debian 5.0, de forma aleatoria, es decir, hay veces que ejecuto el exploit y funciona y otras veces no. El segundo script fue probado por su autor en la version del kernel 2.6.29rc1 de Gentoo.
Estos exploits funcionan bajo situaciones especificas y no todos los sistemas son vulnerables.

Compartir/Guardar