Para peneliti telah menemukan cara untuk mendeteksi dan memotong kunci Honeytoken di sejumlah layanan Amazon.

Dalam paradigma modern keamanan informasi untuk massa, kepercayaan bahwa keamanan cyber mahal, sulit, dan hampir tidak mungkin bagi pengguna rata-rata, telah mapan. Jadi jika Anda ingin sepenuhnya melindungi data dan informasi pribadi Anda, maka buat akun dengan Google atau Amazon, tempelkan dalam hal mengidentifikasi pemilik dan secara berkala memeriksa peringatan alarm bahwa perusahaan besar dan kuat telah menghentikan upaya login lain.

Tetapi orang-orang yang berpengetahuan luas dalam keamanan informasi selalu tahu: layanan cloud jauh lebih rentan daripada stasiun kerja terpisah. Memang, jika terjadi keadaan force majeure, PC secara fisik dapat membatasi akses ke jaringan, dan di sana perlombaan untuk mengubah tampilan dan kata sandi di semua area yang diserang sudah dimulai. Infrastruktur cloud sangat besar, seringkali terdesentralisasi, dan data beberapa klien dapat disimpan pada media fisik yang sama, atau sebaliknya, data satu klien tersebar di lima benua, dan hanya akun yang menggabungkannya.

Singkatnya, ketika Internet relatif segar dan muda (dan itu pada tahun 2003), maka para pakar keamanan informasi dengan hati-hati melihat sistem buffer buffer overflow protection 1997, dan berkembang menjadi teknologi, yang sekarang kita sebut Honeytoken atau Canarytoken. Dan selama lima belas tahun mereka telah bekerja dengan baik (dan masih bekerja), hanya penelitian terbaru yang mengatakan bahwa alih-alih garis pertahanan terakhir di sejumlah layanan AWS, Honeytoken berubah menjadi lubang menganga dalam keamanan informasi karena kekhasan implementasi di sisi Amazon.

Apa itu Honeytoken?

Honeytoken, seperti leluhur leluhur ideologisnya dalam sistem perlindungan overflow tumpukan, menggunakan pendekatan "peringatkan, jangan cegah". Bahkan, Honeytoken adalah umpan bagi penyerang, yang dibiarkan dengan kedok informasi yang berharga dan dapat disajikan dalam bentuk, misalnya, sebuah tautan. Honeytoken yang paling jelas dalam praktik pengguna biasa adalah tautan-alarm, disembunyikan dalam surat dengan tajuk "informasi rekening bank" atau "rekening saya". Prinsipnya juga sederhana: begitu penyerang melihat informasi yang berpura-pura menjadi Honeytoken, penyerang mengirimkan peringatan kepada pemilik / administrator bahwa perimeter keamanan telah dilanggar.

Honeytoken itu sendiri jelas tidak termasuk dalam perimeter: dalam bentuk klasiknya, itu adalah boneka dangkal yang sudah ada di dalam perimeter dan memainkan peran yang sama dengan burung kenari yang sekarat di kandang yang dimainkan di wajah pertambangan - peringatan tentang bahaya.


Dan inilah nenek moyang teknologi

"Sistem pensinyalan" seperti itu sekarang cukup umum dan digunakan untuk mengingatkan pemegang akun pribadi untuk mengingatkan tentang pelanggaran keamanan AWS. Pada saat yang sama, tidak ada standar Honeytoken tunggal - itu bisa apa saja. Sebagai contoh, beberapa kotak surat mati khusus ditambahkan ke daftar alamat email klien, tampilan dari mailing list yang akan menunjukkan pembuangan seluruh database.

Apa kerentanan yang ditemukan di AWS?

Amazon Web Services secara ekstensif menggunakan sistem Honeytokens untuk menerima peringatan layanan cloud perimeter. Amazon Canaries adalah kunci akses akun palsu. Alat ini, dengan segala kesederhanaannya, sangat penting: layanan cloud menjadi sasaran upaya peretasan yang konstan dan serangan lainnya. Fakta memiliki pengetahuan tentang "terobosan" perimeter keamanan siber AWS di salah satu arah sudah setengah kemenangan bagi insinyur Amazon.

Kemarin, 2 Oktober 2018, spesialis dari Rhino Security Labs menerbitkan penelitian yang sangat tidak menyenangkan, esensi yang diungkapkan oleh pernyataan berikut: Honeytokens Amazon Web Services dapat dielakkan tanpa mengganggu sistem pensinyalan cloud. Ini memberi penyerang kesempatan untuk diam-diam "masuk", "mengambil" apa yang mereka butuhkan dan juga diam-diam "pergi".

Seluruh arsitektur Honeytokes AWS didasarkan pada penggunaan kunci palsu bersama dengan CloudTrail , yang juga menyimpan log aktivitas. Tetapi tersedia secara gratis di Amazon userguide ada daftar seluruh alamat dan layanan yang tidak mendukung CloudTrail. Bahkan, ini berarti bahwa setiap permintaan ke layanan ini, termasuk melalui API, tidak terdaftar di mana pun. Pada saat yang sama, Amazon mengembalikan pesan yang dikembalikan dengan kesalahan akses bersama dengan ARN .

Selanjutnya, peneliti dari Rhino Security "mengetuk" AWS AppStream melalui DescribeFleets API dan menerima informasi berikut tentang akun pengujian:



Kemudian, dengan bantuannya, seorang penyerang mengekstrak informasi tentang pengguna / peran IAM dari rencana berikut:
IAM User:
arn:aws:iam::111111111111:user/the-path/TheUserName

IAM Role:
arn:aws:iam::111111111111:role/the-path/TheRoleName/TheSessionName

Hasilnya, berkat pengembalian ARN dan data pengguna / peran IAM yang diterima, spesialis dapat mengkompromikan kunci umpan Honeytokes pada layanan di atas melalui penguraian.

Penanggulangan

Jalur yang ditemukan tidak hanya membuat AWS, tetapi juga pengembang sistem honeytoken populer untuk sistem Amazon seperti CanaryToken dan SpaceCrab dalam bahaya . Kedua pengembang telah diberitahu dan sedang mengambil semua langkah yang mungkin untuk menyelesaikan masalah.

Juga, para ahli dari Rhino Security menerbitkan skrip PoC di GitHub yang akan memeriksa apakah kunci AWS yang diberikan kepada Anda adalah token, karena tidak semua konfigurasi telah diperbarui.

Reaksi Amazon

Amazon melaporkan ke Lab Keamanan Badak bahwa ARN bukan informasi sensitif, CloudTrain berfungsi (dan tidak berfungsi) di mana diperlukan, dan tidak ada masalah seperti itu.