- Ini adalah kasus ketika penyerang berhasil mengirim email phishing yang menyamar sebagai Google dengan memanfaatkan serangan replay DKIM
- Alamat pengirim dan hasil autentikasi email terlihat seperti email resmi Google yang asli sehingga pengguna mudah tertipu
- Penyerang memanfaatkan Google Sites untuk membuat situs yang tampak seperti halaman dukungan resmi dan meningkatkan kredibilitas
- SPF, DMARC, dan DKIM semuanya lolos autentikasi, tetapi inti serangannya adalah meneruskan ulang email tanpa mengubah isi maupun header yang ditandatangani
- Sebagai langkah mitigasi praktis, disarankan rotasi berkala kunci DKIM dan peningkatan kesadaran pengguna
Awal: Email phishing yang tampak normal
- Pada pagi hari, seorang kenalan menerima email tentang permintaan dokumen hukum terkait akun Google
- Pengirim ditampilkan sebagai alamat no-reply resmi Google, ditulis dengan rapi tanpa salah ketik, tautan mencurigakan, maupun domain yang tidak normal
- Penerima sulit menilai keasliannya sehingga meminta bantuan seorang ahli
Analisis detail email
- Header email dan pratinjau tautan diperiksa di lingkungan sandbox
- Alamat pengirim, branding, kualitas bahasa, dan ada tidaknya lampiran semuanya tampak normal
- Namun, saat memeriksa hasil autentikasi SPF, DKIM, dan DMARC, ditemukan tanda-tanda anomali
Hal yang perlu diperhatikan pada email phishing
- Ditekankan untuk tidak mengklik tautan atau menjalankan instruksi dalam email yang mencurigakan
- Jika membalas email tersebut atau membuka lampiran di luar sandbox, ada risiko kebocoran informasi, kompromi email perusahaan, pembajakan akun, dan pelanggaran jaringan
- Jika mencurigakan, perlu segera meminta analisis profesional dan melaporkannya ke tim keamanan
Alur serangan: memanfaatkan Google Sites
- Tautan di email serangan akan langsung mengarah ke Google Sites jika pengguna sedang login
- Google Sites adalah subdomain resmi google.com yang bisa dibuat siapa saja secara gratis, tetapi isinya sendiri bukan halaman dukungan resmi
- Layanan ini digunakan untuk berbagai keperluan seperti wiki internal, dashboard proyek, dokumentasi, dan situs acara, serta dapat disalahgunakan seperti pada serangan ini
Saat kepercayaan pada infrastruktur menjadi ancaman
- Google Sites (dirilis pada 2008) terintegrasi dengan Google Workspace, memudahkan pembuatan dan distribusi, menyediakan SSL, serta memberi kepercayaan merek
- Penyerang dapat membangun situs phishing yang terlihat resmi dengan mudah dan biaya rendah tanpa domain atau hosting terpisah
Rincian proses serangan replay DKIM
Langkah 1: Mendapatkan email Google yang asli
- Penyerang menerima email normal dari akun no-reply@accounts.google.com, lalu menyimpan isi asli dan header-nya
Langkah 2: Menyiapkan pengiriman ulang pesan bertanda tangan
- DKIM memberikan tanda tangan digital pada sebagian isi email dan header tertentu
- Jika pesan asli dan header tanda tangannya tetap dipertahankan, autentikasi tetap berlaku saat dikirim ulang
Langkah 3: Mengirim ulang lewat Outlook
- Penyerang mengirim email serangan dari akun Outlook
- Sebagian informasi asal dan rute berubah, tetapi tanda tangan DKIM tetap valid
Langkah 4: Menggunakan server relay SMTP Jellyfish
- Email dirutekan melalui sistem Jellyfish milik Microsoft (untuk memberi jarak dari server asal)
Langkah 5: Pengiriman lewat Namecheap PrivateEmail
- Layanan PrivateEmail milik Namecheap menerima email lalu bertindak sebagai relay tambahan
- Dalam proses ini, tanda tangan DKIM baru ditambahkan, tetapi tidak memenuhi kriteria DMARC
- Tanda tangan DKIM Google yang asli tetap cocok dan valid sehingga verifikasi DMARC lolos
Langkah 6: Pengantaran akhir ke Gmail
- Pada akhirnya, penerima mendapat email yang terlihat sebagai email resmi Google
- Hasilnya, SPF, DKIM, dan DMARC semuanya lolos autentikasi
Mengapa email panggilan palsu ini berbahaya
- Email ‘surat panggilan’ memicu rasa takut, urgensi, dan kebingungan pada penerima
- Cara penerbitan atau penyampaian surat panggilan yang sebenarnya berbeda; jika normal, prosesnya dilakukan lewat pengiriman fisik atau kanal resmi
- Jenis phishing seperti ini sangat meyakinkan, sehingga bahkan pengguna yang mahir secara teknis pun mudah tertipu
Kesimpulan dan respons
- Semakin mendesak dan tidak terduga sebuah email, semakin penting untuk selalu memverifikasi keasliannya dan meminta tindakan dari ahli
- Jangan klik tautan, membalas, atau menjalankan apa pun
- Disarankan meminta analisis dari tim keamanan atau personel investigasi khusus
Tambahan: proses reproduksi serangan
- Penyerang mendaftarkan domain di Namecheap dan memperoleh layanan PrivateEmail gratis
- Setelah mendaftar Google Workspace (uji coba gratis) dan memverifikasi domain, penyerang membuat Google OAuth App berbahaya
- Melalui kolom App Name, nama yang diinginkan dapat diatur (misalnya: Google Support)
- Notifikasi akun yang dikirim Google diteruskan ke PrivateEmail, dan alamat pengirim serta alamat balasan dapat dimanipulasi
- Pada akhirnya, email serangan dikirim ke target yang diinginkan
Pertanyaan yang sering diajukan
- Serangan replay DKIM: penyerang menangkap email sah yang berisi tanda tangan DKIM valid, lalu mengirimkannya ulang dengan isi dan header yang sama
- Batasan pemblokiran SPF dan DMARC: SPF hanya memverifikasi server/IP pengirim, dan pada serangan replay, DMARC juga bisa lolos jika kesesuaian DKIM terpenuhi
- Mengapa sulit dideteksi: tanpa perubahan isi atau header, verifikasi tanda tangan saja sulit membedakannya
- Bypass Google OAuth dalam serangan ini: penyerang membuat OAuth App berbahaya dan mengirim ulang notifikasi resmi dari Google untuk memperoleh kredibilitas
- Langkah mitigasi: penting melakukan rotasi berkala kunci DKIM (interval 30 hari atau kurang) serta edukasi pengguna (waspada terhadap tautan mencurigakan, memeriksa URL, dan membangun budaya pelaporan)
1 komentar
Komentar Hacker News
Saya sedang mengerjakan solusi untuk masalah ini (bersama para rekan penulis yang pernah bekerja di Google dan Yahoo, dan ini proyek yang kredibel)
Silakan lihat dokumen Draft: DKIM2 Motivation
Pendekatan ini tidak mencegah teks yang dimasukkan pengguna benar-benar dikirim oleh Google, tetapi setidaknya mencegah pesan tersebut diteruskan ulang tanpa maksud nyata dari Google
Karena field SMTP FROM/TO dilindungi
Draft motivation tidak memuat detail teknis, dan drafnya bisa dilihat di dokumen terkait
Silakan lihat tautan DKIM Working Group Documents
Situs Datatracker tidak menampilkan dokumen kandidat dengan baik, jadi saya lampirkan tautan langsung
Draft: dkim2-dns
Draft: dkim2-header
Draft: dkim2-modification-algebra
Draft: dkim2-bounce-processing
Draft: dkim2-message-examples
Saya penasaran bagaimana pendekatan ini akan bekerja untuk mailing list atau grup
Misalnya, sering ada email dari luar ke accounts-payable@example.com yang otomatis diteruskan ke anggota tim
Saya ingin tahu apakah di sistem penerima akhir perlu ada pengaturan untuk mempercayai mailing list forwarder, atau perlu logika internal yang melacak daftar mana saja yang diikutinya
Harus bisa dipastikan bahwa accounts-payable, sebagai penerima asli, adalah penerima yang valid
Saya sendiri pernah seluruh data akun Google saya disita FBI setelah benar-benar divonis bersalah atas tuduhan peretasan komputer
Mereka mengambil datanya sekali pada 2016, dan sekali lagi pada 2018
Dalam praktiknya, mereka tidak melakukannya seperti yang digambarkan artikel ini
Berdasarkan pengalaman saya, mereka berkomunikasi secara resmi dengan mengirim email ke departemen tertentu di Google
Aparat penegak hukum bergerak sangat hati-hati agar target penyelidikan tidak menyadarinya semaksimal mungkin
Saya menerima email seperti ini dari usernotice@google.com:
Dalam subpoena Federal Grand Jury, biasanya diminta penundaan pemberitahuan selama 1-2 tahun agar penyedia layanan (seperti Google) tidak bisa memberi tahu Anda
Subpoena umumnya hanya memberikan catatan umum seperti informasi penagihan, riwayat login, dan sebagainya, bukan konten seperti email
Untuk data sebenarnya seperti email, harus ada surat perintah penggeledahan terpisah, dan Google biasanya tidak memberi pemberitahuan terpisah bahwa surat perintah seperti itu telah dijalankan
Ini hari Jumat, tapi komentar ini membuat saya 10% lebih terjaga
Saya penasaran dengan cerita detail di baliknya
Menarik
Saya penasaran apakah permintaan seperti ini termasuk dalam permintaan GDPR seperti “minta semua data terkait akun saya”, sehingga tercatat atau diberi tag di file data lengkap akun saya
Tebakan saya, surat perintah penggeledahannya kemungkinan terkait pelanggaran CFAA, wire fraud, atau conspiracy
Semoga Anda menyewa pengacara yang bagus dan semuanya beres
Saya juga menerima serangan serupa baru-baru ini
Penyerang mengirim email dari yourgoogleaccount@google.com (tepatnya bukan gmail.com), lalu meneruskan pesan bounce dari server email Google ke yourgoogleaccount@gmail.com, dan menyisipkan pesan spam di bagian akhir
Semua pemeriksaan keamanan lolos
Yang benar-benar aneh adalah gabungan error postmaster dan kampanye phishing
Orang nonteknis bisa dengan mudah tertipu
Dalam kasus saya, isi phishing-nya semacam saya menang alat konstruksi
Sekarang saya mulai merasa Google sudah menyerah soal email
Saya sangat bingung saat membaca tulisan itu
Tulisan tersebut menggambarkannya secara rinci seolah penyerang memanipulasi body email untuk menyisipkan tautan phishing, tetapi sebenarnya tidak ada bukti atau manipulasi seperti itu
Tanda tangan DKIM mencakup hash body
Secara teknis memang bisa membatasi cakupan hash dengan field I=, tetapi saya cek Google tampaknya tidak memakai opsi itu untuk email pendek (berdasarkan pemeriksaan langsung email no-reply@accounts.google.com)
Artinya, agar pemeriksaan DKIM dan DMARC lolos, body tidak boleh diubah, jadi tautan phishing itu juga merupakan konten yang awalnya dikirim oleh Google (hanya saja mungkin ditujukan untuk penerima yang berbeda)
Jadi inti sebenarnya lebih ke “kasus email menakutkan yang salah diteruskan”, dan judul 'DKIM replay attack' bisa terdengar jauh lebih serius bagi orang yang tidak akrab dengan bidang ini
Edit: Saya melihat "The Takeaway?" di TFA dan mengira artikelnya sudah selesai, tetapi pembaruan di bawahnya menjelaskan bahwa tautan tersebut sebenarnya disisipkan ke nama aplikasi Google OAuth dan dimasukkan ke template email Google
Bagian ini justru poin terpenting dari serangan tersebut, tetapi struktur tulisannya sangat buruk sehingga terkubur, dan memicu kesan seolah pengiriman konten arbitrer itu dimungkinkan
Tambahan: Di komentar lain juga ditunjukkan bahwa screenshot email dipotong di tengah sehingga bagian tetap dari template email Google tidak terlihat
Serangan itu sendiri jauh lebih ceroboh daripada yang terlihat
Tulisan ini tampaknya sengaja dibuat dengan cara yang menyesatkan
Potongan di tangkapan layar dibuat seolah itu seluruh isi email, padahal kemungkinan ada teks lanjutan yang justru layak menjadi peringatan
Sejauh yang saya pahami, alasan DKIM bisa tervalidasi adalah karena penyerang benar-benar meneruskan email yang mereka terima dari Google apa adanya
Vektor serangan yang sebenarnya adalah Google bisa dibuat mengirim email yang berisi teks tertentu yang dikendalikan penyerang
Menurut saya, kerentanan yang sebenarnya di sini adalah nama aplikasi Google OAuth bisa berisi URL, dan itu dirender begitu saja ke email no-reply dari root domain Google menuju alamat mana pun
Meskipun tautannya tidak bisa diklik, jika teks di sekitarnya dibuat cukup mengancam, besar kemungkinan korban akan membuka alamat itu secara manual
Bahwa layanan penerusan yang mempertahankan integritas DKIM bisa bertumpuk beberapa lapis hanyalah aspek edukatif tambahan
URL dalam nama aplikasi OAuth harus diblokir sepenuhnya, terutama URL yang mengandung google.com
Akhirnya!
Beberapa bulan lalu saya menerima email yang nyaris identik (ditujukan ke admin Google Domains)
Saya juga benar-benar merinding saat menerimanya
Saya juga menahan diri untuk tidak gegabah mengklik tautannya, lalu mencoba mencari referensi lain tentang penipuan ini
Hal yang aneh adalah semua alamat email disamarkan, dan pola masking-nya tidak cocok dengan email yang saya kelola
Emailnya sendiri memang legit, dan setelah saya cari di Google, teks body-nya juga cocok
Dalam kasus saya, itu email terkait akun orang yang sudah meninggal, padahal tidak sesuai dengan kenyataan
Tetapi saya hampir 100% curiga bahwa seseorang benar-benar sedang mencoba meyakinkan Google bahwa saya telah meninggal dan ingin mengambil alih seluruh akun Google saya
Itu pengalaman yang sangat menakutkan
Langkah 3: penyerang mengirim email dari Outlook
Setahu saya, memalsukan jalur pada header Received: itu tidak mungkin
Setiap server terus menambahkan informasi jalurnya sendiri
Karena itu saya selalu memeriksa informasi tersebut saat memverifikasi asal email
Email dari Google semestinya tidak mungkin lewat server Microsoft
Header dari server 'tepercaya' terakhir tidak bisa dipalsukan, tetapi jalur lainnya bisa dipalsukan
Saya penasaran apakah Anda benar-benar memeriksa header semua email satu per satu secara manual
Atau Anda memakai alat untuk menandai atau memvisualisasikannya
Situasi yang sangat menyeramkan
Bayangkan harus menjelaskan pelajaran dari tulisan ini kepada saudara atau kerabat
Rasanya berat harus menjelaskan bahwa meskipun email datang dari domain tepercaya dan lolos dkim/dmarc/spf secara berurutan, tetap harus dicurigai
Namun cakupan serangan ini sebenarnya cukup terbatas
Misalnya, penyerang tidak bisa memalsukan pesan seolah dikirim dari akun Gmail orang lain
"Saat pesan diteruskan, tanda tangan DKIM akan tetap utuh selama body dan header yang ditandatangani tidak berubah"
Yang mengejutkan adalah header To: ternyata tidak termasuk dalam cakupan tanda tangan DKIM
Menurut saya, pengaturan penandatanganan perlu diubah, atau klien email perlu menambahkan peringatan saat To berubah meskipun emailnya sendiri tampak valid
Bayangkan menjelaskan pelajaran tulisan ini kepada kerabat – bahwa mereka harus selalu curiga
Masalahnya, kita bahkan harus mulai dengan menjelaskan apa itu dkim/dmarc/spf
Padahal teknologi seperti ini seharusnya cukup menjadi urusan backend yang tidak perlu diketahui pengguna
Serangan ini tidak semenakutkan kelihatannya
Tulisan itu terkesan dilebih-lebihkan untuk menjual produk
Bahwa header To tidak termasuk dalam tanda tangan juga sebenarnya tidak terlalu berarti
Dalam praktiknya, To pada email memang tidak harus selalu berisi penerima akhir
Sikap selalu curiga pada email memang sudah lama menjadi keadaan default
Yang terbaik adalah sama sekali tidak pernah mempercayai field From
Tadi dibilang mengejutkan bahwa To: tidak termasuk dalam tanda tangan DKIM, tetapi sebenarnya termasuk
Karena itu nilai To: aslinya memang harus dipertahankan
Alamat To: asli terlihat di screenshot pada bagian reproduksi
Itu tidak berarti emailnya dikirim ke alamat tersebut
Pada dasarnya, email bisa dikirim ke alamat mana pun dengan nilai To: apa pun
Saran dasar saya adalah, jika ada email apa pun yang mendorong Anda untuk melakukan tindakan, langsung buka situs web terkait secara manual
Jangan klik tautan apa pun
Memang jadi kurang praktis, tetapi pada akhirnya itu menyelesaikan masalah
Khususnya untuk bank atau sistem penting, ketidaknyamanan ini sangat layak ditanggung
Di tempat kerja saya, situasi ancaman seperti ini sudah menjadi kebijakan tetap
Di internet, memang praktik yang baik untuk mencurigai apa pun
Banyak usaha kecil dan pekerja lepas masih tidak memakai MFA, dan bahkan jika memakai pun sering mudah terkena pencurian token
Jika akun-akun seperti itu dibobol, maka email berbahaya akan datang dan tampak seperti benar-benar berasal dari pengguna internal
Dari sudut pandang pengguna, itu akan terlihat sangat legit
Karena itu email memang harus selalu diperlakukan dengan penuh kecurigaan
Penulis menulis
"Here is the URL from that email [...] https://sites.google.com[...]";
Tautan inilah justru tanda bahaya pertama
Menurut saya penulis seharusnya menyoroti poin ini sejak awal, bukan tiga paragraf kemudian
Tidak semua orang mengenal seluruh subdomain google.com
Masalah yang sebenarnya adalah (selain soal field valid di SSO) Google menyajikan konten pengguna di subdomain dari domain utama mereka
Layanan lain seperti Drive juga bisa demikian
Mungkin itu tanda bahaya bagi Anda, tapi belum tentu bagi orang tua kami
Secara keseluruhan, saya rasa ini menunjukkan betapa rapuhnya sistem keamanan email
Di forum ini ada begitu banyak orang pintar, saya rasa seharusnya bisa muncul alternatif yang menyelesaikan masalah seperti ini sekaligus
Saya juga berpikir Google seharusnya menyajikan situs-situs seperti ini bukan di domain utama, melainkan di domain terpisah seperti hostedbygoogle.com
Saya heran kenapa sampai sekarang belum dipisahkan
Secara realistis, semua alternatif yang mungkin pada akhirnya akan menjadi sistem yang menyerahkan seluruh kendali kepada satu perusahaan
Itu akan menghilangkan nilai utama email yang masih tersisa, yaitu sistem yang tidak sepenuhnya dikendalikan siapa pun
Masalah teknisnya sebenarnya cukup bisa dipecahkan, tetapi masalah manusia dan kepentingan jauh lebih sulit
Pihak yang punya sumber daya untuk menyelesaikan masalah ini umumnya tidak punya motivasi untuk membangun platform yang sepenuhnya terbuka
Mereka tidak akan mengeluarkan upaya seperti itu kecuali semua uang dan kendalinya jatuh ke tangan mereka
Sebaliknya, tidak semua orang ingin menyerahkan seluruh kendali kepada satu perusahaan
Itulah sebabnya ini bukan masalah teknis, melainkan masalah bisnis
(Sama seperti alasan mengapa di metaverse hampir mustahil semua layanan berbagi avatar dan item
Bukan karena secara teknis tak mungkin, melainkan karena pemegang hak tidak akan pernah mengizinkannya)
Pengumuman startup baru Shadowfax yang didanai Thiel!
Layanan monopoli kami yang aman dan tersentralisasi kini dilengkapi layer berbasis AI dan blockchain, dan akan menggantikan sistem email yang usang
Kami bahkan sudah mendapatkan kontrak dari Departemen Pertahanan AS, dan diperkirakan akan menjadi standar untuk semua komunikasi federal internal dan eksternal pada 2027