MetInfo RCE Chain: Path Traversal ke PHP Code Injection - Ethical Hacking Indonesia

Kerentanan pada MetInfo CMS versi 7.9 hingga 8.1 input tidak disanitasi tetapi secara teknis jauh lebih dalam. Ia menggabungkan tiga elemen yang biasanya dianggap “aman” jika berdiri sendiri: endpoint API (WeChat), mekanisme cache berbasis file, dan parsing string PHP. Ketika ketiganya bertemu dalam satu execution path, hasilnya adalah unauthenticated remote code execution.

Masalah dimulai dari method "weixinreply::wxAdminLogin()" yang memproses request XML dari integrasi WeChat. Dua field, "EventKey" dan "FromUserName", langsung digunakan tanpa validasi ketat. "EventKey" dipakai sebagai parameter "$code" dalam "cache::get()", sementara "FromUserName" disimpan melalui "cache::put()". Secara desain, ini tampak seperti alur caching biasa, tetapi implementasinya membuka celah serius.

Ketika "$code" dapat dikontrol attacker, ia bisa menyisipkan path traversal untuk memanipulasi file yang di-include oleh "cache::get()". Di titik ini, tujuan attacker bukan hanya membaca file, melainkan mengubah state aplikasi. Dengan memaksa hasil tertentu misalnya string "Array" attacker mengarahkan flow ke penulisan file cache baru dengan nama yang bisa diprediksi: "/cache/weixin/Array.php"

Tahap berikutnya adalah inti dari eksploitasi. Nilai "FromUserName" ditulis ke dalam file tersebut dalam konteks string PHP. Di sinilah fitur yang jarang disadari developer menjadi senjata: complex curly syntax dalam PHP memungkinkan evaluasi ekspresi di dalam string. Artinya, input yang tampak seperti teks biasa bisa berubah menjadi kode yang dieksekusi saat file di-include. Ketika file cache itu dipanggil kembali oleh sistem, payload langsung berjalan tanpa hambatan.

Skenario eksploitasi di dunia nyata tidak membutuhkan kondisi yang rumit. Target yang menggunakan plugin WeChat secara default sudah memiliki direktori "/cache/weixin/". Attacker hanya perlu mengirim request XML crafted ke endpoint webhook. Request pertama bertujuan menulis file berisi payload, dan request berikutnya (atau bahkan alur internal yang sama) memicu include file tersebut. Dalam hitungan detik, attacker bisa mendapatkan eksekusi perintah di server, biasanya dilanjutkan dengan drop web shell untuk persistensi.

Dampaknya langsung berada pada level kompromi penuh. Begitu RCE tercapai, batas antara aplikasi dan sistem operasi praktis hilang. Database dapat diakses, konfigurasi dapat diubah, dan sistem bisa dijadikan pivot ke jaringan internal. Dalam konteks yang lebih luas, ini bukan  saja   bug aplikasi, tetapi juga potensi titik masuk untuk serangan supply chain jika CMS digunakan secara luas oleh banyak situs.

Baca Juga Tentang: Remote Code Exceution (RCE)

Yang menarik dari kasus ini adalah bagaimana lapisan cache berubah menjadi attack surface. Banyak sistem menganggap cache sebagai komponen pasif, padahal ketika cache disimpan sebagai file ".php" dan di-include kembali, ia secara efektif menjadi bagian dari runtime execution. Ditambah lagi, endpoint seperti webhook sering diasumsikan “trusted” sehingga jarang mendapat validasi ketat, padahal justru menjadi pintu masuk tanpa autentikasi.

Mitigasi yang efektif harus langsung memutus rantai eksploitasi ini. Validasi input perlu berbasis whitelist dan menolak karakter traversal sejak awal. Lebih penting lagi, mekanisme cache seharusnya tidak pernah menggunakan format executable seperti ".php;" menyimpannya sebagai data (misalnya JSON) sudah cukup untuk kebutuhan caching tanpa membuka risiko eksekusi. Di sisi lain, penggunaan dynamic include berbasis input harus dihindari sepenuhnya. Patch dari vendor memang wajib diterapkan, tetapi tanpa perubahan pola desain seperti ini, risiko serupa akan terus muncul di tempat lain.

Bagi praktisi keamanan, ini contoh jelas bahwa kerentanan kritis sering bukan berasal dari satu bug besar, melainkan dari interaksi beberapa komponen kecil yang masing-masing terlihat “normal”. Ketika boundary antar layer tidak dijaga dengan ketat, sistem akan menciptakan jalur eksekusi yang bahkan tidak disadari oleh developernya sendiri.

Benediktus Sava – Security Researcher

Sumber:

Karmain Security

Eksploitasi CRLF Injection Axios pada Multipart FormData - Ethical Hacking Indonesia

Kerentanan CVE-2026-42037 Axios sebagai isu sanitasi input, tetapi dalam praktiknya membuka primitive yang cukup berbahaya: kemampuan memanipulasi struktur multipart body secara langsung. Ini bukan bypass validasi biasa, melainkan cara untuk mengontrol bagaimana server downstream memahami setiap part dalam request.

Trust Berlebihan pada Metadata File

Dalam banyak arsitektur modern, Node.js sering berperan sebagai proxy layer menerima upload dari user, lalu meneruskan file tersebut ke service lain menggunakan "axios.post()" dengan FormData. Masalah muncul ketika metadata file seperti MIME type "(value.type)" dianggap aman dan langsung digunakan.

Pada implementasi Axios sebelum 1.15.1, nilai type dari objek Blob/File dimasukkan langsung ke header "Content-Type" dalam setiap multipart part, tanpa sanitasi terhadap karakter kontrol seperti "\r\n". Ini menciptakan celah klasik: CRLF injection, tetapi bukan di HTTP header utama melainkan di dalam body multipart itu sendiri.

Perbedaan ini krusial, karena banyak proteksi (termasuk di Node.js v18+) hanya fokus pada header HTTP, bukan struktur internal multipart.

MIME Type ke Header Injection

