CÓDIGO MASVS TITULO MASVS

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-1
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-2
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-3
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-4
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-5
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-6
Amenazas

MSTG-ARCH-7 Requisitos de Arquitectura, Diseño y Modelado de

Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-8
Amenazas

MSTG-ARCH-9 Requisitos de Arquitectura, Diseño y Modelado de

Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-10
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-11
Amenazas

Requisitos de Arquitectura, Diseño y Modelado de

MSTG-ARCH-12
Amenazas

Requerimientos de Almacenamiento de datos y

MSTG-STORAGE-1
Privacidad

Requerimientos de Almacenamiento de datos y

MSTG-STORAGE-2 Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-3
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-4
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-5
Privacidad
 Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-6
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-7
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-8
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-9
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-10
Privacidad
Requerimientos de Almacenamiento de datos y
MSTG-STORAGE-11
Privacidad

Requerimientos de Almacenamiento de datos y

MSTG-STORAGE-12
Privacidad

Requerimientos de Almacenamiento de datos y

MSTG-STORAGE-13
Privacidad

MSTG-STORAGE-14 Requerimientos de Almacenamiento de datos y

Privacidad

Requerimientos de Almacenamiento de datos y

MSTG-STORAGE-15
Privacidad

MSTG-CRYPTO-1 Requerimientos de Criptografía

MSTG-CRYPTO-2 Requerimientos de Criptografía

MSTG-CRYPTO-3 Requerimientos de Criptografía

MSTG-CRYPTO-4 Requerimientos de Criptografía

MSTG-CRYPTO-5 Requerimientos de Criptografía

MSTG-CRYPTO-6 Requerimientos de Criptografía

MSTG-AUTH-1 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-2 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-3 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-4 Requerimientos de Autenticación y Manejo de Sesiones

 MSTG-AUTH-5 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-6 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-7 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-8 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-9 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-10 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-11 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-AUTH-12 Requerimientos de Autenticación y Manejo de Sesiones

MSTG-NETWORK-1 Requerimientos de Comunicación a través de la red

MSTG-NETWORK-2 Requerimientos de Comunicación a través de la red

MSTG-NETWORK-3 Requerimientos de Comunicación a través de la red

MSTG-NETWORK-4 Requerimientos de Comunicación a través de la red

MSTG-NETWORK-5 Requerimientos de Comunicación a través de la red

MSTG-NETWORK-6 Requerimientos de Comunicación a través de la red

MSTG-PLATFORM-1 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-2 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-3 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-4 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-5 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-6 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-7 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-8 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-9 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-10 Requerimientos de Interacción con la Plataforma

MSTG-PLATFORM-11 Requerimientos de Interacción con la Plataforma

Requerimientos de Calidad de Código y Configuración

MSTG-CODE-1
del Compilador

MSTG-CODE-2 Requerimientos de Calidad de Código y Configuración

del Compilador
Requerimientos de Calidad de Código y Configuración
MSTG-CODE-3
del Compilador

Requerimientos de Calidad de Código y Configuración

MSTG-CODE-4
del Compilador

Requerimientos de Calidad de Código y Configuración

MSTG-CODE-5
del Compilador
Requerimientos de Calidad de Código y Configuración
MSTG-CODE-6
del Compilador
Requerimientos de Calidad de Código y Configuración
MSTG-CODE-7
del Compilador
Requerimientos de Calidad de Código y Configuración
MSTG-CODE-8 del Compilador

Requerimientos de Calidad de Código y Configuración

MSTG-CODE-9
del Compilador

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-1 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-2 Inversa
Impedir el Análisis Dinámico y la Manipulación
 Requerimientos de Resistencia ante la Ingeniería
MSTG-RESILIENCE-3 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-4 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-5 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-6 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-7 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-8 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-9 Inversa
Asociación del Dispositivo

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-10 Inversa
Impedir el Análisis Dinámico y la Manipulación

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-11 Inversa
Impedir la Comprensión

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-12 Inversa
Impedir la Comprensión

Requerimientos de Resistencia ante la Ingeniería

MSTG-RESILIENCE-13 Inversa
Impedir el Eavesdropping
 DESCRIPCION

Todos los componentes se encuentran identificados y asegurar que son

necesarios.

Los controles de seguridad nunca se aplican só lo en el cliente, sino que

también en los respectivos servidores.

Se definió una arquitectura de alto nivel para la aplicació n y los servicios y

se incluyeron controles de seguridad en la misma.

Se identificó claramente la informació n considerada sensible en el contexto

de la aplicació n mó vil.

Todos los componentes de la aplicació n está n definidos en términos de la

ló gica de negocio o las funciones de seguridad que proveen.

Se realizó un modelado de amenazas para la aplicació n mó vil y los servicios

en el que se definieron las mismas y sus contramedidas.

Todos los controles de seguridad poseen una implementados centralizada.

Existe una política explícita sobre el uso de claves criptográ ficas (si se usan)
a través de todo su ciclo de vida. Idealmente siguiendo un está ndar de
gestió n de claves como el NIST SP 800-57.

Existe un mecanismo para forzar las actualizaciones de la aplicació n mó vil.

La implementació n de medidas de seguridad es una parte esencial durante

todo el ciclo de vida del desarrollo de software de la aplicació n.

Existe una política de divualgació n responsable y es llevada a cabo

adecuadamente.

La aplicació n debería de cumplir con las leyes y regulaciones de privacidad.

