[기록일지] 📚 15주차 (File Upload 대응·우회 / FLI(File Include) / File Download 취약점)

File Upload 대응·우회

File Upload Vuln

파일 업로드 취약점은 공격자가 원하는 임의의 파일을 업로드할 수 있는 취약점이다.

업로드 가능하다고 끝이 아니고 해당 파일을 실행시킬 수 있어야한다. 그래서 업로드한 파일의 정확한 경로를 파악하는 것이 중요하다.

~~/~~/webshell.php?cmd=

웹 상에 파일이 위치한 경로를 알아야 위와 같이 명령어 파라미터를 넣어서 요청해 줄 수 있다는 것이다. 정확한 경로를 알지 못하여 파일을 업로드 했더라도 요청이 불가능하다면 무용지물이기 때문이다.

그래서 이를 숨기고, 경로를 알지 못하도록 파일의 경로를 알기 힘들게 해놓는 것은 물론 확장자는 그대로지만, 파일명을 바꾸어서 저장되는 경우가 일반적 (그대로 저장되는 경우가 많지 않다.) 이기 때문에 이를 알아내야 한다.

ex) webshell.php -> Fu0C.sfctifmm.php

즉, 파일이 저장된 정확한 위치와 함께, 해당 파일의 저장된 이름을 포함한 완전한 경로를 파악할 수 있어야한다는 것이다.

파일 업로드 공격의 가장 대표적인 공격은 웹쉘(Webshell) 공격으로, File Upload 공격과 웹쉘을 동일시 하는 경우가 일반적이다.

 

웹쉘(Webshell)

웹쉘(Webshell)공격은 서버 측에서 실행 가능한 파일을 업로드할 수 있는 공격을 말한다.

웹쉘파일은 파일 업로드나 취약점을 이용하여 서버에 업로드 하기 때문에 일반적으로 단독파일로 사용하는 경우가 대부분으로 단일 파일로 간단하게 구성된 웹쉘은 다음과 같다.

한줄 웹쉘 / Single-line Webshell / One-line Webshell / 일구화목마(后门木马)​ 라고 불리우며 php를 예시로 들면 코드는 다음과 같다.

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

웹쉘파일은 해당 서버에서 실행할 수 있는 파일을 업로드해야 한다.

업로드한다고 끝이 아니고 이 파일을 실행해야 하는데, 여기서 해당 파일 업로드 및 실행에 대한 잘못된 정보들이 많이 존재한다.

---

잘못 생각하고 있는 우회기법

(*) Image Web Shell

파일을 올릴때 webshell.php로 저장했더니 업로드가 안되었다고 가정해보자.

그런데? webshell.php.jpg로 올렸더니 저장되고 실행도된다?! 라는 말이다.

| 결론은 불.가.능 하다는 것이다. 실행될 여지가 없다.

 

Double Extension

File Upload Bypass 기법으로서 이중확장자(double extension)가 가능한 것 처럼 보이는 경우를 말한다.

파일을 올릴때 webshell.php로 저장했더니 업로드가 안되었다고 가정한 상태에서 위의 확장자와 반대로 webshell.jpg.php와 같은 확장자의 파일인데 업로드가 가능했다?!

만약에 위의 방식이 가능했다면 이것은 성공적인 Bypass 기법인 것이 아니라 웹 애플리케이션 개발이 잘못된 것이다.

파일 업로드의 저장하는 기능을 구현할 때 개발을 잘못한 것인데, (.)을 기준으로 split을 해서 구현을 하는 경우, 가장 앞의 (.)을 기준으로만 저장을 한다면? 실제 저장될 때는 webshell.jpg.php로 저장되지만, .(jpg)로 인식된다는 것이다.

 

Double Encoding (feat. War Game)

webshell.php.jpg 라고 업로드된 파일이 php로서 실행되는 것이다. 해당 취약점은 워게임 측에서 (.php.jpg...)와 같은 더블 인코딩이라는 기법이 있다... 라고 일부러 만들어놓은 것으로 실존하는 취약점이 아니라는 것이다.

만약 실제로 webshell.php.jpg라고 저장되어 있는데 웹서버가 갑자기 뒷부분을 잘라먹고 webshell.php라고 인식한다? 는 것은 말이 안된다는 것이다.

webshell.php.jpg가 가능하다면?! webshell.jpg로 넣어도 가능해야한다는 것으로서 결론은 불가능하다는 것이다.

---

확장자를 속이는 방법

악성코드 유포를 위해, 확장자를 속이는 방법에 대하여 알아보자.

