Especialista en Seguridad de la Información, otoño de Reiwa 5, pregunta 2 de la tarde — Archivos sustraídos por el Wi-Fi de invitados

Prohibieron conectar memorias USB. Prohibieron guardar archivos en el disco local. Bloquearon la comunicación con el webmail y el almacenamiento en la nube no autorizados por la empresa. Prohibieron adjuntar archivos al correo electrónico. Dieron de baja el servidor de archivos interno.

Aun así, los archivos de trabajo se pueden sacar de la empresa.

La pregunta 2 de la tarde del examen de Especialista en Seguridad de la Información, edición de otoño de Reiwa 5, plantea encontrar los huecos que aún quedan en la empresa textil M, que ya había implementado todas esas medidas¹. Este artículo es la segunda entrega de la serie que continúa la explicación de la pregunta 1 (XSS almacenado) anterior, y el ámbito pasa de la aplicación web a la red interna y la autenticación de equipos.

Si la pregunta 1 preguntaba «por dónde se coló el ataque entre las medidas alineadas en la aplicación web», la pregunta 2 pregunta «qué alcance pretendía cubrir el diseño de cada medida». Ninguna de las medidas de la empresa M está mal planteada. Solo que, al confirmar una por una el alcance que cada una pretendía cubrir, justo al lado queda un hueco abierto.

Lo que obtendrá de este artículo, además de los ejemplos de respuesta de cada pregunta y su fundamento, son puntos de verificación directamente aplicables en la práctica sobre tres áreas: LAN inalámbrica, certificado de servidor y restricción por dirección IP de origen. Está escrito para que tenga sentido tanto si lo lee por sección para preparar el examen como si va directo a los capítulos 11 y 12 buscando solo la perspectiva práctica.

1. Primero, la conclusión

• La brecha estaba en la sala de reuniones. La empresa M prohibía traer PCs personales, pero esa prohibición aplicaba solo a las oficinas; la sala de reuniones quedaba fuera. En la sala de reuniones hay señal tanto del Wi-Fi de empleados como del Wi-Fi de invitados
• Hay dos rutas de sustracción por parte de un empleado. El método de falsificar la dirección MAC para conectarse al Wi-Fi de empleados, y el método, mucho más simple, de conectarse sin más al Wi-Fi de invitados, para el que solo hace falta la clave precompartida que se entrega a las visitas
• El almacenamiento en la nube (Servicio B) restringía el acceso a «solo se puede iniciar sesión desde la dirección IP pública de la empresa M». Pero el tráfico del Wi-Fi de invitados también se convierte, por el mismo NAT, en la misma dirección IP pública, así que esa restricción se elude sin más. Una restricción por dirección IP de origen es una configuración que permite el acceso no a un equipo, sino a todos los que comparten esa salida
• Un AP falso y un sitio falso montados por un atacante externo se detienen en la verificación del certificado de servidor. Lo que funciona es comprobar «si lo emitió una entidad certificadora de confianza» y «si el nombre del servidor del certificado coincide con el del destino». Según los comentarios de calificación de IPA, el índice de aciertos de la pregunta sobre esos dos puntos fue bajo
• Aunque se escriba http:// por error, HSTS sustituye la conexión por HTTPS antes de conectarse, así que igualmente aparece un error de certificado. Y en un host donde HSTS está activo, no debe ofrecerse al usuario la opción de ignorar la advertencia y continuar
• La propia función de uso compartido de archivos legítima también sirve como ruta de sustracción: basta con indicar la propia dirección de correo personal como destinatario externo. Existía la aprobación de un superior, pero algunos superiores no verificaban el destinatario
• Las medidas propuestas se apoyan en tres pilares. Pasar el Wi-Fi de empleados a EAP-TLS, autenticando con un certificado de cliente por equipo, con la clave privada dentro del TPM para que no se pueda extraer del PC de trabajo. Separar el Wi-Fi de invitados de la red de la empresa M (o bien usar una dirección IP pública distinta como salida). Y eliminar las VLAN, reglas de filtrado y SSID que ya no se usan

2. Sobre el material — la fuente y el tratamiento en este artículo

El problema tratado es el siguiente.

Fuente: Examen de Especialista en Seguridad de la Información Certificado, edición de otoño de Reiwa 5, tarde, pregunta 2

IPA indica que, salvo que la ley disponga expresamente otra cosa, no hace falta permiso ni pago de derechos para usar los exámenes pasados que publica. Ahora bien, no renuncia a los derechos de autor: exige indicar la fuente en el formato «año, edición, categoría de examen, franja horaria, número de pregunta, etc.», y señalar explícitamente si el enunciado se ha modificado en parte².

Este artículo no reproduce tal cual las figuras y tablas del cuadernillo de examen. Se sustituyen por diagramas simplificados y resúmenes elaborados por esta empresa, en la medida necesaria para explicar el mecanismo. El texto de las preguntas y los ejemplos de respuesta también se tratan de forma resumida. El cuadernillo original, los ejemplos de respuesta y los comentarios de calificación se pueden descargar gratis desde la página de IPA, así que se recomienda tenerlos a mano mientras lee^{1 3 4}.

Correspondencia entre las preguntas y este artículo

Puede empezar a leer directamente por la pregunta que quiera resolver.

Lo que dice el cuadernillo de examen y cómo se trata en este artículo

Para que pueda contrastarlo con el texto original, aquí se resume qué se hizo con cada parte.

3. El escenario — lo que la empresa M «ya había hecho»

La empresa M es una filial de la empresa L, dedicada al sector textil, con 100 empleados. Su edificio de oficinas da a una gran avenida muy transitada del centro de Tokio. Esta frase resulta relevante más adelante.

El año anterior ocurrió un incidente en el que un empleado de la empresa M guardó en una memoria USB archivos confidenciales de diseño de productos que estaban en el servidor de archivos interno y los llevó a una empresa competidora. Por indicación de la empresa matriz L, se está revisando la seguridad. Ya se han implementado estas tres medidas.

• Se instaló software contra fugas de información en los portátiles prestados a los empleados (en adelante, PC de trabajo), configurando: prohibición de conectar dispositivos de almacenamiento externo como memorias USB, prohibición de guardar archivos en el disco local salvo para instalar software, bloqueo de la comunicación con webmail y almacenamiento en la nube no autorizados por la empresa, prohibición de instalar software no autorizado por la empresa, y prohibición de adjuntar archivos al enviar correo electrónico
• Se concentró el lugar donde se guardan los archivos de trabajo en un único punto: el almacenamiento en la nube que ya se usaba desde antes (en adelante, Servicio B), y se revisó su configuración
• Se dio de baja el servidor de archivos interno

Como el incidente anterior siguió la ruta «servidor de archivos interno» → «memoria USB», se taponaron ambos extremos de esa ruta. La lógica es coherente.

La configuración de la red

