OAuth 취약점 공개. Twitter의 OAuth 서비스 중단

Twitter의 OAuth 서비스 중단 사고

Twitter는 OAuth 기능을 지난 달부터 테스트하고 있었는데, 갑자기 며칠전부터 서비스가 다운되었습니다. 악의적인 서드파티 개발자들의 OAuth API를 남용했기 때문이라고 발표했습니다.[1] Twitter 공식 블로그의 포스팅에 따르면 OAuth 프로토콜에 보안 취약점이 발견되었으며, Twitter는 이 문제가 해결될 때까지 OAuth 사용을 중단하기로 했습니다.[2]

This week, we received word from the folks at OAuth that they were looking closely at a security issue within the protocol. We take security seriously and felt the responsible thing to do was temporarily disable OAuth while this matter was sorted out. Yahoo and others made similar decisions. The developers working on Twitter projects that are in our beta test group felt this disruption the hardest and their patience is extremely appreciated.[2]

권고문

여러가지 억측이 존재했는데[4], 한국시간으로 4/24일 오전에 OAuth 측에서 권고문이 나왔습니다.[5] OAuth의 문제는 공격자가 정상적인 사이트에서 OAuth 토큰을 받아 Authorize해야 하는데, 이 토큰을 일반 사용자가 받아서 대신 Authorize할 수 있다는 것이었습니다. 아래 OAuth 인증 흐름으로 설명하겠습니다.

1. 공격자가 정상적인 Consumer사이트에 접근하여 B단계에서 SP에게 oauth_token을 수신합니다. 편의상 T1이라고 하겠습니다.
2. 공격자는 T1을 C 요청을 하지 않고, 일반 사용자가 C 요청을 대신하도록 링크를 만듭니다.
3. 일반 사용자는 원래 T2라는 oauth_token을 처리해야 하지만, T1 토큰을 들고 SP에게 C 요청을 합니다.
4. SP는 일반 사용자를 인증하고 인가 응답을 Consumer 사이트에 전달합니다. T2를 들고 있는 일반 사용자가 아니라, T1을 들고 있는 공격자의 세션이 대신 인가되는 것입니다.


이 문제의 이유는 A,B 단계가 사용자와 무관하게 진행되고 C단계에서 replay attack이 가능하다는 것입니다. A, E 단계의 사용자가 C, D 단계의 사용자와 다르더라도 프로토콜 상에서 구분하지 못합니다. Don Park이라는 블로거의 포스트에서도 동일한 지적을 했습니다[3]

The first flaw is that parameters of HTTP redirects used in OAuth can be tempered with or replayed...

The second and more serious flaw is that the User talking to the Consumer may *not* be the same User talking to the Service Provider.


OAuth 측의 대응 방안

근본적으로 프로토콜의 문제라서 고치는데 상당한 시간이 소요될 것 같습니다. 프로토콜이 수정되더라도 이를 합의하는 시간이 필요하고, 지금까지 개발된 모든 OAuth 라이브러리와 서비스를 변경하는 시간이 듭니다.

OAuth측은 다음과 같은 문구를 우선 추가할 것을 권고합니다. 아래 문구는 C 단계에서 사용자에게 보여집니다. 근본적인 해결책은 아니죠.

“This website is registered with SERVICE_PROVIDER_DOMAIN_NAME to make authorization requests, but has not been configured to send requests securely. If you grant access but you did not initiate this request at CONSUMER_DOMAIN_NAME, it may be possible for other users of CONSUMER_DOMAIN_NAME to access your data. We recommend you deny access unless you are certain that you initiated this request directly with CONSUMER_DOMAIN_NAME.”

맺음말

Twitter와 OAuth는 이번 사고로 가장 큰 피해를 입었습니다. OAuth는 Authorization을 수행하는 프로토콜과 얼마전까지 웹 환경에서 안전하면서도 프라이버시를 보호하는 방식으로 주목받았습니다. 또한 Twitter는 OAuth를 가장 빠르게 도입하여 활용할 수 있음을 보여주고 있었습니다. 하지만 이번 사고로 Twitter는 해당 서비스를 무기한 중지하였고, OAuth는 프로토콜 수정과 라이브러리 교체라는 수모를 당하게 되었습니다. Twitter 측의 대처는 깔끔했고, OAuth도 지금 문제가 발견된 것이 오히려 다행이라고 생각할 수도 있겠습니다. 하지만 상당히 오랜 기간동안 이 파장은 지속될 것입니다.

레퍼런스
[1] Twitter OAuth “Temporarily Disabled”, Developers Left Hanging
[2] What's The Deal with OAuth?
[3] http://blog.docuverse.com/2009/04/23/on-oauth-vulnerability/
[4] http://news.cnet.com/8301-13577_3-10225103-36.html
[5] http://oauth.net/advisories/2009-1

by S_H_Kim | 2009/04/25 00:38 | 트랙백 | 핑백(1) | 덧글(2)

트랙백 주소 : http://ayo79.egloos.com/tb/4123404
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Linked at Korean Identity .. at 2009/12/31 12:37

... 지붕아래 다락방자주 발행한 밸리 & 대표 글IT (65회) / RWW의 2010년 전망가장 많이 읽힌 글은 OAuth 취약점 공개. Twitter의 OAuth 서비스 중단 입니다.가장 대화가 활발했던 글은 2009년 ID 관리 컨퍼런스 입니다. ( 덧글 5개 )내이글루에 가장 덧글을 많이 쓴 사람은 SK_ ... more

Commented by humbroll at 2009/05/10 20:30
안타깝네요.
트위터쪽에서 oauth를 도입하기까지 상당히 신중했던 것으로 기억하는데,
오픈 인증 프로토콜에 대한 불신의 벽이 좀 더 두꺼워진거 같아서 아쉽습니다.
프로토콜의 복잡도가 약간은 더 높아질 수 있겠네요.^^;
Commented by S_H_Kim at 2009/05/12 00:55
공개되지 않아서 그렇지, 기업들의 인증 프로토콜은 더욱 약할 거에요. 빠른 시일내에 스펙이 업데이트 되길 바랄 뿐이네요. 그렇지 않으면 현재 OAuth를 사용하고 있는 업체들의 혼란이 가중될 것이고, 신규 도입 또한 어려워지겠죠.

참, 스프링노트에 적용된 OAuth는 어떻게 되나요? 권고문에 있는 내용을 준수하시는지, 아니면 잠정 중단하시는지 궁금하네요.

:         :

:

비공개 덧글

◀ 이전 페이지다음 페이지 ▶