por SeerLight
Construír calquera servizo inclúe necesariamente un traballo constante en materia de seguridade. A seguridade é un proceso continuo que inclúe constante análise e mellora da seguridade do produto, seguimento de noticias sobre vulnerabilidades e moito máis. Incluíndo auditorías. As auditorías realízanse tanto internamente como por expertos externos, que poden axudar radicalmente coa seguridade porque non están inmersos no proxecto e teñen a mente aberta.
O artigo trata sobre esta visión máis sinxela de expertos externos que axudaron ao equipo de Mail.ru Cloud Solutions (MCS) a probar o servizo na nube e sobre o que atoparon. Como "forza externa", MCS elixiu a empresa de Seguridade Dixital, coñecida pola súa alta experiencia nos círculos de seguridade da información. E neste artigo analizaremos algunhas vulnerabilidades interesantes atopadas como parte dunha auditoría externa, para que evites o mesmo rake cando crees o teu propio servizo na nube.
Описание продукта
é unha plataforma para construír infraestrutura virtual na nube. Inclúe IaaS, PaaS e un mercado de imaxes de aplicacións preparadas para desenvolvedores. Tendo en conta a arquitectura MCS, foi necesario comprobar a seguridade do produto nas seguintes áreas:
- protexer a infraestrutura do contorno de virtualización: hipervisores, enrutamento, cortalumes;
- protección da infraestrutura virtual dos clientes: illamento entre si, incluíndo rede, redes privadas en SDN;
- OpenStack e os seus compoñentes abertos;
- S3 de deseño propio;
- IAM: proxectos multi-tenant cun modelo a seguir;
- Visión (visión por ordenador): API e vulnerabilidades ao traballar con imaxes;
- interface web e ataques web clásicos;
- vulnerabilidades dos compoñentes PaaS;
- API de todos os compoñentes.
Quizais iso sexa todo o que é esencial para a historia.
Que tipo de traballo se realizou e por que foi necesario?
Unha auditoría de seguridade ten como obxectivo identificar vulnerabilidades e erros de configuración que poidan provocar fugas de datos persoais, modificación de información confidencial ou interrupción da dispoñibilidade do servizo.
Durante o traballo, que dura de media 1-2 meses, os auditores repiten as accións dos potenciais atacantes e buscan vulnerabilidades nas partes do cliente e do servidor do servizo seleccionado. No contexto da auditoría da plataforma de nube MCS, identificáronse os seguintes obxectivos:
- Análise da autenticación no servizo. As vulnerabilidades neste compoñente axudarían a entrar inmediatamente nas contas doutras persoas.
- Estudo do modelo a seguir e do control de acceso entre diferentes contas. Para un atacante, a capacidade de acceder á máquina virtual doutra persoa é un obxectivo desexable.
- Vulnerabilidades do lado do cliente. XSS/CSRF/CRLF/etc. É posible atacar a outros usuarios mediante ligazóns maliciosas?
- Vulnerabilidades do lado do servidor: RCE e todo tipo de inxeccións (SQL/XXE/SSRF, etc.). As vulnerabilidades do servidor son xeralmente máis difíciles de atopar, pero levan ao compromiso de moitos usuarios á vez.
- Análise do illamento do segmento de usuarios a nivel de rede. Para un atacante, a falta de illamento aumenta moito a superficie de ataque contra outros usuarios.
- Análise da lóxica empresarial. É posible enganar ás empresas e crear máquinas virtuais de balde?
Neste proxecto, traballouse segundo o modelo "Gray-box": os auditores interactuaron co servizo cos privilexios dos usuarios comúns, pero posuían parcialmente o código fonte da API e tiveron a oportunidade de aclarar detalles cos desenvolvedores. Este adoita ser o modelo de traballo máis cómodo e, ao mesmo tempo, bastante realista: a información interna aínda pode ser recollida por un atacante, só é cuestión de tempo.
Atopáronse vulnerabilidades
Antes de que o auditor comece a enviar varias cargas útiles (a carga útil utilizada para levar a cabo o ataque) a lugares aleatorios, é necesario comprender como funcionan as cousas e que funcionalidades se proporcionan. Pode parecer que este é un exercicio inútil, porque na maioría dos lugares estudados non haberá vulnerabilidades. Pero só comprender a estrutura da aplicación e a lóxica do seu funcionamento permitirá atopar os vectores de ataque máis complexos.
É importante atopar lugares que parecen sospeitosos ou que dalgunha forma sexan moi diferentes dos outros. E a primeira vulnerabilidade perigosa atopouse deste xeito.
IDOR
As vulnerabilidades IDOR (Insecure Direct Object Reference) son unha das vulnerabilidades máis comúns na lóxica empresarial, que permite que un ou outro acceda a obxectos aos que realmente non se permite o acceso. As vulnerabilidades de IDOR crean a posibilidade de obter información sobre un usuario de distintos graos de criticidade.
Unha das opcións de IDOR é realizar accións con obxectos do sistema (usuarios, contas bancarias, artigos da cesta da compra) manipulando os identificadores de acceso a estes obxectos. Isto leva ás consecuencias máis imprevisibles. Por exemplo, a posibilidade de substituír a conta do remitente de fondos, a través da cal pode roubarllos a outros usuarios.
No caso de MCS, os auditores acaban de descubrir unha vulnerabilidade IDOR asociada a identificadores non seguros. Na conta persoal do usuario, os identificadores UUID usáronse para acceder a calquera obxecto, que parecía, como din os expertos en seguridade, impresionantemente inseguro (é dicir, protexido de ataques de forza bruta). Pero para determinadas entidades, descubriuse que se usan números previsibles regulares para obter información sobre os usuarios da aplicación. Creo que podes adiviñar que era posible cambiar o ID de usuario por un, enviar de novo a solicitude e así obter información saltando a ACL (lista de control de acceso, regras de acceso a datos para procesos e usuarios).
Falsificación de solicitudes do lado do servidor (SSRF)
O bo dos produtos OpenSource é que teñen un gran número de foros con descricións técnicas detalladas dos problemas que xorden e, se tes sorte, unha descrición da solución. Pero esta moeda ten unha cara atrás: as vulnerabilidades coñecidas tamén se describen en detalle. Por exemplo, hai descricións marabillosas de vulnerabilidades no foro de OpenStack и , que por algún motivo ninguén ten présa en arranxar.
Unha funcionalidade común das aplicacións é a posibilidade de que o usuario envíe unha ligazón ao servidor, na que o servidor fai clic (por exemplo, para descargar unha imaxe dunha fonte especificada). Se as ferramentas de seguridade non filtran as propias ligazóns ou as respostas devoltas do servidor aos usuarios, esta funcionalidade pode ser utilizada facilmente polos atacantes.
As vulnerabilidades de SSRF poden avanzar moito no desenvolvemento dun ataque. Un atacante pode obter:
- acceso limitado á rede local atacada, por exemplo, só a través de determinados segmentos de rede e utilizando un determinado protocolo;
- acceso total á rede local, se é posible a baixada do nivel de aplicación ao nivel de transporte e, como resultado, a xestión da carga completa a nivel de aplicación;
- acceso para ler ficheiros locais no servidor (se se admite o esquema file:///);
- e moito máis.
Hai tempo que se coñece unha vulnerabilidade SSRF en OpenStack, que é de natureza "cega": cando contactas co servidor, non recibes resposta del, pero recibes diferentes tipos de erros/atrasos, dependendo do resultado da solicitude. . En base a isto, pode realizar unha exploración de portos en hosts da rede interna, con todas as consecuencias que non deben ser subestimadas. Por exemplo, un produto pode ter unha API de back-office á que só se pode acceder desde a rede corporativa. Coa documentación (non se esqueza dos insiders), un atacante pode usar SSRF para acceder a métodos internos. Por exemplo, se de algunha maneira puideches obter unha lista aproximada de URL útiles, usando SSRF podes percorrelos e executar unha solicitude, en termos relativos, transferir diñeiro dunha conta a outra ou cambiar os límites.
Esta non é a primeira vez que se descobre unha vulnerabilidade SSRF en OpenStack. No pasado, era posible descargar imaxes ISO de VM desde unha ligazón directa, o que tamén levou a consecuencias similares. Esta función eliminouse agora de OpenStack. Ao parecer, a comunidade considerou esta a solución máis sinxela e fiable ao problema.
E en informe dispoñible publicamente do servizo HackerOne (h1), a explotación dun SSRF que xa non está cego coa capacidade de ler metadatos da instancia leva ao acceso root a toda a infraestrutura de Shopify.
En MCS, descubríronse vulnerabilidades SSRF en dous lugares con funcionalidades similares, pero eran case imposibles de explotar debido aos cortalumes e outras proteccións. Dun xeito ou doutro, o equipo de MCS solucionou este problema de todos os xeitos, sen esperar á comunidade.
XSS en lugar de cargar shells
A pesar de centos de estudos escritos, ano tras ano o ataque XSS (cross-site scripting) segue sendo o máis vulnerabilidade web (ou ?).
As cargas de ficheiros son un lugar favorito para calquera investigador de seguridade. Moitas veces resulta que pode cargar un script arbitrario (asp/jsp/php) e executar comandos do sistema operativo, na terminoloxía de pentesters - "load shell". Pero a popularidade destas vulnerabilidades funciona en ambas direccións: son recordadas e desenvólvense remedios contra elas, polo que recentemente a probabilidade de "cargar un shell" tende a cero.
O equipo atacante (representado por Seguridade Dixital) tivo sorte. OK, en MCS no lado do servidor comprobáronse os contidos dos ficheiros descargados, só se permitían imaxes. Pero SVG tamén é unha imaxe. Como poden ser perigosas as imaxes SVG? Porque podes inserir neles fragmentos de JavaScript.
Descubriuse que os ficheiros descargados están dispoñibles para todos os usuarios do servizo MCS, o que significa que é posible atacar a outros usuarios da nube, é dicir, os administradores.
Un exemplo de ataque XSS nun formulario de inicio de sesión de phishing
Exemplos de explotación de ataques XSS:
- Por que tentar roubar unha sesión (sobre todo porque agora as cookies só HTTP están en todas partes, protexidas contra roubos mediante scripts js), se o script cargado pode acceder inmediatamente á API do recurso? Neste caso, a carga útil pode usar solicitudes XHR para cambiar a configuración do servidor, por exemplo, engadir a clave SSH pública do atacante e obter acceso SSH ao servidor.
- Se a política CSP (política de protección de contidos) prohibe que se inxecte JavaScript, un atacante pode sobrevivir sen el. Usando HTML puro, crea un formulario de inicio de sesión falso para o sitio e rouba o contrasinal do administrador a través deste phishing avanzado: a páxina de phishing para o usuario acaba no mesmo URL e é máis difícil que o usuario detecte.
- Finalmente, o atacante pode arranxar — Establecer cookies de máis de 4 KB. O usuario só ten que abrir a ligazón unha vez, e todo o sitio pasa a ser inaccesible ata que o usuario pensa limpar especificamente o navegador: na gran maioría dos casos, o servidor web rexeitará aceptar tal cliente.
Vexamos un exemplo doutro XSS detectado, esta vez cun exploit máis intelixente. O servizo MCS permítelle combinar a configuración do firewall en grupos. O nome do grupo foi onde se detectou o XSS. A súa peculiaridade era que o vector non se activaba inmediatamente, non ao ver a lista de regras, senón ao eliminar un grupo:
É dicir, o escenario resultou ser o seguinte: un atacante crea unha regra de firewall con "carga" no nome, o administrador advírteo despois dun tempo e inicia o proceso de eliminación. E aquí é onde funciona o JS malicioso.
Para os desenvolvedores de MCS, para protexerse contra XSS nas imaxes SVG descargadas (se non se poden abandonar), o equipo de Seguridade Dixital recomendou:
- Coloque os ficheiros cargados polos usuarios nun dominio separado que non teña nada que ver coas "cookies". O script executarase no contexto dun dominio diferente e non suporá unha ameaza para MCS.
- Na resposta HTTP do servidor, envíe a cabeceira "Content-disposition: attachment". A continuación, os ficheiros serán descargados polo navegador e non executados.
Ademais, agora hai moitas formas dispoñibles para os desenvolvedores para mitigar os riscos da explotación de XSS:
- usando a marca "Só HTTP", pode facer que as cabeceiras de sesión "Cookies" sexan inaccesibles para JavaScript malicioso;
- fará moito máis difícil para un atacante explotar XSS;
- Os motores de modelos modernos como Angular ou React desinfectan automaticamente os datos do usuario antes de envialos ao navegador do usuario.
Vulnerabilidades de autenticación de dous factores
Para mellorar a seguridade da conta, sempre recoméndase aos usuarios que habiliten 2FA (autenticación de dous factores). De feito, esta é unha forma eficaz de evitar que un atacante acceda a un servizo se as credenciais do usuario foron comprometidas.
Pero o uso dun segundo factor de autenticación sempre garante a seguridade da conta? Hai os seguintes problemas de seguridade na implementación de 2FA:
- Busca por forza bruta do código OTP (códigos únicos). A pesar da simplicidade de operación, as grandes empresas tamén atopan erros como a falta de protección contra a forza bruta OTP: , .
- Algoritmo de xeración débil, por exemplo a capacidade de predicir o seguinte código.
- Erros lóxicos, como a posibilidade de solicitar a OTP doutra persoa no teu teléfono, como este de Shopify.
No caso de MCS, 2FA está implementado baseado en Google Authenticator e . O protocolo en si xa foi probado no tempo, pero paga a pena comprobar a implementación da verificación de código no lado da aplicación.
MCS 2FA úsase en varios lugares:
- Ao autenticar o usuario. Hai protección contra a forza bruta: o usuario só ten uns poucos intentos de introducir un contrasinal único e, a continuación, a entrada está bloqueada por un tempo. Isto bloquea a posibilidade de selección de OTP por forza bruta.
- Ao xerar códigos de copia de seguridade sen conexión para realizar 2FA, así como desactivalo. Aquí, non se implementou ningunha protección de forza bruta, o que fixo posible, se tiña un contrasinal para a conta e unha sesión activa, rexenerar códigos de copia de seguridade ou desactivar completamente 2FA.
Tendo en conta que os códigos de copia de seguridade estaban situados no mesmo rango de valores de cadea que os xerados pola aplicación OTP, a posibilidade de atopar o código en pouco tempo era moito maior.
O proceso de selección dun OTP para desactivar 2FA usando a ferramenta "Burp: Intruder".
Resultado
En xeral, MCS parece ser seguro como produto. Durante a auditoría, o equipo de pentesting non puido acceder ás máquinas virtuales do cliente e aos seus datos, e o equipo de MCS corrixiu rapidamente as vulnerabilidades atopadas.
Pero aquí é importante notar que a seguridade é un traballo continuo. Os servizos non son estáticos, están en constante evolución. E é imposible desenvolver un produto completamente sen vulnerabilidades. Pero podes atopalos a tempo e minimizar a posibilidade de que se repitan.
Agora todas as vulnerabilidades mencionadas en MCS xa foron solucionadas. E para reducir ao mínimo o número de novos e reducir a súa vida útil, o equipo da plataforma segue facendo isto:
- realizar auditorías regularmente por empresas externas;
- apoiar e desenvolver a participación;
- comprometerse na seguridade. 🙂
Fonte: www.habr.com