시낵에서 우리는 정말 큰 취약점을 즐길 수,웹 여부,모바일,호스트 또는 완전히 터무니 장치 및 시스템(위성 해킹 사람?). 그러나 우리는 항상 우리와 우리의 고객을 위해 만든 위대한 연구 결과를 기밀로 유지합니다. 완전한 타협에 이르게 수백만 명의 사용자와 시스템의 취약점:이 시낵 고객의 큰 불신에 대한 게시물되지 않습니다 동안 그래서,그것은 우리가 매주 또는 때로는 매일 볼 일의 정확한 유형을 포함 시스템 보안.

나는 최근에 마이크로 소프트의 취약점을 발견 Live.com 당신이 어떤 마이크로 소프트 서비스와 계정이있는 경우,아마 당신을 영향을 것,인증 시스템. 이 게시물은 마이크로 소프트가 문제를 패치 것을 이제 취약점의 전체 세부 사항을 설명합니다.

소개

컴퓨터 보안에 대한 일반인의 이해는 항상 상당히 제한적이었습니다. 하루에 누군가가 당신이 컴퓨터 보안에 관여했다고 들었 으면 표준 질문은”내 핫메일을 해킹 할 수 있습니까?”또는 더 자주”내 친구의 핫메일을 해킹 할 수 있습니까?”입니다. 나는 다시 하루에 사람들이 여전히 야후 메일을 사용하고 마이크로 소프트는 핫메일을 취득 아직 있다고 가정,하지만 너무 멀리 다시 조금! 필연적으로 당신은 그 사람이 그 사람의 암호 재설정 질문을 추측하거나 서브 7 을 설치할 것을 제안 할 것입니다. 실제로 핫메일을 해킹하는 것은 완전히 불법은 말할 것도없고,너무 어려울 수밖에 없었다.

정보 보안 세계는 지난 몇 년 동안 많이 바뀌었고,마이크로 소프트는 이제 보안 연구원들이”핫메일 해킹”을 시도하도록 완전히 권장합니다. 물론 핫메일은 전망으로 전환되었습니다.닷컴,요즘 모두가 당신이 자신의 페이스 북을 해킹 할 수 있는지 알고 싶어하지만,그 점 옆에 있습니다..

마이크로소프트 온라인 서비스 현상금 프로그램은 최근에 기본적으로 이 도메인의 각각에서 접대되는 로그인 체계인 표적으로”마이크로소프트 계정”를 포함하기 위하여 새롭게 했습니다:
–login.windows.net
–login.microsoftonline.com
–login.live.com

위의 목록에서,login.live.com 인증하려고 할 경우 통과할 인증 시스템입니까 Outlook.com 그리고 다른 마이크로 소프트 서비스의 거대한 숫자. 나는 어떤 문제를 발견 할 수 있는지 확인하기 위해 먼저 검토하기로 결정했다. 예상대로,로그인을 처리하는 데 사용되는 다양한 인터페이스가 잘 강화 된 것으로 나타났습니다. 예를 들어 일부 지역에서는 암호가 전송 전에 공개 키로 암호화됩니다.

몇 시간 동안 테스트 한 후,내가보고 한 몇 가지 사소한 문제를 발견했지만 실제로는 아무것도 없습니다. 웹 응용 프로그램을 테스트 할 때 나는 종종 가장 일반적인 워크 플로 또한 가장 안전한 것을 발견,그래서 나는 사용자가 인증 할 수있는 다른 방법을 조사하기 위해 밖으로 분기 live.com 체계. 거의 년 전에 나는 또한 마이크로 소프트 온라인 서비스 현상금 대상이었다 불평에 여러 오우트의 취약점을 발견했다,그래서 내가 다음에 보였다 곳이다 live.com.이것은 흥미로운 발견이 시작되는 곳입니다!

취약점 배경

취약점이 발견되기 전에 잘못된 보안 시스템에 대한 간략한 개요가 필요합니다.:

위키백과는”자원 소유자를 대신하여 서버 자원에 대한 클라이언트 애플리케이션에’보안 위임된 액세스’를 제공한다”고 말한다. 위키 백과는 또한 좋은 웃음을 위해 읽을 가치가 진화와 보안에 대한 몇 가지 통렬한 의견을 가지고있다. 현실적으로,사용자가 제 3 자에게 자신의 계정의 액세스 권한 중 일부 또는 전부에 대한 액세스 권한을 부여 할 수 있습니다. 나는 위키 백과에 큰 하나를 찾을 수 없기 때문에 나는 이것을 설명하기 위해 미스 페인트 드로잉을했다.2042>

