Dan bagaimana saya melakukan ini? Semuanya dimulai dengan aplikasi yang saya kembangkan. Untuk alasan yang jelas, saya tidak akan mempublikasikan nama tersebut. Aplikasi ini cukup sederhana, dirancang untuk orang-orang yang menyukai kebugaran, dan menawarkan opsi seperti memasukkan data tentang kecepatan selama berlari atau kompleks latihan kekuatan yang sudah jadi. Seperti banyak produk lainnya, pengguna harus membuat akun terlebih dahulu. Menurut analis, sekitar 60% orang, alih-alih melalui seluruh proses pendaftaran, tergoda oleh tombol "Masuk dengan Google" yang menggoda.
Anda mungkin tahu secara umum apa yang terjadi dalam kasus seperti itu: ketika pengguna mengklik tombol, jendela browser untuk masuk ke akun Google terbuka di dalam aplikasi.
Pengguna ini mengaktifkan identifikasi dua faktor, jadi setelah dia memasukkan email dan kata sandi, sebuah kotak dialog muncul menanyakan apakah itu dia. Lokasi dan tipe perangkatnya sama, jadi dia mengklik "Ya".
Faktanya, itu saja. Sekarang seseorang dapat menggunakan aplikasi dengan aman, sementara saya, sementara itu, mendapatkan akses penuh dan tidak terbatas ke akunnya dari server jarak jauh. Dia tidak akan pernah menerima pesan apapun tentang ini. Dan jika dia ternyata sangat teliti dan mulai mempelajari lalu lintas jaringan, dia akan melihat bahwa perangkat mengirim permintaan jaringan saja dan secara eksklusif ke berbagai subdomain dari google.com.
Tapi bagaimana ini mungkin? Mari kembali ke tombol Masuk dengan Google. Mari kita perjelas satu hal: bagi mereka yang tidak tahu, setelah mengklik tombol ini, aplikasi dapat melakukan apa saja. Luncurkan proses otorisasi di Google, berikan suara terompet, tunjukkan gif dengan kucing. Tidak semua opsi dari daftar ini memiliki kemungkinan yang sama, tetapi Anda bisa bermimpi.
Dalam kasus saya, dengan mengklik tombol, aplikasi membuka kotak dialog menggunakan WebView dan menyetel alamat web: accounts.google.com/EmbeddedSetup . Itu sesuai dengan halaman login akun Google, hanya yang khusus dirancang untuk perangkat Android baru. Keadaan ini akan memainkan perannya nanti, ketika kami dengan hormat diberikan semua informasi yang diperlukan dalam bentuk cookie.
Sayangnya, halaman ini terlihat dan bertindak berbeda dari halaman login standar (setidaknya seperti seharusnya secara default):
Perhatikan garis biru aneh, kata-kata Pelajari lebih lanjut dan seterusnya di gambar kanan.
Dan sekarang kesenangan dimulai. Saya menggunakan API standar yang dibangun di iOS dan Android untuk memasukkan kode Javascript yang ditulis dengan baik yang akan membuat modifikasi yang diperlukan sehingga halaman tidak berbeda dari standar dalam hal tampilan atau perilakunya.
Orang yang cerdik sekarang akan berpikir: "Berhenti, jadi jika Anda dapat memasukkan kode JavaScript, apa yang mencegah Anda untuk mencuri login dan sandi Anda langsung dari kolom teks?" Sama sekali tidak ada - secara umum, sudah ada kode yang sudah jadi untuk tujuan ini ada. Namun saat ini akses login dan password sudah tidak cukup. Kecuali Anda sangat beruntung, server akan berada dalam jarak beberapa ratus mil dari lokasi pengguna. Jika tidak, pengguna akan menerima surat dan pemberitahuan dengan pesan tentang "aktivitas mencurigakan" dan upaya peretasan akan dihentikan. Dan otentikasi dua faktor membuat hidup kita semakin sulit.
Jadi mari kita bicara tentang hal lain, seperti token master. Pada pandangan pertama, sepertinya tidak baik, tetapi pada yang kedua - ternyata lebih buruk dari yang terlihat.
Saat pertama kali masuk, perangkat Android mengirimkan token yang diterima dari laman masuk bawaan yang disebutkan di atas ke titik akhir khusus. Berikut adalah contoh permintaan umum:
POST /auth HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 349
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: GoogleLoginService/1.3 (a10 JZO54K);gzip
app: com.google.android.gmsapp=com.google.android.gms&client_sig=38918a453d07199354f8b19af05ec6562ced5788&callerPkg=com.google.android.gms&callerSig=38918a453d07199354f8b19af05ec6562ced5788&service=ac2dm&Token=oauth2_4%2F4AY0e-l5vPImYAf8XsnlrdshQQeNir3rSBx5uJ2oO9Tfl17LpsaBpGf1E2euc18UyOc8MnM&ACCESS_TOKEN=1&add_account=1&get_accountid=1&google_play_services_version=204713000
Token dalam permintaan ini diambil dari cookie halaman login akun, dan yang lainnya adalah informasi yang tersedia untuk umum (terima kasih, microG !). Halaman login akun yang sama menangani berbagai hal dengan autentikasi dua faktor - kami tidak perlu melakukan apa pun.
Setelah itu, endpoint yang disebutkan di atas mengirimkan token master yang sama. Tetapi bagaimana saya bisa mengaksesnya tanpa permintaan jaringan yang mencurigakan? Sangat sederhana: melalui log di Google Firebase.
Dan token master sangat kuat. Ini memiliki masa berlaku yang tidak terbatas, asalkan pengguna tidak mengubah kata sandi atau pengaturan otentikasi dua faktor. Sejauh yang saya tahu, ini tidak tunduk pada pemeriksaan keamanan apa pun, terlepas dari lokasi, IP, dan tindakannya. Itu tidak pernah memprovokasi sistem untuk mengirim pemberitahuan atau surat kepada pengguna.
Dan yang terpenting: ini membuka jalan bagi saya untuk semua, tanpa kecuali, layanan yang pernah tersedia dari perangkat seluler, atas nama pemilik akun yang sesuai. Satu permintaan POST cukup bagi saya untuk berpura-pura menjadi akun Google resmi dan mendapatkan token OAuth untuk mengakses apa pun, termasuk API pribadi (dan kemungkinan besar tidak dipublikasikan di mana pun). Saya dapat membaca email, menjelajahi Google Drive, melihat cadangan dari ponsel dan foto saya di Google Foto, dan pada saat yang sama membaca riwayat web pengguna dan mengobrol dengan teman-temannya di Google Messenger. Saya bahkan membuat versi mikroG yang dimodifikasi sehingga saya dapat mengelola semua akun pengguna ini langsung dari aplikasi Google biasa.
Dan saya ingatkan Anda, keseluruhan proses terlihat seperti ini... Saya mengundang semua orang untuk mengajukan pertanyaan: apakah Anda akan ketahuan?
Paparan
Seperti yang sudah Anda duga, tidak semua yang ada di artikel ini benar. Saya belum menerbitkan aplikasi kebugaran apa pun di Play Store dan belum mengumpulkan jutaan Token Master. Terima kasih untuk posting ini untuk inspirasinya. Tetapi metode itu sendiri berhasil. Saya, dan pengembang lain, pasti bisa membuat aplikasi dengan kejutan seperti itu (mungkin seseorang sudah melakukannya).
FAQ
Tapi halamannya berbeda dari login biasa. Saya akan memperhatikan!
Perbedaannya tidak begitu mencolok, jadi kemungkinan besar mereka tidak akan menyadarinya. Halaman masuk akun Google di Android biasanya memiliki antarmuka "pilih akun", tetapi ada pengecualian - misalnya, banyak aplikasi web, seperti yang dibuat di Ionic dan Cordova. Sebagian besar aplikasi iOS juga lebih menyukai versi web, yang sangat mirip dengan opsi di atas. Selain itu, bahkan jika menurut Anda tidak adanya layar dengan "aplikasi ini dan itu meminta akses ...", Anda pasti akan diberi tahu, maka itu mungkin diterapkan dengan biaya beberapa tambahan jam kerja.
Apakah ini juga berfungsi di iOS?
Saya belum mencobanya, tetapi tidak ada alasan untuk percaya bahwa itu tidak akan berhasil.
Dan apa hubungannya dengan itu?
Secara umum, pertanyaannya rumit. Tak satu pun dari tindakan saya, secara tegas, termasuk dalam definisi eksploitasi, tetapi hasilnya tetap sangat berbahaya. Sebagai permulaan, Google ingin memilah pemberitahuan "masuk dengan perangkat baru" agar berfungsi dengan baik. Secara pribadi, saya mendapatkannya ketika saya mencoba masuk ke akun saya dari komputer, tetapi ketika saya menguji aplikasi ini, sistem tidak pernah berfungsi. Ide bagus lainnya adalah memperbarui pedoman untuk tombol "Masuk dengan Google"; sekarang tidak mengatakan apa-apa tentang persyaratan implementasi sama sekali. Mungkin mereka harus mempelajari lebih dalam tentang hutan keamanan melalui ketidakjelasan - sebuah prinsip, untuk semua kekurangannya, sejauh ini bermanfaat bagi Apple untuk keamanan iMessage.
Saya harus mengakui: Saya tidak yakin bahwa solusi teknis dapat ditemukan di sini yang akan sepenuhnya menghilangkan masalah. Jika aplikasi resmi Google memiliki kemampuan untuk melakukan beberapa tindakan, maka program pihak ketiga, dengan uji tuntas, akan dapat mengulanginya. Namun, perusahaan mempekerjakan orang-orang pintar, jadi tunggu dan lihat.
Apakah masalah ini relevan untuk semua sistem otorisasi di aplikasi pihak ketiga?
Sangat mungkin. Saya tidak memahami secara menyeluruh di mana kasus pemberitahuan dikirim dan di mana tidak, tetapi bahkan ketika pemberitahuan tiba, tidak selalu jelas dari mereka apa yang terjadi. Fungsi "Masuk dengan Apple", bagaimanapun, dilengkapi dengan pedoman yang sangat ketat, dan administrasi App Store (di mana fungsi tersebut, saya yakin, terutama digunakan) secara ketat memantau kepatuhan terhadap persyaratan. Di sisi lain, mereka memiliki masalah sendiri dengan otorisasi, yang akan memudar.
Kisah nyata
Bahkan jika itu bukan jutaan, entah bagaimana saya benar-benar mengumpulkan sejumlah kecil token master dari pengguna yang tidak menaruh curiga, dan secara tidak sengaja.
Kisah nyata pencerahan saya dimulai ketika saya mengembangkan aplikasi Carbon Player; sekarang ini telah tenggelam terlupakan, dan belum menerima distribusi luas. Aplikasi ini disusun sebagai pengganti Google Play Music (ingat hari-hari ketika itu ada?), Hanya dengan desain yang jauh lebih keren. Untuk mengakses folder musik kustom, saya menerjemahkan gmusicapiSimon Weber di Java, tetapi, saat menulis ulang kode, pada awalnya saya tidak begitu mengerti bagaimana proses otorisasi bekerja di sana. Saya hanya menyadari bahwa saya memerlukan nama pengguna dan kata sandi, yang saya minta melalui kotak dialog sederhana, kemudian beberapa permintaan datang dan beberapa token yang cocok untuk saya mengekstrak musik rontok.
Sebelum mentransfer versi pertama aplikasi ke sekelompok kecil penguji, saya menyisir kode, menambahkan logging di mana-mana dan juga menerapkan pencegat, yang seharusnya secara otomatis mengunggah semua log ke Firebase. Tentu saja, saya cukup pintar untuk tidak mencatat kata sandi, tetapi saya menjanjikan tiga token yang diterima oleh implementasi gmusicapi saya karena kesalahan. Dua di antaranya tidak berbahaya - mereka hanya memberi akses ke toko musik yang berbeda. Tapi yang ketiga ternyata adalah token master.
Secara umum, aplikasi telah mengumpulkan paling banyak dua puluh lima unduhan selama seluruh keberadaannya, dan saya dengan cepat melambaikan tangan saya padanya agar tidak terganggu dari studi saya. Namun sebelum itu, ia berhasil merilis beberapa pembaruan, salah satunya adalah desain ulang halaman beranda Google Play Musik baru yang mengagumkan (yah, untuk saat itu) - salah satu dari sedikit elemen produk asli yang terlihat bagus.
Prosesnya ternyata jauh lebih membingungkan daripada yang saya kira, dan tanpa diduga harus melakukan banyak rekayasa balik Protocol Buffer. Lebih penting lagi, untuk beberapa alasan, sekarang diperlukan token yang sama sekali berbeda, yang tidak lagi diterapkan di gmusicapi. Akibatnya, untuk menerapkannya, saya menggali sistem otorisasi selama beberapa jam, mencoba mencari tahu cara kerjanya. Hal ini menyebabkan momen pencerahan yang mengerikan ketika saya menyadari bahwa saya mencatat informasi paling sensitif yang saya bisa. Saya akan mengatakan satu hal: penebangan telah berhenti. Dua puluh lima orang yang mendownload aplikasi, maafkan saya (saya hapus token Anda dari Firebase!).
Ada lagi, yang tidak terkait dengan pertama kali ketika saya bekerja di startup membuat pengelola kata sandi. Salah satu keuntungan utama dari aplikasi ini adalah ia menyimpan sandi secara ketat di ponsel, tetapi pada saat yang sama mengizinkan otorisasi dari komputer berkat bookmarklet JavaScript yang "menghubungkan perangkat" melalui kode QR. Agar semuanya berjalan lancar, saat pengguna membuka situs di komputer, aplikasi mengakses situs yang sama dari ponsel dan memasukkan kode JavaScript yang ditulis dengan cermat yang menangkap info masuk, sandi, dan lainnya. Terdengar akrab?
Pada akhirnya, kedua ide ini muncul di kepala saya. Saya memiliki prototipe untuk Carbon Player tetapi tidak punya cukup waktu untuk membuatnya berfungsi. Beberapa tahun kemudian, saya akhirnya mulai membuat sesuatu seperti versi demo sebagai dasarnya. Banyak yang harus diubah dalam prosesnya - metode yang dijelaskan dalam artikel ini sangat berbeda dari yang diterapkan dalam prototipe, karena Google membuat perubahan pada sistem otorisasi. Tetapi hasil akhirnya tetap sama dan tidak kalah menakutkan dari sebelumnya.
Jika mau, Anda dapat mengunduh versi demodan melihat sistem beraksi; Saya berjanji bahwa tidak ada yang masuk ke cloud. Ingatlah bahwa aplikasinya sangat sederhana dan hampir tidak pernah diuji, jadi ada kemungkinan besar metode ini tidak akan berfungsi jika akun Anda memiliki konfigurasi yang berbeda. Terima kasih telah membaca artikel ini, saya harap Anda menikmati sedikit pengingat akan pentingnya mempertanyakan segalanya. Bahkan hal-hal yang paling tidak berbahaya terkadang menyembunyikan sesuatu yang tidak terlalu menyenangkan di dalam (meskipun dalam kasus kue es krim, hal itu terjadi sebaliknya).