VPN 게이트웨이가 침해되었을 때 실제로 노출되는 것
침해된 VPN 게이트웨이는 자신의 터널 내부를 보지만, 그것이 모든 세션을 장악한다는 뜻은 아니다. 복구 전에 트래픽, 도달 범위, 저장된 비밀을 분리하라.
VPN 게이트웨이는 자신이 보호하는 터널의 끝에 위치한다. 즉, 그 암호화를 통과시키는 것이 아니라 종료한다. 공격자가 호스트를 장악하면 터널은 밖에서 볼 때 여전히 건강해 보이지만, 중간에 있는 기계는 더 이상 신뢰할 수 없다. 유용한 질문은 모든 것이 복호화되는지 여부가 아니다. 그 호스트가 무엇을 볼 수 있었는지, 어디까지 도달할 수 있었는지, 어떤 비밀이 실제로 그 위에 저장되어 있었는지다. 이 세 가지 답은 크게 다르며, 대응도 그에 따라 달라진다.
게이트웨이가 터널을 종료하므로 내부를 본다
VPN의 암호화는 홉 단위로 이루어지고, 게이트웨이가 그 홉이다. 바깥 계층을 벗기고 정책을 적용하며 안쪽 패킷을 전달하므로, 운반되는 모든 패킷은 어느 시점에 그 호스트의 메모리에 읽을 수 있는 형태로 존재한다. 이는 결함이 아니라 설계다. 그래서 게이트웨이의 침해는 터널의 암호 기술 침해와 다른 사건이다.
공격자가 먼저 얻는 것은 위치다. 운반되는 트래픽을 관찰하고, 전달을 바꾸고, 백엔드 대신 응답할 수 있는 능력이다. 다음에 무엇을 얻는지는 호스트에 달려 있으며, 여기서 사람들은 과대평가한다. 게이트웨이 접근만으로는 브라우저의 TLS 세션 키를 넘겨주지 않는다. 그 키는 게이트웨이에 결코 있지 않았기 때문이다.
같은 크기가 아닌 세 가지 노출
질문을 운반되는 트래픽, 도달 가능한 시스템, 저장된 비밀로 나누고 각각에 따로 답하라.
| 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 |
가운데 행이 건너뛰어지는 행이다. 게이트웨이는 보통 사설 네트워크로 가는 경로와 백엔드가 이미 신뢰하는 출발지 주소를 갖는다. 따라서 흥미로운 질문은 그 백엔드들이 그 주소에서 무엇을 허용하는가다. 좁은 클라이언트 접근 정책은 좋은 통제이지만, 호스트 위의 공격자는 일반 클라이언트가 쓰는 인터페이스에 국한되지 않는다.
아래 행은 사건이 얼마나 오래 지속되는지를 결정한다. 서버 키와 CA 키는 영향 범위가 전혀 다르며, 로컬 관리자 계정과 읽기 전용 모니터링 토큰도 마찬가지다.
터널 안의 HTTPS는 여전히 HTTPS
애플리케이션 TLS는 VPN 게이트웨이가 아니라 애플리케이션에서 종료되므로, 침해된 게이트웨이는 그 흐름에 대해 암호문만 관찰한다. 이는 공격자가 얻는 것에 대한 실제 한계이며, 분명히 말할 가치가 있다. 반대 주장은 공포와 잘못된 결정을 퍼뜨리기 때문이다. 두 조건이 이를 깨뜨린다. 신뢰할 수 있는 인증서를 가진 검사 구성요소가 경로에 있으면 게이트웨이는 설계상 평문을 볼 수 있다. 애플리케이션 종단점 자체가 침해되면 터널은 무의미하다.
따라서 그들이 무엇을 보았는가에 대한 답은 조건부이며, 판결로 발표하는 대신 조건으로 기록해야 한다.
다시 신뢰하기 전에 무엇이 바뀌어야 하는가
호스트를 다시 구축하는 것은 필요하지만 충분한 경우는 드물다. 관리 계정, 배포 자격 증명, 서명 키를 여전히 가진 공격자는 호스트를 원하는 대로 되돌릴 수 있다. 복구는 침해된 기계에 의존하지 않는 관리 경로에서 시작해야 한다.
무엇을 교체할지 결정하기 전에 그 위에 무엇이 있었는지 목록을 만들라. 키, 서비스 계정, API 토큰, 로컬 사용자, 예약 작업, 신뢰 관계, 배포 파이프라인은 모두 후보이며, 각각 이를 확인해야 할 소유자가 있다.
ss -lntup
getent passwd
crontab -l
ip route show table all그 목록은 호스트가 무엇을 제공했고 어디까지 도달할 수 있었는지 보는 가장 빠른 방법이다. 먼저 증거를 보존하라. 대응 책임자의 절차에 따라. 재구축은 조사에 필요한 것을 정확히 파괴하기 때문이다. NIST SP 800-61 개정 3은 준비, 탐지, 대응, 복구를 재시작 지침이 아니라 하나의 위험 프로세스의 일부로 본다.
다음 사건을 더 싸게 만드는 경계
필요해지기 전에 네 가지 경계를 구축할 가치가 있다. 게이트웨이를 통해 인증하지 않는 독립적인 복구 경로를 유지하라. 서명 권한을 트래픽을 제공하는 호스트와 분리하라. 게이트웨이가 도달할 수 있는 범위를 제한해, 침해된 게이트웨이가 자동으로 침해된 관리 네트워크가 되지 않게 하라. 그리고 각 자격 증명의 소유자를 기록해, 교체가 고고학 프로젝트가 아니라 전화 한 통이 되게 하라.
이 중 어느 것도 침해를 막지 않는다. 침해를 경계 짓고, 나쁜 한 주와 나쁜 한 분기의 차이를 만든다.