Selamat siang, para pembaca yang budiman. Nama saya Victor Burov, saya seorang pengembang di ISPsystem. Dalam posting terakhir saya berbicara tentang
alat untuk membuat autotests , hari ini saya akan berbagi pengalaman saya dalam mengotomatisasi pengujian keamanan.
Pada awalnya, kerentanan dalam produk dicari oleh karyawan yang terpisah. Pengujian manual membutuhkan banyak waktu dan tidak menjamin bahwa semua kerentanan akan ditemukan. Setelah memastikan hukum dasar pengujian, kami sampai pada kesimpulan bahwa itu bisa otomatis. Kemudian kami memutuskan untuk menulis utilitas yang akan memudahkan masa pakai tester, menghemat waktu dan memungkinkan Anda untuk memeriksa produk setelah setiap perubahan. Karena penguji bernama Lida, kami menamai aplikasi baru itu untuk menghormatinya. Secara umum, di perusahaan kami sudah menjadi tradisi untuk memanggil alat pengujian dengan nama penguji.
Setelah menganalisis utilitas pencarian kerentanan, saya sampai pada kesimpulan bahwa mereka semua perlu menentukan fungsi untuk memanggil dan parameter yang digunakan. Kami kembali memutuskan untuk memanfaatkan antarmuka terpadu dan merumuskan persyaratan untuk Lida.
Persyaratan Startup:
- Secara otomatis membangun daftar fungsi.
- Opsi pelengkapan otomatis.
- Membuat permintaan API.
- Analisis output data setelah melakukan fungsi.
- Cari kerentanan dalam data.
- Pembentukan laporan.
- Pengaturan fleksibel.
Untuk menyadari semua ini tidak mudah.
Implementasi
Lewati formulir dan daftar
Untuk menemukan kerentanan dalam suatu fungsi, itu harus dijalankan dengan melewati parameter yang diperlukan. Antarmuka kami dibangun berdasarkan daftar dan formulir, sehingga Anda dapat mengotomatiskan pengumpulan data dengan memproses xml-dokumen yang menggambarkan struktur elemen antarmuka.
Saya memutuskan untuk mulai merangkak dari menu utama, secara rekursif masuk ke semua daftar bersarang. "Lida" membuka daftar level pertama. Sebagai aturan, ia memiliki beberapa tombol yang memanggil beberapa fungsi.
Jika tombol membuka formulir, hasil panggilan akan menjadi dokumen-xml dengan node yang berisi informasi tentang bidang: nama, validator, rentang nilai yang valid. Berdasarkan informasi ini, nilai bidang dihasilkan. Misalnya, angka akan dihasilkan untuk int. Jika tidak ada validator, string acak dihasilkan. Setelah mengisi semua bidang formulir, permintaan dikirim.
Jika fungsi adalah daftar, maka akan terbuka dan fungsi yang terkait dengan tombol akan dipanggil untuk elemen-elemennya.
Saat memeriksa daftar, muncul masalah - semua daftar harus memiliki satu set catatan yang akan memastikan bahwa semua tombol dalam daftar dapat diklik.
Pencarian injeksi SQL
Injeksi SQL mungkin merupakan salah satu masalah paling umum untuk aplikasi, termasuk masalah kita. Banyak panggilan fungsi menghasilkan berbagai permintaan DBMS. Kesalahan terjadi ketika parameter yang berasal dari luar diganti ke badan permintaan "apa adanya". Konsekuensi dari kesalahan tersebut bisa menyedihkan: dari penerimaan data tanpa izin ke menghapus tabel.
Untuk memulai pencarian injeksi SQL, saya mengatur output dari semua query SQL ke file. Setelah fungsi dieksekusi, aplikasi mencari nilai-nilai parameter yang dikirimkan dalam query SQL yang dihasilkan.
Anda bisa menggunakan log dari server SQL itu sendiri. Namun dalam kasus kami, hanya ada satu metode untuk mengeksekusi kueri dan menambahkan logging ke itu tidak sulit. Berkat ini, kami tahu persis tantangan apa yang menghasilkan permintaan ini atau itu.Ketika nilai parameter yang diteruskan ditemukan, utilitas meneruskan nilai yang berisi kutipan tunggal ke parameter ini. Jika kutipan ditemukan dalam urutan yang sama, maka parameter tidak lolos - kami menemukan tempat untuk injeksi SQL.
Analisis Panggilan Sistem
Masalah serupa terjadi ketika kita melakukan panggilan sistem apa pun. Saya memutuskan untuk mencari mereka dengan strace dan memilih parameter peluncuran optimal untuknya. Contoh memulai ISPmanager:
strace -f -s 1024 -e trace=file,process bin/core ispmgr
Seperti halnya dengan injeksi SQL, Lida melakukan fungsi dan menganalisis output strace untuk menentukan apakah nilai-nilai parameter dilewatkan untuk
membuka, membatalkan tautan, rmdir, chmod chown, chflags, mknod, mkfifo, fcntl, symlink, tautan, jalankan, mkdir disertakan .
Jika parameter ditemukan, utilitas meneruskan nilai yang berisi, misalnya, jalur dengan transisi ke direktori di atas. Jika mendapat apa adanya, maka kerentanan potensial ditemukan.
Analisis fungsi execve ternyata sangat berguna. Ini memungkinkan Anda untuk menentukan di mana argumen fungsi untuk menjalankan file yang dapat dieksekusi tidak lolos. Kesalahan ini sangat mahal, karena melaluinya Anda bisa mendapatkan akses root ke server hanya dengan mengubah kata sandi.
Ketika pengguna menemukan kerentanan dalam produk kami, perusahaan membayar hadiah uang tunai, yang jumlahnya tergantung pada kategori kerentanan. Pendekatan ini bisa lebih murah daripada mencari kesalahan sendiri (penguji mungkin tidak menemukan kesalahan dan mendapatkan gaji).
Tes lain yang menarik: memeriksa urutan fungsi panggilan stat dan lainnya. Seringkali, akses diperiksa terlebih dahulu melalui stat, dan kemudian beberapa tindakan tidak aman, yang meninggalkan peluang untuk substitusi. Tapi kami tidak mengotomatiskan ini.Memeriksa akses ke objek asing
Kami memeriksa akses ke objek asing dari bawah pengguna untuk entitas pengguna dan administrator lain. Dalam mode ini, kami memeriksa kemampuan membaca, memodifikasi, dan melihat daftar elemen pengguna asing.
Lida mem-bypass semua fungsi yang tersedia atas nama pemilik atau administrator dan mengingat elemen-elemennya. Kemudian ia memanggil fungsi yang sama dengan elemen dari bawah pengguna lain. Dalam situasi yang ideal, jawabannya harus berupa kesalahan seperti Access atau Missed. Oleh karena itu, jika kesalahan semacam itu tidak diterima, kemungkinan besar Anda dapat membaca data pengguna orang lain.
Dalam beberapa kasus, tidak adanya kesalahan tidak berarti bahwa Anda dapat langsung mengakses objek pengguna lain. Di awal fungsi tersebut, kami menambahkan pemeriksaan izin elemen. Ini memeriksa tidak hanya keamanan, tetapi juga kebenaran tanggapan server.
Validasi API
Validasi API kami adalah bonus tambahan untuk fungsi pemeriksaan kerentanan. Menganalisis laporan tentang pekerjaan Lida, kami belajar untuk mengembalikan jenis kesalahan yang benar, membuat API kami lebih nyaman dan logis. Akibatnya, seperti halnya dengan tape recorder, kami menerima tidak hanya pemeriksaan keamanan, tetapi juga sekali lagi memeriksa API kami untuk "konsistensi".
Kesulitan
Positif palsu
Utilitas dapat bekerja dengan semua produk kami, oleh karena itu, ia memeriksa banyak fungsi yang berbeda. Pada dasarnya, false positive muncul dalam mode pemeriksaan akses ke objek asing. Ini karena fitur tombol dan fungsi.
Positif palsu adalah masalah terbesar Lida. Tampaknya itu benar-benar debugged, tetapi ketika memeriksa panel yang berbeda, positif palsu baru muncul. Akibatnya, ada beberapa tahap koreksi mereka.
Penciptaan Entitas
Sebagian besar tindakan di panel dilakukan pada entitas apa pun (nama domain, database, dll.). Untuk mencapai otomatisasi maksimum, Lida harus membuat entitas ini secara otomatis. Namun dalam praktiknya hal ini ternyata sulit diimplementasikan. Terkadang validasi dilakukan dalam kode, sehingga tidak selalu mungkin untuk mengganti nilai parameter secara otomatis. Alasan kedua adalah entitas dependen. Misalnya, untuk membuat kotak surat, Anda perlu membuat domain surat.
Karena itu, kami memutuskan untuk tidak memperjuangkan otomatisasi penuh. Sebelum memulai, tester membuat entitas secara manual dan mengambil snapshot dari mesin, karena entitas akan berubah setelah verifikasi. Ini memungkinkan Anda untuk tidak melewati memeriksa sekelompok fungsi jika terjadi kegagalan pembuatan entitas.
Memanggil fungsi yang merusak
Hampir setiap daftar memiliki fungsi untuk menghapus atau mematikan suatu entitas. Jika Anda menjalankannya secara berurutan, maka entitas akan dihapus sebelum melakukan fungsi lainnya. Saya mendefinisikan fungsi-fungsi tersebut dan melakukan setelah yang lain. Selain itu ditambahkan kunci yang melarang eksekusi fungsi-fungsi tersebut.
Beberapa fungsi me-reboot server. Mereka harus dilacak dan ditambahkan ke daftar diabaikan.
Karena sifat logika operasi, beberapa fungsi memulai ulang panel. Selama pengujian keamanan, ini menyebabkan panel untuk memulai tanpa melacak permintaan SQL atau strace - verifikasi lebih lanjut menjadi tidak berarti. Anda harus melacak ini dan memulai ulang panel dalam mode lacak.
Memeriksa parameter dependen
Pada formulir ada bidang untuk memasukkan teks, kotak centang, daftar drop-down, pada nilai-nilai yang ketersediaan nilai-nilai bidang lain bergantung. Setiap nilai bidang dependen dapat memiliki bagian kode yang terpisah, oleh karena itu, bagian ketika mereka tetap tidak diverifikasi.
Untuk mengatasi masalah ini, saya menambahkan algoritma untuk menganalisis bidang dependen dan memeriksa semua kombinasi kontrol dependen.
Memeriksa fitur yang tidak tersedia di antarmuka
Fungsi layanan tidak tersedia untuk transisi, tetapi mungkin mengandung kerentanan. Untuk mengidentifikasi dan memverifikasinya, kami memiliki fungsi khusus yang mengembalikan daftar semua fungsi yang terdaftar. Kami membandingkan daftar ini dengan daftar fungsi yang diuji. Tidak ada metadata untuk fungsi layanan, oleh karena itu tidak mungkin untuk memverifikasi parameter yang diproses di dalamnya.
Kesimpulan
Kami menyertakan Lida di setiap bangunan malam di Jenkins. Berdasarkan hasil kerjanya, laporan verifikasi dihasilkan, informasi tentang fungsi yang mencurigakan ditampilkan dengan semua parameter.
Tugas yang ditutup oleh pengembang sekarang diperiksa tidak hanya oleh tester, tetapi juga oleh Lida. Penguji memproses laporan yang diterima: menyalin parameter fungsi mencurigakan ke browser dan menganalisis perilaku dan panel log. Jika kerentanan dikonfirmasi, kesalahan dicatat ke pengembang.