> For the complete documentation index, see [llms.txt](https://redryan.gitbook.io/studyjoon/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://redryan.gitbook.io/studyjoon/hacking/bhpt/undefined-4/http/undefined-1.md).
# 파일 업로드 취약점 진단
Content-Type 헤더 부분에 MIME Type이 지정된 값이 들어가 있다. 이 Content-Type 헤더 부분에 있는 MIME 부분을 수정하면 우회가 가능하다.
## HTTP - 파일 업로드 취약점 진단
파일 업로드를 허용하는 웹앱들은 유저가 업로드한 파일을 기반으로 파일 안의 데이터를 파싱에 백엔드에 저장하거나 활용할 수 있습니다. 때로는 업로드 한 파일 안의 내용을 바로 프론트엔드 등에 적용하는 경우 (양식, 디자인, 등)도 있습니다. 혹은 PDF나 이미지 등의 업로드된 이미지 파일을 웹 앱의 미들웨어를 거쳐 바로 유저에게 보여주는 경우도 있습니다. 이처럼 파일 업로드는 다양한 방법으로 웹 앱의 다양한 위치에서 사용됩니다.
파일 업로드는 워낙 다양하게 사용되기 때문에 앞서 HTTP 취약점 공격에서 언급했었던 소스와 싱크(Source & Sink)의 개념을 다시 한 번 생각해봐야 합니다. 여기서 소스는 사용자에 의해 제공되는 파일을 의미하며, 싱크는 웹 애플리케이션이 이 파일을 어떻게 저장, 파싱, 사용하는지에 관한 부분입니다. 따라서 파일 업로드 기능을 마주했을 때 유저로서 어떤 소스(파일)을 제공할 수 있는지, 그리고 해당 소스가 웹 앱의 어느 싱크에 들어가 사용될 것인지에 대해서 생각해 봐야 합니다.
파일 업로드 기능은 자주 악용되기 때문에 웹 개발을 하는데 있어서도 신경을 많이 쓰는 편입니다. 더 정확하게는 웹 개발에 사용되는 다양한 프레임워크에서 파일 업로드와 관련된 보안적인 기술들을 이미 적용해놓은 경우가 많습니다. 다음은 파일 업로드 보안을 강화하기 위해 사용되는 몇 가지 기술입니다:
**1. 파일 확장자 검증:** 화이트리스트와 블랙리스트로 나뉩니다. 블랙리스트는 우회 방법이 다양하기 때문에, 보다 안전한 화이트리스트 사용을 권장합니다.
**2. 파일 이름 변경:** 사용자가 설정한 파일 이름 대신 해시화된 이름이나 임의의 문자열을 포함한 이름으로 변경합니다.
**3. 파일 이름 검증:** 파일 이름 변경이 불가능하거나 비즈니스 로직에 맞지 않을 경우, 파일 이름을 검증하고 필터링해야 합니다. 특히, 디렉토리 변경을 유발할 수 있는 문자들을 제거하는 것이 중요합니다.
**4. Content-Type 검증:** 정해진 MIME-Type의 파일만 업로드가 가능하도록 설정합니다.
**5. 파일 권한 변경:** 파일이 실행되지 않도록 Execute 권한을 삭제합니다.
**6. 파일 저장 위치 보안:** 파일의 위치나 접근 권한을 외부에 노출하지 않도록 보호합니다.
공격자의 입장에서는 이러한 보안 기법들을 우회하는 방법에 대해 연구해야 합니다. BHPT에서는 모든 웹 기반 기법이나 우회 방법에 대해서 다루지 않기 때문에 위와 같이 키워드들을 드리고, 일단은 간단한 파일 업로드 우회 방법에 대해서 다룹니다.
파일 업로드 공격을 시도하기 전에는 다음과 같은 사전 조건들을 고려해야 합니다:
1. 업로드된 파일은 어떤 용도로 사용되는가?
2. 파일은 어디에 저장되는가? 백엔드 접근이 제한되어 있을 수 있으므로, 정보 수집이 필요합니다.
3. 어떤 종류의 파일 확장자가 업로드가 가능한가?
### 취약점 진단
파일 업로드 취약점 진단은 소스코드에 접근이 가능하지 않는 이상 직접 시도해보는 수 밖에는 없습니다. 이처럼 검증되지 않고 웹앱이 의도하지 않은 소스(Source)들을 마구 사용하는 방식의 블랙박스 테스팅을 퍼징(Fuzzing)이라고 부릅니다.
파일 업로드 진단 및 공격은 굉장히 다양하게 많이 있지만, BHPT에서는 다음의 기본적인 파일업로드 공격 기법들에 대해서 배워봅니다.
1. 파일 확장자 변경
2. 파일 Content-Type (Mime-type) 변경
3. 파일 매직바이트 변경
각각의 공격 종류들에 대해서는 실습을 진행하며 알아봅니다.
## 실습
실습은 `mod3ex` 실습 머신의 포트 4280에서 실행중인 DVWA 애플리케이션에서 진행합니다. `admin:password`로 로그인 한 뒤, `Create/Reset Database`를 누르고, 왼쪽의 `DVWA Security`에서 `low`로 난이도를 바꿔줍니다. 그 뒤, 왼쪽에서 `File Upload` 탭으로 가 실습을 진행합니다.
### 1. 파일 확장자 변경
파일 업로드 방어 기법중 가장 간단한 방법은 파일의 확장자를 화이트리스트 처리하거나 블랙리스트 처리하는 것입니다. 예를 들어 다음의 PHP 코드 예시를 살펴봅니다.
```sql
```
이런 코드의 경우 특정한 파일 확장자 - `.php`, `.asp`, `.jsp` 를 사용하고 있기 때문에 파일 확장자의 대소문자를 바꿔준다거나 (`.pHP`), 다양한 버전의 파일 확장자를 사용한다면 (`.php5`,`.php6`) 우회가 가능합니다.
파일 확장자 우회를 위해 개념증명용 코드를 다양한 파일 확장자 이름으로 저장합니다.
```sql
echo "echo " > test.PhP
echo "echo " > test.php5
echo "echo " > test.php6
```
파일 업로드한 상태에서 바로 URL 주소창으로 접근한 모습이다.
LFI를 통해 업로드한 파일로 접근한 화면이다.
다른 시나리오로는 파일 확장자를 확인할 때 마지막 확장자만 확인하는 경우도 있습니다. 이런 경우 파일 확장자 검증 코드에 따라 확장자를 두개 붙이거나, 중간에 널 바이트(Null byte)를 붙여 파싱하는 코드의 논리를 속일 수도 있습니다.
```sql
echo "echo " > test.php.jpg
echo "echo " > test.php%00.jpg
```
이렇게 업로드 된 파일들은 일반적인 URL로 방문했을 경우 `.jpg`의 이미지로 보이지만 `www.example.com/hackable/uploads/test.php.jpg`, 파일 확장자를 신경 안쓰고 보여주는 LFI 공격이나 다양한 미들웨어로 방문했을 경우 안에 들어가 있는 PHP 코드가 실행될 수도 있습니다. 혹은, 널 바이트를 붙였을 경우 문자열 파싱 시 널 바이트는 문자열이 끝난다는 의미를 가지고 있기 때문에 웹 서버가 `test.php%00.jpg` 라는 파일 이름으로 파일을 저장하지 않고 `test.php` 라는 파일 이름으로 저장할 수도 있습니다.
> 이처럼 파일 업로드 테스팅의 경우 웹 앱의 백엔드가 파일 확장자를 어떤 논리로 파싱하느냐에따라 공격이 성공할수도, 실패할 수도 있습니다. 완벽한 블랙박스 테스팅에서는 다양한 파일 확장자를 준비한 뒤 퍼징을 해보는 수 밖에는 없습니다.
### 2. 파일 Content-Type 변경
파일 Content-Type은 웹 앱에게 어떤 종류(이미지, 영상, 실행파일, 텍스트, 등)의 파일을 업로드한다 라는 것을 알려주는 의미의 HTTP 요청 헤더입니다. 이 헤더안에는 파일의 [MIME 종류](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types)를 지정함으로서 웹 앱이 파일을 어떻게 처리해야하는지 알려줍니다. 많이 알려진 MIME Type의 경우는 다음과 같습니다:
* `text/plain`: 일반적인 평문 문자열
* `image/jpeg`: JPEG 이미지
* `application/json`: JSON 포멧
* `application/pdf`: PDF 파일
파일 업로드 검증 논리가 파일의 MIME 종류를 파싱한다면, 공격자의 입장에서는 HTTP 요청을 보낼 때 `Content-Type` 헤더의 값을 바꿔 업로드한 파일의 MIME 종류를 바꿀 수도 있습니다. 예를 들어 `.exe` 파일의 실행파일을 업로드 하며 `image/jpeg` 라는 이미지 파일이라고 웹 앱을 속일 수도 있습니다.
예를들어 DVWA 파일 업로드의 `medium` 난이도는 다음과 같이 파일의 MIME 종류를 확인합니다.
```sql
{$target_path} succesfully uploaded!";
}
// 실패
else {
echo '
Your image was not uploaded. We can only accept JPEG or PNG images.
';
}
}
?>
```
이 경우 하드코딩 된 MIME 종류 화이트리스트(`image/jpeg`, `image/png`)를 사용하고 있습니다. 하지만 파일 자체가 실제로 이미지(jpeg, png) 파일인지는 확인하지 않습니다. 따라서 파일 업로드를 할때에도 버프스위트로 HTTP 요청의 `Content-Type`에서 MIME 종류를 바꿔주면 됩니다.
### 3. 파일 매직 바이트 변경
파일의 확장자는 사람/유저가 파일을 알아보기 편하라고 만든 파일 이름의 한 섹션일 뿐입니다. 실제로 프로그램과 운영체제에서 파일을 구분하기 위해서는 파일 시그니쳐(File Signature)/매직 바이트(Magic Byte)라는 것을 사용합니다. 매직 바이트는 파일 형식을 식별하기 위해 파일의 시작 부분에 배치된 특정 바이트 패턴입니다. 예를 들어 PNG 이미지 파일의 가장 첫 몇개의 바이트를 살펴보면 다 `89 50 4E 47 0D 0A 1A 0A` 형식의 바이트가 있습니다.
예를 들어 고양이 파일을 다운받아 해당 파일의 바이트들을 살펴봅니다.
```sql
└─# wget "https://github.com/max-mapper/cats/blob/master/cat_photos/00092f6ec7a911e1be6a12313820455d_7.png?raw=true" -O cat.png
# 가장 첫 8개의 매직 바이트가 89 50 4E 47 0D 0A 1A 0A 인 것을 확인
└─# xxd cat.png| head -2
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452 .PNG........IHDR
00000010: 0000 0264 0000 0264 0802 0000 0030 73aa ...d...d.....0s.
```
이런 파일의 매직바이트를 확인해 파일 업로드 검증을 하는 웹 앱의 경우 웹 개발 프레임워크의 내제된 함수를 사용하는 경우가 많이 있습니다. 예를 들어 DVWA의 High 난이도의 경우 다음과 같은 소스코드를 사용합니다.
```sql
{$target_path} succesfully uploaded!";
}
// 실패
else {
echo '
Your image was not uploaded. We can only accept JPEG or PNG images.
';
}
}
?>
```
Medium 난이도와 달라진 점이 있다면 [`getimagesize()`](https://www.php.net/manual/en/function.getimagesize.php) 함수를 이용해 파일의 이미지 크기를 가져온다는 것입니다. 이미지 크기를 가져오기 위해 먼저 매직바이트를 확인하는 과정을 거칩니다.
{% code overflow="wrap" lineNumbers="true" %}
```sql
# 매직 바이트를 cat.png에서 test.php로 옮김. 그 후 test.php를 test.png 파일명으로 변경.
└─# (head -c 8 cat.png; cat test.php) > temp && mv temp test.php && cp test.php test.png
# test.png 파일에 PNG 매직 바이트와 PHP 코드가 같이 있는 것을 확인.
└─# xxd test.png
00000000: 8950 4e47 0d0a 1a0a 3c3f 7068 7020 7068 .PNG.....
이 명령어는 `test.php` 파일을 PNG 파일 형식으로 위장하는 작업을 수행합니다. 이를 통해 파일을 업로드할 때 PHP 코드가 포함된 파일을 PNG 이미지 파일로 위장할 수 있습니다. 각 명령어의 역할은 다음과 같습니다:
1. **`head -c 8 cat.png`**: `cat.png` 파일의 처음 8바이트를 읽습니다. PNG 파일의 헤더는 일반적으로 8바이트로 구성되어 있으며, 이 헤더를 사용하여 파일이 PNG 형식임을 나타냅니다.
2. **`;`**: 명령어 구분자입니다. 앞의 명령어가 끝난 후 다음 명령어를 실행합니다.
3. **`cat test.php`**: `test.php` 파일의 내용을 읽습니다.
4. **`>`**: 출력 리다이렉션 연산자입니다. 앞의 명령어 출력 결과를 `temp` 파일에 저장합니다.
5. **`mv temp test.php`**: `temp` 파일을 `test.php`로 이름을 변경합니다. 이로 인해 `test.php`는 PNG 헤더와 PHP 코드가 결합된 파일이 됩니다.
6. **`cp test.php test.png`**: `test.php` 파일을 `test.png`로 복사합니다. 이로 인해 `test.png`는 PNG 파일로 위장된 PHP 파일이 됩니다.
```
{% endcode %}
이후 파일을 업로드 합니다.
이렇게 업로드 된 파일의 경우 매직 바이트는 PNG이기 때문에 직접 URL로 방문하면(`:4280/hackable/uploads/test.png`) 열리지 않습니다. PNG 이미지 파일이지만 매직 바이트만 있어 보여줄 이미지가 없고, 안에 들어가 있는 것은 PHP 코드이기 때문입니다. 하지만 파일의 매직 바이트를 신경쓰지 않고 오로지 파일 속의 코드만 보여주고 실행하는 LFI와 같은 두번째 공격이 가능하다면 업로드 한 `test.png` 파일 안 PHP 코드가 실행되게 됩니다.
### 4. 자동화 실습
앞서는 수동으로 파일 업로드 우회 취약점 진단을 진행했습니다. 파일 확장자, 이름, MIME 종류, 매직 바이트 등을 바꾸는 것은 한번 두번 하기는 나쁘지 않지만, 여러개의 조합이 들어가기 시작하면 개념증명용으로 만들어야 하는 파일의 종류가 늘어나게 됩니다. 따라서 파일 업로드의 경우 다양한 자동화 툴을 사용해 취약점 진단 시간을 줄이는 것이 권장됩니다.
> 실무에서는 버프스위트 프로 버전의 Extension인 Upload Scanner 등을 많이 사용합니다. 단, 버프스위트 프로는 가격이 좀 있기 때문에 BHPT에서는 버프스위트 프로를 가지고 실습을 진행하지 않습니다.
앞서 수동 진단에서도 언급했지만, 블랙박스 테스팅 파일 업로드의 경우 직접 파일을 업로드 해보기 전에는 웹 앱이 취약한지 취약하지 않은지 알 수 없습니다. 따라서 많은 숫자의 파일을 업로드하는 퍼징을 진행해야 합니다. 이 경우 반드시 고객사와 사전 협의를 거쳐 어떤 파일들을, 어떤 디렉토리에, 언제 업로드 할 것 인지 고지해야합니다. 또한, 테스트가 끝난 뒤에는 파일들을 직접 삭제해 아티팩트를 남기지 않도록 합니다.
자동화 실습에서는 DVWA 난이도를 Medium으로 올려 실습을 진행합니다.
자동화 실습에서는 오픈소스 툴인 [`fuxploider`](https://github.com/almandin/fuxploider)를 사용합니다.
{% code lineNumbers="true" %}
```sql
sudo apt install python3-venv
cd /opt
git clone https://github.com/almandin/fuxploider.git
cd fuxploider
python3 -m virtualenv venv
source venv/bin/activate
pip3 install -r requirements.txt
python3 fuxploider.py -h
```
{% endcode %}
설치가 끝난 뒤에는 공격을 진행합니다. 대상의 IP주소, 포트, DVWA의 파일 업로드 엔드포인트 `/vulnerabilities/upload/` 등을 고려합니다. 또한, DVWA의 경우 한번 로그인을 한 다음 공격을 진행하는 것이기 때문에 쿠키의 `PHPSESSID`과 `security` 난이도도 줘야합니다.
먼저 DVWA에 로그인을 한 뒤 아무 페이지나 클릭해 쿠키를 복사합니다.
> 여러분들의 PHPSESSID 값은 다 다를겁니다.
그 뒤, 파일 업로드를 테스트 겸 해봅니다. 파일 업로드 POST 요청을 보낼 때 `Upload=Upload` 등의 추가적인 파라미터가 들어가는 것을 확인합니다
그 뒤, fuxploider 툴을 이용해 파일 업로드가 실행되는 `/vulnerabilities/upload/` 엔드포인트에 파일 업로드 진단을 시작합니다. `--cookies`로 PHPSESSID 및 난이도를 추가해주는 것도 잊지 않습니다.
{% code overflow="wrap" %}
```sql
└─# python fuxploider.py --url http://172.31.179.189:4280/vulnerabilities/upload/ --cookies "PHPSESSID=097c5cb692c1c012cbf1af259e77df75; security=medium" --not-regex "not uploaded" -d 'Upload=Upload'
2023-12-18 16:25:38 WARNING - No uploads folder nor true regex defined, code execution detection will not be possible. (Except for templates with a custom
codeExecURL)
2023-12-18 16:25:38 INFO - ### Starting detection of valid extensions ...
2023-12-18 16:25:38 INFO - Extension jpg seems valid for this form.
2023-12-18 16:25:38 INFO - Extension jpeg seems valid for this form.
2023-12-18 16:25:38 INFO - Extension jpe seems valid for this form.
2023-12-18 16:25:38 INFO - Extension png seems valid for this form.
2023-12-18 16:25:43 INFO - ### Tried 100 extensions, 4 are valid.
Extensions detection: 0:00:05.153266
Start uploading payloads? [Y/n]: Y
2023-12-18 16:25:45 INFO - ### Starting code execution detection (messing with file extensions and mime types...)
2023-12-18 16:25:46 INFO - Upload of 'tmpetqnrzcr.php' with mime type image/jpeg successful
2023-12-18 16:25:46 INFO - True regex matched the following information: True
2023-12-18 16:25:46 INFO - Upload of 'tmpdr6i01m9.php1' with mime type image/jpeg successful
2023-12-18 16:25:46 INFO - True regex matched the following information: True
2023-12-18 16:25:46 INFO - Upload of 'tmp5tctkmd7.php2' with mime type image/jpeg successful
2023-12-18 16:25:46 INFO - True regex matched the following information: True
[ . . . ]
```
{% endcode %}
먼저 웹 앱이 어떤 파일 확장자를 받는지 확인하고 있습니다. `jpg, jpeg, jpe, png` 등의 파일 확장자를 받는 것을 확인합니다. 그 뒤 파일 이름과 MIME 종류를 바꿔가며 약 500\~1000개의 파일 업로드 퍼징을 진행합니다.
### 연습 문제
* `mod3ex`의 포트 4280에서 실행중인 DVWA를 상대로 파일 확장자 변경, Content-Type(MIME Type) 변경, 매직 바이트 변경을 통해 파일 업로드 우회가 가능한지 실습해보세요.
* 매직 바이트 실습을 할 때 PNG 파일이 아닌 JPG나 JPEG 파일을 통해 실습해보세요. 관련 파일들의 매직 바이트는 어디서 찾을 수 있으며, JPG/JPEG의 경우 몇 개의 바이트가 매직 바이트인가요?