위의 이미지에서 볼 수 있듯이 사용자가 클라이언트 앱에 자신의 계정에 대한 액세스 권한을 부여하도록 권한을 부여한 서버가 있습니다. 이 장면 뒤에서 처리하는 메커니즘은 여러 가지 방법으로 구축 할 수 있습니다. 이를 구축하는 한 가지 방법은 인증 서버가 클라이언트에 직접 액세스 키를 제공하는”암시 적”인증 흐름입니다. 또 다른 인기있는 방법은 인증 서버가 클라이언트 시스템이 취하는 인증 코드를 제공 한 다음 클라이언트 비밀 값을 사용하여 액세스 키를 교환하는”인증 코드”절차를 사용하는 것입니다. 마이크로 소프트는 그들이 이러한 메커니즘을 구현 한 방법의 자신의 사용에 대한 좋은 설명이 live.com 여기:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

“인증 코드”흐름을 위해 만든 그래픽은 다음과 같습니다:

그런 이미지는 그 과정을 이해하기에 좋지만,펜 테스터로서의 나에게는 일이 잘못 될 수있는 많은 기회와 장소를 보여줍니다. 그래서 그 배경으로,발견 된 것에!

무엇이 잘못 될 수 있습니까?

위의 섹션에서 언급했듯이 뭔가 잘못 될 수있는 곳이 많이 있습니다. 사용자가 응용 프로그램 액세스 권한을 부여하도록 선택할 수 있습니다. 이것은 일반적으로 다음과 같은 프롬프트를 통해 수행됩니다:

일반적으로 사용자는 한 번이 프롬프트를 수락해야합니다,하지만 그들은 그것을 받아 들일 때까지,그 응용 프로그램은 자신의 계정에 액세스 할 수 없습니다(일반 사용자가 액세스 할 수 웨스의 악한 응용 프로그램을 허용할지 여부는 아마도 다른 질문입니다!).

공격자로 생각하면 사용자를 대신하여 요청을 수락 할 수 있다면 확실히 좋을 것입니다. 불행히도 나를 위해,”엑스 프레임 옵션”헤더는”거부”로 설정되었습니다(엑스 프레임 옵션 설정은이 현상금에 대해서도 범위를 벗어났습니다). 그래서 클릭 재키 아웃 동안,나는 요청 자체가 어떻게 작동했는지에 대한 더 나은 이해를 얻기로 결정했다. 사용자가”예”를 클릭하면 다음 요청이 서버에 게시됩니다(일부 지루한 헤더 포함):

위의 경로에는 생성된 토큰이 포함되어 있지만 테스트 결과 요청이 성공하려면 필요하지 않은 것으로 나타났습니다. 다음 링크에 대한 게시물도 잘 작동합니다:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26 점등%3 점등.이 문제를 해결하려면 다음을 수행하십시오.exfiltrated.com 이 문제를 해결하는 방법은 다음과 같습니다.3735>범위=.기본

쿠키에 유효한 세션 토큰을 포함 하는 데 필요한 요청과 함께 전송 됩니다. 이 쿠키 값은 사용자에게 권한을 요청하는 페이지가 표시되기 전에 채워집니다. 이것은 사용자가 궁극적으로”예”를 클릭했는지 여부에 관계없이 발생합니다.하지만 일부 자바 스크립트 코드에 의해 설정되므로,이 프로세스를 공격하는 경우 사용자가 어느 시점에서 해당 페이지를로드하도록 강요해야합니다.

당신이 따라오고 있다면,당신은 이제”좋아,그럼 포스트 요청 자체와 그 카나리아 가치는 어떨까요?”. 나는 다른 모든 매개 변수 및 통신 흐름을 먼저 조사했는데,”카나리아”라고 표시된 값이 게시물 요청과 함께 전송되는 것을 보는 것이 거의 확실하다는 것을 의미합니다. 그러나 보안 테스트의 요점은 가정이 실제로 올바른지 확인하는 것입니다. 그래서 게시물 요청을 수정하고 카나리아 값을”해킹”으로 변경했습니다. 500 오류로 리디렉션하는 대신 서버는 긍정적 인 응답을 다시 보냈습니다!이 취약점을 악용할 수 있다는 것을 확실히 알고 있었습니다. 거의 모든 뇌척수액 공격과 마찬가지로,유일한 전제 조건은 피해자가 로그인되어 있고 쿠키에 유효한 세션 토큰이 있다는 것입니다. 다른 많은 웹 취약점과는 달리,이 취약점의 영향은 영향을 받는 취약점 함수에 전적으로 의존합니다. 따라서 다음 단계는 이 취약점의 영향을 적절하게 시연하기 위한 코드를 작성하는 것입니다.

일반 인증 흐름에서 사용자가 액세스 권한을 부여한 후 서버는 액세스 코드를 사용자에게 반환해야 합니다. 사용자는 이를 클라이언트 응용 프로그램에 전달한 다음 부여된 사용 권한을 사용할 수 있습니다. 에이 live.com 클라이언트 응용 프로그램은 가능한 다양한 권한을 요청할 수 있습니다. 난 그냥 그런 사용자의 연락처 또는 뭔가를 덤핑 고려,하지만 왜 지금 핫메일 해킹의 목표에 희생? 그런 다음 필요한 권한은 다음과 같습니다.100000000000오프라인 모두 필요한 것은 아니었지만,나는 그것이 부여 될 것을 보여주기 위해 그것을 던졌다.

