Vilka validatorer påverkar ett extra rotcertifikat?

Du hittar ett rotcertifikat som inte borde finnas där, och den första frågan är vems identitet det kan imitera. Det ärliga svaret beror på vilken programvara som rådfrågar det arkivet och hur din VPN verifierar sin gateway. En webbläsare, en pakethanterare och en VPN-klient med ett fäst fingeravtryck delar inte nödvändigtvis samma förtroendebeslut. Kartlägg validatorerna innan du bestämmer omfattningen.

En rot i systemarkivet är inte en universell nyckel

Att installera en rot gör certifikat som signerats med den nyckeln godtagbara för program som använder det berörda arkivet. Det gör dem inte automatiskt godtagbara överallt, eftersom vissa program levererar sitt eget paket eller kontrollerar ett fäst värde. Det bevisar inte heller att någon har kört kod på maskinen; en förtroendeändring är en av flera möjligheter. Behandla certifikatet som ett fynd som ska avgränsas, inte som hela incidenten.

Arkivet är lika viktigt som certifikatet: ett paket på användarnivå och ett systemomfattande ankare når olika konsumenter.

Kartlägg varje validator och dess förtroendekälla

Skriv ned varje komponent som validerar certifikat för de berörda arbetsflödena: webbläsare, pakethanterare, e-postklient, VPN. Hitta sedan förtroendekällan som var och en läser.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

Kataloglistningen visar lokalt tillagda ankare på Debian-liknande system, och förtroendelistan visar vad systemarkivet för närvarande exponerar. En webbläsare med eget arkiv kommer inte att dyka upp där, och ett Java- eller Python-program kan använda ännu ett paket. Anteckna vilka poster som är förväntade och vilka som inte är det, med fingeravtrycket i stället för bara visningsnamnet. Den listan är vad en incidentansvarig behöver innan något raderas.

Kontrollera VPN:ens egen peer-validering

En VPN med en privat CA eller ett explicit fingeravtryck utvärderar gatewayen enligt sin egen konfiguration. Jämför vad klienten förväntar sig med vad gatewayen presenterar.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

Utdata ger SHA-256-fingeravtrycket och subjektet för certifikatet som slutpunkten presenterar, vilka du kan jämföra med det konfigurerade värdet. OpenVPN har ett alternativ för peer-fingeravtryck som gör den jämförelsen för tunneln utan att kräva att systemarkivet accepterar undertecknaren. Det oberoendet är användbart för tunneln och säger ingenting om webbläsaren. Det hjälper inte heller om det förväntade fingeravtrycket kopierades från den misstänkta anslutningen från början.

Avgränsa incidenten bortom certifikatet

Använd enhetsägarens procedur för att ta bort obehöriga ankare och leta efter de ändringar som vanligtvis följer dem: nya tjänster, ändrade klienter, ändrade proxyinställningar. På en hanterad maskin, bekräfta den legitima konfigurationen innan du raderar material som annan programvara är beroende av. För varje validator, anteckna varifrån dess förtroende kommer, vilken identitet den förväntar sig och hur du bekräftade att den aktuella konfigurationen är korrekt. En fungerande tunnel efter städningen är en observation, inte bevis för att slutpunkten är ren.

Testa sedan om arbetsflödena som använde arkivet, eftersom borttagning av ett ankare kan bryta en intern tjänst som med rätta litade på det. Återställningen är klar när de förväntade förtroendeförhållandena fungerar och de oväntade inte gör det.