DeepSeek Harness membolehkan penyerang dalam persekitaran sandbox menjalankan sebarang arahan hanya dengan menukar pengepala (header) HTTP Host kepada 127.0.0.1, yang mencatatkan skor 9.4 pada skala CVSS. Kelemahan ini menunjukkan bagaimana satu keputusan kepercayaan yang salah boleh menukarkan sempadan perlindungan menjadi pintu belakang yang terbuka.

Bagaimana pepijat ini terlepas masuk

Kod yang terdedah kepada kerentanan ini berada dalam satu fungsi tunggal yang membaca pengepala Host permintaan dan, jika nilainya sama dengan alamat loopback, ia menganggap permintaan tersebut datang daripada mesin tempatan.

Penyerang yang boleh melaksanakan kod di dalam sandbox tidak memerlukan muatan (payload) yang canggih. Dengan menghantar satu permintaan HTTP dengan Host: 127.0.0.1, bahagian belakang (backend) akan percaya bahawa panggilan tersebut berasal daripada hos itu sendiri dan akan melangkau semua gesaan keselamatan, semakan had kadar (rate-limit), dan langkah pengesahan arahan. Hasilnya: pelaksanaan arahan tanpa sekatan tanpa memerlukan sebarang interaksi lanjut.

Mengapa mempercayai pengepala adalah berbahaya

Pengepala adalah rentetan teks biasa yang dibekalkan oleh pemanggil. Sama ada medan tersebut dinamakan Host, X-Forwarded-For, atau sebarang nama tersuai, klien boleh menetapkannya kepada sebarang nilai yang diingini. Satu-satunya sumber kebenaran yang boleh dipercayai tentang dari mana sambungan itu benar-benar berasal adalah lapisan pengangkutan (transport layer) – alamat IP sumber soket yang direkodkan oleh sistem operasi apabila jabat tangan (handshake) TCP selesai.

Apabila sesebuah aplikasi memutuskan untuk mempercayai pengepala tanpa mengesahkan bahawa proksi yang diketahui dan dikonfigurasi dengan betul telah menyuntiknya, ia seolah-olah menyerahkan kunci kerajaan kepada penyerang. Pepijat DeepSeek Harness adalah contoh klasik bagi kesilapan ini.

Impak dunia nyata: contoh shell.online

Projek sumber terbuka shell.online, yang menawarkan terminal berasaskan web, baru-baru ini mendokumentasikan kesilapan yang sama. Ia menggunakan bendera konfigurasi yang dipanggil TRUST_PROXY:

  • TRUST_PROXY = 0 – aplikasi mengabaikan pengepala X-Forwarded-For dan bergantung pada alamat jauh (remote address) soket. Ini menghalang klien daripada memalsukan alamat IP untuk mengelak had kadar atau menyamar sebagai pengguna yang dipercayai.
  • TRUST_PROXY = 1 – aplikasi mempercayai pengepala X-Forwarded-For sebagai identiti klien. Jika perkhidmatan tersebut tidak berada di belakang proksi sebenar yang menyucikan (sanitises) pengepala ini, penyerang boleh membekalkan alamat IP baharu pada setiap permintaan, yang secara berkesan menetapkan semula sebarang pengehadan (throttling) bagi setiap IP.

Pepijat DeepSeek mencerminkan senario ini: kod tersebut mempercayai Host seolah-olah ia ditetapkan oleh proksi, namun perkhidmatan tersebut boleh diakses secara terus.

Apa yang perlu dilakukan oleh pembangun sekarang

  1. Audit setiap tempat anda membaca pengepala yang dibekalkan oleh klien. Kenal pasti pengepala mana yang anda anggap sebagai berautoriti (contohnya, Host, X-Forwarded-For, X-Real-IP) dan sahkan bahawa proksi yang dipercayai dijamin akan menulis semula pengepala tersebut sebelum ia sampai ke aplikasi anda.
  2. Hubungkan keputusan keselamatan dengan alamat soket jika boleh. Gunakan IP sumber yang disediakan oleh OS untuk pengesahan, had kadar, dan semakan kawalan akses.
  3. Aktifkan bendera kepercayaan proksi hanya apabila proksi terbalik (reverse proxy) yang dikonfigurasi dengan betul berada di hadapan perkhidmatan. Jika anda menjalankan aplikasi secara terus, pastikan bendera tersebut kekal dinyahaktifkan.
  4. Dokumentasikan topologi penggunaan yang diperlukan dalam README atau panduan penggunaan projek anda, supaya pengguna yang menghoskan sendiri (self-host) mengetahui tentang keperluan kepercayaan proksi tersebut.
  5. Jalankan alat analisis-statik atau semakan-kod yang menandakan penggunaan pengepala secara terus untuk keputusan keselamatan tanpa logik pengesahan proksi yang menyertainya.

Apa yang perlu diperhatikan seterusnya

Komuniti yang menyediakan perkhidmatan web hos-sendiri berkemungkinan besar akan menyemak semula tetapan kepercayaan proksi mereka sendiri selepas insiden ini.

Pengajaran utamanya sangat jelas: jangan sesekali membiarkan sepotong teks yang boleh ditulis oleh sesiapa sahaja di internet menentukan postur keselamatan sistem anda. Percayalah pada lapisan rangkaian, bukan lapisan permintaan.