Secara internal, Axios membangun multipart body dengan format seperti:

--boundary

Content-Disposition: form-data; name="file"; filename="a.jpg"

Content-Type: image/jpeg

<binary data>

Namun karena "value.type" tidak disanitasi, attacker bisa menyisipkan CRLF:

image/jpeg\r\nX-Injected: evil\r\nX-Another: test

Hasil di body:

Content-Type: image/jpeg

X-Injected: evil

X-Another: test

Yang terjadi bukan string injection saja tetapi, header smuggling di level multipart. Parser di server tujuan akan menganggap header tambahan tersebut sebagai bagian sah dari part tersebut.

Menariknya, path lain dalam kode Axios (untuk string value) sudah melakukan sanitasi CRLF. Ini menunjukkan bahwa developer sadar akan risiko ini, tetapi implementasinya tidak konsisten.

Abuse pada Arsitektur Proxy Upload

Skenario realistis yang sering terjadi:

Sebuah aplikasi memiliki fitur upload gambar. File dikirim ke backend Node.js, lalu backend ini meneruskan file ke storage service atau API lain menggunakan Axios.

Attacker mengunggah file dengan MIME type yang dimodifikasi:

image/png\r\nContent-Disposition: form-data; name="role"\r\n\r\nadmin

Ketika Axios membangun multipart request, payload ini akan:

• Menutup header asli
• Menyisipkan field baru (role=admin)
• Mengubah struktur form-data

Jika server downstream tidak memvalidasi dengan ketat, maka:

• Field tambahan bisa diterima sebagai input valid
• Validasi berbasis Content-Type bisa dilewati
• Bahkan memungkinkan manipulasi parameter tanpa terlihat di layer aplikasi awal

Ini menjadi sangat berbahaya jika backend downstream menggunakan parsing multipart untuk menentukan logika bisnis (misalnya role assignment, metadata processing, atau routing file).

Boundary Confusion

Yang membuat vulnerability ini menarik adalah sifatnya sebagai boundary confusion attack.

Biasanya, developer berpikir bahwa:

• HTTP header ---- dilindungi
• Body --- data mentah

Namun multipart adalah hybrid: ia memiliki struktur seperti header di dalam body. Dan di sinilah blind spot muncul.

Beberapa insight penting untuk praktisi:

• Banyak WAF tidak menginspeksi per-part headers secara mendalam
• Parser multipart di berbagai framework memiliki perilaku berbeda (permissive vs strict)
• Injection seperti ini bisa digunakan untuk desync antara proxy dan backend

Dengan kata lain, ini bisa menjadi bagian dari attack chain yang lebih besar, seperti:

• request smuggling (layer aplikasi)
• validation bypass
• bahkan exploit chaining ke vulnerability parsing lain

Filter Bypass ke Data Manipulation

Dampak langsung mungkin terlihat “hanya” integrity issue, tapi dalam sistem nyata bisa berkembang:

Pertama, attacker bisa melewati filter upload berbasis MIME type. Jika server hanya memeriksa Content-Type dari part, maka header yang dimanipulasi bisa membuat file berbahaya terlihat legitimate.

Kedua, attacker bisa menyisipkan field tambahan dalam multipart body. Ini membuka kemungkinan manipulasi parameter yang tidak dikontrol oleh aplikasi awal.

Ketiga, dalam sistem yang kompleks (microservices atau API chaining), ini bisa menyebabkan data misrouting di mana service downstream memproses data dengan konteks yang salah.

Dalam konteks lebih luas, ini relevan dengan:

• API gateway trust issue
• data integrity attack
• supply chain input manipulation

Karena Axios digunakan sangat luas, blast radius vulnerability ini cukup besar, terutama pada service yang berperan sebagai relay.

Patch resmi di versi 1.15.1 menambahkan sanitasi terhadap "value.type", menghapus karakter CRLF sebelum digunakan. Ini langkah penting, tetapi bukan satu-satunya.

Pendekatan defensif yang lebih kuat mencakup:

• Validasi MIME type di sisi server, bukan hanya meneruskan dari client
• Jangan mempercayai metadata file dari user (termasuk filename dan type)
• Gunakan parser multipart yang strict dan menolak header anomali
• Implementasi allowlist untuk Content-Type yang diizinkan
• Logging terhadap anomali multipart structure (misalnya header tambahan dalam part)

Ini menunjukkan bagaimana library yang sangat umum seperti Axios bisa menjadi bagian dari attack surface ketika digunakan dalam konteks yang salah. Bukan karena library-nya “buruk”, tetapi karena asumsi trust terhadap input tidak ditegakkan dengan benar.

CRLF injection di multipart bukan teknik baru, tetapi implementasi seperti ini menghidupkan kembali teknik lama dalam konteks modern khususnya di arsitektur berbasis API dan microservices.

Bagi pentester, ini adalah peluang untuk mengeksplorasi area yang sering diabaikan: struktur internal request, bukan hanya endpoint.
Bagi developer, ini pengingat bahwa setiap data yang berasal dari user bahkan yang terlihat sepele seperti MIME type harus diperlakukan sebagai input tidak terpercaya.

Benediktus Sava – Security Researcher

Sumber:

NIST-NVD

Github Advisory Database

Weaver E-cology RCE: Abuse Debug Dubbo API Tanpa Auth - Ethical Hacking Indonesia

Kerentanan CVE-2026-22679 di Weaver E-cology 10.0 sebuah endpoint tanpa autentikasi yang mengarah ke remote code execution. Namun jika dilihat dari sudut pandang arsitektur, ini bukan bug biasa, melainkan kegagalan boundary antara komponen internal (RPC debug interface) dan exposure eksternal (HTTP layer). Dalam banyak kasus modern, justru kesalahan seperti inilah yang menghasilkan kompromi paling fatal.