Las funcionalidades de almacenamiento de credenciales del sistema deben de

ser utilizadas para almacenar información sensible, tal como información
personal, credenciales de usuario o claves criptográficas.
No se debe almacenar información sensible fuera del contenedor de la
aplicación o del almacenamiento de credenciales del sistema.

No se escribe información sensible en los registros (logs) de la aplicación.

No se comparte información sensible con servicios externos salvo que sea una
necesidad de la arquitectura.
Se desactiva la caché del teclado en los campos de texto que contienen
información sensible.
No se expone información sensible mediante mecanismos de comunicación
entre procesos (IPC).
No se expone información sensible como contraseñas y números de tarjetas de
crédito a través de la interfaz o capturas de pantalla.
No se incluye información sensible en las copias de seguridad generadas por el
sistema operativo.
La aplicación elimina toda información sensible de la vista cuando la aplicación
pasa a un segundo plano.
La aplicación no conserva ninguna información sensible en memoria más de lo
necesario y la memoria se limpia trás su uso.
La aplicación obliga a que exista una política mínima de seguridad en el
dispositivo, como que el usuario deba configurar un código de acceso.
La aplicación educa al usuario acerca de los tipos de información personal que
procesa y de las mejores prácticas en seguridad que el usuario debería seguir al
utilizar la aplicación.

No se guarda ningún tipo de información sensible de forma local en el

dispositivo móvil. En su lugar, esa información debería ser obtenida desde un
sistema remoto sólo cuando es necesario y únicamente residir en memoria.

En caso de ser necesario guardar información sensible de forma local, ésta

debe de ser cifrada usando una clave derivada del hardware de
almacenamiento seguro, el cual debe requerir autenticación previa.
El almacenamiento local de la aplicación debe de ser borrado trás un número
excesivo de intentos fallidos de autenticación.
La aplicación no depende únicamente de criptografía simétrica cuyas claves se
encuentran directamente en el código fuente de la misma.
La aplicación utiliza implementaciones de criptografía probadas.
La aplicación utiliza primitivas de seguridad que son apropiadas para el caso
particular y su configuración y parámetros siguen las mejores prácticas de la
industria.
La aplicación no utiliza protocolos o algoritmos criptográficos ampliamente
considerados obsoletos para su uso en seguridad.

La aplicación no reutiliza una misma clave criptográfica para varios propósitos.

Los valores aleatorios son generados utilizando un generador de números

aleatorios suficientemente seguro.

Si la aplicación provee acceso a un servicio remoto, un mecanismo aceptable

de autenticación como usuario y contraseña es realizado en el servidor remoto.

Si se utiliza la gestión de sesión por estado, el servidor remoto usa tokens de

acceso aleatorios para autenticar los pedidos del cliente sin requerir el envío de
las credenciales del usuario en cada uno.

Si se utiliza la autenticación basada en tokens sin estado, el servidor

proporciona un token que se ha firmado utilizando un algoritmo seguro.

Cuando el usuario cierra sesión se termina la sesión también en el servidor.

Existe una política de contraseñas y es aplicada en el servidor.

El servidor implementa mecanismos, cuando credenciales de autenticación son

ingresadas una cantidad excesiva de veces.
Las sesiones y los tokens de acceso expiran luego de un tiempo predefinido de
inactividad.

La autenticación biométrica, si la hay, no está asociada a eventos (p. ej. usando

una API que simplemente retorna “true” o “false”), sino basada en el
desbloqueo del keychain/keystore (almacenamiento seguro).

El sistema remoto implementa un mecanismo de segundo factor de

autenticación (2FA) y lo impone consistentemente.
Para realizar transacciones críticas se requiere una autenticación adicional
(step-up).

La aplicación informa al usuario acerca de todas las actividades sensibles en su

cuenta. El usuario es capaz de ver una lista de los dispositivos conectados,
información contextual (dirección IP, localización, etc.), y es capaz de bloquear
ciertos dispositivos.

Los modelos de autorización deberían de ser definidos e impuestos por el

sistema remoto.
La información es enviada cifrada utilizando TLS. El canal seguro es usado
consistentemente en la aplicación.
Las configuraciones del protocolo TLS siguen las mejores prácticas de la
industria, o lo hacen lo mejor posible en caso de que el sistema operativo del
dispositivo no soporte los estándares recomendados.

La aplicación verifica el certificado X.509 del sistema remoto al establecer el

canal seguro y sólo se aceptan certificados firmados por una CA de confianza.

La aplicación utiliza su propio almacén de certificados o realiza pinning del

certificado o la clave pública del servidor. Bajo ningún concepto establecerá
conexiones con servidores que ofrecen otros certificados o claves, incluso si
están firmados por una CA de confianza.

La aplicación no depende de un único canal de comunicaciones inseguro (email

o SMS) para operaciones críticas como registro de usuarios o recuperación de
cuentas.
La aplicación sólo depende de bibliotecas de conectividad y seguridad
actualizadas.

La aplicación requiere la cantidad de permisos mínimamente necesaria.

Todo dato ingresado por el usuario o cualquier fuente externa debe ser
validado y, si es necesario, saneado. Esto incluye información recibida por la UI
o mecanismos IPC como los Intents, URLs y datos provenientes de la red.

La aplicación no expone ninguna funcionalidad sensible a través esquemas de

