Posted in Advisories on November 30th, 2007 by m313
En menos de un día los competentes trabajadores del FSIRT han modificado el aviso de seguridad FrSIRT/ADV-2007-4021 para incluir mi nombre en los creditos de la vulnerabilidad:
Sigo esperando una rectificación por parte de KJ.
Posted in Advisories on November 30th, 2007 by m313
Autor: Daniel Medianero García ( dmedianero @ gmail.com )
Fabricante: BASE – http://base.secureideas.net/
Impacto: Cross Site Scripting
URL: http://www.meleagro.es.kz
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
Posted in Advisories on November 29th, 2007 by m313
Es increible, la degeneración desde el software libre al imperialismo personalista de los que creen ya no que las herramientas son de su propiedad, sino que utilizan el conocimiento de los demás para ponerse medallas que no merecen.
Estoy hablando del BUG de BASE que llevo mareando desde hace dos meses. Ese bug que YO, DANIEL MEDIANERO GARCÍA, meleagro, m313 descubrí, ese bug que no reporté publiamente hasta ver que no lo tomaban en serio, y que a raiz de su publicación ha sido corregido recientemente en la nueva release de BASE 1.3.9 (anne).
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.
Posted in Advisories on October 3rd, 2007 by m313
No es un secreto que las vulnerabilidades XSS(Cross Site Scripting) abundan en la red, como tampoco lo es que los programadores no otorgan a estas vulnerabilidades la relevancia que merecen.
A menudo evidencio un XSS con un simple script que muestra una ventana con la cookie del usuario, un simple script con un alert y un document.cookie en su interior.
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.
Posted in Advisories on March 13th, 2006 by m313
Hace unos dias Teotihuacan ponía un mensaje en los foros de Ubuntu, lo más destacable era esto:
“There is a file that contains all the installation logs :
/var/log/installer/cdebconf/questions.dat
In this file, there is all the questions asked to the user abd all the user’s answers.
So, near the end of the file, we can find the user created during the installation… and its password (not hidden).”
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.