Blog de Amazon Web Services (AWS)

¿Cómo habilitar Account Takeover Prevention (ATP) para proteger mis páginas de inicio de sesión?

Por Mario Navarro, Sr. Technical Account Manager en AWS

 

En el servicio de AWS Web Application Firewall (WAF), contamos con las Reglas Administradas que son parte de un grupo de subreglas creadas y gestionadas por AWS, estas ayudan a proporcionar protección contra vulnerabilidades existentes a nivel aplicativo y otros accesos no deseados a sistemas; sin tener que escribir reglas personalizadas. Recientemente, se incorporó un nuevo grupo de reglas (paid rule groups) el cual agrega protección contra Bots, utilizando Bot Control y Account Takeover (ATP) con Account Takeover Prevention.

En esta publicación mostraré los pasos a seguir para configurar el Web Access Control List (Web ACL) y la regla de Account Takeover Prevention, en el servicio de AWS Web Application Firewall (WAF) brindando una protección adicional a lo que son las páginas de inicio de sesión (login endpoints).

¿Qué es una apropiación de Cuenta (ATO por sus siglas en inglés)?

El fraude de apropiación de cuenta es una forma de robo de identidad que ha estado creciendo y teniendo relevancia en los últimos años. La apropiación de cuenta es el acceso malicioso por parte de un estafador o ciber criminal que se hacen pasar por un cliente real para obtener control de una cuenta y realizar transacciones no autorizadas.

En febrero 2022, AWS anunció el lanzamiento de AWS WAF Fraud Control – Account Takeover Prevention (ATP). Una nueva protección para ataques de relleno de credenciales (Credential Stuffing), intentos de fuerza bruta y otras actividades de inicio de sesión anómalas. Este grupo de reglas requiere una configuración adicional en comparación con el grupo de Reglas Administradas (managed rule groups), este proporciona mejores capacidades de detección cuando se combina con los SDK de integración de aplicaciones cliente de AWS WAF.

¿Cómo puedo activar el Account Takeover Prevention desde la consola de AWS?

Desde la consola de AWS, seleccionar el servicio de AWS WAF y elegir el Web ACLs en donde deseas habilitar la protección de ATP. Una vez seleccionada, proceder a agregar un “Managed Rule” o editar la regla existente.

Al habilitar la regla, se desplegará una notificación que indica que es requerido editar la regla para proveer configuración adicional.

Presionar el botón de “Edit” para configurar el mecanismo y parámetros de nuestro Login endpoint (página de inicio de session).

Se selecciona el tipo de mecanismo que se está utilizando para accesar a la aplicación. Existen 2 tipos: FORM_ENCONDED (formulario en HTML) o un JSON Payload. En ambos casos vamos a necesitar el endpoint login o URI y la ubicación de los parámetros.

En el siguiente ejemplo, vamos a utilizar el FORM_ENCODED.

Para efectos de este ejemplo, se generó un login endpoint en donde se solicita un usuario y contraseña al usuario a través de un formulario en HTML.

En la página de acceso, verificar el código fuente (View Page Source), donde desplegará el código a nivel de HTML. Este muestra el contenido del “form” y los parámetros necesarios para configurar el ATP endpoint en AWS WAF.

<html>
    <body> 
        <form action="user_login.html" method="POST"> 
            <div class="container"> 
            <label>Username : </label> 
            <input type="text" placeholder="Enter Username" name="username" required> <br>
            <label>Password : </label> 
            <input type="password" placeholder="Enter Password" name="password" required> <br><br><br>
            <button type="submit">Login</button> 
                <br><br><br>
            Forgot <a href="/forgotpass"> password? </a> 
            </div> 
        </form> 
    </body>
</html>

Para definir el Rule Group Configuration se requerirá el código mencionado en la imagen anterior, es necesario la acción (action) y los nombres de variables declarados para el usuario y contraseña; es necesario agregar la siguiente información:

  • action=»user_login.html» = Login Path, necesitamos agregar el «/» al inicio de user_login.html
  • username & password = como son basadas en formulario (form based), vamos a tener que agregar “/form/” y luego el parámetro.

