OpenSSH의 치명적인 regreSSHion 취약점 관련 가이드
핵심 요약
CVE-2024-6387은 2006년에 발생한 CVE의 회귀에서 비롯된 OpenSSH의 중대한 원격 코드 실행(RCE) 취약점입니다.
악용을 위해서는 경쟁 조건에서 승리해야 하며, 성공적으로 악용하는 데는 몇 시간 또는 몇 주까지도 걸릴 수 있습니다.
권장되는 조치는 glibc 기반 Linux 시스템에서 영향을 받지 않는 버전의 OpenSSH 서버로 패치를 적용하는 것입니다. 이것이 불가능한 상황에서 잠재적인 영향을 줄이기 위한 다른 방어 옵션을 포함했습니다.
취약한 버전의 OpenSSH를 탐지할 수 있는 OSQuery도 제공합니다.
OpenSSH 취약점 배경 및 기술적 분석
최근 Qualys Threat Research Unit 에서 인증되지 않은 RCE로 이어질 수 있는 새로운 중대 취약점(CVE-2024-6387)을 OpenSSH에서 발견했습니다. 2024년 7월 1일, Qualys Threat Research Unit은 2006년에 패치되었다가 2021년에 다시 나타난 취약점 CVE-2006-5051의 회귀에 대한 조사 결과 를 발표했습니다.
이 CVE의 근본 원인은 사용자 인증 시간이 초과될 때 신호를 안전하지 않게 처리해 발생하는 경쟁 조건입니다. 타임아웃 시 SIGALRM 신호가 생성되어 힙 관리 루틴을 실행 중인 스레드에 인터럽트를 일으킵니다. 신호 처리기 자체가 힙 관리 루틴을 호출하면 예기치 않은 행동이 발생할 수 있으며, 이 경우 임의 코드가 실행합니다.
현재 이 취약점을 악용하는 공개 개념 증명 (PoC)이 존재하여 악용된 취약점으로 알려졌습니다(이 PoC는 Akamai와 제휴하지 않은 써드파티에서 제공되므로 코드와의 상호 작용을 시도하기 전에 자체 실사를 수행해야 합니다). 심각도에도 불구하고 이 PoC는 성공적인 악용을 위한 몇 가지 제한 사항을 강조합니다. 주요 제한 사항 중 하나는 악용에 걸리는 시간으로, 일부 시스템에서는 몇 시간이 걸릴 수 있고 다른 시스템에서는 최대 일주일이 걸릴 수 있습니다. 다른 제한 사항으로는 운영 체제의 배포판과 OpenSSH 서버의 버전 및 설정에 따라 달라질 수 있다는 점이 있습니다.
누가 취약한가요?
이 취약점은 Linux 배포판 대부분이 기본적으로 OpenSSH와 함께 제공되므로 Linux 배포판 대부분을 포함한 여러 버전의 OpenSSH에 영향을 미칩니다.
이 취약점의 근본 원인은 OpenSSH 코드의 회귀이므로 아주 오래된 버전의 OpenSSH 서버는 원래 CVE의 영향을 받으며, 최신 버전(회귀 이전)은 영향을 받지 않습니다.
이 문서의 발행일을 기준으로 이 취약점의 영향을 받는 것으로 알려진 OpenSSH 버전은 다음과 같습니다.
이전 버전의 취약점(CVE-2006-5051)은 OpenSSH 4.4/4.4p1(2006-09-27) 이전의 OpenSSH 버전에 영향을 미칩니다[CVE-2006-5051 및 CVE-2008-4109에 대한 패치가 적용되지 않은 경우].
이 취약점의 회귀는 OpenSSH 8.5/8.5p1 버전(2021-03-03)에서 도입되었습니다.
OpenSSH 유지 관리자가 OpenSSH 9.8/9.8p1 버전(2024-07-01)에서 취약점을 수정했습니다.
영향을 받는 서버를 검색하는 방법으로는 다음 Insight 쿼리를 사용하는 것이 있습니다.
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
Akamai의 관측에 따르면, 네트워크의 75%에서 취약한 버전의 OpenSSH를 사용하는 머신이 일부 있고, 평균적으로 한 특정 네트워크에 있는 머신의 약 35%가 취약한 것으로 나타났습니다. 긍정적인 측면은 Akamai가 모니터링한 환경에서는 아직 인터넷에 임의로 개방된 SSH 포트가 있는 머신을 발견하지 못했다는 점입니다. 하지만 Shodan 에서 빠르게 검색해 보면 취약한 버전으로 접속 가능한 머신이 600만 대가 넘는 것으로 나타났습니다 (그림).
인터넷에 개방된 취약한 머신에 대한 2024년 7월 2일자 Shodan 보고서
발생 가능한 영향
이 취약점은 기본적으로 OpenSSH에 영향을 미치기 때문에 잠재적인 영향은 매우 크며, 회귀로 인해 Linux 배포판 대부분, 특히 최신 버전에 영향을 미칩니다.
하지만 세 가지 주의 사항을 지키면 크게 당황하지 않아도 됩니다.
현재 PoC는 x86 머신에만 해당하며, (현재 표준인) AMD64 머신에서의 악용은 강력한 메모리 보호 기능으로 인해 기하급수적으로 더 복잡합니다.
현재 악용에 성공하려면 오랜 시간과 여러 번의 트리거 연결이 필요한 것으로 간주됩니다. 따라서 무차별 대입 공격 탐지기 대부분을 트리거해야 합니다.
위의 두 가지 주의 사항 때문에 이 공격은 인터넷을 통한 초기 접속 기법으로 더 적합한 것으로 보입니다. 인터넷 SSH 연결과 (점프박스처럼) 인터넷 기반 SSH 인터페이스가 필요한 머신의 트래픽에 적절한 세그멘테이션을 사용하면 그 영향을 일부 방어할 수 있습니다.
방어
패치 적용
가장 확실한 방법은 취약한 버전이 아닌 업데이트된 버전으로 OpenSSH를 패치 적용하는 것입니다. 그러나 OpenSSH는 일반적으로 Linux 배포판과 함께 번들로 제공되므로 패치 적용은 벤더사의 패치 릴리스에 따라 달라지므로 추가적인 시간과 테스트가 필요할 수 있습니다.
네트워크 관리자는 이 블로그 게시물에 제공된 OSQuery를 사용해 취약한 자산을 탐지하고 시간 경과에 따라 추적할 수 있습니다. Akamai Guardicore Segmentation 고객은 이러한 목적으로 예약 쿼리를 사용한 다음 쿼리 결과에 따라 자산에 라벨을 지정할 수도 있습니다.
세그멘테이션
위에서 언급한 바와 같이 이러한 CVE 악용은 네트워크에 대한 초기 침해에 가장 적합하며, 악용에 성공하는 데 며칠은 아니더라도 몇 시간이 걸릴 수 있습니다. 따라서 인터넷 OpenSSH 인터페이스의 모든 인스턴스를 매핑하고 이에 대한 접속을 닫거나 제한해야 합니다.
인터넷에서 임의의 SSH 접속이 필요한 경우, 해당 머신에 네트워크 세그멘테이션을 적용해 내부 네트워크에 대한 접속을 제한하고 악용 및 유출에 성공할 경우 폭발 반경을 제한하는 것이 좋습니다.
위협 알림 민감도
패치가 아직 제공되지 않을 수 있으므로잠재적으로 취약하고 패치가 적용되지 않은 워크로드에 대한 알림 민감도를 높이는 것이 현명할 수 있습니다. 이렇게 하면 취약점이 악용되어 탐지되지 않더라도 그 후유증에 대해 어느 정도 인지할 수 있습니다. 특히 무차별 대입 시도는 악용될 가능성이 가장 높으므로 민감도를 높이는 것이 좋습니다.
그러나 알림 민감도를 높이면 알림 피로도도 높아집니다. 따라서 영향을 받는 워크로드의 네트워크에 대한 중요도나 영향에 따라 알림 민감도를 조정하는 것이 좋습니다.
요약
이 블로그 게시물에서는 최근에 패치 적용되어 공개된 OpenSSH의 중대한 취약점인 regreSSHion에 대한 사용 가능한 정보를 검토했습니다.
보안팀 직원의 경우 네트워크에 있는 워크로드의 취약점을 파악해야 합니다. 취약한 버전의 OpenSSH를 탐지할 수 있는 OSQuery를 제공해 도움을 드리고자 했습니다. 또한 패치를 사용할 수 없는 경우 일부 리스크를 방어하기 위해 해야 할 일(예: 위협 알림 민감도 조정)에 대해서도 논의했습니다.
본 블로그 게시물에서는 이용 가능한 정보를 바탕으로 현재 파악된 정보와 권장 사항을 대략적으로 살펴봤습니다. Akamai의 검토는 지속적으로 수행되므로 이곳의 모든 정보는 변경될 수 있습니다. 또한 X 계정을 방문해 실시간 업데이트를 확인할 수 있습니다.