Penetrationstestrapport for centraliseret udveksling

Ledelsesoversigt

Centraliseret Exchange-team kontaktede Sayfer for at udføre fuld blackbox-penetrationstest på deres webapplikation og whitebox-gennemgang for deres kryptoarkitektur i december 2021.

Før vi vurderede ovenstående tjenester, holdt vi et kickoff-møde med det tekniske team på Centralized Exchange og modtog et overblik over systemet og målene for denne forskning.

I løbet af undersøgelsesperioden på 4 uger opdagede vi 10 sårbarheder i systemet. De farligste sårbarheder var SQL-injektion og fejl i forretningslogikken.

Indvirkningen på systemet er kritisk, da en ondsindet hacker kan udnytte nogle af disse sårbarheder til at drage fordel af systemet, enten ved at ændre sin brugerrolle til "super_user" via SQL-indsprøjtningen eller ved at misbruge systemet og stjæle penge fra den centraliserede børs ved hjælp af 30'ernes systemopdateringsmekanisme.

Sikkerhedsvurderingsmetode

Sayfer bruger OWASP WSTG som vores tekniske standard ved gennemgang af webapplikationer. Efter at have fået en grundig forståelse af systemet besluttede vi, hvilke OWASP-tests der kræves for at evaluere systemet.

Sikkerhedsvurderingsresultater

Gemmer private MPC-nøgler på en usikker måde

Beskrivelse

Centraliserede udvekslinger lider under nøgleledelsespraksis af lav kvalitet. Der er mange eksempler på sådanne tilfælde, hvor nøglerne blev tabt eller stjålet, hvilket medførte, at tjenesten mistede alle pengepungen eller låste midlerne fuldstændigt.

Under vores revision af konfigurationsfiler gennemgik vi nøglestyringslagringen. Vi fandt ud af, at nøglerne, der bliver brugt til den kolde multi-sig-pung, ikke opbevares fordelt nok steder.

Der er 3 nøgler, der bruges i MPC-nøglesigneringen. 1 opbevares i en fysisk beskyttet maskine. De andre 2 er gemt i den samme dedikerede maskine i GCP.

Der er taget et par sikkerhedsmålinger for at sikre disse maskiner, men problemet afhænger af distributionen, hvis maskinen, der er installeret på GCP, bliver kompromitteret, kan en angriber underskrive enhver transaktion fra den kolde tegnebog.

Dette er et højrisiko og følsomt sted, hvor mange har fejlet tidligere, bedste praksis bør følges nøje.

Mitigation

Brug 3. parts depotservice til at administrere hot wallets og bokse. Vi vil med glæde anbefale en af ​​vores samarbejdspartnere.

Disse tjenester håndterer MPC og nøglestyring for dig, med andre ekstra sikkerhedslag, der gør brugen af ​​sådanne tjenester til det bedste valg til centraliserede udvekslinger.

SQL Injection

Beskrivelse

Et SQL-injektionsangreb involverer at indsætte eller "injicere" en delvis eller komplet SQL-forespørgsel i datainputtet, der transmitteres fra klienten til webapplikationen. Et vellykket SQL-injektionsangreb kan læse følsomme data fra databasen, ændre databasedata (indsætte/opdatere/slette), udføre databaseadministrationshandlinger (såsom nedlukning af DBMS), gendanne indholdet af en given fil på DBMS-filsystemet eller skrive filer ind i filsystemet og i nogle tilfælde udstede kommandoer til operativsystemet.

Brug af transaction endepunkt, vi var i stand til at misbruge more URL-forespørgselsparameter til indsprøjtning af ondsindet SQL-nyttelast:

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

Den nyttelast vi brugte var:

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b – Hvilket i dette tilfælde kontrollerer, om den kørende forekomst af Postgres er version 10 eller ej.

En hacker, der udnytter denne sårbarhed, kan overtage systemet. Vi var i stand til at udtrække tabelskemaerne, opdatere vores egen brugers rolle eller dumpe enhver information gemt på DB'en og endda ændret vores brugers balance på DB'en.

Mitigation

SQL-injektionssårbarhed er let at rette, men svær at afbøde. Der er behov for stærk lining eller implementering af kompileringsregler, der gennemtvinger fremtidige ændringer.

Afhjælpning af SQL-injektionssårbarheder udføres normalt ved at følge en ramme efter eget valg, hvilket betyder, at udvikleren aldrig bør sammenkæde strenge i en fuld SQL-sætning.

