- 개인 또는 기업이 별도의 하드웨어나 서비스 구비 없이 로컬에서 LLM을 구동할 수 있게 해 주는 오픈소스 애플리케이션
2. 주요내용
- 인터넷에 노출된 Ollama 프레임워크에서 6개의 보안 취약점이 발견 [2] > 익스플로잇에 성공할 경우 DDoS, 인공지능 모델 감염, 인공지능 모델 탈취가 가능
> 4개의 취약점에 대한 보안 업데이트 발표
> 2개의 취약점은 Ollama 유지보수 팀이 취약점으로 인정하지 않아 CVE 번호가 할당되지 않음
※ CVE가 할당되지 않은 2개의 취약점은 패치 또한 제공되지 않음 : 엔드포인트를 노출시키지 않는것이 기본이며, 이 기본이 지켜지지 않는다는 가정 하에 연구된 취약점이므로 취약점으로 볼 수 없다는 입장
2.1 CVE-2024-39720
[사진 1] CVE-2024-39720 [3]
- 취약한 버전 Ollama에서 발생하는 서비스 거부 취약점
> 두 개의 HTTP 요청을 사용해 세그먼테이션 오류(SIGSEGV)를 발생시켜 서비스 거부를 유도
영향받는 버전: Ollama <= 0.1.45
- 공격자는 잘못된 형식의 GGUF 파일을 전송하여 서버나 애플리케이션이 이를 처리하는 과정에 예상치 못한 동작을 유도
GGUF [4]
- Georgi Gerganov Unified Format - 오픈 소스 파일 형식으로, AI 모델 파일과 관련 데이터를 효율적으로 저장 및 교환하기 위해 개발된 파일 형식 ① 범용성 > 기존의 모델 저장 방식들은 특정 프레임워크나 라이브러리에 종속 > 다른 환경 또는 플랫폼에서 사용하려면 별도의 변환 작업이 필요함 > 다양한 유형의 모델 파일과 메타데이터를 한 곳에 통합할 수 있어 변환 없이 여러 플랫폼에서 사용할 수 있음 ② 경량 데이터 저장 > 데이터를 압축 및 최적화하여 모델 파일 크기를 최소화하고, 메모리 사용량을 줄임 > 로컬 환경 처럼 메모리 제한이 있는 장치에서 AI 모델을 실행할 때 성능 및 효율성을 높임 ③ 확장성 > 파일 내 모델의 가중치(Weight) 텐서 값들과 메타데이터(모델의 구조, 버전, 텐서 개수 등)가 Key-Value 형식으로 저장 > 새 메타데이터나 추가 정보를 쉽게 저장할 수 있어 확장성을 높임 ④ 다양한 양자화 지원 > 양자화란 모델의 가중치를 더 낮은 비트 정밀도로 변환하는 기술로, 16-bit 부동 소수점, 8-bit, 6-bit, 5-bit, 4-bit, 3-bit, 2-bit 지원 > 모델을 더 작게 만들어 추론 속도를 높이고, 메모리 사용을 줄임
- GGUF 파일은 0x47 0x47 0x55 0x46(GGUF)로 시작하는 헤더와 그 뒤 파일의 구조에 맞는 추가 데이터를 포함
> 공격자는 4Byte(헤더) 데이터만 가지는 GGUF 파일을 생성해 서버에 업로드
[사진 2] GGUF 파일 구조 [4]
- 공격자는 잘못된 GGUF 파일 업로드를 위해 두 개의 HTTP 요청을 사용
> 먼저, 잘못된 GGUF 파일 업로드를 위한 첫 번째 HTTP 요청 전송
> /api/create URL로 잘못된 GGUF 파일을 참조하도록Modelfile 내 FROM 명령문을 사용한두 번째 HTTP 요청 전송
Modelfile [5]
- 모델의 설정과 명령을 정의한 파일 > 사용할 모델, 템플릿 형태, 파라미터 등을 지정해 모델을 지정할 수 있는 파일 ① FROM(필수) : 사용할 기본 모델 정의 ② PARAMETER : Ollama가 모델을 실행하는 방법에 대한 매개변수를 설정 ③ TEMPLATE : 모델에 전송할 전체 프롬프트 템플릿 ④ SYSTEM : 템플릿에 설정될 시스템 메시지를 지정 ⑤ ADAPTER : 모델에 적용할 (Q)LoRA 어댑터를 정의 ⑥ LICENSE : 법적 라이센스를 지정 ⑦ MESSAGE : 메시지 기록을 지정
- CreateModel은 업로드된 파일을 기반으로 새로운 모델을 생성하거나 로드하는 기능
> 이 과정에서 GGUF 파일과 Modelfile을 로드 및 검증 없이 실행을 시도하여 얘기지 못한 메모리 참조가 발생
> 메모리 접근 위반으로 세그멘테이션 오류(Segmentation Fault)가 발생, 시스템은 SIGSEGV 신호 수신 및 프로세스 중단
2.2 CVE-2024-39722
[사진 3] CVE-2024-39722 [6]
- 취약한 버전 Ollama에서 발생하는 파일 존재 여부 공개 취약점
> /api/push 엔드포인트를 존재하지 않는 경로 매개변수를 통해 호출할 때 발생
> 이스케이프된 URI를 공격자에게 응답으로 반환 > 이로 인해 서버에 존재하는 파일 및 디렉터리 정보가 노출되어, 공격자가 추가로 시스템을 탐색 또는 악용할 수 있음
영향받는 버전: Ollama <= 0.1.45
[사진 4] Exploit 예시 및 서버 응답
2.3 CVE-2024-39719
[사진 5] CVE-2024-39719 [7]
- 취약한 버전 Ollama에서 발생하는 파일 존재 여부 공개 취약점
영향받는 버전: Ollama 0.3.14
- /api/create 엔드포인트를 존재하지 않는 경로 매개변수를 통해 호출하여응답(오류)을 통해존재 유무 확인
[사진 5] Exploit 예시
구분
설명
파일이 존재하지 않는 경우
요청 : ~/ curl "hxxp://localhost:11434/api/create" -d '{"name": "file-leak-existence","path": "/tmp/non-existing"}' 응답 : {"error":"error reading modelfile: open /tmp/non-existing: no such file or directory"}%
파일이 존재하는 경우
요청 : ~/ curl hxxp://localhost:11434/api/create -d '{"name": "file-leak-existence","path": "/etc/passwd"}' 응답 : {"error":"command must be one of \"from\", \"license\", \"template\", \"system\", \"adapter\", \"parameter\", or \"message\""}%
파일 경로 대신 디렉터리 사용
요청 : ~/ curl hxxp://localhost:11434/api/create -d '{"name": "file-leak-existence","path": "/etc"}' 응답 : {"error":"read /etc: is a directory"}%
2.4 CVE-2024-39721
[사진 6] CVE-2024-39721 [8]
- 취약한 버전 Ollama에서 발생하는 서비스 거부 취약점
영향받는 버전: Ollama <= 0.1.33
- CreateModelHandler 함수는 os.Open을 사용하여 완료될 때까지 파일을 읽음
> req.Path 사용자 지정 매개변수를 사용하며, /dev/random으로 설정할 수 있음
> 매개변수 값이 /dev/random일 경우 난수를 생성할 엔트로피를 모을 때까지 차단이 발생
> 해당 파일을 열고 읽기 시도한 고루틴은 엔트로피가 충분히 쌓이기를 기다리면서 계속 차단
> 클라이언트가 요청을 취소해도 고루틴은 멈추지 않고 무한히 실행
[사진 7] 예제 Payload 및 PoC
2.5 모델 중독 (CWE-668)
- 기본 설정을 사용하는 Ollama 서버의 경우 /api/pull 경로에 대한 인증 절차가 없음
> 즉, 누구나 인증 없이 해당 API를 호출 가능한 상태
> 공격자는 클라이언트가 자신이 제어하는 서버에서 악의적인 모델을 다운로드하도록 유도할 수 있음
> 해당 API를 지속적으로 호출하여 디스크가 가득 찰 때까지 모델을 다운로드하게 되어 서비스 거부로 이어질 수 있음
[사진 8] 예제 Payload
2.6 모델 도용 (CWE-285)
-기본 설정을 사용하는 Ollama 서버의 경우 /api/push 경로에 대한 인증 절차가 없음
- 대상 모델의 출력을 활용하여 모델이 안전 장치를 우회하도록 유도하여 탈옥하는 멀티-턴 공격 > 목표 달성을 위한 기초가 될 수 있는 질문으로 공격 시작 > 관련된 무해한 주제로 시작하여 점진적으로 질문을 강화하여 모델의 응답을 의도한 결과로 유도 > 따라서 사용자의 프롬프트에 반응하도록 설계된 방어 및 안전 조치를 우회
- 모델의 내부 작동 방식을 파악할 필요가 없음 > 사용자가 LLM과 상호작용하는 데 필요한 수준의 지식만 필요
- 탈옥의 성공 여부를 세 가지 지표(자체 평가, Perspective API, Azure Content Filter)를 통해 평가 > 자체 평가 : 자동화된 평가(1차 및 2차 Judge LLM 평가) 후 가장 높은 성과를 보인 응답에 대해 수동 검토 > Perspective API : 6가지 지표(Toxicity, Severe Toxicity, Insult, Profanity, Sexually Explicit, Threat)를 평가 > Azure Content Filter : 4 가지 지표(Hate Speech, Self-Harm, Sexually Explicit Content, Violence)를 평가
※ Perspective API : 텍스트 내 잠재적인 유해 콘텐츠를 분석하여 여러 지표를 점수로 평가하는 도구 [2] ※ Azure Content Filter : Azure AI 서비스의 일부로, 텍스트 및 이미지 콘텐츠를 분석하여 유해하거나 부적절한 내용을 탐지하고 필터링하는 기능을 제공 [3]
- LLM 학습 단계에서 학습 데이터의 사전 필터링과 LLM의 정렬을 강화 필요 > 전자는 악성 콘텐츠 생성 및 탈옥의 가능성이 낮아지나 비용적 문제 존재 > 후자는 해당 공격을 유발하는 콘텐츠로 LLM을 미세 조정하는 방법 > 또는, 입출력 모두에 콘탠츠 필터 적용
2. Deceptive Delight [4]
[사진 2] Deceptive Delight
- LLM을 대화에 참여시켜 가이드라인을 우회하고 안전하지 않거나 유해한 콘텐츠를 생성하도록 유도하는 멀티-턴 공격 > 64.6%의 공격 성공률을 보이며, 세 번의 대화 턴 내 유해한 콘텐츠를 생성할 수 있음 > 첫 번째 턴 : 3개의 주제(정상 주제 2개+안전하지 않은 주제 1개)를 연결하는 일관된 서사를 만들도록 요구 > 두 번째 턴 : 각 주제에 대해 더 자세히 설명하도록 요청 (정상 주제를 논의하는 동안 안전하지 않은 콘테츠를 생성할 수 있음) > 세 번째 턴(선택 사항) : 안전하지 않은 주제에 대한 디테일 등 확장을 요청 (안전하지 않은 콘테츠의 구체성이 증가 됨)
- 양성(정상) 주제 사이에 안전하지 않거나 제한된 주제를 포함하여 LLM이 안전하지 않은 콘텐츠가 포함된 응답을 생성하도록 유도 > 콘텐츠 필터는 외부 방어 계층 역할을 하여 안전하지 않은 콘텐츠가 모델에 들어오거나 나가는 것을 차단 > 자연어 처리 기술을 사용해 텍스트를 분석하며 유해하거나 부적절한 콘텐츠를 감지하는데 초점 > 그러나, 속도와 효율성을 우선시해야 하므로 상대적으로 덜 정교함 > 연구는 이러한 모델 자체의 안전 메커니즘을 우회하는 데 중점을 둠
- LLM이 긴 대화에서 맥락을 유지하는데 어려움을 겪는 점을 악용 > 무해한 콘텐츠와 잠재적으로 위험한(또는 해로운) 콘텐츠를 섞인 프롬프트를 처리할 때 맥락을 일관되게 평가하는 데 한계를 보임 > 복잡하거나 긴 문장에서 모델은 양성적인 측멱을 우선시하여, 위험 요소를 간과하거나, 잘못 해석할 수 있음
- 세 가지(성공률, 유해성, 생성된 콘텐츠의 품질) 평가 지표로 6가지 카테고리에 걸쳐 40개의 안전하지 않은 주제를 8개의 모델 평가 > 6가지 카테고리: Hate(증오), Harassment(괴롭힘), Self-harm(자해), Sexual(성적인), Violence(폭력), Dangerous(위험) ※ 두 번째 턴에서 세 번째 턴 사이에 유해성 점수 21%, 생성된 콘텐츠의 품질 점수 33% 증가
- 모델의 유용성과 유연성을 유지하며 탈옥 위험을 완화하기 위한 다층 방어 전략 필요 > 정렬 훈련 기술 강화 > 더 많은 방어 매커니즘 탐색 > 탈옥 취약점을 평가 및 해결하기 위한 포괄적 프레임워크 개발 > 연구자-개발자-AI 서비스 제공 업체 간 협력 환경 조성 : 모델의 회복력을 지속적으로 개선하는 데 필수적
3. Context Fusion Attack (CFA) [5]
[사진 3] Context Fusion Attack (CFA)
- 악의적인 키워드를 무해한 키워드로 교체하여 악성 의도를 숨기는 방식으로 LLM의 안전 장치를 우회 > 공격 단계 : 키워드 추출-컨텍스트 생성-공격 > 키워드 추출 : 전처리 단계에서 악성 키워드 필터링 및 추출 > 컨텍스트 생성 : 악의적인 키워드를 무해한 키워드로 대체하여 새로운 문장 생성 > 공격 : 새롭게 생성된 콘텍스트를 이용해 LLM의 안전 장치 우회
- 24.05 무료 S/W의 팝업(Toast) 광고 프로그램을 악용한 TA- RedAnt의 대규모 공격이 탐지 [1] - IE의 자바스크립트 엔진(jscript9.dll)에 존재하는 제로데이 취약점 악용 - 22년 악용한 IE의 Type Confusion 취약점(CVE-2022-41128)에 간단한 코드를 추가하여 보안 패치를 우회
1.1 Chakra
- MS에서 제작한 웹 브라우저의 자바스크립트 엔진 > 웹 브라우저는 HTML, CSS, JavaScript 등의 언어로 작성코드를 사람이 읽을 수 있는 문서로 출력하는 프로그램 > 웹 브라우저에서 자바스크립트 코드를 해석하고 실행하는 역할을 수행
구분
이름
IE 11.0 이하 버전
legacy Chakra engine(jscript9.dll)
Edge Legacy 브라우저
new Chakra engine or Edge engine(Chakra.dll)
1.1.1 동작 과정
- 웹 브라우저에서는 JavaScript의 동작을 위해 자체 엔진을 포함하고 있으며, 빠른 실행을 위해 JIT(Just-In-Time) Compilation 방식을 사용 - MS Chakra에서 JavaScript로 작성된 코드가 실행되는 과정
구분
설명
Parsing
소스코드를 파싱하여 Abstract Syntax Tree(AST)를 생성 ※ Abstract Syntax Tree(AST) : 소스코드의 구조를 트리 형태로 나타낸 자료구조
Interpreting
- AST는 바이트코드(Bytecode)로 변환되어 인터프리터에 의해 실행 - 실행 중인 함수의 데이터 유형 및 호출 횟수와 같은 정보를 분석해 함수의 프로파일을 생성
Compilation
- 생성된 프로파일을 바탕으로 최적화된 기계코드인 JIT’ed code 생성 ※ 인터프리터에서 여러 번 호출되는 코드가 탐지되면 바이트코드를 실행하는 대신 JIT’ed code를 실행해 프로그램 동작 속도를 향상 시킴
- JavaScript엔진에서는 여러 번 호출되는 코드를 따로 관리
구분
설명
Hot
- 자주 반복되는 코드 - 코드가 Hot으로 탐지되면 엔진은 해당 코드를 스텁코드(Stub Code)로 변환 - 이후 바이트코드를 실행하지 않고 미리 생성한 스텁코드를 사용하여 실행 속도를 향상
Warm
덜 자주 반복되는 코드
1.2 Toast 광고
- 다양한 무료 S/W와 함께 설치되어 동작 > 실행 시 광고서버로부터 광고 컨텐츠를 다운받아 PC 화면 우측 하단에 광고창 표시 > 서버는 광고 컨텐츠가 포함된 HTML과 JavaScript로 응답 > Toast 광고 프로그램은 응답값을 IE 브라우저 또는 IE 관련 모듈로 랜더링하여 팝업 광고창을 띄움
2. 주요내용
2.1 CVE-2024-38178
[사진 1] CVE-2024-38178 [2]
- Windows Scripting Engine에서 발생하는 Type Confusion 취약점으로 메모리 손상을 유발해 원격 명령 실행을 가능하게 함 > jscript9.dll에서 발생하는 Type Confusion 취약점
※ Type Confusion 취약점 : 프로그램에서 사용하는 변수나 객체를 선언 혹은 초기화되었을 때와 다른 타입으로 사용할 때 발생하는 취약점
스텁코드는 Type Confusion 문제가 발생할 수 있음 - 매개변수로 정수형 변수를 입력받는 함수가 있으며, 메인에서 100번 호출된다고 가정 > 엔진에서는 Hot으로 간주하여 정수형 변수를 전달받는 스텁코드로 변환 > 그 결과, 해당 변수의 데이터 유형을 정수로 예측 > 이 때, 매개변수를 정수가 아닌 다른 데이터 유형으로 전달할 경우 Type Confusion 발생
2.2 상세분석
[사진 2] iframe이 삽입된 HTML
- 해커는 국내 광고 대행사 중 한 업체의 광고 서버를 해킹 > Toast 광고 프로그램에 전달되는 HTML 코드에 iframe을 삽입하여 경유지를 통해 JavaScript가 로드 되도록 변조 > 해당 JavaScript 파일명은 ad_toast이며 IE(JScript9.dll)의 RCE 취약점이 발현되는 코드가 삽입 > 피해자 PC에 설치된 Toast 광고 프로그램은 취약점 코드를 받아 랜더링하는 과정에서 Exploit 및 해커의 쉘 코드로 실행 흐름이 바뀜
[사진 3] CVE-2024-38178 Exploit
- 해커는 과거 악용했던 CVE-2022-41128(Windows 스크립트 언어 RCE [4]) Exploit 코드에 단 3줄을 추가해 기존 패치 우회
> ex_func(false, false)를 반복 호출하여 JIT 컴파일러의 최적화 오류를 유도한 뒤 인자를 true로 바꿔 호출
- "q=g" 연산으로 Type Confusion 발생
> 정수 배열로 초기화된 변수 q에 변수 g가 가리키는 데이터를 참조하면 변수 q의 Type이 Object로 변경 > 하지만, JIT 컴파일러의 최적화 오류로 인해 Type을 계속해서 정수 배열로 판단
- 이후 q[4], q[11], q[12]의 값을 0x1FFFFFFF로 변경
> 변경하는 이유는 해당 값이 배열 av의 Type(Js::JavascriptNativeIntArray)과 관련 > 변경한 값은 순서대로 배열 av의 Array Length, Array Actual Length, Buffer Length 항목 > 배열의 길이를 조작하면 Object Dataview를 사용하여 임의의 메모리 영역에 대한 읽기 및 쓰기가 가능하게 되어 임의 코드를 실행할 수 있음
※ JIT 컴파일러의 배열 최적화 과정에서 초기화된 변수로 착각하게 만드는 방법을 이용해 CVE-2022-41128의 패치를 우회
[사진 4] 패치
- 해당 취약점은 MS 8월 보안업데이트에서 패치 [4]
> wil::details::FeatureImpl<_ _WilFeatureTraits_Feature_1489045819>::_ _private_ IsEnabled(&`wil::Feature<_ _WilFeatureTraits_Feature_1489045819>::GetImpl’::`2 ’::impl); 함수가 추가 > 해당 함수의 결과 값에 따라 변수 초기화 여부를 검증하는 분기로 진입 > 진입 후 ValueType 클래스에서 정의된 연산자를 통해 두 개의 정수형 값 비교 과정 추가 > 두 Type을 비교해 값이 다를 경우 SetValueType 함수를 호출하여 Type을 일치시키는 추가적인 과정이 수행
2.3 악성코드 유포
- 과거부터 꾸준히 사용해온 RokRAT 악성코드를 유포하며 공격 흐름은 아래와 같음 > Ruby를 사용하여 악성 행위 지속성 확보 및 상용 클라우드 서버를 통해 명령제어를 수행
실행 단계
설명
1차 악성코드(43) 다운로드 및 explorer.exe에 인젝션
- 실행 PC의 파일·프로세스를 확인하여 분석 환경인지 탐지 > 악성코드 43은 첫 1바이트로 XOR 후 실행되는 쉘코드 > 분석 환경이 아니라고 판단되면 경유지에 접속해 2차 악성코드 다운 및 실행
2차 악성코드(23) 다운로드 및 실행
- 컴퓨터 이름 등 시스템 정보를 수집하고 추가 감염 여부 선별 > 악성코드 23은 첫 1바이트로 XOR 후 In-Memory로 실행되는 PE 형태 > 시스템 정보를 경유지로 전송하고, 응답에 따라 3차 악성코드 다운 및 실행
3차 악성코드(move) 다운로드 및 실행 후 추가 파일 다운로드
- 악성 스크립트를 삽입한 ruby standalone 드롭 및 악성 행위 지속성 확보 > 악성코드 move는 첫 1바이트로 XOR 후 In-Memory로 실행되는 PE 형태 > 2차 경유지는 원드라이브 1개와 국내 정상 사이트 2개가 악성코드 내부에 하드코딩 > 지속성 확보를 위해 자동실행 되도록 설정 (주기적 실행 또는 PC 부팅 시 실행)
system32 폴더 내 exe 무작위 선택 후 실행 및 인젝션
- PC에 설치된 백신(AVAST·SYMANTEC)을 확인하여 다르게 동작 > 현재 실행중인 프로세스 명에 "UBY"가 있는지 확인 후 설치된 백신에 따라 동작 결정 > AVAST·SYMANTEC : 현재 프로세스에서 In-Memory 방식으로 실행 > 그 외 백신 : system32 폴더에 있는 랜덤 EXE에 인젝션하여 실행
system32 폴더 내 exe 무작위 선택 후 실행 및 인젝션
- PC에 설치된 백신(AVAST·SYMANTEC)을 확인하여 다르게 동작 > 프로세스의 자체 종료를 막기 위해 ExitProcess 함수를 후킹 및 함수 인자 및 설치된 백신에 따라 동작 결정 > 인자가 0xAC가 아닐 경우 대기 상태, 0xAC일 경우 후킹을 복원 > AVAST·SYMANTEC : rubyw. exe를 재실행 > 그 외 백신 : system32 폴더에 있는 랜덤 EXE에 인젝션하여 실행
In-Memory로 RokRAT 실행
- 상용 클라우드(얀덱스 등)를 경유지로 명령제어를 수행하여 PC 정보 절취 > 윈도우 프로시저에서 수신되는 메시지를 기반으로 해당 핸들러에서 악성 행위를 수행
구분
MD5
ad_toast
e11bb2478930d0b5f6c473464f2a2B6e
43
b9d4702c1b72659f486259520f48b483
23
b18a8ea838b6760f4857843cafe5717d
MOVE
da2a5353400bd5f47178cd7dae7879c5
ban04.bak(top_08.bak,content)
bd2d599ab51f9068d8c8eccadaca103d
operating_system.rb
감염 PC마다 다름
1차 로더
2차 로더
RokRAT
2.4 결론
- MS는 22.06 IE 지원 종료 발표 및 최신 Window OS는 IE가 웹 브라우저로 사용되는 것을 제한하는 등의 조치 > 과거에 비해 워터링홀 공격의 가능성은 희박해짐 > 그러나, 일부 Window 어플리케이션들은 IE를 내장하거나 관련 모듈을 사용해 공격 벡터로 악용될 수 있음 > OS 및 SW 등의 보안 업데이트를 준수하고, 제조사들은 제품 개발 시 보안에 취약한 개발 라이브러리 및 모듈 등이 사용되지 않도록 주의 필요
- 세계 여러 정보 보안 관련 기관이 협력하여 LotL 공격 대비 가이드라인 발표 [1] - 장시간 공격을 유지할 수 있게 해 주는 LotL 공격이 공격자들 사이에서 인기 - ‘이벤트 로그 관리’를 방어책으로 내세움
2. 주요내용
2.1 LotL (Living off the Land)
- 이미 사용자 시스템에 설치된 여러 자원을 공격에 활용하는 방법 - 정상적으로 발생하는 트래픽과 공격으로 발생한 트래픽의 구분이 힘들며, 공격 지속성을 크게 높일 수 있는 장점
2.2 이벤트 로깅 (Event logging)
- 이벤트 로깅은 네트워크 가시성을 지원해 운영과 시스템의 보안 및 복원력을 개선
구분
개요
효과적인 이벤트 로깅 솔루션
① 중요한 소프트웨어 구성 변경 또는 설치시 담당자에게 경고 잔송 ② LotL 공격 또는 침해 후 횡적 이동 등의 보안 사고를 나타낼 수 있는 보안 이벤트 식별 ③ 침해의 범위와 정도를 밝혀 사고 대응 지원 ④ 정책이 잘 적용되도록 하며, 위반 여부 모니터링 ⑤ 오탐과 노이즈를 줄여 저장 공간과 요청 시간 관련 비용을 절감 ⑥ 보안 담당자들이 정보를 바탕으로 결정을 내릴 수 있게 지원 ⑦ 보안 분석가들에게 유용한 로그와 플랫폼을 제공
핵심 고려 요소
① 기업에서 승인된 이벤트 로그 정책 ② 중앙 집중식 이벤트 로그 접근 및 상관 분석 ③ 저장된 데이터의 보안 및 이벤트 로그 무결성 ④ 관련 위협에 대한 탐지 전략
로그 정책
① 어떤 이벤트를 로깅할 것인지 정의 ② 어떤 시스템에 이벤트 로깅을 적용할 것인지 정의 ③ 이벤트 로그를 모니터링하는 방법 정의 ④ 이벤트 로그를 얼마나 보관할 것인지 정의 ⑤ 로그 수집 관련 정책의 재평가 시기 정의
2.3 로그의 품질
- 사고 대응 및 위협 탐지의 맥락에서 이벤트 로그의 품질은 얼마나 잘 포맷 되었는지가 아닌, 수집된 이벤트 유형에 의해 결정
- 유용한 이벤트 로그는 보안 이벤트를 평가하여 정오탐을 식별하는 능력을 강화
> OT 장치를 포함하는 경우 해당 장치에 대한 고려가 필요
> OT 장치는 메모리와 프로세스에 부하를 주는 임베디드 소프트웨어를 사용하며, 과도한 로깅은 장치의 운영에 악영향을 미칠 수 있음
> OT 장치는 자세한 로그를 생성할 수 없으므로 센서를 사용하여 로그 기능을 보완할 수 있음
> 대역 외 로그 통신 또는 오류 코드와 기존 통신의 페이로드를 기반으로 로그를 기록
- LotL을 사용하는 공격자들은 주로 다음과 같은 로그를 수집해 파악할 수 있음
구분
설명
Linux 기반
- curl, systemctl, systemd, python 등을 사용했을 때 기록되는 로그 - 기타 일반적인 LOLBin의 사용와 관련된 로그
Windows 기반
- wmic.exe, ntdsutil.exe, Netsh, cmd.exe, PowerShell, mshta.exe, rundll32.exe, resvr32.exe 등을 사용했을 때 기록되는 로그 - 명령 실행, 스크립트 차단, PowerSehll용 모듈 로그, 관리 작업에 대한 로그
Cloud 환경
- API 호출 및 최종 사용자 로그인을 포함한 모든 컨트롤 플레인 작업을 기록 - 컨트롤 플레인 로그는 읽기 및 쓰기 활동, 관리 변경 사항 및 인증 이벤트를 기록하도록 구성
- 이벤트 로그는 대응을 돕기에 충분한 세부 정보가 포함되어 있는 것이 좋음
미국 관리예산국 M-21-312의 로그에 포함되어야 하는 내용
① 올바르게 포맷되고 정확한 타임스탬프 (밀리초 단위가 이상적) ② 이벤트 유형 ③ 장치 식별자의 MAC 주소 또는 기타 고유 식별자 ④ 세션/트랜잭션 ID ⑤ 자율 시스템 번호 ⑥ 출처 및 도착지 IP (IPv4 및 IPv6 포함) ⑦ 상태 코드 ⑧ 응답 시간 ⑨ 추가 헤더 (Ex. HTTP 헤더) ⑩ 사용자 ID (해당되는 경우) ⑪ 실행된 명령 (해당되는 경우) ⑫ 이벤트 상관 관계를 돕기 위한 고유 이벤트 식별자 (가능한 경우) ※ 모든 데이터는 추출을 더 쉽게 하기 위해 "키-값 쌍" 형식으로 포맷 (가능한 경우)
- 로그의 품질을 높이는 요소들
구분
설명
콘텐츠 및 형식 일관성
- 로그를 중앙 집중화할 때 JSON과 같은 구조화된 로그 형식을 사용 - 형식, 순서, 스키마를 일관되게 유지 - 로그가 생성될 때부터 일관된 형식을 유지하는 것이 좋음 - 그러나, 모든 로그가 정해진 형식을 따를 수 있는 것은 아니므로 자동화된 로그 정규화 방법론을 마련할 필요
타임스탬프 일관성
- 모든 시스템에서 동일한 날짜-시간 형식과 표기법을 사용 - ISO 8601 형식은 연도-월-일-시-분-초-밀리초 순서 권고
로그 보존
- 시스템에 대한 위험 평가 결과에 따라 로그 보관 기간 결정하며, 침입과 영향을 평가하는 로그는 좀 더 오래 보존 - 조직에 적용되는 모든 규제에 어긋나지 않도록 보존 - 조직이 보유하고 있는 저장 공간도 고려 - 공격자들이 로그를 삭제할 수 있으므로, 로그에 대한 접근 또한 강화 ※ 어떤 경우 사고를 발견하는 데 최대 18개월이 걸리고, 어떤 악성코드의 경우 70~200일 동안 네트워크에 거주하는 것을 고려
2.4 로깅 우선순위
- 조직 내에서 로그 소스를 우선순위를 둘 것과 우선순위가 낮은 로그도 모니터링할 것을 권장
구분
설명
로깅 우선순위
- LotL 맥락에서 기업의 망은 공격자들이 사용하기 좋은 도구들이 많음 > 해당 도구들과 관련하여 로그의 우선순위를 정하는 것이 효과적
①공격 대상이 될 가능성이 높은 중요 시스템과 데이터 ② 원격 접근, 네트워크 메타데이터, 기본 서버 OS, 인터넷 연결 서비스 ③ ID 및 도메인 관리 서버 ④ 기타 중요 서버 ⑤ 네트워크 외곽에 있는 라우터와 방화벽 등 ⑥ 관리자의 관리 작업을 위한 워크스테이션 ⑦ 환경 설정, 시스템 모니터링, CI/CD, 취약점 스캔, 비밀 관리, 권한 관리에 사용되는 시스템 ⑧ 데이터 저장소 ⑨ 보안 소프트웨어 ⑩ 사용자 컴퓨터 ⑪ 사용자 애플리케이션 ⑫ 웹 프록시 ⑬ DNS 서비스 ⑭ 이메일 서버 ⑮ DHCP 서버 ⑯ 오래된 레거시 IT 자산 ⑰ 하이퍼바이저 호스트 ⑱ 프린터 등 부수적인 IT 장치 ⑲ 애플리케이션 게이트웨이 등 네트워크 구성 요소
OT 환경 로깅 우선순위
- 최근 OT 네트워크에 대한 공격이 증가
① 안전 및 서비스 제공에 중요한 OT 장치 (Air-Gap 시스템 제외) ② 공공 인터넷과 연결된 OT 장치 ③ 네트워크 외곽선을 통과했을 때 접근이 가능해지는 OT 장치 ④ 로깅 기능이 없는 OT 장치 (OT 장치의 네트워크 트래픽 모니터링 필요)
엔드포인트 로깅 우선순위
- 팬데믹 등으로 재택 근무의 증가
① 사용자가 사용하는 웹 프록시 ② 회사/기관에서 운영 혹은 사용하는 DNS 서비스 ③ 조직에 공식 등록된 장치들의 보안 상황 ④ 조직에 공식 등록된 장치들의 행동 패턴 ⑤ 사용자 계정에서 발생하는 활동 ⑥ VPN 솔루션 ⑦ MDM 및 모바일 애플리케이션 관리(MAM)
클라우드 컴퓨팅 로깅 우선순위
- IaaS, PaaS, SaaS 등 플랫폼과 유형에 따라 이벤트 로깅 방식을 조정 > Ex. IaaS : 테넌트에 로깅 책임을 부여 / SaaS : 서비스 제공 업체에 로깅 책임 부여 > 기업(사용자)과 제공자(CSP) 간 긴밀한 협조 필요
① 표적이 될 가능성이 높은 중요 시스템과 데이터 ② 공공 인터넷에 직접 연결된 서비스 ③ 클라우드 서비스에 직접 접근하고 관리하는 테넌트의 계정 ④ 환경 설정 ⑤ 모든 보안 관련 계정 (생성, 삭제, 수정 등) ⑥ 서드파티 인증 서비스를 활용할 때(성공/실패 로그) ⑦ 클라우드 서비스에서 생성된 로그, 클라우드 API 로그, 네트워크 이벤트 등
2.5 이벤트 로그의 안전한 저장 및 무결성
- 중앙 집중식 이벤트 로깅 시스템을 구축한 후 SIEM, XDR과 같은 분석 도구로 로그를 전달할 것을 권장
> 충분한 저장 용량을 갖출 것 (침해가 발생하였으나, 과거 이벤트 로그가 없으면 사고 대응에 부정적 영향을 미침)
> 별도의 네트워크 또는 세분화된 네트워크에 보관하며, 로그 변조의 위험을 줄이기 위한 추가 보안 제어 기능이 필요
- 이벤트 로그의 안전한 전송 및 무결성을 보장하기 위해 TLS 1.3 및 암호화 검증 등의 보안 메커니즘 구현 권장
> 공격자들은 로그를 수정하거나 삭제하며, 로그에서 유용하면서 민감한 데이터를 확인할 수도 있음
> 적정한 요건을 갖춘 사용자만이 이벤트 로그에 접근할 수 있는 권한을 부여
2.6 LotL 탐지
- 아주 조금의 이상 행동이라도 탐지 및 기록해야 함
구분
설명
이상 (비정상적) 행동
① 비정상적인 시간대에 발생한 사용자 로그인 (근무 외 시간, 공휴일 등) ② 사용자가 일반적으로 접근하지 않는 서비스에 접근 혹은 접근 시도 ③ 비정상적인 장치를 활용한 로그인 및 로그인 시도 ④ 비정상적으로 빈번한 로그인 시도 ⑤ 물리적으로 불가능한 로그인 시도 (불가능한 이동(Impossible Travel) 등) ⑥ 대량의 데이터 다운로드 및 외부 유출 ⑦ 정상 인증 단계를 거치지 않은 로그인 ⑧ 다양한 사용자 ID로 접근하는 단일 IP 주소 ⑨ 사용자 계정 생성 / 비활성화 된 계정의 재활성화(특히 관리자 계정) ⑩ 일반적으로 통신 트래픽이 없는 장치에서 트래픽이 발생 ⑪ 비정상적인 스크립트 실행 ⑫ 갑작스러운 로그 삭제 ⑬ 비정상적인 프로세스 생성 및 실행 ⑭ 보안 소프트웨어 및 로깅 소프트웨어의 환경 설정 변경
추가 분석
① 프로세스 생성 이벤트 / 명령줄 감사 등 상세 로깅 활성화 상태로 유지 > 로그 가시성 향상 가능 ② 조직 내에서 사용할 수 있는 정상 바이너리의 기준 생성 > 비정상 바이너리가 자연스럽게 결정 ③ 진화하는 위협에 따라 다양한 운영 체제에 대한 탐지 규칙 생성 Windows : powershell.exe, cmd.exe, regedit.exe 등에 대한 상세 탐지 규칙 Linux : curl, systemctl, python 등에 유의
OT 환경
① 비정상적인 혹은 예상하기 힘든 도구의 활용 ② 벤더나 서드파티의 갑작스러운 접근 ③ 유지보수나 원격 모니터링을 위한 도구의 비정상적인 사용 ④ 운영 체제, 소프트웨어, 펌웨어, 환경, 데이터베이스 등의 무단 변경 및 무단 업데이트 ⑤ 제어 시스템과 외부 네트워크 간의 비정상적인 통신 ⑥ 평소에 통신 활동이 없던 구성 요소 간에 발생하는 통신 ⑦ 비정상적인 스크립트 실행
- Kubernetes Image Builder에서 이미지 빌드 프로세스 중에 기본 자격 증명이 활성화되는 보안 문제가 발견 [4] > Proxmox 공급자를 사용하여 빌드된 가상 머신 이미지는 기본 자격 증명을 비활성화하지 않아 기본 자격 증명을 통해 액세스가 가능 > 다른 공급자로 빌드된 이미지를 사용하는 VM은 취약점에 영향받지 않음
2.2 CVE-2024-9594 [5][6]
[사진 2] CVE-2024-9594
- Kubernetes Image Builder 기본 자격 증명 비활성화 취약점 > Nutanix, OVA, QEMU 또는 원시 공급자로 빌드된 이미지에도 동일한 문제가 존재하나 빌드가 끝난 후 자격증명이 비활성화 됨 > 이미지 빌드가 발생하는 VM에 접근해 이미지 빌드가 발생하는 시점에 취약성을 악용할때만 영향을 받음
영향받는 버전: Kubernetes Image Builder <= v0.1.37
3. 대응방안
- 벤더사 제공 보안 업데이트 적용 [7] > 이미지 빌드 기간 동안 무작위로 생성된 비밀번호를 설정 > 이미지 빌드가 끝나면 빌더 계정이 비활성화
취약점
제품명
영향받는 버전
해결 버전
CVE-2024-9486 CVE-2024-9594
Kubernetes Image Builder
v0.1.37 이하
v0.1.38
- 사용 중인 Image Builder 버전 확인 방법
구분
설명
이미지 빌더 저장소의 git 복제본의 경우
cd <local path to image builder repo> make version
Tarball 다운로드를 사용하여 설치하는 경우
cd <local path to install location> grep -o v0\\.[0-9.]* RELEASE.md | head -1
컨테이너 이미지 릴리스의 경우
docker run --rm <image pull spec> version 또는 podman run --rm <image pull spec> version
공식 이미지의 경우 지정된 이미지 태그 확인 registry.k8s.io/scl-image-builder/cluster-node-image-builder-amd64:v0.1.37
- last builder 명령으로 builder 계정 로그인 이력 점검
※ 업데이트 적용이 불가할 경우
ⓐ Image Builder의 고정 버전을 사용하여 영향을 받은 모든 이미지를 다시 빌드 > 영향을 받은 모든 VM에 고정된 이미지를 다시 배포
ⓑ 업그레이드 전 영향을 받는 VM에서 빌더 계정을 비활성화하면 취약점을 완화할 수 있음 > usermod -L builder
- 해외 보안 연구원에 의해 공항 보안에 사용되는 KCM과 CASS 프로세스에서 SQL Injection 취약점 발견 [1] - 취약점 악용에 성공할 시 관리자가 되어 항공사에 새로운 직원을 추가하는 등의 악성행위 가능 > 현재는 취약점이 해결되었음
2. 주요내용
2.1 KCM (Known Crewmember)
- 조종사와 승무원이 보안 검색을 우회할 수 있도록 해주는 TSA 프로그램 - 직원은 전용 레인을 사용하며, KCM 바코드 또는 직원 번호를 제시해 통과 여부를 결정
※ TSA (Transportation Security Administration) : 미국 교통안전청, 9.11 테러 이후 여객기 등의 운행 안전 필요성이 대두되어 설립
2.2 CASS (Cockpit Access Security System)
- 조종사가 조종실의 점프 시트를 사용할 수 있도록 하는 시스템
2.3 ARINC
- 항공, 공항, 국방, 정부, 수송분야에서 사용되는 표준과 시스템을 개발 및 제공하는 기업 - TSA와 계약하여 KCM 시스템을 운영하며, 조종사와 승무원이 KCM 상태를 확인할 수 있는 웹 사이트와 항공사 간 승인 요청을 라우팅하는 API 등을 운영 > 각 항공사는 KCM 및 CASS에 참여하기 위해 자체 인증 시스템을 운영하며, ARINC의 허브와 상호작용함 - TSA와 항공사는 CockpitAccessRequest와 CrewVerificationRequest 같은 요청을 ARINC로에 보낼 수 있으며, ARINC는 이를 적절한 항공사 시스템으로 라우팅
2.4 FlyCASS.com
- 소규모 항공사를 위해 KCM, CASS 운영하며, 모든 항공사가 자체 로그인 페이지를 가지고 있음 - 로그인 페이지에서 SQL Injection 취약점을 테스트(username에 ` 입력)한 결과 MySQL 오류 발생 > sqlmap을 사용해 관리자로 FlyCASS에 로그인 성공 > username : ' or '1'='1 / password : ') OR MD5('1')=MD5('1
※ sqlmap : SQL Injection을 감지 및 악용할 수 있는 Python 으로 작성된 오픈 소스 침투 테스트 도구 [2]
※ 잘못된 SQL 문법 등의 경우 반환되는 에러 메시지를 통해 데이터베이스 정보를 획득할 수 있으므로, 에러 메시지를 출력하지 않도록 조치 필요
[사진 1] MySQL 오류
2.5 KCM, CASS 관리자
- FlyCASS에 SQL Injection 취약점을 악용해 관리자 권한으로 접근이 가능 > 직원(조종사, 승무원) 목록을 확인하거나 추가 인증 없이 새로운 직원을 추가할 수 있었음
[사진 2] 관리자 계정 접근 성공
- 테스트를 위해 Test TestOnly 직원 추가 및 KCM, CASS 접근 권한을 부여하는데 성공 > SQL Injection에 기본적인 지식이 있는 누구나 KCM, CASS에 임의의 직원을 추가할 수 있는 심각한 문제
[사진 3] Test TestOnly 사용자 추가 성공
2.6 공개 및 기타 [3]
- 미국 국토안보부(United States Department of Homeland Security, DHS)에 문제를 공개 - 이후 FlyCASS는 KCM, CASS에서 비활성화 - TSA는 취약점을 부인하는 성명을 발표했으며, DHS는 초기에 신속하고 전문적으로 처리했으나, 이후 과정에서 상급 기관으로써의 역할을 제대로 수행하지 못함 - 비밀번호를 저장하는데 MD5 해시를 사용한 것 또한 문제
- CISA는 F5 BIG-IP LTM(로컬 트래픽 관리자, Local Traffic Manager) 모듈에서 생성된 쿠키를 악용한 내부 네트워크 탐색에 대해 경고 [1] - 공격자는 숨겨진 내부 장비를 찾아내고 이를 타켓으로 삼아 침투할 수 있는 취약점을 찾는데 사용할 수 있음
2. 주요내용
- F5 BIG-IP: 애플리케이션 배포 및 트래픽 관리 도구로, 웹 애플리케이션의 로드 밸런싱과 보안을 제공하는 솔루션 > LTM 모듈: 트래픽을 관리하고 로드 밸런싱을 통해 네트워크 트래픽을 여러 서버에 분산
- LTM 모듈은 세션 일관성을 유지하기 위해 쿠키를 사용 > 해당 쿠키를 통해 사용자가 동일한 백엔드 서버로 지속적으로 접속할 수 있도록 함 > 그러나, 해당 쿠키는 기본적으로 암호화되지 않은 상태로 설정되어 있음
- 내부 서버 IP 주소, 포트 번호, 로드 밸런싱 설정 등의 정보가 암호화 없이 쿠키에 포함되어 있음 > 쿠키에서 얻은 정보를 기반으로 네트워크 내 추가 자원을 식별하거나 취약점을 찾아 악용할 수 있음
- F5는 BIG-IP 11.5.0부터 모든 쿠키를 암호화할 수 있는 'Required' 옵션 제공 [2][3] > 쿠키 암호화가 활성화되면 BIG-IP LTM 시스템은 192-Bit AES 암호화 후 Base64 인코딩하여 HTTP 응답에 포함 > 클라이언트가 암호화된 쿠키를 전송한 경우 BIG-IP LTM은 Base64 디코딩 후 복호화한 후 HTTP 요청에 복호화된 쿠키를 포함
