- Kredensial Microsoft corporate cloud terekspos di subdomain kalkulator premi Eicher Motors, sehingga akun email noreply milik TTIBI bisa digunakan untuk login
- API pengiriman email yang bermasalah mengirim email tanpa autentikasi, dan log pengiriman pada respons kesalahan server mengungkap kata sandi yang dienkode base64
- Di akun yang terekspos tersebut tersimpan 657.000 email yang dikirim ke pelanggan, sekitar 25GB PDF polis asuransi, informasi pelanggan, tautan reset kata sandi, dan OTP
- Akun tersebut tidak memiliki autentikasi dua faktor, dan resource cloud lain seperti direktori perusahaan Microsoft, SharePoint, dan Teams juga bisa diakses
- API yang rentan diperbaiki agar mewajibkan autentikasi lebih dari 2 bulan setelah dilaporkan, dan per 27 Januari 2024 kata sandi akun email juga telah diganti sehingga tidak lagi bisa login
Pembobolan TTIBI yang Berawal dari Kalkulator Premi Eicher
- Saat meneliti sistem Eicher Motors, akun email Microsoft
noreplyeicher@ttibi.co.inmilik Toyota Tsusho Insurance Broker India, selanjutnya disebut TTIBI, ditemukan terekspos - TTIBI adalah broker asuransi India di bawah Toyota Tsusho Insurance Management Corporation dari Jepang, yang didirikan pada 2008
- Eicher Motors adalah produsen otomotif India yang memproduksi sepeda motor Royal Enfield Motors dan kendaraan niaga VE Commercial Vehicles, perusahaan patungan dengan Volvo Group
- Kedua perusahaan memiliki kemitraan terkait asuransi, dan di situs TTIBI terdapat subdomain khusus Eicher
Jalur Penemuan Kerentanan
- Saat menganalisis aplikasi Android MY EICHER, URL kalkulator premi ditemukan di kelas Java antarmuka API
- Kode sumber situs kalkulator premi memuat mekanisme pengiriman email sisi klien
- Di dalam kode ada jejak penggunaan Bearer Authorization sehingga tampak memerlukan autentikasi, tetapi saat permintaan API dibuat langsung, email benar-benar terkirim alih-alih mendapat
401 Unauthorized - Respons kesalahan server ikut mengembalikan log pengiriman email, dan di dalamnya terdapat kata sandi yang dienkode base64
Data yang Tersisa di Akun noreply
noreplyeicher@ttibi.co.inadalah akun noreply untuk pengiriman email otomatis, tetapi di TTIBI akun tersebut benar-benar bisa digunakan untuk login- Di akun tersebut tersimpan seluruh riwayat email yang dikirim kepada pelanggan
- Total 657.000 email
- Sekitar 25GB
- Informasi pelanggan
- PDF polis asuransi
- Tautan reset kata sandi
- OTP
- Karena OTP dan tautan reset kata sandi juga dapat dilihat, informasi tersebut berpotensi disalahgunakan untuk mengambil alih akun asuransi pelanggan
- Resource Microsoft cloud juga bisa diakses dengan akun yang sama
- Direktori perusahaan
- SharePoint
- Teams
Kegagalan Keamanan yang Memperbesar Kerentanan
-
Fungsi Pengiriman Email Sisi Klien
- Fungsi pengiriman email yang memungkinkan klien mengontrol subjek, isi, dan penerima dapat disalahgunakan untuk mengirim email berbahaya
- Karena dikirim dari akun sungguhan, hal ini dapat merusak reputasi email dan berujung pada phishing
-
Tidak Ada Autentikasi API
- Di frontend ada jejak penggunaan token autentikasi, tetapi server tidak benar-benar memeriksa token tersebut
- Jika server memverifikasi token, serangan ini kemungkinan bisa dicegah
-
Respons Kesalahan API yang Berlebihan
- Ketika terjadi kesalahan saat pemrosesan API, terlalu banyak informasi dikembalikan ke klien
- Dalam kasus ini, respons kesalahan mengekspos kata sandi secara langsung
-
Tidak Ada Autentikasi Dua Faktor
- Saat login ke akun Microsoft, tidak ada autentikasi dua faktor ataupun prompt verifikasi login lainnya
- Jika autentikasi dua faktor tersedia, login yang berhasil kemungkinan akan lebih sulit dilakukan
-
Retensi Email
- Semua email yang dikirim dan diterima akun disimpan, sehingga informasi pelanggan dalam jumlah besar dapat diakses dengan mudah
- Jika ada kebijakan retensi, dampak paparan data pelanggan bisa dikurangi
Respons dan Status Saat Ini
- Per 17 Januari 2024, meskipun sudah lebih dari 5 bulan sejak TTIBI mengetahui kerentanan tersebut, kata sandi akun email belum diganti
- Menurut pembaruan 27 Januari 2024, kata sandi akun email telah diubah, sehingga akun tersebut tidak lagi bisa digunakan untuk login
- API yang rentan akhirnya diperbaiki agar mewajibkan autentikasi
- Tidak diketahui apakah ada peringatan login Microsoft yang tidak normal; jika ada, peringatan tersebut mungkin diabaikan atau tidak diperiksa
Linimasa Pelaporan
- Karena TTIBI tidak termasuk dalam cakupan program pengungkapan kerentanan HackerOne Toyota, laporan dikirim ke CERT-In India
- 7 Agustus 2023: Mengirim laporan detail kerentanan ke CERT-In
- 8 Agustus 2023: CERT-In menerbitkan case ID dan menjawab bahwa mereka akan menghubungi TTIBI
- 1 September 2023: Meminta pembaruan progres
- 6 September 2023: CERT-In menjawab bahwa mereka telah meneruskan kerentanan kepada TTIBI dan akan membagikan pembaruan tambahan
- 8 Oktober 2023: Situs web yang terdampak sudah diturunkan, tetapi API yang rentan masih ada, sehingga CERT-In diberi tahu
- 11 Oktober 2023: CERT-In menjawab bahwa TTIBI telah memperbaiki kerentanan, tetapi hasil verifikasi menunjukkan kerentanan masih ada
- 18 Oktober 2023: API pengiriman email diubah agar mewajibkan autentikasi, sehingga kerentanan diperbaiki
- Setelah itu berlanjut percakapan untuk memastikan apakah ada imbalan bug bounty, tetapi TTIBI tidak menjawab, dan kasus ditutup pada 22 Desember 2023
1 komentar
Komentar Hacker News
Saya bukan orang India, tetapi sebagai orang yang bekerja di perusahaan IT besar sejenis Tata, ini terasa sangat realistis
Budaya manajemen yang memberi imbalan kalau sesuatu diselesaikan dengan murah, serta budaya yang menekan inisiatif dan aktualisasi diri developer, sangat berperan di sini
Kalau saya melihat hal seperti ini di AS, saya pasti langsung pergi, tetapi mereka punya ketentuan pengembalian gaji 90 hari jika resign, jadi pada dasarnya tidak punya pilihan
Sebagian besar manajer berlatar belakang nonteknis, sehingga hanya mau mendengar hal yang ingin mereka dengar dan tidak mau mendengar kabar buruk
Menganggap ini sebagai hasil dari tim atau perusahaan yang sama pun bisa keliru, karena developer sangat disilo-kan dan dipecah menjadi developer API, developer Office 365, developer front-end, dan seterusnya; mereka tidak menyentuh area yang belum “disertifikasi” untuk mereka
Bahkan dalam rapat proyek senilai 100 juta dolar, mereka bisa berdebat serius soal biaya SendGrid, lalu akhirnya ada developer yang berkata itu bisa dilakukan dengan Office 365 karena ia tidak punya “pengalaman SendGrid”
Anggaran tim keamanan menjadi yang pertama dipotong karena “seharusnya sudah aman”, dan kalau bicara dengan orang setara keponakan yang direkrut untuk keamanan, sikapnya adalah kenapa repot-repot kalau pemerintah atau siapa pun tidak akan menuntut
Developer tidak didorong untuk mengembangkan, melainkan diajari untuk menyelesaikan tiket dan tidak bertanya
Saya bekerja dengan developer India yang cerdas, tetapi ini bukan budaya inovasi; ini pekerjaan yang diperlakukan seperti call center. Jangan keluar dari naskah, tetap di ruang masalah yang sempit, dan selama tidak gagal, dianggap menang
Itu juga bisa segera terjadi pada kita
Pada pertengahan hingga akhir 2000-an, dealer mobil afiliasi Honda yang pernah saya tangani menyimpan aplikasi pembiayaan dengan ID angka yang terus bertambah
Saya tidak melaporkannya, tetapi saya bisa melihat sejumlah informasi sensitif warga New Jersey seperti SSN, tanggal lahir, nama, dan alamat
Saat itu bug bounty praktis tidak ada, sementara CFAA ada, jadi saya tidak melaporkannya
Saya meminta aplikasi saya dihapus, tetapi kerentanannya tetap ada selama bertahun-tahun sampai mereka pindah ke sistem baru, dan sistem barunya pun tampak rentan
Setelah itu saya tidak lagi berurusan dengan dealer tersebut, dan sampai sekarang saya sangat berhati-hati dengan dealer mobil dan aplikasi pembiayaan. Meski sedikit lebih mahal, biasanya saya mengambil pembiayaan dari tempat lain
https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
Di https://cerebrum.com kami sedang mengerjakan area lain, yaitu pemeriksaan identitas, dan komentar ini memunculkan banyak ide
Kesalahan keamanannya sendiri memang mengerikan, tetapi masih bisa dijelaskan sampai batas tertentu sebagai akibat menyerahkan pekerjaan yang jauh melampaui pemahaman kepada developer yang tidak berpengalaman
Namun saya tidak mengerti bagaimana bisa ada yang menyetujui penyimpanan dokumen pelanggan rahasia di akun email
Itu berarti tidak ada penanggung jawab yang tahu cara menjalankan bisnis ini, dan jika ini anak perusahaan atau mitra outsourcing, berarti tidak pernah ada yang mengauditnya
Ini mendekati kelalaian pidana, baik oleh pemilik perusahaan maupun pihak yang menyerahkan pekerjaan ini
Mungkin server email menyimpan email terkirim, dan ini muncul sebagai efek samping dari keputusan bodoh menggunakan akun sungguhan untuk alamat “noreply”
Itu sekaligus menjadi log audit, alat debugging, dan backup database
Mereka baru mengubahnya setelah tahu karyawan membawa semua informasi pelanggan ke tempat kerja baru
Jika “lebih dari 5 bulan berlalu tetapi TTIBI tetap tidak mengganti kata sandi akun email meski mengetahui kerentanannya”, saya harap setidaknya kata sandi Base64 sudah dikeluarkan dari log error
Pasti sudah, kan? Iya kan?
Dampaknya benar-benar besar, setara akses penuh ke SharePoint dan Outlook, tetapi jalurnya hanya sebatas melihat JavaScript sisi klien, jadi ini kerentanan yang cukup unik
Satu hal kecil: untuk informasi sensitif di screenshot, menurut saya menutup dengan blok hitam lebih baik daripada blur. Tidak ada salahnya lebih berhati-hati
Karena struktur yang berakhir dengan “surat terima kasih”, sebagian besar kerentanan seperti ini tidak dilaporkan atau dipublikasikan oleh white hat, melainkan dieksploitasi secara aktif oleh hacker
Harus ada kerangka hukum yang meminta pertanggungjawaban perusahaan atas pengelolaan keamanan yang buruk di atas tingkat tertentu terkait data pribadi pelanggan
India punya masalah yang lebih besar daripada kebocoran data
Salah satunya adalah pasokan listrik yang stabil
Saya menunggu hari ketika India punya listrik yang cukup sehingga peretasan menjadi kekhawatiran utama
Mereka sedang memasang 100 ribu km serat optik setiap bulan dan membangun 350 BTS 5G setiap hari
Perlu juga dilihat bahwa endpoint email pemantauan ini pada dasarnya dirancang seperti pekerja/agen/runner komunikasi, lalu dibiarkan hingga terus membengkak
Ini berarti mereka tidak memantau penggunaan email, dan tidak ada pengaman tambahan untuk mencari perilaku aneh seperti “kenapa biaya penyimpanan alias email ini berkali-kali lipat dibanding yang lain?”
Intinya adalah “akun noreply berpotensi menyimpan semua rekaman yang dikirim ke pelanggan, jadi mungkin merupakan akun terpenting dalam organisasi”
Jika “broker asuransi terkemuka di seluruh India” tidak punya uang untuk mempekerjakan developer yang kompeten, setidaknya mereka harus memberi beberapa receh kepada orang yang menemukan dan secara bertanggung jawab memberi tahu beberapa masalah serius yang membahayakan pelanggan
Namun mereka tidak melakukannya, dan bahkan kata sandi akun email yang telah dibobol pun rupanya belum direset; ini sulit dipercaya
Bagaimana bisa kita mempercayai perusahaan yang bertindak seperti ini untuk melakukan apa pun dengan benar
Toyota Tsusho Insurance Broker India tampak seperti perusahaan yang harus dihindari seperti wabah
Ini bukan seseorang yang secara aktif mengabaikan peringatan keamanan penting, melainkan kondisi ketika mereka tidak memahami apa yang Anda bicarakan
Mereka pada dasarnya tidak memahami lingkungan yang mereka operasikan atau tantangan yang mereka hadapi, dan karena istilah teknis yang Anda gunakan tidak berarti apa-apa bagi mereka atau tim mereka, mereka hanya berharap Anda pergi
Sikapnya seperti “tolong berhenti mengirim email membingungkan ini. Kami punya urusan penting”
Untuk memperbaikinya, organisasi perlu mengganti jajaran pimpinan, dan kepala IT beserta semua yang pernah ia sentuh harus keluar
Sebagian masalahnya adalah inbox ini pada dasarnya dipakai seperti akun SMTP “gratis” agar tidak perlu membayar biaya email keluar
Jika mereka memakai sesuatu seperti SES, kotak terkirim/kotak masuk akun ini tidak akan berisi begitu banyak informasi sensitif
SES sangat murah, 0,10 dolar per 1.000 email
Mereka harus menyimpan semua email yang dikirim dan membuat antarmuka agar staf operasional nondeveloper bisa melihat dan mencari pesan lama
Jika mereka memakai seluruh fungsi dari pendekatan SMTP “gratis” ini, biaya pengembangan dan pemeliharaannya cukup besar