2007년 05월 16일

openid 취약점

title; OpenID와 단일사용자 로그인(Single sign on) 두번째 이야기
link; http://coolengineer.com/421
주의: 본 글을 다시 스크랩하실 경우, 원본 경로와 본 주의 문장을 포함해야합니다.

summary; Mr. Choi posted about an OpenID attack. In the OpenID specification, 'return_to' should be included in 'trust_root'. When 'trust_root' has a redirect page, however, OpenID provider shows a user the 'trust_root' not OpenID consumer. For example, if 'trust_root' is '*.yahoo.com' and 'return_to' is 'rds.yahoo.com/*-evil.com', the user sees '*.yahoo.com' not  'evil.com' in the OpenID provider. In my opinion, OpenID spec should add following sentence. The OpenID provider have to check the 'trust_root' includes consumer's request url.

최호진님께서 OpenID의 취약점(?)을 포스팅하셨습니다. OpenID 스펙에서 'return_to' 주소는 'trust_root'로부터 만들어져야 한다는 내용이 있는데, 해당 'trust_root'에서 redirect하는 페이지가 있을 경우에 문제가 생길 수 있습니다. 아래 웹페이지는 제 pc에 설치된 OpenID Consumer이지만, 사용자에게는 yahoo.com인 것처럼 속일 수 있는 것입니다. 대단히 좋은 아이디어입니다. 짝짝~


조금 더 자세히 말하자면 다음과 같습니다.

...최종적으로 신뢰한 사이트를 돌려 받을 주소(return_to)는 반드시 trust_root로 부터 만들어져야하는 것입니다. 예를 들어,
trust_root=http://www.me2day.net&return_to=http://myservice.org/openid/finish
와 같은 방법으로 앞뒤를 다르게 서비스를 개설할 수 없다는 것입니다.

서문이 너무 길었군요. 다시 처음에 언급한 야후를 이용하여 송신지를 숨기는 스패머들 얘기를 꺼내 보겠습니다. 야후에서 검색을 하고 난 결과 목록에서 원하는 링크를 누르면, 항상 다시 야후로 간다음 목적지로 리다이렉트 됩니다. 편의상 이것을 YR-Hack(Yahoo redirection hack) 이라고 합시다. 아마도, 이 YR핵은 통계를 내거나 클릭 기반의 데이터를 쌓아서 다음 결과에 반영하려고 그런것인지는 잘 모르겠습니다만, 다음과 같은 테스트를 해볼 수 있습니다.
http://rds.yahoo.com/*-http://coolengineer.com/
위와 같이 야후를 이용하여 제 홈에 오는 방법이 가능합니다. 아차!

그럼 신뢰하는 root url을 rds.yahoo.com 혹은 *.yahoo.com 으로 한다면, 야후로 승인받고, 제 홈에 올 수 있다는 얘기 아닙니까. 예를 들면,
trust_root=http://*.yahoo.com/&return_to=http://rds.yahoo.com/*-http://myservice.org/openid/finish
와 같은 형식으로 하면, trust domain을 yahoo로 하고 return_to 에 씌여지는 url이 정상적으로 동작하는 것이라면, 그 앞에 http://rds.yahoo.com/*- 을 붙여주면, myservice.org 서비스에 로그인이 가능하게 됩니다.

위의 그림에서 '승인'을 선택하면 다음과 같은 메시지가 OpenID Consumer에게 돌아옵니다.

http://127.0.0.1:8001/process?janrain_nonce=2007-05-16T04%3A29%3A05ZPRd9Bv&openid.sreg.nickname=asdfasdfasdf&openid.sig=T0iu9SoXr0Xs%2BaGGhn3%2BwkEDZGI%3D&openid.mode=id_res&openid.return_to=http%3A%2F%2Frds.yahoo.com%2F%2A-http%3A%2F%2F127.0.0.1%3A8001%2Fprocess%3Fjanrain_nonce%3D2007-05-16T04%253A29%253A05ZPRd9Bv&openid.sreg.fullname=ayo&openid.sreg.email=ayo%40etri.re.kr&openid.identity=http%3A%2F%2Fayo.myid.net%2F&openid.signed=identity%2Creturn_to%2Cmode%2Csreg.nickname%2Csreg.fullname%2Csreg.email&openid.assoc_handle=%7BHMAC-SHA1%7D%7B464a882a%7D%7BjTtnjg%3D%3D%7D

이건 스펙상으로 쉽게 해결할 수 있는 문제가 아닌 것 같네요..

기존에 trust_root와 return_to를 비교하는 것만으로는 이 문제를 해결할 수 없습니다. 

1. OpenID 프로바이더가 consumer의 url과 trust_root를 비교하는 절차를 추가한다면 이 문제를 해결할 수 있습니다.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

by S_H_Kim | 2007/05/16 13:47 | CardSpace | 트랙백 | 핑백(1) | 덧글(2)

Linked at Korean Identity .. at 2007/07/11 10:08

... 건 맞지만 다른 제품들이 OpenID의 네임밸류를 이용한다는 느낌이 많이 듭니다. 이에 대해 어떻게 생각하고 계신가요?3. 예전에 OpenID 취약점(http://ayo79.egloos.com/3175289)이라는 제목으로 글을 올린적이 있습니다. trust_root와 관련된 문제에 대해 OpenID 커뮤니티에서 논의된 적이 있나요? 논의된 적이 있다면, ... more

Commented by Kay at 2007/06/07 22:06
흥미로운 발견입니다. 다만, 실제 사용시의 컨텍스트를 좀더 보충한다면, 어떨까요.

1위의 사이트 승인이 뜨기전에 사용자가 방문중이던 사이트가 무엇인가에 따라, 문제의 해석이 좀 달라집니다. 우선, 야후에서 사용하다가, 야후에서 오픈아이디 인증요청을 했다면, 사용자는 당연히 야후를 '믿고' 위의 승인을 한것인데, 인증사실을 엉뚱한 사이트로 넘겼다면, 야후가 사용자의 신뢰를 저버린 것이 됩니다.
그게 아니라, 최종적으로 redirection 을 받는 사이트에서, 오픈아이디 요청을 위와같이 올렸다면 사용자는 '갑자기 웬 야후?' 할 것입니다.
즉, 실제로 가능한 사이트의 예를 보여주신다면 좀더 피부에 와 닿을 것 같습니다.
Commented by S_H_Kim at 2007/06/11 13:30
/Kay님, 제 3의 사이트라도 'Yahoo와 협력하여 서비스를 제공하고 있습니다' 라는 식의 구문이 들어있다면 충분히 혹할 수 있다고 생각합니다. 처음에는 피싱을 의심하겠지만, OpenID 서버에서도 'Yahoo'를 신뢰하겠냐는 메시지를 보게 된다면 허락하겠죠.
최호진님께서 해당 내용을 OpenID 커뮤니티에서 보셨다고 말씀하셨으니, OpenID 커뮤니티에서 관련 내용을 언급하고 있는지 찾아보고 좀 더 아이디어를 보강해 보겠습니다.
※ 이 포스트는 더 이상 덧글을 남길 수 없습니다.

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