Berikut ialah tentang pelajar sekolah menengah berusia 17 tahun di Uruguay Kerana dia berminat dalam keselamatan maklumat, melalui kajian dan penyelidikan, dia secara bebas menemui kelemahan dalam Google Cloud Platform dan menerima $7,500 (sebelum ini. , dia telah menemui kerentanan Google Cloud Platform bernilai $10,000). Sebelum menerangkan butiran tentang kelemahan ini, kami mengesyorkan agar pembaca membiasakan diri dengan konsep perkhidmatan Google Cloud dan mekanisme API.
Google menjalankan perkhidmatan pengurusan yang dipanggil Pengurusan Perkhidmatan Google, yang melaluinya Google menguruskan antara muka dalaman dan luaran pelbagai aplikasi, sistem Google dan awan yang dibuat oleh pengguna Serve. Di bawah Pengurusan Perkhidmatan Google, pengguna boleh mendayakan dan melumpuhkan perkhidmatan antara muka peribadi secara individu seperti API Peta, API Gmail, API peribadi, dll. dalam projek platform awan mereka dan boleh mengurus pelbagai perkhidmatan dalam masa nyata melalui kawalan konfigurasi antara muka.
Secara umumnya, sebagai pembangun, kami biasanya tidak menggunakan perkhidmatan Pengurusan Perkhidmatan Google secara langsung Kebanyakan operasi interaktif adalah melalui Google Cloud Console atau baris arahan (seperti mendayakan/menutup perkhidmatan), atau melalui The. Antara muka pengurusan API ialah Titik Akhir Awan Google, tetapi perlu dinyatakan bahawa terdapat antara muka API yang menarik bagi perkhidmatan Pengurusan Perkhidmatan Google.
Antara muka API ini bukan sahaja dapat merealisasikan fungsi pengurusan perkhidmatan di atas, tetapi juga merekodkan dalam dokumentasi rasmi Google bahawa anda boleh menggunakan antara muka API ini untuk mengakses beberapa fungsi tersembunyi perkhidmatan Google.
Fungsi tersembunyi ini boleh ditemui dalam pelbagai cara, tetapi yang paling mudah dan paling mudah ialah mendayakan antara muka API Pengurusan Perkhidmatan dalam projek Google Cloud Platform pengguna dan membolehkan penggunaan kotak Combo untuk penapisan trafik projek. Langkah-langkahnya adalah seperti berikut:
Dalam gambar terakhir di atas, pelbagai API disertakan Kaedah untuk melaksanakan fungsi, termasuk beberapa kaedah tersembunyi yang ditandakan dengan kotak merah. Kaedah yang dipanggil tersembunyi ialah pelanggan bukan Google tidak dibenarkan mengaksesnya Apabila pelanggan bukan Google cuba mengaksesnya, ralat 404 akan dikembalikan. Apa yang sangat menarik ialah ralat 404 ini tidak muncul sebagai gesaan "ralat di sini" seperti halaman HTML biasa, tetapi diberikan dalam mod JSON, yang akan menggesa bahawa kaedah itu tidak wujud.
Begitu juga, terdapat juga beberapa kaedah tersembunyi dalam API itu sendiri, yang merupakan parameter tersembunyi yang diterima dalam beberapa kaedah awam, tetapi secara relatifnya, kaedah tersembunyi ini lebih sukar ditemui.
Untuk kaedah tersembunyi dan parameter tersembunyi, semuanya menggunakan ciri perkhidmatan Google yang dipanggil "Keterlihatan". Rekod ciri ini boleh ditanya daripada dokumen awam, tetapi hanya digunakan secara dalaman oleh Google.
Petua: Bahagian tersembunyi API Google sendiri boleh ditemui dalam pelbagai cara, dan kebanyakan masa ia juga mempunyai beberapa dokumentasi tersembunyi Selain itu, Google tidak menganggap API tersembunyi tersebut kefungsian Kewujudan dokumentasi API yang bocor atau tersembunyi adalah kelemahan keselamatan. (Saya pernah melaporkan perkara ini kepada Google).
Walau bagaimanapun, terdapat juga beberapa fungsi tersembunyi jika ia berjaya dieksploitasi, ia akan dianggap sebagai kelemahan keselamatan Contohnya, parameter tersembunyi yang saya temui setahun lalu membentuk For kelemahan, Google memberi saya ganjaran $5,000. Memandangkan kelemahan masih dalam tempoh pembaikan, adalah tidak mudah untuk mendedahkannya pada masa ini.
Selepas memahami pengetahuan di atas, saya cuba menggunakan kaedah untuk mengakses fungsi tersembunyi Google ini jadi, analisa dengan teliti permintaan HTTP yang dihasilkan.
Google Cloud Console menggunakan berbilang API Google awam dan peribadi, program kliennya sendiri dan kunci API AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g untuk mencapai akses maklumat kepada projek awan.
Permintaan biasa daripada pelanggan Google Cloud Console adalah seperti berikut:
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>
Mari kita lihat maksud bahagian pertama:
" pelanggan6. google.com": ialah kaedah perwakilan lain untuk meminta "googleapis.com". Memandangkan kuki hanya boleh mengakses nama subdomain google.com, kaedah ini diperlukan;
"SAPISIDHASH": Menurut StackOverflow forum, ia adalah nilai "TIMESTAMP_HASH" (timestamp_hash). Terdapat banyak cara lain untuk menjana SAPISIDHASH dalam forum, yang tiada kaitan dengan kerentanan ini; "Asal", ia adalah maklumat pengepala yang sangat diperlukan untuk bahagian SAPISIDHASH dan pelanggan untuk mengesahkan akses ke tapak web
Kuki: termasuk SID, HSID, SSID, APISID dan SAPISID, dsb. Pengguna Google perlu log masuk; dalam untuk Mendapatkan maklumat kuki ini.
由此看来，要伪造谷歌云端控制台（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.。
该漏洞的出现会对谷歌服务产生重要影响，一些重要的流程使用服务配置中的服务名称来执行除权限检查之外的任意操作，所以，如果配置中加入了不同的服务名称后，攻击者就可以在不同的服务中执行一些重要的操作。这些操作包括：
如果我拥有服务"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等）才能访问的内部信息。
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>利用上述同样的方法，我们可以对某云端项目是否启用或关闭某项服务进行控制，但是，要注意的是，这种方法只能禁用其他人项目中的服务，不能执行服务启用操作。
比如，如果我有服务"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 Semua perkhidmatan yang tidak sepadan dengan serviceName/serviceConfig.name telah dihapuskan daripada sistem Google dan kelemahan itu tidak boleh dieksploitasi lagi
2018-01-30 Pasukan keselamatan Google tidak boleh pembaikan Ancaman ketiga kini, tetapi jurutera ujiannya masih boleh menerima 401 ralat
2018-01-30 Pasukan keselamatan Google menemui pencerobohan yang disyaki berkaitan dengan kerentanan ini dan mengeluarkan patch pembaikan segera
2018-01-31 Google memaklumkan saya bahawa pasukan pembangunannya secara bebas menemui kelemahan sejam selepas laporan kelemahan saya, tetapi laporan kelemahan saya masih dihantar kepada pasukan keselamatan Google untuk penilaian hadiah
2018-02 -14 Google memberikan saya hadiah pepijat $7500
Atas ialah kandungan terperinci Contoh analisis untuk menemui kelemahan Google Cloud Platform dan menerima hadiah. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
