# Oh-auth - OAuth를 악용하여 수백만 개의 계정 탈취

> Clean Markdown view of GeekNews topic #11551. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=11551](https://news.hada.io/topic?id=11551)
- GeekNews Markdown: [https://news.hada.io/topic/11551.md](https://news.hada.io/topic/11551.md)
- Type: news
- Author: [kuroneko](https://news.hada.io/@kuroneko)
- Published: 2023-10-27T10:43:22+09:00
- Updated: 2023-10-27T10:43:22+09:00
- Original source: [salt.security](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)
- Points: 20
- Comments: 3

## Topic Body

- Salt Labs는 OAuth 구현의 취약점을 통해 수억 명이 사용하는 초대형 서비스인 Booking.com, Grammarly, Vidio, Bukalapak과 모바일 프레임워크인 Expo에서 계정 탈취가 가능한 것을 발견함.  
- OAuth는 본질적으로 안전한 프로토콜이지만, 구현 방법에 따라 치명적인 취약점이 생길 수 있음을 알림.  
- Booking.com  
  - Facebook OAuth 구현에서 redirect_uri를 동일 호스트의 다른 경로로 변경할 수 있는 문제가 있음.  
  - booking.com 내부에 base64 형태의 주소를 제공하면 해당 주소로 리다이렉션 되는 Endpoint가 있음.  
  - 이 두 개를 조합하여 OAuth의 토큰이 다른 주소로 연결되도록 조작이 가능.  
  - 웹 버전에서는 로그인 처리 시 redirect_uri를 검증하여 취약점이 없었지만, 모바일 버전에서는 redirect_uri도 조작할 수 있는 문제가 있어 계정 탈취가 가능함.  
  - 즉, 매우 합법적으로 보이는 링크를 사용자가 클릭하고 정상적으로 OAuth를 진행하면 계정이 탈취되는 취약점.  
- Expo  
  - 모바일 프레임워크인 Expo의 내장 OAuth 구현에서 발견된 취약점.  
  - 해당 구현 중 returnUrl에는 `exp://~~` 라는 Expo 앱 전용 링크가 들어가는데, 여기에 `hTTps://~~` 처럼 웹 주소를 넣을 수 있는 문제가 있음.  
    - `https://`는 입력되지 않도록 처리되어 있지만, 대소문자 변경만으로 우회됨.  
  - 이러면 returnUrl 정보를 RU라는 쿠키에 저장하고, OAuth가 완료된 이후에 Expo의 OAuth 서버가 해당 쿠키를 읽어서 리다이렉션 함.  
  - 다만, Expo에서 Facebook으로 넘어가기 전에 `https://~~ 를 신뢰하는 경우...` 라는 경고 문구가 쓰고 이를 사용자가 수락해야 함.  
  - 우회하기 위해서 2개의 링크를 자동으로 여는 방법을 사용.  
    - 첫 번째 링크를 열고 바로 닫아서 RU 쿠키만 설정.  
    - 두 번째 링크는 facebook oauth 링크를 직접 제공하여 RU 경고 메시지 무시.  
  - 이 방법을 통해 Codecademy.com의 계정을 탈취하는 데 성공함.  
  - 취약점은 [CVE-2023-28131](https://nvd.nist.gov/vuln/detail/CVE-2023-28131)를 할당받았으며 Expo 팀은 최초 제보 이후 몇 시간 만에 문제를 수정하였음.  
- Grammarly, Vidio, Bukalapak  
  - 3개 사이트는 모두 동일한 방식을 통해 계정 탈취가 가능함.  
  - 먼저 합법적인 웹 사이트를 만들어 Facebook 로그인 토큰을 수집함.  
  - 이후 Vidio, Bukalapak에는 Facebook이 제공한 (다른 웹 사이트용으로 생성된) 토큰을 제공하면 그대로 로그인이 성공함.  
    - Facebook 토큰의 App ID를 확인하지 않아서 벌어지는 취약점. (토큰 재사용 공격)  
  - Grammarly는 조금 다르게 토큰 대신 코드를 쓰기 때문에 위 취약점이 없었음.  
  - 하지만 코드를 전송하는 API에 `"code"` 대신 `"access_token"`이란 이름으로 토큰을 제공하면 로그인이 되는 것을 확인함.  
  - 따라서 3개 사이트 모두 합법적인 다른 사이트에서 Facebook 연동을 하면 즉시 계정이 탈취당할 수 있었음.  
- OAuth 구현시에는 보안 취약점이 발생할 수 있는 부분을 확인하고, 취약점 예방을 위해 모든 처리 과정에서 섬세하게 검증하는 것이 필요함.

## Comments



### Comment 20200

- Author: ironlung
- Created: 2023-10-28T16:47:25+09:00
- Points: 1

경각심이 드네요. 정말 조심해야겠습니다.

### Comment 20196

- Author: [hidden]
- Created: 2023-10-28T11:41:39+09:00
- Points: 1

[숨김 처리된 댓글입니다]

### Comment 20179

- Author: kuroneko
- Created: 2023-10-27T10:46:31+09:00
- Points: 1

- [Booking.com 사례](https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com)  
- [Expo 사례](https://salt.security/blog/a-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services?)  
- Grammarly, Vidio, Bukalapak 사례 - 위 링크  
- [HN 스레드](https://news.ycombinator.com/item?id=38009291)  
  
생각보다 엄청 대형 사이트들이 취약점을 많이 가지고 있었네요.  
확실히 조심해서 다뤄야 하는 기능 같습니다.  
  
인증 라이브러리를 써야겠다...란 생각도 들지만,  
Expo의 사례를 보면 이것도 자체적으로 검증이 필요하다고 생각이 드네요.