Data perusahaan seringkali merupakan rahasia dagang. Membocorkannya dapat merusak reputasi, kerugian finansial, atau bahkan kebangkrutan. Oleh karena itu, persyaratan keamanan untuk produk B2B harus sangat tinggi. Membuat produk baru - Corporate Mail Mail.ru - kami memberikan perhatian khusus pada masalah keamanannya.
Corporate Mail Mail.ru adalah versi lokal dari surat B2C Mail.ru. Dibandingkan dengan itu, ini berisi sejumlah modifikasi untuk bekerja di lingkungan baru - sirkuit pelanggan.
Untuk membuat pelanggan yakin dengan keamanan, kami memutuskan untuk menjalani audit di perusahaan pihak ketiga dan memperbaiki semua kekurangan yang kami temukan sebelum menawarkan produk ke pasar. Untuk melakukan ini, mereka beralih ke salah satu perusahaan paling terkemuka di bidang keamanan informasi - Keamanan Digital.
Hasil audit sedang dalam proses.
Eksekusi kode jarak jauh di uWSGI
Ada kerangka kerja yang berbeda untuk membangun aplikasi web Python. Biasanya, Python Web Server Gateway Interface (WSGI) digunakan untuk berkomunikasi antara aplikasi web dan server web. Selain itu, menggunakan WSGI memungkinkan Anda mengimplementasikan komponen middleware.
Untuk menstandarkan komunikasi antara aplikasi web Python dan server web seperti Apache atau Nginx, dikembangkan PEP 0333, diikuti oleh PEP 3333, yang menjelaskan antarmuka WSGI. Kami tidak akan membahas cara kerja WSGI, tetapi akan memberi tahu Anda tentang server populer yang mendukung antarmuka WSGI - uWSGI.
Server uWSGI dapat bekerja baik dalam mode server web normal maupun dalam "mode WSGI", bertukar data dengan server web lain, seperti Nginx. Pada saat yang sama, Nginx menggunakan protokol biner dengan nama yang samauwsgi , yang menarik bagi penjahat dunia maya karena fungsinya yang kaya. Saat menganalisis "internal" solusi, server uWSGI ditemukan, yang dapat diakses oleh semua komponen internal produk.
Masalahnya adalah protokol uwsgi dapat menggunakan apa yang disebut variabel ajaib yang memungkinkan Anda untuk mengkonfigurasi server uWSGI secara dinamis. Di antara variabel ini, ada
UWSGI_FILEsatu yang memungkinkan Anda memuat aplikasi dinamis baru jika Anda menentukan jalur ke file dalam variabel. Ternyata, uWSGI-server dapat menangani sirkuit yang berbeda dengan cara ini, misalnya section, fd, call, atau paling menarik - exec. Dengan demikian, Anda dapat memasukkan variabel sebagai nilaiexec://<cmmand>untuk menjalankan perintah bash sewenang-wenang. Eksploitasi telah ditulis untuk menganalisis masalah ini dan tersedia di github .
Contoh kueri yang menjalankan perintah.
Kerentanan ini hanya dapat dieksploitasi jika penyerang:
- Sudah di jaringan internal produk, misalnya, salah satu komponen telah disusupi. Hal ini memungkinkannya untuk membajak komponen baru, mengakses data baru, dan melanjutkan serangan.
- Memiliki SSRF dengan kemampuan untuk mengirim data arbitrer melalui TCP (misalnya menggunakan
gopher://). Dalam skenario ini, penyerang dapat memperoleh akses ke bagian dalam produk.
Perlu dicatat bahwa implementasi antarmuka CGI untuk bahasa atau kerangka kerja pemrograman lain juga dapat menjadi rentan, misalnya, eksploitasi dari repositori yang sama untuk FastCGI. Ini bukan untuk mengatakan bahwa ini adalah kerentanan dalam arti biasa, melainkan fitur server CGI, jadi Anda perlu membatasi akses ke server tersebut sebanyak mungkin.
Melewati perlindungan CSRF
Dengan diperkenalkannya berbagai mekanisme keamanan di browser, serangan sisi klien di web modern secara bertahap menghilang. Ini juga berlaku untuk CSRF: browser telah menerapkan dukungan untuk cookie SameSite, meskipun jika dikonfigurasi dengan tidak benar, mungkin masih ada celah. Selain itu, banyak kerangka kerja populer memungkinkan pengembang untuk dengan mudah mengonfigurasi perlindungan CSRF, tetapi beberapa bug atau kerentanan non-kritis dapat menyebabkan serangan CSRF. Kesalahan seperti itu ditemukan dalam aplikasi kalender yang disertakan dengan produk kami.
Aplikasi tersebut memiliki API yang memungkinkan Anda melakukan tindakan pada acara dan kalender pengguna, misalnya: mengedit, melihat, atau menghapusnya. Untuk merujuk ke objek, parameter UID diteruskan di jalur URL, yang bertanggung jawab atas ID kalender atau acara. Ini terlihat seperti ini:
example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?
Secara default, UID dibuat secara acak dan tidak dapat dipengaruhi oleh pengguna. Namun dalam aplikasi, ditemukan dua tempat di mana pengguna dapat mengubah UID.
Yang pertama adalah mengimpor file dalam format ICS (format khusus untuk kalender dan acara), mereka memiliki bidang UID khusus yang dikontrol pengguna saat mengimpor. Dalam kasus ini, setelah peristiwa impor, UID mereka akan tetap sama seperti yang ditransfer dalam file. Selain itu, parameter ini tidak memiliki pemfilteran. Dengan demikian, pengguna dapat membuat acara dengan UID arbitrer.
Yang kedua adalah kemampuan untuk mengubah kalender UID saat mengeditnya. Ini dapat dilakukan dengan mencegat permintaan untuk mengedit kalender dan hanya mengubah bidang UID. Tidak ada pemfilteran di sini juga.
Fitur penting lainnya: API ini mengimplementasikan perlindungan CSRF; untuk ini, parameter khusus diteruskan dalam parameter GET, yang berperan sebagai kunci untuk API dan token CSRF. Itu ditambahkan melalui JavaScript ke semua permintaan API. Merupakan praktik yang buruk untuk meneruskan token CSRF dalam parameter GET, dalam hal ini, token dapat bocor melalui perujuk, log aplikasi, atau riwayat browser.
Menyatukan semuanya. Penyerang dapat mengontrol UID objek dalam aplikasi dan berbagi akses ke acara dan kalender dengan pengguna lain. Dalam kasus ini, pengguna akan melihat UID yang sama, dan saat mereka mulai bekerja dengan objek seperti itu, permintaan akan dieksekusi dengan UID yang dikontrol oleh penyerang. Menggunakan ini, penyerang dapat membuat objek dengan UID seperti:
../../../AnyPathTo?anyparam=value&
Sekarang, saat pengguna melakukan tindakan pada objek, permintaan akan dibuat:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action
Kemudian token juga akan ditambahkan ke dalamnya, memainkan peran sebagai token CSRF:
example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef
Dan terakhir, membuat permintaan, browser menormalkan urutan "
../", sebagai hasilnya, permintaan akan dikirim ke
example.com/AnyPathTo?anyparam=value&/action&token=abcdef
Sekarang penyerang dapat memaksa pengguna untuk mengirim permintaan ke aplikasi di sepanjang jalur arbitrer dengan parameter arbitrer dan dengan token CSRF yang benar. Tetap memahami metode permintaan apa yang dapat kita jalankan.
Ternyata sederhana: saat mengedit, PUT dikirim, saat menghapus, DELETE, saat melihat, GET (POST digunakan untuk membuat, dan kami tidak bisa memaksa korban untuk menggunakannya). Dengan menggunakan DELETE, penyerang dapat memaksa browser pengguna untuk menjalankan permintaan untuk menghapus objek dari pengguna. Bonus terpisah untuk penyerang adalah ketika pengguna mengedit objek, permintaan PUT dikirim dengan isi permintaan. Saat mengedit kalender, isi permintaan akan berisi JSON, yang berisi semua parameter kalender saat ini. Artinya, penyerang yang membuat kalender "jahat" mengontrol parameter ini. Jika penyerang berhasil mengarahkan permintaan edit dari kalender jahat ke kalender pribadi pengguna, maka semua properti dari kalender berbahaya akan diterapkan ke properti kalender korban.Ini dapat menimpa akses ke kalender karena ini adalah salah satu properti kalender yang ditentukan di JSON.
Kemampuan serangan MITM
Penetrasi penyusup ke dalam jaringan internal perusahaan adalah situasi berbahaya yang penuh dengan konsekuensi serius. Oleh karena itu, selama audit produk, salah satu tugas kami adalah menemukan kelemahan dalam arsitektur sistem yang dapat membantu penyerang naik domain atau meningkatkan serangan eksternal.
Salah satu fitur utama produk ini adalah integrasi dengan Active Directory. Ini diimplementasikan untuk otentikasi melalui LDAP dan mengumpulkan pesan dari server Exchange, dalam contoh ini kita akan fokus pada ActiveSync. Untuk penyerang, ini adalah target yang sangat menarik karena akun pengguna dan kata sandi dikirimkan antara produk dan Direktori Aktif selama sambungan. Dengan mendapatkan akses ke koneksi, penyerang akan dapat membajak akun dan selangkah lebih dekat untuk menyusupi domain.
Dalam solusi internal dan server perusahaan, sering kali ada masalah dengan penggunaan TLS yang salah atau tidak adanya sama sekali, sementara itu tidak sulit untuk menerapkan TLS untuk suatu layanan. Hal ini biasanya merupakan konsekuensi dari fakta bahwa jaringan internal perusahaan dianggap lebih aman, dan administrator perusahaan tidak membuang waktu untuk membuat infrastruktur PKI yang benar dan menerbitkan sertifikat untuk semua server.
Serangan paling umum di dalam jaringan perusahaan adalah MITM. Jenis serangan ini paling sering memungkinkan akses di dalam Active Directory perusahaan. Pada saat yang sama, tidak selalu mungkin bagi penyerang untuk menyerang interaksi server-ke-server dalam jaringan perusahaan; paling sering, selama uji penetrasi, ia atau modelnya jatuh ke dalam segmen jaringan pengguna di mana tidak ada server Exchange atau pengontrol domain. Selain itu, dalam kasus kami, produk tidak menggunakan protokol resolusi nama siaran seperti NBNS, LLMNR, mDNS, jadi spoofing protokol ini tidak memungkinkan MITM diimplementasikan. Jadi, untuk MITM yang berhasil antara solusi dan server lain, penyerang perlu memiliki akses ke jaringan tempat salah satu komponen ini dipasang. Terkadang mungkin untuk mencapai tujuan ini - ada router atau server yang rentan,yang pada akhirnya memungkinkan Anda mengakses jaringan tertentu.
Dalam kasus kami, selama analisis, ternyata integrasi dengan Active Directory rentan terhadap serangan MITM.
Saat pengguna memasukkan nama pengguna dan sandi, sistem mengirimkan dua permintaan LDAP ke pengontrol domain. Permintaan pertama mengembalikan daftar alamat email, dan jika login pengguna ada dalam daftar ini, permintaan kedua dikirim, yaitu Autentikasi LDAP Sederhana. Data ditransmisikan dalam bentuk teks biasa tanpa menggunakan SSL / TLS, atau lebih tepatnya, LDAPS (LDAP melalui SSL) tidak digunakan. Hal ini memungkinkan penyerang, bahkan jika terjadi serangan MITM pasif, untuk mendapatkan akun pengguna yang saat ini diotorisasi dalam produk.
Masalah kedua: saat menyambung ke server Exchange menggunakan protokol ActiveSync untuk mengumpulkan pesan masuk, sistem tidak memverifikasi keaslian sertifikat TLS server. Dalam kasus ini, penyerang dapat mengimplementasikan serangan MITM aktif, setelah menerima koneksi, dia dapat memberikan sertifikat yang ditandatangani sendiri, membuat koneksi dan proxy data ke server Exchange; maka MITM tidak akan terlihat, dan penyerang dapat memperoleh kredensial pengguna, yang dikirimkan dalam protokol ActiveSync.
Dengan mengeksploitasi kerentanan ini, penyerang secara teoritis dapat memperoleh akun pengguna dan kemudian menggunakannya untuk menyerang domain Active Directory. Secara terpisah, perlu dicatat bahwa penggunaan TLS yang benar merupakan tugas penting bagi perusahaan yang mengimplementasikan solusi tersebut.
Hasil
Kami terus-menerus dihadapkan pada serangan peretas dan telah memperoleh pengalaman yang solid dalam cara melawannya. Kami yakin bahwa produk yang kami masukkan ke dalam perimeter pelanggan harus seaman mungkin, termasuk berdasarkan hasil pemeriksaan independen. Corporate Mail Mail.ru hanyalah produk seperti itu.
Kami dihadapkan pada tugas yang memakan waktu: untuk mentransfer basis kode besar dengan banyak layanan mikro ke infrastruktur pelanggan sehingga email akan bekerja sendiri hampir sepanjang waktu, tanpa kegagalan dan intervensi administrator.
Kami meminta auditor untuk memberikan perhatian paling besar pada otorisasi yang diubah (Surat Perusahaan menggunakan AD pelanggan) dan API surat utama - kode sumber komponen ini dianalisis secara mendetail. Akibatnya, kekurangan yang ditemukan terutama terkait dengan topologi jaringan yang diubah dan modifikasi khusus untuk solusi lokal.
Untuk komponen lainnya (kalender, Mail.ru untuk antarmuka administrasi bisnis), model kotak abu-abu digunakan: auditor berinteraksi dengan layanan dengan hak istimewa pengguna biasa, tetapi dapat terhubung ke penampung dengan aplikasi yang berjalan, sebagian memiliki kode sumber API dan dapat mengklarifikasi detailnya dengan pengembang.
Audit itu sangat berguna bagi kami. Kami menemukan sejumlah kekurangan di beberapa komponen, yang segera kami koreksi untuk membawa produk yang aman ke pasar. Pada saat yang sama, kami yakin akan perlindungan tingkat tinggi dari sebagian besar komponen lainnya. Kami berencana untuk melakukan audit tersebut secara rutin - kami ingin produk kami selalu menjadi solusi domestik teraman, tidak hanya menurut kami, tetapi juga menurut pendapat auditor independen.
Keamanan Surat Korporat adalah kombinasi dari keamanan produk itu sendiri dan infrastruktur klien. Artinya, tanggung jawab atas keamanan data perusahaan ada pada kami, pengembang, dan klien itu sendiri. Selain itu, kami telah merumuskan rekomendasi praktik terbaik untuk melindungi infrastruktur dari kekurangan dan selalu memberi tahu pelanggan selama pemasangan produk kami.