Una inmersión más profunda en el incidente de seguridad de mayo de 2019: comentarios de la publicación del blog
Acabamos de publicar una actualización del incidente de seguridad que sucedió en mayo de 2019 con detalles técnicos de lo que sucedió, cómo sucedió y las soluciones que aplicamos para evitar que un incidente como este vuelva a suceder. Aquí hay un par de extractos de la publicación, primero de la introducción:
El 12 de mayo de 2019, alrededor de las 00:00 UTC, varios miembros de la comunidad nos alertaron sobre una escalada inesperada de privilegios para una nueva cuenta de usuario. Un usuario que nadie reconoció había obtenido acceso a nivel de moderador y desarrollador en todos los sitios de la red Stack Exchange. Nuestra respuesta inmediata fue revocar privilegios y suspender esta cuenta y luego poner en marcha un proceso para identificar y auditar las acciones que llevaron al evento.
Después del descubrimiento inicial, descubrimos que la escalada de privilegios era solo la punta del iceberg y que el ataque había dado como resultado la exfiltración de nuestro código fuente y la exposición inadvertida de la PII (correo electrónico, nombre real, direcciones IP) de 184 usuarios. de la red Stack Exchange (todos los cuales fueron notificados). Afortunadamente, ninguna de las bases de datos, ni pública (léase: contenido de Stack Exchange) ni privada (Teams, Talent o Enterprise), se extrajo. Además, no ha habido evidencia de ningún acceso directo a nuestra infraestructura de red interna, y en ningún momento el atacante tuvo acceso a los datos de los productos Teams, Talent o Enterprise.
Y del último párrafo:
Este incidente nos recordó algunas prácticas de seguridad fundamentales que todos deberían seguir:
- Registre todo su tráfico entrante. Mantenemos registros de todas las conexiones entrantes. Esto permitió todas nuestras investigaciones. No puede investigar lo que no registra.
- Utilice 2FA. Ese sistema restante que todavía usa autenticación heredada puede ser su mayor vulnerabilidad.
- Guarda mejor los secretos. TeamCity tiene una forma de proteger los secretos, pero descubrimos que no la usábamos de manera constante. Eduque a los ingenieros que "los secretos no son solo contraseñas". Proteja las claves SSH y las cadenas de conexión de la base de datos también. En caso de duda, protéjalo. Si debe almacenar secretos en un repositorio de Git, protéjalos con git-crypt o Blackbox .
- Validar las solicitudes de los clientes. Cuanto más inusual sea una solicitud de un cliente, más importante es verificar si la solicitud es legítima o no.
- Tómate los informes de seguridad en serio. Estamos agradecidos de que nuestra comunidad haya informado sobre actividades sospechosas con tanta rapidez. ¡Gracias!
Hay mucho más en la publicación del blog; no dude en hacer cualquier pregunta o comentario relacionado con la publicación a continuación y haremos todo lo posible para responderlos. No podemos comentar sobre ningún otro detalle relacionado con el ataque más allá de lo que se incluye en la publicación del blog, debido a las investigaciones en curso.
Respuestas
¿Puede hacer algún comentario sobre las intenciones de los atacantes?
¿Parece que buscaban un objetivo determinado / determinados datos (del usuario)?
¿O quizás era más un "adolescente curioso" que empujaba con palos para ver qué tan lejos podían llegar?
PD gracias por la franqueza con respecto a este asunto, ¡se lo agradezco mucho!
Esta línea:
Este acto de buscar cosas (preguntas de visita) en la red de Stack Exchange se convierte en una ocurrencia frecuente y nos permite anticipar y comprender la metodología del atacante en los próximos días. (énfasis mío)
hace que suene como en tiempo real , mientras se producía el ataque, se podía señalar con precisión lo que haría el atacante en función de lo que visitó en Stack Overflow, en lugar de lo que hizo mediante la observación forense de lo que vio (después del ataque). ¿A cuál te refieres?
Varias preguntas relacionadas principalmente con el atacante:
- ¿Qué pasó con el atacante?
- ¿Suspendiste su cuenta?
- ¿SE contactó con el atacante en algún momento?
- ¿Por qué no expone la identidad del atacante?
- ¿Alguien más ha intentado utilizar este mismo método de ataque más tarde?
¿Hubo un ciclo de sueño detectable en el otro extremo de los eventos?
Edite para aclarar:
Después de darse cuenta del atacante, y dado que siguió algunas de sus acciones a medida que se desarrollaban, ¿notó algo parecido a un ciclo biológico, tanto en el día a día como en retrospectiva? Ej .: ¿Comer (descansos de 1 a 2 horas), dormir (patrón de inactividad de 8 horas), "siestas energéticas" (90 minutos), etc ...?
Esto no es realmente parte del incidente, sino una preocupación más general sobre las medidas de seguridad en las cuentas de los empleados. Hubo muchos pasos en este incidente, pero el último fue aumentar los privilegios de una cuenta SE. Puedo imaginar formas mucho más sencillas de intentar esto que obtener acceso de administrador al servidor de CI a través de la instancia de desarrollo para ejecutar SQL en producción, y estoy interesado en qué mitigaciones y prácticas de seguridad ha implementado SE para defenderse de intentos más simples de ganar acceso a una cuenta de empleado.
Obviamente, no puede colocar los sitios principales de SE detrás del firewall, por lo que siempre estarán expuestos. Y el método de inicio de sesión interno de SE no proporciona ningún método 2FA, lo que me parece algo preocupante.
- ¿Las cuentas de los empleados están protegidas por 2FA por otros medios (u otros proveedores de inicio de sesión)?
- ¿Existe alguna medida para garantizar que no se adjunten direcciones de correo electrónico privadas o proveedores de inicio de sesión a las cuentas de los empleados que podrían ser menos seguras y seguir utilizándose para recibir correos de recuperación para obtener acceso a la cuenta?
- ¿Se supervisan los intentos de inicio de sesión de nuevas fuentes para las cuentas de los empleados?
- ¿Existen protecciones adicionales para las herramientas peligrosas de los empleados en caso de que alguien obtenga acceso a una sesión en ejecución de una cuenta de empleado (p. ej., requiera contraseña y / o token 2FA nuevamente al acceder a herramientas críticas para la seguridad)
Algo como el spear phishing es probablemente una de las formas más probables en que alguien podría intentar obtener acceso a la cuenta de un empleado.
Aproximadamente al mismo tiempo que sucedió este incidente de seguridad, unos días después, algunos usuarios comenzaron a notar que Twitter oneboxing en el chat ya no funcionaba . Posteriormente, un empleado confirmó en febrero del próximo año que efectivamente había sido discapacitado intencionalmente debido a tener que "cerrar algunas brechas" como resultado de este incidente de seguridad.
¿Podemos obtener una explicación completa de por qué el oneboxing de Twitter en el chat tuvo que desactivarse como resultado de este incidente de seguridad? La publicación del blog publicada en ese momento indicaba que "otros vectores potenciales" se habían cerrado en ese momento, y el mensaje del personal de febrero de 2020 que vinculé anteriormente indicaba que la función oneboxing de Twitter "hizo uso de una de las brechas que cerramos". ¿Qué era esa cosa y qué riesgo de seguridad creó?
Finalmente, ¿hay alguna forma de que esta funcionalidad se pueda implementar nuevamente, de manera segura? En agosto de 2020, unos meses después del mensaje del personal anterior, otro empleado marcó el informe de error presentado en ese momento por estado por diseño . ¿Se consideraría una solicitud de función para volver a cambiar el diseño (de manera segura), o es imposible hacerlo sin abrir un vector de ataque?
Señalaría que los tipos de parámetros de "contraseña" en TeamCity no se consideran tan seguros:
El valor de la contraseña se almacena en los archivos de configuración en TeamCity Data Directory. Según la configuración de cifrado del servidor, el valor se codifica o se cifra con una clave personalizada.
El valor del registro de compilación se oculta con un algoritmo simple de búsqueda y reemplazo, por lo que si tiene una contraseña trivial de "123", se reemplazarán todas las apariciones de "123", lo que podría exponer la contraseña. Establecer el parámetro en el tipo de contraseña no garantiza que no se pueda recuperar el valor sin procesar. Cualquier administrador de proyecto puede recuperarlo, y cualquier desarrollador que pueda cambiar el script de compilación podría potencialmente escribir código malicioso para obtener la contraseña.
¿Por qué el enlace mágico en dev era visible para los CM (presumiblemente solo en dev) un enlace mágico real?
¡Este es realmente un informe de incidente increíble! Uno de los mejores que he leído.
¡Gracias Stack por hacerlo público y Dean por un excelente escrito!
Solo tengo curiosidad por saber algunas cosas:
- ¿Cuál es el tamaño del equipo de respuesta a incidentes?
- ¿Se siguieron protocolos específicos durante la investigación?
- ¿Qué factor clave estuvo involucrado para involucrar al proveedor de seguridad externo? ¿Cuáles fueron los puntos que se consideraron al elegir ese proveedor en particular?
- ¿Qué lecciones se aprendieron del proveedor de seguridad externo? ¿Su proceso de auditoría fue diferente (efectivo / ineficaz) del que ya usaba el equipo?
El artículo da una buena idea de toda la arquitectura de Stack y los procesos de desarrollo. Una lectura más detallada o un enlace si ya hay un artículo al respecto sería genial.
En "Consejos para otros":
Registre todo su tráfico entrante. Mantenemos registros de todas las conexiones entrantes. Esto permitió todas nuestras investigaciones. No puede investigar lo que no registra.
¿Cómo puede una red tan ocupada como Stack Exchange registrar todo el tráfico entrante? ¿Son estos registros entradas del servidor web, flujos IP o sesiones TCP completas?
Podría registrar la mayoría de las entradas y los intentos de conexión en mi pequeña red, pero no tengo idea de cómo lo hace una red tan grande.
¿Puede explicar más claramente qué significa "propiedades de acceso público" en la cita a continuación?
tenemos una base de datos que contiene un registro de todo el tráfico a nuestras propiedades de acceso público