모의해킹 스터디 4주차: 웹 프록시 툴 - Burp Suite

 <현재 환경 세팅>

1. Virtual Box 7.1.4 + 우분투 리눅스 20.04

2. 우분투 APM (Apache2 + PHP + MySQL)

3. 기본 웹 루트 경로 /var/www/html

4. VScode SSH

5. 사진 등은 termius

 

 

순서

• 웹 프록시 툴
• 버프 스위트
• 버프 스위트를 활용한 CTF 풀이

 

 

 

◈ 웹 프록시 툴

 

• 웹 프록시 툴이란?

클라이언트(브라우저)와 웹 서버 사이에 껴서 요청과 응답을 대신 전달하는 역할(proxy)을 하는 프로그램.

 

 

이전에 공부한 바로는 우리가 브라우저를 이용하여 웹 서버에 어떤 파일을 요청하면

웹 서버는 그 파일에서 필요한 동적, 정적 처리를 완료한 후 우리가 사용 중인 브라우저에게 보낸다.

클라이언트와 웹 서버가 소통하는 모습. 어디를 거쳐가지 않고 직접 소통하고 있다.

 

 

하지만 꼭 이런 식으로 직접 소통하는 방법만 있는 것은 아니다.

 

나와 웹 서버 사이에 오고 가는 패킷이 웹 프록시 툴을 거쳐가게 할 수 있다.

 

클라이언트와 웹 서버가 프록시 툴을 거쳐서 소통하고 있다. 프록시 툴에서 요청을 듣는 쪽은 귀를, 전달하는 쪽은 입을 그려넣어 보았다.

 

 

 

 

• 사용 목적

그렇다면 프록시 툴을 사용하는 목적은 무엇일까?

 

이렇게 패킷이 프록시 툴을 거쳐가면 프록시 툴에서는 패킷의 내용을 볼 수 있다. 

 

그래서 내용을 본다고 뭘 할 수 있는가?

패킷에는 클라이언트와 웹 서버가 어떤 요청을 하고 있는지, 어떤 응답을 줬는지에 대한 정보가 담겨 있다.

이런 정보를 확인하므로써 양측의 의도가 잘 전달되고 있는지 확인할 수 있다.

 

또한 프록시 툴은 의도를 변조하여 전달할 수도 있다. 

 

부부싸움 사이에 끼인 나를 생각해보자.  감정이 격해진 엄마, 아빠는 이제 나를 통해 의사를 전달하려 하고 있다.

이때 "당신은 항상 그런 식"이라는 아빠의 말을 내가 "엄마, 아빠가 그래도 사랑한대."라고 전달하면

엄마는 알게 모르게 감정이 풀려서 그날 저녁은 외식을 하게 될 수도 있다.

 

그런데 이때 의사를 전달하고 있는 내가 나쁜 마음을 먹으면 얘기는 달라진다.

하루 아침에 가정의 신뢰가 파탄날 수도 있는 것이다.

 

가장 중요한 점은 패킷엔 쿠키와 세션ID 정보가 담겨 있다는 것이다.이전 주차에서 배웠듯이 쿠키와 세션ID는 사이트가 제공하는 서비스를 누리는데 필수적이며 사용자의 민감한 개인정보에 접근할 수 있다.

 

엄마가 아빠의 비상금이 어디있는지를 언급하면 얘기를 전달하는 내가 아무도 모르게 그걸 몰래 빼돌릴 수도 있다는 말이다.

(그럼 프록시 툴 개 위험한 거 아님? 모든 사람들의 패킷을 엿보는 거 아님?? 지금 내 개인정보도 누가 보고 있는 거 아님???? 이라는 공포가 생길 수 있는데 지금까지 배운 바에 의하면 그건 아닌 듯 하다. 자세한 내용은 버프 스위트의 사용법을 다루면서 얘기할 예정이다.)

 

여기까지는 프록시 툴의 기능에 따른 사용 목적이라고 할 수 있다.

우리는 더 나아가 그 기능을 왜 사용하여야 하는지를 생각해보아야 한다.

 

왜 프록시 툴을 이용하여 패킷의 내용을 보아야 하는 것이며, 의도를 변조하여 전달해보아야 하는 것인가?

 

그건 모든 유저가 개발자의 의도대로만 사용한다고 장담할 수 없기 때문이다.

