SegFault CTF - 4주차
Burp Suite
노말틱 웹해킹 스터디 4주차에서는 Burp Suite의 사용법 위주로 공부했다.
Burp Suite는 클라이언트와 웹 서버 간의 통신을 분석할 수 있는 Web Proxy Tool이다.
Burp Suite는 아래 공식 홈페이지에서 다운로드 받을 수 있다. 무료 버전은 'Burp Suite Community Edition'이다.
Burp Suite - Application Security Testing Software
Get Burp Suite. The class-leading vulnerability scanning, penetration testing, and web app security platform. Try for free today.
portswigger.net
Burp Suite의 주요 기능들
- Proxy
Burp Suite에서 가장 중요한 기능인 Proxy 탭이다. - Intercept
원래는 클라이언트 - 서버 간의 통신을 지켜보고만 있지만, 이 Intercept를 켜주면, 통신을 중간에 멈추게 할 수 있다. - Open browser
프록시가 이 Burp Suite로 설정된 크로미움 브라우저를 실행한다. 굳이 쓰던 브라우저에 프록시 설정을 따로 하지 않아도 되는 편리함을 제공한다.
빨간 네모로 강조된 HTTP history 탭을 누르면 Burp Suite 프록시를 거쳐간 모든 HTTP 통신 기록을 볼 수 있다. 해당 기록은 google.com에 접속한 기록이다.
Repeater 탭에서는 보냈던 패킷을 쉽게 반복해서 보낼 수 있게 해준다.
Decoder 탭은 유틸리티 느낌의 탭이다. Encode/Decode 사이트를 들어가지 않고도 여기서 편하게 encoding/decoding을 할 수 있다.
Comparer 탭 또한 유틸리티다. 여러 문자열들을 동시에 비교할 수 있다. 오른쪽 밑 Compare ... 에서 Words 또는 Bytes 단위로 문자열을 비교할 수 있다.
Compare ... 에서 Words를 눌렀을 때 나오는 창이다. 오른쪽 아래 빨간색 박스로 강조된 Sync views 를 클릭하면 스크롤을 했을 때 옆에 있는 텍스트도 같이 스크롤이 된다. 클릭하는 편이 편리할 것이다.
Segfault CTF
CTF는 Capture The Flag의 약자로, 형식이 정해진 어떠한 숨겨진 문자열을 찾아내는 일종의 게임이다. 보통은 해킹에 성공했을 때 Flag라고 불리는 문자열을 획득할 수 있다. 이번 CTF에서는 Burp Suite를 사용하면 된다는 강력한 힌트를 가지고 시작한다.
사진이 작아서 글자가 잘 보일지는 모르겠지만 Burp Suite Prac 1이라고 적힌 문제부터 풀어보자.
Burp Suite Prac 1
이러한 문구와 함께 페이지 링크를 제공해준다.
그냥 NO DATA라는 문구만 출력되는 페이지를 받았다. Burp Suite를 통해 정확히 어떤 패킷을 받았는지 확인해보자.
?? 풀이법을 그냥 알려준다. User-Agent 필드에 segfaultDevice를 넣어서 Request를 다시 보내보자.
이 때, Intercept를 켜고 새로고침을 해서 패킷을 다시 보내는 방법도 있고 Repeater를 통해 다시 보내는 방법이 있다. 이번에는 Intercept를 켜고 새로고침을 하여 다시 보내보겠다.
이제 이 빨간색 박스 부분의 값을 segfaultDevice로 변경하여 Forward 를 하면
Flag를 획득할 수 있다. segfault{모자이크} 이 부분이 Flag다.
Burp Suite Prac 2
바로 링크에 접속해보면 다음과 같은 Response를 받는다.
a.html과 b.html 두 데이터를 잘 확인하라고 한다. 링크 맨 뒤에 a.html을 붙여서 Request를 보내보겠다.
쓸데없는 글을 반환해준다. b.html을 요청해보자.
또 Lorem ipsum이다. 하지만 사실 달라진 점이 있다. 그 점은 응답 헤더에서 확인할 수 있다. Content-Length가 7292에서 7312로 바뀌었다. 그렇다면 앞서 소개했던 Comparer 탭에서 두 문자열을 비교하면 뭐가 달라진건지 알 수 있을 것 같다.
비교해보니 Flag가 b.html에 숨겨져 있었다.
Burp Suite Prac 3
드디어 멘트가 바꼈다. 무려 힌트를 제공해준다.
Response를 안 주겠다고 한다. 그럼과 동시에 Set-Cookie를 통해 `answer=1`을 지정하는 것을 볼 수 있다.
F5를 누르라고 하니, 눌러보면 클라이언트에서 이러한 패킷을 전송한다.
content는 하나도 없고 뭔가 보낸다 싶은 거라곤 `answer=1`이라고 설정된 쿠키뿐이다.
아까 받은 힌트를 떠올려보면 1~20 사이라고 했다. 이 `answer`에 대한 정답이 1부터 20 사이의 값인 것 같다.
그럼 1부터 20까지 노가다를 해보면 될 것이다. 하지만 브라우저 들어가서 새로고침하고 다시 Burp Suite 켜서 패킷을 수정하는 과정이 번거롭다. 이럴 때 쓰는 것이 Repeater 이다.
Request에서 마우스 우클릭을 하면 Send to Repeater를 찾을 수 있다.
이제 빨간색 박스의 answer 값을 수정하고, 파란색 박스의 Send 를 눌러 간편하게 반복적으로 패킷을 보낼 수 있다. 이걸 최대 20번만 반복하면 Flag를 얻어낼 수 있을 것이다.
1->20보다 20->1이 Flag 얻기 더 빠를 것이다.
Burp Suite Prac 4
아쉽게도 마지막 문제다.
들어가자마자 쿠키를 설정하더니 나보고 Admin이 아니라고 한다. level에 대한 값으로 `dXNlcg%3D%3D`가 들어가 있다. 웬 뜬금없는 `%3D`가 들어가 있다. 이건 URL 인코딩(Percent Encoding이라고도 한다) 때문이다. 기본적으로 URL은 ASCII로 인코딩되기 때문에 한글과 같은 문자는 들어갈 수 없다(지금은 되는 것 같긴 하다만). 또한 `:`, `?`, `%`, `=`와 같은 특수문자들도 특수한 케이스에서 사용되기 때문에 이 URL 인코딩으로 변환이 된다. `%3D`는 이 중 `=`에 해당한다. 따라서 실제로 받은 level의 값은 `dXNlcg==`인 것이다. `=`가 들어간 것을 보면 어떠한 문자열이 Base64로 인코딩이 된 것 같다.
이럴 때 쓰는 것이 Decoder 이다. `dXNlcg==`를 Base64로 디코딩 해보겠다.
디코딩 결과, `user`라는 단어가 나왔다.
내 level이 `admin`이 아닌 `user`였기 때문에 날 통과시켜주지 않은 것 같다. 그렇다면 `user`가 `dXNlcg==`로 인코딩된 것처럼 `admin`을 Base64로 인코딩하여 쿠키를 변조하면 통과시켜줄 것 같다.
이 값을 쿠키에 넣어 보내보겠다. 브라우저가 알아서 `=`을 `%3D`로 인코딩해주기 때문에 이건 따로 인코딩할 필요가 없다.
빨간 박스를 보면 쿠키값이 위조되어 전송된 것을 볼 수 있다. 이에 대한 Response는 전과 다른 모습을 보인다. 이상한 문자열을 반환받았다.
이 문자열 또한 `=`이 들어간 것을 보아 Base64로 인코딩됐음을 직감할 수 있다.
디코딩을 하면 또 `=`가 포함된 문자열이 나오고, 또 디코딩하면 또다시 `=`가 포함된 문자열이 나와 여러번 디코딩을 반복해주면 마침내 Flag를 얻어낼 수 있다.