RITSEC CTF Write up

Stego

 

the_doge

 

파일을 분석해 보니.. 아무것도 나오지 않아서 문제를 다시 읽어 보았습니다.

 

feed the doge a treat to get the hidden message 를 보고 steghide 를 이용해야 할것 같다 생각이 들었고, treat 를 비밀번호로 사용해 봤습니다.

 

doge_ctf.txt 파일을 열어보면 Flag 를 확인할 수 있습니다.

 

Flag : RITSEC{hAppY_l1L_doG3}

 

 

HD Pepe

 

해당 문제를 보면 exiftool 을 이용해서 확인해 보겠습니다.

 

github 주소를 찾아 볼 수 있습니다.

https://github.com/cyberme69420/hdpepe

 

들어가 보면 아래와 같은 파일이 있습니다.

 

encoder.py 를 확인해 보겠습니다.

 

위의 소스코드는 encoder.py 에서 알파 값을 생성시키는 함수입니다.

base64로 인코딩을 한 값의 문자들을 255-문자의값 형식으로 계산을 해서 알파 값에 들어가게 됩니다.

 

그리고 examiner.py 파일은 이미지를 open 해서 RGBA 값을 추출 하는 파일입니다.

저는 examiner.py 파일을 조금 변환해서 decodeAValues 함수를 만들고 데이터(Flag)를 추출해 보았습니다.

 

해당 코드를 실행해 보면 아래와 같이 Base64 인코딩된 데이터를 출력하고 해당 데이터를 base64 디코딩한 값을 확인할 수 있으며, 디코딩 된 값이 Flag 라는 것을 확인 할 수 있습니다.

 

Flag : RITSEC{M3M3S_CAN_B3_M4LICIOUS}

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

Web

 

misdirection

 

해당 사이트를 들어가보면.. 아래와 같습니다.

 

리디렌션한 횟수가 많다고 해서 BurpSuite 를 이용해서 프록시를 잡아보면 

 

HTTP history를 들어가 보면 아래와 같습니다.

 

Flag : RS{4!way5_Ke3p_m0v1ng}

 

 

Buckets of fun

 

아마존AWS 가 나오고 Bucket 관련 내용을 다룬것 같습니다.

문제를 보기전 어떤 내용인지 확인하기 위해 검색하던중 문서 하나를 발견했습니다.

https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html#access-bucket-intro

Virtual-Hosted-Style URL 이 있다는 것을 알게 되었습니다.

 

문제 url 에 들어가면 아래와 같은 화면을 확인 할 수 있습니다.

 

소스코드를 확인해 보면 아래와 같습니다.

 

위의 박스를 보면 해당 입력 부분은 아무런 작업을 하지 않습니다.

그리고 noscript 를 확인해 보면 해당 사이트를 사용하려면 JS 가 필요하다. 하지만 이용하기 힘든거 처럼 보인다 라는 이야기가 있습니다.

 

JS 가 필요하다고 되어있지만, JS Code를 찾아 볼수 없었지만 아까 문제를 보기전 Virtual-Hosted-Style URL 이라는 것을 알게 되었었고, 현재 접속하고 있는 URL을 보면  http://bucketsoffun-ctf.s3-website-us-east-1.amazonaws.com/ <- Virtual-Hosted-Style URL 이라는 것을 알수 있고,  http://bucketsoffun-ctf.s3.amazonaws.com/ <- 이런식으로 URL을 접속해 보면 XML 파일이 있는것을 확인할 수 있습니다.

 

Key를 확인해 보면 txt 파일이 있습니다. index.html 은 우리가 아까 봤던 경로 인 것 같습니다.

http://bucketsoffun-ctf.s3-website-us-east-1.amazonaws.com/youfoundme-asd897kjm.txt <- 를 확인해 보면 Flag가 있습니다.

 

Flag : RITSEC{LIST_HIDDEN_FILES}

 

 

Potat0

 

해당 사이트에 들어가면 아래와 같은 화면을 확인 할 수 있습니다.

 

