정보보안(Information Security) 기록 저장소

2017. 10. 12.

[웹 취약점] 버프스위트로 파라미터 무차별 대입하고 결과 얻기

취약점 진단을 할 때 파라미터 조작 취약점이 발견되는 경우가 굉장히 많다. 무작위로 인자값을 입력하여 얻어지는 응답값에는 '악의적인 공격자' 입장에서 유용하게 활용 될 만한 정보가 될 수 있다. 경험상 시나리오를 짜보면, 다음과 같은 사례가 있을 수 있다.

"범죄경력 조회 메뉴에서 POST로 전달되는 파라미터 값을 변조하여 응닶값에서 이름과, 주민등록번호, 주소를 파싱하여 텍스트 파일로 저장한다."
"헤더값을 변조하여 서버에 전달하여, 200 OK으로 전달되는 데이터를 취합 한다."

# 파라미터 조작 방법
파라미터 조작 공격이 유효한지 진단하기까지는 굉장히 쉽다. 다만 실제 공격자 입장에서 해당 공격을 통해 유효한 데이터를 얻느냐 얻지 못하느냐는 또 다른 문제이다.

공격은 '파이썬 또는 펄 프로그래밍'과 '버프스위트' 두 가지를 이용하여 시연 될 수 있다.
본 포스트는 버프스위트를 이용한 파라미터 대입에 대한 것이다.

1. Request 패킷을 잡고 'Send to intruder' 클릭

(위 사진은 예시 입니다. 실제로 구글을 대상으로 공격하지 않습니다.)

2. clear를 눌러 해지하고 원하는 파라미터를 블록지정하여 Add 버튼을 클릭한다.

3. Payloads 탭의 Payload type 에서 옵션을 선택한다. number, Dates, bruteforce 등등 있다. (효율성 면에서는 고민해야 할 필요가 있다. 펄이나 파이썬으로 짠 스크립트를 활용하는 측면에서 결과값이 많이 상이 할 수 있다. 고민해서 잘 활용 해야 한다.)

4. payload type을 number 로 선택하면 아래와 같은 옵션을 볼 수 있다.

5. start attack 을 누르면 공격이 시작되며 창이 하나 뜨면서 페이로드 및 결과를 확인 할 수 있다.

6. intruder > Options 메뉴의 'Grep - Extract' 섹션에서 'Add' 를 클릭한다.

7. 이 후, 창이 뜨고, 특정 페이로드를 지정할 수 있다.

'Refresh response' > 영역 지정 > OK

8. Attack start를 하면 공격이 시작된다. 도구에서 결과를 보면 한글이 깨지지만, 보고서를 다운받아 출력하면 한글이 제대로 보인다. save > Results table 을 통해 보고서를 다운받을 수 있지만 free edition 버전에서는 사용 할 수 없다.

** 패스워드 brute force 역시 버프 스위트에서 진행 할 수 있다.
Intruder > " Grep - Match " 메뉴에서 진행 할 수 있으며 매칭하고자 하는 문자열을 입력하면 아래와 같이 매칭 문자열이 발견된 요청을 확인 할 수 있다.
즉, 로그인이 성공했을 때 발견되는 문자열을 입력하여 매칭된 패스워드를 찾을 수 있다는 얘기다.

# 참고

http://blog.naver.com/PostView.nhn?blogId=crehacktive3&logNo=221077074955&parentCategoryNo=&categoryNo=9&viewDate=&isShowPopularPosts=false&from=postList

2017. 10. 11.

[웹취약점] Cross-Site WebSocket Hijacking Tester (SCWSH)

오전 1:06 웹 취약점 , WEB

평소 해커원에서 'Hacker activity' 내용을 즐겨 보곤한다. 여기서 종종 나오는 취약점이 CSWSH 이다. 개념이 조금 생소해서 조사를 조금 해보았다.

