(0275) 2974 127
Menurut Threatpost, sebanyak 1,5 juta situs WordPress telah dihack akibat kerentanan injeksi konten. WordPress merupakan satu dari sekian banyak content management system (CMS) yang paling banyak digunakan di dunia.
Jadi ketika terjadi masalah keamanan pada sistemnya, akan berpengaruh pada jutaan pengguna internet. Satu masalah keamanan ini telah ditemukan oleh peneliti keamanan di Sucuri, sebuah perusahaan keamanan internet, yang mengetahui website WordPress rentan terhadap injeksi konten.
Secara sederhana Content Injection adalah proses ilegal untuk membuat atau mengupdate sebuah post di WordPress dengan memanfaatkan bug di REST API milik WordPress. Sangat parah, karena tanpa harus memiliki user di web tersebut (alias cuma pembaca/visitor saja) bisa update dan tulis konten sesukanya dengan REST API yang ngebug tadi.
REST API diaktifkan secara default di semua situs yang menggunakan WordPress 4.7.0 atau 4.7.1. Jika suatu situs menggunakan versi WordPress ini, maka saat ini situs tersebut rentan terhadap bug ini. Semua Versi WordPress yang terpengaruh khususnya 4.7.0 dan 4.7.1, pokoknya sebelum versi 4.7.2.
Di masa lalu, WordPress telah menemukan berbagai masalah kerentanan seperti :
Sucuri menemukan sebuah Conten Injection vulnerability atau kerentanan injeksi konten yang mempengaruhi REST API dan mengakibatkan hacker dapat memodifikasi konten dari postingan atau halaman mana saja dalam situs WordPress.
Tetapi berita baiknya, Sucuri telah melaporkan hal ini ke tim keamanan WordPress yang mengatasi masalah ini dengan profesional dan mengiformasikan ke banyak penyedia keamanan dan host serta mengimplementasikan sebuah patch sebelum kerentanan ini memberi dampak lebih jauh ke banyak pengguna WordPress.
Karena WordPress sangat populer dan mudah digunakan, masalah keamanan sekecil apapun pada sistemnya bisa mengakibatkan kerusakan besar dan mempengaruhi jutaan penggunanya.
Peneliti keamanan dari Sucuri, Marc-Alexandre Montpas menuliskan dalam postingan blognya kalau ini merupakan kerentanan yang bersifat serius yang bisa disalahgunakan. Ada beberapa hal detail yang sengaja disembunyikan untuk mempersulit hacker.
Tetapi plugin yang di install pada situs, bisa memicu perintah eksekusi jarak jauh atau RCE (Remote Command Execution). Selain itu, meski konten telah melewati wp_kses, tetap ada celah untuk menginjeksi Javascript dan HTML.
Tim keamanan WordPress telah mengatasi masalah ini dalam waktu yang relatif singkat, meski saat itu masih dibutuhkan uji coba. Anggota tim berkoordinasi dengan berbagai perusahaan, termasuk Sucuri, yang menyebarkan firewall aplikasi website untuk memblokir jenis eksploitasi ini ke konsumen.
WordPress menyatakan juga berkoordinasi dengan Incapsula, Cloudflare dan SiteLock untuk memastikan pelanggan untuk mengantisipasi masalah ini.
Ketika dilakukan pengujian perbaikan, fokus beralih ke host WordPress. WordPress akan menghubungi dan menyampaikan informasi tentang kerentanan ini serta cara melindungi para pengguna. Pihak host bekerjasama dengan tim keamanan untuk mengimplementasikan proteksi dan secara reguler mencari percobaan eksploitasi terhadap pengguna.
WordPress sendiri sempat menunda pengungkapan kerentanan ini untuk memastikan penggunanya, yang telah memiliki update otomatis di situs akan terlindungi sebelum publikasi beserta detailnya.
Berikut adalah cara menemukan eksploitasi rest api WordPress di situs yang di rentas, yaitu :
1. Temukan website yang yang menjalankan wordpress.
2. Temukan kerentanan pada wordpress.
3. Mengidentifikasi id posting wp.
4. Jalankan sekarang.
Semua administrator direkomendasikan untuk mengupdate versi situs WordPress terbaru sesegera mungkin. Versi WordPress terbaru ini mencakup perbaikan dari kerentanan ini. Sebagai pencegahan dianjurkan menggunakan update otomatis pada situs WordPress untuk memastikan selalu ada di versi terbaru dan bisa diamankan dari ancaman serupa.
Dimulai dengan ./wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
Ada beberapa hal yang perlu diperhatikan di sini. Rute terdaftar dirancang untuk mengisi parameter permintaan ID dengan digit. Misalnya jika mengirim permintaan untuk / wp-json / wp / v2 / tulisan / 1234 – yang ID parameter akan ditetapkan untuk 1234 .
Perilaku ini sendiri bisa menjadi cara yang baik untuk mencegah penyerang membuat nilai ID berbahaya, tetapi saat melihat bagaimana REST API mengelola akses maka akan segera menemukan bahwa itu memprioritaskan nilai $ _GET dan $ _POST daripada yang dihasilkan oleh ekspresi reguler rute. Hal ini memungkinkan penyerang untuk mengirim permintaan seperti: / wp-json / wp / v2 / posts / 1234? Id = 12345helloworld – yang akan menetapkan 12345helloworld ke parameter ID – yang sekarang berisi lebih dari sekedar digit.
Menyelidiki lebih lanjut telah melihat berbagai panggilan balik (pada tangkapan layar di atas) dan salah satunya menarik perhatian : update_item dan metode pemeriksaan izinnya update_item_permissions_check .
Singkatnya ini meneruskan nilai ID alfanumerik kita langsung ke fungsi get_post () . Fungsi ini memvalidasi permintaan dengan :
Menemukan ini sebagai cara yang aneh untuk membersihkan permintaan. Jika mengirim ID yang tidak memiliki postingan yang sesuai hanya dapat melewati pemeriksaan izin dan diizinkan untuk terus menjalankan permintaan ke metode update_item.
Penasaran tentang apa yang dapat menyebabkan get_post () gagal dalam menemukan postingan (selain ID yang tidak ada ), menyadari bahwa metode ini menggunakan metode statis get_instance () di wp_posts untuk mengambil postingan.
Seperti yang dilihat dari kode, pada dasarnya ini akan gagal pada input apa pun yang semuanya tidak terbuat dari karakter numerik jadi 123ABC akan gagal.
Untuk penyerang berarti bahwa WordPress (mengira itu adalah pengguna dengan hak istimewa yang cukup untuk mengedit posting ini) akan menjalankan metode update_item .
Cukup masuk akal untuk memeriksa apa yang dilakukan metode ini.
Dengan adanya detail yang sangat halus, namun penting dalam tangkapan layar terakhir itu WordPress mentransmisikan parameter ID ke bilangan bulat sebelum meneruskannya ke get_post.
Ini menjadi masalah karena cara PHP melakukan perbandingan dan konversi jenis. Misalnya, dapat melihat bahwa cuplikan berikut akan menghasilkan 123 :
Ini mengarah ke situasi yang sangat berbahaya di mana penyerang dapat mengirimkan permintaan seperti / wp-json / wp / v2 / posts / 123? Id = 456ABC untuk mengubah postingan yang ID-nya adalah 456. Karena masalah jenis juggling ini maka mungkin saja penyerang mengubah konten dari setiap posting atau halaman di situs korban. Dari sana dapat menambahkan kode pendek khusus plugin untuk mengeksploitasi kerentanan (yang seharusnya dibatasi untuk peran kontributor), menginfeksi konten situs dengan kampanye spam SEO atau memasukkan iklan dll.
Bergantung pada plugin yang diaktifkan di situs, bahkan kode PHP dapat dijalankan dengan sangat mudah.
Semoga bermanfaat.
Apakah Anda menggunakan kartu ATM atau kartu debit? Suka bertransaksi secara cashless? Sepertinya Anda perlu…
Design website toko online tidak hanya soal estetika, tapi juga UX yang bagus secara keseluruhan.…
Sebelum memulai karir Anda sebagai desainer UX, Anda harus membuat portofolio yang mencakup semua pengalaman…
Keep-Alive memungkinkan browser pengunjung Anda mendownload semua konten (JavaScript, CSS, gambar, video, dll) melalui koneksi…
Job description seorang web developer adalah membuat situs web menggunakan berbagai bahasa pemrograman. Tanggung jawab…
Secara default, WordPress tidak mendukung A/B testing. Tapi jangan khawatir. Di bawah ini, kami telah…