Ver imagen a continuación: (Rule group configuration)

¿Cómo Account Takeover Prevention evalúa y etiqueta las diferentes solicitudes?

Existe un grupo de reglas administradas de ATP que contiene reglas para bloquear, etiquetar y administrar solicitudes que pueden formar parte de intentos malintencionados de apropiación de cuentas. Todos y cada una de las solicitudes que se realicen a la página de inicio de sesión (ej: “/user_login.html”) se evalúan utilizando un grupo de reglas mencionadas posteriormente, para luego ser etiquetadas con el prefijo de la regla que coincide.

  • awswaf:managed:aws:atp: — La evaluación de reglas y grupo de reglas de ATP genera etiquetas con este prefijo de namespace.
  • awswaf:managed:token: — Estas etiquetas las genera el servicio de validación de tokens, que el grupo de reglas utiliza para validar a los usuarios.

Las reglas administradas de ATP proporcionan las mejores capacidades de detección cuando se combinan con los SDK de integración de aplicaciones cliente de AWS WAF. En la siguiente lista, se enmueran las diferentes reglas a evaluar:

  • VolumetricIpHigh: cuando hay gran volumen de intentos de inicio de sesión desde la misma IP y las clasificamos como alto, medio o bajo.
    • awswaf:managed:aws:atp:aggregate:volumetric:ip:high
    • awswaf:managed:aws:atp:aggregate:volumetric:ip:medium
    • awswaf:managed:aws:atp:aggregate:volumetric:ip:low
  • VolumetricSession: cuando hay gran cantidad de solicitudes procedentes de la misma sesión individual. E
    • awswaf:managed:aws:atp:aggregate:volumetric:session
  • AttributeCompromisedCredentials: cuando la sesión tiene un alto uso de credenciales de compromiso, si se tiene mas de una se agrega la etiqueta.
    • awswaf:managed:aws:atp:aggregate:attribute:compromised_credentials
  • AttributeUsernameTraversal: cuando tenemos muchos intentos de usuario con la misma contraseña.
    • awswaf:managed:aws:atp:aggregate:attribute:username_traversal
  • AttributePasswordTraversal: cuando tenemos muchos intentos de contraseñas para un mismo usuario.
    • awswaf:managed:aws:atp:aggregate:attribute:password_traversal
  • AttributeLongSession: cuando tenemos una sesión que ha estado activa durante un largo periodo de tiempo (horas).
    • awswaf:managed:aws:atp:aggregate:attribute:long_session
  • TokenRejected: cuando el desafío de Javascript para el token de autenticación no tuvo éxito, esto puede deberse a cosas como expiración, no hubo respuesta o que se generó algún tipo de manipulación sobre este.
    • awswaf:managed:token:rejected
  • SignalMissingCredential: cuando se realizan solicitudes a la página de inicio de sesión sin credenciales en ella.
    • awswaf:managed:aws:atp:signal:missing_credential

Se recomienda realizar la configuración en un ambiente de prueba para monitorear las reglas habilitadas, esto con el fin de tener visibilidad y validar el comportamiento de estas. Al activar las reglas en ambientes productivos, puedes utilizar la regla en “Count” o conteo que te permite tener visibilidad de cuando la regla coincide con lo que se está inspeccionando, esto para evitar generar algún tipo de falsos-positivos. Pueden utilizar la opción de “Set all rule actions to count”, el cual te habilita todas las reglas en modo de conteo.

¿Cuál es el costo de Account Takeover Prevention y cómo ser eficiente en su uso?

El Account Takeover Prevention tiene un costo de suscripción de $10.00 por mes y de $1.00 por mil intentos de acceso analizados. Se puede utilizar el Scope-down Statement, el cual permite condicionar la solicitud sea o no analizada; obteniendo el beneficio de no generar costos adicionales. Para habilitar esta opción, a la hora de configurar la regla de ATP, aplicar el “Enable scope-down statement” donde te permite utilizar el editor de regla visual o “Rule visual editor”, adicionalmente esta el “Rule JSON editor” para configurarla a nivel de código. En este ejemplo, utiliza el editor de regla visual y seleccionada entre las diferentes condiciones para generar una regla:

  • match the statement
  • matches all the statements (AND)
  • matches at least one of the statements (OR)
  • doesn’t match the statement (NOT)