NULL Byte Injection

webshell.php%00.jpg

(%00) NULL 값을 이용하여 .jpg 부분이 날아가는 것으로 실제로는 webshell.php와 동일하게 되는 것이다.

 

.htaccess 파일

(.htaccess)는 웹 설정 파일로서 아파치(Apache) 서버에서 실행할 확장자를 지정하는 파일이다.

일반적으로는 숨김처리 되어 있으며, 해당 파일을 수정하거나 덮어 쓰는 경우, 혹은 업로드하는 경우에는 원하는 확장자의 파일을 마치 실행파일 처럼 이용할 수 있다는 것이다.  (ls -> 숨김 파일 -> ls +al)

즉 다음과 같이 .jpg , .png를 .php로 실행하라 라고 할 수 있다는 것이다.

AddType application/x-httpd-php .jpg .png

대체할 확장자에 대하여는 기존에 존재하는 확장자가 아니여도 된다. 원하는대로 확장자 명을 입력하고 이를 이용할 수 있다.

AddType application/x-httpd-(실행하는 확장자) .(대체할 확장자1) .(대체할 확장자2) .(대체할 확장자3)
(AddType MIME_TYPE FILE_EXTENSION)

서버에서 실행될 확장자 규칙을 정해주는 것으로 해당 디렉토리만 영향을 받게된다.

 

File Upload의 대응방안(불충분)

파일 이름 난독화

저장되는 파일의 경로를 감추는 전략으로서 파일의 이름을 난독화하여 추측하기 어렵게 하는 것이다. 파일에 표기가 안될 뿐 아니라, 파일의 경로를 추측하지 못하도록 하는 것이다.

다운로드를 하는데 업로드 경로를 모를 수가 있나? YES

업로드한 파일을 웹 경로 어딘가에 저장해두고, 그것을 직접 접근해서 다운로드 하도록하는 경우는 다음과 같다.
~~/uploads/files/poc.php
위의 경로에 파일이 있는 경우, 경로를 알기 쉬워 직접 접근하는 경우에 인가 취약점 문제가 발생할 수 있다.(로그인한 사람만 파일을 가져가게 해주세요. 라고 하더라도) 이 방식은 모든 사람이 다운로드 가능하게 된다.

하지만 다음과 같이 하는 경우 경로를 모를 수 있다.
download.php?filePath=
download.php?boardId=
download.php?fileId=
위와 같이 다운로드를 위한 기능 파일을 만들어두고,  db에서 조회한다음 가져오는 경우 경로를 모를 수 있다는 것이다.
DB에는 파일의 id와 파일명 경로가 저장되어 있고 파라미터로 받아와서 DB에서 조회를 하고 다운로드 하게 되는 것이다.

<?
php user 확인 : gear
(허가된 사람만 다운로드 가능하도록 구현)
?>

하지만 해당 대응방안의 경우 SQL Injection 취약점으로 파일 경로가 노출되는 경우의 수가 잠재적으로 존재하는 조건부 대응 방안으로서 언제든지 뚫릴 준비가 되어 있게된다.

따라서 추천하지 않는 대응방법으로 미흡한 대응방법에 해당한다.

> 프로필 사진의 경우 경로가 노출될 수 밖에 없다. 그 이유는 Web Page에서 <img> 태그를 통해 요청을 할 것이기 때문이다. (불충분한 인가 취약점의 가능성이 존재한다.)

 

확장자 화이트리스트 기반 필터링

Content-Type Header를 이용하면 파일 이름의 난독화 보다는 조금 더 안전할 수 있다. 하지만 허용되는 확장자의 값으로 변조된 packet을 전달하거나 %00 과 같은 NULL Injection으로 우회가 가능할 여지가 존재한다. 

일반적인 php의 MIME Type

Content-type: application/x-php

위와 같이 php로 되어 있는 확장자를 업로드가 가능한 확장자로 변조하여 속이는 것이다.

Content-type: image/jpeg

 

File Extension 확인

잘못된 file extension의 검증 로직의 경우 아래와 같은 우회 기법이 가능할 수 있다.

1) NULL Byte Injection을 이용하여 우회가 가능하다.
webshell.php%00..jpg

2) 대소문자의 검사가 미흡한 경우에도 우회가 가능하다.
php -> pHp, phP

3) Alternative File Extensions을 사용해서 우회가 가능하다.
https://book.hacktricks.xyz/pentesting-web/file-upload

 

파일의 시그니쳐 확인

