El dia 8 de abril de 2017 el conocido grupo denominado ShadowBrokers libero la password para descifrar el archivo conocido como
EQGRP-Auction-Files a traves de este post en
medium.com.
Horas despues la comunidad de seguridad informatica estaba analizando en las redes sociales mas usadas como Twitter y Reedit el contenido de este leak.
Este articulo trata sobre el reversing realizado al exploit encontrado en este leak, mas especificamente sobre el exploit denominado
EPICHERO.
EPICHERO es un
RCE (zero-day) con privilegios de
ROOT en
Avaya Communication Manager, la vulnerabilidad reside en el CGI
/auth-cgi-bin/distUpgReq cuyo parametro
POST licfile es vulnerable a
Command injection.
EPICHERO, segun la
documentacion encontrada en el leak, es un zero day (No hay un CVE publico que referencie el bug)
RCE con privilegios de
ROOT en
Avaya call server para la version
S8710-013-00.0.340.3.
'Avaya call server' es un nombre generico, segun la
documentacion (Pagina 7, Parrafo 1.1), para referirse a sus
hardware Appliance, que corren el software Avaya Communication Manager.
Debido a esto, nos fue imposible verificar realmente que el exploit sea funcional y especificar todas las versiones vulnerables.
El impacto de la vulnerabilidad mas alla de ser una ejecucion de codigo es mas que notable, el servidor S8710 es un servidor comercial para enrutar voz, data y video.
Debido a esto, comprometiendo este servidor podrias sniffear el trafico enrutado y como consecuencia, grabar llamadas SIP, redirigirlas o explotar cualquier tecnica conocida contra un servidor SIP.
Mas alla de esto, dado la envergadura del leak y su victima (NSA) es muy posible que estemos ante un exploit realmente operacional.
Un vistazo rapido del exploit utilizando 'file' nos arroja la siguiente informacion:
eh.1.1.0.0: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
Es un binario ELF el cual no fue stripped, lo cual nos facilito bastante el reversing del mismo al mantener nombres de funciones y variables globales!
Utilizando 'strings', llegamos a dos strings bastantes interesantes...
GCC: (GNU) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
Version de GCC y SO utilizado por el exploit writer.
y lo mas importante...
TYPE=licxfer&ftp=%s&source=/var/home/ftp/pub&version=NA&licfile=;echo "
Como se puede ver en la imagen el exploit permite:- Especificar el nombre del log file.
- Salvar el tiempo MAC de los archivos modificados por el mismo.
- Indicar un script como payload.
- Correr este ultimo como Root.
- Realizar un escaneo de version del servidor.
Comenzamos reverseando la funcion main, en un principio solo vemos un switch encargado del parseo de los parametros.Rapidamente podemos notar algo particular: un fuerte chequeo de errores.
Esto, junto con el log intensivo de cada variable, demuestra que estamos ante un exploit profesional y no una simple PoC, en donde se puso mucho esfuerzo para que sea utilizable por pentesters mas alla del exploit writer.
Continuamos analizando el main y unos bloques nos llaman la atencion
Tenemos un certificado en formato PEM y su clave privada!Pero por que esta esto aqui?
Esta es la informacion del certificado, junto con una comprobacion de matcheo entre certificado y clave privada...
Common Name: 130.62.9.101
Organization: Avaya Inc.
Organization Unit: s8700
Country: US
Valid From: May 17, 2006
Valid To: May 9, 2036
Issuer: Avaya Call Server, Avaya Inc.
Serial Number: 5024b4b220060517120931
El certificado esta firmado por Avaya Inc, lo que corresponde con la
documentacion del producto el cual indica que los certificados son autofirmados por Avaya.
Ademas de esto fue creado para
130.62.9.101, probablemente uno de los
targets de la NSA para este exploit.
Ok, pero para que se utiliza? Como esta autofirmado el certificado por Avaya, no esta la CA en ningun chain publico de cualquier sistema operativo.
Debido a esto es necesario agregar el certificado al chain para poder establecer una conexion HTTPS que el exploit necesita.
Pero ademas de agregar el
certificado al chain agrega la
clave privada al objecto Ctx?
Si correcto, esto es debido a que tienen una funcion llamada 'client_comm' la cual es llamada una unica vez desde el main, esta se encarga de crear el objeto SSL_CTX necesario para establecer la conexion SSL y chequear que la funcion de cliente, asi como tambien de servidor, funcionen correctamente en el exploit. Recuerdan el fuerte chequeo de errores?
Una de las funcionalidades del exploit es actuar como escaner para poder comprobar la version del Appliance, asi que vamos a ver como lo hace...
La funcion '
version_scan' arma linea a linea un
Request POST a /auth-cgi-bin/distUpgReq enviado por HTTPS, con los siguientes parametros:
TYPE=query&ftp=[VICTIM_IP]&source=/var/home/ftp/pub&version=NA
Parsea la respuesta en busca de los substrings:
version=
patch=
sid=
mid=
Y luego busca un '\n' al final de esos substrings, a medida que va printeando en la consola (En modo verbose) el resultado de cada variable buscada.
Finalmente llegamos a la funcion 'exploit'!En esta funcion nos encontramos con una sorpresa, hay codigo muerto, codigo que no se ejecuta nunca debido a que dos variables globales no son instanciadas en ningun momento del exploit.
Estas variables globales en cuestion se llaman 'BinFile' y 'AscFile', a continuacion pueden ver los resultados de buscar todas las instrucciones que se refieran a ellas en el exploit.
La mejor teoria que podemos tener acerca de esto, es que el exploit writer por una cuestion de tiempo refactoreo el envio de files y ejecucion, olvidandose de este bloque de codigo y/o dejandolo ya que nunca iba a ejecutarse.
Bien, dejando esto de una lado esto, el exploit sigue este camino.
- Crea 2 paths aleatorios en /tmp/%d y otro en /tftpboot/%d. Reemplazando %d por un numero aleatorio.
- A continuacion aparece todo el codigo muerto dentro de un if(BinFile) y if(AscFile), como vimos esto no se ejecuta nunca.
Un loop que va leyendo cada 1024 bytes el payload especificado desde un file, para ser encodeado con URL encode.
Si es la primera linea leida y si se pidio privilegios de root para el script file:
- Se construye un comando que mueve todo en /tftpboot/%numero_aleatorio (Un backup) a /opt/ws/%nombre_original/webupgrade (Su sitio original) y elimina este backup.
- Se concatena a un buffer, el comando del payload leido y luego el del punto anterior.
Si no es la primera linea leida:
- Copiamos esta linea del payload a un buffer.
Cuando este buffer se llena (> 724 ) en un iteracion posterior del loop.
- Se hace uso de snd_n_append enviando el comando guardado en el buffer anterior y guarda todo en el primer path aleatorio en /tmp, lo llamaremos path_random1.
Esto ocurre en un loop infinito hasta que se termina de leer el script payload del usuario, aca es cuando ocurre todo...
- Si quedo algun comando pendiente por enviar, se envia usando snd_n_append.
- Se construye un comando que borra los dos paths aleatorios creados (path_random1 y path_random2) y este se escribe en path_random1.
- En path_random2 se escribe un comando que ejecuta el path_random1 redireccionando los streams a /dev/null.
- Si el usuario pidio privilegios de Root:
- Se salva los MAC de todos los files y directorios en /opt, ademas se cambian su MAC al de ese instante.
- Lo mismo con /tftpboot/
- Lo mismo con /opt/ws/
- Hace un enlace de cada archivo y directorio de /opt/ws/*/webupgrade (Menos los enlace) al path de tftpboot.
- Se ejecuta: sudo /opt/ws/webinstall modifyFileEntry /opt/ws/webupgrade "." /opt/ws/functions | . %path_random2 | exit
- Se ejecuta: sudo /opt/ws/webupgrade
- Si el usuario no pidio Root: Ejecuto directamente el %path_random2
- Si el usuario proporciona los archivos cuyas MAC quiere cambiar el exploit setea la MAC, al tiempo actual, a cada archivo.
Perfecto aca tenemos ejecucion de codigo y todas las funcionalidades del exploit explicadas.
De manera simplificada el archivo %path_random2 termina ejecutando %path_random1 que contiene el payload del usuario, ademas se ejecutan los comandos necesarios para cambiar el MAC de los archivos y directorios asi como tambien los comandos para ganar privilegios de ROOT.
Esto ultimo es posible usando 'sudo', por que lo estimamos que el usuario que corre el codigo vulnerable tiene acceso a el uso de 'sudo', una mala practica de seguridad para usuarios que corren servicios como servidores HTTP.
En cuanto a los binarios ejecutados en /opt/ws, debido a que no tenemos acceso al software y en internet no hay documentacion acerca de ellos no podemos especificar nada.
Ok perfecto ya tenemos todo, pero cual es la vulnerabilidad?!
La vulnerabilidad es explotada en la funcion
bld_n_snd_http, veanlo por ustedes mismos...
'aTypeLicxFerF_7' es el format string que crea los parametros POST enviados en un
Request POST via
HTTPS, a un
CGI en
/auth-cgi-bin/distUpgReq.
Ven ese '
;echo' en el parametro
licfile? Es claramente un
Command Injection, ese CGI esta concatenando el parametro en un comando que luego es ejecutado en una Shell, asi es como la NSA logro ejecucion de codigo.
La funcion
snd_n_append mencionada anteriormente, que escribia un file en el sistema remoto, es simplemente un Wrapper de esta ultima funcion.
Lee el archivo enviado por parametro y luego llama a
bld_n_snd_http pasandole como parametro un string con los parametros POST de este CGI.
Para finalizar me gustaria mencionar que hay un script en el leak
/Linux/bin/epichero/cleanup.script el cual realiza una inspeccion de los logs de apache y borra cualquier rastro del exploit de manera detallada.
Ademas de esto, restaura los backups del directorio /opt/ws y elimina el archivo /var/iglut/upg_status.dat
Por ultimo un dato interesante en el mismo directorio de este script, esta la reverse shell utilizada por la NSA y que contiene una direccion IPv4
206.210.129.25 (Amphitheater Public Schools).Posiblemente este sea uno de los servidores hackeados por la NSA para esconder los rastros de sus Shells y exploits.
El exploit esta desarrollado con un fuerte chequeo de errores, features contra analisis forense como cambiar el MAC de los archivos y directorios, ademas de un fuerte log de cada accion realizada por el exploit.
Todo esto demuestra grandes esfuerzos dedicados en crear un exploit lo mas eficaz posible y sigiloso para evitar cualquier tipo de alerta, asi como tambien en la obtencion y utilizacion de servidores vulnerados anteriormente para utilizarlos como receivers de sus Reverse Shells.
Creditos
Ezequiel Tavella - Infobyte Security Research Lab.
