- 독일 아테네국립응용사이버보안연구센터에서 DNS 보안 프로토콜 DNSSEC의 설계 결함을 악용한 KeyTrap (CVE-2023-50387)발견 [1] - 단일 DNS 패킷을 전송하여 서비스 거부를 유발할 수 있음 > 취약한 DNS의 경우 최소 170초에서 최대 16시간 동안 서비스 거부 발생
2. 주요내용
2.1 DNSSEC(Domain Name System Security Extension) [2][3]
- DNS는 도메인(hxxps://example[.]com)을 IP 주소(1.1.1.1)로 변환하는 역할 > 초기 설계시 보안성을 충분히 고려하지 못해 DNS 정보 위-변조가 가능하다는 문제 존재 Ex. DNS Cache Poisoning
- 기존 DNS 보안성을 강화하기 위해 공개키 암호화 방식의 보안기능을 추가한 DNSSEC(DNS Security Extensions) 도입 > DNS를 대체하는 것이 아님
- DNSSEC 설계 결함으로 인해 DNS 서버에 서비스 거부를 유발할 수 있는 취약점 > DNSKEY 및 RRSIG 레코드가 여러개일 경우 프로토콜 사양에 따라 모든 조합에 대한 유효성 검사를 수행
- 취약점과 관련된 세 가지 DNSSEC 설계 문제 ① 여러 개의 서로 다른 DNS 키가 동일한 키 태그를 가질 수 있어 서명 유효성 검사 프로세스에 계산 부하 발생 가능 ② 서명을 성공적으로 검증하는 키를 찾거나 모든 키가 시도될 때까지 모든 키를 시도해야 하므로(가용성 보장 목적) 계산 부하 발생 가능 ③ 동일한 레코드에 여러 서명이 있는 경우 유효한 서명을 찾거나 모든 서명이 시도될 때까지 수신된 모든 서명을 검증해야 하므로, 계산 부하 발생 가능
- 영향받는 버전
[사진 2] 취약한 DNS 구성
2.2.1 SigJam (하나의 키 X 다수 서명)
- DNS Resolve가 하나의 DNS 키를 사용하여 DNS 레코드에 존재하는 다수의 유효하지 않은 서명을 검증하도록 유도 > DNS Resolve가 DNSKEY로 검증할 수 있는 서명을 찾을 때까지 모든 서명을 시도하도록 설계 됨 > 공격자는 단일 DNS 응답에 340개의 서명을 작성할 수 있음 > 340개의 서명에 대한 유효성 검증을 수행한 후 DNS Reolve는 클라이언트에 SERVFAIL를 반환
2.2.2 LockCram (다수의 키 X 하나의 서명)
- DNS Resolve가 ZSK DNSSEC키를 사용하여 DNS 레코드를 통해 하나의 서명을 검증하도록 유도 > DNS Resolve가 하나의 키가 검증되거나 모두 시도될 때까지 서명에 사용할 수 있는 모든 키를 시도하도록 설계 됨 > DNS Resolve는 서명을 검증하기 위해 모든 DNSSEC 키를 사용 > 해당 서명이 유효하지 않다고 결론을 내릴 때까지 서명이 참조하는 모든 키를 시도
2.2.3 KeySigTrap (다수의 키 X 다수의 서명)
- SigJam과 LockCram를 결합하여 검증 과정이 2배 증가하는 공격
> 모든 키와 서명 쌍이 검증될 때까지, 가능한 모든 조합에 대해 검증을 시도
Ex. 첫 번째 ZSK를 사용해 N개 서명을 검증한 후, 두 번째 ZSK를 사용해 N개 서명을 검증하여 N번째 ZSK를 사용해 N개 서명을 검증
> 모든 조합 시도 후 레코드를 검증할 수 없다는 결론을 내리고 클라이언트에 SERVFAIL를 반환
2.2.4 HashTrap (다수의 키 X 다수의 해시)
- 다수의 DS 해시 레코드에 대해 충동하는 다수의 DNSKEY를 검증하기 위해 많은 해시를 계산하도록 유도
[사진 3] KeyTrap 공격에 의한 서비스 거부 시간
3. 대응방안
- 벤더사 제공 패치 제공 > 현재까지 나온 패치는 임시 조치 > DNSSEC 설계를 처음부터 다시 해야 문제가 해결될 것
- DNSSEC 기능 비활성화시 취약점이 근본적으로 사라지나 권장하지 않음 > KeyTrap 취약점을 제외하면 DNSSEC로부터 얻는 안전의 이득이 훨씬 많음
- AI/ML 대상 버그 바운티 플랫폼 Huntr에서 AI/ML 오픈소스 플랫폼의 보안취약점발견 - 영향을 받는 플랫폼은 MLflow, ClearML, Hugging Face Transformers로, 다양한 산업에서 사용되는 AI 솔루션
> MLflow: AI 라이프 사이클 전 과정을 관리해주는 MLOps 플랫폼 > ClearML: 다양한 사용자들이 AI 서비스를 사용 및 개발할 수 있도록 해주는 E2E MLOps 플랫폼 > Hugging Face Transformers: Hugging Face社에서 제공하는 AI 개발 라이브러리
1.1 MLOps [1][2]
- ML 시스템 개발, 배포, 유지보수를 효율적이고, 지속할 수 있도록 하는 업무 방식
2. 주요내용
AI/ML 플랫폼
CVE
CVSS
설명
취약한 버전
MLflow
CVE-2023-6831 [3]
10.0
- 공격자가 유효성 검사를 우회하고 서버의 모든 파일을 삭제할 수 있음 [4] > mlflow/utils/uri.py의 verify_path_is_safe 메소드가 URL 인코딩을 올바르게 필터링하지 않아 발생 > URL 인코딩(%2E%2E)을 통해 verify_path_is_safe 메소드를 우회할 수 있음 > 악용에 성공한 공격자는 서버의 모든 파일을 삭제할 수 있음
MLflow 2.9.2 이전 버전
CVE-2024-0520
- mlflow.data 모듈의 결함으로 인해 공격자가 데이터 세트를 조작할 수 있음 [5] > 응답 헤더에 "Content-Disposition" 헤더가 설정된 경우 "filename" 값을 검증 없이 최종 파일 경로를 생성 > 악용에 성공한 공격자는 업로드한 파일을 이용해 RCE를 수행할 수 있음
CVE-2023-6977 [6]
- 공격자가 경로 유효성 검사 우회해 서버의 민감한 파일을 읽을 수 있음 [7] > mlflow/utils/uri.py의 is_local_uri 메서드에서 parsed_uri.hostname() 를 사용해 경로 확인 (hostname == "." or hostname.stratwith(127.0.0.1) or hostname.startswith("localhost")) 및 우회 > 악용에 성공한 공격자는 업로드한 민감 파일에 접근해 내용을 확인할 수 있음
CVE-2023-6709 [8]
- 악성 레시피 구성을 로드하여 원격 명령을 실행할 수 있음 [9] > MLflow는 jinja2 템플릿 엔진을 이용해 사용자가 제어할 수 있는 템플릿 구성 파일을 직접 로드하여 레시피 프레임워크를 구축하도록 함 > mlflow/utils/file_utils.py의 render_and_merge_yaml 메서드는 랜더링 및 합병에 샌드박스를 사용하지 않고 jinja2 라이브러리를 사용 > 악용에 성공한 사용자는 RCE를 수행할 수 있음
ClearML
CVE-2023-6778 [10]
5.4
- 마크다운 편집기에 저장된 XSS 취약점 > 프로젝트 설명 및 보고서 섹션에 모두 사용되는 Markdown Editor 구성 요소에서 입력값을 적절히 삭제하지 않아 발생 [11] > 악성 XSS 페이로드가 삽입되어 사용자 계정이 손상될 수 있음
ClearML Server 1.13.0 이전 버전
Hugging Face Transformers
CVE-2023-7018 [12]
9.6
- 기능에 제한이 없어 악성 파일이 자동으로 로드되어 잠재적으로 원격 코드 실행할 수 있음 [13] > pickle.load를 사용하여 원격 레포에서 vocab.pkl 파일을 아무런 제한 없이 자동으로 로드하기 위해 TransfoXLTokenizer를 구현 > 블랙리스트 및 기타 검사를 우회하여 감염된 모델이 로드되도록 함 > 악성 파일을 로드하여 RCE를 수행할 수 있음
Transformers 4.36 이전 버전
3. 조치사항
- 취약한 버전의 플랫폼 사용자의 경우 최신 패치 적용
> MLflow 2.9.2 / ClearML Server 1.13.0 / Transformers 4.36
- GNU Bash Shell에서 환경변수에 악의적인 코드를 삽입해 원격 코드 실행이 가능한 취약점 (CVSS: 9.8) - 영향받는 버전: 1.14.0~1.14.7 / 2.0~2.05 / 3.0~3.0.16 / 3.1~3.2.48 / 4.0~ 4.3 - 관련 추가 내용 확인 불가
3. 대응방안
- 최신 버전 업데이트 적용
취약점
대상 소프트웨어
조치 방안
CVE-2023-22527
Confluence Data Center
8.5.4. 이상 업데이트
Confluence Server
8.6.0 이상 업데이트 8.7.1 이상 업데이트
CVE-2017-3506
WebLogic
2017.10 Oracle Critical 패치 업데이트
CVE-2014-6271
GNU Bash
Red Hat Enterprise Linux 4,5,6,7 업데이트 Ubuntu 10.04, 12.04, 14.04 업데이트 * GNU 기반 운영체제별 최신 업데이트 권고
- 해당 취약점은 "testURLPassesExclude" 메소드에서 URL에 대한 입력값 검증이 부족하여 발생
> doFilter()는 HTTP 요청을 가로채 입력값 검증, 권한 검증 등을 수행하는 것으로 판단됨
> testURLPassesExclude 메소드는 doFilter()에 의해 호출
> testURLPassesExclude는 URL에서 ".." 또는 "%2e (디코딩 .)" 문자열만 필터링하며 그 외 추가적인 필터링은 존재하지 않음
public static boolean testURLPassesExclude(String url, String exclude) {
// If the exclude rule includes a "?" character, the url must exactly match the exclude rule.
// If the exclude rule does not contain the "?" character, we chop off everything starting at the first "?"
// in the URL and then the resulting url must exactly match the exclude rule. If the exclude ends with a "*"
// character then the URL is allowed if it exactly matches everything before the * and there are no ".."
// characters after the "*". All data in the URL before
if (exclude.endsWith("*")) {
if (url.startsWith(exclude.substring(0, exclude.length()-1))) {
// Now make suxre that there are no ".." characters in the rest of the URL.
if (!url.contains("..") && !url.toLowerCase().contains("%2e")) {
return true;
}
}
}
else if (exclude.contains("?")) {
if (url.equals(exclude)) {
return true;
}
}
else {
int paramIndex = url.indexOf("?");
if (paramIndex != -1) {
url = url.substring(0, paramIndex);
}
if (url.equals(exclude)) {
return true;
}
}
return false;
}
- 공격자는 /%u002e%u002e/%u002e%u002e/ (디코딩 /../../)를 이용해 URL 입력값 검증을 우회
> 벤더사는 당시 웹 서버에서 지원하지 않는 UTF-16 문자의 특정 비표준 URL 인코딩에서 오류가 발생하였다고 밝힘
- 취약한 버전의 GoAnywhere MFT에서 발생하는 인증 우회 취약점 (CVSS: 9.8)
> 인증을 우회한 공격자는 새로운 관리자 계정을 생성해 추가 익스플로잇이 가능함
영향받는 버전 [3] ① Fortra GoAnywhere MFT 6.x (6.0.1 이상) ② Fortra GoAnywhere MFT 7.x (7.4.1 이전)
2.1 취약점 상세 [4]
- 최초 설치시 GoAnywhere MFT는 InitialAccountSetup.xhtml를 호출해 관리자 계정을 생성
[사진 2] 설치 중 관리자 계정 추가
- 설치 후 InitialAccountSetup.xhtml를 직접 요청하면 액세스할 수 없으며 리다이렉션이 발생
> 관리자 계정이 생성되었기 때문
> /Dashboard.xhtml 엔드포인트로 리디렉션
> 사용자가 인증되지 않았으므로 최종적으로 /auth/Login.xhtml로 리디렉션
- 모든 요청에 대해 com.linoma.dpa.security.SecurityFilter 클래스 호출
> 어떤 엔드포인트가 요청되는지 확인하고 엔드포인트, 사용자 컨텍스트 및 응용 프로그램 설정을 기반으로 요청이 올바른 엔드포인트로 라우팅 되도록 허용하는 doFilter() 기능을 수행
> 해당 클래스에서 취약점과 관련된 /InitialAccountSetup.xhtml 요청을 처리하는 명시적인 코드가 확인
① 91번 라인: 이미 생성된 관리자 사용자가 없고 경로가 /wizard/InitialAccountSetup.xhtml이 아닌 경우 설정 페이지로 리다이렉션 ② 102번 라인: 이미 생성된 admin 사용자가 있고 경로가 /wizard/InitialAccountSetup.xhtml이면 /Dashboard.xhtml로 리디렉션
[사진 3] /wizard/InitialAccountSetup.xhtml 관련 명시적 코드
- 공격자는 이를 악용하기 위해 페이로드에 "/..;/"를 추가해 경로 순회 취약점을 이용
> Tomcat의 일부 취약한 구성은 /..;/를 /../로 정규화 [5][6]
> /..;/를 이용해 doFilter()를 우회하여 새로운 관리자 계정 생성 및 추가 익스플로잇 수행