필요한 권한을 선택한 상태에서 사용자의 이메일 계정에 대한 액세스 권한을 얻기 위해 4 단계가 있습니다:

1)우리는 위의 권한을 사용하여 클라이언트 응용 프로그램에 대한 인증 요청을해야합니다. 서버는 사용자에게 수락 또는 거부하라는 메시지를 표시합니다.
2)사용자가 이러한 권한에 대한 요청을 수락하면 서버가 수행하도록 지시하는 리디렉션에”#액세스 _토큰=<토큰>”매개 변수를 추가합니다.
3)우리의 서버 측 스크립트는 그 값에 액세스 할 필요가 있기 때문에,우리는 브라우저 링크 필드에서 토큰을 가지고 우리의 서버에 전달하는 간단한 페이지를 확인해야합니다.
4)마지막으로 우리는 그 토큰을 가지고,아이 맵에 로그인하는 데 사용하는 일부 스크립트 서버 측이 필요합니다. 로그인할 수 없습니다. 이를 위해 몇 가지 샘플 라이브러리가 있으며 전체 프로세스가 이 페이지에 설명되어 있습니다:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

그 워크 플로우는 사용자가 우리에게 권한을 부여하기로 선택 가정 잘 작동합니다. 이제 워크플로를 수정하여 대신 워크플로를 포함해야 합니다. 앞서 언급 한 바와 같이,live.com 인증 서버는 쿠키에 세션 토큰을 예상합니다. 우리는 먼저 유효성에 사용자를 전송하여 채워 있는지 확인 할 수 있습니다. 이 요청을 실행하면 새로 채워진 쿠키 값을 사용할 수 있습니다. 이제 1 단계를 대체하고 서버가 즉시 2 단계로 이동하도록 할 수 있습니다.

데모 및 영향

마이크로 소프트는 지금이 문제를 해결하지만,여기에 행동을 보여주는 빠른 동영상입니다.

비디오에서 볼 수 있듯이,정말 필요한 모든 악의적 인 웹 페이지를 방문하는 피해자를 얻는 것입니다. 데모는 비열한 및 웹 사이트의 백그라운드에서 실행하도록 설계,또는 일부 악성 배너 광고의 일환으로,그러나 그것은 확실히 그런 식으로 만들 수 있었다되지 않았습니다.

이것을 표적 공격으로 사용하는 것은 확실히 높은 영향을 미치지 만,이것은 또한 웜으로 변하는 완벽한 유형의 취약점입니다. 웜은 사용자의 모든 연락처(또는 적어도 핫메일을 사용하는 사람)를 쉽게 이메일로 보낼 수 있습니다.Outlook.com 바이러스 스타일을 유혹하고 링크를 클릭하는 모든 사용자에게 퍼집니다.

최종 생각과 타임라인

이 취약점을 찾아내고 다양한 취약점을 파헤치는 데 상당한 노력을 기울였다.live.com 에피. 그러나 모든 것을 되돌아 보면,이것은 단지 고전적인 취약점입니다. 그것에 대해 놀라운 유일한 것은 궁극적으로 모든 사용자의 계정을 인수하는 데 사용할 수있는 중요한 인증 시스템에 있다는 것입니다.

외부 테스터로서 나는이 취약점이 얼마나 오래 존재했는지,또는 누군가가 그것을 악용하려고 시도했는지 전혀 모른다. 동시에,공격자가 당신을 상대로 그들을 활용하기 전에 외부 테스터가 회사에 취약점을 제출 할 수 있도록의 가치를 확실히 보여이 같은 연구 결과입니다. 이 보안에 올 때 마이크로 소프트는 훨씬 앞서 대부분의 기업이다,아직이 같은 문제에 여전히 성공적이다. 시낵의 경험은 취약점이 외부 연구자의 큰 그룹이 시스템을 테스트 할 때 겉으로는 잘 보안 시스템에서도 발견되어왔다. 즉 본질적으로 시낵이 작동하는 전제,그리고 점점 더 많은 기업들이 자신의 현상금 프로그램을 제공하는 이유입니다(나는 물론,자신을 실행을 통해 시낵의 프로그램을 추천 할 것입니다!).

아래의 타임 라인에서 볼 수 있듯이,마이크로 소프트는 볼 좋았어요 밖으로이 문제에 대한 수정을 얻기에 반응했다.

타임라인:
2015 년 8 월 23 일:취약점 발견
2015 년 8 월 25 일:마이크로소프트에 보고된 취약점
2015 년 8 월 31 일:마이크로소프트 문제점
2015 년 9 월 15 일:마이크로소프트 문제점,문제점$24,000 현상금(이중 현상금 프로모션)