일반적으로 우리는 회원가입을 하고 로그인하여 사이트가 제공하는 서비스를 누린다. 하지만 공격자는 이런 일반적인 방식을 어떻게든 우회하려 할 것이다. 프록시 툴은 이들이 로그인을 우회하는 방법을 찾을 때 필요하다.

 

즉, 우리가 프록시 툴을 배워야하는 이유는 사이트를 해킹하기 위해서가 아니라

공격자가 서버의 자원을 무분별하게 사용할 가능성을 찾아내기 위함이며

이것은 모의해킹이 필요한 이유와도 크게 연관이 있다.

 

 

 

 

◈ Burp Suite (버프 스위트)

 

버프 스위트는 유명한 웹 프록시 툴임.

 

• 설치하기

1) 검색창에 burp suite 검색

 

2) 이 사이트에 들어가기

https://portswigger.net/burp

Burp Suite - Application Security Testing Software

 

3) product 탭에서 community edition 찾아 들어가기 (무료 버전)

4) 입력창 아래에 Go Stragint To Download 클릭

 

5) 설치한 .exe 파일 실행

 

6) 무한 다음, 설치

 

7) 파일 실행

아이콘이 한반도 모양이다.

8) 파란 화면 뜨고 나오는 첫번째 페이지 : 프로젝트 관리 창 

이어하기 할 수 있음. 근데 무료버전에선 못 쓰고 어차피 잘 안 쓴다고 들음 -> NEXT

 

9) 두번째 페이지 : 버프스위트 세팅 -> 기본 설정 사용하기 선택 -> Start Burp

 

10) 그럼 이제 버스 스위트가 시작되는데 

상단 바에서 가장 많이 사용할 탭이 Proxy 탭이고 

이번 주차에서는 Repeater와 Decoder, Comparer를 배웠다.

 

11) 프록시 설정

본격적으로 사용하기 전에 가장 중요한 설정이 남아있다. 프록시 설정이다.

여서 설정할 수 있슈.

 

저 톱니바퀴를 누르면

이런 화면이 뜨는데 여기서 버프 스위트가 어디로부터 패킷을 받을지를 정할 수 있다.

다시 말해, 프록시 리스너를 설정할 수 있다.

 

현재 기본적으로 만들어져 있는 설정을 사용해도 되지만 간혹 리스너를 직접 열어야 할 때도 있다.

그러기 위해서는 사진에 표시된 Add 버튼을 눌러야 한다.

그러면 이런 창이 뜨는데 

 

Bind to port 부분에서 내 컴퓨터의 어떤 포트로 들어오는 패킷을 프록시로 받을지 정할 수 있고

Bind to address 부분에서 어디서 오는 패킷을 받을지를 정할 수 있다.

       1. Loopback only : 내 컴퓨터에서 8888포트로 오고가는 패킷을 버프 스위트로 확인하고자 할 때 사용.

       2. All interfaces : 다른 컴퓨터에서 내 컴퓨터에 있는 버프 스위트로 패킷을 받고자 할 때 사용.

                                  (모바일 앱에서 주고받는 패킷을 확인하고자 할 때 많이 사용)

       3. Specific address : 특정한 IP 주소에서 오는 패킷을 받고자 할 때 사용. 

 

이때 어떤 걸 선택하든 발신지 IP 주소가 버프스위트를 사용 중인 컴퓨터의 IP 주소와 같은 대역대에 있어야 한다. 

(참고로 위 설정은 프로젝트를 저장하지 않는 한 버프 스위트를 껐다 키면 또 다시 해야 하는 듯하다. 근데 무료엔 프로젝트 관리를 못하니까 매번 새로 세팅해야할듯!)

 

 

12) 브라우저 프록시 설정 (찐막)

 

버스 스위트의 귀가 어디로 향할지 정해서 뚫었다면

내가 사용할 브라우저의 입이 버프 스위트로 향하도록 설정해야 한다.

 

나는 원래 크롬 브라우저를 많이 사용하는 편이지만 크롬도 엣지도 해당 브라우저에서 통신하는 패킷만 프록시로 보내는 게 아니라

