CTF/MISC

[LACTF] EBE - MISC / Wireshark / Tshark

SecurityMan 2023. 2. 21. 11:00

 

MISC 카테고리에 있던 문제

 

포렌식으로 분류해도 될 것 같다.

 

MISC는 miscellaneous의 약자로 여러가지 잡다한 이라는 의미를 가지고 있다.

 

반응형

 

문제 설명을 읽어보면

 

친구에게 UDP 를 이용해 플래그를 한글자씩 보내고 있었는데

 

누군가가 이상한 데이터를 보내서 망쳐놨다고 한다.

 

RFC 3514 와 관련있을거 같다는 힌트가 같이 주어진다.

 

 

RFC 3514 가 뭔지 궁금해서 구글에 검색해봤다.

 

위키피디아 문서가 하나 나오는데 Evil bit 이라는 제목이다.

 

IPv4 패킷 헤더에 추가되는 만우절에 만들어진 뭔가인듯 하다.

 

일단 여기까지만 대충 보고 문제 파일로 바로 들어갔다.

 

 

먼저 주어진 EBE.pcap 파일을 Wireshark 를 이용해 열어보았다.

 

10.0.1.10 에서 10.0.1.5 로 보내는 UDP 패킷이 가득 있는게 보인다.

 

패킷을 자세히 보면 패킷의 맨 뒷부분이 Data(data.data) 부분인데,

 

나머지 부분은 다 똑같고 해당 부분만

 

1번 패킷은 4c, 2번패킷은 70 ... 이런식으로 바꿔가며 데이터를 담아서 전송하고 있는것을 볼 수 있다.

 

 

일단 데이터를 추출하기 위해서 tshark를 이용한다.

 

tshark는 Wireshark의 커맨드라인 버전이라고 생각하면 된다.

 

tshark는 칼리 리눅스를 설치하면 안에 내장되어 있다.(https://hackingstudypad.tistory.com/58)

 

tshark 명령어로 실행 가능하며

 

-r 옵션으로 불러올 패킷 파일을 지정해준다.

-T 옵션은 텍스트 출력형식을 지정하는데 fields 형식으로 지정해준다.

-e 옵션은 표시하고자 하는 필드를 지정할 수 있다. -T 옵션과 같이 쓰이는데 data.data 필드를 지정했다.

 

이렇게 추출한 데이터는 data 라느 파일에 저장했다.

 

 

CyberChef(https://gchq.github.io/CyberChef/) 에서 추출한 데이터를

 

Hex 값에서 문자로 바꿔봤다.

 

Output 을 보면 알겠지만

 

아무리봐도 추출된 결과는 아무 의미 없는 데이터였다.

 

 

그 원인은 뭔가 RFC 3514 거라 생각했다.

 

조금 더 자세히 살펴보니

 

패킷은 크게 두 종류가 있었다.

 

15번 패킷처럼(왼쪽) ip.checksum 부분이 e4 c0 인 패킷과

 

16번 패킷처럼(오른쪽) ip.checksum 부분이 64 c1 인 패킷 두 종류였다.

 

어느 한 종류의 패킷만 따로 분류하여 분석하면 의미있는 데이터가 나올것이라 생각했다.

 

 

ip.checksum 부분이 64 c1 인 패킷만 골라내기 위해

 

ip.checksum == 25793 라고 필터를 걸어주었다.

 

 

저렇게 걸어준 이유는 64C1 이 10진수로 25,793이기 때문이다.

 

 

필터를 걸어준 뒤, 

 

File - Export Specified Packets 메뉴를 선택해

 

필터된 패킷만 추출해준 뒤

 

EBE2.pcap 라는 이름으로 저장해줬다.

 

 

그런다음 다시한번 tshark 를 이용해

 

data.data 를 추출한 뒤 data 파일로 저장해줬다.

 

 

다시한번 CyberChef 에서 Hex 값 인코딩을 해주면

 

이번엔 플래그를 찾을 수 있다.

반응형