버그 보고서 - 2022년 1월

저자: Kevin McGrath · 2022년 2월 2일

사이버 보안 코믹 릴리프

여긴 어디죠?

오미크론(Omicron)은 그리스 알파벳의 15번째 문자이고, 프톨레마이오스의 Almagest에서 0으로 표시되는 Big-O 표기법을 나타내기 위해 Donald Knuth가 사용했고, isopsephy의 실행에서 70의 값을 가졌습니다. 그러나 대부분의 사람에게 그것은 결코 쉽게 끝나지 않을 팬데믹을 나타냅니다. 잠깐만요. 2022년 1월에 가장 많이 언급된 단어에 대한 철학적인 배경에는 관심이 없다고요? 정말로 취약성에 대해 읽으려고 여기에 오셨다고요? 그렇지만, 그렇지만요... 됐어요, 신경 쓰지 마세요. 1월 버그 보고서: Surge 에디션에 오신 것을 환영합니다.

• CVE-2022-0185: Java 개발자들만 입력 유효성 검사를 잊어버리는 것은 아니기 때문입니다!
• CVE-2021-42392: 뭐라고요? Log4Shell이 사라질 거라고 생각하셨나요?
• CVE-2022-21907: 작은 벌레(worm), 당신을 잊지 않았습니다.
• CVE-2021-4034: PwnKit, sudo가 충분하지 않다고 판단하면 무슨 일이 생기나요?

CVE-2022-21907: HTTP.sys 웜 가능한 버그

이게 뭐죠?

2022년 1월 패치 화요일, Microsoft는 HTTP.sys 커널 드라이버의 웜 가능한 취약성으로 새해를 맞이했습니다. 이것은 7개월 동안 HTTP.sys에서 발견된 두 번째 웜 가능한 취약성입니다. 이 드라이버의 코드 성숙도를 고려할 때 이는 매우 인상적입니다. CVE-2021-31166은 인터넷을 폭파하지 않았고, 21907도 그러지 않기를 바랍니다! '21907은 '31166의 불완전한 수정을 활용하여 HTTP 트레일러 지원(청크된 메시지 끝에 있는 메타데이터)을 활용합니다. 이 익스플로잇이 최종 청크에 있는 TRAILER 헤더의 존재 여부에 의존하는지 여부는 불분명합니다. RFC는 이를 OPTIONAL로 표시합니다. 이것은 TRAILER 헤더에 의존할 수 없는 네트워크 제품 시그니처 작성자에게 잠재적으로 문제가 됩니다.

재미있는 사실: 이를 위해 PoC가 GitHub에 있습니다!

또 다른 재미있는 사실: 현장에서 악용이 관찰되기 시작합니다! 현재 위협에 대한 최신 정보를 받아보려면 McAfee Insights를 반드시 살펴봐야 합니다!

IIS만 HTTP.sys를 사용하는 것이 그럴듯하게 보일 수 있지만 실제로는 그렇지 않습니다. HTTP.sys는 핵심 HTTP 처리 코드를 제공하는 커널 드라이버입니다. 다른 하위 시스템은 이 코드를 사용합니다.

• ADFS
• WinRM
• Intel Support Assistant

다음을 통해 드라이버를 활용하는 서비스를 확인할 수 있습니다.

PS > netsh http show servicestate

이를 실행하면 현재 시스템에서 실행 중인 요청 대기열 및 연결된 URL이 나열됩니다.

다행히 Server 2019 또는 Windows 10 1809 버전 이후로 업데이트하지 않은 경우, 레지스트리에서 트레일러 지원을 활성화하지만 않았다면 문제가 없으실 겁니다.

그게 나와 상관이 있나요?

240만 명의 Twitter 사용자. 환경에서 IIS를 실행하는 사용자. Docusign을 사용하는 사용자(특히 팬데믹 기간에 Docusign을 통해 진행되는 법적 구속력이 있는 계약의 수를 고려할 때 이는 상당한 양입니다). 최근 시장 보고서에 따르면 인터넷 사이트의 약 7%가 IIS를 사용합니다. Microsoft조차도 인터넷 대면 시스템이 많지 않습니다. 즉, MS 외에도 IIS를 사용하는 사이트가 많습니다. 기본적으로 취약한 Windows 버전:

• Windows 10 2004 이상(ARM과 x64 모두)
• Windows Server 20H2 이상

내가 무엇을 할 수 있을까요?

패치죠! Microsoft는 발표와 함께 이 취약성에 대한 패치를 릴리스했습니다. 패치가 가능하지 않다면, 인터넷 대면 역할에서 해당 시스템을 제거하는 것이 가장 좋습니다. 아쉽게도 현재 버전의 Windows에는 사용 가능한 호스트 기반 완화 기능이 없습니다.