내 컴퓨터에서 보내는 모든 패킷을 프록시를 통해 보내도록 설정해야하는 것 같아서 (내가  잘 모르는 것일 수 있음)버프 스위트가 필요할 때는 파이어 폭스를 이용할 생각이다.

 

   1. 파이어 폭스를 다운 받는다.

   2. 실행한다.

  3. 파이어폭스 설정에 들어간다.

    4. 우측 상단에 있는 검색창에 프록시를 써넣고 검색 결과의 설정에 들어간다.    5. 수동 프록시를 선택하고 버프 스위트에서 설정한 리스너의 IP주소와 포트 번호(내 경우 127.0.0.1:8888)를 입력한다.    6. 확인

 

이제 파이어폭스에서 사용한 내 인터넷 기록을 버프 스위트에서 볼 수 있다.

 

 

이처럼 프록시 툴을 사용하여 패킷을 보려면 프록시 툴에서 귀를 어디로 향하게 할 것인지를 설정해야할 뿐만 아니라패킷의 주인, 사이트 이용자의 입이 내 버프 스위트로 향하도록 설정할 필요가 있다. 사람의 허락이 필요한 부분이라는 뜻이다.

 

따라서 물리 해킹이 동반되지 않는 한 누가 내 패킷 보고 있을까봐 너무 걱정할 필요는 없어 보인다.  

(근데 세션이나 쿠키 탈취가 허락 받고 하는 건 아닐텐데... 공부가 필요한 부분이다.)

 

 

 

버프 스위트 https 환경에서도 사용하는 방법

버프 스위트를 연결한 채로 네이버나 유튜브를 들어갈 경우 "연결이 비공개로 설정되어 있지 않습니다."라는 경고문이 뜬다. 이건 버프 스위트의 인증서 문제이다.

 

아래 두 곳에서 방법을 찾았다.

https://always-try.tistory.com/7

버프스위트 (Burp suite) 사용 가이드 - 4. HTTPS (구글, 네이버 등) Proxy 불가 이슈 조치 방법 (버프스위

https://choideu.tistory.com/291

Burp suite - HTTPS 접속 설정하기

 

 

https 문제를 해결하기 위해선 

1) Proxy settings에 들어가서 리스너 설정 부분 하단에 있는 Import/Export CA Certificate을 클릭한다.

2) Export에 있는 Certificate in DER format을 선택하고 원하는 저장위치에 내보내기 한다.

    (이름은 첫번째 블로그를 따라 burp.crt로 설정했다.)

3) 해당 인증서를 찾아 더블클릭하면 인증서 설치 버튼이 나온다. 클릭하여 실행한다.

4) 로컬 저장소를 저장소 위치로 설정, 모든 인증서를 다음 저장소에 저장 -> 찾아보기

5) 신뢰할 수 있는 루트 인증 기관 -> 확인

 

잘 받아졌나 확인하려면

1) 제어판에 있는 "컴퓨터 인증서 관리"에 가서 좌측 메뉴에 신뢰할 수 있는 루트 인증 기관 선택

2) 인증서 -> PortSwigger CA를 찾아 더블 클릭.

(인증서의 용도: 모든 발급 정책, 모든 응용 프로그램 정책| 발급 대상, 발급자: PortSwigger CA)

 

파이어폭스에서 인증서 확인

1) 파이어폭스 설정에서 개인 정보 및 보안 -> 보안 -> 인증서 보기 선택

2) 가져오기 -> 해당 인증서 선택 -> Trust 어쩌구 다 선택 -> 확인

 

이 과정을 거치면 이제 네이버나 유튜브같이 https 프로토콜을 사용하는 사이트의 패킷도 볼 수 있다.

 

 

 

• 탐색하기

앞서 말했듯이 우리는 버프 스위트에서 Proxy 탭을 가장 많이 쓸 것이다.

그 중 특히나 많이 쓸 하위 탭이 intercept, HTTP History, Proxy settings 이다.

 

1) Proxy settings

 

㉮ Proxy Listeners

프록시 리스너 설정을 하여 어떤 포트로 받을지, 어떤 IP주소의 패킷을 받을지 등을 설정할 수 있다.

 

㉯ Request Interception Rules

앞으로 배울 intercept 탭에서 어떤 요청을 가로막을지 여기서 설정할 수 있다.

 

㉰ Response Interception Rules

앞으로 배울 intercept 탭에서 어떤 응답을 가로막을지 여기서 설정할 수 있다.

 

㉱ HTTP match and replace rules