URL salvo que dichos mecanismos estén debidamente protegidos.
La aplicación no expone ninguna funcionalidad sensible a través de
mecanismos IPC salvo que dichos mecanismos estén debidamente protegidos.

JavaScript se encuentra deshabilitado en los WebViews salvo que sea

necesario.
Las WebViews se configuran para permitir el mínimo de los esquemas
(idealmente, sólo https). Esquemas peligrosos como file, tel y app-id están
deshabilitados.

Si objetos nativos son expuestos en WebViews, debe verificarse que cualquier

componente JavaScript se carga exclusivamente desde el contenedor de la
aplicación.
La serialización de objetos, si se realiza, debe implementarse utilizando API
seguras.

La aplicación se protege contra ataques de tipo screen overlay. (sólo Android)

La caché, el almacenamiento y los recursos cargados (JavaScript, etc.) de las

WebViews deben de borrarse antes de destruir la WebView.
Verificar que la aplicación impide el uso de teclados de terceros siempre que se
introduzca información sensible.
La aplicación es firmada y provista con un certificado válido, cuya clave privada
está debidamente protegida.
La aplicación fue publicada en modo release y con las configuraciones
apropiadas para el mismo (por ejemplo, non-debuggable).

Los símbolos de depuración fueron eliminados de los binarios nativos.

Cualquier código de depuración y/o de asistencia al desarrollador (p. ej. código

de test, backdoors, configuraciones ocultas) debe ser eliminado. La aplicación
no hace logs detallados de errores ni de mensajes de depuración.

Todos los componentes de terceros se encuentran identificados y revisados en

cuanto a vulnerabilidades conocidas.

La aplicación captura y gestiona debidamente las posibles excepciones.

Los controles de seguridad deniegan el acceso por defecto.

En código no administrado, la memoria es solicitada, utilizada y liberada de

manera correcta.
Las funcionalidades de seguridad gratuitas de las herramientas, tales como
minificación del byte-code, protección de la pila, soporte PIE y conteo
automático de referencias, se encuentran activadas.

La aplicación detecta y responde a la presencia de un dispositivo rooteado, ya

sea alertando al usuario o finalizando la ejecución de la aplicación.

La aplicación impide la depuración o detecta y responde a la misma. Se deben

cubrir todos los protocolos de depuración.
La aplicación detecta y responde a cualquier modificación de ejecutables y
datos críticos de la propia aplicación.

La aplicación detecta la presencia de herramientas de ingeniería inversa o

frameworks comunmente utilizados.

La aplicación detecta y responde a ser ejecutada en un emulador.

La aplicación detecta y responde ante modificaciones de código o datos en su

propio espacio de memoria.

La aplicación implementa múltiples mecanismos de detección para los puntos

del 8.1 al 8.6. Nótese que, a mayor cantidad y diversidad de mecanismos
usados, mayor será la resistencia.

Los mecanismos de detección provocan distintos tipos de respuestas,

incluyendo respuestas retardadas y silenciosas.

La ofuscación se aplica a las defensas del programa, lo que a su vez impide la

desofuscación mediante análisis dinámico.

La aplicación implementa un “enlace al dispositivo” utilizando una huella del

dispositivo derivado de varias propiedades únicas al mismo.

Todos los archivos ejecutables y bibliotecas correspondientes a la aplicación se

encuentran cifrados, o bien los segmentos importantes de código se
encuentran cifrados o “empaquetados” (packed). De este modo cualquier
análisis estático trivial no revelará código o datos importantes.

Si el objetivo de la ofuscación es proteger código propietario, debe utilizarse un

esquema de ofuscación apropiado para la tarea particular y robusto contra
métodos de desofuscación manual y automatizada, considerando la
investigación actual publicada. La eficacia del esquema de ofuscación debe
verificarse mediante pruebas manuales. Nótese que, siempre que sea posible,
las características de aislamiento basadas en hardware son preferibles a la
ofuscación.

A modo de defensa en profundidad, además de incluir un refuerzo (hardening)

sólido de la comunicación, puede implementarse el cifrado de datos (payloads)
a nivel de aplicación como medida adicional contra ataques de eavesdropping.
RECOMENDACIÓN HERRAMIENTAS
VULNERABILIDADES
CÓDIGO OWISAM TITULO OWISAM

OWISAM-DI-001 Descubrimiento de dispositivos WiFi no autorizados

OWISAM-DI-002 Descubrimiento de redes ocultas

Identificación pasiva de direcciones MAC de dispositivos

OWISAM-DI-003
(clientes)

Descubrimiento de preferencias de redes conocidas de

OWISAM-DI-004
clientes

OWISAM-DI-005 Descubrimiento activo de dispositivos y redes

OWISAM-FP-001 Identificación del dispositivo

Identificación de funcionalidades soportadas por el

OWISAM-FP-002 dispositivo

Enumeración de mecanismos de autenticación radius

OWISAM-FP-003
(802.1x)

OWISAM-FP-004 Detección de Rogue Aps

OWISAM-FP-005 Pruebas de client isolation

OWISAM-FP-006 Detección de ataques por parte de dispositivos Wireless

OWISAM-AU-001 Detección de protección de acceso basado en MAC

OWISAM-AU-002 Pruebas sobre WPS

OWISAM-AU-003 Pruebas de downgrade del método de autenticación

Captura de las claves transmitidas en el proceso de

OWISAM-AU-004 autenticación