Hvert brugerinput bør renses til en SQL-eksekvering i stedet for at blive brugt som en simpel SQL-forespørgselsstreng.

For mere information om SQL-injektion perfektion henvises til SQL Injection Forebyggelse CheatSheet.

Usikre direkte objektreferencer

Beskrivelse

Usikre direkte objektreferencer (IDOR) er en type adgangskontrolsårbarhed, der opstår, når en applikation bruger brugerleveret input til at få direkte adgang til objekter. Som et resultat af denne sårbarhed kan angribere omgå autorisation og få direkte adgang til ressourcer i systemet, for eksempel databaseposter eller filer.

Vi fandt ud af, at █████████ API'en lader en angriber se andre brugeres dashboardoplysninger, herunder alle denne brugers finansielle data.
Sårbarheden er afhængig af dashboard-id-parameteren, som er et gætteligt heltal. Eksempel på anmodning om et enkelt dashboard (for et dashboard, der ikke ejes af den aktuelle bruger):

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

Det indikerer, at /dashboard/DASHBOARD_ID slutpunkt tjekker ikke for autorisation for den anmodede ressource. En autentificeret angriber kunne skrabe hvert enkelt dashboard, som indeholder oplysninger om brugerens midler og tidligere transaktioner.

Mitigation

Der er flere måder at afbøde IDOR-sårbarheder på, i dette tilfælde ser det ud til, at løsningen kan være at tjekke for autorisation for hver eneste anmodning.

Det betyder, at hver anmodningsnøgle kun vil kunne hente sin kontos dashboards

Svagere autentificering i alternativ kanal

Beskrivelse

Selvom de primære godkendelsesmekanismer ikke inkluderer nogen sårbarheder, kan det være, at der findes sårbarheder i alternative legitime godkendelsesbrugerkanaler for de samme brugerkonti.

Denne sårbarhed er en del af en kæde af 2 sårbarheder, der gjorde det muligt for os at overtage enhver konto med kun en e-mailadresse.

Som en del af vores rekognoseringsfase, hvor vi prøver at finde en bredere angrebsvektor ved at opregne de vigtigste målundersystemer, fandt vi en admin -grænseflade under underdomænet ██████████████████. Det er muligt at logge ind på admin-grænsefladen ved hjælp af en normal app-bruger, men for næsten alle de netværksanmodninger, vi inspicerede under indlæsningen af ​​hovedsiden, returnerer serveren en 401-fejl.

[IMAGE_REDACTED]

Vi reverse-manipulerede main.js bundle-filen, som har front-end-koden til appen, og fandt alle de potentielle slutpunkter, en administrator kan interagere med.

Vi kunne kun udnytte endepunktet af api/updateUser. Slutpunktet gjorde det muligt for os at redigere enhver bruger-e-mail, og ved at gøre det var vi i stand til at nulstille ofrets adgangskode og overtage kontoen

[IMAGE_REDACTED]

Mitigation

Det anbefales stærkt at lave en godkendelsesmekanisme eller en VPN til debugging eller til de administrative tjenester i systemet for at forhindre tilstedeværelsen af ​​usikrede offentlige applikationer, der kan udnyttes af en angriber.

Derudover er der en autorisationsmekanisme i admin-grænsefladen, men dette er uden for dette projekts rammer.

Gennemgå webservermetafiler for informationslækage

Beskrivelse

Som en del af vores forskning om målet og dets underdomæner fandt vi nogle metafiler, der ikke burde være offentlige, eller i det mindste ikke uden den rette autentificeringsmekanisme.

• ████████████████████████.gitignore
• ██████████████████████████████./docker-komponér
• ████████████████████████/swagger-ui.html

[IMAGE_REDACTED]

[IMAGE_REDACTED]

[IMAGE_REDACTED]

Vi fandt tre slags filer, der kan skade ████████ tjenester, .gitignore, swagger-ui og docker-compose.yml fil. Disse tre filer afslører følsomme data

om servicearkitekturen. En ondsindet aktør kan bruge denne information til at øge sin angrebsvektor på målet.

Mitigation

Hvis det er muligt, skal du fjerne disse filer fra den offentlige service eller implementere en autorisationsmekanisme, der kun giver adgang til privilegerede brugere.

Manglende overskrift for indholdssikkerhedspolitik

Beskrivelse