Masalah dimulai dari endpoint "/papi/esearch/data/devops/dubboApi/debug/method". Endpoint ini pada dasarnya adalah generic invoker untuk Dubbo RPC, yang memungkinkan pemanggilan method secara dinamis hanya berdasarkan nama interface dan method. Secara internal, fitur ini sangat powerful untuk debugging atau troubleshooting. Tetapi ketika endpoint ini tidak dilindungi autentikasi dan tidak memiliki validasi input, ia berubah menjadi mekanisme eksekusi jarak jauh yang sepenuhnya dikontrol attacker.

Baca Juga Tentang: RCE (Remote Code Execution) - Study Kasus

Secara teknis, alur eksploitasinya cukup jelas. Request HTTP POST dengan payload JSON diterima oleh server, lalu langsung diteruskan ke layer Dubbo tanpa filtering berarti. Framework Dubbo kemudian melakukan resolusi interface menggunakan reflection, mencari method yang sesuai, dan mengeksekusinya dengan parameter yang diberikan. Di sinilah titik kritisnya: attacker bebas menentukan interfaceName dan methodName, sehingga bisa mengarahkan eksekusi ke helper internal yang memang dirancang untuk menjalankan perintah sistem. Pada implementasi tertentu, ini berujung pada pemanggilan Runtime.exec(), yang berarti perintah OS dijalankan langsung oleh server.

Baca Juga Tentang: Command Injection - KEV

Yang membuat vulnerability ini sangat berbahaya adalah sifatnya yang single-step exploitation. Tidak ada kebutuhan untuk bypass autentikasi, tidak perlu chaining dengan vulnerability lain, dan tidak membutuhkan kondisi khusus. Selama endpoint tersebut dapat diakses, attacker bisa langsung mengeksekusi command. Dalam praktiknya, eksploitasi bisa dimulai dari scanning massal terhadap endpoint ini, kemudian dilanjutkan dengan payload sederhana untuk mendapatkan shell. Misalnya, attacker cukup mengirim perintah untuk mengunduh dan menjalankan script dari server eksternal, lalu membuka reverse shell ke mesin mereka.

Dari sisi dampak, ini bukan hanya soal akses ke satu server. Weaver E-cology biasanya terintegrasi dengan berbagai komponen penting dalam organisasi database, sistem HR, workflow internal, hingga penyimpanan dokumen. Begitu attacker mendapatkan eksekusi command, mereka berada dalam posisi ideal untuk melakukan pivot ke sistem lain. Kredensial bisa diambil dari file konfigurasi, koneksi database bisa dieksploitasi, dan akses ke dokumen internal bisa dimanfaatkan untuk eksfiltrasi data sensitif.

Baca Juga Tentang: Pivot - Lateral Movement - Local Privilege

Dalam konteks yang lebih luas, vulnerability ini sangat relevan dengan pola supply chain attack dan identity compromise. Sistem seperti E-cology sering digunakan sebagai pusat operasional organisasi. Mengompromikannya berarti attacker tidak hanya mendapatkan akses data, tetapi juga kemampuan untuk memanipulasi proses bisnis misalnya menyisipkan dokumen berbahaya dalam workflow atau memodifikasi data internal tanpa terdeteksi. Ini adalah jenis akses yang sangat bernilai dalam skenario APT.

Hal yang menarik dari kasus ini adalah bahwa akar masalahnya bukan pada teknologi Dubbo itu sendiri, namun lebih pada cara penggunaannya. RPC framework seperti Dubbo memang dirancang untuk fleksibilitas tinggi, termasuk dynamic invocation. Namun fleksibilitas ini menjadi risiko ketika tidak dibatasi oleh kontrol keamanan yang ketat. Debug endpoint yang seharusnya hanya tersedia di lingkungan development justru terekspos ke internet, tanpa autentikasi dan tanpa pembatasan method. Ini menunjukkan adanya asumsi yang salah dalam desain: bahwa komponen internal tidak akan pernah diakses oleh pihak luar.

Mitigasi tentu dimulai dari patch resmi yang menghapus endpoint tersebut. Tetapi pendekatan defensif tidak boleh berhenti di sana. Sistem harus dipandang sebagai kumpulan attack surface, termasuk endpoint yang “tidak seharusnya digunakan publik”. Pembatasan akses melalui network segmentation, filtering pada reverse proxy, dan penerapan prinsip least privilege pada service account menjadi langkah penting. Selain itu, monitoring juga perlu difokuskan pada perilaku abnormal, seperti proses shell yang dipicu oleh aplikasi Java atau request mencurigakan ke endpoint RPC.

Vulnerability ini cukup jelas: setiap interface yang memberikan kemampuan eksekusi dinamis baik itu RPC, scripting engine, atau debug tool harus dianggap sebagai komponen berisiko tinggi. Ketika interface tersebut terekspos tanpa kontrol, ia tidak lagi sekadar fitur debugging, melainkan berubah menjadi execution primitive bagi attacker. Dan dalam lingkungan enterprise, satu primitive seperti ini sudah cukup untuk membuka jalan menuju kompromi total.

Benediktus Sava – Security Researcher

Sumber:

NIST

Vegaio

RMM Abuse: Teknik Persistence Tanpa Malware Tradisional - Ethical Hacking Indonesia

Ketika Trust Model Menjadi Attack Surface

Sebagian besar sistem keamanan endpoint masih beroperasi dengan asumsi bahwa ancaman datang dari binary yang tidak dikenal, unsigned, atau memiliki reputasi catcat atau rendah. Kampanye ini justru bergerak di arah sebaliknya. Tidak ada eksploitasi kernel, tidak ada shellcode injection, bahkan tidak ada malware dalam bentuk tradisional di tahap awal. Yang digunakan adalah software RMM seperti ITarian, SimpleHelp, dan ScreenConnect semuanya legitimate, signed, dan umum digunakan di lingkungan enterprise.

Baca Juga Tentang: Penggunaan ScreenConnect Dalam Serangan (Analisis Serangan Storm-1175)

Di sinilah problem utamanya muncul. Mekanisme trust yang dibangun untuk mempermudah operasional IT justru menjadi attack surface. Ketika sebuah binary memiliki valid code-signing certificate dan dikenal luas, hampir seluruh lapisan pertahanan dari SmartScreen hingga antivirus secara default akan memperlakukannya sebagai aman.

