Search

Web

Search

Introduction

Vulnerability Detail

Apache OFBiz 1-Day 취약점 살펴보기: CVE-2024-47208 (7/7)
One-Day Analysis

Introduction

이번에 분석할 CVE-2024-45507 취약점은 이전에 분석한 CVE-2024-45195 취약점과 유사하지만 취약점을 일으키는 엔드포인트가 다릅니다. 이는 취약점을 발생시키는 Groovy 스크립트가 다르다는 것입니다.
CVE-2024-45507 취약점은 StatsSinceStart.groovy 스크립트를 이용하여 서버 측 요청 위조(SSRF)와 코드 인젝션 취약점을 발생시키는 문제를 가지고 있고, CVE-2024-45195 취약점은 ViewDataFile.groovy 스크립트를 이용한 강제 브라우징(Forced Browsing) 취약점입니다.
 CVE-2024-45507 vs CVE-2024-45195
여기서 SSRF 취약점과 Forced Browsing 취약점의 큰 차이는 다음과 같습니다.
 SSRF(Server-Side Request Forgery) vs Forced Browsing
•
SSRF(Server-Side Request Forgery) 취약점은 공격자가 서버를 통해 내부 네트워크나 다른 서비스에 요청을 보낼 수 있게 하는 취약점이며, 코드 인젝션은 악의적인 코드를 실행시킬 수 있게 합니다.
•
Forced Browsing은 권한이 없는 사용자가 접근 제한된 파일이나 디렉토리에 직접 접근하는 취약점입니다.
즉, CVE-2204-45507 취약점의 경우 직접적으로 인증된 사용자로부터 URL을 입력받아 SSRF 취약점이 발생되지만, CVE-2204-45195 의 경우 비 인가된 사용자로부터 요청이 발생되므로 Forced Browsing 취약점으로 결정된 것입니다.
Apache OFBiz 1-Day 취약점 살펴보기: CVE-2024-45507 (6/7)
One-Day Analysis
2025/03/04

Introduction

네 번째 취약점인 CVE-2024-45195 취약점에 대해 알아보겠습니다. 해당 취약점은 Apache OFBiz 버전 18.12.15 이하에서 발생되는 강제 브라우징(Forced Browsing) 취약점입니다.
이전에 발생한 세 가지 취약점(CVE-2024-32113, CVE-2024-36104, CVE-2204-38856)과 동일하게 URI 처리 메커니즘에서 컨트롤러(Controller)와 뷰(View)의 매핑 처리과정에서 발생하는 잘못된 인증 처리로 인해 발생됩니다.
즉, requestUri 와 overrideViewrUri 에 대한 구분된 처리로 인해 발생하는 취약점으로 아래 분석을 통해 상세히 살펴보겠습니다.

Vulnerability Detail

Analysis

해당 CVE-2024-45195 취약점에서는 ProgramExport 에 대한 접근이 불가능하기 때문에 인증 없이 접근 가능한 다른 엔드포인트를 찾아야 합니다.
ProgramExport.groovy 의 권한 검사 로직
Apache OFBiz 1-Day 취약점 살펴보기: CVE-2024-45195 (5/7)
One-Day Analysis
2025/03/04

Introduction

세 번째 취약점인 CVE-2024-38856은 이전에 발견된 CVE-2024-32113, CVE-2024-36104 취약점의 근본적인 원인에 대한 취약점입니다. 이전에 발견된 CVE-2024-32113, CVE-2024-36104 취약점은 공격 벡터가 된 URI를 기반으로 Path Traversal 취약점을 방어했지만, 사실 근본적인 취약점 원인에 대한 해결책은 아니었습니다.
이번 CVE-2024-38856 취약점은 NVD에서도 언급되었듯이 Incorrect Authorization 취약점으로, Apache OFBiz에서 인증되지 않은 엔드포인트를 통해 권한 검사 없이 화면 렌더링 코드 실행이 가능한 문제입니다. 그럼 이번 CVE-2024-38856 취약점 분석을 통해 근본적인 취약점 발생 원인을 분석해보겠습니다.

Vulnerability Detail

Analysis

먼저, 이전에 발생한 CVE-2024-32113와 CVE-2024-36104 취약점이 패치된 Apache OFBiz 18.12.14 버전에서 Path Traversal 공격을 어떻게 방어하고 있는지 살펴보고, 이 버전에서 발생한 CVE-2024-38856 취약점의 발생 원인을 분석해보겠습니다.

