[영어포럼-] Sign in with Apple - authentication bypass

Sign in with Apple - authentication bypass

https://sector7.computest.nl/post/2020-08-sign-in-with-apple/

Sign in with Apple - authentication bypass

 

1

Last year Apple launched Sign in with Apple, which allows you to sigin in to services using your Apple ID. We identified a critical vulnerability in the service from Apple, which allowed an attacker to obtain authentication tokens which could be used to access a users iCloud account.

단어

뜻

 

2

A couple of weeks ago we found a vulnerability that could be used to gain unauthorized access to an iCloud account, by abusing a new feature allowing TouchID to log in to websites.

단어

뜻

 

3

In iOS 13 and macOS 10.15, Apple added the possibility to sign in on Apple’s own sites using TouchID/FaceID in Safari on devices which include the required biometric hardware.

단어

뜻

 

 

4

When you visit any page with a login form for an Apple-account, a prompt is shown to authenticate using TouchID instead. If you authenticate, you’re immediately logged in. This skips the 2-factor authentication step you would normally need to perform when logging in with your password. This makes sense because the process can be considered to already require two factors: your biometrics and the device. You can cancel the prompt to log in normally, for example if you want to use a different AppleID than the one signed in on the phone.

단어

뜻

 

5

We expect that the primary use-case of this feature is not for signing in on iCloud (as it is pretty rare to use icloud.com in Safari on a phone), but we expect that the main motivator was for “Sign in with Apple” on the web, for which this feature works as well. For those sites additional options are shown when creating a new account, for example whether to hide your email address.

단어

뜻

 

 

6

Although all of this works in both macOS and iOS, with TouchID and FaceID and for all sites using AppleID logins, we’ll use iOS, TouchID and https://icloud.com to explain the vulnerability, but keep in mind that the impact is more broad.

단어

뜻

 

7

Logging in on Apple domains happens using OAuth2. On https://icloud.com, this uses the web_message mode. This works as follows when doing a normal login:

1. https://icloud.com embeds an iframe pointing to https://idmsa.apple.com/appleauth/auth/authorize/signin?client_id=d39ba9916b7251055b22c7f910e2ea796ee65e98b2ddecea8f5dde8d9d1a815d &redirect_uri=https%3A%2F%2Fwww.icloud.com&response_mode=web_message &response_type=code.
2. The user logs in (including steps such as entering a 2FA-token) inside the iframe.
3. If the authentication succeeds, the iframe posts a message back to the parent window with a grant_code for the user using window.parent.postMessage(<token>, "https://icloud.com") in JavaScript.
4. The grant_code is used by the icloud.com page to continue the login process.

단어

뜻

 

 

8

Two of the parameters are very important in the iframe URL: the client_id and redirect_uri. The idmsa.apple.com server keeps track of a list of registered clients and the redirect URIs that are allowed for each client. In the case of the web_message flow, the redirect URI is not used as a real redirect, but instead it is used as the required page origin of the posted message with the grant code (the second argument for postMessage).

단어

뜻

 

9

For all OAuth2 modes, it is very important that the authentication server validates the redirect URI correctly. If it does not do that, then the user’s grant_code could be sent to a malicious webpage instead. When logging in on the website, idmsa.apple.com performs that check correctly: changing the redirect_uri to anything else results in an error page.

단어

뜻

 

 

10

When the user authenticates using TouchID, the iframe is handled differently, but the outer page remains the same. When Safari detects a new page with a URL matching the example URL above, it does not download the page, but it invokes the process AKAppSSOExtension instead. This process communicates with the AuthKit daemon (akd) to handle the biometric authentication and to retrieve a grant_code. If the user successfully authenticates then Safari injects a fake response to the pending iframe request which posts the message back, in the same way that the normal page would do if the authentication had succeeded. akd communicates with an API on gsa.apple.com, to which it sends the details of the request and from which it receives a grant_code.

사용자가 TouchID를 사용하여 인증하면 iframe은 다르게 처리되지만 외부 페이지는 동일하게 유지된다. Safari가 윗쪽의 예시 URL과 일치하는 URL으로 새로운 페이지를 발견하면, 페이지는 다운로드되지 않고 AKAppSSOExtension 프로세스를 대신 실행한다. 이 프로세스는 AuthKit 데몬 (akd) 와 통신하여 생체 인증을 처리하고 grant_code를 가져온다. 사용자가 성공적으로 인증하면 Safari는 일반 페이지가 인증에 성공했을 때와 같은 방식으로 메시지를 다시 전송하는 남아있는 iframe 요청에 가짜 응답을 주입한다. akd 는 gsa.apple.com의 API와 요청에 대한 세부사항을 전송하고 grant_code를 수신하는 통신을 한다.

invoke

빌다, 축원하다, 발동하다

biometric authentication

생체 인증

retrieve

회수, 검색하다, 되찾다, 가져오다

pending

현안의, 남아있는, 계류중인, 미결

 

11

