Lo interesante no es hablar y hablar sobre este fallo, sino hacerse con los recursos técnicos suficientes para entenderla, auditarla y en su caso explotarla. No es dificil pero es tedioso, ya que la sobredósis de información hace pesado el acto de separar la paja del grano, espero que os guste mi separación.

Información.

Para entender la vulnerabilidad en sí misma, las causas de la misma y los detalles técnicos el mejor documento que he encontrado es un papper de Sourcefire, empresa del conocido NIDS Snort.

Auditoría.

Para saber si una máquina es vulnerable tenemos por un lado un script realizado por Portcullis Lab, escrito en Python. Por otro lado Nessus ha sacado dos plugins al respecto: 34477 y 34476.

Detección.

Snort ha sacado recientemente una actualización de las reglas VRT que incorpora reglas de detección de esta vulnerabilidad.

Explotación.

Para explotar esta vulnerabildad ha sido publicado un exploit para el framework Metasploit. Tengo que decir que tal como lo descargas este exploit no funciona, pero a poco que investiguéis os daréis cuenta de que le faltan un par de cosillas. Es una medida habitual contra los script kiddies. Yo he realizado las modificaciones y puedo decir que funciona perfectamente.

Por otro lado en Milw0rm han publicado un exploit alternativo, no lo he probado, pero dada la reputación del sitio creo necesario nombrarlo.

Si conocéis alguna mejor ya sabéis, tengo activados los comentarios.

Compártelo

La vulnerabilidad en sí no es muy grave, no tiene un punto de explotación claro, si bien es necesario no tener este tipo de fallos en aplicaciones forenses, ya que de ellas se espera la mayor robusted. Uno de los problemas del software OpenSource en el ámbito forense (lo dice el CHFI no yo) es que generalmente no son programas muy aceptados debido a que la publicación del código fuente los hace más vulnerables (?????).

Sobra decir las dudas que tengo al respecto de esa afirmación pero poco importa. Hoy escribo porque ha salido una nueva versión de Autopsy, la 2.20 y este error ha sido corregido.

mi_ego++

Compártelo

A veces uno llega tarde…

Compártelo

* FrSIRT Advisory: ADV-2007-4021
* Bugtraq ID: 26596
* OSVDB ID: 38792
* Secunia Advisory ID: 27834
* CVE ID: 2007-6156 (ver también: NVD)

Esto además de alimentar mi ego me incentiva para seguir buscando errores en aplicaciones web de código abierto.

Compártelo

Aplicaciones afectadas:
———————–
- W-Agora : web publishing and forum software

Versiones afectadas:
——————–
- W-Agora 4.2.1

Sistemas operativos afectados:
——————————
- Multiplataforma(Aplicación web escrita en php)

Versiones no afectadas:
———————–
- Actualmente ninguna