Content Security Policy (CSP) er et ekstra lag af sikkerhed, der hjælper med at opdage og afbøde visse typer angreb, herunder Cross-Site Scripting (XSS) og datainjektionsangreb.

Vi fandt ikke en CSP-header i nogen af ​​serverens svar.

[IMAGE_REDACTED]

Ved at bruge CSP-webstedsadministratorer tilføjer en anden forsvarslinje mod XSS eller clickjacking-angreb, ved at gøre det vil systemet være sikkert, selvom fremtidige usikrede ændringer foretages i kildekoden.

En grundlæggende CSP-politik bør i det mindste beskrive de standard-hvidlistede domæner for statiske filer (som scripts, billeder og CSS). Og frame-ancestors for at forhindre klik-jack-angreb.

Mere info:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

Mitigation

Tilføjelse af Content-Security-Policy: [policy] på hvert svar, hvor det kan være farligt at indlæse eksterne ressourcer

Vi anbefaler stærkt, at du bruger den og tester den først med varianten "Kun rapportering" for at teste din politik, før du frigiver den til produktion:

Content-Security-Policy-Report-Only: [policy]

Test af sikkerhedsoverskrifter

Beskrivelse

1. Browsere understøtter mange HTTP-headere, der kan forbedre applikationssikkerheden for at beskytte mod en række almindelige angreb, headerne udveksles mellem en webklient (normalt en browser) og en server for at specificere de sikkerhedsrelaterede detaljer for HTTP-kommunikation.

Når du ser på ████████ sikkerhedsheadere, mangler følgende:

• X-Content-Type-Options

Indstilling af denne header forhindrer browseren i at fortolke filer som noget andet end det, der er deklareret af indholdstypen i HTTP-headerne.

• Streng-Transport-Sikkerhed

HSTS er en websikkerhedspolitikmekanisme, der hjælper med at beskytte websteder mod protokolnedgraderingsangreb og cookiekapring. Det giver webservere mulighed for at erklære, at webbrowsere kun bør interagere med den ved hjælp af sikre HTTPS-forbindelser og aldrig via den usikre HTTP-protokol.

• Henvisningspolitik

Referer-headeren er en anmodningsheader, der angiver det sted, hvorfra trafikken stammer fra. Hvis der ikke er tilstrækkelig forebyggelse på plads, vil selve URL'en og endda følsomme oplysninger indeholdt i URL'en blive lækket til webstedet med krydsoprindelse.

• Access-Control-Allow-Origin

Overskriften har værdien "*", som afslører API'en for hvert websted, dette er muligvis ikke det ønskede resultat.

Mitigation

Tilføjelse af de nævnte overskrifter til alle back-end-tjenester.

Gennemgå webservermetafiler for informationslækage

Beskrivelse

Mens vi undersøgte målet med DevTool, var vi i stand til at se frontend-kildekoden uden nogen form for sløring. Denne sårbarhed opstår, fordi JS-pakkerne sendes med sourcemaps til produktion, som gør det muligt at læse den originale kildekode med kommentarer, der kan afsløre information, for eksempel følgende paths.ts-fil:

█████████████████████/paths.ts [IMAGE_REDACTED]

Ved at have kildekortet kan en angriber lære om kodebasen, læse kommentarer og finde forældede kodedele, som senere kan bruges til at finde sårbarheder.

Mitigation

Send ikke kildekort til produktion, de fleste log- og fejlsporingssystemer har en mening om at uploade kildekortene til et back-office-system. En anden tilgang ville være kun at servere kildekortene til autentificerede brugere via VPN eller andre mekanismer.

Fingeraftryk webserver

Beskrivelse

Mens blotlagte serveroplysninger i sig selv ikke nødvendigvis er en sårbarhed, er det oplysninger, der kan hjælpe angribere med at udnytte andre sårbarheder, der måtte eksistere. De fleste af slutpunkterne afslører ikke nogen information om serveren gennem HTTP-headere eller fejlsider.
Ved at bruge følgende forkert udformet HTTP-anmodning var vi i stand til at fingeraftrykke en Nginx-server gennem et 400-svar
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

Svarlegemet er:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

Mitigation

Der er forskellige måder at skjule webserverheadere på, de mest almindeligt anvendte metoder er:

1. Reverse proxy-servere, der står mellem det globale internet og det interne
2. Konfigurer hver webserver til at fjerne disse overskrifter.

Bilag A: Rettelser til sikkerhedsevaluering

Vil blive opdateret af Sayfer-teamet efter den første revision.