Google Cloud Platform 취약점 발견 및 포상금 수령 분석 예시

다음은 정보 보안에 관심이 있었던 우루과이의 17세 고등학생에 대한 이야기입니다. 그는 연구와 연구를 통해 독자적으로 Google Cloud Platform의 취약점을 발견하고 $7,500를 받았습니다. $10,000 상당의 Google 호스트 헤더 유출 취약점). 이 취약점에 대해 자세히 설명하기 전에 독자가 Google Cloud 서비스 및 API 메커니즘의 개념을 숙지하는 것이 좋습니다.

Pilot 개념

Google은 Google Service Management라는 관리 서비스를 운영하며, 이를 통해 Google은 사용자가 만든 다양한 애플리케이션 Google 시스템 및 클라우드 서비스의 내부 및 외부 인터페이스를 관리합니다. Google 서비스 관리에서는 사용자가 클라우드 플랫폼 프로젝트에서 Maps API, Gmail API, Private API 등 개인 인터페이스 서비스를 개별적으로 활성화 및 비활성화할 수 있으며, 인터페이스 구성 파일 제어를 통해 다양한 서비스를 실시간으로 관리할 수 있습니다.

일반적으로 우리는 개발자로서 Google 서비스 관리 서비스를 직접 사용하지 않습니다. 대부분의 대화형 작업은 클라우드 콘솔 Google Cloud Console 또는 명령줄(예: 서비스 활성화/종료) 또는 API 관리 인터페이스를 통해 이루어집니다. Google Cloud Endpoints를 사용하여 이를 완료할 수 있지만 Google Service Management 서비스의 흥미로운 API 인터페이스가 있다는 점을 언급할 가치가 있습니다.

이 API 인터페이스는 위의 서비스 관리 기능을 실현할 수 있을 뿐만 아니라 이 API 인터페이스를 사용하여 Google 서비스의 일부 숨겨진 기능에 액세스할 수 있다는 사실이 Google 공식 문서에 기록되어 있습니다.

이러한 숨겨진 기능은 여러 가지 방법으로 찾을 수 있지만 가장 간단하고 쉬운 방법은 사용자의 Google Cloud Platform 프로젝트에서 Service Management API 인터페이스를 활성화하고 프로젝트 트래픽 필터링 콤보 상자를 활성화하는 것입니다. 단계는 다음과 같습니다.

위의 마지막 그림에는 빨간색 상자로 표시된 숨겨진 메소드를 포함하여 API를 사용하여 기능을 구현하는 다양한 방법이 있습니다. 소위 숨겨진 방법은 Google이 아닌 클라이언트가 액세스를 허용하지 않는 것입니다. Google이 아닌 클라이언트가 액세스를 시도하면 404 오류가 반환됩니다. 매우 흥미로운 점은 이 404 오류가 일반적인 HTML 페이지처럼 "여기에 오류가 있습니다" 프롬프트로 표시되지 않고 JSON 모드에서 제공되어 메소드가 존재하지 않는다는 메시지를 표시한다는 것입니다.

마찬가지로 API 자체에도 숨겨진 메소드가 있는데, 이는 일부 공개 메소드에서 수신된 숨겨진 매개변수이지만 상대적으로 이러한 숨겨진 메소드는 발견하기가 더 어렵습니다.

숨겨진 메소드와 숨겨진 매개변수의 경우 모두 '가시성'이라는 Google 서비스 기능을 사용합니다. 이 기능 기록은 공개 문서에서 쿼리할 수 있지만 Google에서만 내부적으로 사용됩니다.

팁: Google 자체 API의 숨겨진 부분은 다양한 방법으로 발견될 수 있으며, 대부분의 경우 숨겨진 문서도 있습니다. 또한 Google은 이러한 숨겨진 API 기능이 유출되거나 숨겨진 API로 간주하지 않습니다. 문서 보안 취약점이 있습니다. (한번은 Google에 이 내용을 보고한 적이 있습니다.)

