🏆 2024

맛집 분야 크리에이터

🏆 2023

IT 분야 크리에이터

👩‍❤️‍👨 구독자 수

183

✒️ 게시글 수

0
https://tistory1.daumcdn.net/tistory/4631271/skin/images/blank.png 네이버블로그

🩷 방문자 추이

오늘

어제

전체

🏆 인기글 순위

티스토리 뷰

보안/Wargame

[Hackthebox] - Diogenes' Rage Writeup(문제풀이)

알 수 없는 사용자 2021. 12. 8. 03:04
728x90
반응형

문제 개요

Race Condition

 

처음에 페이지에 접속하면 위와 같이 나옵니다. 그리고 소스코드가 제공됐습니다.

 

소스코드 분석

중요한 부분만 보도록 하겠습니다. 아래 소스코드는 물건을 구매할 때 실행되는 API 입니다.

이곳에서 중요한 부분은 db.registerUser 부분입니다. 아래 쿠폰 발급 받을 때도 registerUser를 하지만, 이곳에서도 registerUser을 한다는 것이 중요한 부분입니다. 그 이유에 대해서는 나중에 말씀드리겠습니다.

 

그리고 아래 코드는 쿠폰을 발급받았을 때 실행되는 API 입니다. 

이곳에서 주요 깊게 봐야할 점은 만약 user 세션 값이 존재한다면, 별도로 registerUser 를 하지 않고, 쿠폰을 가져와서 쿠폰에 적힌 값만큼 addBalance를 한다는 점입니다. 그리고 정말 중요한 점은 async ... then 부분입니다. addBalance를 하고나서 setCoupon 함수를 불러서 쿠폰을 사용했음을 설정합니다. 바로 여기서 Race Condition 이 발생할 수 있습니다.

 

이제 위 두 코드에서 중요한 점 2가지를 뽑자면, 아래와 같습니다.

1. 물건 구매 시에도 registerUser 를 통해서 세션값을 발급 받을 수 있다.

2. 쿠폰 발급 시에 race condition 이 일어난다.

 

1번은 왜 중요하냐면, user 세션이 없는 상태에서 2번을 수행하게 되면 registerUser 함수를 불러일으켜서 매번 새로운 세션으로 쿠폰을 발급받기 때문에 쿠폰을 한 계정에 중복으로 발급받을 수 없기 때문입니다.

그래서 물건 구매 API를 우선 실행시켜서 user 세션을 획득해주어야 합니다.

 

이제 위 시나리오들을 실제로 코드로 작성해서 Exploit 해보겠습니다.

 

Exploit

우선 Exploit 코드는 Python의 multiprocessing 모듈을 이용해서 작성했습니다.

API 요청 순서는 아래와 같습니다.

1. /api/purchase 로 user 세션을 획득합니다.

2. /api/coupons/apply 를 여러 프로세스로 동시에 실행시킵니다.

3. /api/purchase 로 C8 을 구매합니다. 만약 구매에 성공하면 flag 를 출력합니다.

4. 구매에 실패하면 다시 위 과정을 시도합니다.

 

처음에는 C8을 바로 구매하지 않고 A1을 구매하도록 해보았습니다.

그랬더니, A1 의 가격을 제외한 잔여 credits이 무려 $12.45 가 있다고 나옵니다. 똑같은 코드를 다시 반복해서 돌려보아도 아래와 같이 다양한 잔여 credits 이 나오는 것을 알 수 있습니다. 매번 돌릴 때마다 성공과 실패가 달라져서 그런 것 같습니다.

위와 같이 여러번 시도했을 때 충분히 C8 물품을 구매할 수 있겠다고 판단되어서, 바로 C8을 구매해보았습니다.

그랬더니 위와 같이 flag 값이 잘 출력된 것을 확인할 수 있었습니다.

 

추신 : HTB Web Challenges 로서 난이도는 쉬움에 속하는 문제였습니다. 28번째로 풀었습니다! 우와!

 

버그바운티 케이스

찾아보니깐 위 문제의 취약점과 동일한 Race Condition 문제로 버그바운티한 케이스가 있는 걸 발견했는데, 무려 포상금이 1천만원이 넘더군요!

https://hackerone.com/reports/300305

 

Shopify disclosed on HackerOne: Ability to bypass partner email...

 

hackerone.com

 

요약 정리하면, 이메일 변경과 인증 기능에서 생긴 Race Condition 취약점에 대해 다루고 있습니다. 그리고 요약 시나리오는 아래와 같은데요.

  1. 사용자가 이메일 변경 요청을 합니다.
  2. 서버는 해당 이메일로 이메일 인증 URL을 보내줍니다.
    (여기서 사용자는 이메일 인증 URL을 바로 누르지 않고 일단 대기합니다.)
  3. 사용자는 다시 이메일 변경 요청을 합니다. 하지만 이번에는 본인 이메일이 아니라 다른 주요 인사의 이메일로 변경 요청합니다.
  4. 3번과 거의 동시에 2번에서 언급한 이메일 인증 URL을 클릭해서 이메일 검증을 합니다.
  5. 만약 성공적으로 했다면 다른 주요 인사의 이메일로 성공적으로 변경하고 인증받은 것을 확인할 수 있습니다.

해당 취약점의 로직은 간단하지만, 영향력을 봤을 때 특정 shop 의 관리자 급 권한을 얻게 되는 것과 같기에 위험도가 Critical(10.0)로 인정받았고, 무려 $15,250 을 받은 것으로 나타납니다. (대..박...😮)

 

또 문제와 정말 많이 유사한 케이스도 있었는데요. 이번 거는 진짜 문제랑 거의 동일하게 사이버 머니를 무한정 불릴 수 있는 어마어마한 취약점인데, 문제랑 너무 동일해서 흥미로웠던 케이스입니다!

https://hackerone.com/reports/759247

 

Reverb.com disclosed on HackerOne: Race Condition allows to redeem...

 

hackerone.com

 

- 끝 -

728x90
반응형
댓글