Windows Server 1909 또는 Windows 10 1809를 실행하는 경우 기본적으로 취약하지 않습니다. 취약성 상태를 확인하려면 다음을 실행하십시오.

PS > Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

값이 반환되고 0이 아닌 경우 시스템이 취약한 것입니다. 이를 완화하려면 다음을 실행하십시오.

PS > Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" -name EnableTrailerSupport -Value 0

아니면 단순히 해당 레지스트리 키를 삭제하십시오.

최적의 표준

좋은 소식은 사용 가능한 패치가 있다는 것입니다. 패치를 적용하십시오. 어떤 이유로든 패치를 적용할 수 없는 경우 너무 걱정하지 마십시오. Trellix는 이 취약성에 대한 NSP(Network Security Platform) 시그니처를 제공합니다. 그러니 최소한 시그니처 데이터베이스를 업데이트했는지 확인하십시오!

CVE-2021-42392: 이 Log4Shell 작업에 관여하려는 H2

이게 뭐죠?

JNDI 원격 클래스 로딩 처리에서 Log4Shell과 유사한 취약성. 이것은 Log4j에 있는 버그를 활용하지 않지만(Log4j는 필요하지도 않음) 동일한 기본 기술(JNDI)을 활용합니다. 데이터베이스에 대한 접근을 관리하는 공격자가 제어하는 모든 URL(비록 사용자가 입력을 삭제했더라도)은 H2 RDBMS 컨텍스트에서 원격 코드 실행을 얻을 수 있습니다. 그러나 물론 데이터베이스에 대한 모든 쿼리가 삭제되고 매개 변수화되고 저장되기 때문에 그런 일이 발생하지 않습니다. 이는 분명합니다.

그게 나와 상관이 있나요?

일각에서는 거의 7,000개 프로젝트에서 Log4j를 포함하여 H2를 사용하는 것으로 추정합니다. 아하, Log4j가 정말 별 문제가 있기나 한 건지 궁금하실 수도 있으시겠네요. Log4Shell이 이름만 바꾼다면 Log4j 사용자보다 더 오래도록 살아남을 수도 있습니다. 자연은 언제나 방법을 찾아내기 마련이죠…

내가 무엇을 할 수 있을까요?

H2 데이터베이스 버전 1.1.100부터 2.0.204까지 영향을 받습니다. 2022년 1월 5일에 출시된 버전 2.0.206에서는 이 취약성을 교정합니다. 적어도 버전 2.0.206으로 업데이트하는 것이 가장 좋습니다.

데이터베이스 엔진을 전환할 수 있지만 이는 오히려 극단적인 솔루션으로 보입니다. 숙주를 죽여서 질병을 치료하는 것은 의학계에서는 물론 IT에서도 권장되는 방식이 아닙니다.

Java 사용을 중단할 수도 있지 않을까요? 아까 말한 경우와도 유사해 보이지만, 이 경우에는 타당한 방법입니다. 사실, 이거야말로 분명히 최고의 해결책입니다. Java는 서버가 아닌 커피잔에 속합니다.

최적의 표준

패치 적용, 모든 Java 코드를 스크랩하고 다른 언어로 전환, 데이터베이스 엔진 교체 등이 불가능한 경우 익스플로잇 자체가 Log4Shell과 매우 유사해 보이기 때문에 Trellix가 해결해 드립니다.

Trellix 고객은 다각도로 보호됩니다(자세히 알아보려면 이 기술 자료 문서를 참조하십시오).

• 이 블로그에 설명된 대로 ENS(Endpoint Security)에 대한 전문가 규칙은 메모리에서 위험한 패턴을 골라낼 수 있습니다.
• ENS(Endpoint Security), VSE(VirusScan Enterprise), MWG(McAfee Web Gateway)는 ‘잠재적으로 원하지 않는 소프트웨어’ 탐지를 통해 타일 Exploit-CVE-2021-44228.C에서 일반 탐지를 제공할 수 있습니다. 이 탐지는 또한 이 취약성을 악용하는 현장(in-the-wild) 캠페인과 관련된 샘플의 해시 목록에 의해 보완됩니다.
• NSP(Network Security Platform)는 사용자 정의 시그니처를 통해 공격을 탐지할 수도 있습니다(이전에 링크된 기술 자료 문서에서 제공).
• RTS(Real-Time Search) 쿼리로 취약한 시스템을 찾는 데 MVISION EDR(Endpoint Detection and Response), MAR(McAfee Active Response)도 사용할 수 있습니다.
• McAfee SIEM은 잠재적인 익스플로잇 시도에 대해 경보를 알리는 업데이트(Exploit Content Pack 버전 4.1.0)를 받았습니다.

