내 web shell은 어디에...

어찌어찌 서버에 web shell을 올렸다고 해도 내 web shell 위치를 찾지 못해서 헛수고하고 로그만 남기고 억장이 와르르할 수가 있다! web shell 올리기 전에 파일 올릴 때의 내부 로직을 정확히 파악하고 해 보자!!

 

내가 올린 파일 찾기

음 일단 로직을 분석하고 직접 차근차근 찾아보는 방법이 가장 좋은 방법이긴 하다!

그래도 여러 가지 대표적인 방법들이 있으니 알아보자!

 

 

응답을 분석해 보자

파일을 업로드하면 종종 응답 내용에서 서버 내부에 파일 위치가 도착하는 경우가 있다.

내부 파일 위치에 접근해서 내 web shell에 접근해 보자!

 

 

 

 

F12를 눌러보자

이미지를 업로드한 img 태그를 확인해 보면 src에 url이 걸려있다.

걸려있는 url을 봐보면 업로드된 위치를 확인할 수 있다.

해당 URL에 한번 접근해보자!

 

파일 업로드 URL은 특정한 규칙이 있는 경우가 많다.

/file/board/filename/

/file/board/date/

/upload/file/

생각보다 해당 형식으로 저장되어 있는 경우가 많다.

직접 URL을 잘 살펴보면서 유추해 보는 것이 좋다. 알아볼 수 없는 문자열이 아니면, 파일을 여러 개 업로드해서 규칙을 찾는 것도 좋은 방법이다.

 

 

SQLi 해보기

생각보다 파일을 저장하는 방법은 엄청 여러 가지이다. 작은 파일은 직접 DB에 올리는 경우도 있고,, 아님 파일 업로드 된 URL을 DB에 저장하는 등등 등등 등 엄청 여여여여러러러가지 방법들이 있다.

DB를 건드는 모든 입력값들은 다 SQLi 취약점이 발생할 수 있다.

 

파일 조회 시 SQLi가 발생하는 대표적인 로직이 DB에서 파일명, 파일 경로 정보를 조회한 후, 파일을 다운로드 한다. 

파일 조회시 쿼리가? file=123 이런 식으로 되어 있으면 보통 DB에서 file이 123인 정보를 찾아서 보여준다.

이때 DB에 파일을 찾으려고 WHERE 절을 사용할 텐데 이때 SQLi취약점이 발생하는 것이다.

 

 

 

그냥 때려보기

file 업로드 위치도 딕셔너리가 몇 개 굴러다닐 것이다. 여기서 요청을 계속 보내는 것 이다

404가 뜨면 없는 페이지라는 것을 알 수 있지만 403이 뜨면 접근권한이 없다는 의미니까 403 뜰 때까지 공격해 보는 방법도 있다.

예시를 들어서

file, download, data, upload.....

생각보다 무차별 대입으로 파일이 업로드된 디렉터리를 알 수 있는 경우가 있다

 

 

 

file 관련 취약점은

내가 생각하기엔 강력한 공격 중에 하나라고 생각한다. 물론 ss공격들이 다 엄청난 영향력을 미친다

SQLi 공격은 오래됐음에도 강력하고 흔히 발생하는 취약점이다. 파일 취약점도 그런 것 같다.

직접 웹 쉘을 올려서 서버를 장악하고, 공격해서 피해자 서버에 큰 파괴력을 보일 수 있기 때문이다. 물론 SQLi 취약점도 웹 쉘을 올릴 수 있지만 매우 힘들다.

 

파일 관련 취약점은 제일 멋진 취약점인 것 같다.