Uložené heslo VPN: kto ho môže dešifrovať a kedy

Klient VPN, ktorý zobrazuje šifrované heslo vo svojom XML, vám nepovedal takmer nič. Šifrovaný text odpovedá len na to, že hodnota v tomto zobrazení nie je uložená ako čistý text. Kto ho môže dešifrovať, akým kľúčom a v akom používateľskom kontexte — to sú otázky, ktoré rozhodujú, či ukladanie pomáha. Odpovedzte na ne skôr, než súbor nazvete bezpečným alebo nebezpečným.

Určite, ktorý objekt sa ukladá

Začnite s dokumentovaným modelom ukladania produktu. Klient môže ukladať obnoviteľné heslo, token alebo odkaz na úložisko prihlasovacích údajov a každá z týchto možností má inú expozíciu. Názov prvku XML nie je návrh a ani reťazec pripomínajúci base64 nie je dôkazom šifrovania.

Spýtajte sa dodávateľa alebo správcu, ktorý komponent číta hodnotu pri pripájaní.

Potom určite ochranné API, ak je zdokumentované. V systéme Windows CryptProtectData chráni údaje kľúčom odvodeným z prihlasovacích údajov šifrujúceho používateľa a možnosť na úrovni počítača mení, kto môže dešifrovať. To je konkrétny príklad toho, prečo záleží na rozsahu. Nie je to dôkaz, že nejaký konkrétny klient VPN toto API používa.

Oddeľte ukradnutú kópiu od použitia za behu

Klient, ktorý sa pripája znova bez toho, aby sa vás opýtal, potrebuje podporovaný spôsob obnovy prihlasovacích údajov. Ochrana záložnej kópie túto schopnosť neodstraňuje. Akýkoľvek program bežiaci v správnom používateľskom kontexte môže použiť tú istú cestu, a preto samotný koncový bod leží vnútri hranice dôvery. Práva súborov a privilégiá procesov túto hranicu zužujú; neodstraňujú ju.

Práve tento rozdiel zvyčajne pokazí tvrdenie o offline súbore. Šifrovanie v pokoji môže zastaviť niekoho, kto skopíruje jeden súbor bez účtu. Nezastaví kód, ktorý beží ako ten účet.

Obe tvrdenia môžu platiť súčasne a počas reakcie na incident záleží na tom druhom.

Prečítajte si riadiace prvky prístupu, ktoré skutočne platia

Skontrolujte ACL súboru aj adresára nad ním, nielen režim súboru. V systéme Windows porovnajte efektívne oprávnenia používateľského profilu s oprávneniami služby alebo naplánovanej úlohy klienta. Tajomstvo chránené pre jedného používateľa nie je automaticky chránené pred správcom a nie je mu ani automaticky vystavené.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Zapíšte, aká identita spúšťa klienta, pretože táto identita je subjektom dešifrovania.

Pre spravovanú flotilu môže byť príslušnou kontrolou správa zariadení namiesto súboru. Opýtajte sa, či sú prihlasovacie údaje uložené v úschove, či ich možno vzdialene zrušiť a aký je postup pri strate zariadenia.

Plánujte expozíciu namiesto testovania dešifrovania

Nespúšťajte na súbor neznámy nástroj na extrakciu, aby ste niečo dokázali. Môže fungovať, môže poškodiť profil a v každom prípade mení dôkazy. Použite dokumentovaný návrh a autorizované posúdenie, ak je overenie skutočne potrebné.

Ak je expozícia preukázaná, vymeňte prihlasovacie údaje u vlastníka identity.

Vymazanie uloženého záznamu nie je zrušenie. Môže zabrániť tomu klientovi znova ponúknuť hodnotu a nič nerobí s už prevzatou kópiou ani s už autorizovanou reláciou. Nahraďte prihlasovacie údaje, ukončite relácie, ktoré vlastník môže ukončiť, a zapíšte, čo sa vymenilo a kedy.

Otázky na revíziu dodávateľa

Opýtajte sa, aké tajomstvo sa ukladá, ktorý komponent ho používa, ktorý používateľský alebo počítačový kľúč ho chráni, ktoré riadiace prvky prístupu platia na bežné používanie a zálohy a ako sa spracúvajú politika ukladania a vzdialené zneplatnenie. Tých päť odpovedí opisuje návrh; XML nie.

Odpovede uchovajte spolu so záznamom o nasadení, aby ďalší recenzent neopakoval toto cvičenie.

Uložené prihlasovacie údaje sú výmena medzi pohodlím a expozíciou. Urobte tú výmenu vedome a zapíšte, kto ju prijal.