"Allrequestsallowed.com" ... Upaya retas?

11

Saya memiliki banyak upaya pada server web (kecil, pribadi, dan sama sekali tidak penting) saya, dan apache dan fail2ban biasanya melakukan pekerjaan mereka dengan benar. Tapi ada entri log yang membuatku khawatir:

xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"

Masalahnya adalah jawabannya bukan kode 404, melainkan 200. Apakah itu tidak apa apa? Kelihatannya aneh bagi saya, tetapi pengetahuan saya tentang bidang ini (dan banyak lainnya) adalah, secara halus, terbatas.

server security webserver luri
sumber
1
Terlihat seperti aku tidak diizinkan untuk memasukkan jawaban baru, tapi kami menemukan sebuah entri seperti ini di log kami, dan kami dapat memverifikasi bahwa itu tidak berbahaya dengan mereproduksi permintaan dengan ikal: curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Konfigurasi default tampaknya mengembalikan halaman "Selamat datang di nginx" tanpa konten yang berarti, di sistem ubuntu kami. Jadi ini adalah tanggapan 200, tapi ini adalah halaman tangkap sederhana - kami sebenarnya tidak memproksi permintaan di tempat lain atau semacamnya.
Frank Farmer

Jawaban:

12

Pertama, di muka, saya tidak tahu apa yang penyerang coba capai. Mungkin ada skrip PHP atau versi PHP di luar sana yang rentan terhadap beberapa serangan ID sesi yang aneh, saya tidak tahu. Anda mungkin tidak perlu khawatir.

Server Anda berperilaku tepat seperti yang diharapkan. 200 adalah kode yang diharapkan dalam situasi tertentu karena bagaimana Apache mengartikan URL yang diteruskan ke sana.

Pertama, http://allrequestsallowed.comdiperlakukan seperti header 'Host:' yang lebih biasa ( perhatikan bahwa saya tidak berpikir ini ditentukan dalam RFC dan server lain mungkin tidak menafsirkannya dengan cara ini saya salah, ini ditentukan dalam RFC 2616 di bagian 5.1. 2, meskipun klien tampaknya jarang menggunakan formulir itu. Maaf, saya harus memperbaiki implementasi server HTTP yang saya tulis beberapa waktu lalu ...).

Sekarang, mungkin Anda tidak memiliki situs bernama 'allrequestsallowed.com'. Jadi apa yang terjadi ketika Apache mendapat Host:tajuk (atau setara) untuk nama host yang tidak dikenali? Ini mengambil host virtual pertama sebagai default. Ini adalah perilaku yang terdefinisi dan terdokumentasi dengan baik untuk Apache. Jadi apa pun virtual host pertama Anda (atau hanya konfigurasi server utama jika tidak ada vhosts) mengambil alih, apa pun namanya.

Sekarang, sisa URL yang diberikan terdiri dari dua bagian - path /,, dan parameter GET ( ?PHPSESSID...bit).

Sekarang, path /harus ada pada hampir semua server web di luar sana. Dalam kebanyakan kasus, ini memetakan ke sesuatu seperti index.htmlatau mungkin sebuah index.phpskrip, meskipun Anda dapat mengabaikan semua ini tentu saja.

Jika peta ke file HTML statis, sama sekali tidak ada yang tidak biasa terjadi - konten file dikembalikan, dan hanya itu, parameternya diabaikan. (Dengan asumsi Anda tidak memiliki arahan konfigurasi lanjutan tertentu yang ditetapkan, dan Anda hampir pasti tidak.)

Di sisi lain, jika itu semacam skrip, PHPSESSIDvariabel itu akan diteruskan ke skrip. Jika skrip benar-benar menggunakan variabel itu (dalam kasus khusus ini, hanya skrip PHP yang menggunakan penanganan sesi bawaan PHP yang cenderung), perilakunya akan tergantung pada konten.

