Hacking_study/해킹과제

파일 업로드 및 다운로드

jin_li 2023. 6. 1. 22:12
파일 업로드(FIle Upload)

공격자가 임의의 파일을 업로드는 공격.
업로드 되는 파일을 검증하지 않거나 또는 검증이 미흡하기 때문에 생기는 취약점.

게시판이나, sns 프로필 사진 올리기 등... 어떤 형태의 파일이든 업로드 할 수 있는 곳이면 일어날 수 있다.
웹 쉘을 업로드하여 실행시키면 서버를 장악하는 것까지 가능하므로, 위험도가 높은 편이다. 모든 공격의 상위버전이라고도 할 수 있다.

 

 

공격 시나리오

1. 웹 쉘
2. 대용량 파일을 업로드 > DOS공격
3. 디페이스 공격. index.html을 업로드해서 메인페이지 바꾸는 공격
4. 페이지 변조해서 피싱공격...
5. 악성코드 유포.(XSS)
...등등

 

웹 쉘 : 서버에서 실행할 수 있는 프로그램.

<?php echo system($_GET['cmd']); ?> 와 같이 한 줄 만으로도 웹 서버에 충분히 명령내릴 수 있다.

(한 줄짜리의 웹 쉘 코드는... 실제로 잘 쓰이지는 않고 POC코드 같은 느낌의 용도로만 취급한다고 한다. 공격자들은 reverse shell cheat sheet 이용하거나 직접 짜거나 한다고.)  

 

웹쉘을 실행시켜서 서버에 명령어를 날릴 수 있게 되면, 공격자들은 대개 소스코드를 탈취한다

소스코드를 탈취하는 것은, 곧 DB를 탈취하게 되는 것이기 때문이다.

그래서 공격자들은 소스코드부터 탈취해서 로그인창과 같은 sqli 가능할법한 페이지의 소스코드 확인해가면서 DB의 아이디, 패스워드, DB주소까지 알아내려고 한다.

참고로 DB의 데이터가 암호화되어있을 때는 보통 DB내에 데이터 복호화 할 수 있는 키가 다 있으므로 별 의미없다.

 

이렇게 공격자가 웹쉘을 올려서 실행시키고 DB까지 탈취한 뒤에는, reverse shell을 받아온다.

reverse shell : 트워크 연결을 통해 원격 시스템에 접근하여 명령을 실행할 수 있는 기술...(포트 열어놓고 공격서버보고 들어오라고 하는거...역방향...바인드 쉘은 정방향.. 공격할 서버에 포트 열고 직접 들어가는거..) 리버스 쉘을 쓰는 이유는, 방화벽 때문. 들어오는게 인바운드, 나가는게 아웃바운드인데. 인바운드는 방화벽때문에 까다로움. 아웃바운드는 보안정책 잘 없고 443번 포트는 항상 열려있음. 나중에 침투 테스트 공부하다 보면 리버스 쉘 연결 안 될 때 nc -nvlp 443 입력하면 될 때 많다고... 그렇구나... 아무튼 이 리버스 쉘을 이용하여 시스템을 장악할 수 있다.

 

 

 

 

 

 

※ Bypass Trick 하나씩 시도하면서 익숙해지기~ 여러 트릭들 이것저것 조합해서 해놓은 경우도 많음.

 

1. Content-Type.

웹서버가 파일 확장자명이 아닌 Contect-Type을 보고 파일을 가리는 경우.

그러면 버프스위트 인터셉트 켜서 Content-Type만 바꿔 보내면 가능. 

 

2. 업로드 되는 디렉토리에 실행권한을 안 주는 경우.

이럴 때는 디렉토리 트래버셜을 쓸 수 있음. 즉 파일 이름을 "../webshell.php"와 같이 해서 상위 디렉토리에 웹쉘을 저장되게 만드는 것. 만약 이것도 안 될 때, ../을 필터링 해놓은 경우라면 "..%2f/webshell.php"와 같이 url인코딩으로 필터링 우회해보기.

 

3. 블랙리스트 기반 필터링 우회.

예를 들어 파일이름에 "php" 글자 필터걸어놓은 경우. 대소문자 섞거나, php중첩해서 쓰거나... 또는 php5나 jsp, jspx 뭐 이렇게 바꾸는거... 근데 jsp와 jspx는 문법 조금 달라서 페이로드 좀 바꿔야한다고 함.

 

4. 확장자 우회.

이중 확장자 쓰기! 예를 들어 test.png.php와 같이 올리는거... 이 경우는 컴터가 확장자를 .png.php로 착각하게 하는 것.

test.php%00.png 와 같이 null 바이트 %00(문자열의 종료를 나타냄)을 넣어서 php파일을 png로 위장시킬 수 있다.

