Open Journal Systems: ¿Que tan bueno es no tener vulnerabilidades?

Open Journal Systems (OJS) es un  CMS especializado en la gestión de publicaciones científicas desarrollado por el Public Knowledge Project . Es muy usado en instituciones académicas y científicas, me atrevería a afirmar que la mayoría de las universidades, de todo el mundo, tienen una instalación de OJS. Sus ventajas para gestionar todo el flujo de revisión de los artículos propuestos son indiscutibles.

Sin embargo, OJS tiene dos problemas fundamentales que lo hacen vulnerable frente a los ciberataques, estos son:

  1. Mala política de comunicación de problemas de seguridad: No hay que ser especialista para darse cuenta que es imposible que un producto basado en PHP, cuya primera versión data del 2001, tenga solamente tres vulnerabilidades publicadas. Si tenemos en cuenta además que esas tres vulnerabilidades fueron hechas públicas por una tercera organización (Hight-Tech Bridge), podemos concluir que la política de divulgación de problemas de seguridad es inadecuada, lo que provoca que si usted es un sysadmin preocupado y busca las vulnerabilidades conocidas que pueda tener su versión de OJS, lo más seguro es que la información que encontrará le hará sentirse confiado y feliz pues solamente hay tres vulnerabilidades conocidas de OJS y todas afectan a versiones por debajo de la  2.3.7. Pero esto no quiere decir que sea totalmente cierto.
  2. Subida de archivos con código dañino: La propia naturaleza del proceso que informatiza OJS requiere que además del artículo a publicar, se suban archivos anexos los cuales pueden tener códigos fuentes y otros elementos que pueden comprometer la seguridad de los servidores de despliegue. Un ciberdelincuente puede hacerse pasar por un investigador y subir una shellcode como si fuera un anexo o el artículo principal. En el blog ya tratamos de este tema en el artículo sobre la OTG-BUSLOGIC-008 .

Las vulnerabilidades descubiertas en el año 2012 supuestamente fueron solucionadas a partir de la versión 2.3.7. No obstante, recientemente algunos grupos de ciberdelincuentes han descubierto que este problema no se ha resuelto del todo  y han aprovechado ese conocimiento para explotar estas vulnerabilidades, específicamente la CVE-2012-1468, que permite la subida de código dañino.

No creo que sea relevante explicar la manera de explotar esta vulnerabilidad o de que país de Asia provienen estos ataques. Cualquiera que tenga acceso a Google y escriba las palabras claves ojs y deface  puede encontrar esta información al instante (spoiler alert: abre también el Google Traslate, no importa el nivel de inglés que tengas). Lo que sí creo importante es comunicar que la explotación de esta vulnerabilidad es demasiado simple y con la shellcode correcta puede poner de rodillas una red entera.

figura-1

Figura 1. La búsqueda en Google muestra 7590 resultados, muchos de ellos del 2016 en idioma indonesio.

Por suerte, dificultar la explotación de esta vulnerabilidad es sencillo también:

  • Prohibir la subida de archivos con extensiones diferentes a .doc, .docx, odt, .pdf u otros de esta clase en las configuraciones del servidor web. Nunca, bajo ningún concepto permitas la subida de archivos con extensiones ejecutables del lado del servidor como .phtml, .asp, .php, .rb, .py, etc.
  • Seguir las orientaciones de los desarrolladores de OJS para su correcta instalación, específicamente, la instrucción de colocar fuera del directorio de despliegue de OJS, el directorio /files, el cual además no debe ser directamente accesible a través del user-agent: https://pkp.sfu.ca/ojs/README:

Create a directory to store uploaded files (submission files, etc.) and make this directory writeable. It is recommended that this directory be placed in a non-web-accessible location (or otherwise protected from direct access, such as via .htaccess rules).

systemadmininstallfilesettings

Figura 2. Estableciendo la ruta del directorio /files en el proceso de instalación de OJS. Fuente PKP.

  • Mantener siempre actualizada la instalación de OJS con la última versión de su rama y los parches correspondientes.

Es cierto que lleva tiempo y esfuerzo actualizar un despliegue de OJS que lleva mucho tiempo instalado, sin embargo, recuerda que peor será perder todo el trabajo realizado en ese tiempo por los investigadores y autores de la publicación basada en OJS. Recientemente se liberó la versión 3.0 de OJS. Vale la pena actualizarse a ella.

Espero que te haya gustado la entrada y te pueda ayudar a fortalecer la seguridad en las infraestructuras TIC bajo tu responsabilidad.

S4lud0s y h4st4 el próx1m0 p0st qu3 s3rá 3n 3l 2017. F3l1z N4v1d4d y f3l1c36 Fi3t46!!!

Anuncios

3 comentarios en “Open Journal Systems: ¿Que tan bueno es no tener vulnerabilidades?

  1. yraul, gracias por tu comentario. Trataré de preparar un artículo en los próximos días pero básicamente estamos hablando de vulnerabilidades que permiten la subida de archivos con extensiones ejecutables y la posibilidad de calcular exactamente la ruta física de estos con el objetivo de poderlos instanciar y ejecutar.

    Me gusta

  2. Pingback: Análisis de la shellcode IndoXploit | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s