소스코드를 확인해 보겠습니다.

파일 업로드가 가능한 링크가 준비되지 않았다고 되어있습니다.

물론 링크는 없지만 파일업로드를 할 수 있다는 것을 알 수 있습니다.

WebScan 기능을 가지고 있는 툴인 gobuster를 이용해서 한번 어떤 파일과 어떤 폴더가 / 하위에 존재 하는지 확인해 보겠습니다.

 

위의 명령어를 입력해보면 upload.php와 photos.php 를 확인 할 수  있니다.

해당 소스코드로 업로드를 해서 웹쉘을 이용해서 flag를 얻어 내는것 같습니다.

웹쉘 관련 파일업로드 설명 :  https://github.com/xapax/security/blob/master/bypass_image_upload.md

 

위와 같이 파일을 생성합니다.

[웹쉘 코드는 사람마다 다 다릅니다.!]

 

그리고 http://ctfchallenges.ritsec.club:8003/upload.php 에서 파일 업로드를 해보겠습니다.

 

 

갤러리가 새로고침 되었다고 합니다.

http://ctfchallenges.ritsec.club:8003/photos.php 로 들어가 보면 갤러리가 있습니다.

 

두번째 세번째는 모르겠지만 첫번째 업로드된 파일은 제가 아까 올린 파일입니다.

 

업로드가 되었다는 것을 확인 할 수 있었고, uploads 폴더로 가보면 다음과 같습니다.

 

제가 업로드한 파일이 보입니다.

들어가보면 아래와 같습니다.

 

ls 를 적어뒀으니 위와 같이 출력이 되었습니다.

 

이번엔 ls / 로 업로드를 해서 확인해 보겠습니다.

 

이런식으로 flag를 찾아보면 /home/flag.txt  가 있는것을 확인 할 수 있습니다.

 

파일 업로드를 해보면 아래와 같습니다.

 

Flag 를 찾을 수 있습니다.

 

