Zero Day Threat adalah istilah untuk kerentanan pembangunan yang belum ditemukan. Kerentanan semacam itu dapat dieksploitasi oleh penjahat cyber, yang pada akhirnya akan mempengaruhi reputasi perusahaan. Pengembang dihadapkan pada tugas meminimalkan jumlah cacat dalam kode yang dapat menyebabkan kerentanan seperti itu. Salah satu alat untuk membantu mengidentifikasi kelemahan keamanan adalah penganalisis kode statis PVS-Studio untuk C, C ++, C #, Java.
Ancaman nol hari
Ancaman zero-day adalah istilah yang mengidentifikasi kesenjangan dan kerentanan yang diizinkan oleh pengembang, tetapi belum ditemukan. Hingga kerentanan diperbaiki, dapat digunakan untuk mengakses jaringan, mengontrol komputer dari jarak jauh, memanipulasi data, dll. Nama istilah ini sudah mapan karena fakta bahwa pengembang tidak punya waktu untuk memperbaiki cacat, karena belum ada yang tahu tentang itu. Pada waktunya, perusahaan besar dan peranti lunak seperti
Adobe ,
Windows ,
peramban Tor , dan banyak lainnya menderita kerawanan tersebut.
Beberapa organisasi beruntung, kerentanan mereka ditemukan oleh orang-orang yang tidak akan menggunakannya, dan mereka hanya memberikan informasi tentang masalah tersebut. Misalnya, ini dengan
MacOS . Atau ada pembaruan yang, selain fitur baru, juga secara tidak sengaja memperbaiki ancaman zero-day.
Namun, ada situasi lain. Sebagai contoh, Google Chrome pada suatu waktu sangat mendesak untuk memperbaiki
kerentanan yang memungkinkan penyerang untuk mengeksekusi kode arbitrer dari jarak jauh pada perangkat korban.
Masalah dengan ancaman ini adalah bahwa tidak mungkin untuk bertahan melawannya 100%, karena sulit untuk mempertahankan diri terhadap apa yang belum Anda ketahui. Namun, ada cara untuk mengurangi kemungkinan ancaman seperti itu dalam proyek Anda, dan kami akan membahasnya nanti, tetapi untuk memulai dengan sedikit teori.
Analisis statis
Analisis kode statis adalah proses pengecekan kode program oleh penganalisa tanpa memulai program itu sendiri. Analisis statis dapat dianggap sebagai proses peninjauan kode otomatis. Dalam beberapa kasus, efektivitas analisis statis lebih unggul daripada tinjauan kode, tetapi tidak dapat dianggap sebagai alternatif lengkap untuk tinjauan kode oleh beberapa programmer. Di bawah ini saya mencoba untuk menguraikan secara singkat pro dan kontra dari tinjauan kode dan analisis kode statis satu sama lain.
CVE dan CWE
Kerentanan dan Eksposur Umum (CVE) adalah basis data kesalahan perangkat lunak yang dapat digunakan oleh penjahat cyber. CVE dibuat untuk merampingkan cacat perangkat lunak yang dikenal. Sebagian besar alat keamanan informasi menggunakan database dan nama mereka sendiri, dan untuk menghilangkan kekacauan ini dan menambah kompatibilitas dengan berbagai alat, MITER pada tahun 1999 menciptakan CVE. Namun, CVE tidak cukup untuk mengevaluasi keamanan kode. Ini membutuhkan sesuatu yang lebih tepat, dengan deskripsi terperinci tentang masalah dan kurang kasar dari dia. Oleh karena itu, basis Weakness Enumeration (CWE) umum telah dibuat yang memenuhi persyaratan ini. Jika kesalahan ada di daftar CWE, maka kemungkinan akan menyebabkan kerentanan yang dapat dieksploitasi oleh penyerang dan masuk ke daftar CVE. Untuk kejelasan, Anda dapat melihat diagram Euler di bawah ini.
Beberapa analisis statis dapat memberi tahu pengembang bahwa, misalnya, proyek menggunakan pustaka tempat kerentanan ditemukan. Ini memungkinkan Anda untuk memilih versi perpustakaan yang lebih baru di mana kerentanan telah diperbaiki, dan mengurangi kemungkinan masalah dengan ancaman yang timbul dari kode orang lain.
Dengan perkembangan daftar CVE dan CWE, banyak alat keamanan informasi telah menjaga dukungan mereka, termasuk analisa statis. Analisis semacam itu dapat dianggap sebagai solusi SAST. SAST (Pengujian Keamanan Aplikasi Statis) memungkinkan pengembang untuk menemukan kerentanan dalam kode sumber aplikasi yang sudah dalam tahap awal siklus hidup pengembangan perangkat lunak.
Menggunakan SAST dalam pengembangan adalah pilihan lain untuk meminimalkan kemungkinan ancaman zero-day. Analisator, mengklasifikasikan kesalahannya menurut CWE, dapat mengetahui di mana kerentanan mungkin bersembunyi. Dan dengan memperbaiki kesalahan ini, pengembang membuat aplikasinya lebih dapat diandalkan dan mengurangi kemungkinan ancaman 0 hari.
Ada berbagai alat untuk pengujian keamanan statis. Untuk menunjukkan kemampuan dalam menangani kerentanan, marilah kita memikirkan alat
PVS-Studio . Peringatan dari penganalisa ini dapat diklasifikasikan sebagai CWE. Mari kita lihat beberapa contoh.
Peringatan PVS-Studio:
CWE-561 : Dead Code (
V3021 ).
public string EncodeImage(....) { if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("inputPath"); } if (string.IsNullOrWhiteSpace(inputPath)) { throw new ArgumentNullException("outputPath"); } .... }
Kode ini secara tidak sengaja membuat kesalahan ketik. Dalam dua kondisi
jika , variabel yang sama diperiksa. Dilihat oleh pengecualian yang dihasilkan, dalam kondisi kedua
outputPath variabel harus diperiksa. Akibatnya, bagian dari kode tidak dapat dijangkau.
Pandangan seperti itu kelihatannya tidak berbahaya pada pandangan pertama. Namun, kesan ini bisa sangat menyesatkan. Pertimbangkan kesalahan tidak berbahaya yang sangat sederhana dan sekilas terkait dengan duplikasi operator
goto .
Pada suatu waktu, kesalahan ini menyebabkan kerentanan pada sistem operasi iOS.
Deskripsi Kerentanan
CVE-2014-1266 : Fungsi SSLVerifySignedServerKeyExchange di libsecurity_ssl / lib / sslKeyExchange.c dalam fitur Transportasi Aman dalam komponen Keamanan Data di Apple iOS 6.x sebelum 6.1.6 dan 7.x sebelum 7.0.6, Apple TV 6.x sebelum 6.0.2, dan Apple OS X 10.9.x sebelum 10.9.2 tidak memeriksa tanda tangan di pesan TLS Server Key Exchange, yang memungkinkan penyerang man-in-the-middle untuk menipu server SSL dengan menggunakan sewenang-wenang kunci pribadi untuk langkah penandatanganan atau menghilangkan langkah penandatanganan.
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; .... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; .... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }
Karena
goto ganda, situasi dengan kode yang tidak terjangkau juga muncul. Terlepas dari kondisinya,
pernyataan kebagian kedua akan dieksekusi dalam pernyataan
if . Ini mengarah pada fakta bahwa verifikasi tanda tangan tidak terjadi. Fungsi mengembalikan 0, yang berarti semuanya baik-baik saja dengan tanda tangan, dan kemudian program menerima kunci dari server, bahkan jika ada masalah dengan tanda tangan. Kunci ini diperlukan untuk mengenkripsi data selama transmisi.
Konsekuensi dari kesalahan sederhana seperti itu sangat serius. Oleh karena itu, tidak masuk akal untuk berdebat betapa berbahayanya kesalahan ini atau itu diklasifikasikan sebagai CWE. Itu hanya perlu diperbaiki, sehingga membuat kode lebih aman.
By the way, kesalahan yang dijelaskan dapat dengan mudah dideteksi oleh penganalisa PVS-Studio. Dia akan memberikan dua peringatan CWE di sini segera:
Mari kita lihat contoh lain. Kembali pada tahun 2012, diketahui tentang masalah keamanan di MySQL, di mana penyerang dapat memasuki database MySQL. Saya akan memberikan potongan kode yang menjadi alasannya.
CVE-2012-2122 Keterangan : sql / password.c di Oracle MySQL 5.1.x sebelum 5.1.63, 5.5.x sebelum 5.5.24, dan 5.6.x sebelum 5.6.6, dan MariaDB 5.1.x sebelum 5.1.62, 5.2.x sebelum 5.2.12, 5.3.x sebelum 5.3.6, dan 5.5.x sebelum 5.5.23, ketika berjalan di lingkungan tertentu dengan implementasi tertentu dari fungsi memcmp, memungkinkan penyerang jarak jauh untuk memotong otentikasi dengan berulang kali mengotentikasi dengan yang sama kata sandi salah, yang akhirnya menyebabkan perbandingan token berhasil karena nilai pengembalian yang tidak diperiksa dengan benar.
typedef char my_bool; my_bool check_scramble(const char *scramble_arg, const char *message, const uint8 *hash_stage2) { .... return memcmp(hash_stage2, hash_stage2_reassured, SHA1_HASH_SIZE); }
Tipe
kembalinya fungsi
memcmp adalah int , dan tipe kembalinya dari fungsi
check_scramble adalah my_bool , pada kenyataannya,
char . Akibatnya, sebuah
int dilemparkan ke
char , di mana bit orde tinggi dibuang. Ini mengarah pada fakta bahwa dalam sekitar 1 kasus dari 256, dimungkinkan untuk terhubung dengan kata sandi, mengetahui nama pengguna.
Sekali lagi, kesalahan CWE ini dapat dinetralkan dan dicegah dari berubah menjadi CVE bahkan pada tahap penulisan kode. Sebagai contoh, analisa statis PVS-Studio menghasilkan peringatan berikut:
CWE-197 (
V642 ): Kesalahan Pemotongan Numerik.
Sebagai kelanjutan dari topik ini, saya mengusulkan untuk melihat artikel "
Bagaimana PVS-Studio dapat membantu dalam menemukan kerentanan? ".
Kesimpulan
Kerentanan 0-hari - suatu hal yang tidak ada jaminan perlindungannya. Tetapi kemungkinan terjadinya mereka dapat dikurangi secara signifikan. Untuk ini, solusi SAST khusus seperti PVS-Studio dapat digunakan. Jika proyek Anda mendeteksi kesalahan yang dapat diklasifikasikan sebagai CWE, maka Anda harus memperhatikannya dan memperbaikinya. Terlepas dari kenyataan bahwa hanya sejumlah kecil CWE yang akan mengisi daftar CVE dengan menghilangkan kesalahan CWE, Anda melindungi aplikasi Anda dari banyak ancaman potensial.
Tautan situs
- Unduh dan coba PVS-Studio
- Teknologi yang digunakan dalam penganalisa kode PVS-Studio untuk mencari kesalahan dan kerentanan potensial
- Klasifikasi peringatan PVS-Studio menurut Common Weakness Enumeration (CWE)
- Klasifikasi peringatan PVS-Studio menurut SEI CERT Coding Standard
Jika Anda ingin berbagi artikel ini dengan audiens yang berbahasa Inggris, silakan gunakan tautan ke terjemahan: Ekaterina Nikiforova.
PVS-Studio Static Analyzer sebagai Alat Perlindungan terhadap Kerentanan Zero-Day .