[보안이슈] OAuth Misconfiguration(4) : 취약점 사례(Convert Redirect)

[보안이슈] OAuth Misconfiguration(4)

 

01___Intro

OAuth Misconfiguration으로 발생할 수 있는 취약점 사례에 대해 살펴보기로 하자.

 

02___취약점 사례

01) Convert Redirect

OAuth 2.0 인증 Flow 중 redirect_uri 파라미터 값에 대해 검증이 누락되거나 미흡할 경우 발생하는 취약점이다.

정상적인 Flow 대로라면 사용자(Resource Owner)가 로그인 성공 후 발급받은 Authorization code를 Client 측으로 전달해야합니다. 그러나 아래의 그림과 같은 방법으로 공격자는 사용자(피해자)에게 변조된 Redirect URI를 전송하여 로그인을 유도하게 됩니다. 4번 단계에서 사용자(피해자)가 Redirect URL 값이 변조된 URL로 로그인할 경우, Authorization code 값이 공격자 서버로 전달되어 공격자는 사용자(피해자)의 계정 탈취가 가능해집니다.

위의 공격의 예시로 한가지 경우를 살펴보자.

http://client.co.kr/OAuth/Callback?code=XXXXXXXXXXXXXXXXXXXX 에서 도메인까지만 검증할 경우 http://client.co.kr/logout?returnURL=http%3a%2f%2fattacker.NulLBr4in.com%2fcode%2f 로 변조하게되면 도메인이 동일하여 검증을 우회하고 공격자 서버로 code를 전송합니다.

위의 예시처럼 도메인까지만 검증할 경우, code 값에 Query String이 포함되서 공격자 서버로 전달되거나 HTTP 헤더의 Referer를 참고하여 Authorization code 값을 탈취할 수 있다.

 

02) Convert Redirect 실제사례

https://medium.com/oad-earth/bug-or-feature-github-adventure-001-eae9bea48ae8

Bug or Feature? GitHub Adventure #001

https://www.hahwul.com/2019/06/oauth-chained-bugs-to-leak-oauth-token.html

OAuth 과정에서 발생할 수 있는 재미있는 인증토큰 탈취 취약점(Chained Bugs to Leak Oauth Token) Review

 

Case 1) Github의 사례

GitHub의 경우 Redirect URL 파라미터는 선택사항입니다. 이를 기술해주지 않으면 GitHub는 OAuth 설정에서 구성된 콜백 URL로 리다이렉션하게 됩니다. 제공된 경우 리다이렉션 URL의 호스트와 콜백 URL가 정확히 일치하는지 확인하는 로직이 구현되어 있습니다. Redirect URL은 콜백 URL의 하위 디렉토리를 참조해야만 합니다.

Redirect URL에 대한 검증에 대해 조금 더 유의할 필요가 있습니다. Redirect URL과 콜백 URL은 정확히 일치해야합니다. 그렇지 않을 경우, 해커가 중간자 공격을 통해 Authorization code 값을 탈취할 수 있습니다.

아래의 그림처럼, 하위 도메인에 대한 검증절차가 제대로 이루어지지 않아 이를 악용하여 임의의 도메인으로 Redirect URL 변조가 가능한 상태입니다.

 

Case 2) 우버의 사례

우버의 로그인 창에서 OAuth 인증을 통한 Facebook 로그인을 선택합니다.

 

로그인 시 패킷을 확인해보면 아래와 같은 패킷이 전송됨을 알 수 있습니다.

https://www.facebook.com/v2.9/dialog/oauth?app_id=277064115737714&channel_url=https%3A%2F%2Fstaticxx.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D44%23cb%3Df5be1cf~~~&fallback_redirect_url=https://login.uber.com~~~

 

우버와 페이스북을 연동한 사용자가 로그인했을 때 oauth 요청으로 인증정보를 받아오는데 이 과정에서 redirect url이 지정됩니다. (redirect url이 지정되는건 당연한거고, Oauth쪽 플로우 한번 쭉 보시면 아하 하실겁니다.)

아무튼 이 redirect url 중 특정 값은 Oauth 성공 시 페북쪽 서버가 우버쪽 서버로 인증정보를 찔러줄 때 사용하는 주소일텐데요. 보통 Oauth idp 측(현재 기준 페북)에선 개발자센터 등을 통해서 허용된 URL로만 통신할 수 있게 지정해서 사용합니다.

우버의 경우 https://auth.uber.com/login?* 까지가 지정된 URL이라고 합니다.
이러다보니 사용자가 https://auth.uber.com/login?next_url= 을 통해서 redirect url을 넘겨주는 경우 인증정보가 다른 우버 서버로 넘어가게 되는데 공격자는 여기서 한번 더 머리를 쓴 것 같습니다.

아까 위에서 이야기드렸듯이 https://login.uber.com/logout 주소는 Referer 헤더를 참조해서 Redirect 하다보니 공격자 서버상에서 로그아웃 페이지가 호출되면 공격자 사이트로 Redirect 되게 됩니다. 물론 이 구조도 보편적으로 많이 쓰이는 구조다보니, 이거 자체만으로 문제라고 하기엔 어렵습니다.
아무튼 Oauth 요청은 서버 to 서버로 요청이 발생하는데 결국 공격자 사이트에서 페북 Oauth 주소를 호출했을 때 Oauth 처리 후 redirect url은 logout 페이지를 바라보게 되고, Referer를 참조해서 공격자 사이트로 인증정보를 전송하게 되는 것 같습니다.

이를 참조하여 POC를 작성하면 아래와 같습니다.

<a href="https://www.facebook.com/v2.9/dialog/oauth/?~~blahblah~~&redirect_url=https://auth.uber.com/login?next_url=https://login.uber.com/logout">PoC</a>

 

03___Convert Redirect URL 보안방안

정해진 도메인으로만 Redirect URL이 지정되도록 입력 값 검증을 해야한다. 위와 같이 하위 도메인이나, 내부에서 사용되는 Redirect 기능을 통해 이러한 도메인 검증이 우회되지 않도록 주의해야한다.

 

 

Reference :

https://www.hahwul.com/

HAHWUL