A túa pasarela VPN está comprometida: que queda realmente exposto
Unha pasarela VPN pirateada ve dentro do seu propio túnel, pero iso non é controlar cada sesión. Separa o tráfico, o alcance e os segredos almacenados antes de recuperar.
Unha pasarela VPN sitúase no extremo do túnel que protexe, o que significa que remata ese cifrado en vez de deixalo pasar. Se un atacante controla o host, o túnel segue parecendo san desde fóra mentres a máquina do medio xa non é fiable. A pregunta útil non é se todo se descifra. É que podía ver ese host, ata onde podía chegar e que segredos estaban realmente almacenados nel. Esas tres respostas difiren moito, e a resposta difire con elas.
A pasarela remata o túnel, así que ve dentro
O cifrado nunha VPN vai salto a salto, e a pasarela é o salto. Elimina a capa exterior, aplica a política e reenvía o paquete interior, así que cada paquete transportado existe en forma lexible na memoria dese host nalgún momento. Ese é o deseño e non un defecto. É tamén a razón de que comprometer a pasarela sexa un suceso distinto de comprometer a criptografía do túnel.
O primeiro que gaña o atacante é posición: a capacidade de observar o tráfico transportado, alterar o reenvío ou responder no canto dun backend. O que gaña despois depende do host, e aquí a xente sobreestima. O acceso á pasarela por si só non entrega as claves de sesión TLS dun navegador, porque nunca estiveron na pasarela.
Tres exposicións que non son do mesmo tamaño
Divide a pregunta en tráfico transportado, sistemas alcanzables e segredos almacenados, e logo responde cada unha por separado.
| 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 |
A fila do medio é a que se omite. Unha pasarela adoita ter unha ruta cara a redes privadas e un enderezo de orixe no que os backends xa confían, así que a pregunta interesante é que permiten eses backends desde ese enderezo. Unha política estreita de acceso de clientes é un bo control, pero un atacante no host non se limita á interface que usaría un cliente normal.
A fila inferior decide canto dura o incidente. Unha clave de servidor e unha clave de CA teñen radios de impacto completamente distintos, e tamén unha conta de administrador local e un token de monitorización de só lectura.
HTTPS dentro do túnel segue a ser HTTPS
O TLS da aplicación remata na aplicación, non na pasarela VPN, así que unha pasarela comprometida observa texto cifrado para eses fluxos. Ese é un límite real ao que obtén o atacante, e merece dicirse con claridade, porque a afirmación contraria espalla pánico e malas decisións. Dúas condicións rompen isto. Se no camiño hai un compoñente de inspección cun certificado de confianza, a pasarela pode ver texto plano por deseño. Se o propio punto final da aplicación está comprometido, o túnel é irrelevante.
Por tanto, a resposta a que viron é condicional, e debería escribirse como condicións en vez de anunciarse como un veredicto.
Que ten que cambiar antes de volver confiar nela
Reconstruír o host é necesario e raramente suficiente. Un atacante que aínda conserva unha conta de xestión, unha credencial de despregamento ou unha clave de sinatura pode devolver o host ao seu gusto. A recuperación debe comezar por unha vía de administración que non dependa da máquina comprometida.
Fai un inventario do que había nel antes de decidir que rotar. Claves, contas de servizo, tokens de API, usuarios locais, tarefas programadas, relacións de confianza e a canalización de despregamento son todos candidatos, e cada un ten un propietario que debería confirmalo.
ss -lntup
getent passwd
crontab -l
ip route show table allEsa listaxe é a forma máis rápida de ver que ofrecía o host e ata onde podía chegar. Conserva primeiro as probas, segundo o proceso do propietario da resposta, porque unha reconstrución destrúe exactamente o que necesita unha investigación. NIST SP 800-61 Revisión 3 trata a preparación, a detección, a resposta e a recuperación como partes dun único proceso de risco, non como unha instrución de reinicio.
Fronteiras que abaratan a seguinte
Merece a pena construír catro fronteiras antes de necesitalas. Mantén unha vía de recuperación independente que non se autentique a través da pasarela. Mantén a autoridade de sinatura separada do host que serve tráfico. Limita ata onde pode chegar a pasarela, para que unha pasarela comprometida non sexa automaticamente unha rede de xestión comprometida. E rexistra quen posúe cada credencial, para que a rotación sexa unha chamada en vez dun proxecto de arqueoloxía.
Ningunha destas cousas impide o compromiso. Acóutano, e marcan a diferenza entre unha mala semana e un mal trimestre.