Serangan Berbasis Legitimate Execution

Rantai serangan dimulai dari phishing yang tidak menggunakan domain attacker secara langsung, melainkan domain legitimate yang telah dikompromi. Ini bukan sekadar teknik pengaburan, tetapi strategi untuk melewati filtering berbasis reputasi yang umum digunakan pada email gateway dan web proxy.

Baca Juga tentang: Spear Phising (FrostArmada)

Payload yang dikirim ke korban tidak terlihat mencurigakan karena memanfaatkan perilaku default Windows. Ekstensi file disembunyikan sehingga executable tampil seperti dokumen biasa, sementara icon dan metadata dimodifikasi agar selaras dengan konteks social engineering. Ketika file dijalankan, tidak ada indikator eksploitasi klasik. Sebaliknya, yang aktif adalah JWrapper sebuah Java-based launcher yang bertindak sebagai abstraction layer.

JWrapper mengeksekusi beberapa langkah penting secara diam-diam. Ia mengekstrak runtime Java yang dibundel, membaca konfigurasi terenkripsi yang disisipkan dalam binary, lalu menjalankan payload tanpa UI. Dari perspektif sistem, proses ini terlihat seperti aplikasi Java biasa yang berjalan dengan parameter tertentu, bukan sebagai loader malware. Inilah titik di mana banyak solusi EDR kehilangan konteks, karena tidak ada anomali struktural pada binary maupun prosesnya.

Persistence dan Session Control Tanpa Exploit Tradisional

Mengeksploitasi vulnerability, attacker membangun kontrol penuh melalui mekanisme sistem yang sah. Mereka mendaftarkan service Windows yang berjalan secara persist dan kemudian memperluas jangkauannya hingga ke user session.

Yang menarik adalah bagaimana persistence dibangun. Service tidak hanya didaftarkan melalui Service Control Manager, tetapi juga diikat ke Safe Mode melalui registry SafeBoot. Artinya, bahkan ketika defender mencoba membersihkan sistem melalui Safe Mode, service tersebut tetap aktif. Ini diperkuat dengan mekanisme watchdog berbasis file yang akan me-restart proses jika berhenti, menciptakan efek self-healing.

Baca Juga Tentang: Persistence Access (Firestarter - Cisco)

Setelah persistence stabil, attacker melakukan eskalasi dari konteks service (SYSTEM) ke konteks user. Ini dilakukan dengan mencuri token dari proses seperti winlogon.exe, kemudian menggunakannya untuk membuat proses baru di session user aktif. Dengan pendekatan ini, attacker tidak hanya memiliki kontrol sistem, tetapi juga kemampuan interaktif melihat layar, mengirim input, dan mengakses resource berbasis user.

Yang membuat operasi ini semakin solid adalah penggunaan dua RMM secara paralel. Satu channel digunakan untuk automation dan monitoring, sementara channel lain untuk akses interaktif. Ini bukan sekadar redundansi, melainkan desain arsitektur yang memastikan akses tetap bertahan meskipun salah satu jalur berhasil diputus.

Baca Juga Tentang: Apa itu RRM?

Dari Akses Diam-Diam ke Pengambilalihan Infrastruktur

Setelah foothold terbentuk, sistem tidak langsung disalahgunakan secara agresif. Sebaliknya, attacker menjalankan monitoring pasif dengan pola yang sangat konsisten. Mereka mengumpulkan informasi tentang jaringan, status keamanan, dan aktivitas user secara berkala. Salah satu teknik yang cukup cerdas adalah memonitor pergerakan mouse untuk menentukan apakah user sedang aktif. Interaksi hanya dilakukan ketika sistem idle, meminimalkan kemungkinan terdeteksi.

Dalam skenario nyata, ini memberikan keuntungan besar bagi attacker. Mereka bisa masuk ke sistem, mengumpulkan kredensial dari browser, mengevaluasi akses VPN, dan memahami topologi internal tanpa menimbulkan alarm. Karena RMM secara natural memang digunakan untuk remote administration, aktivitas seperti command execution atau file transfer tidak terlihat aneh jika dilihat tanpa konteks.

Dampaknya kemudian meluas. Dengan kredensial yang diperoleh, attacker dapat melakukan lateral movement ke sistem lain. Dalam banyak kasus, tahap ini berfungsi sebagai fase awal sebelum deployment ransomware. Yang membedakan adalah seluruh proses berlangsung di atas software yang dipercaya, sehingga visibility terhadap aktivitas berbahaya menjadi sangat terbatas.

Baca Juga Artikel Tentang: Lateral-Movement - Kredensial Harvesting

Dari Signature ke Behavioral Context

Serangan seperti ini tidak bisa dideteksi secara efektif hanya dengan signature atau reputasi file. Yang dibutuhkan adalah pemahaman terhadap behavior dan konteks eksekusi.

Indikator kompromi tidak lagi berupa hash file atau domain mencurigakan, melainkan pola aktivitas. Misalnya, service baru yang dibuat dari direktori tidak umum seperti ProgramData, atau proses RMM yang memicu eksekusi command-line utilities secara berulang. Bahkan detail kecil seperti keberadaan binary yang di-rename misalnya wmic.exe yang berubah nama bisa menjadi indikator kuat karena tidak pernah muncul dalam operasi normal.

Selain itu, organisasi perlu mulai memperlakukan RMM sebagai komponen yang harus diawasi ketat. Tidak cukup hanya mengizinkan software tersebut berjalan; perlu ada baseline yang jelas mengenai bagaimana, kapan, dan oleh siapa software tersebut digunakan. Setiap deviasi dari baseline tersebut harus dianggap sebagai anomali, bukan noise.

Pergeseran ke Living-off-Trusted-Software

Kampanye ini menandai pergeseran penting dalam lanskap threat. Jika sebelumnya attacker berusaha membuat malware terlihat legitimate, kini mereka langsung menggunakan sesuatu yang memang legitimate sejak awal.

