- Kalian keren! Jadi belum ada yang mengecewakan kita!
- Kami sudah mencoba.Ya, kehidupan pemburu kerentanan penuh dengan pujian khusus dari pelanggan dan situasi yang tidak kalah spesifik. Selama setahun terakhir, kami telah menyelesaikan lebih dari lima puluh tes penetrasi di berbagai perusahaan dan, harus dikatakan, telah melihat segalanya. Satu kata sandi untuk semua akun dan sistem, penyimpanan kata sandi yang terbuka dalam database, sisa-sisa fungsi debugging di lingkungan pertempuran ... Oleh karena itu, ketika kolega kami dari JSOC CERT
menceritakan beberapa kisah tentang investigasi insiden cyber, kami di departemen Pentest memutuskan untuk mengikuti dan menunjukkan sisi lain dari "barikade" ยป: Infrastruktur pelanggan melalui mata seorang peretas. Hari ini kami akan memberi tahu Anda tentang pentest eksternal paling menarik dalam beberapa waktu terakhir, ketika kami harus menembus batas internal pelanggan, hanya memiliki daftar alamat IP eksternal dan nama domainnya.
Odyn
Senin:
- Guys, mulai lebih cepat dengan pentest - Anda hanya punya 3 minggu untuk meretas kami. Tetapi perlu diingat bahwa peluang Anda minimal: mereka memeriksa kami setiap tahun dan tidak menemukan petunjuk.
Setelah 4 jam:
"Kita sudah di dalam."
- Ayo? Tidak mungkin seperti itu! Sekarang mari kita periksa log ...
Jumat:
- Sial, sungguh. Bagaimana bisa ?! Tetapi karena waktu tidak berhasil, mungkin Anda akan mencari sesuatu yang lain?
- Ya, tidak ada pertanyaan.
Dan kami mulai mencari. Memindai perimeter organisasi, kami menemukan sebuah host di mana 4 aplikasi web berputar, server FTP, dan panel admin phpMyAdmin digantung. Analisis aplikasi web tidak mengungkapkan kerentanan kritis (misalnya, injeksi SQL, XXE, RCE, dll.) Yang memungkinkan kami mengakses server. Di beberapa titik mereka beralih ke FTP - dan di sini sudah lebih menarik: akses anonim dibuka di server, tetapi hanya untuk membaca.

Selama beberapa hari, kami memeriksa konten server dan menemukan beberapa baris aneh di log - beberapa kata sandi dimasukkan dengan salah untuk admin aplikasi web.

Berdasarkan opsi yang salah, kami membuat asumsi tentang seperti apa kata sandi itu, dan muncul. Kami memutuskan untuk mencobanya untuk phpMyAdmin, dan - oh, keajaiban - juga muncul. Selanjutnya, itu masalah kecil - unggah shell, akses jaringan internal, dapatkan pijakan di sana dan kembangkan di dalamnya.

Inilah kemalasan yang biasa (dan bagaimana cara lain untuk menjelaskan keengganan untuk memasukkan kata sandi yang berbeda untuk setiap panel admin?) Membuka jalan bagi peretas ke jaringan internal organisasi.
Mengapa men-debug di lingkungan pertempuran?
Sebagian besar terobosan kami terjadi melalui aplikasi web, dan sering kali kami menemukan "sisa" pengembangan dan pengujian yang aneh. Seringkali kita menemukan log, beberapa mode debug, tetapi tidak selalu dengan bantuannya kita berhasil melakukan RCE (eksekusi kode jarak jauh).
Selama salah satu klien kami, kami menemukan sistem CRM, yang kami putuskan untuk menghabiskan lebih banyak waktu (dan, harus saya katakan, itu kemudian terbayar). Melakukan analisis aplikasi, kami menemukan sisa-sisa tes, yang, tampaknya, digunakan pada tahap pengembangan. Otentikasi terjadi pada mereka dengan cara yang sangat ajaib: hanya nama pengguna dan fakta melewati parameter yang mengandung beberapa kata sandi yang diperiksa. Lima menit mencari dan membaca dokumentasi standar - dan kami memiliki di tangan kami nama akun pengguna super bawaan. Mengisi shell sudah menjadi masalah teknologi.