Namun, dalam kemungkinan besar, bahkan jika Anda /memetakan ke skrip PHP menggunakan sesi, tidak ada yang luar biasa yang akan terjadi. ID sesi mungkin tidak akan ada, dan akan diabaikan, atau skrip akan menampilkan kesalahan.

Dalam kasus yang tidak mungkin bahwa ID sesi memang ada, well, penyerang dapat membajak sesi orang lain. Itu akan buruk, tetapi itu sebenarnya bukan lubang keamanan itu sendiri - lubang itu akan berada di mana pun penyerang mendapatkan informasi sesi ID dari (mengendus jaringan nirkabel adalah kandidat yang baik jika Anda tidak menggunakan HTTPS). Mereka sebenarnya tidak akan bisa melakukan apa pun yang tidak bisa dilakukan oleh pengguna yang sesi yang awalnya dibuatnya.

Sunting: Selain itu, '% 5C' di dalam SESSIONID memetakan ke karakter backslash. Ini tampaknya menjadi ujian untuk serangan direktori traversal pada host windows.

Nicholas Knight
sumber
Saya memiliki permintaan serupa 404, 500, 403, dan 20x di server saya yang menjalankan nginxatau lighttpd, dan setelah mengirim IP / sumber host ke perusahaan analisis cyber, dipastikan itu adalah upaya untuk mengeksploitasi lubang di server antara lain . Permintaan serupa dengan yang ditentukan oleh OP, host yang berbeda. Apakah Anda mengatakan bahwa mereka harus sepenuhnya diabaikan? Karena jika mereka benar-benar peduli, mereka dapat memblokir host iptables.
Thomas Ward
@The Evil Phoenix: Host di URL tidak dari mana permintaan itu berasal, itu hanya setara dengan header 'Host:'. Alamat IP klien yang sebenarnya, yang dikaburkan OP, dapat diblokir dengan iptables jika dia mau, tetapi kecuali dia dibanjiri permintaan, itu benar-benar tidak masalah. Hanya karena seseorang mencoba mengeksploitasi lubang tidak berarti ada lubang. Saya mengelola banyak server (Linux) yang mencatat banyak permintaan aneh yang dimaksudkan untuk mengeksploitasi lubang setiap hari - kebanyakan dari mereka lubang Windows / IIS! Itu hanya pemindaian buta. Jika tidak terkena, ia pindah ke alamat IP berikutnya.
Nicholas Knight
@The Kejahatan Phoenix: Lebih lanjut, jika lubang yang hadir, memblokir alamat IP yang dieksploitasi itu tidak akan melakukan salah satu dari sedikit yang baik. Server Anda sudah akan dikompromikan, dan masih akan rentan terhadap serangan yang sama dari sumber lain - dan ada banyak sumber. Setiap sistem zombie di luar sana (dan ada jutaan) adalah sumber pemindaian berbahaya.
Nicholas Knight
Penjelasan yang bagus dan menyeluruh .... Terima kasih banyak. Saya mengaburkan IP yang menyinggung kalau-kalau ia ip-ego-surfes :). Peta saya ke default apache "Berhasil" (Saya tahu, betapa tidak profesional ... tapi saya katakan itu pribadi, lol). Jadi saya berasumsi saya harus melakukan apa - apa kecuali IP yang sama menjadi sakit, dalam hal ini saya akan memblokirnya dengan iptables (atau bahkan hosts.deny?). Terima kasih lagi.
luri
1

Saya meminta semua ini dibiarkan masuk pada ip yang digunakan sebagai catatan untuk semua domain parkir kami.

Tembakan saya adalah bahwa nama host ini digunakan dalam kombinasi dengan hostfile lokal "penyerang" yang menunjuk ke host target.

Server web yang sebenarnya di 31.44.184.250 hanya untuk menangani permintaan eksternal.

Pendapat saya: sama sekali tidak berbahaya. Tidak melihat adanya nilai tambah yang digunakan untuk itu kecuali untuk hal-hal yang dapat Anda lakukan dengan nama domain palsu lainnya di hostfile Anda.

Kajje
sumber