Descripción del producto:
————————–
W-agora(http://www.w-agora.net) Sistema de publicación en Web y foros de discusión, totalmente personalizable de acuerdo con las necesidades del usuario, de código abierto para su libre modificación y distribución. La instalación y configuración es rápida y sencilla.

Descripción de la vulnerabilidad:
———————————
La vulnerabilidad se debe a la mala validación de los parametros de
entrada en el fichero admin_user.php. Concretamente los parámetros
“userid” y “pattern“.

Detalles técnicos:
——————
La explotación de estas vulnerabilidades es posible haciendo
tampering de los parametros mencionados y cambiando su valor por algún vector
de ataque XSS.

Soluciones:
———-
- Actualmente no hay ninguna versión que corrija este fallo. Se recomienda instalar modsecurity con reglas anti XSS.

Histórico:
—————-

03/01/2008 - Vulnerabilidad descubiertas
- Primera notificación a W-Agora Software
- Apertura de bug en Bugtrack #1863010

Descargar advisory (Spanish):SIAADV-08-001-ES.txt

Descargar advisory (English):SIAADV-08-001-EN.txt

Compártelo

Sigo esperando una rectificación por parte de KJ.

Compártelo

Aplicaciones afectadas:
———————–
- Basic Analysis and Security Engine

Versiones afectadas:
——————–
- BASE 1.3.8(jodie)

Sistemas operativos afectados:
——————————
- Multiplataforma(Aplicación web escrita en php)

Versiones no afectadas:
———————–
- Iguales o superiores a BASE 1.3.9(anne)

Descripción del producto:
————————–
BASE(http://sourceforge.net/projects/secureideas/) es una interfaz
web de administración de alertas del detector de intrusos Snort.Está escrita
en php y soporta varias BBDD, entre ellas MySQL, Postgree, etc.
Es el producto más utilizado para ver/clasificar las alertas de Snort.
Su origen es el ya historia ACID( Analisys Control Intrusion Detection ).

Descripción de la vulnerabilidad:
———————————
La vulnerabilidad se debe a la mala validación de los parametros de
entrada en el fichero base_qry_main.php. Concretamente los parámetros
sig%5B0%5D y sig%5B1%5D.

Detalles técnicos:
——————
La explotación de estas vulnerabilidades es posible haciendo
tampering de los parametros mencionados y cambiando su valor por algún vector
de ataque XSS como el siguiente:

‘;!–” <script> alert (document.cookie); </script>

Soluciones:
———-
- Actualice el software a la última versión disponible por el fabricante (actualmente v1.3.9)

Histórico:
—————-

24/09/2007 - Vulnerabilidad descubiertas
– Primera notificación a Secureideas
– Secureideas solicita información más extensa
– Proporciono dicha información y abro el bug en Bugtrack #1801192
13/10/2007 - Secureideas asigna al bug una prioridad alta(9)
20/11/2007 - Secureideas informa de que el bug ha sido arreglado.
- Se publica la versión 1.3.9(anne)
28/11/2007 - El bug es publicado por el FSIRT(FrSIRT/ADV-2007-4021)

Descargar advisory (Spanish):SIAADV-07-005-ES.txt

Descargar advisory (English):SIAADV-07-005-EN.txt

Compártelo

Claro que si entras en el CHANGELOG de BASE no verás mención alguna hacia mi persona en relación con el bug de seguridad por Cross Site Scripting, aunque en BUGTRACK pueda verse claramente que la persona que descubrió el bug es la persona que hizo el documento sobre BASE+Snort en Slackware( osea yo mismo), y esto esté admitido en el CVS del documento en cuestión e incluso en el propio CHANGELOG de BASE:

Puede pensarse que esto es una cuestión de ego. En efecto, lo es.
Pero también tengo que decir que no puede arrebatarseme lo que es mio, agradezco a Kevin Johnson( lider del proyecto BASE, en adelante KJ ) su trabajo en la aplicación pero no puedo pasar por alto este grave fallo y así se lo he hecho saber por correo electrónico.

Desde que descubrí el fallo he estado a su completa disposición, y he aportado documentación para resolverlo a la mayor brevedad posible.
Pero es muy facil adjudicarse el trabajo ajeno y aparecer en la foto.

Hoy veo que el FSIRT(French Security Incident Response Team) se hace eco de esta vulnerabilidad y la ha publicado, por supuesto y dado que desde el proyecto BASE se ningunea mi trabajo podemos ver que en los creditos del bug no hay mención alguna hacia mi persona:

Se lo he hecho saber al FSIRT y también a KJ. Del FSIRT aún no he recibido respuesta y del intercambio de correos con KJ solo veo por su parte lo doloroso que le es dedicar su tiempo libre a un proyecto OpenSource, bla bla bla.
Si KJ, sé lo que es dedicar tiempo a actividades que no repercutirán directamente sobre tu bolsillo. Dedico bastante tiempo a participar en la comunidad Slackware, a proveerla de documentación, paquetes, intervengo en foros, canales de IRC, He participado en la creación de proyectos como Open-Eslack, comunidad de la que sigo formando parte e incluso creo mis propios proyectos como XSSnortRules o “Embajadores Slackware”, que estoy madurando antes de darle el escopetazo definitivo.
Además de todo eso KJ, también le dedico mi tiempo a buscar fallos de seguridad en aplicaciones de mi interés, tal es el caso de BASE.

Pero no te preocupes KJ, lo bueno de las licencias OpenSource es que aunque te adjudiques mi trabajo, el código es libre y por tanto puede crearse un fork de BASE facilmente.

Así son las cosas y así se las hemos contado.

Compártelo

Sin embargo el alcance de estas vulnerabilidades va mucho más allá de esta simple inyección. Las posibilidades son infinitas cuando hablamos de ejecución de código remoto, con una importancia mayor aún si cabe cuando tratamos XSS permanentes. Pruebas de esta importancia son los tuneles XSS, pruebas de concepto como la del ya famoso Jikto( cuyo código disponemos ya todos ), o herramientas de secuestro del navegador cada dia más maduras, como el ejemplo de BeEF.

Este post viene al caso no solo para quejarme publicamente sobre el desprecio generalizado antes estas fallas, sino a la decepción que me he llevado recientemente al descubrir y reportar una de ellas.
Se trata del ya famoso BASE, la interfaz escrita en php para administrar alertas del detector de intrusos Snort.
El dia 24 de Septiembre del mes pasado(hace ya 10 días) descubrí un XSS en BASE, lo evidencié en forma de imagenes:

que remití a los desarrolladores. Mi correo fue contestado muy rapidamente por Kevin Johnson, el lider del proyecto, agradeciendome el reporte, pidiendome información concreta sobre la vulnerabilidad y comentandome que intentarían arreglarlo ese mismo dia.

Tras 10 días no solo sigue aún sin resolver, sino que el bug que abrí en Bugtrack tiene una prioridad media y no ha sido asignado a nadie. Por otro lado en el CVS del fichero afectado en cuestión no hay ninguna entrada que haga referencia alguna a esta vulnerabilidad.

Como curiosidad dejo un pantallazo de la inserción de un enlace, apuntando hacia un supuesto código maligno:

Estaré pendiente de la resolución.

Compártelo

Teotihuacan no se daba cuenta de que la seguridad de Ubuntu había quedado hecha añicos, y es que en dicho fichero se almacenaba la contraseña del primer usuario en texto plano, es decir, del que por defecto tiene privilegios de root.
De la gestión del error no podemos decir más que fue expléndida, en Launchpad lo resolvieron con celeridad.

La curiosidad técnica es que este fallo de seguridad solo afectaba a la versión 5.10, quedaba libre la anterior 5.04 y la Dapper, de desarrollo.

Queda fuera de toda duda que no podemos pasar por alto este fallo solo porque Ubuntu sea un Linux de código abierto. El error de diseño es gravísimo, aunque también hay que destacar la eficiencia de su solución una vez descubierto.
Tenemos de nuevo la reflexión sobre si la seguridad es la oscuridad. Hace unos dias Symantec cambiaba su vara de medir en los errores en navegadores y aceptaba los errores en sí, admitidos por las compañías o sin admitir. Como resultado de dicha elección IE Explorer pasaba a ser el navegador menos seguro y Mozilla Firefox el más seguro.
¿Es conveniente que se conozcan los errores de un programa? Es evidente que en el OpenSource, al estar centrados en el producto interesa que se sepan para solucionarlos cuanto antes, en el software propietario interesa solucionarlos, pero no que se sepan para dar mejor imagen de la compañía. Como resultado es posible ( y sucede ) que las compañías trabajan en solucionar fallos que el usuario final ignora que existan.

Hay por tanto dos formas filosóficas de recibir el fallo de Ubuntu: En la primera nos quejaremos de la gravedad y les echaremos la culpa por incompetentes y diremos que software libre no equivale a seguridad, y en la segunda nos alegramos porque nuestro software tiene un error menos por descubrir ( nunca estaremos libres de errores ) y porque el desarrollo del mismo es transparente a los usuarios finales, o quizá una mezcla de ambas.

Compártelo