CVE-2022-0185: Linux 커널 네임스페이스 언더플…

이게 뭐죠?

표면적으로 CVE-2022-0185는 레거시 코드 경로의 단순한 정수 언더플로입니다. 모든 컨테이너 사용자에게 다행히도 해당 레거시 코드 경로는 FSC(File System Context)에 있습니다. FSC가 FCAPI(File Context API)로 대체되는 동안 취약한 경로를 포함하여 이전 버전과의 호환성을 지원하기 위해 일부 기능은 유지되었습니다. 정수 언더플로는 컨테이너 프로세스 자체의 컨텍스트에서 공격자에 대한 무한 쓰기를 생성합니다. 컨테이너에 대한 액세스 권한이 있는 공격자는 이 결함을 활용해 기본 호스트를 공격하여, 이 노드에서 실행 중인 다른 모든 컨테이너에 대한 액세스 권한을 얻을 수 있습니다. k8s(Kubernetes)와 같은 도구가 얼마나 인기가 있었는지를 고려해보면, 신뢰할 수 없는 사용자가 있는 상태에서 프로세스 격리를 위해 컨테이너를 사용하는 모든 사용자는 잠재적으로 우려되는 상황입니다. 이 문제는 권한 없는 네임스페이스를 사용하는 컨테이너, unshare 명령을 허용하는 컨테이너 또는 CAP_SYS_ADMIN 권한(기본적으로 꺼짐)이 있는 컨테이너에만 영향을 미칩니다. unshare 명령은 seccomp 필터에 의해 Docker 컨테이너에서 기본적으로 차단됩니다. k8s 사용자에게는 아쉽게도, seccomp 필터는 기본적으로 켜져 있지 않으므로 Kubernetes 클러스터는 위험한 상태입니다.

과거는 진보의 목에 두른 교수형틀과 같아서, 이 세상의 모든 좋은 것들로부터 삶을 서서히 질식시킵니다. 다시 말해, 이전 버전과의 호환성은 종종 우리가 좋은 것을 가질 수 없는 이유입니다.

그게 나와 상관이 있나요?

컨테이너를 실행하는 모든 사용자에게는 상관이 있을 수도 있습니다. 실제로 실행하지는 않지만 사용자가 실행하도록 허용하는 관리자도 마찬가지입니다. 그리고 남은 음식을 보관하기 위해 컨테이너를 사용하는 사람... 농담은 여기까지만 하겠습니다. 최소한 공유 서버에서 컨테이너를 실행하는 사용자는 이에 대해 매우 우려해야 하며, 기본 커널이 업데이트되었음을 확인할 때까지 해당 서버에서 업무상 중요한 모든 것을 잠재적으로 제거할 수 있습니다.

작성자는 이 취약성에 대한 자세한 블로그를 작성하고 PoC 코드를 릴리스했습니다. 따라서 이 시점에서는 악의적인 행위자가 이를 무기화하는 것이 시간문제일 뿐이므로 우리 모두 주의해야 합니다.

내가 무엇을 할 수 있을까요?

호스트를 제어하는 경우 커널을 업데이트해야 합니다. 그렇게 할 수 없는 경우(또는 소유자가 거부하는 경우) 다음을 실행하십시오.

# sysctl -w kernel.unprivileged_userns_clone = 0

그러면 이 취약성은 CAP_SYS_ADMIN 권한이 있는 컨테이너로만 제한됩니다. 컨테이너에서 해당 권한을 제거하면 이 취약성도 완화됩니다(기본적으로 꺼져 있음).

컨테이너를 실행하지 않는 시스템에 대한 RedHat 권장 사항은 단순히 네임스페이스를 완전히 비활성화하는 것입니다.

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf # sysctl -p /etc/sysctl.d/userns.conf

또한 이렇게 하면 호스트가 컨테이너를 실행할 수 없게 됩니다. 사용 중이 아닌 경우라도 이는 아무튼 좋은 생각일 수 있습니다.

최적의 표준

이 시점에서는 패치 또는 완화 적용이 최선의 선택입니다. 컨테이너는 격리 메커니즘으로 사용되기 때문에 실행 중인 컨테이너를 볼 수 있는 외부 프로세스는 거의 없습니다. 패치가 적용된 호스트에서 실행하거나 k8s에서 seccomp 필터를 활성화해야 합니다.

CVE-2021-4034: PwnKit

이게 뭐죠?

