Penting untuk dicatat bahwa "permainan" serangan dan pertahanan, yang dimainkan oleh para peretas dan pemilik sistem komputer, adalah permainan yang tidak jujur. Cukup bagi penyerang untuk menembus sistem, hanya menang sekali. Dan mereka yang bertahan hanya bisa menang dengan selalu menang. Kesulitan utama di sini adalah untuk mengetahui apa yang perlu Anda perhatikan. Tetapi setelah pembela HAM mengetahui “pintu” virtual mana yang bisa dimasuki hacker ke dalam sistemnya, “pintu” ini dapat dilindungi menggunakan mekanisme yang cukup sederhana. Saya percaya bahwa kesederhanaan mekanisme ini terkadang mengurangi kepentingannya dan merupakan alasan mengapa banyak pembela sistem komputer mengabaikan mekanisme ini.
Berikut adalah aturan dasar untuk melindungi sistem yang akan saya ungkapkan dalam artikel ini. Mereka sederhana, tetapi ini tidak berarti bahwa Anda dapat melupakannya dengan bebas:
- (multi-factor authentication, MFA) , . Google GitHub, , VPN-. MFA — .
- , .
- , . .
- . , .
Dalam hal mencegah kebocoran informasi rahasia dan mencegah munculnya "lubang" dalam sistem keamanan, prinsip Pareto beroperasi , yang menurutnya 20% upaya menghasilkan 80% dari hasil.
Bagaimana cara kerja peretas ketika mereka menemukan kata sandi dan kunci rahasia? Alat apa yang mereka gunakan?
Peretas menemukan data rahasia dalam file JavaScript
Kunci API tersebar di seluruh internet. Siapapun bisa menggunakannya. Itu adalah fakta. Seringkali tidak ada alasan khusus untuk kunci tersedia untuk umum. Pengembang melupakannya di mana saja. Misalnya, kunci masuk ke kode karena alasan berikut:
- Untuk tujuan debugging.
- Untuk tujuan pembangunan lokal.
- Berupa komentar yang ditujukan bagi mereka yang akan mendukung proyek nantinya.
Blok kode yang menyerupai berikut ini dapat ditemukan cukup sering di Internet:
// DEBUG ONLY
// TODO: remove -->
API_KEY=t0psecr3tkey00237948
Meskipun banyak peretas membaca file JavaScript sendiri, mereka kebanyakan mencari file tersebut menggunakan alat seperti meg , dan kemudian memeriksa apa yang mereka temukan untuk pola yang cocok.
Bagaimana mereka melakukannya? Setelah menggunakan pemindai,
megmereka tampaknya mencari string dalam file yang ditemukan yang cocok dengan berbagai pola. Orang yang membuat meg, menulis program bagus lainnya, yang ditujukan untuk ini. Ini disebut gf dan merupakan versi yang ditingkatkan grep. Dalam kasus ini, menggunakan gfopsi saat memulai truffleHogatau, dalam varian lain tulisannya trufflehog, memungkinkan alat untuk menemukan string dengan entropi tinggi yang merupakan kunci ke API. Hal yang sama berlaku untuk pencarian stringAPI_KEY... Hasil pencarian untuk string seperti itu seringkali (terlalu sering) berhasil.
Seringkali terdapat alasan yang sangat normal untuk menampilkan kunci dalam kode, tetapi kunci tersebut tidak dilindungi dari pihak luar. Izinkan saya memberi Anda sebuah contoh. Satu klien tempat saya bekerja menggunakan layanan informasi peta eksternal. Ini dilakukan di banyak proyek. Untuk memuat informasi peta dan bekerja dengannya, Anda perlu melakukan panggilan ke API yang sesuai menggunakan kunci. Tetapi klien saya lupa mengonfigurasi layanan yang dia gunakan untuk membatasi sumber dari mana layanan itu dapat menerima permintaan menggunakan kunci khusus itu. Tidak sulit untuk membayangkan serangan sederhana, yang terdiri dari menghabiskan kuota penggunaan sumber daya dari layanan peta dengan mengirimkan banyak permintaan ke sana. Ini dapat menghabiskan banyak uang bagi pengguna layanan semacam itu. Atau,bahkan "lebih baik" (dari sudut pandang penyerang), serangan semacam itu dapat mengarah pada fakta bahwa bagian-bagian dari proyek klien yang terkait dengan kartu, hanya "jatuh".
File JS digunakan oleh peretas untuk lebih dari sekadar menemukan data rahasia. Bagaimanapun, file tersebut adalah kode aplikasi Anda, yang dapat dilihat oleh siapa saja yang tertarik dengan kode ini. Seorang peretas yang baik dapat, setelah membaca kode dengan cermat, memahami pendekatan penamaan entitas yang digunakan di dalamnya, menemukan jalur ke API, dan dapat menemukan komentar berharga. Temuan seperti ini diformat sebagai daftar kata yang dikirim ke pemindai otomatis. Inilah yang disebut "pemindaian otomatis cerdas", di mana seorang peretas menggabungkan alat otomatis dan informasi yang dikumpulkannya tentang proyek tertentu.
Berikut adalah komentar nyata dari halaman beranda salah satu proyek, yang berbicara dalam teks biasa tentang API tidak aman yang datanya dapat diperoleh siapa saja:
/* Debug ->
domain.com/api/v3 not yet in production
and therefore not using auth guards yet
use only for debugging purposes until approved */
▍Apa yang harus dilakukan?
- . . , , .
- API. , . , .
- , , . , , , , , , . , .
- , . . , .
grepgf. . , , . - -. , - . 100% . - — .
, -
Arsip Internet (juga dikenal sebagai "Mesin Wayback") menyimpan snapshot situs web secara berkala. Proyek ini memungkinkan Anda untuk melihat seperti apa Internet beberapa tahun yang lalu. Data arsip sangat menarik bagi peretas yang perlu mengumpulkan informasi tentang proyek tertentu. Anda dapat memindai file untuk varian lama situs web menggunakan alat seperti waybackurl (berdasarkan waybackurls.py ). Artinya, meskipun Anda menemukan kunci di kode situs dan menghapusnya dari sana, tetapi tidak merotasi kuncinya, peretas dapat menemukan kunci ini di versi lama situs dan menggunakan kunci ini untuk meretas sistem.
Inilah yang harus dilakukan jika Anda menemukan kunci di tempat yang tidak semestinya:
- Buat kunci yang dirancang untuk menggantikan kunci yang disusupi.
- Lepaskan versi baru kode yang menggunakan kunci baru. Kode ini harus ditulis ulang sehingga tidak ada baris di dalamnya yang memudahkan untuk mengidentifikasi kuncinya.
- Hapus atau nonaktifkan kunci lama.
▍ Arsip Internet bukan satu-satunya tempat untuk menemukan kunci
Kode lama memberi penyerang berbagai macam informasi yang menarik minat mereka.
- Jalur rahasia API. Kita berbicara tentang titik akhir API tidak aman yang menurut pengembang tidak akan pernah dibagikan. Meskipun jalur yang ditemukan peretas mungkin tidak berguna bagi mereka, jalur ini dapat membantu dalam memahami desain API proyek dan konvensi API-nya. Setelah kode situs diproduksi, pengembang tidak memiliki cara untuk menyembunyikan kode ini dari pengintip. Sangat penting untuk mengingat ini.
- -. , API, . , . , , . , -. , , . , , . ,
shttps.
GitHub
GitHub adalah tambang emas bagi para peretas. Jika Anda tahu di mana mencarinya, Anda dapat menemukan banyak hal menarik menggunakan alat pencarian sederhana. Jika akun GitHub organisasi Anda tidak dilindungi oleh autentikasi multi-faktor, maka semua karyawan organisasi, tanpa kecuali, akan melewati celah keamanan. Sangat mungkin bahwa beberapa karyawan menggunakan kata sandi yang sama di mana-mana, dan kata sandi ini telah dicuri dari mereka melalui sistem lain. Seorang peretas yang tertarik pada organisasi tertentu dapat dengan mudah mengotomatiskan pencarian kata sandi yang disusupi, tetapi apa yang bisa saya katakan, dia dapat menemukan kata sandi semacam itu secara manual.
Daftar karyawan organisasi dapat dibuat menggunakan teknik kecerdasan sumber terbuka (OSINT). LinkedIn atau daftar publik karyawan perusahaan dari GitHub dapat membantu penyerang dalam hal ini.
Jika, misalnya, seseorang memutuskan untuk meretas Tesla, dia mungkin akan mulai mempelajari perusahaan tersebut dari halaman ini:
https://api.github.com/orgs/teslamotors/members
Dan bahkan jika sebuah perusahaan tidak menggunakan GitHub sebagai platform git, masih ada sesuatu yang berharga untuk ditemukan di GitHub. Sudah cukup setidaknya satu karyawan perusahaan menggunakan platform ini, misalnya, untuk proyek rumah. Jika sesuatu yang rahasia tentang sebuah perusahaan muncul di kode proyek ini (atau dalam sejarah git), ini akan cukup untuk menembus sistem perusahaan ini.
Melacak riwayat lengkap perubahan yang dibuat untuk setiap proyek adalah sifat dari git. Mengingat masalah keamanan, fakta ini memainkan peran besar. Dengan kata lain, setiap perubahan yang dilakukan pada kode oleh siapa pun yang memiliki akses ke salah satu sistem organisasi menempatkan organisasi tersebut dalam risiko.
▍Mengapa ini terjadi?
- Perusahaan tidak memeriksa kerentanan sistem mereka.
- , , .
- , , ( , , 1%), ( — git, , , ).
- , . .
▍ GitHub
Ada yang namanya "dorks" - kueri penelusuran khusus yang menggunakan kemampuan berbeda dari mesin telusur untuk menemukan apa yang terkait dengan data tertentu. Berikut adalah daftar menarik dari pencarian serupa untuk Google oleh exploit-db.com.
Jika Anda ingin mendalami topik ini lebih dalam, dan saya sarankan Anda melakukannya, maka sebelum memberi Anda daftar singkat string yang digunakan untuk menemukan kunci dan kata sandi di GitHub, saya sarankan Anda membaca materi berharga ini , yang ditulis oleh peneliti keamanan sistem yang berbakat. Dia berbicara tentang bagaimana, apa dan di mana mencari di GitHub, bagaimana menggunakan dorks, dan menguraikan secara rinci proses manual untuk menemukan data rahasia.
Jalan yang digunakan di GitHub tidak serumit yang digunakan di Google. Intinya adalah, GitHub tidak menawarkan kepada pengguna kemampuan pencarian lanjutan yang sama seperti yang dilakukan Google. Apapun itu, pencarian yang tepat dari repositori GitHub dapat menghasilkan keajaiban. Coba cari di repositori yang Anda minati untuk baris berikut:
password
dbpassword
dbuser
access_key
secret_access_key
bucket_password
redis_password
root_password
Dan jika Anda mencoba mencari file tertentu menggunakan kueri seperti
filename:.npmrc _authatau filename:.htpasswd, maka Anda dapat memfilter hasil pencarian berdasarkan jenis kebocoran data. Ini bagian bagus lainnya tentang topik ini.
▍Tindakan mitigasi risiko yang terkait dengan GitHub
- Jadikan pemindaian kode Anda untuk mengetahui kerentanan sebagai bagian dari proses CI. Alat GitRob yang luar biasa dapat membantu Anda dalam hal ini .
- . GitRob . ,
no-expand-orgs. - . GitRob, , 500 , ,
-commit-depth <#number>. - GitHub !
- , , , , . G Suite Active Directory. , .
Setelah materi ini diterbitkan, beberapa pembacanya memberikan komentar berharga mengenai kompleksitas kata sandi dan rotasi mereka, serta penggunaan perlindungan informasi perangkat keras.
Berikut komentar @ codemouse92 :
Gunakan kata sandi yang kompleks dan unik di mana pun kata sandi logon digunakan. Namun perlu diingat bahwa kata sandi yang rumit belum tentu merupakan kata sandi yang membingungkan antara huruf, angka, dan karakter khusus. Strategi terbaik sekarang adalah menggunakan frase panjang sebagai kata sandi. Saya ingin membuat satu catatan tentang pengelola kata sandi. Meskipun program semacam itu pasti bermanfaat, masih lebih baik menggunakan kata sandi, yang merupakan frasa yang diingat dan dapat dimasukkan pengguna sendiri.
Inilah yang dikatakan pengguna @corymcdonald :
Di tempat saya bekerja, setiap orang diberikan perangkat keras otentikasi multifaktor. Masing-masing memiliki 2 perangkat YubiKey. Selain itu, setiap tim menggunakan pengelola kata sandi 1Password, dan setiap tim memiliki brankas kata sandinya sendiri. Ketika seorang karyawan meninggalkan perusahaan, tim dukungan merotasi kata sandi di setiap brankas yang dapat diakses oleh karyawan tersebut. Secara pribadi, misalnya, saya membuat kesalahan yang tidak bisa dimaafkan dengan mengunggah kunci untuk mengakses AWS di GitHub. Anda disarankan untuk memeriksa barang Anda menggunakan git-secret sebelum melakukannya . Ini akan mencegah apa yang tampak seperti informasi rahasia dibagikan.
Peretas menggunakan Google
Sekarang setelah kita memiliki pemahaman dasar tentang dorks, kita dapat berbicara tentang penggunaan kueri penelusuran tertentu di Google. Di sini Anda dapat menemukan hal-hal luar biasa dengan bantuan mereka. Google adalah mesin pencari canggih yang memungkinkan Anda membuat kueri dengan mendeskripsikan string yang harus dan tidak boleh ada dalam data yang Anda cari. Google, antara lain, memungkinkan Anda untuk mencari file dengan ekstensi tertentu, dapat mencari domain tertentu, URL. Perhatikan string pencarian berikut:
"MySQL_ROOT_PASSWORD:" "docker-compose" ext:yml
String ini dirancang untuk mencari file berekstensi
yml, terlebih lagi, ini adalah file docker-composeyang sering digunakan developer untuk menyimpan sandi. Bukan sandi yang sangat unik. Coba jalankan pencarian Google untuk string ini. Anda akan terkejut dengan apa yang Anda temukan.
String pencarian menarik lainnya mungkin mencari kunci RSA atau kredensial AWS. Berikut contoh lainnya:
"-----BEGIN RSA PRIVATE KEY-----" ext:key
Di sini, kemungkinan tak terbatas terbuka di hadapan kita. Kualitas pencarian hanya bergantung pada tingkat kreativitas peneliti dan seberapa baik dia mengenal berbagai sistem. Berikut daftar besar Google Dorks jika Anda ingin bereksperimen.
Peretas meneliti sistem yang mereka minati
Ketika seorang peneliti keamanan (atau peretas yang termotivasi) sangat tertarik pada sistem tertentu, dia mulai mempelajari sistem tersebut secara mendalam. Dia mengenalnya lebih dekat. Dia tertarik pada titik akhir API, konvensi penamaan untuk entitas, kekhasan interaksi bagian internal sistem, ketersediaan akses ke berbagai versi sistem jika versi yang berbeda digunakan secara bersamaan.
Pendekatan yang tidak terlalu bagus untuk mengamankan API adalah dengan mempersulit jalur untuk mengaksesnya, menyembunyikannya menggunakan sesuatu seperti generator karakter acak. Ini bukan pengganti mekanisme keamanan nyata. Peneliti keamanan mencoba menemukan jalur akses yang tidak aman ke sistem, titik akhir API, misalnya, menggunakan alat untuk pencarian kerentanan yang "kabur". Alat tersebut menggunakan daftar kata, membuat jalur darinya, dan menguji jalur tersebut dengan menganalisis respons yang mereka terima saat mencoba mengaksesnya. Pemindai seperti itu tidak akan menemukan titik akhir, jalur yang diwakili oleh sekumpulan karakter yang benar-benar acak. Tetapi alat semacam itu hebat dalam mengidentifikasi pola dan menemukan titik akhir yang mungkin dilupakan atau tidak pernah diketahui oleh pemilik sistem.
Ingatlah bahwa "keamanan melalui ketidakjelasan" bukanlah cara terbaik untuk melindungi sistem (meskipun Anda tidak boleh mengabaikannya sepenuhnya).
Di sinilah para dork GitHub, yang telah kita bicarakan di atas, datang membantu para penyerang. Mengetahui aturan apa yang digunakan saat membangun jalur ke titik akhir sistem (misalnya, sesuatu seperti
api.mydomain.com/v1/payments/...) dapat sangat membantu peretas. Menelusuri repositori GitHub perusahaan (dan repositori karyawannya) untuk string terkait API akan sering menemukan jalur yang menyertakan karakter acak.
Tapi "string acak", bagaimanapun, memiliki tempatnya dalam sistem. Penggunaannya selalu lebih baik daripada menggunakan urutan dari pengenal sumber daya, string seperti
usersdan di jalur ke API orders.
Ini adalah repositori SecLists yang luar biasa, yang berisi banyak string yang digunakan saat memberi nama entitas. Ini digunakan oleh hampir semua orang di industri perlindungan data. Seringkali bahan ini dimodifikasi untuk sistem tertentu. Alat lain yang dapat digunakan untuk menemukan jalur "terenkripsi" adalah FFuf , program logika fuzzy yang sangat cepat yang ditulis dalam Go.
Hasil
Masalah keamanan sering kali diabaikan saat memulai. Pemrogram dan manajer biasanya memprioritaskan kecepatan pengembangan dan frekuensi rilis produk, mengorbankan kualitas dan keamanan. Di sini kita melihat penyertaan informasi rahasia dalam kode yang masuk ke repositori, penggunaan kunci yang sama di tempat berbeda dalam sistem, penggunaan kunci akses di mana Anda dapat menggunakan sesuatu yang lain. Kadang-kadang mungkin terlihat bahwa sesuatu seperti ini memungkinkan Anda untuk mempercepat pekerjaan pada proyek, tetapi seiring waktu, hal itu dapat menyebabkan konsekuensi yang sangat buruk.
Dalam posting ini, saya mencoba menunjukkan kepada Anda bagaimana string yang tampaknya dilindungi dengan disimpan di repositori pribadi dapat dengan mudah go public. Hal yang sama berlaku untuk klon repositori, dibuat oleh karyawan yang bermaksud baik dan tidak dimaksudkan untuk mengintip, tetapi ternyata untuk publik. Namun, Anda dapat membangun fondasi untuk operasi yang aman dengan menggunakan alat berbagi kata sandi yang aman, menggunakan penyimpanan rahasia yang terpusat , mengonfigurasi kebijakan keamanan kata sandi, dan autentikasi multi-faktor. Ini akan memungkinkan, tanpa mengabaikan keamanan, untuk tidak memperlambat kecepatan pengerjaan proyek.
Dalam hal perlindungan informasi, gagasan bahwa kecepatan adalah hal terpenting tidak berjalan dengan baik di sini.
Memperoleh pengetahuan tentang cara kerja peretas biasanya merupakan langkah pertama yang sangat baik untuk memahami apa itu keamanan informasi. Ini adalah langkah pertama untuk mengamankan sistem. Saat mengamankan sistem, pertimbangkan metode di atas untuk menembusnya, dan fakta bahwa peretas menggunakan metode yang cukup terbatas. Direkomendasikan untuk mempertimbangkan dari sudut pandang keamanan secara mutlak segala sesuatu yang dalam satu atau lain cara terkait dengan sistem tertentu, terlepas dari apakah itu tentang mekanisme eksternal atau internal.
Keamanan sistem terkadang dianggap tidak terlalu penting, tetapi memakan waktu dan kesibukan. Namun yakinlah, langkah sederhana yang Anda lakukan untuk mengamankan sistem dapat menyelamatkan Anda dari banyak masalah.
Bagaimana Anda melindungi sistem Anda?