En este ejemplo, se configuró la regla que no coincide con la sentencia mencionada. Se inspecciona los headers (encabezados) y se busca a “ATPHeader” en la solicitud, se valida que coincide exactamente con la cadena “NoInspection” y no hay transformación de texto. Esto hace que se analicen todas las solicitudes excepto cuando se tiene un Header ATPHeader = NoInspection
Se guardan los cambios realizados dando click en el botón de “Save rule”, recibirás una notificación que los cambios hechos han sido realizados satisfactoriamente, como se muestran en la imagen a continuación.

Dar clic al botón de “Add Rules” (Agregar Regla) y en la siguiente ventana se nos presenta la opción de escoger el orden de reglas a inspeccionar de primero (up) a último (down). Es recomendado dejar la regla de ATP entre las últimas de inspección, puesto que permite aplicar según el orden de las reglas, los filtros adecuados para detectar anomalías en las solicitudes; como lo son Rate Based o Reputation. Esas reglas serán utilizadas y bloquearán las peticiones antes de ser inspeccionadas por el ATP, minimizando los costos. Una vez seleccionadas las reglas, guardamos los cambios dando clic al botón de «Save».

Cuando se hace la integración opcional de JavaScript y SDK de IOS/Android, AWS incorporó el manejo de sesiones con estado (Stateful Sessions). Esta funcionalidad ayuda a recolectar telemetría del usuario cuando interactúa con el sitio o app web, permitiendo tener puntos de datos sobre solicitudes históricas para tomar una mejor una decisión a la hora de etiquetar o bloquear la solicitud.

Una vez configurada y guardada la regla de ATP, es necesario que se realice la integración con la aplicación del cliente, utilizando el Javascript SDK o Mobile SDK para poder clasificar la solicitud en base a las reglas habilitadas anteriormente. Para realizarlo, ir al menú del servicio de AWS WAF y seleccionar la opción de “Application integration SDK”. Se enlistan los diferentes endpoints que se configuraron para la protección de ATP; al seleccionar este mostrará el “Integration URL”. La URL de integración te permite integrar la aplicación con el Web ACL, incorporando el código del Javascript SDK a nivel de HTML. Para más información, revisar el siguiente link donde se presenta un ejemplo.

Finalizada la integración con el SDK, tendrás tu página de inicio de sesión protegido con el AWS WAF Account Takeover Prevention. Una vez implementado, es importante monitorear desde AWS CloudWatch las etiquetas de las solicitudes a la regla de ATP configuradas, esto da visibilidad sobre posibles falsos-positivos o verdaderos-positivos. Para validarlo, buscar el servicio de AWS CloudWatch. En el listado de la izquierda, seleccionar “All Metrics” y luego hacer una búsqueda por WAF como se ve en la siguiente imagen:

Seleccionar de la lista las reglas del ATP, visualizando únicamente estas métricas en el dashboard. Es conveniente entender el patrón de tráfico que se espera en el endpoint y crear alarmas, permitiendo al equipo de seguridad ser notificado si hay algún evento de crecimiento en solicitudes de alguna regla activa. También es valioso generar un dashboard que te permita tener visualización de las métricas de forma rápida, sin tener que hacer filtros. Información de como crear un dashboard en el siguiente link.

Conclusión

En esta entrada de blog, presenté los pasos para configurar una regla de ATP desde la consola de AWS. Esta regla agrega una capa adicional de protección para la prevención de ataques de relleno de credenciales, intentos de fuerza bruta y otras actividades de inicio de sesión anómalas. La integración del JavaScript SDK permitirá tener más información del comportamiento de la sesión, siendo más efectivo al ATP etiquetar la solicitud de acuerdo a las reglas habilitadas. Para finalizar, se recomienda estar revisando por falsos-positivos cuando haya cambios a nivel aplicativo o de códigos que pueden impactar el comportamiento de la solicitud.

Sobre el autor

Mario Navarro es Sr. Technical Account Manager en AWS Costa Rica.