18.12.14 패치 기록

Apache OFBiz 18.12.14 이전 버전에서 발생한 Path Traversal 취약점은 공격 벡터가된 URI의 요청을 방어하기 위한 코드 로직이 추가되었습니다.
Apache OFBiz 1-Day 취약점 살펴보기: CVE-2024-38856 (4/7)

Introduction

두 번째 취약점인 CVE-2024-36104 취약점은 이전에 분석한 과 동일한 Path Traversal 취약점 입니다. 해당 취약점은 CVE-2024-32113 이 패치된 이후, 보완된 버전인 Apache OFBiz 버전 18.12.13에서도 우회가 가능하여 새로운 취약점으로 분류되었습니다. 공격자는 특수문자 및 인코딩 기법을 이용하여 보안 제한을 우회하고 원격 코드 실행(RCE)이 가능합니다.

Vulnerability Detail

Analysis

패치 확인(18.12.12 18.12.13)

이전에 발생한 취약점 CVE-2024-32113 은 다음의 파일이 패치 되었습니다.
 framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/ControlFilter.java
Apache OFBiz 1-Day 취약점 살펴보기: CVE-2024-36104 (3/7)

Introduction

Apache OFBiz에서 발생된 1-Day 취약점 중 먼저 살펴볼 취약점은 CVE-2024-32113 입니다. 해당 취약점은 OFBiz 버전 18.12.12 이하에서 발생하는 Path Traversal 취약점으로, OFBiz 프레임워크의 URL 요청에 대한 컨트롤러(Controller)와 뷰(View)의 처리 과정에서 발생하는 취약점 입니다.

Vulnerability Detail

Analysis

이 취약점은 Apache OFBiz 프레임워크의 버전 18.12.12 이하에서 발생하는 경로 조작(Path Traversal) 취약점입니다. 해당 취약점의 주요 원인은 OFBiz의 URI 요청 처리 과정에서 사용자 입력값에 대한 충분한 검증이 이루어지지 않아 발생합니다.

URI 처리 메커니즘

Apache OFBiz 1-Day 취약점 살펴보기: CVE-2024-32113 (2/7)

Introduction

이번 1-Day 취약점 분석 대상은 Apache 재단에서 개발한 OFBiz 프레임워크 입니다.
해당 프레임워크에서 발생한 취약점을 분석하던 중 CVE-2024-47208 취약점은 아래 표(Vulnerability Context)로 정리된 이전에 발생한 여러 취약점들과 이어지는 내용이므로 연관성을 확인할 필요가 있습니다.
따라서, 이번 분석에서는 해당 취약점뿐만 아니라 이전에 발생한 취약점들에 대한 분석과 PoC를 함께 수행하며, 관련 취약점들의 패치가 어떻게 우회되었는지를 살펴보겠습니다.

Vulnerability Context

먼저, 취약점 분석 이전에 Apache OFBiz 프레임워크에 대해 알아보겠습니다. 참고로 본 보고서에서는 해당 프레임워크에 대한 자세한 설명보다는 취약점 분석에 필요한 사전 지식만을 정리하겠습니다.

Apache OFBiz 란?

Apache OFBiz는 오픈소스 ERP(Enterprise Resource Planning) 프레임워크로, 기업의 다양한 비즈니스 프로젝트를 통합하여 관리할 수 있도록 설계된 솔루션입니다.
해당 프레임워크는 기업의 다양한 비즈니스 프로세스를 통합하여 관리할 수 있도록 설계 되었으며, ERP 기능 뿐만 아니라 CRM(Customer Relationship Management), 전자상거래, 회계, 제조, 프로젝트 관리 등의 기능을 제공합니다.

주요 기능 및 특징

Apache OFBiz 1-Day 취약점 살펴보기: 개요 (1/7)
One-Day Analysis
2025/03/04

Introduction

해당 취약점을 분석하는 과정에서 Exploit을 수행하기 위해 PHP Wrapper 중 php://filter 스트림을 이용 했는데, 이를 활용한 LFI2RCE(Local File Inclusion to Remote Code Execution) 기법에 대해 자세히 알아보겠습니다.

PHP Wrapper 란?

