정보보안 스터디 - 9주차 4일 - 파일 업로드 공격과정
☞ 파일 업로드 공격과정
1. 게시판업로드, 프로필사진등록, 서류제출 등 파일창이 있는 곳이면 어디든 찾아봅니다.
2. 이미지를 올려 어떤 경로로 저장되는지 확인합니다.
burp suite 또는 새창에서 열기로 현재 경로를 알아냅니다.
3. webshell.php 파일이 올라가는지 확인합니다.
올라가지 않는다면
4. intercept를 켜고 클라이언트측 알림창인지, 서버측 알림창인지 확인합니다.
요청을 잡지 않고 알림창이 뜨니까 클라이언트 측 에러라고 볼 수 있습니다.
클라이언트측이라면 요청이 서버까지 가서 응답을 받아온 것이 아니라 웹브라우저 측에서만 겉으로만 막아냈다고 보시면됩니다. 조금 더 보안에 신경쓴 사이트라면 자바스크립트가 노출되어있지 않고 .js 파일로 include했을 것입니다.
A. 어떻게 되었든 js파일을 눌러서 알림부분을 찾거나 자바스크립트를 수정하면 됩니다.
html 부분에서 제한하지 않도록 수정을 해봐도 적용이 안되는 것을 알 수 있습니다.
Console 부분에서 수정을 하고 적용시켜야 합니다.
B. 일반 글 쓰기로 intercept를 잡을 뒤 거기에 파일이름을 .php 확장자를 넣고
jpg 파일이라면 외계어가 떳겠지만
웹쉘 php코드는 인식이 가능해서 직접 넣어줍니다.
C. Burp suite에서도 클라이언트측 스크립트 수정이 가능합니다.
글쓰기 페이지 들어가는 요청을 보낼 때 서버의 응답은 스크립트로 막는 기능을 보내기 때문에 그때 부터 응답을 바로 받지 않고 변조해야 합니다. Intercept로 서버 응답도 받는다고 체크한다음 막습니다.
응답을 변조하여 받습니다.
클라이언트에서 스크립트로 막히지 않고 글쓰기 요청을 보낼 수 있습니다.
5. 서버측 오류가 개발자의 실수가 들어있는지 확인합니다.
역시나 그렇듯 서버에서도 php파일을 막아내네요.
하지만 드물지만 개발자의 실수 중 하나는
로그인에서 세션을 먼저 발급하고, 로그인이 틀렸다고 오류가 뜨거나,
업로드를 먼저해주고 업로드할 수 없다고 알림창 뜨는 등
코딩을 거꾸로 하는 실수도 있습니다.
혹시 모르니 업로드한 경로를 확인해봅니다.
들어가 있는 것을 확인할 수 있습니다.
아마 대부분의 페이지들은 유저에게 이 페이지를 막아놓을 것입니다.
하지만 파일을 올릴 수 있다면 그 주소로 가면되기 때문에 문제되지 않습니다.
6. 웹쉘 실행
GET방식으로 명령어를 넣어서 응답을 확인합니다.
| pwd로 내위치 확인 |
| id 소유자 권한확인 |
| ls -al 로 다른 폴더, 파일들의 읽기/쓰기/실행 권한을 확인하고 현재 apache(익명)권한으로 어디까지 할 수 있는지 확인합니다. |
현재는 /www 디렉토리 자체를 삭제,수정까지 수 있습니다.
읽기는 물론이구요.
shadow 읽기, 루트까지의 파일생성 등 루트권한이 있어야지 되는 작업들은
루트권한 확보 후에 가능합니다.
setuid 권한이 설정되어있는 실행파일로 인해
실행하는 순간 유저가 root권한을 얻을 수 있습니다.
그렇기 때문에 목적에 맞지 않는 setuid로 설정되어있는 파일이 있다면 최대한 삭제하는 것이 좋습니다.
find / -perm -4000 2> /dev/null
-4000은 권한4000을 포함하는 파일을 찾고
4000은 권한이 4000인 것만 찾습니다.
에러 출력은 /dev/null로 재지정해줍니다.
예를 들어 more라는 명령어에 setuid 설정이 되어있다면
more를 통해 루트권한을 얻어 /etc/shadow를 확인할 수 있습니다.
지금은 가능할만한 그런 명령어가 없습니다.
| chsh -s /usr/bin/bash kali 쉘 변경 |
| cat /etc/shells 쉘종류 확인 |
| cat /etc/passwd | egrep "kali|root" 현재 사용 쉘 확인 |
현재 저는 root, kali는 zsh을 사용중입니다.
bash쉘은 자동완성이 없습니다.
다른 쉘들과 크게 차이는 안나는 것 같습니다.
