Saltar a contenido

Recuperación de credenciales de cámaras desde Milestone

Verificado en vivo el 2026-09-20 contra XProtect VMS 2026 R1 en SRV-MILESTONE (192.0.2.50).

La respuesta corta

Sí. Con credenciales de administrador del VMS se pueden recuperar las contraseñas en claro de todas las cámaras dadas de alta, sin tocar la base de datos ni descifrar nada.

La prueba

Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force -Scope AllUsers -Confirm:$false
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
Install-Module MilestonePSTools -Scope AllUsers -Force -AllowClobber -SkipPublisherCheck

Import-Module MilestonePSTools
Connect-Vms -ServerAddress "http://localhost" -AcceptEula

Get-VmsHardware | Where-Object { $_.Name -match 'Hanwha' } | Get-VmsHardwarePassword

Resultado: devolvió la contraseña real de la cámara, verificada contra la que funciona por SUNAPI.

Para volcar el inventario completo:

Get-VmsHardware | ForEach-Object {
    [PSCustomObject]@{
        Nombre   = $_.Name
        Address  = $_.Address
        Usuario  = $_.UserName
        Password = ($_ | Get-VmsHardwarePassword)
    }
}

Por qué funciona

No es una vulnerabilidad ni un bypass. Es funcionalidad documentada y por diseño:

  • El Recording Server necesita la contraseña en claro para hablar con la cámara, así que el sistema tiene que poder descifrarla. No es un hash, es cifrado reversible.
  • El Management Client ya expone esto en la UI: en Recording Servers → hardware → pestaña Settings hay un botón que revela la contraseña a un administrador.
  • Get-VmsHardwarePassword no descifra nada localmente: le pide al Management Server que la revele, por MIP SDK, exactamente igual que el Management Client. El servidor decide si tu rol tiene permiso.

La columna Hardware.EncryptedPassword de la base Surveillance está cifrada con material de clave del servidor. No hace falta ir por ahí, y hacerlo sería frágil y no soportado.

Lo que esto implica para el proyecto

Es la razón por la que HanwhaZoneBridge no necesita su propio almacén de credenciales. Se autentica una vez contra el Management Server y obtiene IP, usuario y contraseña de cada cámara desde la config de Milestone, que ya es la fuente de verdad.

A 100+ cámaras esto es la diferencia entre un producto usable y uno que no:

  • Alta de cámara nueva en Milestone → el panel la ve sola, sin configurar nada.
  • Cambio de contraseña de una cámara → se propaga solo en el siguiente refresco.
  • Cero riesgo de un segundo inventario de credenciales desactualizado.
  • Cero credenciales nuestras que proteger, rotar o auditar.

Requisito: la cuenta de servicio necesita rol con permiso de lectura de contraseñas de hardware en el VMS.

Lo que esto implica para la seguridad

Vale la pena tenerlo presente más allá de este desarrollo:

  • Un administrador del VMS es, efectivamente, administrador de todas las cámaras. Si esas credenciales se reusan en otros equipos de la red, el alcance de un compromiso del Management Server es mucho mayor que "ver video".
  • Conviene que las cámaras usen credenciales dedicadas, distintas de cualquier otra cosa en la red, y sin reuso entre sitios.
  • Conviene revisar qué roles del VMS tienen permiso de administración de hardware. No todo operador necesita ese rol.
  • La recuperación de contraseñas queda en el log de auditoría del Management Server. Vale la pena que el servicio use una cuenta propia identificable y no la de un humano, para que la auditoría sea legible.

Nada de esto es exclusivo de Milestone: cualquier VMS que hable con cámaras tiene que poder recuperar la credencial. Es inherente al problema.