정보보안 스터디 - 20주차 1일 - E2E, SSRF 취약점
☞ 기존 공격 정의 및 개념 정리
CSRF
무엇인가(what) CSRF는 직역하면 사용자의 요청을 위조하는 공격입니다.
=사용자가 자기도 모르게 서버로 임의의 요청을 보내게 만드는 공격입니다.
어디에서 발생하나(where?)
서버로 보내는 모든 요청(요청 패킷 내에 이용자 검증이 없는곳)
--
XSS가 되는곳 stored로 스크립트를 사용자가 받기 때문에
파라미터 값에다가 넣을 수도 있고.
XSS가 통하는 모든 곳
그리고 XSS가 안되도 get방식으로도 주소를 만들어서 될 수 있음.
왜 발생하나(why?)
공격자가 서버로 보내는 임의의 요청 위조할 수 있기 때문입니다.(예를들어 요청정보를 예측할 수 있기 때문에)
예를들어 이용자 인증정보나 랜덤한 토큰 정보가 없는 요청을 말합니다.
---
사용자의 요청을 검증하지 않아서 스크립트를 삽입할 수 있는 상황이 발생합니다. 그렇기 때문에
임의로 다른 사용자가 요청을 하도록 할 수 있습니다.
scenario
다른 사람의 이름으로 악성 스크립트 코드를 작성하거나 악성 파일을 첨부하여 글을 작성하게 할 수 있습니다.
defence
서버로 보내는 요청을 예측하지 못하도록 합니다.
이용자 인증정보를 이중으로 구현하거나, 1회용 랜던값 CSRF 토큰을 구현합니다.
원래는 요청을 보낼 때 기존 비밀번호가 맞으면 요청가능하도록 하는 것이 좋지만
댓글 작성 등 모든 요청에서 적용할 수 없으니 CSRF 토큰을 사용하거나, referer을 적용합니다.
>> CSRF 토큰 방식도 우회 가능합니다.
사용자 세션이 바인딩되지 않을 경우 우회가능합니다.
있다면 iframe태그를 삽입해서 토큰을 가져온 뒤 CSRF를 우회합니다. 단 전제조건은 같은 도메인에 XSS취약점이 있어야합니다.
--
계정 정보를 변경할 때는 기존 비밀번호를 입력하게 합니다.
하지만 댓글을 작성하거나 모든 요청에서 비밀번호를 입력하게 하기에는 번거로우니
사용자 입력에 대해 HTML entity 치환하여 스크립트를 삽입할 수 없도록 합니다.
파일 업로드
what
파일 업로드는 임의의 파일을 업로드하여 실행 시킬 수 있는 공격입니다. (실질적인 공격까지 생각하자면 실행까지 시켜야합니다.)
where
파일을 업로드하는 페이지에서 발생합니다.
why
사용자가 업로드하는 파일을 검증하지 않기 때문에 발생합니다.
scenario
웹쉘: 웹 서버를 장악하게 합니다.
defence
근본적인 방법은 1) 업로드되는 파일을 DB에 저장하고 관리하는 방법입니다. (문자열 속성을 변경하여)
왜냐하면 DB에 저장하면 파일을 실행시키거나 할 수 있는 방법이 없습니다.
또는 2) 파일을 저장하기 위해서만 NAS 서버를 구축하여 웹서버와 분리시킵니다.
왜냐하면 NAS서버에서는 웹서버와 분리되어
php, jsp 등 WAS 엔진이 실행되지 않기 때문에 업로드 된 파일을 실행시킬 수 없습니다.
기존 방법을 고수하고 싶고 너무 비용이 부담된다고 할 경우에는
업로드 하는 파일의 확장자를 화이트 리스트 기반으로 필터링 합니다.
파일 다운로드
what
웹 서버의 임의의 파일을 다운로드 할 수 있는 공격입니다.
where
다운로드 스크립트가 있는 페이지 입니다.(이 때 download 태그로 구현 후 페이지에 직접 접근해서 다운로드하는 방식이 아닌 다운로드 스크립트로 페이지가 구현되었을 경우 입니다.)
why
사용자 입력 검증 부재입니다.
--
파일을 다운로드 할 때 다운로드할 경로를 임의의 값으로 변조할 수 있기 때문에 발생합니다.
scenario
다운로드를 한다면 boot.ini 나 /etc/passwd 파일을 실행하는 것은 입증하는 용도에 그칩니다.
왜냐하면 공격으로 발전할 가능성이 낮아보이기 때문입니다. 사용자 계정 아이디를 알아서 brute force하는 방법이 있을텐데
웹으로의 ssh접속은 요즘 기본적으로 내부IP주소가 아닌 외부주소에서는 접속할 수 없도록 막아져있으며
로그인 실패 제한이 걸려있기 때문입니다.
ftp도 마찬가지로 일 것입니다.
1) 소스코드를 다운로드 하여 확인합니다.
소스코드를 확인하여 어떻게 돌아가는지 확인하고,
파일 업로드, SQL 등 치명적인 취약점을 발견하여 발견할 수 있습니다.
소스코드에는 주석 등 다양한 취약점을 발견할 수 있습니다.
2) DB 계정 정보
로그인 페이지로 들어가 DB 계정 정보를 가져옵니다.
DB에 관리자 권한으로 로그인 접속할 수 있고, 권한을 이용할 수 있기 때문입니다.
defence
근본적인 방법은
경로를 파라미터로 사용하는 대신
1) 파일이나 파일 경로를 DB로 관리하는 방법입니다.
파일을 DB로 업로드하고 관리하면 웹 서버와 분리되기 때문에 웹 서버 내의 소스코드나 내부 파일에 접근할 수 없습니다.
?fileId=1 이런 것처럼 파일 경로와 번호를 매칭시켜서 파일을 가져오는 방법을 사용하면 사용자가 입력하는 파일을 그대로 받아올 수 없습니다.
2) NAS 서버에 파일을 관리하는 방법입니다.
마찬가지로 서버와 분리되어 있기 때문에 웹서버 내의 소스코드나 설정파일을 불러올 수 없습니다.
기존 방법을 고수하고 싶고 너무 비용이 부담된다고 할 경우에는
파일 경로 파라미터값을 입력할 때 디렉토리 path traverser(../) 이동하는 문자열을 필터링합니다.
☞ E2E
End to End로
원래는 https로 프로토콜 상에서만 암호화 했었다면
그걸 웹 브라우저까지 늘려서 암호화하자는 방식입니다. 그러면 burp suite로 요청 후 입력값을 확인했을 때 모두 암호화로 해서 나옵니다.
네이버나 금융권에서 많이 사용하는 방식으로 모의해킹 종사자마저 이러한 기능을 발견하면 뚫어보려고 하지 않고 넘어갑니다.
나온지 얼마 되지 않았기도 하고
js파일로 암호화하기 때문에
고 프롬프트창을 띄우면 기존과 같이 평문으로 확인할 수 있습니다.
또는 2) 꼼수를 사용하는 방법입니다.
스위치처럼 on/off기능이 가능합니다. enctp을 1> 0으로 바꿔주고
encid를 빈값으로 바꾸고
id=파라미터에 값을 넣어주면 됩니다.
하지만 E2E 기능을 분석하고 뚫으면 취약점이 많이 나올 것입니다.
☞ SSRF
하지만 전제조건은 서버내에 XSS취약점이 있다는 조건입니다.
이용자의 요청을 변조해서 계정 변경하거나 글을 작성하는 등 악의적인 행동을 했다면
서버측 요청을 변조할 수 있다면 서버 내부 파일 가져오거나 서버를 제어하려고 할 것입니다.
카카오 날씨 API를 사용하는 웹사이트라면
정보를 받아오고 응답할 것입니다.
보통 이렇게 되어있습니다.
.php?http://weather.kakao.com/api.jsp
그러니까 서버에 요청하면 Api 카카오 서버로 요청해서 응답한다는 것입니다.
그러면 입력값을 바꿀수 있으니 자기서버로 자기한테 요청을 보냅니다.
file:// 로 바꾸고 내부 localhost/ect/passwod 등으로 내부 임의의 파일을 다운로드할 수 있습니다.
또는 ftps:// 등도 가능할 것같습니다.
그래서 대응방안은
1) 입력값 수정못하도록합니다.
2) 동적인(매번 바뀌도록 설정하려면) 방법이라면 DB에 num1, 2,3을 두고 범위안에서만 바뀌도록 설정합니다.
3) 주소값을 변경하지 못하도록 화이트리스트 기반 필터링합니다.
블랙리스트 기반 필터링한다면 거의 끝이없을 정도로 우회가 가능하기 때문입니다.
localhost를 막는다면 -> 127.0.0.1, 바이너리 값, 대소문자 우회 등등 접속할 방법은 많습니다.
또는 이런 화이트리스트 기반 우회도 있습니다.
# (fragment)
wonder.com만 허용하도록 되고
127.0.0.1에 접속하길 원한다면
wonder.com#127.0.0.1/etc/passwd 로 우회할 수 있습니다.
#뒤에 부분은 주석처리하기 때문입니다.
+) ASTX 프로그램에서 burp suite를 임의로 종료시킨다면
ASTX 프로그램을 바이너리로 리버싱 분석하면 됩니다.
그러면 크롬, IE, edge에 대해서 모니터링하고 있기 때문에 우회시킵니다.
1) VM 가상머신에서 burp, 본체에서 크롬을 실행시켜 프록시 연결하면 꺼지지 않습니다.
2) fiddler 등 다른 proxy 툴을 사용합니다.
3) 네이버 웨일 등 다른 브라우저를 사용합니다.
우회합니다.