Ini memungkinkan evolusi dari konsep Living-off-the-Land menjadi Living-off-Trusted-Software. Perbedaannya bukan sekadar istilah, tetapi implikasi operasional. Ketika software yang digunakan adalah bagian dari workflow IT sehari-hari, maka deteksi tidak bisa lagi bergantung pada apa yang dijalankan, tetapi harus fokus pada bagaimana software tersebut digunakan.

Serangan seperti ini memaksa defender untuk berpindah dari pendekatan berbasis objek ke pendekatan berbasis perilaku. Karena ketika backdoor tidak lagi berupa malware, satu-satunya jejak yang tersisa adalah pola aktivitas yang tidak seharusnya terjadi.

Benediktus Sava – Security Researcher

Sumber:

Securonix

Redcanary

False Positive Microsoft Defender dan Dampaknya pada Trust Chain - Ethical Hacking Indonesia

Ketika mekanisme proteksi endpoint mulai memodifikasi trust anchor sistem, kita tidak lagi berbicara sekadar false positive ini sudah masuk ke domain integrity failure pada root of trust. Kasus deteksi Trojan:Win32/Cerdigent.A!dha oleh Microsoft Defender terhadap entri root certificate DigiCert menjadi contoh nyata bagaimana kontrol keamanan dapat berubah menjadi attack surface yang tidak disengaja.

Masalah inti muncul dari signature update Defender (sekitar 30 April) yang mengklasifikasikan registry key tertentu sebagai indikator malware. Targetnya bukan file berbahaya, melainkan entri trust store Windows di path:

HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\

Secara teknis, lokasi ini menyimpan root CA yang digunakan dalam validasi TLS, code signing, dan berbagai mekanisme trust lainnya. Ketika Defender menghapus entri berdasarkan hash tertentu, sistem kehilangan kemampuan untuk memverifikasi rantai sertifikat yang bergantung pada root tersebut. Ini bukan sekadar alert ini adalah modifikasi aktif terhadap cryptographic trust chain.

Analisa lebih dalam menunjukkan kemungkinan besar bahwa signature detection dibangun dari indikator yang overlap dengan artefak insiden DigiCert sebelumnya. Dalam insiden tersebut, attacker berhasil memperoleh initialization code untuk code-signing certificate dan menggunakannya untuk menandatangani malware. Jika Defender mengandalkan pattern matching terhadap struktur atau metadata sertifikat yang mirip, maka false positive menjadi konsekuensi logis dari pendekatan heuristik yang terlalu agresif.

Skenario eksploitasi yang realistis tidak harus melibatkan eksploit langsung oleh attacker justru yang menarik adalah abuse of defensive side-effects. Bayangkan environment enterprise di mana root certificate tertentu dihapus secara massal. Dampaknya:

TLS handshake ke layanan tertentu gagal - downtime aplikasi internal

Validasi signature software gagal - deployment pipeline berhenti

Endpoint kehilangan kemampuan verifikasi update - membuka peluang supply chain attack lanjutan

Dalam kondisi chaos seperti ini, attacker bisa melakukan opportunistic attack. Misalnya, dengan melakukan MITM pada koneksi yang fallback ke insecure mode atau dengan menyisipkan sertifikat alternatif di endpoint yang sudah kehilangan baseline trust-nya. Ini bukan eksploit klasik, tapi lebih ke arah trust degradation attack memanfaatkan kondisi sistem yang sudah tidak konsisten.

Dampaknya meluas ke beberapa layer:

1. Operational impact – gangguan layanan akibat TLS failure
2. Security impact – potensi bypass verifikasi jika fallback terjadi
3. Psychological impact – admin panik, bahkan sampai reinstall OS tanpa alasan valid

Menariknya, beberapa organisasi justru memperburuk situasi dengan melakukan remediation yang tidak tepat, seperti wipe sistem, padahal root cause ada pada signature update.

Dari sisi deteksi dan forensik, pendekatan yang lebih tepat adalah memonitor perubahan registry menggunakan telemetry seperti:

• DeviceRegistryEvents untuk melihat re-creation certificate
• certutil -store AuthRoot untuk validasi manual trust store

Insight penting di sini: trust store harus diperlakukan sebagai critical asset, bukan sekadar konfigurasi pasif. Perubahan terhadapnya seharusnya memiliki audit trail yang ketat, sama seperti perubahan pada IAM atau firewall rules.

Microsoft kemudian memperbaiki signature ini di update versi 1.449.430.0 ke atas, yang menunjukkan bahwa ini murni kesalahan deteksi, bukan kompromi aktif. Namun, kejadian ini membuka diskusi lebih luas tentang ketergantungan terhadap automated security controls.

Mitigasi yang relevan untuk praktisi:

• Implementasikan monitoring terhadap perubahan trust store (registry + certificate store)
• Gunakan baseline integrity check untuk root CA penting
• Hindari auto-remediation agresif tanpa validation layer tambahan
• Segmentasikan critical system agar tidak semua endpoint menerima signature update secara simultan (staged rollout)

Secara strategis, ini juga berkaitan dengan konsep supply chain trust. Ketika CA seperti DigiCert mengalami insiden, efeknya tidak hanya pada certificate issuance, tetapi juga pada bagaimana vendor security merespons dan respons tersebut bisa berdampak lebih luas dari insiden awal.

Kesimpulannya: False positive ini bukan sekadar bug, melainkan ilustrasi bahwa dalam ekosistem modern, boundary antara defense dan disruption sangat tipis. Bagi pentester dan security engineer, ini adalah pengingat bahwa kontrol keamanan sendiri harus diuji sebagai bagian dari threat model.

Benediktus Sava – Security Researcher

Baca Juga Artikel Yang Berrkaitan:

Exploit Chains Di Windows

Windows - MSHTML

Microsoft Security Pathcing

Sumber:

Florian Roth - X

Microsoft - MSI

NinjaOne

Authenticated Phishing: Abuse Infrastruktur Google AppSheet - Ethical Hacking Indonesia