파일 검증 로직으로서 파일 검증 함수를 이용하여 파일의 시그니쳐(File Signature)를 확인하는 방법이 있다.

File Signature는 file의 맨 첫부분에 해당 확장자에 대한 시그니쳐가 담겨져 있는데 이를 말한다.

http://forensic-proof.com/archives/300

파일 시그니처 모음 (Common File Signatures) | FORENSIC-PROOF

파일 검증 로직에 대하여 라이브러리를 이용하거나, 직접 제작해서 사용하는데 제대로 구현하지 않는다면,  이것를 변경하여 다른 확장자로서 인식하도록 하거나, 해당 확장자의 시그니처는 그대로 두고 파일 가장 뒷쪽에 웹쉘을 삽입하는 경우에 우회가 가능할 수 있다.

 

File Upload의 대응방안(여지가 없는 방법)

BLOB / CLOB

DB에 파일을 저장하는 방법으로서 BLOB / CLOB 파일 형식을 이용하는 것이다.

파일 업로드가 가능한 근본적인 원인은 웹 서버에 파일로 저장되기 때문에 문제가 되는 것이었는데, 이것을 DB 테이블 안에 저장한다면? 실행될 여지가 없어진다는 것이다.

그런데 여기서 문제는 DB가 모자랄 수 있다는 것이다. 그러므로 파일 저장 서버를 따로 만들어준다.

NAS

파일 저장 서버로서 해당 서버는 웹 서버와 완전 분리하고 해당 파일이 실행될 수 있는 여지를 만들지 않으면된다.

동적 페이지 처리를 위해 Web Server에 WAS가 연결되어 동작하듯이 파일을 관리하는 NAS Server를 연결하여 따로 관리하기 위함이다. 

WEB - WAS - DB
WEB - NAS

여기서 중요한 것은 NAS Server의 경우 서버측 코드를 실행할 수 있는 환경이 구축되어 있어서는 안된다. 파일을 실행되지 않도록 하기 위해서 따로 관리하는 것을 목적으로하는데, 코드가 실행 가능하다면 문제가 된다.

즉 php 파일을 저장한다면 php 자체가 설치되어 있지 않으면 실행 자체가 불가능하다는 것이다.

---

Webshell의 단점

웹쉘(webshell)을 올려서 cmd 명령을 통해 경로를 이동하며, 내부를 확인하는 것에 대하여 단.발.성 이라는 것이다.

그래서 한번 명령을 입력하고 나면 해당 디렉토리에 유지되는 것이 아니라 다시 기존의 경로로 돌아오기 때문에 경로부터 다시 입력해줘야한다는 것이다.

즉 일회성/휘발성 이기 때문에 상태에 대한 저장이 안되기 때문에 발생하는 것으로 그렇기 때문에 Reverse Shell이 필요하다.

---

FLI(File Include)취약점

Webshell 취약점의 자매품격인 취약점으로 File Include 취약점(File Inclusion)이 있다.

include / include_once / require / require _once

위와 같은 including 기능을 가진 코드가 존재하는 곳에서 발생 가능한 취약점이다.

db정보의 경우 id/pw가 사용할 때마다 필요하다. 그런데 이것을 필요한 모든 페이지마다 쓰는 것이 아니고 하나의 php에 계정에 관한 정보를 넣어두고, 필요한 경우에 가져와서 쓰는 것이다. 이렇게 하면 중복되는 동일한 코드를 적성해두고 가져다 쓰는 방식을 취함으로써 효율성을 높일 수 있다.

dbConfig.php
<?php
(php코드로 저장되어 있는 db 계정 정보)
?>

login.php
<?php
include('dbConfig.php');
(위의 파일 내용을 그대로 가져와서 복붙하고 실행)
?>

위와 같이 include를 쓰는 경우 해당 파일의 내부 내용을 그대로 가져와서 복사 붙여넣기하듯이 실행한 후 다음으로 넘어간다는 것이다.

네비게이션 바 (nav.php) 같은 경우도 마찬가지이다. 모든 페이지에 띄우는 부분은 각각에 만들어 주는 것이 아니라 nav.html, nav.php와 같이 만들어서 띄운다는 것이다.(헤더(Header) / 푸터(Footer))

* 프로그래밍, 해킹, 컴퓨터 공부
> 게으른 사람이 잘함. 한번에 다바꿈.
> 성실한 사람. 하나 하나 가서 바꿈.
결론 : 게으르기 위해서 노력하고 부지런한 사람이 되자!

