Company
Defensa activa de Mailgun contra Log4j
El 10 de diciembre de 2021, el mundo se vio sacudido por una enorme vulnerabilidad que dejó a millones de profesionales de TI y seguridad en apuros. La vulnerabilidad, denominada Log4Shell, dejó a los activos expuestos a un exploit (ridículamente) sencillo que provocaba la ejecución de código remoto (RCE). Este artículo del blog no es un texto técnico sobre la vulnerabilidad en sí; para ello existen recursos excelentes a una simple búsqueda en Google. En su lugar, queremos compartir cómo Mailgun trató la vulnerabilidad como un incidente inmediato y pasó a un modelo de defensa activa pocas horas después de reconocer nuestra propia exposición…
Identificación
En cuanto reconocimos el impacto de esta vulnerabilidad, movilizamos a nuestro equipo interno de respuesta a incidentes (IR). Por lo general, gestionamos las nuevas vulnerabilidades a través de nuestro proceso estándar de gestión, que habría solucionado las vulnerabilidades y exposiciones comunes (CVE) de nivel alto en siete días, y las vulnerabilidades críticas en 48 horas. Sin embargo, ¡no se trataba de una vulnerabilidad “normal”!
Dos horas después de la notificación, nuestro equipo de IR había revisado nuestro inventario de activos y la lista de materiales de software. Descubrimos que ningún activo público de Mailgun se había visto afectado por esta vulnerabilidad. Sin embargo, había varios activos internos que sí presentaban algunos aspectos del software afectado. Algunos de estos activos estaban protegidos gracias al uso de Java Security Manager.
Otro componente que suele pasarse por alto en la respuesta a una vulnerabilidad tan crítica es entender tu exposición ante terceros. Durante nuestra fase inicial de identificación, nuestro equipo de cumplimiento inició una revisión de proveedores. Ponerte en contacto con todos tus proveedores no es un proceso sencillo, pero resulta fundamental para comprender si es necesario limitar el acceso a los datos a algunos de esos terceros.
Tras esta revisión inicial, el equipo de respuesta a incidentes pasó a una fase de remediación y defensa activa.
Remediación
De nuevo, pocas horas después de comprender nuestra exposición, los equipos de ingeniería de Mailgun habían implementado los primeros parches para esta vulnerabilidad. Debido a la naturaleza crítica de algunos de estos activos, tuvimos que seguir un proceso de parcheo estándar, pasando primero por nuestros entornos de desarrollo y preproducción. Sin embargo, vale la pena señalar lo críticos que son esos entornos. Muchos programas de gestión de vulnerabilidades pasan por alto estos entornos “no críticos” en su intento de lograr una postura ágil. A los atacantes no les importa: ¡seguirán comprometiendo esos entornos y abusando de ellos para hacerte daño!
Por desgracia, en el transcurso de los días siguientes, se liberaron más CVE y exploits en todo el mundo, y tuvimos que reevaluar nuestros activos continuamente e implementar nuevos parches o mitigaciones. No obstante, nuestros equipos de ingeniería estuvieron a la altura del desafío y continuaron parcheando y revisando los informes durante los días siguientes.
Una vez iniciado el esfuerzo de parcheo y con nuestros equipos de ingeniería involucrados, el equipo de seguridad pasó a la defensa activa.
Defensa activa
La siguiente fase importante para combatir una CVE tan crítica es participar en la defensa activa. Consideramos que la defensa activa consta de algunos elementos: prevenciones, detecciones y honeypots. Por suerte, el firewall de aplicaciones web (WAF) que eligió Mailgun empezó a implementar detecciones para este exploit desde el primer día. Sin embargo, cualquier profesional de la seguridad que se precie reconocerá que esto no es, ni fue, suficiente. Mantener el ritmo de la cantidad de permutaciones contra esta vulnerabilidad se volvió casi imposible…
Aquí es donde un buen registro y la redacción de una lógica de detección sólida se vuelven fundamentales en un incidente. Mailgun invierte mucho en el registro de las solicitudes enviadas a nuestra infraestructura, y pudimos ver hasta qué punto esta vulnerabilidad se convirtió en un objetivo. De la noche a la mañana, vimos que la cadena `${` se disparaba en nuestros registros debido a los intentos de explotar esta vulnerabilidad. Debido a la magnitud del ataque, reconocimos que el bloqueo básico de IP no funcionaría. Junto con la permutación de ataques y el aluvión de nuevas CVE, nos dimos cuenta de que debíamos centrar nuestros esfuerzos en mitigar por completo esta vía de ataque e implementar formas de reducir el ruido. Pasemos a los honeypots…
La siguiente etapa en una defensa activa madura es la implementación de honeypots. La comunidad de seguridad en general estuvo a la altura de las circunstancias. A los pocos días del informe de la vulnerabilidad, se publicaron numerosos honeypots que podían implementarse en cuestión de minutos. Tras realizar la debida diligencia con varios de ellos, optamos por implementar un pequeño script de monitorización en bash que podía convertir un servidor en un honeypot de escucha. Al implementarlo en nuestras redes internas y abrirlo a casi todos los servidores (entrantes) del entorno, podríamos reconocer muy rápido si un actor malintencionado estaba operando dentro de nuestras redes privadas.
Resumen
En Mailgun, adoptamos la mentalidad de “cuándo pasará, no si pasará”. Reconocemos que, con esta vulnerabilidad en particular, tuvimos suerte de no tener ningún activo externo expuesto o activos que se hubieran visto comprometidos a través de este exploit sin acceso interno. Puede que mañana no tengamos tanta suerte. Pero podemos seguir preparándonos y trabajando para crear sistemas más seguros y mejores capacidades.