What we found was that the gsa.apple.com API had a bug: even though the client_id and redirect_uri were included in the data submitted to it by akd, it did not check that the redirect URI matches the client ID. Instead, there was only a whitelist applied by AKAppSSOExtension on the domains. All domains ending with apple.com, icloud.com and icloud.com.cn were allowed. That may sound secure enough, but keep in mind that apple.com has hundreds (if not thousands) of subdomains. If any of these subdomains can somehow be tricked into running malicious JavaScript then they could be used to trigger the prompt for a login with the iCloud client_id, allowing that script to retrieve the user’s grant code if they authenticate. Then the page can send it back to an attacker which can use it to obtain a session on icloud.com.

우리가 발견한 것은 gsa.apple.com API에 버그가 있었다는 것이었다: client_id와 redirect_uri이 akd에 의해 그것에 전송된 데이터에 포함되었음에도, 그것은 리다이렉트 URL이 클라이언트 ID와 일치한지 확인하지 않았다. 대신, 도메인의 AKAppSSOExtension에 이해 제공된 화이트리스트만 있었다. apple.com, icloud.com, 그리고 icloud.com.cn으로 끝나는 모든 도메인이 허용되었다. 충분히 안전한 것처럼 들리겠지만, apple.com에 수백개의(아니면 수천개의) 서브도메인이 있다는 것을 명심해라. 이런 서브도메인들 중 하나라도 악의적인 JavaScript를 실행하도록 속을 수 있다면, 그것들은 iCloud client_id를 포함한 프롬포트를 트리거하는 데 사용될 수 있고, 스크립트가 사용자가 인증한다면 그 승인 코드를 가져올 수 있다. 그런 다음 페이지는 icloud.com 세션을 얻는 데 사용할 수 있는 그것을 공격자에게 다시 보낼 수 있다.

grant

부여하다, 주다, 보조금, 허가하다, 승인하다

 

12

Some examples of how that could happen:

• A cross-site scripting vulnerability on any subdomain. These are found quite regularly, https://support.apple.com/en-us/HT201536 lists at least 30 candidates from 2019, and that just covers the domains that are important enough to investigate.
• A dangling subdomain that can be taken over by an attacker. While we are not aware of any instances of this happening to Apple, recently someone found 670 subdomains of microsoft.com available for takeover: https://nakedsecurity.sophos.com/2020/03/06/researcher-finds-670-microsoft-subdomains-vulnerable-to-takeover/
• A user visiting a page on any subdomain over HTTP. The important subdomains will have a HSTS header, but many will not. The domain apple.com is not HSTS preloaded with includeSubdomains.

어떻게 발생하는지에 대한 몇 가지 예시:

• 크로스 사이트 스크립팅 취약점이 있다. 이것들은 꽤 정기적으로 방생하며, https://support.apple.com/en-us/HT201536 은 2019년부터 최소 30개의 후보들을 나열하고, 이는 조사하기에 충분히 중요한 영역을 포함하고 있다.
• 매달린 서브도메인은 공격자에 의해 탈취될 수 있다. 애플에게 일어나는 이 일의 어떤 사례도 인지하지 못하는 동안, 최근 누군가 탈취할 수 있는 670개의 microsoft.com 서브도메인을 을 발견했다:  https://security.sophos.com/2020/03/06/researcher-finds-670-microsoft-subdomains-vulnerable-to-takeover/
• 서브도메인의 페이지에 HTTP를 통해 방문하는 사용자. 중요한 서브도메인은 HSTS 헤더를 갖지만, 대부분은 그렇지 않다. apple.com 도메인은 includeSubdomains로 사전로드되지 않는 HSTS이다.

candidate

후보자, 지원자

domain

영토, 분야, 영역, 범위

investigate

조사하다, 살피다

dangle

매달리다, 매달다, 대롱거림

be aware of

인지하다, 깨닫다, 알아차리다

instance

예, 사례

HSTS

(HTTP Strict Transport Security)는 HTTP 대신 HTTPS만을 사용하여 통신해야 한다고 웹사이트가 브라우저에 알리는 보안 기능

 

13

The first two require the attacker to trick users into visiting the malicious page. The third requires that the attacker has access to the user’s local network. While such an attack is in general harder, it does allow a very interesting example: captive.apple.com. When an Apple device connects to a wifi-network, it will try to access http://captive.apple.com/hotspot-detect.html. If the response does not match the usual response, then the system assumes there is a captive portal where the user will need to do something first. To allow the user to do that, the response page is opened and shown. Usually, this redirects the user to another page where they need to login, accept terms and conditions, pay, etc. However, it does not need to do that. Instead, the page could embed JavaScript which triggers the TouchID login, which will be allowed as it is on an apple.com subdomain. If the user authenticates, then the malicious JavaScript receives the user’s grant_code.