PHP에서는 다양한 데이터 소스(파일, HTTP 요청, FTP 서버, 압축 파일 등)에 대한 일관된 접근 방식을 제공하기 위해 Stream Wrapper 라는 개념을 도입했습니다. 이 스트림 래퍼는 데이터 소스에 접근하기 위한 URL 스타일의 표기법을 사용하며, 프로토콜과 유사한 방식으로 리소스를 식별하고 처리합니다.

Wrapper 종류

Wrapper는 기본적으로 여러 가지 스트림 래퍼를 제공합니다. 해당 래퍼들을 보면 모두 URL 스타일 표기법을 사용하는 것을 볼 수 있으며, 각각의 래퍼는 특정 프로토콜을 나타내는 접두사와 그 뒤에 오는 리소스 경로로 구성되어 있습니다.
예를 들어, 로컬에 있는 파일을 읽을 때는 아래와 같이 사용합니다.
또한, HTTP 요청을 보낼 때는 다음과 같이 사용할 수 있습니다.
PHP Wrapper, php://filter를 이용한 LFI2RCE 기법: PART 1
Web Security
2025/02/10

PHP 래퍼(php://filter)를 이용한 LFI2RCE

악성코드가 포함된 파일을 업로드하거나 로그 파일을 통해 PHP 코드를 입력하는 방식은 웹 서버의 파일 시스템에 직접적인 접근이 필요하다는 제약이 있습니다. 또한, 웹 서버의 보안 정책이나 설정에 따라 파일 시스템 접근이 제한되어 있을 수 있으며 로그 파일의 위치가 다르거나 접근 권한이 없는 경우도 많습니다.
하지만, PHP 래퍼(php://filter)를 활용하면 파일 시스템 접근 권한이나 로그 파일 위치와 같은 제약 사항에 구애받지 않고 공격을 수행할 수 있습니다.

php://filter 래퍼의 동작 방식

먼저 php://filter 를 이용한 LFI2RCE 공격 원리를 이해하기 위해 LFI 취약점이 발생하는 환경에서 php://filter 가 어떻게 동작 되는지 살펴보겠습니다.

PHP 코드 실행

php://filter 를 사용할 때, 필수 매개변수 resource 를 지정해야 합니다. 이는 필터링하려는 스트림(파일 경로 혹은 입력 스트림)을 지정하는 것인데, PHP 파일 경로를 지정할 경우 해당 PHP 파일이 불러와지고 해당 스트림이 include 에 의해 실행됩니다.
예를 들어, 웹 서버에 앞서 살펴본 LFI 취약점이 있는 index.php 와 load.php 가 존재합니다.
이 경우 load.php 파일을 index.php 의 include 함수를 이용하여 파일 경로를 직접 입력하지 않고 아래 php://filter 를 사용하여 불러오려면 다음과 같이 resource 매개변수에 load.php 경로를 지정하여 요청하면 됩니다.
PHP Wrapper, php://filter를 이용한 LFI2RCE 기법: PART 2
Web Security
2025/02/10

Challenge

Introduction

주어진 문제는 Kotlin으로 개발된 Spring 웹 애플리케이션이며, Docker로 배포되어 있습니다.
해당 웹 애플리케이션의 main() 함수는 WebwebhookhookApplication.kt 에 정의되어 있으며, 객체 State 의 arr 배열에 StateType 인스턴스를 추가하고 있습니다.
이어서 State 객체는 State.kt에 정의되어 있습니다. 이 객체는 StateType 클래스의 인스턴스들을 저장하는 배열 arr을 가지고 있습니다.
또한, StateType 클래스는 URL로 변환될 문자열 hook, 템플릿으로 사용될 template, 그리고 반환값으로 사용될 response 총 3개의 속성을 가집니다. 이 중 hook 속성은 URI.create(hook).toURL() 구문을 통해 입력된 문자열을 URL 객체로 변환하여 저장합니다.
마지막으로 웹 애플리케이션의 엔드포인트는 MainController.kt에 정의되어 있으며, 총 3개의 엔드포인트가 있습니다. 이 중 /webhook과 /create 엔드포인트는 모두 앞에서 확인한 State 객체를 참조하고 있습니다.

End-Point Analysis

주어진 문제 웹 애플리케이션의 각 엔드포인트는 다음과 같습니다.
[2025 Iris CTF - WEB] webwebhookhook 문제 풀이 및 설명
CTF
2025/01/12