Uso de protocolos de autenticación inseguros en 802.1x

OWISAM-AU-005
(FAST-EAP, LEAP, EAP-MD5)

Pruebas de fuerza bruta de usuarios/contraseñas de

OWISAM-AU-006
RADIUS (802.1x)

OWISAM-AU-007 Pruebas de fuerza bruta de contraseñas contra el proceso

de autenticación (PSK)

OWISAM-AU-008 Debilidades en el repositorio de credenciales

OWISAM-CP-001 Captura y análisis de tráfico en red abierta

OWISAM-CP-002 Descifrado de tráfico cifrado

Pruebas de análisis de información transmitida a través de

OWISAM-CP-003
Wireless
OWISAM-CP-004 Análisis de protocolos de cifrado inseguro (WEP, TKIP,…)

OWISAM-CP-005 Pruebas de renovación de claves de cifrado

OWISAM-CP-006 Pruebas de re-inyección de tráfico (replay attack, Mic,…)

OWISAM-CF-001 Identificación de redes Wireless con ESSID genérico

Contraseñas genéricas en interfaz administrativa del punto

OWISAM-CF-002
de acceso

OWISAM-CF-003 Verificación del nivel de intensidad de la señal o área de

cobertura

Análisis del solapamiento de redes en el mismo canal de

OWISAM-CF-004
comunicaciones

OWISAM-CF-005 Generación de claves en base a algoritmos conocidos

OWISAM-CF-006 Pruebas sobre UpNP

OWISAM-IF-001 Debilidades en el firmware del AP

OWISAM-IF-002 Interfaces administrativas expuestas a la red

OWISAM-IF-003 Política de firewall incorrecta

OWISAM-IF-004 Controles sobre mecanismos de detección de intrusos

OWISAM-IF-005 Pruebas de verificación de túneles VPN

OWISAM-IF-006 Debilidades en servidor RADIUS

OWISAM-IF-007 Vulnerabilidades incubadas

OWISAM-IF-008 Gestión (Alta/Baja/Modificación) de claves y certificados

Dispositivos de comunicaciones accesibles/expuestos

OWISAM-IF-009
físicamente

OWISAM-IF-010 Detección y análisis de sistemas Scada

OWISAM-DS-001 Pruebas de deautenticación

OWISAM-DS-002 Saturación del canal de comunicaciones

OWISAM-DS-003 Bloqueo de cuentas de usuario

OWISAM-DS-004 Bloqueo de dispositivo de comunicaciones

OWISAM-DS-005 Pruebas de degradación del canal de comunicaciones

OWISAM-GD-001 Identificación de dispositivos que no cumplen el estándar

Detección de dispositivos emitiendo en frecuencias

OWISAM-GD-002
restringidas

Análisis de la política de uso/restricción de uso de redes

OWISAM-GD-003
inalámbricas

OWISAM-GD-004 Análisis de configuración de dispositivos

OWISAM-GD-005 Análisis de la política de gestión y cambio de claves

OWISAM-GD-006 Verificación de inventario de dispositivos autorizados

OWISAM-CT-001 Pruebas de Rogue AP y asociación automática

Análisis de APTs (Advanced Persistent Threats) sobre

OWISAM-CT-002
Wireless
OWISAM-CT-003 Desbordamiento de buffer en cliente

OWISAM-CT-004 Extracción de identificadores de usuarios (802.1x)

OWISAM-CT-005 Pruebas sobre supplicant débil o inseguro

OWISAM-CT-006 Ataques contra clientes

OWISAM-CT-007 Extracción de credenciales de los clientes

OWISAM-HS-001 Acceso a otros segmentos de red sin autenticación

OWISAM-HS-002 Debilidades en el mecanismo de autenticación

OWISAM-HS-003 Pruebas de encapsulación de tráfico con el exterior

OWISAM-HS-004 Debilidades en el portal cautivo

 DESCRIPCION

Comprobar si existe algún dispositivo WiFi que no debería estar ahí.

Identificación de redes ocultas existentes

Identificación de clientes asociados al AP

Escanear durante cierto tiempo para localizar clientes y sus

continuas asociaciones a través de los "Probe Requests"

Mediante el envío de frames “Probe Request” contra direcciones de

broadcast (FF:FF:FF:FF:FF:FF) o con un parámetro BSSID/ESSID
específico se pueden identificar las redes que se encuentran a
nuestro alcance, incluso aunque éstas se encuentren configuradas
como red oculta.

Determinados frames de tipo "Management" contienen una serie de

parámetros conocidos como “Information Elements” cuyos valores
revelan información acerca del dispositivo y sus funcionalidades. Por
ejemplo, el IE con identificador 0xDD, está asociado a Wi-Fi
protected Setup (WPS), y publica información sobre el dispositivo de
comunicaciones.

En los frames “Management”, muchas veces se envían una serie de

parámetros, ya sea dentro de los “Fixed Parameters” o los “Tagged
Parameters”, que posibilitan la identificación de las distintas
funcionalidades de los dispositivos.

La verificación de este control permite la identificación mecanismos

de autenticación débiles disponibles (EAP-MD5, EAP-LEAP, FAST-
EAP...) normalmente debidos a una incorrecta configuración del
servidor.

La existencia de puntos de acceso dentro de una organización, que

no han sido autorizados para su uso, o la presencia en el perímetro
de puntos de acceso creados con el objetivo de engañar al usuario y
forzar su vinculación y conexión a ellos.