따라서 Web Page에서 파라미터의 값에 따라서 다른페이지를 보여주기 위해 ?page= 과 같은 방식으로 받는다면 해당 취약점을 생각해 볼 수 있다.

서버에 존재하는 임의의 파일을 가져올 수 있다는 것이다. 즉, DB 계정을 받아오는 파일 또한 털린다는 것이다.

LFI 취약점이 있는지 확인하기 위해서는 include가 있는 것을 인지해야 하기 때문에
이것은 웹 페이지를 만들어보면서 생각해봐야한다.

해당 취약점은 서버에서 원하는 파일을 가져올 수 있다. 단, 소스 코드 빼고... 라는 생각에 별거 아닌 취약점이라고 생각할 수 있다. 

하지만 이것을 역으로 이용한다고 생각을 해야한다. 결론부터 말하자면 엄청난 취약점이다.

소스코드를 얻어올 수 없는 이유는 서버가 실행해서 결과값만 전달해주기 때문이다. 그렇기 때문에 원하는 서버 측 코드가 삽입된 파일을 업로드해 해당 파일을 가져온다면? 코드가 실행된 결과를 얻어올 수 있다는 것이다.

 

FLI -> LFI 

이미지 파일로 바꾸어준 실행파일(webshell.php -> webshell.jpg) 을 넣는다면? 이미지 파일로 넣고 불러주는 경우 내부의 소스코드를 실행하고 준다는 것이다. 이것은 LFI 취약점으로 Local File Include 취약점에 해당한다.(File Include와는 다른 취약점이다.)

File Inclusion 공격을 하는 과정에서 File Upload를 활용할 수는 있지만, 다른 취약점이라는 것을 인지하도록 하자.

OSCP 침투테스트 : 해킹
침투 테스트라는 해킹의 전체 장르에서 웹 해킹이라는 장르 내에서  LFI 취약점은 단골 문제라고 한다.
LFI 취약점은 생각보다 대단하다라는 것이다.

> 만약 LFI 취약점을 찾았는데 파일 업로드가 없다면? 파일을 전혀 올릴 껀덕지가 없다면?!
그래도 한가지 방법이 있다. 파일을 올리지 않더라도, 웹 서버의 어떤 파일에 영향을 줄 수 있다.
> 바로 웹 로그(Web log), 접속한 기록이 웹 서버에는 다 기록되고 있고 이것을 이용하는 것이다.

URL 주소에 그냥 <?php system($_GET['cmd']); ?>를 넣어준다면? 이상한 요청이네 하고 넘기고 ,404 에러가 날 것이다. 그런데 이것을 access_log에서 요청한다면?.... 그 자체로 웹쉘을 딸 수 있는 취약점이 된다는 것이다.
(URL 주소에 입력한 내용들은 access_log에는 기록되기 때문이다.)

include는 어떤 파일이든 불러온다.
include는 해당 위치에 그 파일을 붙여넣기 하는 것이다.!!!!
그리고 나서 실행하는 것이다.

로그에서는 URL에 입력되는 모든 내용이 기록된다. 그러므로 include 기능을 이용하여 로그 파일을 불러온다면?! 해당 기록을 불러오게된다. 그러므로 파일을 따로 업로드 하지 않더라도 로그파일을 include 하는 과정에서 오류가 났던 webshell 코드에 대한 기록이 불러와지면서 실행되게 된다는 것이다.

즉, 어떤 언어로 구성되어 있던간에 php의 include와 같은 기능을 가진 언어별 함수를 이용한다면 해당 로그에서 원하는 코드를 실행할 수 있게 된다는 것이다.

심지어 include 취약점의 경우 txt 안에 있는 php 코드도 실행이 된다. 어떤 파일이든 그 내용을 붙여넣기 하고 실행하기 때문이다.

LFI / RFI

LFI 는 Local File Include로서 File Include시 웹 서버 내에 있는 파일을 가져온다.

RFI 는 Remote File Include 로서 (NAS 서버와 같은 외부 서버의 경우) File Include시 외부 서버에 있는 파일을 가져온다.

---

File Download

파일 다운로드(File Download) 취약점은 어떤 파일을 전달해주고 있는 기능이 있는 경우에만 가능하다.

download.php?fileName=test.txt

<?php
fileName = $_GET['fileName'];
downlaod('/files/' . $fileName); 
?>

위와 같은 형식으로 구성되어 있는 file download를 위한 기능이 존재한다면 해당 기능의 파라미터를 이용하여, 경로 조작을 통해 원하는 파일을 다운받을 수 있는 취약점이다.

