2023. 11. 15. 23:26ㆍnormaltic 취업반 5기/내용 정리
Burp Suite (버프 스위트)
버프 스위트는 프록시를 사용하여 클라이언트 측에서 서버 측으로 보내는 HTTP 요청을 가로채 분석 및 수정을 할 수 있는 웹 프록시 툴이다. 기본 기능 외에도 다양한 기능들이 존재하여 웹 애플리케이션의 취약점을 테스트하거나 모의해킹을 수행할 수 있도록 해주는 점검 도구로서의 역할도 가진다.
일반적으로 클라이언트-서버 구조의 데이터 전달 방식은 클라이언트에서 서버에게 요청하면 서버는 그에 해당하는 데이터를 응답해주는 방식이다.
그러나 여기에 프록시가 개입을 하게 되면 클라이언트가 서버로 데이터를 요청 시 프록시를 거쳐 보내게 되고 마찬가지로 서버가 클라이언트에게 데이터를 응답 시 프록시를 거쳐 보내게 된다. 이때 프록시는 중간전달자로서 요청 및 응답에 해당하는 데이터들을 확인 및 변경이 가능하다.
Burp Suite의 기능
버프 스위트에서 사용할 수 있는 기능들을 상단 탭에 배치하였으며 어떤 기능들이 있는지 알아보자.
1) Dashboard
자동화된 활동들을 보기 쉽게 디스플레이 해놓았으며 이곳에서 모니터링하고 제어 가능하다.
2) Target
목표 어플리케이션에 대한 자세한 정보를 확인할 수 있는 기능이다. 필요시 취약점 테스트도 수행 가능하다.
3) Proxy
버프 스위트의 대표적인 기능이며 클라이언트와 서버 간의 요청 및 응답 시 데이터를 확인 및 변경이 가능하다.
4) Intruder
사용자가 설정한 자동화 공격을 수행하는 기능이다. 어플리케이션 테스트 시 발생하는 모든 종류의 작업을 자동화하는 데 사용한다.
5) Repeater
개별 요청을 반복적으로 수행할 때 사용하는 기능이다. 요청 시 여러가지 값의 변경에 의한 응답을 분석하기 위해 사용된다.
6) Comparer
두 데이터간의 내용에 대한 추가나 삭제 그리고 변경 시 달라진 곳을 확인하기 위해 비교하는 기능이다.
7) Decoder
데이터의 인/디코딩, 암/복호화, 해싱 작업을 수행할 수 있는 기능이다.
Burp Suite 기능 실습
간단한 CTF를 Burp Suite의 기능들을 사용하여 실제 어떻게 작동하는지 알아보자.
1번 문제
1번 문제에 해당하는 웹 페이지를 들어가 보면 'NO DATA'라는 문자열만 볼 수 있다. 이제 이 웹 페이지를 버프 스위트로 확인해 보자.
버프 스위트로 서버 측에서 응답한 데이터를 확인해 본 결과 헤더 중 User-Agent에 segfaultDevice라고 입력 후 요청하라는 안내를 확인할 수 있다. 이는 버프 스위트뿐만 아니라 '페이지 소스 보기' 기능으로도 확인할 수 있으니 참고한다.
버프 스위트 기능 중에 여러 가지 값을 변경하여 요청하는 기능은 Repeater이므로 해당 기능을 사용하기 위해 요청 화면을 우클릭 후 'Send to Repeater'를 클릭하면 해당 화면이 'Repeater'탭으로 보내진다.
Repeater 탭을 클릭하여 들어가면 요청/응답 화면이 보인다. 이제 요청 시 데이터의 값들을 변경 후에 좌측 상단 'Send'라는 주황색 버튼을 클릭하면 변경된 값이 적용된 상태로 응답을 받을 수 있다.
User-Agent 헤더의 값을 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.6045.123 Safari/537.36'에서 'segfaultDevice'으로 변경 후 요청했더니 다른 응답을 받아 플레그를 획득할 수 있었다.
2번 문제
2번 문제에 해당하는 웹 페이지를 들어가 보면 'LOOK INSIDE'라는 문자열만 볼 수 있다. 이제 이 웹 페이지를 버프 스위트로 확인해 보자.
이번에는 a.html과 b.html 두 데이터를 잘 확인해 보라는 안내를 확인할 수 있었다. 우선 a.html과 b.html의 데이터를 확인하려면 주어진 URL를 통해 요청을 해야 한다. 그렇다면 URL에 파일을 요청하듯 /a.html과 /b.html을 입력해 보자.
두 페이지를 각각 요청했더니 수많은 문자가 나열되어 있다. 두 페이지의 처음을 잘 살펴보면 같은 내용을 담고 있는 것으로 확인이 되나 마지막 문단을 확인해 보면 두 페이지간 글자 수의 차이가 있음을 추측해 볼 수 있다. 이것을 하나하나 확인해 보는 것은 매우 시간 낭비적인 일이니 이러한 상황에 필요한 Comparer 기능을 사용하도록 하자.
Repeater기능을 썼을 때와 마찬가지로 비교가 필요한 부분을 'Send to Comparer'으로 보내게 되면 사진과 같이 두 데이터가 존재한다. Comparer 기능을 사용하려면 우측 하단에 'Words'와 'Bytes' 버튼이 존재하는데 각각 어떤 형식으로 비교할 건지를 나타낸다. 여기서는 글자를 비교해야 하므로 Words 버튼을 클릭한다.
클릭을 하게 되면 이렇게 두 데이터를 양쪽으로 보인다. 우측 하단에 'Sync views'라는 체크박스를 체크하게 되면 한쪽의 스크롤 바만 작동시켜도 양쪽이 같이 싱크 되어 움직인다.
스크롤 바를 오른쪽으로 움직였더니 노란색 하이라이트된 부분을 볼 수 있다. 좌측 하단을 보면 두 데이터를 비교했을 때 수정되었는지, 삭제되었는지 추가되었는지를 색깔에 따른 하이라이트로 확인할 수 있다. 노란색 하이라이트이므로 추가된 문자열이라는 것을 알 수 있으며 저 두 문자를 연결하면 플레그를 획득할 수 있다.
3번 문제
3번 문제에 해당하는 웹 페이지를 들어가 보면 'No Flag'와 'Press F5'라는 문자열만 볼 수 있다. 이제 이 웹 페이지를 버프 스위트로 확인해 보자.
버프 스위트로 확인해 본 결과 응답 측에서 'answer=1'의 쿠키를 발급하는 것을 확인할 수 있다. 그렇다면 문자열 그대로 F5를 눌러서 새로고침 해보면 쿠키가 발급된 것을 확인할 수 있다. 쿠키는 요청 시 같이 동봉되어 요청되는 성질과 문제에서 주어진 힌트를 연계해 보면 Repeater 기능을 사용하여 answer 쿠키의 값을 1부터 20까지 변경하면서 요청하는 시나리오를 생각해 볼 수 있다.
요청 페이지를 Repeater로 보내고 answer값을 변경하면서 요청했더니 answer=13일 때 플레그를 얻을 수 있었다.
4번 문제
4번 문제에 해당하는 웹 페이지를 들어가 보면 'You are Not Admin'이라는 문자열만 볼 수 있다. 이제 이 웹 페이지를 버프 스위트로 확인해 보자.
버프 스위트로 확인해 본 결과 level이라는 이름의 쿠키를 발급하고 있는 것을 확인할 수 있다. 이때 level 쿠키의 값을 자세히 살펴보면 '%3D%3D'라는 문자열을 볼 수 있는데 이는 대체 URL 코드로 '=='라는 것을 확인할 수 있다. 그렇다면 지금 level 쿠키의 값은 URL 인코딩 된 상태라는 것을 알 수 있는데 이를 디코딩하기 위해서 버프 스위트의 Decoder 기능을 사용하자.
Decoder로 들어가 보면 대상 문자열을 입력할 수 있는 공간과 오른쪽에 어떤 기능을 사용할지를 확인할 수 있다. Decode as는 대상 문자열을 디코딩한다는 뜻이고 Encode as는 인코딩을, 그리고 Hash는 해싱 작업을 의미한다. 그렇다면 URL 형식으로 디코딩을 해보자.
URL로 디코딩하면 '%3D'가 '='로 변경된 것을 확인할 수 있다. 여기서 또 하나 알 수 있는 점은 문자열 마지막이 '='나 '=='로 끝나는 문자열은 base64 형식으로 인코딩 된 것으로 추측해 볼 수 있다. 그렇다면 한번 base64로 디코딩해보자.
base64로 디코딩한 결과 'user'라는 결과가 나왔다. 이걸 통해 알 수 있는 점은 현재 발급된 쿠키의 값은 'user'라는 문자열이며 이 문자열은 base64 인코딩 후 URL 형식으로 인코딩이 되었다는 것을 알 수 있다. 그렇다면 'admin' 문자열을 base64 인코딩 후 URL 형식으로 인코딩한 값을 level 쿠키 값에 넣어서 요청을 하게 된다면 플레그를 얻을 수 있을지도 모른다.
admin이라는 문자열을 base64 인코딩 후 URL 형식으로 인코딩했더니 추측했던 형태와 다른 형태를 볼 수 있다. 그렇다는 것은 base64 형태에서 '=' 문자만 '%3D'로 바꾸기만 하면 된다. 해당 과정을 모두 거치게 되면 'admin'문자열은 'YWRtaW4%3D'라는 문자열로 변경을 할 수 있으며 이를 level 쿠키 값에 넣어 요청을 하게 되면 플레그를 획득할 수 있는 가능성이 존재한다.
요청 페이지를 Repeater로 보내 쿠키값을 변경하여 요청하면 '='로 끝나는 문자열을 응답한다. 이는 위에서도 언급했듯이 base64로 인코딩 된 것이라 생각해 볼 수 있다. 그렇다면 해당 코드를 디코딩해보자.
해당 코드를 base64 형식으로 세 번 한 결과 플레그를 획득할 수 있었다.
웹 상태 코드
서버에서의 처리 결과는 응답 메시지의 상태 라인에 있는 상태 코드를 보고 대략적으로 파악할 수 있다.
- 100번대 : 임시 응답으로 현재 클라이언트의 요청까지는 처리되었으니 계속 진행하라는 의미
- 200번대 : 클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미
- 300번대 : 완전한 처리를 위한 추가 동작이 필요한 경우이며 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니(리다이렉션) 그 주소로 다시 시도하라는 의미
- 400번대 : 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미
- 500번대 : 서버에서 클라이언트의 요청 처리에 문제가 발생된 경우이며 서버 과부화, DB 처리 과정 시 오류 등 서버에 문제가 생겨 제대로 된 응답을 하지 못하는걸 의미
'normaltic 취업반 5기 > 내용 정리' 카테고리의 다른 글
| [normaltic 취업반 5기] 2023-11-29 6주차 내용 정리 (0) | 2023.11.29 |
|---|---|
| [normaltic 취업반 5기] 2023-11-22 5주차 내용 정리 (0) | 2023.11.22 |
| [normaltic 취업반 5기] 2023-11-08 3주차 내용 정리 (0) | 2023.11.08 |
| [normaltic 취업반 5기] 2023-11-01 2주차 내용 정리 (0) | 2023.11.02 |
| [normaltic 취업반 5기] 2023-10-25 1주차 내용 정리 (0) | 2023.10.25 |