Awalnya dikembangkan untuk browser, protokol SSL / TLS kemudian menjadi standar de facto untuk semua komunikasi Internet yang aman. Sekarang digunakan untuk administrasi jarak jauh dari infrastruktur virtual yang digunakan di cloud, untuk mentransfer rincian pembayaran pelanggan dari server e-commerce ke pemroses pembayaran seperti PayPal dan Amazon, untuk mengirim data lokal ke penyimpanan cloud, menyimpan korespondensi dalam pesan instan dan otentikasi server dalam aplikasi mobile iOS dan Android.

Daftar situasi di mana pertukaran informasi yang sangat sensitif membutuhkan keamanan maksimum cukup mengesankan. Dalam artikel ini, kita akan memeriksa bagaimana keamanan komunikasi ini dipastikan dalam praktiknya.

- Protokol SSL / TLS: mereka menginginkan yang terbaik ...
- ... tetapi ternyata seperti biasa: contoh gagal verifikasi sertifikat SSL / TLS
- Kerentanan logis dari protokol SSL / TLS
- Kerentanan implementasi protokol SSL / TLS umum lainnya
- Akar penyebab kerentanan dalam protokol SSL / TLS
- Satu sendok madu dalam satu tong tar

Protokol SSL / TLS: kami menginginkan yang terbaik ...

Secara teori, koneksi protokol SSL / TLS yang aman harus memastikan kerahasiaan, keandalan dan integritas komunikasi perangkat lunak klien dan server, bahkan di hadapan penyerang canggih aktif dari jaringan: ketika jaringan sepenuhnya diambil oleh musuh, DNS diracuni, dan titik akses dan router, switch dan WiFi dikendalikan oleh penyerang; penyerang yang, antara lain, mengontrol backend SSL / TLS. Selain itu, ketika perangkat lunak klien mencoba menyambung ke server yang sah, penyerang dapat mengubah alamat jaringan server (misalnya, melalui keracunan DNS), dan alih-alih server yang sah, mengarahkan klien ke server jahatnya.

Keamanan komunikasi dalam kondisi keras seperti itu, seperti yang Anda tahu, sepenuhnya bergantung pada kecukupan verifikasi sertifikat kriptografi yang disediakan oleh server ketika membuat koneksi. Termasuk kecukupan implementasi satu set cipher (ciphersuite), yang digunakan klien dan server saat bertukar data. Agar koneksi SSL / TLS sepenuhnya aman, perangkat lunak klien, antara lain, harus dengan hati-hati memverifikasi bahwa:

• sertifikat yang dikeluarkan oleh lembaga sertifikasi saat ini;
• masa berlakunya belum kedaluwarsa (atau sertifikat belum dicabut);
• daftar nama yang tercantum dalam sertifikat berisi domain tempat Anda terhubung.

... tetapi ternyata seperti biasa: contoh gagal verifikasi sertifikat SSL / TLS

Namun, di banyak aplikasi dan perpustakaan, yang keamanan komunikasinya sangat kritis, prosedur untuk memeriksa sertifikat SSL / TLS, dan bahkan EV-SSL, sertifikat verifikasi diperpanjang [4], sama sekali tidak berhasil. Di semua sistem operasi populer: Linux, Windows, Android dan iOS. Di antara perangkat lunak yang rentan, perpustakaan, dan layanan middleware, berikut ini dapat dibedakan [1]:

• Pustaka EC2 Java Amazon dan semua klien front-end berbasis cloud dibangun atas dasar itu.
• SDK perdagangan Amazon dan PayPal, yang bertanggung jawab atas pengiriman detail pembayaran dari situs (di mana infrastruktur perdagangan online digunakan) ke gateway pembayaran.
• “Keranjang” terpadu, seperti osCommerce, ZenCart, Ubercart, dan PrestaShop, yang sama sekali tidak memvalidasi sertifikat.
• Kode AdMob digunakan oleh perangkat lunak seluler untuk menampilkan iklan kontekstual.
• Antarmuka komponen ujung depan ElephantDrive dan FilesAnywhere, bertanggung jawab untuk berinteraksi dengan penyimpanan cloud.
• Pustaka Android Pusher dan semua perangkat lunak yang menggunakan API Pusher untuk mengontrol pengiriman pesan instan (misalnya, Gaug.es GitHub).
• Apache HttpClient (versi 3.x); Apache Libcloud dan semua koneksi klien ke server Apache ActiveMQ, dll.
• Layanan middleware SOAP Java, termasuk Apache Axis, Axis 2, Codehaus XFire; serta semua perangkat lunak yang dibangun berdasarkan layanan middleware ini.
• Alat API Balancing Beban Elastis
• Implementasi Weberknecht dari WebSockets.
• Serta semua perangkat lunak seluler yang dibangun atas dasar perpustakaan dan layanan middleware yang tercantum di atas (untuk memahami apa layanan middleware, lihat Gambar 1); termasuk klien iOS dari penyedia hosting Rackspace.

