저번 포스팅에서는 File Upload의 개념과 공격을 위해 필요한 경로 파악하는 법에 대해 알아보았다.
이번에는 File Upload 공격을 막을 수 있다고 알려진 대응 방안의 우회 방안에 대해 알아볼 것이다.
① 파일 유형(Content-Type)
서버는 파일을 주고받을 때 MIME(Multipurpose Internet Mail Extensions) Type으로 파일의 종류를 확인한다. 따라서 이 MIME-Type의 Content-Type을 확인해서 image/jpeg등인 경우에만 업로드할 수 있도록 만들 수 있다.
[우회 방안]
BurpSuite으로 패킷을 확인해보면 위와 같이 img를 업로드했을 때는 Content-Type : image/jpeg이지만 php 파일을 업로드하면 Content-Type : application/x-php로 뜨는 것을 볼 수 있다.
BurpSuite에서 Intercept on을 켜서 데이터를 중간에서 막은 후, 패킷의 Content-Type을 image/jpeg 등으로 수정해서 보낸다면, 서버는 업로드된 파일이 img 파일이라고 생각해서 저장할 것이다. XSS 취약점에서도 언급했듯이, 중간에서 데이터를 변경하는 방식으로 우회가 가능하기 때문에 검증은 서버에서 이루어져야 한다.
② 실행 권한 설정
만약 업로드된 파일이 모두 /upload 경로에 저장된다고 가정하자. 관리자는 upload 폴더의 실행 권한을 제거하는 방식으로 파일 업로드 공격에 대응할 수 있다. 이 경우 php 파일이 업로드된 경로로 접속하면 그냥 글자로서의 "<?php command ?>"만 보이는 것이다.
[우회 방안]
Directory traversal를 사용하여 파일 이름을 test.php가 아니라 ../test.php로 저장하면 upload의 상위 디렉터리에 저장되게 할 수 있다. 즉 실행 권한이 제거된 폴더가 아닌 다른 경로에 저장되게 만드는 방법이다. 이 방식은 파일을 다른 폴더에 저장되게 하므로 Deface(override) 공격도 가능하다. 만일 실행 권한이 있다면 파일을 /etc/passwd에 덮어써서 계정 정보를 변경할 수도 있다.
여기서, 왜 root 권한으로 웹 서버를 개발하면 안 되는지에 대해 알 수 있다.
보통 권한 Error가 생기면 마법의 명령어 chmod 777을 사용하는 경우가 많다.(뜨끔) 하지만 chmod 777을 남발하면, 공격자가 쉘을 획득했을 때 공격자 스스로도 root 권한으로 명령을 수행할 수 있다. 공격자는 보통 쉘을 획득하면 그다음으로 root 권한으로 상승하기 위한 과정을 거치는데, chmod로 이미 권한을 주게 되면, 공격자는 쉽게 명령을 수행할 수 있기 때문에 위험하다.
③ 파일 확장자 검증
관리자는 업로드된 파일의 확장자를 검증할 수도 있다. 이때, 화이트리스트 기법으로 특정 확장자만 허용하는 것이 아니라 블랙리스트로 특정 확장자를 사용하지 못하게 한다면, 예를 들어 php를 막는다면 php5 등의 확장자로 바꾸어 업로드할 수 있다.
④ File Signature 검증
HxD 등의 Hex editor 프로그램으로 이미지를 확인해보면, jpg는 FF D8 FF로 시작하는 등, 각 확장자마다 시그니처가 존재한다. 따로 Hex editor를 깔지 않고 터미널에서 사진 하나를 hex date로 변경해서 확인해보았다.
관리자는 이 파일 시그니처를 이용해서 확장자를 확인할 수 있다.
[우회 방안]
시그니처를 변경하지 않고 hex data의 마지막에 <?php echo command ?>, 즉 php 코드를 추가하여 업로드할 수 있다. 서버에서는 파일 시그니처만 보고 jpg라고 생각하지만, 마지막에 php 코드가 있기 때문에 원하는 명령을 수행할 수 있다.
다음 포스팅에서는 그렇다면 파일 업로드 공격은 어떻게 막을 수 있을지, 파일 업로드 기능이 없을 때는 어떻게 공격할 수 있을지에 대해 알아볼 것이다.
'WEB HACKING > 웹 해킹[이론]' 카테고리의 다른 글
File Download 공격 (0) | 2021.12.21 |
---|---|
File Upload 공격(3) (0) | 2021.12.18 |
File Upload 공격 (0) | 2021.12.11 |
CSRF : Cross-Site Request Forgery (0) | 2021.11.26 |
XSS : Cross-Site Scripting 대응 방안 (0) | 2021.11.25 |
댓글