HTTP 요청, 응답 중 설정한 부분을 자동으로 교체해서 보내도록 할 수 있다.

 

 

 

2) Intercept

 

여기서 패킷 이동을 차단하여 패킷 내용을 보고 수정할 수 있다. 

상단의 intercept on이라고 쓰인 버튼이 현재 버프 스위트를 지나가는 어떤 요청도 지나갈 수 없게 하고 있다는 뜻이다.

우측에 Forward 버튼을 클릭하면 로그에 있는 한 줄씩  서버로 전송할 수 있다. (옆에 화살표를 누르면 한번에 모두 보내는 선택지도 있다.)

 

Intercept on을 다시 누르면 Intercept off가 되는데 버프 스위트에서 차단하던게 열리며

막혀있던 모든 요청이 지나가게 된다. 와르르~~ 그럼 이제 막히는 것 없이 요청 응답이 원활하게 이루어진다.

 

 

 

3) HTTP history

 

버프스위트를 통과한 요청/응답 패킷이 줄줄이 뜨는 곳

유튜브 index페이지를 요청한 결과이다.

 

위와 같이 화면 상단엔 요청 로그가 줄지어 나타나고 

그 아래로는 요청과 응답 헤더 정보가 뜨고 헤더 부분에서 한 줄 띄고 요청의 본문이 이어진다. (html 형식 등)

pretty, raw, hex, render 정보로 볼 수 있으며 그 중 render에서는 사이트 미리보기가 가능하다.

 

예를 들어 로그인 과정을 분석하고 싶을 때 프록시 설정을 해두고

해당 사이트에서 정상적인 로그인 절차를 밟은 뒤 history를 분석할 수 있다.

 

요청 로그 창에서 우클릭하면 여러 항목이 뜨는 것을 볼 수 있는데

그 중 clear history를 선택하면 로그 정보가 말끔히 사라진다.

 

 

 

4) Repeater

 

요청을 수정하여 몇 번이고 서버로 보낼 수 있다.

HTTP history에서 필요한 재요청이 필요한 로그를 선택한다.

request 탭에서 우클릭하면 여러 항목이 뜨는데 그 중 Send to Repeater를 선택하면

저 위에 화살표가 가리키는 Repeater 탭이 주황색이 될 것이다.

 

이제 Repeater 탭으로 이동하여 확인해보자.

Request 탭에 위의 요청 정보가 그대로 들어 있다.

 

요청 정보에서 수정하고 싶은 부분을 찾아 수정하여 상단의 Send 버튼을 누르면

원하는 요청으로 바꿔서 서버에 재요청할 수 있다.

수정한 요청헤더를 보내 응답을 받은 모습이다. 이건 여담인데 요청헤더의 쿠키에 세션으로 저장된 값으로 로그인해봤는데 로그인이 안된다.(물론 저 값은 내 계정으로 로그인해서 얻은 결과이다.) 세션ID가 아닌건가? 아니면 로그인 폼이 아니라 요청헤더에다 넣어야 적용되나? 내 사이트에 세션을 적용시켜보면 뭐가 정답인지 알 수 있을 것 같다.

 

5) Decoder

 

 

인코딩된 정보를 디코딩시킬 수 있다.

물론 디코딩 사이트가 있지만 귀찮게 여기저기 갈 필요 없이 버프 스위트 내에서 해결할 수 있다는 장점이 있다.

인코딩은 인간들이 쓰는 언어를 암호화, 부호화하는 것이고 디코딩은 그것을 해독하는 것으로 보면 될 것 같다.

 

좌측의 창에서 인코딩, 혹은 디코딩할 데이터를 입력하고

우측에서 어떤 방식으로 인코딩, 혹은 디코딩할 건지 정할 수 있다.

 

admin이라는 글자를 html로 인코딩한 결과이다.

 

 

6) Comparer

두 텍스트의 차이를 비교해주는 기능이다.

 

어떤 요청/응답 정보가 되게 비슷하게 생겼는데 다른 부분이 있는지 확인하고 싶은 경우 사용한다.

HTTP history에서 요청 정보를 복사하고 Comparer 탭에 가서 우측에 있는 버튼 중 Paste를 클릭하면

복사했던 텍스트가 목록에 추가된다.

 

