Tal y como comenté en esta entrada y dado que Cacert parece estarse tomando las cosas en serio (además de que no me ha fallado hasta hoy), y aprovechando además, algunas ideas que me ha dado la nueva configuración del vhost por defecto de apache en gentoo. He reconfigurado todos los hosts virtuales para que podáis acceder a ellos usando http seguro. Y además, en algunos he forzado, usando mod_rewrite, a que se acceda así (mayormente el sistema de webmail del servidor y el de configuración de la DB por lo que no deberíais de notarlo).
Para esto, simplemente he utilizado la directiva include para reaprovechar las configuraciones del los hosts y así, poder disponer de unas configuraciones bastante sencillas y mínimas para configurar el sistema ssl y, además, garantizar que los cambios en las configuraciones se vean independientemente de como se acceda al host virtual.

Además, he aprovechado para desactivar algunos host de proyectos que o bien ya no se alojan en este sitio, cómo hyperchess que ahora es la ACUV o que nunca han llegado a dar frutos y han muerto.

Cómo siempre os agradecería que me comentáseis cualquier cosa rara que veáis.

De estas vulnerabilidades una tiene un grado deseveridad crítico y afecta a los foros del sistema de comunicaciones del poliformat mientras que la segunda afecta particularmente (lo que no significa únicamente) al sistema de correo del DSIC y tiene un grado de severidad moderado.

Empecemos.

La primera vulnerabilidad es muy fácil de explotar y es debida a una mala configuración de los permisos por defecto que da el poliformat. Posiblemente, también afecte a otros sistemas basados en sakai con versiones semejantes. Dicha vulnerabilidad permite en cualquier foro donde se apliquen los permisos por defecto, que los alumnos puedan editar los mensajes de otros usuarios, revisando, además, los permisos para impedir a otros usuarios volver a editarlos. Para revisar los permisos simplemente hay que hacer clic en el botón “Configurar Tema”, luego abajo en el botón “Revisar” y voila ya podéis tanto editar el tema como los permisos (esto último haciendo clic en la pestaña de Permisos).
Ahora que ya tenéis permisos para editar todos los mensajes (aplicando a alumnos la opción de “Revisar Enviados:” “Todos”), podéis proceder a la edición de los mismos: abrís el mensaje a editar, le dais al botón revisar y listo, ya podéis revisarlo.

Hay que añadir que esta vulnerabilidad tiene fácil solución modificando tanto los permisos que se asignan por defecto a los temas como los de los temas ya publicados.

Aviso Importante: Generalmente sakai añade a los mensajes revisados quien ha hecho la última revisión, eso significa que en caso de que aprovechéis esta vulnerabilidad, será fácil descubrir quien es el responsable.

Pasemos a la vulnerabilidad del sistema de correo del DSIC. En el DSIC utilizan Amavisd-new cómo sistema de filtrado de correo y lo tienen configurado para que notifique al remitente en caso de que el correo no pueda ser entregado. Entre otras restricciones tienen la imposibilidad de mandar archivos con el mime-type de ejecutable.
¿Cómo utilizar dicha vulnerabilidad?
Muy sencillo en primer lugar debemos crearnos un mensaje que contenga dichas cabeceras o un ejecutable, en él debemos editar el campo FROM para que parezca haber sido enviado por la víctima y el TO: por la dirección de un profesor del DSIC. Ahora lo guardamos y utilizando un programa como mail y un bucle while lo enviamos indefinidamente a la cuenta del profesor (que también puede ser la víctima). Si hemos sido inteligentes nuestro mensaje no debería llegar a ocupar más de 1k; ahora, si esperamos comprobaremos como la cuenta de la víctima se va llenando de avisos que ocupan al menos 5ks. Esto nos permitiría bombardear fácilmente la cuenta (y la cuota) de una víctima aumentando varias veces la velocidad y efectividad del ataque. Evidentemente, en caso de que cambien las políticas de amavisd, dicha vulnerabilidad será evitada.

Aviso Importante: En las cabeceras de vuestros mensajes, que son añadidas al mensaje de aviso, constan entre otras cosas la dirección IP desde la que se ha enviado el mensaje. Si apreciáis vuestros traseros mínimante, y no queréis acabar en el cuadro de honor de los técnicos del DSIC (y que si os reconocen os corten las pelotas) utilizareis al menos uno o dos proxys para la ejecución del programa de bombardeo.