Contoh lain. Pada awal proyek, kami meluncurkan bruteforce rekursif dari subdomain dan meninggalkannya. Setelah beberapa waktu, yang mengejutkan kami, subdomain tingkat kelima yang disebut test.debug.application.client.ru muncul, di mana kami menemukan aplikasi web dengan Adminer diinstal di sana. Ini adalah aplikasi administrasi basis data yang ringan, di versi yang lama, dengan pengaturan yang salah, Anda dapat berinteraksi dengan basis data SQLite tanpa kata sandi.
Fakta bahwa tidak ada data dalam database ini tidak penting - lagipula, dalam SQLite Anda dapat membuat database pada jalur arbitrer dengan shell web sederhana di dalamnya, sehingga mendapatkan kemampuan untuk mengelola server dengan mudah dan menjalankan perintah di atasnya dari halaman web.
Yang tersisa hanyalah mencari tahu alamat lengkap aplikasi web di server. Di sini kami dibantu oleh semua CMS 1C-Bitrix "tercinta", yang, dalam pesan kesalahan, dengan senang hati berbagi dengan kami di mana ia berada. Kemudian tinggal mengisi shell dan menyelesaikan proyek.

Bekerja dengan DB SQLite dapat dilihat di
sini .
Ditemukan log? Kata sandi sebagai hadiah!
Seorang pelanggan meminta kami melakukan pentest aplikasi web. Selama tiga tahun sebelumnya, ia mengadakan pentest dengan tim lain dan mungkin berhasil menambal beberapa lubang di perimeter, jadi kami tidak mengharapkan kesuksesan cepat.
Selama fuzzing aplikasi web, kami menemukan halaman di mana otorisasi pengguna dicatat. Waktu dan login pengguna yang masuk ke aplikasi ditampilkan di log. Kami menulis sebuah skrip yang beberapa menit sekali menyurvei halaman ini, mem-parsing respons dan menuliskan login yang ditemukan dalam file. Setelah beberapa hari, kami berhasil mengumpulkan sekitar seratus login. Kami memutuskan untuk memulai pemilihan kata sandi - untuk 5 login mereka ditemukan dalam daftar
kata sandi terburuk TOP-500 .
Setelah mendapatkan akses ke aplikasi, kami terus menganalisisnya dan menemukan file lain yang menarik - semua permintaan basis data waktu nyata ditampilkan di dalamnya. Dengan alat debugging yang nyaman seperti itu, mencari kerentanan dan mengeksploitasi
injeksi SQL Boolean-Timebased yang ditemukan
telah menjadi tugas yang sepele.
Terlepas dari kenyataan bahwa ini sudah 2019, orang masih percaya bahwa menyimpan kata sandi dalam database dalam bentuk terbuka adalah ide yang bagus. Kami menggunakan ini dan menemukan injeksi SQL dan mendapatkan akun administrator untuk mengisi shell web dan membuka akses ke jaringan internal organisasi itu bukan masalah besar.
Tanda pangkas
Pertama, lakukan pengujian penetrasi berkala - mereka akan membantu Anda menemukan titik-titik tipis yang mungkin Anda lewatkan pada tahap pengembangan atau ketika beralih dari lingkungan pengujian ke yang memerangi.
Kedua, selalu pertimbangkan faktor manusia: orang terlalu malas untuk mengubah kata sandi, dan mereka bahkan dapat menggunakan satu kata sandi di beberapa situs. Ya, admin juga melakukan dosa ini.
Ketiga, hapus mode debugging di lingkungan pertempuran.
PS
Secara umum, kehidupan sehari-hari departemen Pentest penuh dengan semua jenis "hiburan" dan, tentu saja, tes eksternal bukan satu-satunya. Pelanggan mungkin ingin memeriksa kerentanan perimeter internal (pentest internal), atau menganalisis keamanan aplikasi web dan seluler, serta jaringan WiFi, atau mengatur agar karyawan memeriksa menggunakan metode rekayasa sosial.
Di waktu luang kami dari proyek, kami
memahami Zen, mencari kerentanan baru, meningkatkan alat dan teknik kami. Dan kami terlibat dalam bugbounty (di mana tanpanya).
Anda akan belajar tentang keragaman "petualangan" kami di posting berikut.