per SeerLight
La construcció de qualsevol servei inclou necessàriament un treball constant en seguretat. La seguretat és un procés continu que inclou l'anàlisi i la millora constant de la seguretat del producte, el seguiment de notícies sobre vulnerabilitats i molt més. Incloses les auditories. Les auditories les realitzen tant a casa com a experts externs, que poden ajudar radicalment amb la seguretat perquè no estan immersos en el projecte i tenen la ment oberta.
L'article tracta sobre aquesta visió més directa dels experts externs que van ajudar l'equip de Mail.ru Cloud Solutions (MCS) a provar el servei al núvol i sobre què van trobar. Com a "força externa", MCS va triar l'empresa de Seguretat Digital, coneguda per la seva gran experiència en cercles de seguretat de la informació. I en aquest article analitzarem algunes vulnerabilitats interessants trobades com a part d'una auditoria externa, de manera que eviteu el mateix rastre quan creeu el vostre propi servei al núvol.
продукта Описание
és una plataforma per construir infraestructura virtual al núvol. Inclou IaaS, PaaS i un mercat d'imatges d'aplicacions preparades per a desenvolupadors. Tenint en compte l'arquitectura MCS, va ser necessari comprovar la seguretat del producte en les àrees següents:
- protegir la infraestructura de l'entorn de virtualització: hipervisors, enrutament, tallafocs;
- protecció de la infraestructura virtual dels clients: aïllament els uns dels altres, inclosa la xarxa, xarxes privades en SDN;
- OpenStack i els seus components oberts;
- S3 de disseny propi;
- IAM: projectes multi-arrendatari amb model a seguir;
- Visió (visió per ordinador): API i vulnerabilitats quan es treballa amb imatges;
- interfície web i atacs web clàssics;
- vulnerabilitats dels components PaaS;
- API de tots els components.
Potser això és tot el que és essencial per a més història.
Quin tipus de treball es va fer i per què va ser necessari?
Una auditoria de seguretat té com a objectiu identificar vulnerabilitats i errors de configuració que podrien provocar la fuga de dades personals, la modificació d'informació sensible o la interrupció de la disponibilitat del servei.
Durant el treball, que té una durada mitjana d'1-2 mesos, els auditors repeteixen les accions dels potencials atacants i busquen vulnerabilitats a les parts del client i del servidor del servei seleccionat. En el context de l'auditoria de la plataforma de núvol MCS, es van identificar els objectius següents:
- Anàlisi de l'autenticació en el servei. Les vulnerabilitats d'aquest component ajudarien a entrar immediatament als comptes d'altres persones.
- Estudiar el model a seguir i el control d'accés entre diferents comptes. Per a un atacant, la possibilitat d'accedir a la màquina virtual d'una altra persona és un objectiu desitjable.
- Vulnerabilitats del costat del client. XSS/CSRF/CRLF/etc. És possible atacar altres usuaris mitjançant enllaços maliciosos?
- Vulnerabilitats del costat del servidor: RCE i tot tipus d'injeccions (SQL/XXE/SSRF, etc.). Les vulnerabilitats del servidor són generalment més difícils de trobar, però comporten el compromís de molts usuaris alhora.
- Anàlisi de l'aïllament del segment d'usuari a nivell de xarxa. Per a un atacant, la manca d'aïllament augmenta considerablement la superfície d'atac contra altres usuaris.
- Anàlisi de la lògica empresarial. És possible enganyar empreses i crear màquines virtuals gratuïtament?
En aquest projecte, s'ha treballat segons el model “Grey-box”: els auditors van interactuar amb el servei amb els privilegis dels usuaris normals, però posseïen parcialment el codi font de l'API i tenien l'oportunitat d'aclarir detalls amb els desenvolupadors. Aquest sol ser el model de treball més convenient i alhora força realista: un atacant encara pot recopilar informació interna, és només qüestió de temps.
Vulnerabilitats trobades
Abans que l'auditor comenci a enviar diverses càrregues útils (la càrrega útil utilitzada per dur a terme l'atac) a llocs aleatoris, cal entendre com funcionen les coses i quina funcionalitat s'ofereix. Pot semblar que aquest és un exercici inútil, perquè a la majoria dels llocs estudiats no hi haurà vulnerabilitats. Però només entendre l'estructura de l'aplicació i la lògica del seu funcionament permetrà trobar els vectors d'atac més complexos.
És important trobar llocs que semblin sospitosos o que d'alguna manera siguin molt diferents dels altres. I la primera vulnerabilitat perillosa es va trobar d'aquesta manera.
IDOR
Les vulnerabilitats IDOR (Insecure Direct Object Reference) són una de les vulnerabilitats més comunes en la lògica empresarial, que permet a uns o altres accedir a objectes als quals realment no es permet l'accés. Les vulnerabilitats IDOR creen la possibilitat d'obtenir informació sobre un usuari de diferents graus de criticitat.
Una de les opcions IDOR és realitzar accions amb objectes del sistema (usuaris, comptes bancaris, articles del carretó de la compra) manipulant els identificadors d'accés a aquests objectes. Això porta a les conseqüències més imprevisibles. Per exemple, la possibilitat de substituir el compte del remitent de fons, a través del qual podràs robar-los a altres usuaris.
En el cas de MCS, els auditors acaben de descobrir una vulnerabilitat IDOR associada a identificadors no segurs. Al compte personal de l'usuari, s'utilitzaven identificadors UUID per accedir a qualsevol objecte, que semblava, com diuen els experts en seguretat, impressionantment insegur (és a dir, protegit d'atacs de força bruta). Però per a determinades entitats, es va descobrir que s'utilitzen números previsibles regulars per obtenir informació sobre els usuaris de l'aplicació. Crec que podeu endevinar que era possible canviar l'identificador d'usuari per un, tornar a enviar la sol·licitud i així obtenir informació sense passar per l'ACL (llista de control d'accés, regles d'accés a dades per a processos i usuaris).
Falsificació de sol·licituds del costat del servidor (SSRF)
El millor dels productes OpenSource és que tenen un gran nombre de fòrums amb descripcions tècniques detallades dels problemes que sorgeixen i, si teniu sort, una descripció de la solució. Però aquesta moneda té una cara inversa: les vulnerabilitats conegudes també es descriuen amb detall. Per exemple, hi ha descripcions meravelloses de vulnerabilitats al fòrum OpenStack и , que per alguna raó ningú té pressa per arreglar.
Una funcionalitat comuna de les aplicacions és la capacitat per a l'usuari d'enviar un enllaç al servidor, on el servidor fa clic (per exemple, per descarregar una imatge d'una font especificada). Si les eines de seguretat no filtren els enllaços ni les respostes retornades del servidor als usuaris, aquesta funcionalitat la poden utilitzar fàcilment els atacants.
Les vulnerabilitats SSRF poden avançar molt en el desenvolupament d'un atac. Un atacant pot obtenir:
- accés limitat a la xarxa local atacada, per exemple, només a través de determinats segments de xarxa i utilitzant un determinat protocol;
- accés complet a la xarxa local, si és possible baixar de nivell d'aplicació al nivell de transport i, com a resultat, gestió de la càrrega completa a nivell d'aplicació;
- accés per llegir fitxers locals al servidor (si s'admet l'esquema file:///);
- i molt més.
Fa temps que es coneix una vulnerabilitat SSRF a OpenStack, que és de naturalesa "cega": quan contacteu amb el servidor, no rebeu cap resposta d'aquest, però rebeu diferents tipus d'errors/retards, segons el resultat de la sol·licitud. . A partir d'això, podeu realitzar una exploració de ports als amfitrions de la xarxa interna, amb totes les conseqüències consegüents que no s'han de subestimar. Per exemple, un producte pot tenir una API de back-office a la qual només es pot accedir des de la xarxa corporativa. Amb la documentació (no us oblideu dels experts), un atacant pot utilitzar SSRF per accedir als mètodes interns. Per exemple, si d'alguna manera vau poder obtenir una llista aproximada d'URL útils, us podeu fer servir SSRF i executar una sol·licitud, en termes relatius, transferir diners d'un compte a un altre o canviar els límits.
Aquesta no és la primera vegada que es descobreix una vulnerabilitat SSRF a OpenStack. En el passat, era possible descarregar imatges ISO de VM des d'un enllaç directe, cosa que també va provocar conseqüències similars. Aquesta funció s'ha eliminat ara d'OpenStack. Pel que sembla, la comunitat va considerar que aquesta era la solució més senzilla i fiable al problema.
I en informe disponible públicament del servei HackerOne (h1), l'explotació d'un SSRF ja no cec amb la capacitat de llegir metadades de la instància condueix a l'accés root a tota la infraestructura de Shopify.
A MCS, es van descobrir vulnerabilitats SSRF en dos llocs amb una funcionalitat similar, però eren gairebé impossibles d'explotar a causa dels tallafocs i altres proteccions. D'una manera o altra, l'equip de MCS va solucionar aquest problema de totes maneres, sense esperar a la comunitat.
XSS en lloc de carregar shells
Malgrat els centenars d'estudis escrits, any rere any l'atac XSS (cross-site scripting) segueix sent el més vulnerabilitat web (o ?).
Les càrregues de fitxers són un lloc preferit per a qualsevol investigador de seguretat. Sovint resulta que podeu carregar un script arbitrari (asp/jsp/php) i executar ordres del sistema operatiu, amb la terminologia de pentesters - "load shell". Però la popularitat d'aquestes vulnerabilitats funciona en ambdues direccions: es recorden i es desenvolupen remeis contra elles, de manera que recentment la probabilitat de "carregar un shell" tendeix a zero.
L'equip atacant (representat per Seguretat Digital) va tenir sort. D'acord, a MCS al costat del servidor es va comprovar el contingut dels fitxers descarregats, només es permetien imatges. Però SVG també és una imatge. Com poden ser perilloses les imatges SVG? Perquè podeu inserir-hi fragments de JavaScript!
Va resultar que els fitxers descarregats estan disponibles per a tots els usuaris del servei MCS, la qual cosa significa que és possible atacar altres usuaris del núvol, és a dir, els administradors.
Un exemple d'atac XSS a un formulari d'inici de sessió de pesca
Exemples d'explotació d'atac XSS:
- Per què intentar robar una sessió (sobretot perquè ara les galetes només HTTP estan a tot arreu, protegides del robatori mitjançant scripts js), si l'script carregat pot accedir immediatament a l'API de recursos? En aquest cas, la càrrega útil pot utilitzar sol·licituds XHR per canviar la configuració del servidor, per exemple, afegir la clau SSH pública de l'atacant i obtenir accés SSH al servidor.
- Si la política CSP (política de protecció de contingut) prohibeix que s'injecti JavaScript, un atacant pot sobreposar-s'hi. Utilitzant HTML pur, creeu un formulari d'inici de sessió fals per al lloc i roba la contrasenya de l'administrador mitjançant aquest phishing avançat: la pàgina de phishing de l'usuari acaba a la mateixa URL i és més difícil que l'usuari la detecti.
- Finalment, l'atacant pot organitzar-se — establiu galetes de més de 4 KB. L'usuari només necessita obrir l'enllaç una vegada, i tot el lloc esdevé inaccessible fins que l'usuari pensa netejar específicament el navegador: en la gran majoria dels casos, el servidor web es negarà a acceptar aquest client.
Vegem un exemple d'un altre XSS detectat, aquesta vegada amb un exploit més intel·ligent. El servei MCS us permet combinar la configuració del tallafoc en grups. El nom del grup era on es va detectar l'XSS. La seva particularitat era que el vector no es va activar immediatament, no quan es visualitza la llista de regles, sinó quan s'elimina un grup:
És a dir, l'escenari va resultar ser el següent: un atacant crea una regla de tallafoc amb "càrrega" al nom, l'administrador ho nota al cap d'un temps i inicia el procés d'eliminació. I aquí és on funciona el JS maliciós.
Perquè els desenvolupadors de MCS es protegeixin contra XSS a les imatges SVG penjades (si no es poden ometre), l'equip de seguretat digital va recomanar:
- Col·loqueu els fitxers penjats pels usuaris en un domini independent que no tingui res a veure amb les "cookies". L'script s'executarà en el context d'un domini diferent i no representarà una amenaça per a MCS.
- A la resposta HTTP del servidor, envieu la capçalera "Content-disposition: attachment". Aleshores, el navegador baixarà els fitxers i no s'executaran.
A més, ara hi ha moltes maneres disponibles per als desenvolupadors per mitigar els riscos de l'explotació XSS:
- utilitzant la marca "Només HTTP", podeu fer que les capçaleres de les "Cookies" de sessió siguin inaccessibles per a JavaScript maliciós;
- farà que sigui molt més difícil per a un atacant explotar XSS;
- Els motors de plantilles moderns com Angular o React desinfecten automàticament les dades de l'usuari abans d'enviar-les al navegador de l'usuari.
Vulnerabilitats d'autenticació de dos factors
Per millorar la seguretat del compte, sempre es recomana als usuaris que habilitin 2FA (autenticació de dos factors). De fet, aquesta és una manera eficaç d'evitar que un atacant accedeixi a un servei si les credencials de l'usuari s'han vist compromeses.
Però l'ús d'un segon factor d'autenticació sempre garanteix la seguretat del compte? Hi ha els següents problemes de seguretat en la implementació de 2FA:
- Cerca per força bruta del codi OTP (codis d'un sol ús). Malgrat la simplicitat d'operació, les grans empreses també troben errors com la manca de protecció contra la força bruta OTP: , .
- Algorisme de generació feble, per exemple la capacitat de predir el següent codi.
- Errors lògics, com ara la possibilitat de sol·licitar l'OTP d'una altra persona al telèfon, com aquest de Shopify.
En el cas de MCS, s'implementa 2FA basat en Google Authenticator i . El protocol en si ja s'ha provat amb el temps, però val la pena comprovar la implementació de la verificació de codi al costat de l'aplicació.
MCS 2FA s'utilitza en diversos llocs:
- En autenticar l'usuari. Hi ha protecció contra la força bruta: l'usuari només té uns quants intents d'introduir una contrasenya única i després l'entrada queda bloquejada durant un temps. Això bloqueja la possibilitat de selecció de força bruta d'OTP.
- En generar codis de còpia de seguretat fora de línia per realitzar 2FA, així com desactivar-lo. Aquí, no es va implementar cap protecció de força bruta, cosa que va permetre, si teníeu una contrasenya per al compte i una sessió activa, regenerar codis de seguretat o desactivar completament 2FA.
Tenint en compte que els codis de seguretat estaven situats en el mateix rang de valors de cadena que els generats per l'aplicació OTP, la possibilitat de trobar el codi en poc temps era molt més gran.
El procés de selecció d'un OTP per desactivar 2FA mitjançant l'eina "Burp: Intruder".
Resultat
En general, MCS sembla ser segur com a producte. Durant l'auditoria, l'equip de pentesting no va poder accedir a les VM del client i les seves dades, i l'equip MCS va corregir ràpidament les vulnerabilitats trobades.
Però aquí és important tenir en compte que la seguretat és un treball continu. Els serveis no són estàtics, estan en constant evolució. I és impossible desenvolupar un producte completament sense vulnerabilitats. Però podeu trobar-los a temps i minimitzar les possibilitats que es repeteixin.
Ara totes les vulnerabilitats esmentades a MCS ja s'han solucionat. I per tal de reduir el nombre de nous al mínim i reduir la seva vida útil, l'equip de la plataforma continua fent això:
- realitzar auditories periòdiques per empreses externes;
- donar suport i desenvolupar la participació;
- dedicar-se a la seguretat. 🙂
Font: www.habr.com