test.php.png 이런 건 안 된다. 의미 없다. 다른 블로그 글에서 된다고 나와있는 경우는... htaccess파일 건드려서 되는것.

 

5. 파일 시그니쳐

이미지 파일 맨 뒤에 웹쉘 덧붙이는 것.

일단 맨 처음엔 파일 이름의 확장자를 php로 바꿔보기. 올려지면 이미지파일 내용 맨 아래에다가 웹쉘 추가해서 올리면 됨.그럼 파일 맨 끝에 출력돼서 나와용

 

6. PUT Method

메소드를 PUT으로 바꿔서 웹쉘 업로드할 수 있다.

 

 

 

 

 

 

※ 파일 업로드로 서버 공격할 때 포인트

 

1. 자신이 웹 서버에서 실행할 수 있는 파일을 올려야 하고,

2. 그 파일을 실행할 수 있어야 한다. 올려놓고 파일 실행 못하면 무용지물

 

예를 들어, mal.php를 올린 뒤, 실행시킬 수 있는 방법은? mal.php가 저장된 경로로 접속하는 것!

즉, 웹 브라우저로 우리가 올린 파일을 요청하면 되고, 그러려면

3. 업로드 된 파일의 위치를 알아야 한다.

 

업로드 된 파일의 위치는 올린 파일을 다운로드 받아보면 된다.

 

 

팁! XSS 공격할 때든 웹쉘을 실행할 때든

버프스위트 repeater 기능 이용하는 게 보기 좋고 암튼 좋다. 그리고 대개 리눅스 환경이니 리눅스에서 개발 많이~

 

 

 

 

 

 

※ 파일 업로드 취약점에 대해 실무에서 주의사항

 

1) 실제 웹 쉘X

<?php echo "Script Run";

 날짜 출력.

?>

만약 실수하면..ㅎ 담당자..

 

2) 업로드 테스트 파일 내역 저장해두기.

내가 테스트하고 지우기도 해야하지만... 담당자도 확인할 수 있도록.

 

3) 다른 사람이 만든 웹쉘 긁어다가 쓰는거 절 대 X. 웹쉘은 직접 만들기!!

 

 

 

 

 

※ 대응방법

 

1. 업로드 되는 파일을 DB에 저장되게 하기. (파일로 저장되게 하는 게 아니라 텍스트로, 즉 데이터로 저장되게 하는 것)

웹 쉘을 올렸을 때, 이 웹 쉘이 웹서버에 저장돼서 실행됐기 때문에 공격되는 것. 따라서 DB에 그냥 바이너리 정보로 들어가게 되면 웹쉘공격 방지할 수 있음. DB에 파일안의 데이터들을 글자로(데이터 타입은 CLOB, BLOB)저장되게 하면 된다. 이는 근본적인 해결방법이나 DB에 테이블도 수정해야하고 소스코드도 여러가지로 수정해야 하니 고치기 힘들 때가 있다. 이럴 때는 차선책으로,

 

2. 웹서버가 아닌 다른 서버(NAS)에 저장되게 한다. 단, 이 서버에 웹 서버 실행 엔진이 있으면 소용X

핵심! : NAS는 업로드 파일이 저장되는 서버를 웹서버와 분리하는 것.

 

3. 파일검증 꼼꼼히. 확장자 검증, 파일 시그니쳐 검증, MIME TYPE 검증

 

 

 

 

 

 

파일 다운로드

공격자가 원하는 임의의 파일을 다운로드 할 수 있을 때, php파일 등을 다운해서 DB계정 정보를 알아내거나 서버 측 취약점을 더 찾는 식으로 악용할 수 있는 취약점이다.

 

 

※ 파일 다운로드 취약점 찾는 팁

1. download 스크립트 있는지 확인

download.php

down.php

 

2. 파라미터로 파일이름을 받는가? 또는 파일 경로를 받는가 확인

download.php?idx=2

 

만약..?

여기서 sql injection이 된다면? 다운로드 취약점 가능할 수 있음

select path from board where idx={} 

idx=0 union select '/etc/passwd'

처럼..

 

 

 

※ 대응방법

 

1. DB에다가 파일 올리게 하는 것. 파일 업로드 취약점과 대응방법이 같다.

2. DB 구조 바꾸는 게 힘들 때 차선책 : 디렉토리 트레버져 막기.

../ 자체를 못 쓰게 만드는 건데, 이 방법은 우회 가능하다.

'Hacking_study > 해킹과제' 카테고리의 다른 글

인증/인가 취약점  (0) 2023.06.15
SSRF  (0) 2023.06.07
CSRF 수업 정리(9주차)  (0) 2023.05.25
CSRF 수업 정리(8주차)  (0) 2023.05.18
XSS (stored xss / reflected xss / 대응 방안)  (0) 2023.05.11