Din VPN-gateway är komprometterad: vad som faktiskt är exponerat
En hackad VPN-gateway ser in i sin egen tunnel, men det är inte att äga varje session. Separera trafik, räckvidd och lagrade hemligheter före återställning.
En VPN-gateway står vid slutet av tunneln den skyddar, vilket innebär att den avslutar krypteringen i stället för att släppa igenom den. Om en angripare kontrollerar värden ser tunneln fortfarande frisk ut utifrån medan maskinen i mitten inte längre är pålitlig. Den användbara frågan är inte om allt dekrypteras. Den är vad den värden kunde se, vart den kunde nå och vilka hemligheter som faktiskt lagrades på den. De tre svaren skiljer sig mycket, och responsen skiljer sig med dem.
Gatewayen avslutar tunneln, så den ser in i den
Kryptering i en VPN går hopp för hopp, och gatewayen är hoppet. Den tar bort det yttre lagret, tillämpar policy och vidarebefordrar det inre paketet, så varje transporterat paket finns någon gång i läsbar form i den värdens minne. Det är designen och inte en brist. Det är också därför kompromettering av gatewayen är en annan händelse än kompromettering av tunnelns kryptografi.
Det angriparen först vinner är position: förmågan att observera transporterad trafik, ändra vidarebefordran eller svara i stället för en backend. Vad de vinner därefter beror på värden, och det är här människor överskattar. Enbart åtkomst till gatewayen lämnar inte ut webbläsarens TLS-sessionsnycklar, eftersom de aldrig fanns på gatewayen.
Tre exponeringar som inte är lika stora
Dela upp frågan i transporterad trafik, nåbara system och lagrade hemligheter, och svara sedan på var och en för sig.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
Den mellersta raden är den som hoppas över. En gateway har vanligtvis en rutt in i privata nätverk och en källadress som backends redan litar på, så den intressanta frågan är vad dessa backends tillåter från den adressen. En snäv klientåtkomstpolicy är en bra kontroll, men en angripare på värden är inte begränsad till det gränssnitt en normal klient skulle använda.
Den nedersta raden avgör hur länge incidenten varar. En servernyckel och en CA-nyckel har helt olika verkansradier, och detsamma gäller ett lokalt administratörskonto och en skrivskyddad övervakningstoken.
HTTPS inne i tunneln är fortfarande HTTPS
Applikationens TLS avslutas i applikationen, inte på VPN-gatewayen, så en komprometterad gateway observerar bara chiffertext för dessa flöden. Det är en verklig gräns för vad angriparen får, och det är värt att säga tydligt, eftersom det motsatta påståendet sprider panik och dåliga beslut. Två villkor bryter det. Om en inspektionskomponent med ett betrott certifikat sitter i vägen kan gatewayen se klartext enligt design. Om själva applikationens slutpunkt är komprometterad är tunneln irrelevant.
Svaret på vad de såg är alltså villkorat, och det bör skrivas ned som villkor i stället för att annonseras som en dom.
Vad som måste ändras innan du litar på den igen
Att bygga om värden är nödvändigt och sällan tillräckligt. En angripare som fortfarande har ett administrationskonto, en distributionsuppgift eller en signeringsnyckel kan sätta tillbaka värden som de vill. Återställning måste börja från en administrationsväg som inte beror på den komprometterade maskinen.
Kartlägg vad som fanns på den innan du bestämmer vad som ska roteras. Nycklar, tjänstekonton, API-token, lokala användare, schemalagda jobb, förtroenderelationer och distributionspipen är alla kandidater, och var och en har en ägare som bör bekräfta det.
ss -lntup
getent passwd
crontab -l
ip route show table allDen listan är det snabbaste sättet att se vad värden erbjöd och vart den kunde nå. Bevara bevisen först, enligt ägaren till insatsens process, eftersom en ombyggnad förstör precis det en utredning behöver. NIST SP 800-61 Revision 3 behandlar förberedelse, detektion, respons och återställning som delar av en enda riskprocess i stället för som en omstartsinstruktion.
Gränser som gör nästa billigare
Fyra gränser är värda att bygga innan du behöver dem. Håll en oberoende återställningsväg som inte autentiserar genom gatewayen. Håll signeringsbefogenheten åtskild från värden som betjänar trafik. Begränsa vart gatewayen kan nå, så att en komprometterad gateway inte automatiskt är ett komprometterat administrationsnät. Och registrera vem som äger varje inloggningsuppgift, så att rotation är ett telefonsamtal i stället för ett arkeologiprojekt.
Inget av detta förhindrar kompromettering. De begränsar den, och de gör skillnaden mellan en dålig vecka och ett dåligt kvartal.