Tres señales de un ataque a una aplicación que los desarrolladores deben conocer

Las aplicaciones están bajo asedio. Los ataques ocurren con una frecuencia alarmante (cada 39 segundos según una investigación realizada por la Universidad de Maryland ) y con una probabilidad de éxito inquietantemente alta.

Los desarrolladores, que cada vez asumen más la carga de proteger estas aplicaciones, son muy conscientes de la amenaza. Una encuesta realizada a finales de 2017 a desarrolladores de node.js por NodeSource y Sqreen descubrió que “más de un tercio de todos los encuestados (34 por ciento) creen que existe una gran posibilidad de que su organización sea el objetivo de un ataque a gran escala en los próximos seis meses”. Dados nuestros propios hallazgos de que el vector de ataque inicial en el 86% de los ataques es la propia aplicação o las identidades, esa creencia es más que razonable.

Puede resultar inquietante descubrir que “el 35% de los encuestados no estaba seguro de cómo identificar un ataque mientras estaba ocurriendo”. Esperan uno, pero no están seguros de cómo reconocerlo cuando llega. Si no estás seguro de cómo identificar un ataque en curso, es extremadamente difícil detenerlo.

Eso hace que el 23% de desarrolladores de Node.js (23 por ciento) que no utilizan ningún tipo de protección en tiempo real contra ataques sea aún más preocupante.

La buena noticia es que, según nuestra propia investigación sobre el estado de la entrega de aplicação 2018,  La mayoría de las organizaciones utilizan algún tipo de protección en tiempo real contra ataques. Cuatro de cada cinco utilizan dos o más tecnologías, entre ellas, firewall de aplicação web (57%), autoprotección de aplicação en tiempo de ejecución (11%) y análisis del comportamiento del usuario (26%).

La característica que todas estas tecnologías tienen en común es aquello que a menudo les falta a los desarrolladores: visibilidad. La visibilidad es necesaria porque para detectar (y con suerte identificar) un ataque, es necesario poder reconocer un comportamiento anormal.

Las aplicações y sus servicios tienen patrones de uso bastante predecibles. Por ejemplo, las aplicações de inicio de sesión único (SSO) tienden a tener un uso intensivo los lunes por la mañana y un uso ligero los viernes por la tarde. Las aplicações financieras tienden a usarse intensamente justo antes de los eventos financieros (días de pago, finales de períodos impositivos y cierres de años fiscales).

Incluso las aplicações dirigidas al consumidor tienen patrones de uso predecibles que pueden usarse para ayudar a detectar comportamientos inusuales (y potencialmente peligrosos). Por ejemplo, en abril de 2017, Malauzai Software publicó uno de sus informes mensuales de "datos pequeños" basados en datos de uso recopilados de más de "435 bancos y cooperativas de crédito, que abarcan 13,2 millones de inicios de sesión de 730 000 usuarios activos de banca por Internet y móvil". En él, aprendemos que “el 100% de los usuarios finales ven sus saldos y revisan el historial de transacciones recientes. Esto se debe a que los saldos y el historial reciente se muestran en la página de destino para que todos puedan verlos. Y es por esto que vienen. 77% del tiempo. El 77% del tiempo lo único que hace un usuario es consultar saldos e historial. Solo el 23% de las interacciones totales en la banca digital van más allá de los saldos y el historial para realizar alguna otra tarea”.

Se podría inferir, entonces, que un interés repentino en otros tipos de transacciones podría ser indicativo de un ataque.

Desafortunadamente, estas estadísticas no siempre están disponibles para todas las aplicação. Por eso es importante la visibilidad (monitoreo), para poder establecer una línea base a partir de la cual las anomalías se vuelven obvias. No todas las anomalías son indicativas de un ataque, por supuesto. Un aumento repentino en el uso del servicio SSO a mitad de semana podría deberse a una fecha límite para cambiar las contraseñas corporativas o porque el lunes y el martes fueron feriados y no había nadie en la oficina. Aun así, tener una línea de base te da una ventaja para identificar el comportamiento que puede indicarte que un ataque está en curso.

Asegúrese de verificar estos tres patrones de uso anormales en caso de que, de hecho, sean un ataque. Porque muy a menudo, lo son.

1. Aumento dramático en las conexiones. Quizás te hayas vuelto viral, pero es probable que esté sucediendo algo más. Cuando observe un aumento significativo en las tasas de conexión, es una buena idea verificar inmediatamente si hay un aumento correspondiente en el tráfico de la red. De lo contrario, tus sentidos arácnidos deberían estar alerta porque se trata de un ataque potencial. Las inundaciones GET son los ataques DDoS basados ​​en HTTP más fáciles de perpetuar, porque se basan simplemente en rociar una tonelada métrica de HTTP GET a una aplicação y nada más. A menudo ni siquiera intentan acceder a URL reales, porque el objetivo es simplemente consumir tantas conexiones como sea posible y forzarlo a una situación de sobrecarga.

Si el aumento apunta específicamente a URL o servicios que proporcionan inicios de sesión, usted podría ser víctima de un ataque de fuerza bruta para obtener acceso. 

Busque errores del servidor, un rendimiento cada vez más degradado y agotamiento de recursos como señales de un ataque en curso.

2. Tamaño de la respuesta saliente. Una respuesta saliente repentinamente grande puede indicar un ataque de exfiltración exitoso en el que el atacante obtuvo acceso a datos que no debería tener. Esta es una de las principales señales de alerta de un ataque SQLi exitoso, ya que los atacantes a menudo utilizan comodines para obtener acceso no autorizado a los datos. Uno podría pensar que SQLi es un vector de ataque tan bien comprendido que a esta altura ya lo tendríamos cubierto. Pero SQLi figura sistemáticamente entre los ataques más exitosos cada año en varios informes de la industria.

Básicamente, el ataque está diseñado para eludir las restricciones de acceso a los datos. Entonces, en lugar de recibir un solo registro (o incluso unos pocos), el ataque podría recibir miles . Un ataque exitoso será entonces notorio porque la cantidad de datos devueltos será significativamente mayor que lo normal.

Cualquier diferencia significativa en el tamaño de la respuesta debería ser suficiente para justificar una investigación inmediata.

3. Se bloquea y falla. Si bien esto se puede explicar por defectos o entradas "malas" accidentales, también pueden ser indicativos de intentos de saturar los buffers en bibliotecas de terceros o plataformas de servidores web (o su aplicação) con la esperanza de explotar una vulnerabilidad nueva (o antigua). Si bien es bueno que los sistemas puedan simplemente "reiniciarse" hoy, no es bueno ignorar el motivo por el cual necesitaron reiniciarse .

Si bien puede resultar tentador ignorar los accidentes ocasionales, no lo hagas.

No ignore los fallos y las fallas y considere arquitecturas que le permitan poner en cuarentena los sistemas defectuosos hasta que pueda revisarlos.

Obviamente, esta no es una lista completa, pero es un buen comienzo para poder identificar cuándo una aplicação podría estar bajo ataque y detenerlo de inmediato.

¡Mantenerse seguro!