Gambar 1. Apa itu layanan middleware

Selain itu, dalam [2] bahkan lebih dari seratus aplikasi seluler yang rentan terdaftar (lihat Gambar. 2). Termasuk: Google Cloud Messaging Android, Daftar Kata Sandi Pusat Bisnis Angie, Klien Jaringan Global AT&T, CapitalOne Spark Pay, Cisco OnPlus (akses jarak jauh), Dukungan Teknis Cisco, Cisco Webex, Kata Sandi WebEx Cisco, Domino Pizza, E-Trade, Freelancer , Google Earth, Huntington Mobile (Bank), Akuntan Daring Pajak Intuit, iTunes Connect, Microsoft Skype, Oracle Now, Pinterest, SafeNet (klien VPN), SouthWest Airlines, Uber, Bank AS - Akses Online, WesternUnion, WordPress, Yahoo! Keuangan, Yahoo! Mail

Gambar 2. Pilihan kecil dari daftar aplikasi seluler yang rentan

SSL / TLS Kerentanan Logis

Koneksi SSL / TLS dari semua ini dan banyak perangkat lunak lain rentan terhadap berbagai serangan MiTM. Pada saat yang sama, serangan MiTM dapat dilakukan, seringkali bahkan tanpa memalsukan sertifikat dan tanpa mencuri kunci pribadi dimana server menandatangani sertifikat mereka. Serangan MiTM dapat dilakukan dengan hanya mengeksploitasi kerentanan logis yang ada dalam prosedur untuk memeriksa sertifikat SSL / TLS di sisi perangkat lunak klien. Akibatnya, penyerang MiTM dapat, misalnya, mengumpulkan token otorisasi, nomor kartu kredit, nama, alamat, dll. - dari pedagang mana pun yang menggunakan aplikasi web pemrosesan pembayaran yang rentan.

Vendor perangkat lunak seluler, yang mengambil kode sampel AdMob untuk menghubungkan aplikasi mereka dengan akun AdMob, juga rentan - mereka memungkinkan penyerang untuk menangkap kredensial dan mendapatkan akses ke semua layanan Google-nya. Misalnya, karena verifikasi sertifikat yang salah pada messenger seperti Trillian dan AIM, penyerang MiTM dapat mencuri kredensial login untuk semua layanan Google (termasuk Gmail), Yahoo !; dan juga ke layanan Windows Live (termasuk SkyDrive). Kerentanan lain yang memengaruhi perangkat lunak web non-browser modern termasuk: penggunaan ekspresi reguler yang salah ketika membandingkan nama host; mengabaikan hasil validasi sertifikat; penutupan verifikasi disengaja atau tidak disengaja. [1]

Kerentanan implementasi protokol SSL / TLS umum lainnya

Dan tentu saja, kita tidak boleh lupa bahwa bahkan jika tidak ada kesalahan logis dalam implementasi protokol SSL / TLS (kecuali tentu saja seseorang masih mempercayainya), perlindungan dapat dilewati dengan mencuri kunci privat [12], dengan menggunakan 0day- eksploitasi untuk hal-hal seperti keyboard, browser, sistem operasi, utilitas dan firmware [3]; dengan mengorbankan routing BGP [10]; atau menyerang SSL / TLS melalui perangkat keras (lihat Gambar 3) [8] dan / atau perangkat lunak [9] memotong saluran.

Gambar 3. Serangan SSL pada perangkat keras