El objetivo de ataques entre clientes es comprometer una STA

pudiendo realizar ataques Man in the Middle, inyección de código en
dispositivos o realizar ataques de denegación de servicio (Hole 196).
Comprobar la comunicación entre clientes.
Es posible que alguno de los dispositivos dentro del alcance de la red
Wi-Fi se encuentre realizando algún tipo de actividad ilícita dentro
de la misma con algún propósito malicioso.

Comprobación de acceso limitado a una whitelist. Si existe acceso

limitado por MAC spoofear una MAC de cliente conectada
correctamente con, por ejemplo, macchanger.
Realización de ataques sobre el AP con WPS activado, ataques de
PIN guessing y PIN cracking (brute force).
Una mala configuración por defecto de un servidor RADIUS puede
permitir la utilización de distintos mecanismos de autenticación
incluyendo aquellos que son inseguros.

En esta parte se capturarán los paquetes con las credenciales

enviadas por los clientes de los AP. Obtendremos el handshake de
WPA y la autenticación de 802.1x

Dentro de los métodos de autenticación soportados por un servidor

RADIUS existen varios cuya seguridad ya se ha visto comprometida y
han probado ser inseguros.

El servidor RADIUS, en la mayoría de implementaciones, funciona

como cualquier otro servidor, por lo que es posible realizar
numerosos intentos de autenticación con el fin de obtener
credenciales válidas de acceso.

Cuando se utiliza autenticación basada en clave compartida (PSK) es

factible intentar realizar ataques de fuerza bruta, probando
diferentes claves.

Para verificar la seguridad de las credenciales se debe tener acceso a

ellas, por lo cual o se compromete el sistema o se pide acceso al
sistema que las almacena.

Si no se utiliza ningún método de cifrado es posible visualizar todo el

tráfico en texto claro capturado a través de la red Wi-Fi, siempre que
no se use un mecanismo alternativo de cifrado, como por ejemplo el
envío de credenciales a través de HTTPS, túneles VPN, etc.

En el caso de las redes Wi-Fi en las que se utiliza una clave

precompartida (PSK) existe la posibilidad de llevar a cabo el proceso
de descifrado de las comunicaciones cifradas cuando se conoce
dicha clave.

Cuando al menos parte de comunicación se realiza a través de redes

Wi-Fi, cuyo medio de transmisión es por defecto inseguro (el aire), se
deben de tomar todas las precauciones posibles para protegerla.
Debido a esto, muchos de los algoritmos de cifrado que se
consideraban seguros ya no lo son tanto. Por si esto no fuera
suficiente, se han encontrado vulnerabilidades y colisiones en los
hashes generados por algunos de estos algoritmos.

Tanto el protocolo de cifrado WPA como WPA2 ofrecen la

posibilidad de establecer un tiempo máximo durante el cual las
claves de cifrado serán válidas. Una vez finalizado el fijado para cada
cliente, se produce un nuevo proceso de 4-way-handshake de forma
automática y transparente al usuario

Aunque muchas veces no se pueda obtener la PSK (Pre-Shared Key),

las redes Wi-Fi pueden estar expuestas a ataques de reinyección de
tráfico. Estos ataques se basan en la recuperación de un keystream
válido, o bien un frame específico.

El uso de redes Wi-Fi con ESSIDs genéricos puede suponer un

problema de seguridad por varios factores

Se comprobará, en caso de tener acceso, las credenciales del panel

de administración del punto de acceso y la capacidad para realizar
fuerza bruta a través de HTTP. Probar también con cuentas que no
son visibles, como support:support

El perímetro de seguridad de una red Wi-Fi depende en gran medida

de la cobertura que dicha red es capaz de proveer. Una incorrecta
configuración de la red podría permitir que la cobertura de la misma
se propagase fuera del perímetro de la organización.

Esto hace que algunos rangos de frecuencia se encuentren muy

saturados, por lo que al configurar múltiples redes Wi-Fi en el mismo
canal o en canales que se solapan, la calidad de las comunicaciones
se ve muy degradada.

Se intenta la identificación de claves genéricas para dispositivos a

través de su BSSID, SSID, firmware…

El creciente número de debilidades en este protocolo, que afectan

en gran medida a routers Wi-Fi, requiere que el uso y soporte de
UPnP sea evaluado de forma adecuada para evitar accesos no
autorizados en la infraestructura de red.
El firmware integrado no suele estar enfocado a la seguridad, sino al
rendimiento y a la escalabilidad, motivo por el cual los fallos de
seguridad son bastante comunes. Cada día existe un mayor número
de APs por lo que comienzan a suponer un vector de ataque
importante a la hora de conseguir acceso a una red.

Por defecto las interfaces administrativas de muchos dispositivos son

accesibles desde la red Wi-Fi, esto ocurre sobre todo en los routers
que se emplean como AP. Estas interfaces vienen configuradas con
credenciales por defecto que son muy predecibles o incluso
disponen de una página de ayuda accesible a todos los usuarios en la
que se pueden consultar.

Comprobar que los dispositivos físicos no estén accesibles a

manipulaciones por parte de terceros.

Comprobar si, dentro de la red Wireless, existen comunicaciones de

sistemas SCADA. Estos sistemas pueden ser susceptibles de ataques
a través de la red provocando un gran impacto sobre el sistema que
controlan automaticamente.