fileName = ../../../../../../../etc/passwd
/files/../../../../../../../etc/passwd

위와 같이 웹 경로를 벗어나는 것이 가능한 경우에 etc/passwd 경로에 접근하여 중요 정보를 빼올 수 있는 것이다.

해당 취약점은 소스코드의 실행이 가능한 것은 아니라는 단점이 있지만, 내부의 소스코드를 다운로드 가능한 취약점이다.

그렇기 때문에 ../../../../../../../와 같이 경로 이동이 가능한 취약점 : path traversal 을 함께 이용하면 내부의 파일을 전부 열람할 수 있게 되는 위험한 취약점이다. 실행되지 않은 형태의 코드, 그 자체(소스 코드)를 획득할 수 있다는 것이다.

즉, File Download 취약점이 존재하면 Web Source Code를 탈취할 수 있고, DB정보를 저장해둔 것도 탈취되어 DB자체도 털리는 것이다. 일반적으로 download.php와 같은 다운로드 기능이 있는 페이지의 path를 확인하게 되는데, ../../../../../../../etc/passwd 와 같은 경우 쭉 올라가면 있기 때문에 찾기 쉽지만, 소스코드를 찾는 것은 쉽지 않다.

1. path traversal
2. guessing (추측)

* 지금은 사용하지 않는 기능에서 많이 나오는 경우가 있는데, 예전에 쓰다가 html tag로 삭제된 것의 경우, 즉 코드를 지우지 않고 주석처리만 해놓은 경우, 해당 주석을 풀고 들어가보면 이전에 쓰던 부분에서 취약점이 존재하는 경우가 있다.

일반적으로 파라미터의 이름을 작성하는 방식이 비슷할 것이라고 생각하고 해당 파라미터들의 이름을 추측을 통해, 예측하여 넣어보는 것도 방법이다.

(여기서 guessing 공격의 경우, 여기에 있을거 같은데?, 비밀번호 이것일거 같은데?, 등과 같이 프로젝트를 많이 다니면서 여러 웹사이트를 분석하고, 페이지별 디렉토리와 구성들을 생각하는 능력이 달라지기 때문에 경력을 무시하지 못한다고한다.)

 

단, 주의할 점이 있다.

주의할 점

위의 File Download취약점의 경우 해킹의 입장에서는 소스코드를 찾아내어 내부의 해당 코드를 직접 보고 취약점을 추가적으로 찾을 수도 있는 엄청난 취약점이지만, 모의해킹에서는 해당 취약점이 존재한다고 마음대로 내부 파일을 받아서는 안된다는 것이다.

해킹의 입장에서 해당 취약점을 발견했다고 생각해보자.

1. 소스코드를 찾는다. (이미 여기서부터 엄청난 취약점이다.)
2. 소스코드를 분석한다. 
 -> 분석의 단계에서 코드를 보지 않고는 알 수 없던 SQL Injection 가능 Point가 대거 발견될 수 있다.
(소스코드 분석을 통해서만 알아낼 수 있는 취약점을 추가로 발견할 수도 있다는 것이다.)

취약점을 더 찾기 위해 소스코드를 다운로드 받고 분석하여 더 많은 취약점을 찾아낸다. 원하는 파일들을 다운받을 수 있기 때문에 엄청난 취약점이 될 수 있다는 것이다.

하지만 이것은 침투테스트의 관점(해킹의 관점)으로서 파일 다운로드 취약점을, 어떻게 활용할 수 있는지 생각해봐야 하는 것이지 모의해킹의 단계에서는 해당 취약점이 발견된다면, 담당자와의 상의를 통해 추가적인 취약점 발견을 위해서 소스코드를 다운받아 점검할지 여부를 결정하고 진행해야한다.

마음대로 코드를 다운받는다면, 법적인 문제로도 번질 수 있다는 것을 잊어서는 안된다.

 

POC로서 다운로드 해봐야할 파일

/etc/passwd

Windows
/boot.ini
winnt/win.ini

../../../../../../../../boot.ini

 

File Download 대응 방안

File Downlaod 취약점의 공격에 대한 대응방안은 File Upload 의 대응방안과 흡사하다.

난독화

만약 javascript 파일을 다운받아 보는 경우에 난독화가 되어 있는 경우 난독화를 풀어주고 확인이 가능하다. (온라인 사이트의 난독화 툴을 이용하자.) 혹은 핵심 함수들 같은 경우에는 그대로 보여진다.

툴로 해결되지 않는다면 리버싱을 해야한다.

---

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