Kerberos는 SSH 중간자 시나리오(공격자가 사용자가 서버의 공개 키를 신뢰하도록 유도하고 해당 서버를 통해 트래픽을 리디렉션하는 시나리오)에서 공격자가 사용자의 자격 증명을 가져오는 것을 확실히 방지합니다. 그러나 공격자가 인증 후 세션을 수신할 수 있고 이후에 입력된 자격 증명을 포함하여 귀중한 정보를 얻을 수 있기 때문에 공격자가 사용자의 자격 증명을 가져오지 않아도 괜찮다면 어떻게 될까요?
명확하게 말하면 시나리오는 다음과 같습니다.
- SSH 서버(Server1)와 클라이언트(User1)가 Kerberos에 대해 설정되었습니다. Server1에는 인증 등을 위한 표준 공개/개인 키 쌍이 있습니다.
- User1은 처음에 Server1에 연결을 시도하지만 공격자에 의해 연결이 Server2로 리디렉션됩니다.
- User1은 제시된 Server2의 공개 키를 자세히 살펴보지 않고 이를 Server1의 알려진 호스트 키로 받아들입니다(따라서 MITM 설정).
- User1은 Server1에서 Server2까지 Kerberos 인증을 거칩니다(Server2는 두 개의 별도 SSH 세션을 설정하고 이들 간에 정보를 전달합니다). Kerberos 작동 방식으로 인해 공격자는 인증 중에 중요한 정보를 얻지 못합니다.
- 그러나 인증되면 User1은 sudo를 포함하여 Server1에서 작업을 수행하기 시작합니다. 공격자는 Server2를 통과하면서 세션의 모든 내용을 볼 수 있습니다.
이것이 작동할까요? 이 시나리오는 인증 단계에서 공개 키 인증을 사용하면 분명히 방해받을 수 있습니다. 그러나 이러한 상황을 방지할 수 있는 것이 Kerberos 또는 SSH 프로토콜에 있습니까?
답변1
의견의 토론에서 약간 확장되었습니다.
귀하의 질문은 다음과 같습니다. SSH 트래픽을 클라이언트에서 불량 SSH 서버로 전환하는 경우 불량 SSH 서버에서 클라이언트 Kerberos 티켓을 캡처하고 실제 Server1로 전달하여 재생 공격에 사용할 수 있습니까?
이는 MiTM 공격 실패를 방지하는 SSH 보안 메커니즘에 의존합니다. 즉, 클라이언트가 아직 Server1에서 실제 서버 키를 캐시하지 않았거나 캐시한 경우 StrictHostKeyChecking비활성화되거나 무시되었습니다.
SSH + Kerberos GSS-API는 데이터 암호화를 위해 SSH를 사용하므로 SSH는 Kerberos를 사용하지 않기 때문에 Server1에 대한 인증이 성공하면 중간자 사기 SSH 서버가 전송된 모든 정보에 액세스할 수 있다고 가정합니다. SSH 암호화 위에 기반 데이터 암호화.
예, 이론상으로는 가능합니다. 하지만 가짜 SSH 서버인 Server2가 클라이언트를 Server1로 가장하는 데 성공한 경우에만 가능합니다.
나는 실제 Server1이 전달된 자격 증명을 거부할 것이라고 생각합니다(또는 적어도 거부해야 합니다). Kerberos 인증의 일부로 클라이언트는 두 개의 메시지를 보냅니다.서비스 티켓 및 인증기. 전달된 서비스 티켓은 유효하지만 동반된 인증자는 유효하지 않습니다.
RFC 4121SSH에서 사용되는 Kerberos GSS-API 사양에는 인증자 메시지의 일부로 채널 바인딩 정보가 있습니다.
"채널 바인딩 태그는 GSS-API 보안 컨텍스트 설정 토큰이 의도된 특정 통신 채널을 식별하는 데 사용되므로 공격자가 가로채는 컨텍스트 설정 토큰을 재사용할 수 있는 범위를 제한합니다."
즉, 인증자 메시지에는 보낸 사람의 IP 주소와 소스 포트는 물론 대상 IP 주소와 포트 번호도 포함됩니다. 실제 연결과 일치하지 않으면 Server1에서 Kerberos 교환을 거부해야 합니다.