Selain itu, penyerang dapat melakukan serangan MiTM praktis tidak terlihat, menyalahgunakan mekanisme caching sesi SSL / TLS diimplementasikan dalam kelas SSLSessionCache. Mekanisme ini memeriksa validitas sertifikat hanya pada koneksi awal; juga tidak mampu membatalkan sesi komunikasi dengan benar setelah menghapus sertifikat dari perangkat. Selain itu, setelah me-reboot perangkat Android (melalui opsi "Restart" atau "Matikan"), Anda dapat terus melihat lalu lintas terenkripsi dari beberapa aplikasi yang tidak memulai setelah reboot, tetapi bekerja sebelum reboot. Jadi misalnya dengan Google Maps terjadi. Dalam [2], dijelaskan bagaimana, berkat cacat caching ini, penyerang dapat sepenuhnya mengatur dan menghapus "sertifikat tak terlihat" secara transparan untuk pengguna, dan kemudian membuat koneksi jaringan dengan aplikasi apa pun.

Gambar 4. Retrospektif enkripsi rentan

Kerentanan umum lainnya dalam implementasi protokol SSL / TLS termasuk enkripsi yang rentan (lihat Gambar 4) [5], penggunaan kembali GCM (Mode Galois / Kontra; tanggapan dengan otentikasi Galois) [6], trik dengan CNG (CryptoAPI-NG ) di Schannel (lihat Gambar. 5) [7], verifikasi yang salah dari rantai kepercayaan [2], verifikasi yang salah dari nama host [11].

Gambar 5. Trik CNG: menarik rahasia dari Schannel

Verifikasi rantai kepercayaan yang salah adalah situasi di mana aplikasi web benar-benar menerima sertifikat apa pun yang menunjukkan nama host yang benar, tanpa memeriksa dengan otoritas sertifikat apa itu ditandatangani. Ini memungkinkan Anda untuk mencegat dan mendekripsi kata sandi dan / atau nomor kartu kredit. Dan dalam beberapa kasus bahkan melakukan injeksi kode berbahaya. Dalam perangkat lunak Android, kerentanan ini menembus, misalnya, ketika antarmuka X509TrustManger yang disesuaikan dibuat yang mengabaikan pengecualian CertificateException. Atau ketika pengembang perangkat lunak memasukkan panggilan ke metode SslErrorHandler.proceed () ke dalam kode komponen WebViews. [2]

Verifikasi nama host yang salah adalah situasi ketika aplikasi web menerima sertifikat tanpa memastikan bahwa host dari mana sertifikat ini masuk dalam daftar host tepercaya. Dalam perangkat lunak Android, kerentanan ini menembus, misalnya, ketika antarmuka HostnameVerifier dibuat, yang mengembalikan TRUE dalam kondisi apa pun. Atau ketika pengembang perangkat lunak memasukkan panggilan ke metode SslErrorHandler.proceed () ke dalam kode komponen WebViews. [2]

Akar penyebab kerentanan dalam protokol SSL / TLS

Penyebab utama dari sebagian besar kerentanan ini adalah desain API yang mengerikan dari perpustakaan SSL / TLS (termasuk JSSE, OpenSSL, dan GnuTLS). Serta desain perpustakaan transfer data yang sama buruknya (seperti cURL, Apache HttpClient, dan urllib), yang masing-masing merupakan pembungkus tingkat tinggi untuk perpustakaan SSL / TLS. Belum lagi layanan middleware (seperti Apache Axis, Axis 2, atau Codehaus XFire), yang merupakan pembungkus tingkat lebih tinggi, dan yang semakin meningkatkan "bola salju" dari desain yang mengerikan. Alih-alih melakukan dialog dengan pengembang aplikasi (sering jauh dari pemrograman sistem) dalam bahasa yang dia pahami (dalam hal kerahasiaan dan otentikasi), disarikan dari detail tingkat rendah implementasi protokol SSL / TLS, API ini membuang banyak parameter SSL / TLS tingkat rendah pada orang miskin tidak bisa dimengerti olehnya. Mereka membutuhkan perangkat lunak tingkat tinggi untuk mengekspos opsi tingkat rendah dengan benar; mengimplementasikan fungsi verifikasi nama host dan menangani interpretasi nilai-nilai yang dikembalikan oleh operasi tingkat rendah.

Akibatnya, pengembang aplikasi menggunakan API SSL / TLS secara tidak benar: mereka keliru menafsirkan keragaman parameter, opsi, efek samping, dan nilai pengembalian. Misalnya [1]:

• Perpustakaan PHP Layanan Pembayaran Fleksibel Amazon berupaya mengaktifkan validasi nama host dengan menetapkan parameter CURLOPT_SSL_VERIFYHOST menjadi TRUE (di perpustakaan cURL). Namun, nilai default yang benar untuk parameter ini adalah 2; jika Anda memberinya nilai TRUE, maka parameter ini tidak terlihat untuk pengembang yang menetapkan nilai 1, dan seterusnya. verifikasi sertifikat dinonaktifkan.
• Pustaka PHP Standar Pembayaran PayPal - mendapatkan kesalahan yang sama; Selain itu, pada saat implementasi yang sebelumnya, rentan, diperbarui (yaitu, satu kesalahan dihapus, satu lainnya ditambahkan).
• Contoh lain adalah Lynx, browser berorientasi teks. Ini memverifikasi sertifikat yang ditandatangani sendiri - tetapi hanya jika fungsi verifikasi sertifikat GnuTLS mengembalikan nilai negatif. Namun, fungsi ini mengembalikan 0 untuk beberapa kesalahan; termasuk dalam kasus di mana sertifikat ditandatangani oleh badan yang tidak dipercaya. Karena hal ini, rantai kepercayaan di Lynx rusak.

Selain itu, pengembang aplikasi sering salah memahami jenis jaminan keamanan apa yang disediakan oleh perpustakaan SSL / TLS tertentu. Oleh karena itu, di alam liar, seseorang dapat menemukan kasus klinis di mana dalam aplikasi yang secara mendasar membutuhkan komunikasi yang aman (misalnya, berinteraksi dengan prosesor pembayaran), perpustakaan SSL / TLS digunakan yang sama sekali tidak memeriksa sertifikat SSL / TLS. Lebih sederhana, tetapi lebih banyak kasus pembunuhan adalah ketika pengembang dari salah satu lapisan perangkat lunak menengah diam-diam menonaktifkan prosedur untuk memeriksa sertifikat SSL / TLS (ia dapat melakukan ini, misalnya, untuk menguji sistem, dan setelah pengujian lupa mengaktifkannya kembali). Pada saat yang sama, kode program tingkat tinggi menggunakan lapisan perantara ini yakin bahwa verifikasi sertifikat dilakukan. T.O. Kesalahan SSL / TLS sering disembunyikan di kedalaman satu atau beberapa lapisan pustaka antara sekaligus - membuatnya hampir mustahil untuk mendeteksi masalah ini.

Misalnya, di JSSE (Java Secure Socket Extension), antarmuka SSLSocketFactory diperpanjang tanpa suara mengecek nama host jika bidang "algoritma" di klien SSL diatur ke NULL atau ke string kosong, dan bukan ke HTTPS. Meskipun fakta ini disebutkan dalam panduan referensi JSSE, banyak implementasi protokol SSL Java menggunakan SSLSocketFactory tanpa melakukan validasi nama host ...

Satu sendok madu dalam satu tong tar

Jadi, pada kenyataannya, ternyata di sebagian besar perangkat lunak web non-browser, verifikasi sertifikat SSL / TLS benar-benar dinonaktifkan atau diterapkan secara tidak benar. Gambar 7 menunjukkan klasifikasi kerentanan protokol SSL / TLS saat ini. Beberapa kerentanan ini, tetapi tidak semua, telah dijelaskan dan / atau disebutkan di atas. Anda dapat membiasakan diri dengan kerentanan yang disebutkan tetapi tidak dijelaskan dengan membaca materi yang tercantum dalam daftar pustaka.

Gambar 6. Klasifikasi kerentanan yang relevan untuk SSL / TLS

Nah, untuk menambahkan satu sendok madu ke tong tar, perlu dicatat bahwa dalam [1] itu dijelaskan secara rinci / dimengerti / populer / kompeten bagaimana SSL harus dilaksanakan, dengan mengacu pada RFC. Kami belum pernah menemukan deskripsi yang lebih baik, yang secara teknis akurat dan pada saat yang sama dapat dimengerti. Juga di [1], perpustakaan SSL yang paling umum dianalisis, dengan klasifikasi berdasarkan tingkat abstraksi (tingkat rendah / tingkat tinggi). Semua dengan diagram dan algoritma ringkas dalam pseudo-code. Kerentanan produk tertentu dijelaskan secara rinci, dengan kode yang salah dan kode kesalahan. Jadi jika tiba-tiba seseorang sekali lagi memiliki keinginan untuk membuat implementasi kerangka SSL / TLS, yang akan menjadi perkecualian untuk mengatakan "mereka menginginkan yang terbaik, tetapi ternyata seperti biasa", maka [1] adalah awal yang ideal untuk ini.