처음 두 개는 공격자가 사용자를 악의적 페이지에 방문하도록 속이는 것이 필요하다. 세 번째는 공격자가 사용자의 로컬 네트워크에 접근하는 것이 필요하다. 이런 공격이 일반적으로 어렵지만 아주 흥미로운 사례를 허용한다: captive.apple.com. Apple 기기가 와이파이 네트워크에 연결되었을 때, http://captive.apple.com/hotspot-detect.html 에 접속하려고 시도할 것이다. 만약 응답이 일반적인 응답과 일치하지 않는다면 시스템은 사용자가 무언가 먼저 해야 하는 captive portal이 있다고 추측한다. 사용자가 그것을 할 수 있도록 응답 페이지가 열려 표시된다. 일반적으로 사용자를 로그인, 약관 동의, 지불 등을 해야 하는 페이지로 리다이렉트한다. 하지만 그렇게 할 필요는 없다. 대신 페이지는 apple.com 서브도메인이라 허용되는 TouchID 로그인을 트리거하는 JavaScript를 내장할 수 있다. 사용자가 인증하면, 악성 JavaScript가 사용자의 grant_code를 받는다.

Captive Portal

wifi를 이용하기 위해 일종의 사용자에 대한 인증을 수행하는 시스템을 말하며, CS에서는 AAA(authentication, authorization and accounting) 이라 불린다.

terms and conditions

약관

 

14

The page could include all sorts of content to make the user more likely to authenticate, for example by making the page look like it is part of iOS itself or a “Sign in with Apple” button. “Sign in with Apple” is still pretty new, so user’s might not notice that the prompt is slightly different than usual. Besides, many users will probably automatically authenticate when they see a TouchID prompt as those are almost always about them authenticating to the phone, the fact that users should also determine if they want to authenticate to the page which opened the prompt is not made obvious.

페이지는 사용자가 인증할 가능성이 더 높은 모든 종류의 컨텐츠를 포함할 수 있고, 예를 들면 iOS의 일부이거나 "Apple으로 로그인" 버튼같이 보이게 만들어진 페이지가 있다. "Apple으로 로그인"은 아직 새로워서 사용자는 명령이 평소와는 약간 다르다는 것을 알아채지 못할 것이다. 게다가, 많은 사용자들은 TouchID 명령을 보았을 때 거의 항상 폰에 인증하는 것에 관한 것이므로 자동적으로 인증할 것이고, 그들이 프롬프트를 연 페이지에 인증하고싶다고 결정 해야 하는 사실은 명백하지 않다.

 

15

By setting up a fake hotspot in a location where users expect to receive a captive portal (for example at an airport, hotel or train station), it would have been possible to gain access to a significant number of iCloud accounts, which would have allowed access to backups of pictures, location of the phone, files and much more. As I mentioned, this also bypasses the normal 2FA approve + 6-digit code step.

사용자가 캡티드 포털을 받을 거라 예상되는 위치에 (예를 들면 공항, 호텔, 또는 기차역) 가짜 핫스팟을 설치함으로써 상당한 수의 iCloud 계정에 엑세스할 수 있었을 것이고, 이는 사진, 폰의 위치, 파일 등의 백업에 엑세스하는 것을 가능케 했을 것이다. 언급했듯이, 이는 일반적인 2FA 승인 + 6자리 숫자 코드 단계를 우회한다.

 

16

We reported this vulnerability to Apple, and they fixed it the same day they triaged it. The gsa.apple.com API now correctly checks that the redirect_uri matches the client_id. Therefore, this could be fixed entirely server-side.

우리는 이 취약점을 Apple에 보고했고, 그들은 그것을 분류한 당일 수정했다. gsa.apple.com API는 이제 redirect_uri와 client_id가 일치하는지 제대로 확인한다. 따라서, 이는 서버측에서 완전히 수정될 수 있었다.

 

triage

자원의 선별적 분배, 부상한 정도에 따른 우선 순위의 구분

 

17

It makes a lot of sense to us how this vulnerability could have been missed: people testing this will probably have focused on using untrusted domains for the redirect_uri. For example, sometimes it works to use https://www.icloud.com.attacker.com or https://attacker.com/https://www.icloud.com. In this case those both fail, however, by trying just those you would miss the ability to use a malicious subdomain.

어떻게 이 취약점이 놓쳐졌는지는 매우 타당하다: 이를 테스트하는 사람들은 redirect_uri에 대해 신뢰할 수 없는 도메인을 사용하는 데 초점을 맞췄을 것이다. 예를 들면, https://www.icloud.com.attacker.com 이나 https://attacker.com/https://www.icloud.com 을 사용하는 것이 가능하다. 하지만 이 경우 모두 악의적인 서브도메인을 사용할 능력이 없어 실패한다.

 

18

The video below illustrates the vulnerability.

하단의 영상은 취약점을 설명한다.

 

 

Words

invoke

빌다, 축원하다, 발동하다

biometric authentication

생체 인증

grant

부여하다, 주다, 보조금, 허가하다, 승인하다

candidate

후보자, 지원자

Captive Portal

wifi를 이용하기 위해 일종의 사용자에 대한 인증을 수행하는 시스템을 말하며, CS에서는 AAA(authentication, authorization and accounting) 이라 불린다.

terms and conditions

약관

triage

자원의 선별적 분배, 부상한 정도에 따른 우선 순위의 구분