Open redirect 취약점 모의해킹

오랜만에 모의해킹을 진행했는데 재미있는 취약점이 발견됐다.

 

Open redirect 취약점인데 좀 다른 느낌의 취약점이고, 계정 탈취까지 되는 취약점이였다.

 

처음엔 CRLF 인젝션이 될까? 하고 %0d%0a 넣고 이런저런 삽질을 해봤는데 아쉽게도 CRLF 인젝션은 안되더라..

 

# 로그인 프로세스

1. 로그인 페이지 접근 및 요청
 - (공격 벡터1) callback URL과 이전 페이지로 돌아가기 위한 파라미터 returnUrl이 포함되어 있음

2. A 페이지로 로그인 시도 및 returnUrl 파라미터가 담긴 callback URL 전달
 - (단서1) callback URL의 domain name, scheme를 여기서 검증 하고 있음

3. 로그인 성공이면 callback URL 뒤에 임시 토큰을 nonce라는 파라미터로 전달

4. B 페이지로 도메인, returnUrl, accessToken, refreshToken 파라미터를 location 헤더에 삽입하여 리다이렉트
 - (공격 벡터2) accessToken, refreshToken을 파라미터에 노출하고 있음
 - Set-Cookie를 통해 JWT 토큰 발급 완료

 

일반적인 Open redirect 취약점은 공격자가 원하는 도메인으로 넘길 수 있는데, 이미 해당 서비스는 callback URL에 입력된 값의 domain name과 scheme를 검증하고 있어 도메인 수정이 불가능했다. (혹은 Unicode reverse character를 사용해서 뭔가 트릭이 가능할까 했는데 불가능했다...)

 

여러가지 삽질을 해보니 4번 공격 벡터에서 https://example.com으로 고정적으로 URL이 삽입되어 있고 returnUrl파라미터를 뒤에 붙여서 concat하는 방식을 사용하고 있었다.

 

이 말은 도메인이 https://example.com, returnUrl은 pany/ 인 경우 https://example.com과 pany/가 concat 되어 https://example.company 이라는 URL이 완성된다.

 

따라서, returnUrl이 처음 삽입되는 1번 벡터에서 pany/를 삽입하고 로그인하면 4번 벡터에서 accessToken과 refreshToken을 탈취할 수 있다는 소리. (실제로 *.company 도메인은 19,000원에 구입이 가능한 도메인이였다.)

2번 벡터에서는 scheme가 무조건 https여야 하고, 도메인은 auth.example.company를 가지고 있어야 했으나, 굳이 도메인 구입은 하기 싫어서 PoC 용도로 로컬에 SSL 서버를 구동(링크)했다.

 

SSL 서버 구동

위와 같이 노드로 SSL 서버를 구동하고 실제 테스트 해봤다.

 

공격자 서버로 탈취되는 accessToken과 refreshToken

탈취된 accessToken과 refreshToken

위와 같이 accessToken과 refreshToken이 탈취되는 것을 볼 수 있었다.

 

노드 서버에서 실제 로그인 URL로 302 리다이렉트까지 시킨다면 로그인까지 됐으니 별다른 이상함을 못느낀 사용자 입장에서는 속을 수 밖에 없다.