¡Hola! Recientemente, con RBK.money Processing participamos activamente en el polígono cibernético The Standoff : aquí es cuando hacen un modelo virtual de una metrópolis completa con toda su infraestructura, plantas de energía, tiendas y otros elementos importantes. Y luego dejaron que el equipo azul (6 equipos este año) y el equipo rojo (29 equipos este año, respectivamente) ingresen en este gemelo digital de la ciudad, el primero protege toda esta infraestructura, el segundo está tratando activamente de romper algo.
de la película “Blade Runner 2049”
Por supuesto, llevamos nuestro procesamiento al evento, sobre el cual puedes leer en las publicaciones anteriores de nuestro blog. El procesamiento era parte del bancoy brindó servicios financieros y de pago a los residentes de la ciberciudad, atendió la emisión de tarjetas de pago y posibilitó la venta de bienes y servicios.
En esta publicación, quiero contarles cómo los piratas informáticos nos rompieron (alerta de spoiler: y no lo hicieron), así como cómo nosotros mismos nos disparamos en el pie un par de veces en el proceso de preparación e implementación de nuestra solución. Y sí, lo principal es que para nosotros inicialmente fue una situación de ganar-ganar: no nos van a romper, lo que quiere decir que no es por nada que tengamos tanta confianza en nuestro procesamiento que lo ponemos en código abierto y ahora se lo estamos dando a los hackers. Lo romperán, generalmente genial, veremos dónde estaban las debilidades y estaremos aún más protegidos en términos de seguridad para nuestros clientes.
Nos infiltramos en la ciudad cibernética con prisa tangible: esta es una de nuestras primeras implementaciones en Kubernetes (antes de eso, implementamos todo con los estados Salt), y tuvimos que usar nuevos enfoques de instalación. Y las consecuencias de esta prisa no se hicieron esperar.
Consejos para hackers
Incluso antes de la expansión del procesamiento a una ciudad cibernética, dejamos deliberadamente dos puntos débiles allí.
La primera es una vulnerabilidad asociada con los métodos de tokenización de tarjetas. Estos métodos eran susceptibles a vulnerabilidades en forma de ataques de repetición, es decir, la tarjeta podía tokenizarse con éxito en una tienda, y luego, con este token, pasaba a otra y se reutilizaba allí. Tímidamente esperábamos que se encontrara la vulnerabilidad, pero lamentablemente.
El segundo es una simple contabilidad del comerciante principal. Creamos solo un comerciante oligarca, era una entidad legal que poseía tiendas en línea en la ciudad cibernética. Y esta bolsa de dinero tenía credenciales bastante simples, es decir, una contraseña como Parolec0, en principio, podría haber sido magullada . Pero tampoco despegó.
Pero surgieron nuestras propias jambas.
De prisa, no puedes proteger todo
Un lector atento concluirá desde el punto sobre el comerciante principal: espere un minuto, tiene un único oligarca que posee todas las tiendas en línea, basta con piratear una de esas tiendas en línea y puede acceder al resto. Bueno, sí, no pensaron en este momento apresuradamente ...
Y de hecho, después de hackear a este comerciante, fue posible obtener su clave API para nuestro procesamiento y administrar completamente este procesamiento. En realidad, esto es lo que sucedió: los atacantes piratearon una solución de terceros, una tienda de entretenimiento en línea en la ciudad, obtuvieron la clave API de nuestro comerciante de allí, la acompañaron a nuestro procesamiento y llamaron a un método que le permite encender / apagar su tienda en línea. Y dado que una entidad legal era propietaria de todos los puntos de venta de la ciudad, todos se apagaron.
En principio, esto es correcto, si eres un oligarca fuerte y codicioso que se ha apoderado de todo para sí mismo, sufre. Sacamos conclusiones y decidimos despojarnos rápidamente de la bolsa de dinero mediante la creación de 5 entidades legales más independientes, y para cada "inicio de sesión-contraseña" y pares de claves API separados. Creo que en los próximos concursos de este tipo intentaremos acercar aún más la situación a la realidad en la parte empresarial.
Y también “pasó volando” debido a las peculiaridades del Kuber.
En Kubernetes, el repositorio principal para el estado del clúster es ETCD , un sistema distribuido útil en el que puede construir cosas muy, muy confiables. Pero es demasiado crítico con la latencia de los discos duros.
Como escribí, implementamos el procesamiento en un entorno virtual de ciudad cibernética. Hubo ataques bastante activos a los objetos adyacentes a nosotros, y una vez que uno de esos objetos “ruidosos” fue trasladado a nuestro almacén de datos, la infraestructura de uno de los participantes, que estuvo rota durante mucho tiempo y de manera persistente. Y aunque de facto no éramos un objetivo en este caso y en ese momento nadie rompió el procesamiento, continuó funcionando normalmente, pero el clúster en sí comenzó a desacelerarse enormemente, los duros simplemente no pudieron hacer frente (lograron notar que la salida del comando ls -l tomó alrededor de 19 segundos). Resultó que salió una especie de DoS, y en una noche enviamos a nuestros gatos estándar a todas las solicitudes.
Luego de esta situación, los organizadores de The Standoff nos trasladaron a otros discos, es decir, apagaron una máquina virtual y encendieron otra, en una ubicación diferente. Después de eso, nuestro DBMS distribuido atrapó felizmente un cerebro dividido, la mitad de los nodos contenían una información, la mitad, otra, y realmente no podían estar de acuerdo con ellos mismos. En la batalla, por supuesto, nos habríamos confundido más con la migración y no habríamos permitido que esto sucediera. Y en un entorno de prueba, fue mucho más fácil simplemente golpear todo lo que estaba disponible y reinstalarlo, lo cual hicimos, gastando, por cierto, 2 horas. Por qué enfatizo esto, porque implementamos un flujo de trabajo completo con todos los componentes en dos horas, y usted puede hacer esto con nuestro procesamiento en batalla en su empresa. El procesamiento clásico se suele implementar en empresas de 3 meses.
Entonces, sobre el cerebro dividido, todo es una prisa. Simplemente eliminamos / tmp en uno de los nodos debajo de la raíz . Quién sabía que el módulo CSI LVM , que distribuye volúmenes locales desde el hardware a los pods, monta secretamente (!) Un volumen Kuber persistente en / tmp . Así, resultó que con nuestras propias manos demolíamos los datos bajo los pies del DBMS que giraba sobre él. Además, a pesar de que demolimos el almacenamiento de algunos de los nodos en los clústeres base, todo siguió funcionando para nosotros hasta el primer reinicio de la máquina virtual, que sucedió cuando comenzaron a trasladarnos a nuevos lados.
El equipo azul está apagando lentamente sus defensas ...
Un día, el equipo azul decidió desactivar la protección externa (firewall, etc.). Es decir, los primeros días, los piratas informáticos intentaron romper los sistemas con este tipo de protección habilitada y luego, sin ella. También teníamos un WAF de terceros, que en el ingreso con njinks como módulo se cargó y protegió nuestro tráfico.
Y luego llegó el día, fuimos a apagar WAF y nos dimos cuenta de que ya estaba apagado. Hace dos días. Como somos geniales y tenemos prisa (sí, sí), estábamos configurando kubernetes de entrada, que tenían una instancia WAF. Y todo estaría bien, pero WAF simplemente no llegó al servidor de control, no pudo descargar el archivo de licencia de él, se encogió de hombros y simplemente se apartó del pecado. Y resulta que todos estos dos días que “Rompemos con la protección incluida” estuvimos sentados, de hecho, sin esta protección.
Pero aún así no estábamos rotos.
Otra confirmación de la tesis de que apurarse es perjudicial (si no tienes suficiente de los anteriores): la situación con nuestro antifraude Lo describí en publicaciones de blog anteriores , hay una caja mágica con un conjunto de reglas. Antifraude protege contra la rotura de tarjetas bancarias, intentos de pagar en un momento desde diferentes ubicaciones / IP / correo electrónico y otras acciones hostiles. Le dijimos al equipo de defensa que nosotros mismos estableceríamos cuidadosamente todas estas reglas. Y lo hicimos: configuramos cuidadosamente todas las reglas antifraude. En nuestro servidor de producción RBK.money en lugar de instalarlo para The Standoff. Las URL de la interfaz de usuario en la barra de direcciones del navegador son cursis. Es decir, el antifraude en este momento era una caja con un misterioso vacío silencioso. Este se convirtió en uno de los vectores exitosos para los editores:
Por ejemplo, anteriormente habían pirateado un banco de Internet de terceros al robar el código PAN de la tarjeta (los números en sí, el número de cuenta principal), el nombre del titular de la tarjeta y la fecha de validez. Después de eso, ya en nuestro procesamiento en este PAN, comenzaron a clasificar los CVV. Y todo estaría bien, después de 3 intentos de romper las cartas, serían bloqueadas por nuestro antifraude. Si tan solo ... ver arriba.
En general, hubo muchas historias divertidas. En algún momento, nuestros servicios dejaron de resolverse y la hora en los nodos dejó de estar sincronizada, y de alguna manera al azar, de algunos hosts.
Por supuesto, lo primero que hicieron fue culpar a la mala configuración, al incomprensible trabajo del clúster.
Con DNS, el problema se resolvió rápidamente moviendo los pods de CoreDNS directamente a los nodos donde no se activaba este tráfico, pero con NTP tuvimos suerte; afortunadamente, no detectamos una gran desviación de reloj y, al crear un clúster, los nodos aún lograron sincronizarse.
Resultó que en algún momento a nivel de firewall, las solicitudes salientes de NTP y DNS se deshabilitaron para algunos de los nodos. Al parecer, alguien apretó demasiado las tuercas de filtración.
Otros ataques
Los ataques a otros objetivos de las ciudades cibernéticas cercanas también han tenido éxito en ocasiones, incluidos aquellos, como nosotros, en el sistema financiero de la ciudad cibernética.
Es bueno que no hayamos confundido las URL de alerta por encima del elástico y en la monitorización, y las vimos con bastante precisión y rapidez.
Por ejemplo, como en el caso de piratear a nuestro oligarca y retirar la clave API. Fue pirateado a las 22.17 hora de Moscú. A las 22.22 nosotros de nuestro lado notamos esto e inmediatamente lo informamos a los defensores y organizadores. Por cierto, nos dimos cuenta de que gracias al uso incorrecto de la API (los piratas informáticos pasaron un encabezado de tipo de contenido extraño en la primera solicitud, llamado método raro de nuestra API, y algunos otros matices), esa fue la razón para activar la alerta.
Cuando el sistema funciona con normalidad y de forma automática, rara vez todo coincide al mismo tiempo. Pero si sucede algo así, significa que alguien está jugando con la API con sus manos. Aquí está la alerta y funcionó.
Si no estamos hablando de una ciberciudad, sino de situaciones reales de este tipo, entonces todo sucede aún más rápido, en tales casos el sistema bloquea automáticamente las acciones del comerciante para que no se retire nada de su cuenta y, en principio, no perjudique el trabajo y el negocio de ninguna manera, genera pánico y conecta a los empleados que ya viven
Para el futuro
El formato de piratería de la ciudad cibernética es, no es broma, el futuro de la seguridad de la información. Definitivamente volveremos aquí, tomaremos en cuenta todos los errores y pensaremos en la infraestructura y los esquemas comerciales para que estén lo más cerca posible de la realidad. Idealmente, generalmente quiero que la gente del Banco Central o de los Servicios del Estado lleguen a las mismas conclusiones: probar su infraestructura en la batalla, brindar la oportunidad de encontrar vulnerabilidades y volverse aún mejores y más confiables para los usuarios y las empresas.
Y en realidad fue muy divertido y divertido. De hecho, recibimos un gran conjunto de casos de Chaos Monkey que no necesariamente se reproducirían en producción, probamos el procesamiento para detectar ataques, habiendo recibido más ataques en 2 días de los que recibimos habitualmente en seis meses.
Aprendimos mucho y, lo que es más importante, vimos que nuestro producto, que estamos escribiendo para nosotros y para usted, es popular entre los participantes de la ciudad cibernética, para nuestra TI fue una gran motivación; después de todo, es agradable cuando las personas usan el resultado de su trabajo, incluso si en este caso y para propósitos muy específicos.
Nos gustó mucho y queremos MÁS.
¡En el próximo Standoff, espéranos con esquemas aún más interesantes, más funciones de pago y nuevos vectores de ataque!