mdm_privacy.webp

Por alguna puta razón ahora tengo que gestionar MDM para muchas empresas. Así que supuse que iba a tener que aprender con más profundidad cómo funcionan…

Algunas empresas les dan a sus empleados un “teléfono de trabajo” o les piden que descarguen software para usar aplicaciones laborales en sus teléfonos personales. El tema es que no es solo darle acceso a recursos de la empresa, sino que también les permite a los admins/IT ver muchos más detalles de tu teléfono y su uso. Algo así como un spyware.

MDM (Mobile Device Management) es como una capa invisible entre el hardware (el teléfono) y el equipo de IT de la empresa/organización. Hay muchas razones por las que una empresa querría implementar MDM, como cumplimiento de seguridad, borrado remoto de datos cuando se pierden dispositivos, forzar cifrado, monitorear el uso correcto, etc. Sin embargo, también les permite a los empleadores ver el comportamiento del empleado con un nivel de detalle sorprendente.

Mucha gente tiene dispositivos iOS pero me voy a enfocar en Android, porque que se joda Apple.

¿Qué es el Software MDM?

MDM (Mobile Device Management) no es spyware. No te graba el micrófono ni captura la pantalla a demanda. Es un framework: una combinación de agentes a nivel de dispositivo, servidores de políticas en la nube y APIs a nivel de OS que permiten a los administradores de IT configurar, monitorear y controlar dispositivos enrolados a escala.

Las principales plataformas son Microsoft Intune, VMware Workspace ONE e IBM MaaS360. Todas se conectan a las mismas APIs subyacentes del OS, y básicamente se diferencian en funcionalidades, no en capacidad fundamental.

Lo más importante a entender es que lo que MDM puede ver depende de cómo fue enrolado el dispositivo. Un teléfono emitido por la empresa enrolado en modo de gestión completa del dispositivo es mucho más una pesadilla para la privacidad que un teléfono personal enrolado en un work profile BYOD.

Qué Puede Ver Tu Empleador Realmente

mdm_user_sad.webp

En un dispositivo de la empresa, completamente gestionado, la plataforma MDM del empleador tiene acceso a nivel de device owner al OS de Android. Eso incluye:

  • Cada app instalada en el dispositivo
  • Ubicación GPS en tiempo real e histórica
  • Nivel de batería
  • Redes Wi-Fi a las que se conectó el dispositivo
  • Volumen de tráfico de datos móviles y Wi-Fi por app
  • Estado de compliance del dispositivo (¿rooteado? ¿bloqueo de pantalla configurado? ¿OS parcheado?)
  • Historial de navegación, cuando se implementa un perfil de navegador gestionado

En un teléfono personal enrolado mediante Android Work Profile (la configuración BYOD estándar), el perfil es un container aislado que corre bajo un user ID separado. El MDM está limitado a los permisos de profile owner y no puede acceder al lado personal del dispositivo. Las apps personales, fotos, mensajes e historial de navegación son invisibles para IT.

Cómo Funciona el MDM en Android

Los Tres Modos de Gestión

El framework Android Enterprise de Google tiene 3 modos de gestión, cada uno otorgando diferentes niveles de acceso al OS a la app DPC (Device Policy Controller) desplegada.

flowchart TB
    subgraph DO["COMPLETAMENTE GESTIONADO: Device Owner"]
        D1["DPC = Device Owner<br>Control total del OS, dispositivo solo de trabajo"]
        D2["Ve: todas las apps instaladas<br>Ubicación GPS<br>Uso de red por app<br>Aplicación de políticas en todo el dispositivo"]
        D1 --> D2
    end

    subgraph COPE["WORK PROFILE EN DISPOSITIVO DE LA EMPRESA, Android 11+"]
        C1["DPC = Profile Owner<br>con políticas elevadas de dispositivo de empresa"]
        C2["Work Profile<br>IT gestiona completamente: apps, datos, políticas"]
        C3["Lado personal<br>Contenido de apps invisible para IT<br>Políticas de seguridad aplicadas en todo el dispositivo"]
        C1 --> C2
        C1 --> C3
    end

    subgraph BYOD["WORK PROFILE: Dispositivo Personal"]
        B1["DPC = Profile Owner solamente"]
        B2["Work Profile<br>IT gestiona completamente"]
        B3["Lado personal<br>Barrera kernel impuesta por el OS<br>IT no tiene ningún acceso"]
        B1 --> B2
        B2 -. "bloqueado, Linux UID separado" .-> B3
    end

    style DO fill:#1a2e1a,stroke:#4caf50,color:#e8f5e9
    style COPE fill:#1a1a2e,stroke:#5c7cfa,color:#e8eaf6
    style BYOD fill:#2e1a1a,stroke:#ef5350,color:#fce4ec