그렇게 비교할 두 텍스트를 모두 넣고 우측 하단의 Words를 클릭하면 어떤 부분이 다른지 단어 단위로 보여준다.

(텍스트를 더 넣어도 비교는 두 개씩만 할 수 있다.)

화이팅~!

 

좌측 하단엔 다른 부분이 어떤 식으로 달라졌는지 표현할 색을 나타내고 있고

우측 하단의 Sync views를 선택하면 스크롤을 하나만 움직여도 두 화면이 같은 위치를 보여주도록 하는 기능이 활성된다.

 

 

4주차에 배운 버프 스위트의 기능은 대략 이정도이며

아래부터는 이 기능들을 어떻게 사용하는지 CTF를 풀어보며 실습한 내용이다.

 

 

추가로, 버프 스위트를 연결한 파이어 폭스는 이제 버프 스위트를 끄면 사용할 수 없다. 두 마을을 연결하던 유일한 통로가 사라지면 소통은 끊기게 되어있다. (물론 사람의 경우 필요하면 어떻게든 방법을 찾는다.)

파이어폭스의 프록시 설정을  사용안함으로 바꾸면 계속 사용할 수 있다.

버프 스위트를 종료한 상태로 파이어폭스를 통해 네이버에 접속하려 한 결과 화면이다.

 

 

 

◈ 버프 스위트를 활용해 CTF 풀어보기

 

• 1번

첫번째 문제의 링크를 누르자 나온 사이트이다.

이제 버프 스위트의 HTTP history 탭에 가서 /1_burp 페이지를 요청한 기록을 확인한다.

요청과 응답 헤더의 내용을 볼 수 있다. 

응답 헤더의 주석처리된 내용이 문제의 힌트이다.

 

우선 요청 헤더 창을 우클릭하고 해당 내용을 repeater로 보낸다

그 후 User-Agent부분 내용을 지우고 segfaultDevice를 써넣는다. send버튼을 눌러 요청을 서버에 보낸다.

응답 바디부분에서 flag를 발견할 수 있었다.

텍스트{텍스트} 형식으로 된 flag를 복사해서 사이트의 입력칸에 붙여넣어 제출하면

 

클리얼~

 

다음.

 

 

• 2번

2번 문제의 링크를 클릭하고 /2_burp 요청 내역을 확인한다.

 

이번 문제의 실마리는 a.html 파일과 b.html 파일 비교하는 것이다.

그러려면 우선 이 두 파일의 내용을 알아야 한다.

 

두 파일을 요청하기 위해 요청헤더 첫번째 줄의 구조를 알아야하는데

 

HTTP 요청 헤더 첫번째 줄의 구조는

[메소드] [파일경로] [HTTP 프로토콜] 이런 식이다. 

(응답헤더의 경우 [HTTP 프로토콜] [HTTP상태코드])

 

따라서 a.html을 요청하려면 메소드의 GET 다음에 있는 /2_burp을 /2_burp/a.html로 수정하여 재요청하면 된다. 

리피터를 활용하여 a.html을 요청한 결과

리피터를 활용하여 b.html을 요청한 결과

 

이제 두 요청의 응답으로 받은 본문을 복사하여 comparer에 붙여넣고 두 텍스트를 word단위로 비교한다.

우측 하단의 sync view를 활용하면 편하게 비교할 수 있다.

추가된 단어가 보인다.

이 단어를 조합하여 flag를 만들고 사이트에 제출하면

 

클리얼~

 

다음.

 

 

 

• 3번

이번 문제의 실마리는 1~20 이라는 숫자 범위이다. 리피터의 냄새가 솔솔 난다.

우선 해당 링크를 누르고 HTTP history에서 요청 내역을 확인한다.

http 요청과 그에 따른 응답

여기서 1~20까지 증가시키면서 반복적으로 요청할 수 있는 부분을 확인한다.

 

음 cookie에 있는 answer와 그 밑에 upgrade-insecure-requests가 눈에 띈다.

answer는 응답 헤더에서 받은 값이므로 이걸 바꿔가야하지 않을까 싶다.

 

일단 요청을 리피터로 보내고 answer부터 1씩 증가시켜 보내본다.

 

스스로에 대한 불신의 시간 끝에 응답 본문에 원하는 값이 떴다. 

 

찾은 flag 값을 답 입력창에 복붙하면

 

클리얼~

 