Serangan AccountDumpling memperlihatkan celah yang jarang dibahas secara serius dalam security engineering: bukan bug pada sistem, tetapi kegagalan asumsi terhadap trust. Lebih dari 30.000 akun Facebook berhasil dikompromikan bukan melalui spoofing atau malware, tapi lewat email yang secara teknis sah dikirim langsung dari infrastruktur Google melalui AppSheet. Di sini, model pertahanan klasik runtuh karena indikator kepercayaan (SPF, DKIM, DMARC) justru bekerja “terlalu baik”.

Masalah utamanya bukan pada mekanisme autentikasi email itu sendiri, tapi pada interpretasinya. Email authentication hanya menjawab pertanyaan “siapa yang mengirim”, bukan “apakah kontennya aman”. AppSheet, sebagai platform no-code, dirancang untuk mengirim notifikasi otomatis berbasis workflow. Namun dalam konteks ini, attacker memanfaatkannya sebagai phishing relay yang tidak dapat dibedakan dari notifikasi legitimate. Karena email berasal dari domain Google yang valid, sistem filter tidak memiliki alasan teknis untuk memblokirnya. Ini menciptakan kondisi di mana payload berbahaya dibungkus dalam jalur distribusi yang sepenuhnya trusted.

Jika ditelusuri lebih dalam, serangan ini bukan sekadar phishing campaign biasa, tetapi sebuah arsitektur terdistribusi yang menyerupai sistem produksi modern. AppSheet berfungsi sebagai delivery layer dengan reputasi tinggi. Setelah korban berinteraksi, mereka diarahkan ke infrastruktur yang di-host di Netlify atau Vercel, yang masing-masing memiliki peran berbeda. Netlify digunakan untuk halaman phishing statis dengan subdomain unik per korban, sehingga mempersulit blocklisting. Sementara itu, Vercel digunakan untuk flow yang lebih kompleks, termasuk validasi kredensial secara real-time, pengumpulan data bertahap, dan mekanisme anti-analisis seperti obfuscation dan deteksi debugging.

Baca Juga Tentang Penggunaan Netlify(UTA0388) dan Vercel Dalam CyberCrime

Dalam salah satu skenario eksploitasi yang digunakan adalah, seorang admin Facebook Business menerima email peringatan terkait pelanggaran kebijakan. Karena email tersebut lolos semua validasi dan terlihat profesional, korban cenderung langsung mengikuti instruksi. Setelah klik, korban masuk ke halaman yang menyerupai pusat bantuan Facebook. Di titik ini, serangan tidak berhenti pada pengumpulan username dan password. Sistem akan langsung menguji kredensial tersebut ke layanan asli. Jika valid, korban diminta memasukkan kode 2FA, bahkan hingga beberapa kali jika diperlukan. Dalam varian yang lebih canggih, attacker memanfaatkan koneksi WebSocket untuk memonitor interaksi korban secara langsung. Ini memungkinkan attacker bertindak sebagai operator aktif yang bisa menyesuaikan alur phishing secara real-time misalnya meminta ulang input, mengubah tampilan halaman, atau mengeksekusi langkah tambahan untuk memastikan akses benar-benar berhasil diambil alih.

Pendekatan ini mengubah phishing dari aktivitas pasif menjadi sesi interaktif yang hampir menyerupai man-in-the-middle attack, tetapi berbasis social engineering. Tidak hanya kredensial yang diambil, tetapi juga data pemulihan seperti nomor telepon, tanggal lahir, hingga dokumen identitas. Artinya, attacker tidak hanya mendapatkan akses awal, tetapi juga kemampuan untuk mempertahankan kontrol jika korban mencoba melakukan recovery.

Dampaknya melampaui sekadar account takeover. Dalam konteks Facebook Business, satu akun bisa memiliki nilai ekonomi tinggi karena terhubung dengan sistem iklan, audiens, dan identitas brand. Setelah diambil alih, akun tersebut bisa digunakan untuk menjalankan iklan berbahaya, melakukan penipuan, atau bahkan dijual kembali di pasar gelap. Yang lebih menarik, investigasi menunjukkan adanya loop monetisasi di mana akun yang dicuri kemudian “dipulihkan” melalui layanan yang kemungkinan dioperasikan oleh aktor yang sama. Ini menciptakan model bisnis tertutup yang menyerupai supply chain, di mana akses menjadi komoditas yang terus diputar.

Bagi praktisi keamanan, ada beberapa pelajaran penting yang muncul dari kasus ini. Pertama, reliance terhadap reputasi domain sudah tidak cukup. Ketika attacker menggunakan platform seperti Google, Netlify, dan Vercel, sinyal kepercayaan tradisional kehilangan relevansinya. Kedua, phishing telah berevolusi menjadi proses stateful yang melibatkan validasi langsung dan interaksi manusia di belakang layar. Ketiga, identity kini harus dipandang sebagai bagian dari supply chain security, bukan hanya sebagai endpoint authentication.

Mitigasi terhadap serangan seperti ini tidak bisa hanya mengandalkan filtering email. Pendekatan yang lebih efektif adalah menggeser fokus ke level interaksi. Sistem perlu mampu mendeteksi anomali dalam alur login, bukan hanya pada sumber email. Penggunaan metode autentikasi yang tahan phishing seperti passkey atau FIDO2 menjadi semakin penting karena menghilangkan nilai dari kredensial yang dicuri. Selain itu, pembatasan akses ke akun kritikal, misalnya melalui IP allowlisting atau device binding, dapat mengurangi peluang eksploitasi meskipun kredensial sudah bocor.

Bisa kita lihat dan simpulkan yaitu AccountDumpling menunjukkan bahwa attacker tidak selalu perlu menembus sistem. Cukup dengan memanfaatkan cara sistem dirancang untuk dipercaya, mereka bisa mendapatkan hasil yang sama. Ini menandai pergeseran penting dalam threat landscape: dari eksploitasi kerentanan teknis menuju eksploitasi asumsi desain. Dan dalam banyak kasus, yang kedua jauh lebih sulit dideteksi.

