[Study] Intranet - Web 2020.09.12

문제 페이지를 접근하면 

로그인기능과 회원가입 기능이 구현되어 있다. 

 

회원가입을 하고 나면 게시판 기능과 Mypage 기능이 구현되어 있지만 게시판 열람 및 글쓰기 권한은 없는 상태이며 

Mypage에는 Auth request 기능이 구현되어 있다. 여기에 특정 입력값을 넣으면 권한이 상승되는듯 보였다.

 

다시 로그인이전으로 돌아와서, admin계정 존재 여부를 파악하기 위해 admin계정으로 가입해보았다.

그랬더니 guest권한의 아이디가 생성되었다..

 

그래서 우선은 sqli 가 아니라고 판단하고 발행되는 토큰에 집중을 해봤다.

발급되는 토큰에 뭔가 정보가 숨어있을거라고 생각하고 팀원들과 의견을 나누다가 아래 URL을 전달받았고

jwt.io/

JWT.IO

이내 별 내용이 없음을 확인했다..

 

다시 sqli 로 돌아와서 시도를 하다가 Error 메시지를 통해 문제 시스템이 몽고디비를 사용하고 있다는 것을 알게 되었다.

빈칸으로 로그인 시도 시,

몽고에러 메시지가 노출되었다.

(지금 이글을 적는 시점에서는 같은 request에 대해 406에러가 뜬다.. 왜지?  ㅠㅠ)

 

무튼, 몽고디비는 NoSql 의 예시 중 하나로, sqli를 시도하려면 일반적인 쿼리가 아닌 다른 방식으로 시도해야 했다.

급하게 몽고디비에서의 NoSql Injection에 대해 공부를 하고,

비밀번호가 "" 이 아닐 경우를 조회하므로

{"$ne":""} 구문을 활용해서 NoSqli가 유효함을 확인하였다. 

비밀번호 없이 로그인 가능

같은 구문을 Auth request 기능에 활용하면,

멤버 권한을 획득 가능하며 게시판을 이용 할 수 있다.

 

그 후로 게시판에 XSS등 많은 공격 시도를 해보고,

Auth request에 또 한단계 더 높은 Admin권한 획득을 위한 Sqli도 시도해보고..( {"$regex":"^"} 와 같은 구문으로도 멤버 권한까지는 획득 가능..)

했지만 결국 문제해결에는 실패했다.. 9/12

 

-----------------------------------------------------------------------------------------------------------------------------------

 

마지막에 권한을 한단계더 높은 Admin권한 획득을 위한 시도로, 이미 Member권한인 계정이 URL직접접속을 통해서 한단계 더 권한상승을 요청 하는 시도를 해봤었는데,

결론적으로 실패했지만 시도는 좋았었다고 스스로를 평가하고 싶다.

그 이유인즉슨, 이 문제의 풀이법을 알게되었는데

 

한단계 더 높은 권한 요청을 시도하는 것 자체는 맞았지만 접근방식을 멀티스레드를 활용한 Race Condition 취약점을 이용한 방법이었던 것이다.

 

로직은 이렇다.

[추측 1]

1. 반복문을 통해 여러 계정을 생성한다.

2. 1에서 계정성공한 계정에 대해 멀티스레드로 권한 신청을 요청하면

3. {"$ne":""} 로 권한상승을 요청하기 때문에 처음에는 멤버로 권한 상승시켜주는 로직이 처리를 하지만

4. 부하가 일어나면서 레이스컨디션이 발생하고, 다음 로직인 Admin 권한을 부여하는 로직이 발생되는 것이다.

 

혹은..

내가 개인적인 시도를 통해서 유추한 로직은 이렇다.

[추측 2]

(1) 권한 요청 받음 ->

(2) 권한을 상승시켜준다({"$ne":""} 로 요청하기 때문에 멤버권한->어드민권한 순으로 처리될것이다) ->

(3) 해당 계정에 대해 권한 상승 요청 기능 제한을 한다.

 

동시다발적으로 권한 요청을 받으면 .. (1)

권한을 상승시켜준다.. (2)

여기서 권한상승 요청을 제한 ..(3) 이 처리되기 전에

동시에 받았던 다른 (1) 요청에 의해

(2) 가 한번 더 일어나고, ( 이미 멤버이기 때문에 한번더 상승되면 어드민)

결과적으로 어드민이 되는 것이다.

 

일단 지금까지 이해한 바로는 이러한데... 

(같은 계정에 대해 권한상승이 2번 일어나서 어드민이 되는건지, [추측 2]

 멤버로 상승시키는 로직이 있고(1) 어드민으로 상승시키는 로직이 있는데(2)

 (1)이 바빠서 (2)가 일어나는지 헷갈린다..[추측 1]) 

 

후에 구체적인 롸업을 보고 공부 겸 해서 마무리 지으러 오겠다. 9/13

 

-----------------------------------------------------------------------------------------------------------------------------------

arang 님의 Writeup을 확인했다.

ar9ang3.tistory.com/65

2020 사이버 작전 경연대회 [웹] - Intranet; Write-up

내가 db 에러메시지를 통해 Nosql injection을 추측했다면,

Writeup에서는 mypage 접근 시 /api/static/{:userid} 를 요청하는것과 서버가 nginx인 것을 근거로 file leak의 가능성을 의심하였고

api/static../User.js 를 요청하여 서버단의 소스코드를 확인하는 과정을 거쳐 Nosql injeciton을 하였다.

문제의 설정을 보고 어떤 근거(?)로 취약점을 유추하셨는지에 대해 블로그에 댓글로 문의드렸는데

감사하게도 친절하게 답글을 주셨고

www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Path traversal via misconfigured NGINX alias - Vulnerabilities - Acunetix

와 같은 좋은 글도 추천해주셨다..(갓아랑)

 

내 시도와 Writeup의 차이점을 정리해보면

2단계 권한을 요청해야한다는 것에 대해 나는 단지 추측을했을 뿐이지만

아랑님께서는 소스코드를 획득해서 파악하셨고,

Race Condition에 대한 시도 대한 근거 또한 소스를 분석하셨다.

 

이렇게 구조적 취약점을 통해 파일 다운로드로 소스를 획득 가능했다는 것이 내가 이 문제에서 놓친 가장 큰 부분인 것 같다.. 9/15

 

-----------------------------------------------------------------------------------------------------------------------------------

 

++ 비하인드

게시판에 접근을 하고 나니 admin계정으로 글이 많이 있었다..

혹시나 해서 이전에 만들었던 admin계정으로 로그인해보니 멤버권한으로 바뀌어 있었다..

 

이론상 $regex 를 통해 비밀번호 유추가 가능하고(실제로 일부 구해짐을 확인..),

그 계정의 password는 내가 평소에 자주 사용하는 것이었기 때문에 급히 운영진에게 비밀번호 초기화를 요청했던 해프닝이 있었다 ㅋㅋ.