Se comprobará nuestra capacidad para realizar un ataque deauth

contra un cliente en concreto o contra toda la red.

La integración de la autenticación WPA(2) - Enterprise con un

servicio RADIUS que emplee alguno de los almacenes de
credenciales citados anteriormente, puede posibilitar el abuso de
funcionalidad y que sea utilizado por parte de usuarios para realizar
ataques de fuerza bruta que resulten en el bloqueo de las cuentas de
usuario.
Un desbordamiento de buffer en el dispositivo, o el envío de
mensajes que fuercen un alto consumo de recursos en el dispositivo,
como por ejemplo envío de mensajes de autenticación WPS que
fuerzan a un router a realizar un alto número de operaciones en el
procesador, pueden ser utilizados para bloquear la comunicación.

Se debe comprobar AP que esté funcionando siguiendo el estándar

802.11b/g, para ello basta con fijar una tarjeta Wi-Fi en el modo de
funcionamiento de 11Mbps y comprobar la velocidad de la conexión.
Desde Kali Linux es tan sencillo como: sudo iwconfig wlan0 rate 11M

Mediante el análisis de paquetes de datos, ignorando el parámetro

FCS (Frame Check Sequence) puede ser posible identificar
comunicaciones entre dispositivos inalámbricos que no cumplen
correctamente el estándar y que hacen uso de su propio protocolo
de comunicaciones.

Existen frecuencias englobadas en el estándar 802.11, tanto en la

banda de 2.4Ghz como en la de 5Ghz que no pueden ser utilizadas
en ciertos países.

El objetivo de este control es analizar si existe una normativa interna

en la organización sobre el uso de las redes Wi-Fi.
De existir, se debe evaluar si los dispositivos que hacen uso de
comunicaciones Wi-Fi cumplen lo definido en la norma y únicamente
aquellos dispositivos o usuarios autorizados disponen de acceso a la
red.

Se deben establecer políticas para que se realice un cambio de

claves periódico en las redes Wi-Fi que hacen uso de un secreto
compartido (PSK).

Análisis del inventario de dispositivos autorizados para la conexión a

las redes de comunicaciones Wi-Fi, cuyo acceso se encuentra
restringido.

Se realizarán pruebas de Rogue AP contra los clientes

Se debe monitorizar el tráfico Wi-Fi prestando atención al

geoposicionamiento de dispositivos y al inventario existentes.
Dispositivos con funcionalidad de keyloggers Wi-Fi, como es el caso
de keelog, pueden ser detectados mediante este análisis.
Normalmente cuando se diseñan drivers para hardware
determinado como puede ser una tarjeta de red Wi-Fi, no se hace
desde el punto de vista de la seguridad. Esto puede acabar
derivando en un fallo de seguridad conocido como desbordamiento
de búfer (buffer overflow).

Una vez realizado un ataque con éxito contra los clientes (equipos
portátiles, dispositivos móviles,...) se deben extraer los perfiles de
configuración de las redes inalámbricas.

En las redes que utilizan portales cautivos como medida de

autenticación es necesario verificar que la red está correctamente
segmentada y que los clientes que acceden al portal cautivo no
dispongan de conexión con otros segmentos de red

Se debe verificar que el portal cautivo emplea un método de

autenticación seguro, ya que de otra forma las credenciales de
acceso podrían ser interceptadas por un usuario malintencionado.

Se debe verificar que a los usuarios que acceden al portal cautivo no

se les permite llevar a cabo ningún tipo de encapsulación de tráfico
al exterior, ya sea explotando débilidades de la interfaz web o
mediante la utilización de protocolos a nivel de capa de aplicación
como DNS (DNS tunneling).

Es necesario verificar que no existen debilidades en el portales de

autenticación, generalmente interfaces web, que puedan ser
explotadas para vulnerar la seguridad la red ya sea para esquivar el
proceso de autenticación o permitiendo ganar privilegios en el
dispositivo.
 RECOMENDACIÓN HERRAMIENTAS

Evitar la presencia de dispositivos no autorizados que puedan

suponer un riesgo para la organización.
-Evitar nombres que identifiquen a la organización.
airodump-ng
-Políticas para todo el personal.
-Inventario de dispositivos autorizados.
-Implantación de sistemas WIDS.

Evaluar que existen controles de seguridad compensatorios.

-Deshabilitar "conexión automática" en clientes. airodump-ng
-Verificación de firmware actualizado

airodump-ng
N/A
airgraph-ng

Se deberían eliminar las redes preferidas de los dispositivos,

sobre todo las que no se van a volver a utilizar (hoteles, probeSniffer
cafeterías...) y las que pertenezcan a la entidad corporativa.

Se deberían eliminar las redes preferidas de los dispositivos,

sobre todo las que no se van a volver a utilizar (hoteles, N/A
cafeterías...) y las que pertenezcan a la entidad corporativa.

wash
N/A WPSIG
airodump-ng

N/A Wireshark

Es necesario eliminar los métodos de autenticación inseguros y airodump-ng

permitir únicamente aquel que se vaya a utilizar. Wireshark

Monitorizar periódicamente la actividad en busca de nuevos

airodump-ng
puntos de acceso que puedan haber sido desplegados

Habilitar el client-isolation dentro de la configuración del punto

N/A
de acceso.
Se debe habilitar durante un tiempo extendido algún dispositivo
de monitoreo de la red Wireless en busca de ataques vinculados Kismet
con la red auditada.