Flag : RS_CTF{FILE_UPLOAD_ISN'T_SECURE}

 

 

Our First API

 

2개의 URL이 있습니다.

3000번 PORT 로 들어가 보면 아래와 같습니다.

 

해당 페이지는 API 인증으로만 사용이 되었고, 로컬 포트는 4000번이다. 라고 되어 있습니다.

4000번 PORT 로 들어가 보겠습니다.

 

위의 내용을 보면 아래와 같이 endpoints 를 확인 할 수 있습니다.

 

일단 /api/normal 과 /api/admin 을 확인해 보면 auth 에서 인증 토큰을 필요로 한다고 합니다.

/api/normal에 들어가 보면 아래와 같습니다.

 

Forbidden, missing JWT authorization 이라고 뜹니다. JWT authorization 가 없다고 하는것으로 보아 ~~:3000/auth 에서 봐야 할 것 같습니다.

 

파라미터로 name를 넣어줘야 한다고 합니다. 

?name=admin으로 넣어서 토큰을 한번 받아 보겠습니다.

 

해당 토큰의 내용을 가시적으로 보여주는 사이트가 있습니다.

https://jwt.io/#debugger <- 해당 사이트에 넣어보면 아래와 같습니다.

 

name은 admin 입니다. 하지만 type 이 일반 user 인것을 확인 할 수 있습니다.

해당 토큰을 가지고 ~~:4000/api/normal 에 들어가 보면 아래와 같이 출력이 됩니다.

 

위와 같이 인증엔 성공을 했다고 했지만 normal user한테는 flag를 줄 수 없다고 합니다.

아마 그이유는 앞서 봤듯이 JWT 페이로드에 type이 user로 적혀 있어서가 아닌가 싶습니다.

그렇다면 ~~:4000/api/admin으로 한번 들어가 보겠습니다.

아예 admin이 아니라고 하는군요!

 

그렇다면 우리는 ?name= 이라는 페이로드를 통해서 밖에 토큰을 생성할 수 없기 때문에 type 를 user가 아닌 admin으로 하려면 직접 토큰을 만드는 방법 밖에 없습니다. 토큰을 만들기 위해서 필요한 iat 는 앞에서 확인 했었지만 중요한 데이터가 하나 있습니다.  .pem 확장자인 토큰을 생성할때 사용한 공개키 입니다.

API Documentation 페이지 였던 ~~:4000 페이지에서 소스코드를 확인해 보면 주석으로 추가 힌트를 확인 할 수 있습니다.

 

로봇이 api를 이용해서 당신을 도와줄수 있다고 이야기 합니다.

로봇하면 robots.txt 를 떠올릴수 있고 ~~:3000/robots.txt 에서 .pem 파일을 찾을 수 있습니다.

 

/signing.pem 파일이 있다고 합니다.

~~:3000/signing.pem 을 들어가 보면 파일이 하나 다운로드가 됩니다.

 

토큰을 생성하기 위해 필요했었던 공개키 입니다.

그렇다면 지금 까지 추출한 데이터를 바탕으로 type가 admin인 jwt 토큰을 생성해 보겠습니다.

 

결과값을 확인해 보면 아래와 같습니다.

 

해당 값을 jwt.io 에 넣어 보면 아래와 같이 decode된 것을 확인 할 수 있습니다.

 

생성한 토큰을 가지고 ~~:4000/api/admin 에 접속을 해보겠습니다.

 

Flag : RITSEC{JWT_th1s_0ne_d0wn}

 

 

Hop By Hop

 

해당 문제의 제목을 보면 Hop By Hop 이라고 하면서 힌트로는 forward 라는 키워드가 보입니다.

해당 문자열을 보고 X-Forwarded-For 와 Hop By Hop Header 가 생각 났습니다.

먼저 URL 에 들어가 보면 아래와 같이 화면을 확인 할 수있는데 

 

사이트에 admin 페이지가 있습니다.

~~:81/admin 이라는 URL 을 가지고 있는데 한번 들어가 보면 아래와 같습니다.

 

해당 사이트는 admin 컴퓨터만이 접속 할 수 있다고 합니다.

해당 웹사이트는 IP를 필터링해서 로컬 사용자 에게만 접속을 허용해주는데 아까 힌트로 받았던 X-Forwarded-For HTTP Header(IP 를 저장하는 헤더) 를 Hop By Hop Header로 이용해서 IP 처리를 할 수 없도록 하는 방식을 이용할 수 있습니다.

먼저 아래와 같이 헤더를 바꿔보겠습니다.

 

응답은 위와 똑같습니다.

 

그래서 Connection에 X-Forwarded-For 를 추가했습니다.

 

이에 대한 응답으로는 아래와 같습니다.

 

Flag를 출력해 주는것 같습니다.

 

Flag : RITSEC{2227DF03559A4C4E1173BF3565964FD3}

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

Forensics

 

Take it to the Cleaners

 

해당 사진을 받아서 exiftool 로 확인해 보면 아래와 같습니다.

 

User Comment에 데이터가 들어있습니다. base64 decoding 을 해보겠습니다.

 

 

EVGFRP{SBERAFVPF_SNVYF_JBAG_URYC_LBH_URER} 이렇게 출력이 되는데 RITSEC{ 의 형태라고 생각을 하고 ROT 복호화를 해보겠습니다.

 

 

ROT13 이였습니다.

 

Flag : RITSEC{FORENSICS_FAILS_WONT_HELP_YOU_HERE}

 

 

Long Gone

 

chromebin 이라는 데이터 파일을 주는데 file 명령어를 이용해서 어떤 파일인지 확인해 보겠습니다.

 

tar 파일이네요 알집으로 tar 파일을 압축 해제해 보겠습니다.

 

data가 아니고 기본적인 역사(History)라고 하기 때문에 History 파일을 분석해보면 알것 같습니다.

 

해당 History File 은 DB File 입니다.

 

DB Browser for SQLite를 이용해서 db 파일을 열어 보겠습니다.

 

데이터 테이블을 확인해 보면 keyword_search_terms을 검색한 흔적이 있는데 검색하기 좀 의심스러운 데이터가 있습니다.

 

us-central-1.ritsec.club/l/relaxfizzblur <- 의심 스러운 URL 형식입니다.

링크를 들어가 보면 Flag 를 찾아볼 수 있습니다.

 

Flag : RITSEC{SP00KY_BR0WS3R_H1ST0RY}

 

 

Vacation

 

Long Gone에서 받은 파일 과 동일합니다.

방문한 가장 좋아하는 장소가 있다고 하는데 해당 장소를 구하는 거 같습니다.

 

상식적으로 자기 자신이 가장 좋아하는 장소는 북마크 해두기 마련입니다.

 

해당 북마크는 js 형식으로 저장을 하는것으로 판단이 되서 .js로 확장자를 변경하고 열어보면 아래와 같습니다.

 

roots 하위에 other 하위에 children에 있는 name을 이어보면 RIT 인것으로 보아 Flag 인것 같습니다.

 

jq 명령어로 한번에 추출 해 보겠습니다.

 

Flag를 확인할 수 있습니다.

 

Flag : RITSEC{CHR0M3_BM_FTW}

 

 

Findme

첨부된 파일을 열어보면 주요한 스트림 데이터가 있는데 아래와 같습니다.

 

 

둘다 base64 encoding 되어있는 데이터 입니다.

 

1. aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1kUXc0dzlXZ1hjUQo= = https://www.youtube.com/watch?v=dQw4w9WgXcQ

2. H4sIAFSZx10AA+3OMQuCQBiH8Zv9FPcFgrvUcw2kIWgydzG1EkQPvZui757S0lSTRPD8lmd43+F/6cqrWJmaGRMt1Ums3vtitkKHsdGJDqNtKJSeGwup1h628JMrRymFP/ve+Q9/X+5/Kjvkp316t1Vpp0KNReuKuq17V9x21jb9IwjSPDtuKukGWXXD1AS/XgwAAAAAAAAAAAAAAAAAWDwB38XEewAoAAA=

 

2번 문자열은 복호화를 해도 이상한 값이 나오는데 그 이유는 긴 문자열은 서버관련 패킷이기 때문입니다. 서버에서 gzip compressed data 형식으로 제공을 하기 때문에 gunzip을 해야합니다. 

 

그래서 2번 문자열을 복호화 하려면 아래와 같이 명령어를 입력해야 합니다.

 

위에는 그냥 base64 복호화, 아래는 gunzip 후에 복호화를 하면 Flag를 확인 할 수 있습니다.

 

Flag : RITSEC{pcaps_0r_it_didnt_h@ppen}

 

 

URGGGGG

 

문제 파일을 열어보면 아래와 같이 USB Protocol 을 이용한 패킷들이 눈에 보입니다.

 

USB 입력값중에 특정 고유 값들을 가지게 됩니다.

하나의 패킷을 확인해 보면 아래와 같습니다.

 

해당 데이터를 Capdata라고 이야기를 하는데 00:00:00:00:00:00:00:00 은 0000000000000000 라고 표기를 하는데 아무런 데이터가 없다는 것과 같다.

그래서 해당 capdata가 0000000000000000 이 아니고, URB 타입이 URB_INTERRUPT(0x01) 인것만을 필터링 해보면 아래와 같습니다.

 

이러한 데이터만 추출해 보겠습니다.

 

해당 데이터의 : 를 없애주면 아래와 같이 표현됩니다.

 

해당 데이터를 가지고 아래의 키입력 값을 이용해서 아래 코드를 실행하면 Flag를 획득 할 수 있습니다.

 

위의 코드를 실행하면 아래와 같습니다.

 

Flag : RITSEC{wH0_s@vd_ntw0rk1nG_wAs_tH3_oNlY_pAck3t_TyP3}