Imaxina esta situación. Fría mañá de outubro, instituto de deseño no centro rexional dunha das rexións de Rusia. Alguén do departamento de RRHH vai a unha das páxinas de vacantes da páxina web do instituto, publicada hai un par de días, e ve alí unha foto dun gato. A mañá axiña deixa de ser aburrida...
Neste artigo, Pavel Suprunyuk, xefe técnico do departamento de auditoría e consultoría do Grupo-IB, fala sobre o lugar dos ataques sociotécnicos nos proxectos que avalían a seguridade práctica, cales son as formas pouco habituais que poden adoptar e como protexerse contra estes ataques. O autor aclara que o artigo ten carácter de revisión, non obstante, se algún aspecto interesa aos lectores, os expertos do Grupo IB responderán facilmente ás preguntas nos comentarios.
Parte 1. Por que tan serio?
Volvemos ao noso gato. Despois dun tempo, o departamento de RRHH elimina a foto (as capturas de pantalla aquí e abaixo están parcialmente retocadas para non revelar nomes reais), pero volve teimudamente, bótase de novo e isto ocorre varias veces máis. O departamento de RRHH entende que o gato ten as intencións máis serias, non quere marchar e piden axuda a un programador web: unha persoa que creou o sitio e o entende e agora o administra. O programador vai ao sitio, unha vez máis borra o gato molesto, descobre que foi publicado en nome do propio departamento de RRHH, entón asume que o contrasinal do departamento de RRHH se filtrou a algúns hooligans en liña e cámbiao. O gato non volve aparecer.
Que pasou realmente? En relación ao grupo de empresas que incluía o instituto, os especialistas do Grupo-IB realizaron probas de penetración nun formato próximo ao Red Teaming (é dicir, trátase dunha imitación de ataques dirixidos á súa empresa utilizando os métodos e ferramentas máis avanzados do arsenal de grupos de hackers). Falamos en detalle sobre Red Teaming . É importante saber que ao realizar unha proba deste tipo pódese utilizar unha gama moi ampla de ataques previamente acordados, incluíndo a enxeñaría social. Está claro que a propia colocación do gato non era o obxectivo final do que estaba a suceder. E houbo o seguinte:
- o sitio web do instituto estaba aloxado nun servidor dentro da propia rede do instituto, e non en servidores de terceiros;
- Atopouse unha fuga na conta do departamento de RRHH (o ficheiro de rexistro do correo electrónico está na raíz do sitio). Era imposible administrar o sitio con esta conta, pero si era posible editar páxinas de traballo;
- Ao cambiar as páxinas, podes colocar os teus scripts en JavaScript. Normalmente fan que as páxinas sexan interactivas, pero nesta situación, os mesmos scripts poderían roubar do navegador do visitante o que distinguía o departamento de recursos humanos do programador e o programador dun simple visitante: o identificador de sesión do sitio. O gato foi un detonante de ataque e unha imaxe para chamar a atención. Na linguaxe de marcado do sitio web HTML, parecía o seguinte: se a túa imaxe se cargou, xa se executou JavaScript e xa se roubou o teu ID de sesión, xunto cos datos do teu navegador e enderezo IP.
- Cun ID de sesión de administrador roubado, sería posible obter acceso completo ao sitio, aloxar páxinas executables en PHP e, polo tanto, acceder ao sistema operativo do servidor, e despois á propia rede local, que era un importante obxectivo intermedio de o proxecto.
O ataque foi parcialmente exitoso: o ID de sesión do administrador foi roubado, pero estaba ligado a un enderezo IP. Non puidemos evitar isto; non puidemos aumentar os privilexios do noso sitio aos privilexios de administrador, pero melloramos o noso estado de ánimo. O resultado final obtívose finalmente noutro tramo do perímetro da rede.
Parte 2. Escríboche: que máis? Tamén chamo e quedo na túa oficina, deixando caer as unidades flash.
O que pasou na situación co gato é un exemplo de enxeñería social, aínda que non moi clásica. De feito, houbo máis acontecementos nesta historia: había un gato, un instituto, un departamento de persoal e un programador, pero tamén había correos electrónicos con preguntas aclaratorias que supostamente "candidatos" escribían ao propio departamento de persoal e persoalmente. ao programador para provocar que vaian á páxina do sitio.
Falando de letras. O correo electrónico ordinario, probablemente o principal vehículo para a realización da enxeñaría social, non perde a súa relevancia desde hai un par de décadas e, ás veces, leva ás consecuencias máis insólitas.
A miúdo contamos a seguinte historia nos nosos eventos, xa que é moi reveladora.
Normalmente, baseándonos nos resultados de proxectos de enxeñería social, elaboramos estatísticas que, como sabemos, son algo seco e aburrido. Tanto por cento dos destinatarios abriron o anexo da carta, tantos seguiron a ligazón, pero estes tres realmente introduciron o seu nome de usuario e contrasinal. Nun proxecto, recibimos máis do 100 % dos contrasinais introducidos, é dicir, saíron máis do que enviamos.
Ocorreu así: enviouse unha carta de phishing, supostamente do CISO dunha corporación estatal, coa demanda de "probar urxentemente os cambios no servizo de correo". A carta chegou ao xefe dun gran departamento que se ocupaba do soporte técnico. O xerente foi moi dilixente no cumprimento das instrucións das altas autoridades e remitiunas a todos os subordinados. O propio centro de chamadas resultou ser bastante grande. En xeral, as situacións nas que alguén reenvía correos electrónicos de phishing "interesantes" aos seus colegas e tamén son atrapados son unha ocorrencia bastante común. Para nós, este é o mellor comentario sobre a calidade de escribir unha carta.
Un pouco máis tarde decatáronse de nós (a carta foi levada nun buzón comprometido):
O éxito do ataque debeuse a que o correo explotou unha serie de deficiencias técnicas no sistema de correo do cliente. Estaba configurado de tal xeito que era posible enviar calquera carta en nome de calquera remitente da propia organización sen autorización, mesmo desde Internet. É dicir, podería facerse pasar por un CISO, ou o xefe de soporte técnico ou outra persoa. Ademais, a interface de correo, observando as cartas do "seu" dominio, inseriu coidadosamente unha foto da axenda de enderezos, o que engadía naturalidade ao remitente.
En realidade, tal ataque non é unha tecnoloxía especialmente complexa; é unha explotación exitosa dunha falla moi básica na configuración do correo. Revísase regularmente sobre recursos informáticos especializados e de seguridade da información, pero, con todo, aínda hai empresas que teñen todo isto presente. Dado que ninguén está inclinado a comprobar a fondo as cabeceiras do servizo do protocolo de correo SMTP, unha carta adoita comprobarse se hai "perigo" mediante iconas de aviso na interface de correo, que non sempre mostran a imaxe completa.
Curiosamente, unha vulnerabilidade similar tamén funciona na outra dirección: un atacante pode enviar un correo electrónico en nome da súa empresa a un terceiro destinatario. Por exemplo, pode falsificar unha factura para o pago regular no teu nome, indicando outros datos en lugar dos teus. Ademais dos problemas antifraude e de retirada de efectivo, esta é probablemente unha das formas máis sinxelas de roubar cartos a través da enxeñaría social.
Ademais de roubar contrasinais mediante phishing, un ataque sociotécnico clásico é o envío de anexos executables. Se estes investimentos superan todas as medidas de seguridade, das que as empresas modernas adoitan ter moitas, crearase unha canle de acceso remoto ao ordenador da vítima. Para demostrar as consecuencias do ataque, o control remoto resultante pódese desenvolver ata acceder a información confidencial especialmente importante. Cabe destacar que a gran maioría dos ataques que utilizan os medios para asustar a todos comezan exactamente así.
No noso departamento de auditoría, por diversión, calculamos estatísticas aproximadas: cal é o valor total dos activos das empresas ás que obtivemos acceso de Administrador de Dominios, principalmente mediante phishing e envío de anexos executables? Este ano alcanzou uns 150 millóns de euros.
Está claro que enviar correos electrónicos provocativos e publicar fotos de gatos en sitios web non son os únicos métodos de enxeñería social. Nestes exemplos tentamos mostrar a variedade de formas de ataque e as súas consecuencias. Ademais das cartas, un atacante potencial pode chamar para obter a información necesaria, espallar medios (por exemplo, unidades flash) con ficheiros executables na oficina da empresa de destino, conseguir un emprego como interno, acceder físico á rede local. baixo o pretexto dun instalador de cámaras CCTV. Todos estes, por certo, son exemplos dos nosos proxectos rematados con éxito.
Parte 3. O ensino é luz, pero o non aprendido é escuridade
Xorde unha pregunta razoable: ben, vale, hai enxeñería social, parece perigosa, pero que deben facer as empresas con todo isto? O capitán Obvious vén ao rescate: cómpre defenderse, e dunha forma integral. Parte da protección estará destinada a medidas de seguridade xa clásicas, como medios técnicos de protección da información, seguimento, soporte organizativo e xurídico dos procesos, pero a parte principal, na nosa opinión, debería estar dirixida ao traballo directo cos empregados como o elo máis débil. Despois de todo, por moito que reforces a tecnoloxía ou escribas normativas duras, sempre haberá un usuario que descubrirá unha nova forma de romper todo. Ademais, nin as normativas nin a tecnoloxía seguirán o voo da creatividade do usuario, especialmente se o pide un atacante cualificado.
En primeiro lugar, é importante formar ao usuario: explique que mesmo no seu traballo rutineiro poden xurdir situacións relacionadas coa enxeñaría social. Para os nosos clientes realizamos moitas veces sobre hixiene dixital: un evento que ensina habilidades básicas para contrarrestar ataques en xeral.
Podo engadir que unha das mellores medidas de protección non sería memorizar en absoluto as normas de seguridade da información, senón avaliar a situación dun xeito lixeiramente separado:
- Quen é o meu interlocutor?
- De onde saíu a súa proposta ou petición (isto nunca ocorreu, e agora apareceu)?
- Que ten de raro esta solicitude?
Incluso un tipo de letra inusual ou un estilo de discurso que non é habitual para o remitente pode provocar unha cadea de dúbidas que deterán un ataque. Tamén son necesarias instrucións prescritas, pero funcionan de forma diferente e non poden especificar todas as situacións posibles. Por exemplo, os administradores de seguridade da información escriben neles que non pode introducir o seu contrasinal en recursos de terceiros. E se o recurso de rede "o teu", "corporativo" pide un contrasinal? O usuario pensa: "A nosa empresa xa ten dúas ducias de servizos cunha única conta, por que non tes outra?" Isto leva a outra regra: un proceso de traballo ben estruturado tamén afecta directamente á seguridade: se un departamento veciño pode solicitarche información só por escrito e só a través do teu xestor, unha persoa "dun socio de confianza da empresa" seguramente non será poder solicitalo por teléfono - isto é para ti será unha tontería. Debería ser especialmente cauteloso se o seu interlocutor esixe que faga todo agora mesmo, ou "o antes posible", xa que está de moda escribir. Incluso no traballo normal, esta situación moitas veces non é saudable, e ante posibles ataques, é un forte detonante. Non hai tempo para explicar, executa o meu ficheiro!
Observamos que os usuarios sempre son apuntados como lendas por un ataque sociotécnico por temas relacionados co diñeiro dunha ou outra forma: promesas de promocións, preferencias, agasallos, así como información con chismes e intrigas supostamente locais. Noutras palabras, os banais "pecados capitais" están a traballar: sede de lucro, avaricia e curiosidade excesiva.
Un bo adestramento debe incluír sempre a práctica. Aquí é onde os expertos en probas de penetración poden acudir ao rescate. A seguinte pregunta é: que e como probaremos? En Group-IB propoñemos o seguinte enfoque: seleccionar inmediatamente o foco das probas: ou ben avaliar a preparación para ataques só dos propios usuarios ou comprobar a seguridade da empresa no seu conxunto. E proba usando métodos de enxeñería social, simulando ataques reais, é dicir, o mesmo phishing, enviando documentos executables, chamadas e outras técnicas.
No primeiro caso, o ataque prepárase coidadosamente xunto con representantes do cliente, principalmente cos seus especialistas en TI e seguridade da información. As lendas, as ferramentas e as técnicas de ataque son consistentes. O propio cliente proporciona grupos focales e listas de usuarios para atacar, que inclúen todos os contactos necesarios. Créanse excepcións nas medidas de seguridade, xa que as mensaxes e as cargas executables deben chegar ao destinatario, porque nun proxecto deste tipo só interesan as reaccións das persoas. Opcionalmente, pode incluír marcadores no ataque, polos que o usuario pode adiviñar que se trata dun ataque; por exemplo, pode cometer un par de erros ortográficos nas mensaxes ou deixar imprecisións ao copiar o estilo corporativo. Ao final do proxecto obtéñense as mesmas “estatísticas secas”: que grupos focales responderon aos escenarios e ata que punto.
No segundo caso, o ataque realízase cun coñecemento inicial cero, utilizando o método da "caixa negra". Recollemos de forma independente información sobre a empresa, os seus empregados, o perímetro da rede, creamos lendas de ataque, seleccionamos métodos, buscamos posibles medidas de seguridade utilizadas na empresa de destino, adaptamos ferramentas e creamos escenarios. Os nosos especialistas usan tanto os métodos clásicos de intelixencia de código aberto (OSINT) como o produto propio de Group-IB: Threat Intelligence, un sistema que, cando se prepara para o phishing, pode actuar como un agregador de información sobre unha empresa durante un longo período, incluíndo información clasificada. Iso si, para que o ataque non se converta nunha sorpresa desagradable, os seus detalles tamén se acordan co cliente. Resulta ser unha proba de penetración de pleno dereito, pero estará baseada en enxeñería social avanzada. A opción lóxica neste caso é desenvolver un ataque dentro da rede, ata conseguir os máximos dereitos nos sistemas internos. Por certo, de xeito similar empregamos os ataques sociotécnicos en , e nalgunhas probas de penetración. Como resultado, o cliente recibirá unha visión integral independente da súa seguridade fronte a un determinado tipo de ataques sociotécnicos, así como unha demostración da eficacia (ou, pola contra, ineficacia) da liña de defensa construída contra ameazas externas.
Recomendamos realizar esta formación polo menos dúas veces ao ano. En primeiro lugar, en calquera empresa hai rotación de persoal e a experiencia previa é gradualmente esquecida polos empregados. En segundo lugar, os métodos e técnicas de ataque están en constante cambio e isto leva á necesidade de adaptar os procesos de seguridade e as ferramentas de protección.
Se falamos de medidas técnicas para protexerse contra ataques, as seguintes axudan máis:
- A presenza dunha autenticación obrigatoria de dous factores nos servizos publicados en Internet. Liberar estes servizos en 2019 sen sistemas de inicio de sesión único, sen protección contra a forza bruta do contrasinal e sen autenticación de dous factores nunha empresa de varios centos de persoas equivale a unha chamada aberta para "romperme". A protección implementada correctamente fará imposible o uso rápido dos contrasinais roubados e dará tempo para eliminar as consecuencias dun ataque de phishing.
- Controlando o control de acceso, minimizando os dereitos dos usuarios nos sistemas e seguindo as directrices para a configuración segura do produto que publica cada fabricante principal. Adoitan ser de natureza sinxela, pero moi eficaces e de difícil aplicación, que todo o mundo, nun ou outro grao, descoida por mor da rapidez. E algúns son tan necesarios que sen eles ningún medio de protección salvará.
- Liña de filtrado de correo electrónico ben construída. Antispam, dixitalización total de anexos en busca de código malicioso, incluíndo probas dinámicas a través de sandbox. Un ataque ben preparado significa que o anexo executable non será detectado polas ferramentas antivirus. O sandbox, pola contra, probará todo por si mesmo, utilizando os ficheiros do mesmo xeito que unha persoa os usa. Como resultado, un posible compoñente malicioso será revelado polos cambios realizados dentro do sandbox.
- Medios de protección contra ataques selectivos. Como xa se indicou, as ferramentas antivirus clásicas non detectarán ficheiros maliciosos no caso dun ataque ben preparado. Os produtos máis avanzados deberían supervisar automaticamente a totalidade dos eventos que ocorren na rede, tanto a nivel de host individual como a nivel de tráfico dentro da rede. No caso dos ataques, aparecen cadeas de sucesos moi características que se poden seguir e deter se se ten un seguimento centrado en sucesos deste tipo.
Artigo orixinal na revista “Seguridade da información/ Seguridade da información” #6, 2019.
Fonte: www.habr.com