WireGuard / CVE-2019-14899 : 프로토콜이 실제로 얼마나 안전합니까?
저는 수년 동안 다양한 시나리오에 OpenVPN 및 SSH 터널을 사용해 왔으며 최근에는 WireGuard의 단순성과 보안에 대해 많은 관심을 받고 있습니다. 이제 CVE-2019-14899에 대한 몇 가지 문제가되는 정보를 찾았습니다 .
L2 링크 (예 : WiFi 또는 LAN)를 제어하는 공격자가 특수 제작 된 패킷을 장치로 보낼 수 있습니다. 그런 다음 공격자는 이러한 패킷을 사용하여 장치에서 시작된 TCP 연결의 특정 속성을 적극적으로 조사 할 수 있습니다. 즉, 공격자는 장치의 인터넷 액세스 포인트를 제어하여 사용자가 특정 호스트 및 포트에 연결되어 있는지 유추 할 수 있습니다.
또한 VPN 터널 내에서 TCP 연결이 암호화되지 않은 경우 (예를 들어 HTTPS 대신 HTTP를 사용하는 페이지를 방문하는 경우) 공격자는 해당 암호화되지 않은 특정 스트림에 패킷을 삽입 할 수 있습니다. 이렇게하면 공격자가 특정 스트림에 대한 가짜 HTML 콘텐츠를 장치에 공급할 수 있습니다. 이는 위험 할 수 있지만 앞서 언급했듯이 공격자는 특정 TCP 연결을 대상으로해야하므로 악용 할 수있는 간단한 취약점이 아닙니다.
출처: https://protonvpn.com/blog/statement-on-cve-2019-14899/
- 이 정보가 기술적으로 정확합니까?
- 웹상의 일부 소스에서는 서버의 WAN을 제어하는 모든 사람이이 결함을 이용할 수 있다고도 설명합니다. 사실인가요? 서버의 ISP가이를 악용 할 수 있습니까?
정보가 정확하다고 가정합니다.
- "TCP 연결이 VPN 터널 내에서 암호화되지 않은 경우"가 왜 중요합니까? 이론적으로는이 문제를 해결하기 위해 VPN을 정확히 사용합니다. 두 시스템 간의 통신 내용을 아무도 볼 수 없도록하기 위해;
- 클라이언트의 LAN을 제어하는 사람이 패키지를 삽입 할 수 있다면 어떻게 이것이 보안 프로토콜로 간주됩니까? 내 절제된 진위 확인은 이와 같은 시나리오에서 필수입니다. 서버는 새로운 데이터를 맹목적으로 받아들이는 대신 진위를 확인할 수 있어야합니다 ... 이것에 대한 어떤 종류의 키 교환이 있지 않습니까?
- Wireguard의 웹 사이트에 따르면 "SSH 및 Mosh 모델을 모방합니다 . 양 당사자는 서로의 공개 키 를 가지고 있으며 인터페이스를 통해 패킷 교환을 시작할 수 있습니다." 제 3 자 (올바른 키가없는)가 클라이언트를 가장하고 데이터를 전송 한 다음 서버가 오류없이 클라이언트의 실제 키를 사용하여이를 해독하는 방법은 무엇입니까?
미리 감사드립니다.
답변
이 정보가 기술적으로 정확합니까?
예,하지만 이전에 권장 된 완화 방법으로 중지 할 수없는 이전 공격의 수정 사항이 있습니다. Blind In / On-Path Attack Disclosure FAQ를 참조하십시오 .
웹상의 일부 소스에서는 서버의 WAN을 제어하는 모든 사람이이 결함을 이용할 수 있다고도 설명합니다. 사실인가요? 서버의 ISP가이를 악용 할 수 있습니까?
이것은 완전히 다른 시나리오입니다. VPN 엔드 포인트에서 서버로의 연결은 어쨌든 VPN에 의해 보호되지 않습니다. 공격자가이 부분을 훨씬 쉽게 제어한다면 더 위험한 공격이 가능합니다.
"TCP 연결이 VPN 터널 내에서 암호화되지 않은 경우"가 왜 중요합니까? 이론적으로는 VPN을 사용하여이 문제를 해결합니다. 두 컴퓨터 간의 통신 내용을 아무도 볼 수 없도록하기 위해
공격은 기존 TCP 연결에 패킷을 삽입 할 수 있습니다. 정상적인 TCP 연결은 공격에 의해 우회되는 이것 (즉, 임의의 소스 포트 및 시퀀스 번호)에 대한 제한적인 보호 만 있습니다. 연결이 암호화에 의해 추가로 보호되는 경우이 주입은 더 이상 작동하지 않습니다. "암호화"는 실제로 필요하지도 충분하지도 않지만 요점은 무결성 보호입니다. 그러나 TLS와 같은 적절한 암호화 프로토콜에는 무결성 보호도 포함됩니다.
클라이언트의 LAN을 제어하는 사람이 패키지를 삽입 할 수 있다면 어떻게 이것이 보안 프로토콜로 간주됩니까? 내 절제된 진위성 검증은 이와 같은 시나리오에서 필수입니다. 서버는 새로운 데이터를 맹목적으로 받아들이는 대신 진위를 확인할 수 있어야합니다 ... 이것에 대한 어떤 종류의 키 교환이 있지 않습니까?
서버의 관점에서 볼 때 데이터가 잘못 보이는 것은 아닙니다. 즉, 여기서는 아무것도 감지 할 수 없습니다.
Wireguard의 웹 사이트에 따르면 "SSH와 Mosh의 모델을 모방합니다. 양 당사자는 서로의 공개 키를 가지고 있으며 인터페이스를 통해 패킷 교환을 시작할 수 있습니다." 제 3 자 (올바른 키가없는)가 클라이언트를 가장하고 데이터를 전송 한 다음 서버가 오류없이 클라이언트의 실제 키를 사용하여이를 해독하는 방법은 무엇입니까?
이것은 암호화에 대한 공격이 아닙니다. 원래 공격 CVE-2019-14899는 클라이언트가 다른 인터페이스에서 일반 데이터를 수락하고 VPN 터널 인터페이스에서 해독 된 데이터와 동일한 방식으로 처리하여 주입을 가능하게했습니다. 그렇기 때문에 공격이 사용 된 실제 레이어 3 VPN 기술과는 무관합니다.
즉, OS (VPN이 아님)는 VPN 인터페이스에서 나오는 신뢰할 수있는 데이터 (암호 해독 후)를 다른 네트워크 인터페이스에서 나오는 신뢰할 수없는 (공격자 제어) 데이터와 병합합니다. VPN 계층 자체에 대한 공격이 아니라 VPN이 OS에 통합되는 방식입니다.