# WebSocket
웹 소켓은 웹 페이지에서 실시간으로 동작하는 웹 서비스를 만들어 줄 수 있는 표준 기술이다. (예를 들면, 채팅과 같은)
일반적으로 웹 프로토콜인 HTTP는 Request와 Response 기반으로 새로 요청이 발생하면 페이지를 다시 그려야 하는 구조이다. 이와 같은 환경아래서 인증 정보를 유지하기 위해, 쿠키도 사용되게 되었다.
http://www.websocket.org 에서 많은 내용을 확인 할 수 있다.
즉, 사용자는 페이지의 이동없이 내부 동작을 처리하길 원했고, 이 때문에 WebSocket 이 사용되게 되었다. (이는 HTML5의 표준으로 올라가게 되었다.)

아래와 같이 Upgrade 헤더와 connect 헤더에 각각 WebSocket, Upgrade 가 들어있는 것을 볼 수 있다. 이는 HTTP 기반 웹 처리에서 WebSocket으로 넘어가게 하는 구절이며, 이와 동시에 클라이언트가 랜덤한 키 값을 서버로 보내어 토큰을 생성하고 반환하는 과정, 즉, Handshake가 이루어진다.

GET /.... HTTP/1.1
Upgrade:WebSocket
Connection: Upgrade

Request

GET /?encoding=text HTTP/1.1
Host: echo.websocket.org
origin:http://www.websocket.org
Sec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==    -> BASE64(Random Byte)
Connection: keep-alive, Upgrade
Upgrade:WebSocket

Response

HTTP/1.1 101 Switching Protocols
Upgrade:WebSocket
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=  -> BASE64(SHA1(GUID))

Sec-WebSocket-Key와 Sec-WebSocket-Accept 부분은 개인정보 보호 및 무결성 검증을 위해서 사용되는 부분이다.

# Cross-Site WebSocket Hijacking
CSWSH 에서는 origin 필드가 핵심이다.
origin 은

WebSocket 접속을 요청한 페이지의 scheme, hostname, port(만약 기본포트가 아닐 경우에만 포함) 정보
WebSocket 서버에서 요청 페이지에 따라 다른 처리방식을 각각 결정하기 위해 필요한 정보이다.

CSWSH 공격은 바로 이 orgin 필드의 기존 값을 악성 사이트로 변조하여 서버에 전달하는 기법이다.
때문에, 당연히 서버에서 제대로 대응하고 있다면 서버에서 관리하고 있는 origin 이 아닐 경우 cross-protocol attack 이나 cross-site webSocket hijacking 으로 간주하고 접속이 중지 될 것이다.

이름에서도 드러나지만 이 공격은 CSRF 와 유사하다. 로그인 한 사용자의 request 를 변조하여 victim의 세션값을 갈취 할 수 있기 때문이다.

# 검증 방법

검증 방법 역시 굉장히 간단하다. origin 의 url 을 다른것으로 변조했는데, HTTP/1.1 101 Switching protocols 메시지를 받으면 해당 서버는 취약한 것이다.

<출처 - notsosecure.com>

** 추가 **

CSWSH 에 얽힌 슬픈 이야기 <https://hackerone.com/reports/274324>

어떤 버그바운터가 CSWSH 취약점을 잡았는데, 보안담당자가 "그래, handshake 까지는 그렇다 치고, 너 origin 바꾸는걸로 어떤 해킹을 할 수 있는데? 아니면 사용자 민감데이터를 다른 서버에 보낼 수 있어? 라고 압박을 했다. 어려보이는 버그 바운터는 바로 꼬리를 내렸다. 이유가 뭘까. 어렵다.

보안 담당자가 증거로 내세운 자료는 https://github.com/meteor/meteor/issues/8317 이거다. 나중에 읽어봐야지

# 참조

https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html
https://www.notsosecure.com/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/
http://www.hahwul.com/2016/08/coding-websocket-overview-protocolapi.html

2017. 10. 10.

[스크랩] 관심이 가는 스캐닝 도구 (유료)

오전 1:59 SCRAB

요즘 유료 스캐닝 툴에 눈이 간다..

ironwasp
acunetix

and so on...