PwnKit라는 애칭으로 알려진 CVE-2021-4034는 PolKit(이전의 PolicyKit)의 논리 버그를 활용합니다. PolKit는 권한 없는 프로세스에 권한 있는 프로세스에 대한 안전한(또는 그렇게 믿었던) 액세스를 제공하는 시스템 전반의 정책 관리 키트입니다. 버그는 특히 도구 pkexec에 존재합니다(어떤 이유로 sudo가 충분하지 않았으므로 우리는 정확히 sudo와 동일한 작업을 수행할 또 다른 setuid 프로그램의 필요성을 느꼈습니다). argc 변수가 적어도 1이라고 가정합니다. 일반적인 프로그램 호출에서 이것은 분명히 사실입니다. 거의 모두가 침투를 나타내고 런타임에서 거부되겠지만 방법은 있습니다.

일반적으로 pkexec를 사용할 때 자격 증명을 요구하는 팝업 창이 나타납니다. 이 취약성은 자격 증명 확인을 우회하고 루트로서 실행됩니다. 실패를 다루는 방법은 왕국에 키를 넘겨주고 등을 두드려주는 것입니다.

이는 6개월 만에 나타난 두 번째 polkit 취약성입니다. CVE-2021-3560 역시 dbus 메커니즘을 사용해 자격 증명 확인을 우회하여 polkit를 호출했습니다. 둘 다 동일한 루트 결함을 활용한 것 같습니다. 주제로 돌아가서, 근본 원인은 2013년에 처음 보고되었지만 작성자는 악용의 직접적인 경로를 보지 못했습니다. 그래서 패치는 버려진 상태에서 빛이 바랜 채 빛날 날을 기다리고 있었습니다. 드디어 9년 만에 패치가 빛을 발하게 되었습니다. 이제 그 빛을 누리면 됩니다.

그게 나와 상관이 있나요?

이것이 작년의 가장 큰 로컬 권한 상승 버그가 아니라고 주장하기는 어려울 것입니다. 이 취약성은 오래된 polkit 이진을 실행하는 대부분의 주요 Linux 배포판에서 작동하므로 1월 25일 이후 패치되지 않은 Linux를 실행하는 경우 모두 취약합니다. Debian이 자체 포크를 유지 관리하기 때문에 polkit의 버전 번호는 약간 불안정하지만, 다음을 실행 중인 경우

• Ubuntu 20.04(LTS)에서 0.105-26ubuntu1.2 미만
• Ubuntu 21.10에서 0.105-31ubuntu0.1 미만
• Debian bullseye에서 0.105-31+deb11u1 미만
• RHEL(RedHat Enterprise Linux) 8.4 EUS에서 polkit-0.115-11.el8_4.2 미만

취약한 상태입니다. 다시 말하지만, 1월 25일 이후에 패치를 적용하지 않은 경우 취약합니다. 현장에 PoC 코드도 있으므로, 머지않아 적극적으로 악용될 것입니다.

또는 모든 사용자를 신뢰하시나요? In that case, you have nothing to worry about. Compromised accounts are readily available. 피싱이나 크래킹, 동일한 자격 증명을 공유하는 다른 곳의 손상된 계정, 아니면 기타 다른 계정 손상 등 원인이 무엇이든 사용자를 신뢰한다는 것이 사용자 계정을 신뢰한다는 것은 아닙니다.

이 버그는 Linux에서 발견되었지만 BSD를 포함한 다른 UNIX 배포판에서는 polkit를 사용합니다. OpenBSD는 최소한 이에 대한 완화 조치를 취했으므로, argc가 0인 프로그램 실행을 거부합니다. Solaris도 polkit를 사용하지만 Oracle은 Solaris에 대해 너무 비밀스러워 보안 게시판도 유료로 운영합니다. 분명히 그것이 고객을 유지하는 가장 좋은 방법이기 때문입니다!

내가 무엇을 할 수 있을까요?

업데이트입니다! 패치는 모든 주요 Linux 공급업체에서 구할 수 있으며 반드시 적용해야 합니다. 재부팅은 필요하지 않습니다. 패치하지 않기로 한 경우 pkexec에서 setuid 비트를 제거할 수 있습니다.

# chmod 0755 /usr/bin/pkexec

아쉽게도 이렇게 하면 pkexec가 의도한 작업을 수행할 수 없게 됩니다. 그러나 그것이 피해를 입는 것보다는 나을 것입니다.

RedHat의 보안 게시판에는 특정 RHEL 완화 가이드가 있습니다.

최적의 표준

이것은 모든 Linux 배포판에서 조정된 릴리스였으므로 실제로 적용해야 합니다. 비정상적인 로그인 시작점은 다른 형식의 인증 없이 기록되고, 플래그 지정되고, 차단되어야 한다는 점을 강조할 필요가 있습니다. 다단계 인증을 사용하고 계신가요? MFA는 비 내부자의 악용 위협을 막을 수 있습니다. 이들이 시스템에 액세스할 수 없기 때문입니다. 내부자 위협에 대해서는 독자를 위한 연습으로 남겨둡니다.