Benediktus Sava – Security Researcher

Sumber:

GuardIo

Bedah Copy Fail: Bug Kernel Linux Jadi Akses Root CVE-2026-31431 - Ethical Hacking Indonesia

Kerentanan Local Privilege Escalation biasanya bergantung pada dua hal: race condition yang sempit atau offset kernel yang spesifik. Copy Fail (CVE-2026-31431) mematahkan asumsi itu sepenuhnya. Ini bukan bug timing, bukan juga exploit yang membutuhkan penyesuaian terhadap versi kernel tertentu. Ini adalah logic flaw linear di dalam subsistem crypto Linux, tepatnya pada implementasi algif_aead dalam AF_ALG. Artinya, eksploitasi tidak membutuhkan kondisi khusus cukup user biasa, tanpa privilege, tanpa debugging capability, dan tanpa primitif tambahan. Di banyak environment modern, itu sudah cukup untuk mendapatkan root.

Baca Juga Tentang: Local Privilege Escalation

Masalah utamanya muncul dari desain “in-place operation” yang sebelumnya diperkenalkan, di mana source dan destination buffer diasumsikan bisa berbagi mapping memori. Dalam praktiknya, asumsi ini tidak valid karena keduanya berasal dari mapping berbeda. Kompleksitas tambahan untuk mendukung operasi ini justru membuka celah: data yang seharusnya diisolasi malah diproses dengan cara yang memungkinkan manipulasi terhadap page cache atau buffer kernel. Ketika kernel melakukan copy data associated (AD) dalam konteks AEAD, terdapat inkonsistensi dalam bagaimana pointer dan panjang data divalidasi. Ini menciptakan kondisi di mana user-space bisa memicu write ke area yang tidak semestinya.

Yang membuatnya berbahaya adalah sifatnya yang deterministik. Tidak ada race window yang harus “ditangkap”. Eksekusi berjalan lurus: kirim input crafted ke AF_ALG socket, trigger path yang salah dalam algif_aead, dan hasilnya adalah memory corruption yang bisa dikontrol. Ini menjelaskan kenapa PoC bisa sesederhana script Python ~700 byte dan tetap bekerja lintas distro sejak 2017.

Skenario eksploitasi yang realistis muncul di lingkungan multi-tenant. Bayangkan sebuah CI runner self-hosted yang mengeksekusi pull request dari publik. Attacker cukup mengirim PR berisi payload Python sederhana. Karena runner menjalankan kode sebagai user biasa di host kernel yang sama, exploit dapat dijalankan langsung. Begitu privilege escalation berhasil, attacker memiliki akses root ke mesin runner, yang seringkali menyimpan secrets seperti token deployment, SSH keys, atau credentials cloud. Ini bukan  LPE saja tetapi ini pivot point untuk supply chain attack. Dari satu runner, attacker bisa menyuntikkan malicious code ke pipeline build dan menyebarkannya ke artifact produksi.

Dalam konteks container, dampaknya bahkan lebih luas. Banyak organisasi masih menganggap container sebagai boundary keamanan, padahal kernel tetap shared. Dengan Copy Fail, sebuah pod yang dikompromi dapat melakukan escape ke host. Karena page cache dan subsistem kernel dibagi, exploit ini membuka jalan untuk cross-container compromise. Dalam cluster Kubernetes multi-tenant, ini berarti satu tenant bisa mengakses resource tenant lain, atau bahkan menguasai node secara penuh.

Jika dibandingkan dengan kasus seperti Dirty Pipe, pola eksploitasinya memiliki kemiripan: manipulasi terhadap mekanisme kernel yang berhubungan dengan data flow (pipe atau crypto buffer) untuk menulis ke area yang seharusnya read-only atau terisolasi. Insight penting di sini adalah bahwa kelas bug seperti ini tidak lagi jarang atau mahal untuk ditemukan. Dengan bantuan sistem otomatis seperti yang digunakan oleh peneliti, discovery terhadap logic flaw semacam ini menjadi jauh lebih cepat. Artinya, asumsi lama bahwa kernel bug adalah “rare commodity” sudah tidak relevan.

Dampaknya terhadap threat model cukup signifikan. Sistem yang sebelumnya dianggap aman karena tidak expose network service kini tetap rentan jika attacker mendapatkan foothold lokal sekecil apapun misalnya melalui web RCE, credential leakage, atau misconfigured service. Copy Fail menjadi tahap eskalasi yang hampir pasti berhasil setelah initial access.

Lalukan Pengecekan Linux Kamu: Github - Copy Fail

Mitigasi utamanya tentu patch kernel ke versi yang telah memperbaiki implementasi algif_aead dengan kembali ke pendekatan out-of-place operation. Namun, pendekatan defensif tidak boleh berhenti di patching. Untuk environment dengan risiko tinggi seperti CI/CD, Kubernetes, atau SaaS yang menjalankan kode user, isolasi berbasis VM atau microVM menjadi jauh lebih relevan dibanding sekadar namespace container. Selain itu, pembatasan akses terhadap AF_ALG dapat dipertimbangkan melalui seccomp atau LSM policy, karena tidak semua aplikasi membutuhkan interface crypto kernel secara langsung.

Baca Juga Tentang: CI/CD

Di sisi engineering, kasus ini juga menunjukkan pentingnya validasi terhadap laporan vulnerability. Dengan meningkatnya penggunaan AI dalam vulnerability discovery, jumlah laporan akan naik drastis, tetapi tidak semuanya valid. Organisasi perlu memiliki pipeline untuk reproduksi cepat terhadap PoC agar bisa membedakan noise dan exploit nyata. Tanpa itu, vulnerability seperti Copy Fail bisa terlambat ditangani meskipun exploit-nya trivial.

Kesimpulan yang bisa kita ambil Copy Fail bukan hanya tentang satu bug di kernel. Ini adalah indikator perubahan lanskap: eksploitasi semakin mudah, discovery semakin cepat, dan boundary keamanan tradisional seperti container semakin tidak cukup. Praktisi security perlu mulai mengasumsikan bahwa LPE seperti ini akan terus muncul dan merancang sistem dengan asumsi tersebut, bukan sebagai edge case.