그러나 몇 가지 숨겨진 기능도 악용될 수 있다면 보안 취약점으로 간주됩니다. 예를 들어, 제가 1년 전에 발견한 숨겨진 매개변수는 악용에 성공한 후 취약성을 형성했습니다. 5,000달러로. 아직 취약점은 복구 단계에 있기 때문에 현시점에서는 공개하기가 쉽지 않습니다.

사전 분석

위의 지식을 이해한 후 Google의 숨겨진 기능에 액세스하는 방법을 사용해 보았습니다. Google Cloud Console에 액세스할 때 생성된 기능을 주의 깊게 분석하면 된다는 것입니다. 요구.

Google Cloud Console은 여러 공개 및 비공개 Google API, 자체 클라이언트 프로그램, API 키 AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g를 사용하여 클라우드 프로젝트에 대한 정보 액세스를 달성합니다.

Google Cloud Console 클라이언트의 일반적인 요청은 다음과 같습니다.

GET /v1/services?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
Host: servicemanagement.clients6.google.com
Authorization: SAPISIDHASH <sapisidhash>
X-Origin: https://console.cloud.google.com
Cookie: <google></google></sapisidhash>

첫 번째 부분의 의미를 살펴보겠습니다.

"clients6.google.com": "googleapis.com"에 대한 요청입니다. 방법, 쿠키는 google.com의 하위 도메인 이름에만 액세스할 수 있으므로 이 방법이 필요합니다.