Completamente Gestionado (Device Owner): La empresa es dueña y controla el dispositivo completo.

Work Profile En Dispositivo De La Empresa: El DPC actúa como Profile Owner con acceso a políticas extendidas de dispositivo de empresa mediante getParentProfileInstance(). IT gestiona completamente el work profile y puede aplicar políticas de seguridad en todo el dispositivo como bloqueo de pantalla y cifrado, pero los datos de apps personales permanecen inaccesibles.

Work Profile En Dispositivo Personal (BYOD): Esta es la separación de privacidad más estricta. IT no puede ver el perfil personal. ¡Genial!

Cómo Se Otorga el Estado de Device Owner

El modo Device Owner solo puede configurarse en un teléfono con reset de fábrica o uno nuevo. El proceso de provisioning es orquestado por el asistente de configuración de Android, que otorga el estado Device Owner al paquete DPC especificado mediante una llamada interna al sistema. Los métodos de enrollment son:

flowchart LR
    subgraph ZT["Zero-Touch"]
        ZT1["Dispositivo comprado<br>de revendedor autorizado"] --> ZT2["IT pre-registra<br>IMEI en portal ZT"]
        ZT2 --> ZT3["Primer arranque contacta<br>servidores ZT de Google"]
        ZT3 --> ZT4["DPC APK descargado<br>e instalado silenciosamente"]
    end
 
    subgraph QR["QR Code"]
        QR1["Dispositivo con reset de fábrica"] --> QR2["Tocar la pantalla de configuración<br>6 veces en el mismo lugar"]
        QR2 --> QR3["Escanear código QR desde<br>la consola de IT"]
        QR3 --> QR4["El payload JSON decodifica:<br>paquete DPC, URL del APK,<br>token de enrollment, credenciales WiFi"]
        QR4 --> QR5["Android descarga<br>e instala el DPC APK"]
    end
 
    subgraph AFW["DPC Identifier"]
        AFW1["Dispositivo con reset de fábrica"] --> AFW2["Ingresar afw#setup<br>en vez de cuenta de Google<br>en el asistente de configuración"]
        AFW2 --> AFW3["El asistente descarga el DPC<br>desde Play Store"]
    end
 
    subgraph KME["Knox Mobile Enrollment<br>Solo Samsung"]
        KME1["Registrar IMEI del dispositivo<br>o número de serie en portal Knox<br>(sin necesidad de revendedor)"] --> KME2["El dispositivo obtiene la configuración<br>y el DPC en el primer arranque"]
    end
 
    subgraph FINAL["Provisioning Completado"]
        F1["DPC instalado"] --> F2["El asistente de configuración otorga<br>estado de Device Owner<br>al paquete DPC"]
        F2 --> F3["El dispositivo se enrolla con<br>el servidor MDM en la nube"]
        F3 --> F4["Políticas enviadas:<br>certificados CA, configuración VPN,<br>restricciones de apps,<br>reporte de ubicación..."]
    end
 
    ZT --> FINAL
    QR --> FINAL
    AFW --> FINAL
    KME --> FINAL
 
    style ZT fill:#1a2e1a,stroke:#4caf50,color:#e8f5e9
    style QR fill:#1a1a2e,stroke:#5c7cfa,color:#e8eaf6
    style AFW fill:#2e1f1a,stroke:#ffa726,color:#fff3e0
    style KME fill:#2e2e1a,stroke:#cddc39,color:#f9fbe7
    style FINAL fill:#1a1a1a,stroke:#ef5350,color:#fce4ec

El Problema de la Inspección SSL

Cuando un MDM empuja un certificado CA raíz corporativo, el OS lo agrega al sistema de confianza. Cada conexión TLS que valida contra el sistema de confianza (que son la mayoría) ahora confía en certificados firmados por ese CA. Combinado con setAlwaysOnVpnPackage(lockdownEnabled = true), la empresa enruta todo el tráfico del dispositivo a través de un proxy corporativo que realiza una inspección TLS completa de break-and-inspect:

flowchart TB
    subgraph PREREQ["Pre-Condiciones del MDM Activas"]
        S1["installCaCert<br>CA raíz corporativo enviado al sistema de confianza"]
        S2["setAlwaysOnVpnPackage lockdown=true<br>Todo el tráfico enrutado a través del proxy de la organización"]
    end

    subgraph INTERCEPT["Solicitud HTTPS Estándar: Interceptada"]
        N1["La app envía TLS ClientHello a example.com"]
        N2["El proxy corporativo intercepta la conexión"]
        N3["El proxy abre una sesión TLS separada a example.com<br>Recibe el certificado DigiCert real"]
        N4["El proxy presenta un certificado falsificado a la app<br>CA corporativo firmó example.com<br>La app confía en el CA corporativo, no se muestra advertencia"]
        N5["La solicitud de la app es descifrada por el proxy<br>Registrada en la consola de IT<br>Re-cifrada y reenviada al servidor"]
        N6["La respuesta del servidor es descifrada por el proxy<br>Registrada en la consola de IT<br>Re-cifrada de vuelta a la app"]
        N1 --> N2 --> N3 --> N4 --> N5 --> N6
    end

    subgraph PINNED["Apps Con Certificate Pinning: No Interceptables"]
        P1["La app envía TLS ClientHello a los servidores de Signal"]
        P2["El proxy presenta certificado firmado por CA corporativo"]
        P3["La app verifica el fingerprint del certificado contra el valor hardcodeado<br>Fingerprint no coincide, conexión rechazada<br>No es posible la interceptación silenciosa"]
        P1 --> P2 --> P3
    end

    PREREQ --> INTERCEPT
    PREREQ --> PINNED

    style PREREQ fill:#1a1a2e,stroke:#5c7cfa,color:#e8eaf6
    style INTERCEPT fill:#2e1a1a,stroke:#ef5350,color:#fce4ec
    style PINNED fill:#1a2e1a,stroke:#4caf50,color:#e8f5e9

El proxy descifra el tráfico, lo inspecciona para detectar violaciones de políticas DLP, lo registra, lo re-cifra con un certificado firmado por el CA corporativo y lo reenvía. Desde la perspectiva de la app, el TLS fue exitoso. Desde la perspectiva de IT, vieron el texto plano.

¿Qué Puedo Hacer? Certificate pinning. Las apps que hardcodean los fingerprints de certificados esperados (como Signal) validan la cadena de certificados independientemente del sistema de confianza del OS. Si el fingerprint no coincide con lo que la app espera, la conexión falla en vez de aceptar silenciosamente el certificado del proxy. El tráfico de Signal aparece ante el proxy corporativo como un stream TLS opaco a los servidores de Signal; el proxy no puede descifrarlo y no puede proveer un certificado falsificado plausible que Signal aceptaría.

Verificá el Estado de Enrollment de tu Dispositivo Android

Los pasos varían según la marca/OEM, pero estos son para Samsung.

Verificá Si el MDM Está Activo:

  • Cualquier app listada aquí tiene permisos de administración del dispositivo elevados
Settings → Security and privacy → More security settings → Device admin apps

Verificá el Modo de Gestión:

  • Un Work Profile aparece como una sección separada con un ícono de maletín en los íconos de las apps del lado de trabajo. Si no aparece ningún work profile pero hay apps de administración del dispositivo presentes, estás en un dispositivo completamente gestionado sin separación personal/trabajo
Settings → Accounts and backup → Manage accounts

Verificá los Certificados CA Enviados:

  • Cualquier certificado en la pestaña User que no instalaste vos mismo fue enviado por un MDM
  • En un dispositivo completamente gestionado también revisá la pestaña System, ya que los DPCs con Device Owner pueden instalar CAs a nivel del sistema donde son menos visibles
Settings → Security and privacy → More security settings → View security cetificated → User tab

Verificá la VPN Always-on:

  • Un perfil VPN con un ícono de candado y sin opción para desconectar es una VPN always-on impuesta por el MDM. Cada paquete que enviás pasa por la infraestructura corporativa sin importar en qué red estés, incluyendo la red celular
Settings → Connections → More connection settings → VPN

Qué Podés Hacer

No me gustan los dispositivos controlados por MDM. La protección más efectiva es tener un dispositivo separado para el trabajo y otro para uso personal (nunca los mezcles, la tecnología mejora y se vuelve cada vez más anti-privacidad). Usar un teléfono de la empresa para actividad personal es efectivamente consentir el monitoreo, ya sea que estés al tanto del alcance completo o no.

Si querés comunicarte con otra persona, usá un dispositivo personal privado y usá Signal. El certificate pinning evita que el proxy de inspección SSL corporativo intercepte el tráfico de Signal. El cifrado de extremo a extremo significa que el contenido está protegido de todas formas. El MDM puede ver que Signal está instalado y que hay tráfico fluyendo hacia los servidores de Signal, pero no puede ver qué estás diciendo.

No inicies sesión en cuentas personales en un dispositivo gestionado usando el navegador corporativo ni ninguna app sin certificate pinning. En un despliegue de VPN always-on, asumí que el proxy ve el texto plano de esas sesiones.

Por último, leé el acuerdo BYOD de tu empresa. Siempre vas a estar jodido, pero a nadie le importa supongo…