다음.

 

 

upgrade-insecure-requests는 

대충 니 응답 암호화하고 진짜인 걸 증명해줘라(?)라는 의미로

클라이언트 측에서 요청 헤더에 포함시켜 보내는 신호인 듯

 

문법 자체가 Upgrade-Insecure-Requests: 1 이거인 걸 보면 1이 일케 해줘라 라는 의미인 듯 하다.

 

vary헤더로 Upgrade-Insecure-Requests 이걸 담아서 보내면 https에 리다이렉션 시킬 수 있는 듯 하다.

 

 

 

• 4번

4번 문제는 좀 특이하다. 

문제 링크를 클릭했더니 2개의 로그가 기록된 것이다.

 

상태 코드를 보아하니 첫번째 /4_burp/flag.php는 302로, 찾아보니 임시 이동을 뜻한다고 한다.

핵심은 리다이렉션 당했다(?)는 뜻. 왜 리다이렉션 페이지를 거쳐야 했을까?

첫번째 /4_burp/flag.php 의 요청, 응답 패킷. 응답 패킷에서 사용자에게 level이라는 쿠키를 주기로 설정한 걸 확인할 수 있다.location이 현재 디렉토리의 flag.php로 설정되었다. 현재 디렉토리 안에 flag.php 파일이 있고 현재 디렉토리 안에 4_burp 디렉토리 안에 flag.php라는 다른 파일 있는 걸까?

두번째 /4_burp/flag.php 요청, 응답 패킷. 이전에 응답 헤더에 있던 level값이 요청의 쿠키 헤더로 전달되었다.

 

4번의 핵심은 쿠키값으로 받은 level로 보인다. 

저걸 어쩌라는 걸까?

 

우리가 찾아야 하는 것은 flag이며 flag의 형태는 문자열{문자열}이 보통인 듯하다.

하지만 level 값 자체로는 답을 알기 어렵다. 

여기에 위에서 다뤘던 버프 스위트의 Decoder 기능을 사용해보면 어떨까?

 

level의 값을 드래그해 보니 우측 inspector 부분에 

url로 디코딩하고 base64로 또 디코딩해야 한다.

이런 결과가 출력되었다. (좋은 세상)

디코딩한 결과는 user였다.

 

이제 요청 헤더를 리피터로 옮기고 level의 값으로 부호화된 값 대신 user를 써넣어 재요청한다.

 

그러면 아무 변화가 없다. 이건 답이 아니라는 뜻이다.

그래도 명백하게 user라는 값이 나왔으니 접근은 괜찮은 것 같다.

 

그럼 대체!!! 뭐~~가 문제냐!!

 

user라는 단어가 문제인 것이다. 한낱 사용자따리로는 접근할 수 없는 flag인 걸까?

그럼 내 레벨을 admin 으로 승격시키면 될 일이다.

 

이제 admin이란 단어를 부호화해보자.

순서는 user를 디코딩했던 역순이다. (base64 -> url. 다른 순서로는 안된다. 이게 저 서버의 규칙인 듯?)

순서대로 admin - base64 인코딩 결과 - url 인코딩 결과

최종 결과를 복사해서 리피터에 있는 요청 헤더의 level 값에 붙여넣는다.

보낸다.

응답 헤더에 또 영문 모를 글이 있음을 확인한다.

드래그한다. 

우측 화면을 확인한다.

최종 flag 값을 얻는다.

 

답 입력란에 저 flag를 입력하면

 

클리얼~

 

NEXT.

 

 

뭐로 디코딩해야할지 눈치채기 위한 인코딩 종류, 특징 간략 정리 (진짜 간략함)

https://ghdwn0217.tistory.com/76

인코딩(Encoding)이란 ? : ASCII, URL, HTML, Base64, MS Script 인코딩

 

 

1. ASCII : 0~127까지의 숫자로 영어 대소문자, 보조문자, 제어문자 표현

 

2. URL : 퍼센트(%)가 많아!!!!

                 HEX값 앞에 % 씀

 

3. HTML : 앤드(&)가 많아!!!!!

                   내 html코드를 보안 등의 목적으로 인코딩

 

4. base64 : 코드 마지막에 = 또는 ==가 붙어!!!!!!!

                        이메일 사용 인터넷 표준 포멧 (MIME)를 위해 사용