Verificar que existen controles de seguridad adicionales que macchanger

aporten una protección real de la plataforma. mdk3

Deshabilitar el soporte de WPS PIN y verificar que dicha reaver

funcionalidad no se encuentra activa. wash

Deshabilitar el soporte de WPS PIN y verificar que dicha

audit-radius
funcionalidad no se encuentra activa.

airodump-ng
Hacer uso de mecanismos de autenticación robustos, con WPA2-
aireplay-ng
CCMP, no utilizar credenciales genéricas o predecibles y habilitar mdk3
la renovación automática de claves.
crEAP

Usar un método de autenticación robusto y deshabilitar todos los

audit-radius
demás.

Es imprescindible disponer de algún sistema de protección ante

ataques de fuerza bruta, así como una buena política de Auto_EAP
contraseñas.

Usar contraseñas robustas (8 caracteres mínimo, incluyendo

letras mayúsculas, números y símbolos especiales).
-Evaluar si sería mejor optar por implantar una solución RADIUS. aircrack-ng
-También es factible usar un WIDS o un firewall a nivel de router o
AP para limitar los intentos de autenticación

Las credenciales de acceso de cada usuario deben almacenarse

N/A
en forma de hashes usando un algoritmo criptográfico seguro.

En una organización, las redes abiertas no deberían estar

presentes, ya que generan nuevos vectores de ataque que un Wireshark
usuario malintencionado podría aprovechar.

Usar siempre una contraseña lo más robusta posible y un

algoritmo de cifrado seguro. En caso de usar WPA/2 habilitar la
renovación de claves, si es posible en un umbral de tiempo Wireshark
inferior a 3.600 segundos.

Como primera medida, se debe hacer hincapié en usar el sistema

de cifrado más robusto del que se dispone a nivel de capa de
Wireshark
enlace (actualmente AES-CCMP). En las capas superiores es
recomendable el uso soluciones VPN, IPSec o SSL.
El uso de los algoritmos de cifrado TKIP y WEP se encuentra
desaconsejado por la Wi-Fi Alliance. A la hora de utilizar un
airodump-ng
protocolo de cifrado (cipher suite en inglés) la mejor opción es
usar siempre el más robusto, en la actualidad AES-CCMP

Las medidas a tomar deberían ser establecer un intervalo de

renovación de claves siempre inferior a 3600 segundos y usar una N/A
suite de cifrado lo más robusta posible (AES-CCMP).

La mejor medida es establecer WPA2 con AES-CCMP como

método de autenticación y cifrado, estableciendo un tiempo de
¿?
renovación de claves prudencial, es decir, inferior a 3600
segundos.

Se recomienda evitar todo lo posible nombres genéricos o que

puedan revelar información no deseada como puede ser la N/A
utilidad de la red o que perfil de usuarios la tienen acceso.

Modificar siempre las credenciales por defecto, sustituyéndolas

BurpSuite
por unas más robustas.

La potencia con la que los APs difunden la red debe estar

controlada y limitada, evitando que el perímetro de cobertura Acrylic HeatMaps
exceda más de lo imprescindible fuera de los límites de la
organización

Las diferentes redes Wi-Fi de la organización deberían estar

Acrylic HeatMaps
configuradas en diferentes canales sin solapamiento.

Los usuarios deben realizar el cambio de la clave de fábrica de

cualquier router Wi-Fi para evitar la exposición a estos ataques.
Los operadores de telecomunicaciones y fabricantes de hardware
deben hacer uso de algoritmos que generen claves aleatorias. Si N/A
es necesario poder obtener una clave fija para un dispositivo, se
recomienda hacer uso de valores del hardware que no puedan
conocidos remotamente.

Si el servicio de UPnP que se está utilizando resulta ser

miranda
vulnerable, la mejor opción es deshabilitar esta funcionalidad.
Es importante que el firmware del AP esté actualizado a su última
versión con los últimos parches de seguridad. A mayores se
N/A
debería mantener un log de eventos de todo lo que ocurre en el
AP.

Aunque las interfaces administrativas son necesarias, no deben

ser ser accesibles desde cualquier parte de la red, ya que si un
N/A
usuario no autorizado logra acceder a ellas es muy posible que
pueda llegar a modificar la configuración del dispositivo.

Todos los dispositivos de comunicaciones deben estar situados de

tal manera que un tercero no pueda manipular su N/A
comportamiento a través de vía física.

Las comunicaciones de los sistemas SCADA deben ir cifradas y,

siempre que sea posible, evitar el uso de redes Wireless. Además N/A
se deberá comprobar si estos sistemas tienen vulnerabilidades.

Dada la implementación actual del estándar por parte de los

dispositivos es muy difícil prevenir que esto suceda e incluso
mitigarlo. Para la parte que corresponde al AP se pueden aireplay-ng
establecer un Wi-Fi IDS que alerte y prevenga cuándo se reciben
varios de estos frames, evitando que el AP llegue a procesarlos.

Establecer alguna medida de protección estilo IDS/IPS o Firewall,

que bloquee determinadas peticiones o los dispositivos que las Auto_EAP
realizan.
El firmware del dispositivo debe estar actualizado a la última
versión, con todos los parches de seguridad. Además el AP
¿?
debería estar protegido por algún sistema que facilitase el control
de la carga de trabajo y evitase la denegación de servicio.