El edificio de oficinas tiene oficinas y una sala de reuniones. En las oficinas se puede usar el Wi-Fi de empleados; en la sala de reuniones se pueden usar tanto el de empleados como el de invitados. El proyector de la sala de reuniones se usa conectando al Wi-Fi de invitados un dispositivo que trae la visita (PC, tableta o smartphone) o bien un PC de trabajo.

Si se dibuja solo lo necesario para la explicación, queda así.

flowchart LR
    subgraph M["Red interna de la empresa M"]
        direction TB
        G["Wi-Fi de invitados<br/>192.168.10.0/24<br/>(solo el AP de la sala de reuniones)"]
        E["Wi-Fi de empleados<br/>192.168.20.0/24<br/>(oficinas y sala de reuniones)"]
        S["Red de servidores<br/>192.168.30.0/24<br/>DHCP, DNS, directorio"]
        FW["FW<br/>NAT que convierte el origen<br/>en una sola dirección IP<br/>pública"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Servicio B<br/>(almacenamiento en la nube)"]
    FW --> I["Internet"]

Las especificaciones que conviene retener, por su relevancia en las preguntas, son las siguientes.

Y hay tres reglas de seguridad: prohibido sacar el PC de trabajo fuera de la empresa, prohibido traer PCs, tabletas o smartphones personales a las oficinas y prohibido sacar archivos de trabajo fuera de la empresa por cualquier medio que no sea la función de uso compartido de archivos del Servicio B.

¿Se ha fijado en que la segunda regla dice «a las oficinas»? La sala de reuniones no se menciona.

Cómo avanza el caso

La señora Y, del departamento de sistemas, con el apoyo del señor S, Especialista en Seguridad de la Información Certificado (登録セキスペ) de la empresa matriz L, va comprobando si las medidas contra la sustracción de archivos desde el Servicio B son suficientes. Ambos analizan por separado la sustracción por un atacante externo y la sustracción por un empleado. La pregunta 1 corresponde a la primera y la pregunta 2 a la segunda; la pregunta 3 plantea las medidas.

4. El Wi-Fi falso y el sitio falso — preguntas 1(1) y 1(2)

Lo primero que plantea la señora Y es un escenario en el que un visitante que ya usó el Wi-Fi de invitados alguna vez, actuando como atacante, se conecta al Wi-Fi de invitados desde cerca de la empresa M y accede al Servicio B.

Este escenario funciona porque el método de autenticación de la LAN inalámbrica es WPA2-PSK. PSK (Pre-Shared Key, clave precompartida) es, como su nombre indica, un método en el que todos comparten la misma clave. La clave precompartida del Wi-Fi de invitados existe precisamente para dársela a las visitas. Una vez entregada, no hay forma de revocar que esa persona siga conociéndola (salvo cambiarla para todos). Y como el edificio de oficinas da a una avenida muy transitada, la señal llega incluso desde fuera del edificio.

La respuesta del señor S ante esto es contundente. Para iniciar sesión en el Servicio B hacen falta [a] un identificador de usuario y [b] una contraseña. Ese es el ejemplo de respuesta de la pregunta 1(1) (en cualquier orden). Conectarse al Wi-Fi por sí solo no equivale a iniciar sesión en el Servicio B.

El AP falso y el sitio falso

Entonces la señora Y plantea un escenario un paso más allá. ¿Qué pasa si se preparan un AP falso con la misma configuración que el AP de invitados, y un sitio falso con la misma URL que el Servicio B, y se manipula la configuración de DNS para robar el identificador de usuario y la contraseña? Si el AP falso se coloca cerca de la empresa M, un empleado podría conectar por error su PC de trabajo al AP falso, intentar acceder al Servicio B, acabar en el sitio falso e iniciar sesión sin darse cuenta.

Esto es lo que se conoce como evil twin (el gemelo maligno). Si se levanta un AP con el mismo SSID y la misma clave precompartida que el Wi-Fi de invitados, el equipo no puede distinguirlo del AP legítimo. Con WPA2-PSK, lo único que un equipo puede verificar de un AP es «que conoce la misma clave precompartida». Un AP que no conoce la clave no puede completar el proceso de conexión, pero, dicho al revés, cualquiera que conozca la clave puede convertirse en el «AP legítimo». Al ser una clave que se entrega a las visitas, hay que asumir que también se ha entregado, de hecho, a un posible atacante.

La respuesta del señor S vuelve a ser contundente. Cuando un empleado intenta acceder por HTTPS al sitio falso, el navegador muestra un mensaje de error indicando que la conexión no es segura, junto con uno o más de los siguientes cuatro elementos, según el certificado de servidor usado en el sitio falso.

• Este certificado de servidor no lo emitió una entidad certificadora de confianza (espacio en blanco c)
• El nombre de servidor indicado en este certificado de servidor difiere del servidor de destino (espacio en blanco d)
• Este certificado de servidor está revocado
• Este certificado de servidor ha caducado

De estos cuatro, los dos últimos ya venían escritos en el enunciado; la pregunta 1(2) pide responder los dos primeros (espacios en blanco c y d, hasta 40 caracteres cada uno, en cualquier orden).

sequenceDiagram
    autonumber
    participant U as PC de trabajo del empleado
    participant F as AP y sitio falsos<br/>(atacante)
    participant B as Servicio B (legítimo)

    Note over F: Levanta un AP con el mismo SSID<br/>y la misma clave precompartida que el Wi-Fi de invitados
    U->>F: Se conecta por error al AP falso
    Note over F: Manipula el DNS y dirige<br/>el dominio del Servicio B al sitio falso
    U->>F: Se conecta por HTTPS a la URL del Servicio B
    F-->>U: Certificado de servidor del sitio falso
    Note over U: Falla la verificación:<br/>no lo emitió una entidad certificadora de confianza<br/>el nombre del certificado no coincide con el destino
    Note over U: Muestra un error de conexión no segura<br/>no aparece la pantalla de inicio de sesión
    Note over U,B: No hay comunicación real<br/>con el Servicio B legítimo

Qué verifica exactamente la validación del certificado

Los comentarios de calificación dicen lo siguiente sobre esta pregunta.

La pregunta 1(2) tuvo un índice de aciertos bajo. Aunque un atacante prepare un sitio falso, si el acceso es por HTTPS, la verificación del certificado de servidor fallará. La verificación del certificado de servidor es un conocimiento básico para garantizar la seguridad de la comunicación, así que se recomienda comprenderla bien, incluyendo qué elementos concretos se verifican.

En otras palabras, muchos sabían que «aparece un error de certificado», pero pocos podían descomponer en cuatro elementos qué es exactamente lo que se comprueba para que falle. Si se ordenan los cuatro elementos de la figura 2 según qué verificación representa cada uno, queda así.

Desde el punto de vista del atacante, los dos primeros son un muro infranqueable. Si crea un certificado autofirmado, cae en el primero; si obtiene legítimamente un certificado gratuito para su propio dominio (por ejemplo, b-service.example.net), como el destino es el dominio del Servicio B, cae en el segundo. Un certificado para el dominio del Servicio B solo se puede obtener si se controla el dominio del Servicio B. Se puede decir que la combinación de estos dos puntos es el núcleo mismo del mecanismo del certificado.

El procedimiento de validación de la cadena de certificados lo define el RFC 5280⁵, y el procedimiento para comparar el nombre indicado en el certificado con el nombre del destino lo define el RFC 6125⁶.

Los cuatro elementos no tienen la misma fuerza

Aquí conviene separar la respuesta del examen del comportamiento real de los navegadores. Los cuatro elementos anteriores son los que la figura 2 del enunciado cita como «detalle del error que puede mostrarse»; no debe leerse que todos los navegadores verifican los cuatro con la misma certeza.

El emisor, el nombre de servidor y la fecha de caducidad se pueden determinar con la información que ya se tiene en el momento de recibir el certificado, así que siempre se verifican. Y son precisamente esos tres los que detienen el ataque en este caso.

En cambio, la comprobación de revocación es distinta por naturaleza. Si un certificado está revocado no consta dentro del propio certificado; hace falta consultar información adicional, así que depende de la implementación y de la configuración.

• Chrome normalmente no consulta OCSP ni CRL en línea. En su lugar distribuye CRLSet, una lista limitada pensada sobre todo para bloquear certificados rápidamente en situaciones de emergencia, que solo incorpora una parte de las listas de revocación de las entidades certificadoras⁷
• Incluso las implementaciones que sí consultan OCSP suelen usar configuraciones que dejan pasar la conexión cuando no obtienen respuesta (soft-fail)

Por eso, no conviene apoyar las medidas en la idea de «si se filtra la clave privada, basta con revocar el certificado». Revocar es algo que hay que hacer, pero no es un mecanismo que funcione con certeza en todos los navegadores de todos los usuarios. El acortamiento reciente del período de validez de los certificados es, precisamente, la respuesta del sector ante el hecho de que no se puede confiar en la revocación. Si en su propia empresa sospecha de una filtración de clave, además de solicitar la revocación hay que actuar en paralelo sustituyendo el certificado e invalidando todo lo que ese certificado protegía (sesiones, claves de API, etc.).

Una trampa habitual en la práctica — quién decide qué es una «entidad certificadora de confianza»

A partir de aquí salimos del enunciado del examen. El primer punto de la tabla anterior depende de en qué confía ese equipo concreto. La lista de confianza la tiene el navegador o el sistema operativo; en Windows corresponde al almacén de certificados «Entidades de certificación raíz de confianza».

Es decir, esta primera comprobación se supera en situaciones como las siguientes.

• Se distribuye a los PCs de trabajo el certificado raíz de una entidad certificadora interna (CA privada), y el atacante controla la clave privada de esa CA o su procedimiento de emisión
• Un proxy o un producto de seguridad que inspecciona el contenido del tráfico instala su propio certificado raíz en el equipo para terminar TLS, y el atacante controla ese producto o su operación
• Alguien registró en el pasado una excepción, o incorporó un certificado autofirmado al almacén de confianza, con la excusa de que «aparecía un error de certificado»

El tercer caso se ve muchísimo en la práctica: algo que alguien instaló a mano en su momento para quitar un error de certificado de un sistema interno sigue vivo en la imagen que heredan los PCs de los empleados que se van de la empresa. El contenido del almacén de entidades de certificación raíz de confianza es, literalmente, la declaración de en quién confía ese equipo, así que debe ser objeto de una revisión periódica. Qué debe entrar en cada almacén se trata en la guía práctica del almacén de certificados de Windows.

Sobre la segunda comprobación (coincidencia del nombre de servidor) hay otro punto que conviene tener presente en la práctica. Cuando el usuario confunde el nombre de dominio, el certificado no sirve de nada. Si un atacante registra un dominio parecido pero engañoso, como b-serv1ce.example.com, y obtiene legítimamente un certificado para ese dominio, el navegador no mostrará ningún error. Lo que garantiza el certificado es que «el nombre de servidor del destino coincide con el del certificado», no que «ese nombre de servidor sea, de hecho, con quien el usuario quería comunicarse». Un mecanismo que no depende de que el usuario verifique visualmente ese último paso es, por ejemplo, las claves de acceso (passkeys, WebAuthn), donde el propio autenticador verifica el origen. Puede leer más al respecto en Por qué las passkeys son seguras.

5. Por qué se detiene incluso si se escribe http:// — pregunta 1(3)

La señora Y insiste. Si, conectado al AP falso, un empleado escribe la URL del Servicio B en el navegador y por error introduce http://, ¿no dejaría de mostrarse el mensaje de error?

Es una duda razonable. Con una conexión HTTP no aparece ningún certificado de servidor. El sitio falso podría mostrar la pantalla de inicio de sesión sin mostrar ningún error.

La respuesta del señor S es: «No hay problema. Como HSTS está activado, en ese caso también se muestra el mismo mensaje de error de antes». La pregunta 1(3) pide describir, en hasta 60 caracteres, el comportamiento del navegador justo hasta antes de mostrar ese mensaje de error.

El ejemplo de respuesta es: «Sustituye el acceso HTTP por un acceso HTTPS y se conecta así. Después, recibe el certificado de servidor del sitio falso».

Qué ocurre dentro del navegador

HSTS (HTTP Strict Transport Security) es el mecanismo por el cual un sitio declara, mediante la cabecera Strict-Transport-Security, que «a partir de ahora hay que venir siempre por HTTPS a este host», y el navegador recuerda esa declaración. Lo define el RFC 6797⁸.

Cuando se intenta acceder por http:// a un host recordado de esta forma, el navegador hace lo siguiente.

1. Sustituye el esquema de la URL de http por https. Si el puerto 80 estaba explícito, lo convierte en 443 (RFC 6797, sección 8.3)
2. Como resultado, se conecta por HTTPS. Como el DNS está manipulado, el destino es el sitio falso
3. Recibe el certificado de servidor del sitio falso
4. Falla la verificación y aparece el mismo error del capítulo 4

Lo importante es que el paso 1 se completa antes de salir a la red. La solicitud HTTP en texto plano nunca llega a enviarse. Por eso no se da la situación de «como se conectó por HTTP, no aparece ningún certificado».

El botón «continuar de todos modos» que no se puede pulsar

HSTS tiene otra propiedad enorme en la práctica. La sección 8.4 del RFC 6797 exige que, si ocurre un error al establecer una comunicación segura con un host donde HSTS está activo, se corte la conexión, sea el error una advertencia o un fallo crítico. Y la sección 12.1 describe ese comportamiento como “No User Recourse” (sin salida para el usuario), e indica que no debe ofrecerse una opción del tipo «esta conexión no es segura, ¿desea continuar de todos modos?».

Ante un error de certificado normal, la mayoría de los navegadores incluyen en la pantalla de advertencia enlaces del tipo «configuración avanzada» o «continuar de todos modos». En la práctica no es raro ver a usuarios acostumbrados a los errores de certificado de sistemas internos pulsar ese botón por reflejo. HSTS anula ese reflejo. Frente a un sitio falso, se podría decir incluso que este «no poder pulsar continuar» pesa más que la propia verificación del certificado.

La condición de HSTS — el primer acceso no se puede proteger

Ahora bien, HSTS tiene una condición previa. Según define la sección 8.1 del RFC 6797, un host se convierte en «host HSTS conocido» cuando el agente de usuario recibe la cabecera Strict-Transport-Security a través de un canal de comunicación seguro. Es decir, ese navegador tiene que haber llegado al menos una vez, por HTTPS, al sitio legítimo.

Por lo tanto, HSTS no protege en estos casos.

• Un PC de trabajo recién entregado cuyo primer acceso ocurrió, precisamente, bajo el AP falso
• Se reconstruyó el perfil del navegador, o se borraron los datos de navegación y con ellos el registro de HSTS
• El período de validez del registro (max-age) ya había caducado

Lo que cubre este problema del primer acceso es la lista de precarga (preload) de HSTS. Si el dominio figura de antemano en la lista integrada en el navegador, se fuerza HTTPS aunque nunca se haya accedido antes.

Ahora bien, si su empresa está considerando registrar su sitio, primero revise los requisitos. Estos son los requisitos de registro⁹.

• Ofrecer un certificado válido
• Si escucha en el puerto 80, redirigir de HTTP a HTTPS en el mismo host
• Ofrecer HTTPS en todos los subdominios (incluido www si existe el registro DNS)
• Devolver, en el dominio base, una cabecera Strict-Transport-Security con max-age de 31 536 000 segundos (un año) o más, junto con includeSubDomains y preload

El punto crítico es el tercer requisito, combinado con includeSubDomains. Si algún subdominio interno antiguo solo funciona por HTTP, o no tiene un certificado preparado, en el momento del registro deja de poder alcanzarse. Haga un inventario completo de subdominios antes de registrar.

Y revertir el registro no es sencillo. En general se acepta la solicitud de eliminación, pero el cambio tarda meses en llegar a los navegadores de los usuarios, y para navegadores distintos de Chrome no hay ninguna garantía⁹. Conviene entrar con la idea de que la precarga no es una configuración que se pueda «deshacer si nos equivocamos».

Y a la inversa, desde el punto de vista de quien usa un servicio: si un servicio en la nube que usa para el trabajo admite HSTS es un punto que puede añadir a los criterios de selección.

6. En el momento en que la aprobación se vuelve pura formalidad, el uso compartido se convierte en ruta de sustracción — pregunta 2(1)

A partir de aquí pasamos a analizar la sustracción por parte de un empleado.

El señor S empieza confirmando cómo se opera la función de uso compartido de archivos. ¿El superior verifica correctamente la dirección de correo del destinatario y el archivo antes de aprobar? La respuesta de la señora Y es: «Parece que hay superiores que no lo verifican».

Ahí es donde el señor S plantea la pregunta 2(1): responder en hasta 40 caracteres, de forma concreta, una forma de abusar de la función de uso compartido de archivos para poder descargar un archivo desde fuera de la empresa M.

El ejemplo de respuesta es: «Indicar la propia dirección de correo personal como dirección del destinatario externo».

El diseño es correcto; lo que falla es la operación

La función de uso compartido de archivos del Servicio B está pensada con cuidado.

• El uso compartido requiere la aprobación de un superior
• Ni el propio usuario ni el superior conocen el enlace de uso compartido externo. El propio solicitante no puede reenviar el enlace para sustraer el archivo
• El enlace incluye una cadena aleatoria difícil de adivinar y caduca en un día

El segundo punto, en particular, está diseñado pensando en la sustracción interna. Y aun así se puede eludir: basta con poner la propia dirección como destinatario para que el enlace «que no se comunica al propio solicitante» llegue, precisamente, a manos del propio solicitante.

Y la condición para que se abra esta brecha es una sola: «que el superior no verifique el destinatario». El flujo de aprobación está diseñado partiendo de que el aprobador revisa el contenido. Si no lo revisa, no es más que un canal de envío automatizado.

Las condiciones bajo las que la aprobación se vuelve formalidad ya se conocen

En la práctica, cuando la aprobación se vuelve mera formalidad, la causa suele ser una de estas.

Lo que le falta a la empresa M en este caso son, sobre todo, los dos últimos puntos. Si se pone un mecanismo para que las aprobaciones pasen, también hace falta un mecanismo para revisar después el resultado de esas aprobaciones. Con solo poder listar cuántos usos compartidos externos hubo en un mes hacia dominios de correo gratuito, esta técnica se vuelve mucho más fácil de detectar.

Una visión general de por dónde empezar en una pequeña o mediana empresa se trata en Cómo abordar la Guía de medidas de seguridad de la información para pymes v4.0 de IPA.

7. La brecha llamada sala de reuniones — pregunta 2(2)

La siguiente pregunta del señor S es: «¿Se pueden traer PCs personales a la sala de reuniones?». La respuesta de la señora Y es: «No está prohibido traerlos a la sala de reuniones, así que sí se pueden traer».

Aquí aparecen los métodos 1 y 2. Ambos siguen el mismo guion: descargar los archivos del Servicio B con un PC personal y llevarse ese PC personal fuera de la empresa. La configuración del software contra fugas de información instalado en el PC de trabajo no afecta en absoluto al PC personal.

Método 1 — Falsificación de la dirección MAC

El método 1 consiste en cambiar la [e] dirección MAC de la interfaz inalámbrica del PC personal por la dirección MAC de la interfaz inalámbrica de un PC de trabajo, y luego conectar el PC personal al Wi-Fi de empleados. Responder el espacio en blanco e es la pregunta 2(2).

Lo que protegía la entrada al Wi-Fi de empleados eran dos cosas: la clave precompartida de WPA2-PSK y el filtrado por dirección MAC. Un empleado puede sortear ambas.

• La clave precompartida es la que está configurada en el PC de trabajo, y el empleado es quien usa ese PC de trabajo. Al ser un método en el que todos comparten una única clave, hay que asumir como premisa que «el usuario puede llegar a conocerla»
• La dirección MAC se puede reescribir desde el propio equipo. Lo normal es poder cambiarla desde la configuración del sistema operativo o las propiedades del controlador, sin necesidad de ninguna herramienta especial. Y como la dirección MAC va sin cifrar en las tramas de la LAN inalámbrica, basta con captar la señal cerca para conocer la dirección MAC de un PC de trabajo registrado

El filtrado por dirección MAC y la ocultación del SSID sí tienen sentido como orden y limpieza para reducir conexiones accidentales. Pero no son un mecanismo de autenticación capaz de detener a alguien que intenta entrar de forma intencional. Conviene revisar, en la propia configuración, si estas dos cosas se están contando como «medidas» dentro del total.

Método 2 — Simplemente conectarse al Wi-Fi de invitados

El método 2 es aún más simple. Conectar el PC personal al Wi-Fi de invitados, descargar los archivos del Servicio B y llevarse el PC personal fuera de la empresa. Nada más.

No hace falta ni falsificar la dirección MAC. Lo único necesario es la clave precompartida del Wi-Fi de invitados, que es justamente la que se entrega a las visitas. No hay razón para que un empleado no la conozca.

Aquí surge, como es lógico, la siguiente duda. ¿No estaba el Servicio B restringido a «con el identificador asignado a un empleado de la empresa M, solo se puede iniciar sesión desde la dirección IP pública de la empresa M»?

Qué permite en realidad una restricción por dirección IP de origen

La respuesta está en la configuración del firewall descrita en el enunciado. Tanto el tráfico que sale a Internet desde el Wi-Fi de invitados como el que sale desde el Wi-Fi de empleados se convierten, por el mismo NAT, en la misma dirección IP pública.

Desde el Servicio B, estos tres son indistinguibles. La restricción por dirección IP se elude sin más.

Esta estructura reaparece una y otra vez fuera del examen. Una restricción por dirección IP de origen no significa «solo desde este equipo». Significa «desde todos los que salen por esta dirección IP pública». A continuación se listan casos típicos en los que el alcance que se cree haber permitido difiere del alcance realmente permitido.

No se trata de que una restricción por dirección IP de origen no sirva de nada. Se trata de no usarla como única capa. Solo al combinar la restricción por IP con un mecanismo que identifique el propio equipo (certificado de cliente o certificado de dispositivo) y un mecanismo que identifique al usuario (autenticación multifactor) se puede expresar «esta persona, con este equipo». Las medidas de este caso avanzan justamente en esa dirección.

8. Atar el equipo con un certificado — preguntas 3(1) a 3(4)

Como medida contra el método 1, la empresa M decide adoptar EAP-TLS como método de autenticación del Wi-Fi de empleados y preparar un servidor de autenticación.

Pregunta 3(1) — RADIUS

La pregunta 3(1) pregunta qué protocolo sobre UDP usa el servidor de autenticación para EAP. El ejemplo de respuesta es RADIUS.

Si se ordena el esquema, hay tres actores.

Entre el PC de trabajo y el AP se usa IEEE 802.1X (EAP over LAN); entre el AP y el servidor de autenticación se usa RADIUS. RADIUS funciona sobre UDP¹⁰. El procedimiento propio de EAP-TLS lo define el RFC 5216¹¹. Si se monta con Windows Server, el rol de servidor de autenticación lo cumple el Servidor de directivas de redes (NPS, Network Policy Server)¹².

Conviene fijar qué cambia al pasar de WPA2-PSK a EAP-TLS.

La última fila necesita una aclaración. En EAP-TLS, el certificado que verifica el cliente es el del servidor de autenticación, no el del AP. El AP es solo el autenticador que retransmite el intercambio de EAP; el cliente no está comprobando la identidad del AP en sí.

Aun así, esto sí sirve como protección frente al evil twin del capítulo 4, porque el material de claves que solo se genera al completarse con éxito la autenticación solo llega a un AP legítimo que posea el secreto compartido de RADIUS. Un AP que un atacante levante por su cuenta no puede completar este procedimiento a menos que tenga detrás un servidor de autenticación legítimo. La estructura es que el cliente verifica directamente al servidor de autenticación, y la legitimidad del AP se deduce de ahí de forma indirecta.

Ahora bien, hay una condición: si en el lado del cliente no se configura qué entidad certificadora, con qué nombre de servidor, hay que aceptar como válida, no se podrá distinguir cuando un atacante prepare su propio servidor de autenticación. En la práctica existen configuraciones en las que se implementó EAP-TLS pero se desactivó la verificación del certificado de servidor en el perfil del cliente. Al implementarlo, revise también ese punto hasta el final.

Pregunta 3(2) — El error que señalaron los comentarios de calificación

La explicación de la señora Y continúa así: el certificado de cliente se emite montando un nuevo servidor de CA, y en lugar de que cada empleado lo instale en su propio PC de trabajo, se distribuye mediante la función del servidor de directorio. Y lo que corresponde al certificado de cliente, [f], se guarda en el TPM del PC de trabajo para [g] y así protegerlo.

La pregunta 3(2) pregunta por el espacio en blanco f. El ejemplo de respuesta es la clave privada.

Los comentarios de calificación dicen lo siguiente.

La pregunta 3(2) tuvo un índice de aciertos algo alto, aunque se vieron algunas respuestas como «clave pública» o «certificado de servidor». Como PKI es una tecnología fundamental que sustenta diversas técnicas de seguridad, se recomienda entender bien en qué escenarios y de qué forma se utiliza.

La clave pública es la que va dentro del certificado y se distribuye al mundo entero; no es algo que haga falta proteger. Lo que hay que proteger es la clave privada, que solo debería poseer el titular de ese certificado. «Autenticarse con un certificado de cliente» significa, en rigor, «demostrar, firmando con ella, que se posee la clave privada correspondiente a la clave pública incluida en el certificado». Por eso, si la clave privada se pudiera copiar, la autenticación mediante certificado perdería todo su sentido.

Qué cambia al guardarla en el TPM — pregunta 3(3)

La pregunta 3(3) pregunta por el espacio en blanco g, en hasta 20 caracteres. El ejemplo de respuesta es «para que no se pueda extraer del PC de trabajo».

Si la clave privada se guarda como un archivo en el equipo, es un dato que se puede copiar. Si se copia a un PC personal, ese PC personal pasaría la autenticación como si fuera un PC de trabajo. Se habría tapado el método 1 (falsificación de MAC) solo para que lo sustituya la «falsificación del certificado».

El TPM permite generar la clave dentro de él y mantenerla en un estado en el que no se puede extraer. Las operaciones como la firma se realizan dentro del TPM, y la clave en sí nunca llega ni al sistema operativo, ni a las aplicaciones, ni a ningún malware. Como resultado, esa clave privada queda fijada a ese único componente físico.

En Windows, esto se implementa señalando Microsoft Platform Crypto Provider como proveedor de almacenamiento de claves (KSP) en la plantilla de certificado. Este proveedor protege la clave usando el TPM y no se puede seleccionar si en la plantilla de certificado está marcada la casilla «permitir exportar la clave privada»¹³. Es una restricción lógica: si se pudiera exportar, no tendría sentido protegerla.

El papel del TPM como componente en sí se trata, desde el enfoque del cifrado de disco, en la guía práctica de BitLocker. La idea de «no dejar salir la clave privada fuera del dispositivo» es la misma que hay detrás del diseño de los autenticadores que se explica en Por qué las passkeys son seguras.

Por qué se puede decir que «no hay problema» — pregunta 3(4)

Al oír la explicación de la señora Y, el señor S responde: «Con ese método de almacenamiento, creo que no hay problema». La pregunta 3(4) pregunta el porqué, en hasta 40 caracteres.

El ejemplo de respuesta es: «Porque la información de autenticación necesaria para EAP-TLS solo se puede guardar en el PC de trabajo».

Si se sigue el razonamiento, queda así.

1. El certificado de cliente no lo instala el empleado por su cuenta, sino que lo distribuye la función del servidor de directorio al PC de trabajo. No pasa por las manos del empleado
2. La clave privada está dentro del TPM y no se puede extraer del PC de trabajo
3. Por lo tanto, solo los PCs de trabajo entregados por la empresa pueden conectarse al Wi-Fi de empleados mediante EAP-TLS
4. Un PC personal, aunque falsifique su dirección MAC, no puede pasar la autenticación. El método 1 queda cerrado

Fíjese en la expresión condicional «con ese método de almacenamiento». Si la clave privada se hubiera guardado como un archivo en el PC de trabajo, el señor S no habría dicho que no había problema. Con la misma «autenticación mediante certificado de cliente», el alcance que se protege cambia según cómo se guarde la clave privada.

Lo que el TPM no protege

Ahora bien, guardar la clave en el TPM no significa que ya esté todo resuelto. Lo que garantiza el TPM es únicamente que «esa clave no se puede copiar a otro equipo». No protege lo siguiente.

• Que se lleven el propio equipo. Si se saca el PC de trabajo de la empresa, se saca el TPM con él. Las reglas de la empresa M prohíben sacar el PC de trabajo fuera de la empresa, pero una regla y una imposición técnica son cosas distintas. Hace falta, por separado, cifrado de disco (incluida la autenticación previa al arranque) y un procedimiento de revocación del certificado en caso de pérdida o robo
• La suplantación del usuario. El TPM identifica el equipo, pero no garantiza quién lo está operando. La autenticación del usuario es necesaria aparte
• El malware que corre en el propio equipo. No se puede leer la clave privada, pero el código que corre en ese equipo sí puede «pedirle al TPM que firme». Se evita copiar la clave, pero no se evita el abuso mientras ese equipo está comprometido

9. Separar la dirección IP de salida — pregunta 3(5)

Como medida contra el método 2 (conectarse sin más al Wi-Fi de invitados), la empresa M analiza dos opciones: cambiar la configuración de NAT del FW, o contratar un servicio de LAN inalámbrica (Servicio D).

La pregunta 3(5) pregunta, en hasta 70 caracteres, el contenido del cambio en la primera opción. El ejemplo de respuesta viene a decir: «Hacer que la dirección IP de origen al acceder a Internet desde el Wi-Fi de invitados sea distinta de la dirección IP pública que se usa actualmente» (el enunciado denota esa dirección IP pública como a1.b1.c1.d1).

Como se vio en el capítulo 7, el método 2 funciona porque el tráfico del Wi-Fi de invitados sale con la misma dirección IP pública que el de empleados. Basta entonces con convertir el tráfico del Wi-Fi de invitados a una dirección IP pública distinta. La restricción de IP del lado del Servicio B no cambia; solo el acceso desde el Wi-Fi de invitados queda fuera de ella.

Esto es posible porque a la empresa M se le asignaron varias direcciones IP públicas en su conexión WAN. Si se lee con atención la configuración de la interfaz del FW en el enunciado, la máscara de subred del lado WAN es 255.255.255.248, es decir /29, lo que revela que hay más de una dirección disponible. Es una pista discreta pero segura, sembrada en una tabla del enunciado que invita a leerla con detalle.

Que su propia empresa pueda aplicar esta misma solución depende de si el contrato de línea de su operador permite usar varias direcciones IP públicas. Si solo hay una, esta opción no está disponible, y toca recurrir a la separación que se ve en el capítulo siguiente.

10. Eliminar lo que ya no se usa forma parte de la medida — preguntas 3(6) y 3(7)

Tras el análisis, la empresa M decide contratar el Servicio D.

• Se instala en la sala de reuniones un router inalámbrico prestado por el Servicio D (Router D)
• En el Router D se activan la función de servidor DHCP y la función de servidor de caché DNS
• Los dispositivos que traen las visitas se conectan a Internet sin pasar por la red de la empresa M, usando la SIM integrada en el Router D
• El proyector deja de usar el Wi-Fi de invitados y pasa a conectarse por cable HDMI

flowchart LR
    subgraph M["Red interna de la empresa M (después de las medidas)"]
        direction TB
        E["Wi-Fi de empleados<br/>EAP-TLS + RADIUS<br/>clave privada dentro del TPM"]
        S["Red de servidores"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["Sala de reuniones"]
        T["Dispositivo del visitante"]
        D["Router D<br/>a Internet directamente por SIM"]
        T --> D
    end
    FW --> B["Servicio B"]
    D --> I["Internet"]

La red para invitados queda separada de la red de la empresa M, tanto física como lógicamente. Tampoco sale ya por la misma dirección IP pública.

Pregunta 3(6) — Comunicación que deja de ser necesaria

Cuando los dispositivos de las visitas dejan de usar la red de la empresa M, deja de ser necesaria la comunicación con el servidor DHCP y con el servidor [h] que antes hacía falta. El ejemplo de respuesta del espacio en blanco h es DNS.

Como el propio Router D tiene función de servidor DHCP y de caché DNS, los dispositivos de las visitas dejan de necesitar el servidor DHCP y el servidor DNS de la red de servidores de la empresa M. Si se relee la descripción del enunciado, está escrito tal cual.

Pregunta 3(7) — Enumerar todo lo que hay que eliminar

La pregunta 3(7) pide responder todos los números de ítem que deben eliminarse de la configuración de interfaces VLAN del FW y de la configuración de filtrado del FW, respectivamente, como consecuencia de este cambio.

La respuesta es: de la configuración de interfaces VLAN, la VLAN del Wi-Fi de invitados (ítem 1); de la configuración de filtrado, la regla que permite HTTP/HTTPS desde el Wi-Fi de invitados hacia Internet (ítem 1) y la regla que permite el acceso desde el Wi-Fi de invitados al DNS de la red de servidores (ítem 4). Además, de la configuración del AP se elimina la configuración del SSID de invitados.

Los comentarios de calificación dicen lo siguiente.

La pregunta 3(7) tuvo un índice de aciertos alto. Hacía falta comprender el impacto de la revisión del entorno de LAN inalámbrica sobre todas las configuraciones de filtrado del firewall para responder correctamente, y en general se comprendió bien.

Es una pregunta con índice de aciertos alto, pero en la práctica no son muchas las organizaciones que llegan a hacerlo hasta el final. El trabajo de introducir un mecanismo nuevo suele tener presupuesto y plazo asignados; el trabajo de eliminar la configuración antigua, no. Y los olvidos de eliminación aparecen más tarde de estas formas.

El firewall de este caso funciona evaluando las reglas en orden desde el número de ítem más bajo y aplicando la primera que coincide (así lo especifica el enunciado). Con este esquema, dejar una regla de permiso obsoleta en una posición alta equivale a dejar abierto un hueco que impide que el tráfico llegue nunca hasta la regla de denegación final.

Ahora bien, no generalice este esquema de evaluación a todos los firewalls. El criterio varía según el producto.

Sea cual sea el esquema, dejar un permiso que ya no se usa sigue siendo peligroso en todos los casos. Lo que cambia es «por qué es peligroso» y «cómo se corrige». Confirme qué esquema usa el equipo de su empresa e incluya, en la revisión periódica, el criterio de «si el origen y el destino todavía existen».

Cómo gestionar, del lado de la aplicación de trabajo, las reglas de entrada necesarias —es decir, el firewall del propio equipo— se trata en El firewall de Windows y las aplicaciones de trabajo.

11. Las medidas que no funcionaron y las que sí funcionaron

Si se resume este caso en una sola tabla, queda así: las medidas que tenía la empresa M frente a por dónde se acabaron superando.

Solo la última fila es la que «funcionó». Y, si se listan las medidas propuestas, quedan así.

Comparando ambas tablas, la diferencia de carácter es clara. Las medidas que se superaron eran, en su mayoría, prohibiciones sobre «medios»; las medidas que funcionaron y las que se propusieron cambian el «camino» o la naturaleza de las «credenciales». Bloquear la memoria USB no sirve de nada si queda un camino que llega hasta el archivo; alargar la clave precompartida no cambia el hecho de que siga siendo un secreto compartido.

12. Puntos de verificación para la práctica

A continuación se listan los puntos que conviene revisar al aplicar este caso a la configuración de su propia empresa.

1. ¿Puede describir las medidas contra la sustracción en términos de rutas, no de medios? No haga una lista de medios (memoria USB, adjunto de correo, webmail); elabore una lista de «equipos y redes que pueden llegar a los archivos de trabajo». Si queda una sola ruta por la que un equipo no gestionado pueda llegar, la prohibición de medios se elude
2. ¿Las reglas de traer y sacar equipos limitan realmente el espacio? «Prohibido traer a las oficinas» permite implícitamente la sala de reuniones, la recepción y los espacios comunes. Confirme si la delimitación física coincide con la delimitación de red
3. ¿Puede decir con precisión qué alcance permite en realidad una restricción por dirección IP de origen? Cuente todo lo que sale por esa dirección IP pública: Wi-Fi de invitados, red para visitas, VPN entre sedes, puerta de enlace concentradora de teletrabajo, entornos de prueba
4. ¿Las credenciales de la LAN inalámbrica son por equipo? Una clave precompartida es un secreto compartido que todos poseen por igual; si una sola persona la filtra, se filtra para todos, y no se puede detener solo a un equipo concreto
5. ¿Está contando el filtrado por dirección MAC y la ocultación del SSID como medidas de seguridad? Ambos reducen las conexiones accidentales, pero no son autenticación
6. ¿La clave privada del certificado de cliente está en un estado que no se puede extraer del equipo? Una clave privada guardada como archivo se puede copiar. Señale un proveedor de almacenamiento de claves que use el TPM y no permita exportarla
7. ¿El cliente que implementa EAP-TLS verifica el certificado del servidor de autenticación? Si se desactiva esta verificación, se pierde la resistencia frente a un servidor de autenticación falso
8. ¿Puede el usuario superar un error de certificado de servidor pulsando «continuar»? Configure HSTS en los sitios de su propia empresa. No deje sin corregir los errores de certificado de los sistemas internos, para no acostumbrar al usuario a que «un error es algo que se pulsa para seguir adelante»
9. ¿Revisa periódicamente el contenido del almacén de entidades de certificación raíz de confianza? Lo que hay ahí dentro es, literalmente, la declaración de a quién ese equipo considera «legítimo si presenta un certificado emitido por esta entidad»
10. ¿Los aprobadores del flujo de aprobación reciben los elementos de juicio necesarios? ¿Y se revisa después el resultado de esas aprobaciones? Revise periódicamente, en una lista, los usos compartidos dirigidos a dominios externos o a correos gratuitos
11. ¿Ha eliminado la configuración de las rutas que ya se dieron de baja? Interfaces VLAN, reglas de filtrado, SSID, entradas de listas de permitidos. Dele a la tarea de eliminar el mismo trato que a la de agregar algo nuevo: con un plazo asignado

Para terminar — una medida que no declara su «alcance» no protege

Si la pregunta 1 preguntaba «esa medida, ¿qué ataque detiene y en qué fase?», lo que pregunta la pregunta 2 es «esa medida, ¿qué alcance protege?».

Todas las medidas de la empresa M tenían un alcance implícito. El del software contra fugas de información llegaba hasta el PC de trabajo. El de la prohibición de traer dispositivos llegaba hasta las oficinas. El del filtrado por dirección MAC llegaba hasta «quien no falsifique nada». El de la restricción por dirección IP de origen llegaba hasta «todos los que salen por esa dirección IP pública». Cada alcance funcionaba correctamente por sí mismo; solo que, justo en la unión con el de al lado, quedaba un hueco.

Lo que hace que este caso sea tan aplicable a la práctica es que la empresa M aparece retratada como una empresa que tomaba la seguridad en serio. Tras el incidente del año anterior, taponó ambos extremos de la ruta e incluso instaló software específico. Y aun así queda un hueco, no porque el responsable fuera descuidado, sino porque, cuando las medidas se van añadiendo una por una, los huecos entre alcances no se ven.

Para encontrar esos huecos no hay más remedio que escribir, en lugar de una lista de medidas, una lista de rutas. Eso es exactamente lo que hicieron la señora Y y el señor S en este caso: separar «el atacante externo» del «empleado» y, para cada uno, ir taponando sus rutas de acceso una a una. A eso se refiere, probablemente, la «capacidad de imaginar desde distintos ángulos las amenazas propias de un entorno con LAN inalámbrica» que IPA menciona en el objetivo de la pregunta.

Áreas de consultoría relacionadas

KomuraSoft LLC trabaja en revisiones de diseño sobre configuraciones de red y de equipos ya existentes, así como en la implementación, en entornos Windows, de la distribución de certificados y la protección de claves.

• Consultoría técnica y revisión de diseño
• Desarrollo en Windows
• Investigación de fallos y análisis de causas
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Si prohibieron conectar memorias USB y también prohibieron guardar en el disco local, ¿por qué se pueden sacar los archivos?

Porque lo que prohibieron fue una función del PC de trabajo prestado por la empresa, no la ruta de acceso al lugar donde están los archivos. En este caso, el empleado usa su propio PC personal. Sin tocar en ningún momento el PC de trabajo, conecta el PC personal al Wi-Fi de la sala de reuniones, inicia sesión en el almacenamiento en la nube (Servicio B) con su propio identificador de usuario, descarga los archivos y se lleva el PC personal completo. La configuración del software contra fugas de información instalado en el PC de trabajo no afecta en absoluto al PC personal. La empresa M prohibía traer PCs personales, pero esa prohibición aplicaba solo a las oficinas; la sala de reuniones quedaba fuera. Aunque se bloqueen uno a uno los medios (memoria USB, adjunto de correo, webmail), si queda una ruta que llega hasta el archivo, la sustracción sigue siendo posible.

El Servicio B restringía el acceso a «solo se puede iniciar sesión desde la dirección IP pública de la empresa M». ¿Por qué se puede eludir desde el Wi-Fi de invitados?

Porque el tráfico del Wi-Fi de invitados también pasa por el NAT del mismo firewall y se convierte a la misma dirección IP pública antes de salir a Internet. Desde el punto de vista del Servicio B, el acceso desde un PC de trabajo dentro de la oficina y el acceso desde un PC personal conectado al Wi-Fi de invitados en la sala de reuniones se ven como la misma dirección IP de origen. No se pueden distinguir. Hay que entender que una restricción por dirección IP de origen no es una configuración de «solo desde este equipo», sino de «todos los que comparten esta salida». Cualquier tráfico que salga por la misma dirección IP pública —el Wi-Fi de invitados, una VPN entre sedes, una puerta de enlace concentradora de teletrabajo— queda dentro del rango permitido.

El Wi-Fi de empleados tenía filtrado por dirección MAC. ¿Eso no sirve como medida de protección?

No sirve, porque la dirección MAC se puede reescribir libremente desde el propio equipo. El método 1 de este caso consistía precisamente en cambiar la dirección MAC de la interfaz inalámbrica del PC personal por la de un PC de trabajo ya registrado, y conectarse con eso. Como las tramas de la LAN inalámbrica llevan la dirección MAC sin cifrar, basta con captar la señal cerca para conocer la dirección MAC de un equipo registrado. Lo mismo aplica a la ocultación del SSID: aunque se desactive su difusión, el SSID se revela en el intercambio que ocurre cuando un equipo se conecta. El filtrado por MAC y la ocultación del SSID reducen las conexiones accidentales, pero no son un mecanismo de autenticación capaz de detener una conexión intencional.

Aunque preparen un punto de acceso falso y un sitio falso, ¿por qué se puede afirmar que el empleado no caerá en el engaño?

Porque, al conectarse por HTTPS, el sitio falso no puede superar la verificación del certificado de servidor. La figura 2 del enunciado cita cuatro elementos que puede mostrar el error en ese momento: que no lo emitió una entidad certificadora de confianza, que el nombre del servidor indicado en el certificado difiere del servidor de destino, que está revocado y que ha caducado. El atacante no puede obtener un certificado legítimo para el dominio del Servicio B, así que si usa un certificado autofirmado falla en el primer punto, y si usa un certificado obtenido legítimamente para su propio dominio falla en el segundo. Según los comentarios de calificación de IPA, el índice de aciertos de la pregunta sobre este contenido de verificación fue bajo. Cabe aclarar que estos cuatro elementos no tienen la misma fuerza: lo que detiene el ataque son los dos primeros (emisor y nombre) y la fecha de caducidad, que el navegador siempre verifica. La comprobación de revocación, en cambio, depende de la implementación y de la configuración. Chrome, por ejemplo, normalmente no consulta OCSP ni CRL en línea, sino que usa un diseño basado en CRLSet, una lista limitada pensada sobre todo para bloqueos de emergencia. No dé por hecho que revocar un certificado siempre lo bloqueará. Además, si el PC de trabajo tiene distribuido el certificado raíz de una entidad certificadora interna y el atacante controla la clave privada o el procedimiento de emisión de esa entidad, incluso la primera comprobación se superaría.

¿Qué pasa si se escribe «http://» por error en la URL? ¿Qué hace HSTS en ese caso?

El navegador sustituye HTTP por HTTPS antes de conectarse, así que el resultado es el mismo error de certificado. HSTS es el mecanismo por el cual el navegador recuerda el contenido de una cabecera recibida en una conexión HTTPS anterior a ese sitio. El RFC 6797 exige que, cuando la URL hacia el host de destino incluya el esquema http, el agente de usuario lo sustituya por https, y que convierta el puerto 80 en 443 si estaba explícito. Es decir, la solicitud HTTP en texto plano desaparece antes de salir a la red. Y algo aún más importante: cuando falla la verificación del certificado en la comunicación con un host donde HSTS está activo, se exige cortar la conexión, sea el fallo una advertencia o un error crítico. Se especifica explícitamente que no debe ofrecerse al usuario la opción de «esta conexión no es segura, ¿desea continuar de todos modos?». Ahora bien, HSTS presupone que ese navegador ya llegó al menos una vez al sitio legítimo por HTTPS y recibió la cabecera. Si en un equipo completamente nuevo el primer acceso es directamente al sitio falso, HSTS no protege. Lo que cubre ese primer acceso es la lista de precarga (preload) integrada en el navegador.

¿Qué cambia al guardar la clave privada del certificado de cliente en el TPM?

Que la clave privada deja de poder extraerse de ese PC de trabajo. Una clave privada guardada como archivo en el equipo se puede copiar; si se copia a un PC personal, ese PC pasaría la autenticación como si fuera un PC de trabajo. Si la clave se genera dentro del TPM y queda marcada como no exportable, las operaciones como la firma se realizan solo dentro del TPM, y la clave en sí nunca llega al sistema operativo ni a ningún malware. Como resultado, solo los PCs de trabajo entregados por la empresa pueden pasar la autenticación EAP-TLS. Por eso el señor S pudo decir que «con ese método de almacenamiento no hay problema». En Windows, esto se implementa señalando Microsoft Platform Crypto Provider como proveedor de almacenamiento de claves en la plantilla de certificado, y desactivando la opción que permite exportar la clave privada. Ahora bien, el TPM solo protege que «la clave no se pueda copiar a otro equipo»; no cambia el hecho de que quien tenga ese equipo en sus manos pueda usarla. Ante la pérdida o el robo del equipo hace falta, por separado, cifrado de disco y revocación del certificado.

¿Qué debe llevarse a la práctica profesional a partir de este caso?

Cuatro cosas. Primera, pensar las medidas contra la sustracción en términos de rutas, no de medios. Bloquear uno a uno la memoria USB, el adjunto de correo o el webmail no sirve de nada si queda un equipo capaz de llegar hasta el archivo. Segunda, escribir explícitamente el alcance real que permite una restricción por dirección IP de origen. Si el Wi-Fi de invitados o una VPN comparten la misma salida, también quedan dentro de ese alcance. Tercera, hacer que la autenticación de la LAN inalámbrica dependa de credenciales por equipo. Una clave precompartida es un secreto compartido que todos poseen por igual, así que si una sola persona la filtra, se filtra para todos. Con EAP-TLS, un certificado de cliente y una configuración que no deja salir la clave privada del TPM, las credenciales quedan fijadas a cada equipo. Cuarta, eliminar la configuración que ya no se usa. La última pregunta de este caso pide enumerar todas las configuraciones de interfaz VLAN y todas las reglas de filtrado del firewall que quedan tras dar de baja el Wi-Fi de invitados; según los comentarios de calificación de IPA el índice de aciertos fue alto, pero en la práctica son pocas las organizaciones que llegan a hacerlo del todo.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.