Benediktus Sava – Security Researcher

Sumber:

Copy File

Bugcrowd

Eksploitasi CVE-2026-3854: Git Push ke RCE di GHES - Ethical Hacking Indonesia

CVE-2026-3854 bukan sekadar bug input validation biasa, tetapi representasi nyata bagaimana fitur legitimate seperti git push options dapat berubah menjadi attack surface kritis ketika boundary antara user input dan internal metadata tidak dijaga dengan ketat. Problem utamanya terletak pada improper neutralization terhadap karakter spesial, di mana nilai yang dikirim user saat proses git push langsung dimasukkan ke dalam header internal tanpa sanitasi yang memadai. Karena format metadata internal menggunakan delimiter seperti titik koma (;), attacker dapat memanfaatkan konflik ini untuk melakukan injection dan memanipulasi cara sistem memproses request tersebut.

Baca Juga Tentang: Command Injection - 4 CVE KEV April 2026

Secara teknis, alur normal git push di GitHub Enterprise Server melibatkan beberapa service internal yang saling berkomunikasi menggunakan metadata header. Push options memungkinkan client mengirim key-value tambahan ke server, yang kemudian diteruskan sebagai bagian dari header seperti X-Stat. Masalahnya muncul ketika nilai tersebut tidak di-escape atau divalidasi, sehingga attacker dapat menyisipkan delimiter tambahan untuk “memecah” struktur metadata. Ini memungkinkan injeksi field baru yang akan dianggap sebagai konfigurasi internal yang trusted oleh service downstream. Dalam konteks ini, attacker tidak lagi sekadar mengontrol input mereka mengontrol environment eksekusi.

Baca Juga Tentang: Bagaimana Data User Bisa Mengontrol Internal Service

Eksploitasi menjadi menarik karena tidak berhenti di satu injection saja. Peneliti menunjukkan bahwa dengan chaining beberapa nilai yang disuntikkan, attacker bisa mengubah rails_env menjadi non-production untuk melemahkan sandbox, mengarahkan custom_hooks_dir ke lokasi yang dikontrol, dan memanipulasi repo_pre_receive_hooks untuk mengeksekusi hook berbahaya melalui path traversal. Ini bukan sekadar command injection langsung, tetapi lebih ke arah environment poisoning mengubah konteks eksekusi sehingga sistem sendiri menjalankan payload attacker sebagai bagian dari workflow normal.

Baca Juga Tentang: Environment Manipulation

Skenario eksploitasi realistis bisa terjadi di organisasi yang menggunakan GitHub Enterprise Server secara internal. Seorang attacker yang sudah memiliki akses push ke repository baik melalui akun yang dikompromi atau insider threat dapat melakukan push dengan opsi yang telah dimodifikasi secara khusus. Tanpa interaksi tambahan, server akan memproses push tersebut dan secara tidak sadar menjalankan hook yang telah dimanipulasi. Karena eksekusi terjadi sebagai user git, attacker mendapatkan foothold dengan akses ke filesystem, konfigurasi internal, dan kemungkinan pivot ke service lain dalam lingkungan yang sama. Dalam environment yang menggunakan shared storage node, dampaknya bisa meluas ke repository lain.

Dampak vulnerability ini tidak bisa diabaikan. Dengan CVSS tinggi dan kemampuan remote code execution, attacker berpotensi mengambil alih seluruh instance GHES. Ini termasuk akses read/write ke repository privat, credential internal, hingga pipeline CI/CD yang terintegrasi. Jika dikaitkan dengan konteks supply chain attack, ini menjadi sangat kritikal karena compromise pada Git server berarti attacker bisa menyisipkan backdoor langsung ke source code yang nantinya akan didistribusikan ke production. Ini menggeser vulnerability ini dari sekadar “server exploit” menjadi potensi entry point untuk software supply chain compromise.

Insight penting bagi praktisi adalah bagaimana vulnerability ini menunjukkan kelemahan umum dalam desain sistem terdistribusi: asumsi bahwa internal metadata selalu trusted. Ketika user-controlled data dapat masuk ke jalur komunikasi internal tanpa validasi ketat, boundary antara external input dan internal logic runtuh. Ini adalah pola yang sering muncul di banyak sistem, tidak hanya GitHub terutama pada service yang menggunakan custom protocol atau header untuk komunikasi antar komponen.

Mitigasi utama tentu adalah patching ke versi yang telah diperbaiki, tetapi pendekatan defensif tidak boleh berhenti di situ. Validasi dan sanitasi input harus dilakukan secara konsisten di setiap layer, bukan hanya di entry point. Selain itu, prinsip least privilege harus diterapkan pada akses repository tidak semua user seharusnya memiliki hak push, terutama di environment sensitif. Monitoring juga menjadi krusial: log seperti /var/log/github-audit.log harus dianalisis untuk mendeteksi anomali, misalnya penggunaan karakter delimiter dalam push options yang tidak lazim. Dari sisi arsitektur, menghapus code path yang tidak digunakan di environment tertentu adalah langkah penting dalam defense-in-depth, karena mengurangi kemungkinan abuse meskipun vulnerability serupa muncul kembali.

CVE-2026-3854 memperlihatkan attack surface modern tidak selalu berasal dari fitur yang berbahaya, tetapi justru dari fitur yang dirancang untuk fleksibilitas. Dalam dunia DevOps yang sangat bergantung pada automasi dan integrasi, setiap titik yang menghubungkan user input dengan sistem internal harus dianggap sebagai potensi vektor eksploitasi. Bagi pentester dan security engineer, ini adalah pengingat bahwa eksploitasi tingkat lanjut sering kali bukan tentang menemukan bug baru, tetapi tentang memahami bagaimana sistem mempercayai data dan di mana kepercayaan itu bisa disalahgunakan.

Benediktus Sava – Security Researcher

Sumber:

Github Advisory Database

WIZ IO