Hola a todos! Me llamo Vitaliy Malkin. Soy el jefe del departamento de an谩lisis de seguridad en Informzashchita y el capit谩n a tiempo parcial del equipo True0xA3. Con este art铆culo, comenzamos un ciclo de 3 materiales dedicados a nuestro desempe帽o en PHDays IX Standoff. En este art铆culo, explicaremos por qu茅 la preparaci贸n competente es la mitad del 茅xito, por qu茅 es tan importante recoger las "frutas" a tiempo y c贸mo puede organizar la interacci贸n del equipo anterior en un solo proyecto.
El art铆culo de TL; DR contiene una gran cantidad de ingl茅s y t茅rminos t茅cnicos complejos, por lo cual me disculpo por separado.
I. Entrada
Tuvimos 16 pentesters seleccionados, 4 aprendices, 6 servidores, nuestra propia estaci贸n CUDA y un gran deseo de ganar.
Comenzamos la fase de preparaci贸n activa 8 d铆as antes del inicio de StandOff. Este fue nuestro tercer intento como atacante, y muchos de nosotros ya ten铆amos suficiente experiencia para entender qu茅 buscar este a帽o. Vimos 5 谩reas prioritarias para la elaboraci贸n:
- Coordinaci贸n efectiva;
- Colecci贸n de frutas bajas colgantes;
- Explotaci贸n de vulnerabilidades de tecnolog铆as at铆picas (para nosotros) (ACS TP, IoT, GSM);
- Preparaci贸n de infraestructura y equipos externos;
- Desarrollo agregar. persistencia y m茅todos de endurecimiento.
Intentemos analizar estos elementos en orden.
1. Coordinaci贸n efectiva
Es m谩s f谩cil para m铆 hablar sobre este punto, porque la decisi贸n general fue la responsable de su implementaci贸n. Durante StandOff, el problema m谩s com煤n para los principiantes, en mi opini贸n, es la falta de coordinaci贸n. Los miembros del equipo resuelven las mismas tareas, no hay una comprensi贸n clara de lo que ya se ha visto y lo que no. La informaci贸n recibida sobre la tarea no se transmite entre s铆, como resultado, la eficiencia del trabajo disminuye considerablemente. Y cuantos m谩s participantes, m谩s cae la eficiencia. Adem谩s, es muy 煤til tener una persona que comprenda bien la imagen general de la infraestructura y pueda vincular vulnerabilidades individuales en un vector de ataque completo.
Este a帽o, la plataforma Discord fue elegida para la interacci贸n del equipo. En general, es muy similar al viejo chat IRC con caracter铆sticas adicionales como la carga de archivos y la comunicaci贸n de voz. Tomamos una descripci贸n de todos los objetos de las competencias de Agend y creamos un canal para cada uno de ellos, en el que se public贸 la informaci贸n. Por lo tanto, cualquier persona que se conecte a la tarea podr铆a ver todo lo que se le ocurri贸, incluidos los resultados del lanzamiento de varias herramientas y b煤squedas manuales. En todos los canales de informaci贸n, se estableci贸 un l铆mite de un mensaje por minuto para evitar inundaciones. Y toda la discusi贸n se realiz贸 en chats separados, que tambi茅n se crearon para cada objeto.
Tambi茅n se tomaron varias decisiones organizativas para mejorar la coordinaci贸n. En general, no es habitual que nuestro equipo establezca tareas con la frase "NADO". Tratamos de discutir por qu茅 se establece esta o aquella tarea, a qu茅 conducir谩 su implementaci贸n y tambi茅n c贸mo llevarla a cabo de manera m谩s eficiente. Pero dentro del marco de StandOff, dicho modelo puede conducir a disputas innecesarias, por lo que decidimos confiar al coordinador una autoridad completa sobre el proceso. A las 28 horas de la competencia, sus decisiones pr谩cticamente no se discutieron, lo que ciertamente nos ahorr贸 mucho tiempo. Aunque puede haber afectado la calidad de las comunicaciones. Adem谩s de esto, decidimos delinear muy claramente las 谩reas de responsabilidad: a pesar de que algunos de los miembros del equipo no obtuvieron las tareas m谩s emocionantes.
2. Recolecci贸n de frutas bajas
En mi opini贸n, el secreto principal de nuestro 茅xito fue: una gran experiencia diaria de proyectos y la correcta priorizaci贸n de tareas. El a帽o pasado, pudimos capturar una oficina completa y mantenerla durante todo el juego simplemente debido a vulnerabilidades simples pirateadas r谩pidamente. Este a帽o, abordamos el problema centralmente y compilamos una lista de tales vulnerabilidades.
ms17-010; ms08-67; SMBCRY LibSSH RCE; HP DATA Protector; HP iLo; ipmi Instalaci贸n inteligente de Cisco Java RMI JDWP; JBOSS; drupalgeddon2; weblogic desangrado concha ibm websphere iis-webdav; servicios; vnc; ftp-anon; NFS smb-null; Tomcat
A continuaci贸n, se escribieron dos servicios de verificaci贸n y penetraci贸n, que en un modo automatizado, utilizando exploits p煤blicos y metasploit, primero verificaron vulnerabilidades y luego intentaron explotarlas. La utilidad recibi贸 un informe nmap en la entrada, que finalmente aceler贸 el proceso.
3. Explotaci贸n de vulnerabilidades de tecnolog铆as at铆picas (para nosotros) (ACS TP, IoT, GSM)
La mayor铆a de las veces hacemos proyectos para bancos y otras organizaciones financieras. Los sistemas SCADA, si lo hacen, son m谩s bien al estilo de: "Si pudo obtener acceso de red a la scada, corr铆jalo y cu茅ntelo como uno de los criterios de 茅xito del proyecto". Por lo tanto, no tenemos una buena experiencia aplicada en el an谩lisis de la seguridad de los sistemas de control de procesos. Esto a su vez llev贸 al hecho de que una semana antes de StandOff nos sentamos con urgencia para estudiar las vulnerabilidades t铆picas. Con IoT y GSM, la situaci贸n es a煤n peor: si IoT a veces se encuentra en proyectos, entonces vimos GSM solo en StandOffs anteriores.
Por lo tanto, durante la preparaci贸n, identificamos dos personas separadas en el sistema automatizado de control de procesos y dos m谩s en GSM e IoT. Durante la semana preparatoria, el primer grupo escribi贸 enfoques t铆picos para el 煤ltimo sistema SCADA, y estudi贸 en detalle un video sobre la infraestructura ICS del a帽o pasado. Los chicos tambi茅n bombearon alrededor de 200 GB de varios HMI, controladores y otro software que est谩 directamente relacionado con los controladores. En cuanto a GSM e IoT, aqu铆 preparamos varias piezas de hierro, le铆mos todos los art铆culos disponibles sobre GSM y esperamos que esto fuera suficiente. (SPOILER: 隆No realmente!)
4. Preparaci贸n de infraestructura y equipos externos.
Entendiendo que nuestro equipo ser谩 lo suficientemente grande este a帽o, inmediatamente decidimos que necesit谩bamos equipo adicional. La siguiente es una lista de sugerencias que hemos recopilado dentro del equipo, el signo "+" indica que finalmente tomamos:
- cafetera;
+ - servidor CUDA (no se lo llevaron, pero lo usaron);
+ laptop de repuesto;
+ Enrutador WIFI;
+ interruptor gestionado;
+ cables de red de varias longitudes (20 piezas);
+ piloto (3 piezas);
+ Alfa Wi-fi (3 piezas);
+ pato de goma (2 piezas);
- proxmark;
- una camara.
En cuanto a la infraestructura, esta es una canci贸n separada. El a帽o pasado, nos dimos cuenta de lo 煤til que es usar una estaci贸n CUDA, rompiendo varios apretones de manos, por lo que no hab铆a dudas sobre la necesidad de usarla. Es importante que este a帽o, as铆 como en el pasado, todos los atacantes estuvieran detr谩s del NATth, que generalmente rechaz贸 la posibilidad de conexiones inversas desde DMZ. Pero absolutamente todos los hosts deber铆an tener acceso a Internet, excepto los nodos ICS. En este sentido, decidimos crear tres servidores de escucha, accesibles desde Internet. Adem谩s, para simplificar el giro y la consolidaci贸n, utilizamos nuestro propio servidor OpenVpn con el modo de cliente a cliente habilitado. Desafortunadamente, es imposible automatizar el proceso de conexi贸n de una puerta de enlace, por lo que durante aproximadamente 12 horas de 28, uno de los miembros del equipo trabaj贸 con las puertas de enlace.
5. Desarrollo de add. m茅todos de persistencia y endurecimiento
Nuestra experiencia pasada con StandOff ha demostrado muy claramente que no es suficiente piratear un servidor con 茅xito: es importante no dejar que otros lo arreglen. Por lo tanto, se prest贸 suficiente atenci贸n a RAT con nuevas firmas y scripts para fortalecer la protecci贸n de Windows. Utilizamos nuestra RAT est谩ndar, cambiando ligeramente los m茅todos de ofuscaci贸n. Las reglas eran un poco m谩s complicadas. En general, determinamos por nosotros mismos el siguiente conjunto de scripts:
- cierre de SMB y RPC;
- portar RDP a un puerto no est谩ndar;
- Deshabilitar el cifrado reversible, las cuentas de invitados y otras configuraciones desde la l铆nea de base de seguridad.
Para Linux, se desarroll贸 un script de inicio especial que cerr贸 todos los puertos, abri贸 SSH en un puerto no est谩ndar y registr贸 las claves p煤blicas del comando para acceder a SSH.
II Briefing
El 17 de mayo, 5 d铆as antes de StandOff, se realiz贸 una sesi贸n informativa para los atacantes. En el transcurso de la misma, surgi贸 mucha informaci贸n que influy贸 en nuestro entrenamiento.
En primer lugar, los organizadores publicaron un mapa de la red, y esto se ha convertido en una gran ayuda para nosotros. Pudimos dividir las 谩reas de responsabilidad por adelantado, actualizar los segmentos de la red y, lo m谩s importante, comprender qu茅 es la red de todos modos. En mi opini贸n, la declaraci贸n m谩s importante realizada en la sesi贸n informativa fue la frase de que la red ICS ser谩 accesible desde un solo segmento, y este segmento no estar谩 protegido. Adem谩s, se otorgar谩n la mayor cantidad de puntos para ICS y oficinas seguras, y los organizadores alientan directamente la lucha por las redes entre hackers.
Tomamos esta informaci贸n de esta manera: "El que captura el bigbrogroup es probable que gane el juego". El caso es que nuestra experiencia nos lo dijo: no importa qu茅 castigos se les ocurran a los organizadores por un servicio simple, los defensores abandonar铆an los servicios vulnerables si no pudieran parchearlos. Despu茅s de todo, es mucho peor cuando anuncian desde el escenario de la conferencia de seguridad de la informaci贸n m谩s grande que usted ha malcriado a los piratas inform谩ticos que si le quitan algunos puntos de juego. Nuestra teor铆a fue confirmada, pero hablaremos de esto en detalle en el segundo art铆culo.
Como resultado, decidimos dividir a todo el equipo en 4 partes:
1. Bigbrogroup. Esta fue la tarea a la que le asignamos la m谩xima prioridad. El equipo involucr贸 a las personas que tienen la mayor experiencia en irrumpir en la infraestructura interna de diferentes clientes. En total, este mini equipo estaba formado por 5 personas. Su objetivo era obtener un punto de apoyo en el dominio lo m谩s r谩pido posible y cortar el acceso de otros equipos al ICS.
2. Red inal谩mbrica. El equipo responsable de monitorear la conexi贸n Wi-Fi, rastre贸 nuevos puntos, intercept贸 los apretones de manos y los maltrat贸. GSM tambi茅n particip贸 en sus tareas, pero antes que nada era necesario capturar Wi-Fi y cortar otros comandos.
3. Redes desprotegidas. El equipo que durante las primeras cuatro horas seleccion贸 todas las redes desprotegidas para detectar vulnerabilidades. Entendimos que en estas cuatro horas no suceder谩 nada s煤per importante en los segmentos protegidos, y si lo hace, los defensores lo revertir谩n. Por lo tanto, se centraron en lo que podr铆a haber cambiado irreversiblemente. Al final result贸 que no en vano. Cuatro horas despu茅s, el mismo grupo comenz贸 a analizar segmentos protegidos.
4. Grupo de esc谩neres. Los organizadores declararon directamente que las redes cambiar谩n, por lo que tuvimos dos personas que exploraron continuamente la red en busca de cambios. No fue tan f谩cil automatizar, porque bajo diferentes redes, se necesitaban diferentes configuraciones en diferentes momentos. Por ejemplo, en la primera hora en la red fe.phd, nmap funcion贸 bien para nosotros en modo T3, y despu茅s de 12 horas apenas funcion贸 en T1.
Otro vector importante para nosotros fue la lista de software y tecnolog铆as publicada por los organizadores. Para cada tecnolog铆a, tratamos de crear nuestro propio centro de competencia, que podr铆a ayudar y ver r谩pidamente las vulnerabilidades t铆picas.
Para algunos servicios, encontramos vulnerabilidades muy interesantes, pero no hubo exploits p煤blicos. As铆 fue, por ejemplo, con Redis Post-explotaci贸n RCE. Est谩bamos seguros de que esta vulnerabilidad aparecer铆a en la infraestructura del juego, por lo que decidimos escribir nuestro propio exploit de 1 d铆a. No fue posible escribir 1 d铆a espec铆ficamente para esta vulnerabilidad, pero en general ten铆amos cerca de cinco exploits no p煤blicos disponibles que est谩bamos listos para usar.
Desafortunadamente, no logramos compartir todas las tecnolog铆as, pero no fue tan aterrador. Cubrimos el set principal, y esto fue suficiente. Tambi茅n hab铆a una lista de controladores de procesos, que tambi茅n resolvimos y tratamos de preparar.
En preparaci贸n para la batalla, preparamos varias herramientas para conectarse sin problemas a la red f铆sica ICS. Por ejemplo, implementamos un an谩logo barato de Pineapple-a usando frambuesa. El m贸dulo se conect贸 a trav茅s de Ethernet a la red industrial y a trav茅s de GSM al servicio de gesti贸n. A continuaci贸n, podr铆amos configurar de forma remota la conexi贸n Ethernet y distribuirla en el acto utilizando el m贸dulo Wi-Fi incorporado. Desafortunadamente, en la sesi贸n informativa, los organizadores dejaron en claro que no se puede conectar f铆sicamente al ICS, por lo que dejamos este m贸dulo hasta tiempos mejores.
Mucha informaci贸n era sobre el banco, el banco offshore y el trabajo antifraude. Pero al haber aprendido que no hay mucho dinero en 茅l, decidimos no prepararnos para esto por adelantado, sino idear algo en el camino.
En resumen, hemos realizado una gran cantidad de trabajo en preparaci贸n. Es importante tener en cuenta que, adem谩s de las ventajas obvias en forma de un desempe帽o exitoso en StandOff, tampoco hubo otras obvias.
- Tal preparaci贸n es una excelente manera de distraerse y hacer algo que siempre he querido probar y explorar, y simplemente no hab铆a tiempo en el marco de la actividad del proyecto.
- No tenemos proyectos que involucren a todo el equipo como parte de una tarea, por lo que obtuvimos un buen trabajo en equipo, persiguiendo objetivos espec铆ficos.
- Gran parte de lo que hemos hecho se puede usar en proyectos reales, por lo que, adem谩s de ampliar nuestras competencias, tambi茅n obtuvimos herramientas listas para usar.
Ahora, habiendo descrito todo esto en el texto, entiendo que no logramos nada tan grandioso como parec铆a antes. En general, me parece que la etapa de preparaci贸n correctamente organizada se convirti贸 en la raz贸n principal de la victoria de nuestro equipo. Y lo que sucedi贸 directamente durante StandOff en s铆, lo contar茅 en el segundo art铆culo del ciclo.