"SAPISIDHASH": StackOverflow 포럼에 따르면 "TIMESTAMP_HASH"(timestamp_ha(Hish) 값이며 다른 많은 방법이 있습니다. 이 취약점과 관련이 없는 포럼에서 SAPISIDHASH를 생성하는 방법

"X-Origin": "Origin"이라고도 알려져 있으며 여기 SAPISIDHASH 부분과 클라이언트가 웹 사이트에 액세스하기 위해 신뢰할 수 있는 확인을 수행하는 데 필수적입니다. 헤더 정보,

쿠키: SID, HSID, SSID, APISID, SAPISID 등을 포함합니다. Google 사용자는 이 쿠키 정보를 얻으려면 로그인해야 합니다.

由此看来，要伪造谷歌云端控制台（Google Cloud Console）的请求非常简单，而且由于它是谷歌自身的客户端程序，因此它可以访问到多个Google API，甚至是一些私有Google API的某些内部功能，其中就包括Service Management的API。

谷歌云端控制台（Google Cloud Console）客户端的多个功能之一就是，创建一个从一开始就附加了配置项的服务（一般的客户端通常会忽略 "serviceConfig"参数，因为该参数是隐藏的，而且在创建服务时不产生初始配置操作），其简单的配置请求如下：

POST /v1/services?key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
Host: servicemanagement.clients6.google.com
Authorization: SAPISIDHASH <sapisidhash>
X-Origin: https://console.cloud.google.com
Cookie: <google>
Content-Length: <content-length>
{
  "serviceName": "<service>",
  "producerProjectId": "<project>",
  "serviceConfig": {
    "name": "<service>",
    "producerProjectId": "<project>",
    "configVersion": 3
}</project></service></project></service></content-length></google></sapisidhash>

漏洞分析

通常来说，参数"serviceName"和"serviceConfig.name"必须与指定了两者的请求发生匹配，但在实际的服务创建过程中，当 "configVersion" 变量值被设置为1或2，或者是2147483648至4294967295之间的值时（相当于后端发生了一个整型溢出），这种匹配的受限条件并不会被检查实行，因此，任意用户都可以使用真实的名称（如“the-expanse.appspot.com”）来创建服务，只需在其配置文件中声明它其中还存在另一个不同的服务，如"my-private-secure-api.appspot.com"。Due to a certain compatibility setting, this vulnerability will not affect some older versions of Google services.。

该漏洞的出现会对谷歌服务产生重要影响，一些重要的流程使用服务配置中的服务名称来执行除权限检查之外的任意操作，所以，如果配置中加入了不同的服务名称后，攻击者就可以在不同的服务中执行一些重要的操作。这些操作包括：

1#启用其它服务

如果我拥有服务"the-expanse.appspot.com" ，和其在配置项中对应的"very-important-api.example.com" ，当启用 "the-expanse.appspot.com"运行某项谷歌的云端项目时，谷歌服务会继续运行，因为我拥有启用"the-expanse.appspot.com" 的权限，但是，最终操作会实现在"very-important-api.example.com"的执行上，因此，最终可以启用"very-important-api.example.com"。

如果用户设置了具备Google API 密钥或Google认证令牌的API，来对合法客户进行认证，那么，攻击者可以绕过这种身份验证机制。

由于谷歌本身使用了这种方法来认证合法客户端，因此，攻击者可以使用一些用于开发的私有Google API，获取到一些仅供白名单用户（可信测试人员、Google My Business API等）才能访问的内部信息。

2#访问隐藏功能

Service Management API中的一个隐藏方法是“PatchProjectSettings”，这允许服务的所有者配置针对特定服务项目的某些隐藏设置，在这些设置中，可以选择配置可见性标签来对隐藏功能的访问进行管理。

例如，如果我有服务“the-expanse.appspot.com”，和其配置项中的“cloudresourcemanager.googleapis.com”，我可以发送以下请求访问我的云端项目(the-expanse)中，由少数可信测试人员测试的功能。

PATCH /v1/services/the-expanse.appspot.com/projectSettings/the-expanse?updateMask=visibilitySettings&key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
<..same>
{
  "visibilitySettings": {
    "visibilityLabels": [
      "TRUSTED_TESTER"
    ]
  }}</..same>

3#关闭他人云端项目的服务功能

利用上述同样的方法，我们可以对某云端项目是否启用或关闭某项服务进行控制，但是，要注意的是，这种方法只能禁用其他人项目中的服务，不能执行服务启用操作。

比如，如果我有服务"the-expanse.appspot.com" ，以及配置项中的"cloudresourcemanager.googleapis.com" ，我可以发送以下请求去禁用位于Cloud SDK中的谷歌云端资源管理API：

PATCH /v1/services/the-expanse.appspot.com/projectSettings/google.com:cloudsdktool?updateMask=usageSettings&key=AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g HTTP/1.1
<..same>
{
  "usageSettings": {
    "consumerEnableStatus": "DISABLED"
  }
}</..same>

漏洞影响

该漏洞可导致很多问题，如启用私有API、访问隐藏功能、禁用其他人项目中的服务，进而导致客户对谷歌云端服务的使用问题。我没一一进行过验证，但我可以肯定的是，该漏洞可以实现以下操作，对客户服务造成影响：

访问各种处于开发阶段尚未公开的Google API和其中的内置功能；

免费使用一些收费的Google API功能；

访问那些使用谷歌云端服务来进行开发的私有API；

访问一些谷歌自身未向公众开放的API隐藏功能；

绕过一些特殊限制条件；

在该漏洞基础上，对其它潜在漏洞形成威胁利用；

对关键API的禁用导致的重要服务中断（如Cloud SDK无法访问项目，Android的YouTube应用无法检索视频的元数据等等）

漏洞上报进程

2018-01-27   发现漏洞

2018-01-27   漏洞初报

2018-01-29   谷歌开发团队修复了服务创建过程的漏洞

2018-01-29   漏洞报告分类

2018-01-30 serviceName/serviceConfig.name과 일치하지 않는 모든 서비스는 Google 시스템에서 삭제되었으며 더 이상 취약점을 악용할 수 없습니다.

2018-01-30 Google 보안 팀은 세 번째 위협을 재현할 수 없지만, 테스트 엔지니어들은 여전히 ​​401 오류를 받을 수 있습니다

2018-01-30 구글 보안팀은 이 취약점과 관련이 있는 것으로 의심되는 침입을 발견하고 긴급히 복구 패치를 출시했습니다

2018-01-31 구글이 이를 알려왔습니다 개발팀 취약점을 보고한 지 1시간 후에 독립적으로 취약점을 발견했지만 내 취약점 보고서는 현상금 평가를 위해 Google 보안 팀에 계속 전송되었습니다

2018-02-14 Google은 취약점 현상금에 대해 7500달러를 지급했습니다

위 내용은 Google Cloud Platform 취약점 발견 및 포상금 수령 분석 예시의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!