CVE-2024-6387: regreSSHion — 18년 만에 재발한 OpenSSH RCE

OpenSSH의 시그널 핸들러에 존재하는 경쟁 조건(race condition)으로 인해, 인증되지 않은 공격자가 glibc를 사용하는 Linux 서버에서 root 권한으로 임의의 코드를 실행할 수 있습니다. "regreSSHion"이라는 별칭으로 불리며 — 2020년에 실수로 재도입된 CVE-2006-5051의 회귀(regression) 취약점입니다. 약 1,400만 대의 인터넷 노출 SSH 서버에 영향을 미칩니다. CVSS 8.1 높음.

CVE-2024-6387이란?

CVE-2024-6387은 OpenSSH 서버(sshd)에 존재하는 시그널 핸들러 경쟁 조건입니다. 클라이언트가 LoginGraceTime (기본값: 120초) 이내에 인증하지 않으면, sshd는 연결을 종료하기 위해 SIGALRM을 호출합니다. 이 시그널 핸들러는 async-signal-unsafe 함수를 호출하는데 — 구체적으로는 syslog() — 이며, 다른 작업과 동시에 호출될 경우 힙 상태를 손상시킬 수 있습니다.

이 취약점을 발견한 Qualys 연구진은 동일한 버그(CVE-2006-5051)가 2006년에 수정되었으나, 2020년 10월 OpenSSH 8.5p1이 출시되면서 그 수정 사항이 실수로 제거되었기 때문에 이를 "regreSSHion"이라고 명명했습니다 — 즉, 이 취약점이 발견되기까지 거의 4년 동안 조용히 다시 존재했다는 의미입니다.

영향받는 버전

glibc 요구사항: Qualys의 PoC는 glibc의 malloc 구현을 악용했습니다. OpenBSD의 sshd는 취약하지 않습니다. musl libc를 사용하는 Alpine Linux와 macOS는 경쟁 조건 자체는 존재하지만, 시연된 익스플로잇 기법에는 취약하지 않습니다.

경쟁 조건 설명

C 프로그램의 시그널 핸들러는 반드시 "async-signal-safe" 함수만 호출해야 합니다 — 공유 상태를 사용하지 않기 때문에 시그널 핸들러 내부에서 호출해도 안전한 소수의 libc 함수 집합입니다. syslog() 함수는 async-signal-safe가 아닙니다 — 내부적으로 malloc()을 사용하기 때문입니다.

# 문제가 되는 코드 경로(단순화):
# LoginGraceTime이 만료되면:
SIGALRM → grace_alarm_handler() → syslog() → malloc() internally
                                              ↕ RACE
           main sshd thread also calls        malloc() / free()

# 두 malloc 작업이 겹치면:
# → 힙 손상
# → 충분한 시도 횟수: 제어된 힙 레이아웃
# → root 권한 원격 코드 실행

익스플로잇에 성공하려면 경쟁 조건에서 안정적으로 승리해야 하며, 이를 위해서는 수 분에 걸쳐 수천 번의 연결 시도가 필요합니다. 이로 인해 인터넷 규모의 자동화된 익스플로잇은 일반적인 "발사 후 망각(fire and forget)" 취약점보다 다소 느립니다 — 하지만 표적에 지속적으로 접근할 수 있는 정교한 공격자에게는 시간이 충분합니다.

익스플로잇 난이도

Qualys는 32비트 시스템(x86)에서 안정적인 익스플로잇을 시연했습니다. 64비트 시스템에서는 ASLR이 난이도를 크게 높입니다. 연구진에 따르면 6~8시간에 걸쳐 약 1만 번을 시도하면 64비트 시스템에서도 이론적으로 익스플로잇이 가능하지만, x86_64용 작동 가능한 PoC는 공개하지 않았습니다.

다만 다음 요인으로 인해 진입 장벽이 낮아질 수 있습니다:

• ASLR을 무력화하는 정보 유출(복합 익스플로잇)
• fail2ban이나 속도 제한이 구성되지 않은 환경에서의 무차별 대입 공격
• 익스플로잇 기법을 개선하는 향후 연구
• 취약한 32비트 시스템에 대한 접근(IoT 및 임베디드 Linux에서 여전히 흔함)

탐지

# OpenSSH 버전 확인
ssh -V
sshd -V

# 설치된 패키지 버전 확인(Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# 설치된 패키지 버전 확인(RHEL/CentOS)
rpm -qa | grep openssh-server

# regreSSHion 익스플로잇을 시사하는 무차별 대입 시도 확인
# (단일 IP에서의 매우 높은 연결 빈도, grace period 내 전부 실패)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# 높은 빈도의 로그인 실패 확인
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -10

완화 방안

1. OpenSSH를 9.8p1+로 업데이트: 모든 주요 배포판이 공개 후 며칠 내에 패치를 배포했습니다. apt update && apt upgrade openssh-server 또는 이에 상응하는 명령을 사용하세요.
2. LoginGraceTime을 0으로 설정: 다음을 설정하세요: LoginGraceTime 0 (파일: /etc/ssh/sshd_config ) — SIGALRM 핸들러가 호출되지 않도록 하여 경쟁 조건을 제거합니다(다만 유예 시간 제한 기능도 사라집니다):

   echo "LoginGraceTime 0" >> /etc/ssh/sshd_config
   systemctl reload sshd

3. SSH 연결 속도 제한: 익스플로잇에 필요한 수천 건의 연결 시도를 막기 위해 fail2ban 또는 iptables 속도 제한을 구성하세요
4. IP 기준으로 SSH 접근 제한: sshd 접근을 알려진 관리 IP 범위로 제한하려면 AllowUsers, ListenAddress, 또는 방화벽 규칙을 사용하세요
5. SSH 키만 사용: 비밀번호 인증을 비활성화하세요 — 키 기반 인증은 강력한 사전 인증 필터 역할을 합니다
6. SSH를 비표준 포트로 이전 고려: 보안 통제 수단은 아니지만 기회주의적 스캐너의 노이즈를 줄여줍니다

KENSAI 탐지 역량

• SSH 배너 스캐닝: KENSAI는 모든 인터넷 노출 자산에서 OpenSSH 버전을 식별하여 8.5p1~9.7p1을 CVE-2024-6387에 취약한 것으로 표시합니다
• 내부 네트워크 스캐닝: 내부 네트워크에서 취약한 SSH 서버를 포괄적으로 탐색합니다
• 구성 점검: 완화 구성 여부를 확인합니다(LoginGraceTime, AllowUsers, 키 전용 인증)
• 패치 검증: 해결 조치 이후 패치 적용 여부를 확인합니다
• 노출 맥락: 내부 전용 시스템보다 인터넷에 노출된 SSH 서버에 우선순위를 둡니다