En caso de que no sea imprescindible, deshabilitar la

funcionalidad de compatibilidad del AP con redes 802.11b
N/A
permitiendo únicamente conexiones Wi-Fi que sigan el estándar
802.11g.

Deberían usarse siempre dispositivos que cumplan el estándar, ya

que son más fáciles de monitorizar y tener controlados. Además N/A
se evitan comportamientos extraños y problemas en la red.

No debería haber ningún dispositivo empleando frecuencias

restringidas. Cambiar su configuración si es posible o sustituirlos ¿?
cuando no haya otra solución.

Es importante que las redes Wi-Fi de la empresa no se empleen

para tareas críticas, debido a los riesgos que suponen. Además es
importante saber qué dispositivos y usuarios están autorizados N/A
para emplearlas y así poder mantener un control sobre las
mismas.

Es necesario ir rotando para asegurar que ninguna persona no

autorizada no tiene acceso a los recursos de la misma que se
quieren proteger. Por este motivo, como medida fundamental
debería existir una política que establezca una robustez mínima y N/A
una duración temporal máxima para las contraseñas que se
empleen en la organización.

El análisis periódico de esta información permitirá detectar

N/A
accesos no autorizados y desviaciones en la normativa interna.

La protección frente a Rogue APs se debe establecer en varios

niveles, ya que los elementos de protección perimetral, como es Piña WiFi
el caso de los firewalls, no tienen capacidad de identificar ni Wifiphisher
bloquear conexiones a sistemas externos a la infraestructura.

Evaluar periódicamente la infraestructura en busca de nuevos

dispositivos Wi-Fi y monitorizar el tráfico en busca de patrones de Wireshark
tráfico anómalos.
Los drivers de las tarjetas Wi-Fi deberían estar actualizados a su
última versión y verificar que tengan aplicados todos los parches N/A
de seguridad.

MITMf

La mejor forma de evitar que las credenciales de acceso a la

organización se vean expuestas es verificar que estas no están N/A
siendo almacenadas en los equipos y dispositivos de los usuarios.

Se debe establecer una segmentación adecuada antes de

desplegar un portal cautivo y verificar que no existe visibilidad de
netdiscover
otros segmentos de red y otros direccionamiento antes de la
autenticación.

Se recomienda usar certificados o en su defecto un método de

autenticación más seguro que mandar las credenciales en texto N/A
plano, como puede ser Digest.

Asignar al usuario una vlan aislada sin conexión con redes iodine
externas. El servicio DNS encargado de ofrecer resolución de DNScapy
nombres al usuario conectado a la red Wi-Fi únicamente debe icmptx
resolver nombres internos. dns2tcp

En caso de disponer de un portal cautivo a través del cual se

permita o no el acceso a la red, es imprescindible verificar que los N/A
controles de seguridad están implementados correctamente.
 VULNERABILIDADES

Presencia de clientes no
autorizados y rogue APs

Debilidad en el firmware y
seguridad por oscuridad

Dispositivos no autorizados
conectados

Asociación automática a AP
inseguro

Identificación de dispositivos
mediante técnicas de
descubrimiento activo.

Obtención de información sobre el

hardware y software.

Obtención de información sobre el

hardware y software.

Mecanismos de autenticación
inseguros.

Intrusos en redes Wireless

Ataques a clientes
Intrusos en redes Wi-Fi

Mayores probabilidades de
intrusión no autorizada

Acceso no autorizado a Wireless

Inseguridad en mecanismos de
autenticación.

Credenciales débiles.

Interceptación y descifrado de
credenciales.

Contraseñas débiles.

Posibilidad de descifrar
contraseñas débiles offline.

Acceso no autorizado y robo de

credenciales.

Transmisión de información
sensible.

Transmisión de información
sensible.

Obtención de información sensible.

Debilidad de seguridad en la red.

Tiempo de vida de claves

criptográficas elevado.

Suplantación de identidad

Suplantación de identidad y
ataques basados en memory
trading.

Credenciales débiles o por defecto

y acceso no autorizado.

Área de cobertura excesiva

Degradación de calidad del servicio.

Algoritmos de claves PSK o WPS

débiles.

Redirección de puertos.
Robo de credenciales y acceso no
autorizado.

Acceso no autorizado e
interceptación de tráfico.

Acceso a segmentos de red

restringidos.
Ausencia de sistemas de
monitorización.

Interceptación de comunicaciones.

Ejecución remota de código o

denegación de servicio.
Debilidades en elementos de
arquitectura o software
Gestión incorrecta de claves de
acceso

Acceso no autorizado y
modificación de firmware

Acceso a sistemas de control

industrial

Interceptación de credenciales de
autenticación

Ataques a la disponibilidad del

servicio.

Bloqueo de cuentas
Suplantación de AP y DOS

Degradación de servicio

N/A

Emisión de señal no autorizada

Accesos indebidos

Configuración incorrecta

Tiempo de vida de contraseñas

elevado, política de contraseñas
fuertes no activa.

Inventario no actualizado.

Suplantación de identidad y robo

de credenciales

Existencia de APTs
Ausencia de parches de seguridad y
RCE

Recopilación de información y
configuración insegura

Modificación de respuestas DNS

Suplantación de identidad

Segmentación o política de
cortafuegos incorrecta

Acceso no autorizado

Evasión del mecanismo de

autenticación

Acceso no autorizado