OpenSSL 3.x 취약점에 대한 효과적인 준비
업데이트(2022년 11월 1일): HTTP 및 HTTPS를 통한 Akamai 콘텐츠 전송은 영향을 받지 않은 OpenSSL 버전을 서버에 사용하므로 이 취약점의 영향을 받지 않습니다. 또한 Akamai 시스템은 이 글에서 설명하는 공격 기법에 대해 방어하는 업계 표준 스택 보호 메커니즘을 활용합니다. Akamai는 영향을 받을 가능성이 있는 내부 시스템에 패치를 적용하고 있지만, 이러한 작업에 의해 고객사의 다운타임이 발생할 것으로 예상하지는 않습니다.
10월 25일, OpenSSL 프로젝트 팀은 OpenSSL 버전 3.x의 심각한 취약점에 대한 보안 수정 패치 소식을 발표 했습니다. 이 패치는 2022년 11월 1일 오후 1:00~오후 5:00(UTC)에 릴리스될 예정입니다.
OpenSSL은 광범위하게 사용되고 있으므로 이번 발표에는 각종 추측이 뒤따랐습니다. 우리는 이 문서를 통해서 각종 잡음을 잠재우고, 추측성 내용 없이 위협을 탐지하고 방어하는 법에 대한 전반적인 지식과 팁을 제공하고자 합니다. 이 게시물의 첫 번째 부분에서는 OpenSSL과 취약점의 범위를 설명합니다. 두 번째 부분에서는 OpenSSL이 애플리케이션에서 어떻게 사용되는지 설명하고 취약한 자산을 탐지할 툴을 제공합니다. 원하시는 경우, 다음 링크를 통해 이러한 유틸리티로 바로 이동하실 수 있습니다.
참고: 이 블로그 게시물은 진화 중인 인시던트를 다루며, 추가 정보 수집 및 수정 패치 릴리스에 따라 업데이트될 예정입니다.
해당 취약점의 범위
OpenSSL 팀이 취약점의 심각도를 위험으로 평가하는 경우는 드물어서 보안 커뮤니티의 우려를 낳았습니다. 해당 취약점의 심각도는 추후 "높음"으로 조정되었습니다. Heartbleed(메모리 누수 및 키 유출 가능성으로 이어지는 취약점)이 발생하고 나서 취약점 레이블이 도입된 이후로 '위험'으로 분류된 추가적인 취약점은 CVE-2016-6309 한 건뿐이었습니다.
OpenSSL 팀의 평가 기준에 따르면, 취약점이 일반적인 설정에 영향을 미치고 악용될 가능성이 있는 경우에 위험 등급이 부여됩니다. 이러한 취약점의 예로는 '서버 메모리 내용의 심각한 노출(사용자 세부 정보를 노출할 가능성이 있음), 원격으로 손쉽게 악용해 서버 비공개 키를 감염시킬 수 있는 취약점 또는 일반적인 상황에서 원격 코드 실행이 가능할 것으로 간주하는 취약점' 등이 있습니다.
OpenSSL 라이브러리가 얼마나 널리 사용되는지를 고려하면, 이 라이브러리의 취약점은 위험할 수 있습니다. 비록 취약점을 경계할 필요는 있지만, 아직 당황할 필요는 없습니다. OpenSSL이 매우 일반적이지만, 가장 널리 보급된 버전은 1.X.X.X이고 이 취약점은 OpenSSL 3.0.0 이상 버전에만 영향을 미칩니다 (2021년 9월에만 릴리스). 따라서 취약점은 아마도 OpenSSL 라이브러리 자체의 유통에 비하면 덜 널리 퍼져 있을 겁니다.
일부 매니지드 네트워크에서 탐지 툴을 실행했으며 다음 사항을 파악했습니다.
모니터링 대상 환경의 약 50%에 최소 한 대의 컴퓨터가 취약한 버전의 OpenSSL에 의존하는 프로세스를 한 개 이상 갖고 있습니다.
해당 네트워크 중 취약한 OpenSSL 버전에 어느 정도 의존하는 컴퓨터가 차지하는 비율은 0.2%~33%입니다.
중앙값의 범위는 6.1% 이고 평균은 11.3% 이며 표준 편차는 11.6%입니다.
이 통계는 취약점에 해당이 없는 OpenSSL 사용은 반영하지 않았습니다. 유일한 지표는 취약한 버전의 OpenSSL(3.0–3.6)에 의존하는 프로세스가 하나 이상 있는 컴퓨터입니다. 같은 컴퓨터에서 실행되는 다른 프로세스도 고려하지 않았습니다.
OpenSSL이란?
OpenSSL은 오픈 소스 소프트웨어 툴킷이므로 OpenSSL 릴리스는 기본적으로 소스 코드 릴리스입니다. 공격 탐지 측면에서 보면 이는 애플리케이션이 OpenSSL을 로딩하거나 OpenSSL에 의존할 방법이 매우 많아 취약점의 위험도가 높아진다는 것을 의미합니다.
먼저, OpenSSL의 세 가지 구성요소를 정의해야 합니다.
libcrypto - 여러 프로토콜(AES, RSA, ChaCha 등)을 구축한 암호화 라이브러리
libssl - TLSv1.3까지의 모든 TLS 프로토콜을 구축한 라이브러리
OpenSSL - 다양한 작업(인증서 생성 등)에 사용하는 명령줄 유틸리티
애플리케이션이 OpenSSL에 의존하려면 libcrypto 또는 libssl 둘 중 하나의 코드 로직을 호출해야 합니다 (OpenSSL 은 그 자체로 이 두 가지에 의존하는 애플리케이션).
OpenSSL 취약점 방어
OpenSSL 위협에 대한 방어 첫 단계는 취약한 자산을 탐지하는 것입니다. 비록 이 조언이 흔히 주어지지만, 실제 실행 방법을 함께 가르쳐주는 경우는 드뭅니다. 알려진 취약한 응용 프로그램 목록(아래 참조)과 네트워크 내 취약한 애플리케이션을 찾을 수 있는 일반적인 방법을 알려드립니다.
세그멘테이션 - 패치 전 및 패치 후 방어
OpenSSL에 대한 대부분의 의존도는 벤더사의 소프트웨어(패치를 직접 적용해야 함)에서 비롯되므로 패치를 즉시 적용하는 것이 어렵더라도 여전히 탐지를 통해 얻을 수 있는 가시성을 활용할 수 있습니다. 세그멘테이션과 라우팅을 사용해 공격자가 취약점을 악용해 영향을 미칠 수 있는 범위를 축소할 수 있습니다.
우리는 (더 엄격한) DMZ의 형태로 인터넷 기반 자산에 대해 추가적인 제한을 가할 수 있습니다.
도메인 전반에 걸쳐 더 많은 세그멘테이션을 생성해 침입이 발생한 내부 컴퓨터가 전체 네트워크로 전파하는 데 사용되지 못하게 할 수 있습니다. 이 기능은 취약한 컴퓨터의 공격표면이 실제로 통신해야 하는 네트워크의 일부에 국한되도록 줄이는 데도 사용할 수 있습니다.
또한 이러한 가시성과 탐지를 활용해 패치 작업 계획을 작성하고 실수로 일정 단계를 건너뛰는 일이 발생하지 않도록 할 수 있습니다. 패치가 릴리스되고 패치 프로세스가 완료된 후, 탐지 로직을 다시 실행해 결과를 비교할 수 있습니다. 가장 이상적인 것은 취약한 컴퓨터가 없는 것입니다.
잘 알려진 애플리케이션 중 취약한 애플리케이션
BoringSSL(Google Chrome에서 사용)과 LibreSSL 은 OpenSSL 코드를 기반으로 하지만 향후 취약점에 아직 영향을 받지 않은 두 개의 라이브러리입니다.
다양한 Linux 배포판이 OpenSSL 라이브러리와 함께 제공되는 경우가 많습니다. Linux 환경을 실행하는 경우, 취약한 OpenSSL과 함께 제공되는 다음 버전 중 하나를 사용하고 있는지 확인하시는 것을 추천합니다.
Red Hat Enterprise Linux 9
Ubuntu 22.04+
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
목록에 없는 Linux 배포판을 사용하고 있다고 해서 취약점에서 오는 위험으로부터 안전하다고 확신할 수 없습니다. 예를 들어 패키지 매니저의 업그레이드 명령에 따라 라이브러리를 직접 업데이트한 경우, 취약한 상태에 있게 됩니다. 터미널에 'openssl version'을 입력해 라이브러리 버전을 아웃풋할 수 있습니다.
Docker 또한 다가오는 릴리스에 대한 권고를 발행 해 다양한 Docker Official Images 및 Docker Verified Publisher 이미지 전반에 걸쳐 약 1000개의 이미지 저장소가 영향을 받을 수 있을 것으로 추정된다고 알렸습니다. 여기에는 위에서 언급한 Linux 배포판의 변형에 기반한 이미지가 포함됩니다.
일부 프레임워크도 영향을 받을 수 있습니다. Node.js v18.x과 v19.x는 OpenSSL 3을 사용하므로 이 취약점의 영향을 받는 것으로 간주합니다. Node.js는 새로운 업데이트가 있을 시 다음 블로그 게시물에서발표할 것입니다.
개발자를 깜짝 놀라게 한 또 다른 프로그래밍 언어는 Golang입니다. Go 바이너리의 라이브러리는 정적으로 연결되어 있으므로 Go 개발자가 소프트웨어를 다시 컴파일해야 하는 상황이 발생할 수도 있습니다. Golang 팀에서 다가오는 OpenSSL 패치와 같은 날짜에 보안 수정 패치를 포함한 새로운 부 릴리스를 발표하자, 사람들은 두 가지를 연결해서 생각해 둘 사이에 연관이 있을 것으로 추측했습니다. 걱정하지 않으셔도 됩니다. 공연한 소동이기 때문입니다. Golang의 릴리스는 향후 취약점과 무관합니다.
취약한 애플리케이션 목록은 앞으로 며칠간 길어질 것으로 예상되며, 이에 따라 이 게시물을 업데이트할 예정입니다. 다음 섹션에서는 여러분의 환경에서 OpenSSL 3을 사용해 취약한 애플리케이션을 파악하는 데 유용한 탐지 방법과 툴을 제공합니다. 원하시는 경우, 탐지 메커니즘으로 바로 넘어가셔도 됩니다.
OpenSSL 3을 사용하는 애플리케이션을 탐지하는 일반적인 방법
참고: 이 섹션에서는 애플리케이션이 OpenSSL을 사용하는 방법에 대한 내부 세부 정보를 제공합니다. 탐지 방법에만 관심이 있으신 경우, 바로 YARA 룰 또는 OSQuery 쿼리를.
OpenSSL은 정적 및 동적으로 애플리케이션에 연결할 수 있습니다. 정적 연결을 사용하면 OpenSSL의 소스 코드가 애플리케이션 코드의 일부로 포함되며, 두 소스 코드는 함께 동일한 바이너리로 컴파일됩니다. 동적 연결을 사용하면 OpenSSL은 공유 라이브러리(Windows의 경우 libssl.dll과 libcrypto.dll, Linux의 경우 libssl.so와 libcrypto.so)에 개별적으로 컴파일됩니다. 그런 다음 애플리케이션 코드는 공유 라이브러리에 대한 참조를 가지며, 이 참조는 운영 체제가 애플리케이션을 로딩하면서 해결됩니다.
이는 탐지에서는 어떻게 활용될까요? 사실상 정적으로 컴파일된 바이너리를 탐지하는 방법만으로도 충분합니다. 왜 그럴까요? 실행 중인 애플리케이션이 OpenSSL을 동적으로 로딩하거나 라이브러리를 동적으로 로딩해 그 라이브러리가 OpenSSL 등을 동적으로 로딩하더라도, 결과적으로는 정적으로 컴파일된 OpenSSL 라이브러리가 일부 로딩되기 때문입니다. 모든 동적 로딩은 동일한 프로세스의 맥락에서 발생하므로, 각 프로세스에 로딩된 라이브러리 목록을 확인해 정적으로 컴파일된 라이브러리를 찾기만 하면 됩니다.
따라서 정적으로 컴파일된 OpenSSL이 어떤 모습인지를 파악해야 할 겁니다. 다행히도 이는 매우 간단합니다. OpenSSL의 모든 정적 컴파일은 OpenSSL 3.0.6 11 Oct 2022와 같은 버전 문자열을 포함하며이 중 3.0.6은 버전 번호입니다. 이 문자열은 Regex나 YARA를 사용해 매우 간단히 탐지할 수 있습니다.
그러나 이 방법이 완벽하지 않을 수도 있습니다. OpenSSL은 오픈 소스 코드이기 때문에 사용자는 요구사항에 따라 버전 관리 로직을 쉽게 변경할 수 있습니다(따라서 탐지에서 누락될 수 있음). 이 문제가 확인된 경우는 단 한 번이지만(Cisco에서는 대신 다음 문자열 CiscoSSL 1.1.1k.7.2.225 를 사용함), 다른 벤더사에도 위 문제가 발생할 수 있습니다.
지금 하면 좋을 일
수정 패치가 릴리스되기 전까지는 알 수 있는 것이 많지 않지만, 패치에 대비하기 위해 보안팀이 선제적으로 할 수 있는 몇 가지 작업이 있습니다. Akamai 팀에서는 가시성과 방어 용이성을 위해 고객 환경에서 실행하면 좋을 몇 가지 유틸리티를 개발했습니다. Insight 기능을 지원하는 Akamai Guardicore Segmentation 고객은 고객사 환경에서 이 로직을 손쉽게 실행할 수 있습니다.
YARA
여기에 적어둔 기본 룰은 위에서 언급한 문자열에 대한 것입니다. 간결성을 위해 이번 릴리스로 영향을 받는 실제 OpenSSL 버전으로만 탐지를 제한할 것이나, 이 기준은 쉽게 수정할 수 있습니다.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
이 문자열에 의존하지 않으려는 경우, OpenSSL에 의존하나 실행 파일이 불러온 내용을 구문 분석하는 주된 애플리케이션을 찾아도 됩니다. 그러나 이 방법은 덜 확실한 방법이므로, 그에 걸맞게 취급해야 합니다.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
위 쿼리를 사용하면 osquery의 YARA 테이블을 활용해 실행 중인 모든 프로세스에 해당 룰을 실행할 수도 있습니다.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
물론 앞서 언급한 다른 YARA 룰을 추가하거나 필터를 추가하거나 제거해 확인할 파일의 규모를 줄이거나 확장할 수도 있습니다.
요약
OpenSSL 팀은 보안팀에 향후 출시될 수정 패치 릴리스를 알리는 특이한 접근 방식을 도입했습니다. 보안팀은 이 공지를 통해 패치를 기다리고 있는 중요한 자산을 준비하고 매핑할 시간을 확보했습니다. 이 블로그 게시물은 바로 이 작업, 즉 패치일에 대처가 필요한 애플리케이션과 자산을 파악하는 작업을 수행하는 것을 지원하기 위해 작성되었습니다.
이는 계속 진행 중인 사건이므로, 새로운 정보가 공개되면 이 블로그 게시물을 업데이트할 예정입니다. 따라서 새로운 소식을 접하기 위해서 다시 게시물을 확인하시기 바랍니다. Twitter에서 Akamai를 팔로우해 실시간 업데이트를 받는 방법도 있습니다.
