Bagaimana cara menguji apakah server saya rentan terhadap bug ShellShock?

80

Bagaimana saya bisa memastikan instalasi Bash saya tidak rentan terhadap bug ShellShock lagi setelah pembaruan?

Giovanni Tirloni
sumber
Harap dicatat ada dua kerentanan lain di bash yang masih belum ditambal (CVE-2014-7186 dan CVE-2014-7187).
Deer Hunter
Tambalan yang memperbaiki CVE-2014-7186 dan CVE-2014-7187 tersedia tidak lama setelah Deer Hunter memposting komentarnya. Jika Anda memiliki patch yang disediakan distro untuk CVE-2014-7169 Anda mungkin sudah memiliki cukup untuk memblokir 7186/7187, uji sistem Anda dengan perintah di bawah ini dan lihat. Periksa juga pembaruan keamanan lagi untuk distro Anda.
BeowulfNode42

Jawaban:

83

Untuk memeriksa kerentanan CVE-2014-6271

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

seharusnya TIDAK menggemakan kembali kata rentan.


Untuk memeriksa kerentanan CVE-2014-7169
(peringatan: jika gagal, kerentanan akan membuat atau menimpa file yang dipanggil /tmp/echoyang dapat Anda hapus setelahnya, dan perlu dihapus sebelum pengujian lagi)

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

itu harus mengatakan tanggal kata lalu mengeluh dengan pesan seperti cat: echo: No such file or directory. Jika sebaliknya ia memberi tahu Anda apa itu datetime saat ini maka sistem Anda rentan.


Untuk memeriksa CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

seharusnya TIDAK menggemakan kembali teks CVE-2014-7186 vulnerable, redir_stack.


Untuk memeriksa CVE-2014-7187

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

seharusnya TIDAK menggemakan kembali teks CVE-2014-7187 vulnerable, word_lineno.


Untuk memeriksa CVE-2014-6277. Saya tidak 100% yakin pada yang satu ini karena tampaknya mengandalkan sistem yang ditambal sebagian yang saya tidak lagi memiliki akses.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

Hasil lulus yang ini adalah HANYA menggemakan kembali teks testing CVE-2014-6277. Jika menjalankan perl atau jika perl bahwa perl tidak diinstal itu pasti gagal. Saya tidak yakin tentang karakteristik kegagalan lainnya karena saya tidak lagi memiliki sistem yang belum ditambal.


Untuk memeriksa CVE-2014-6278. Sekali lagi, saya tidak 100% yakin apakah tes ini karena saya tidak lagi memiliki sistem yang belum ditambal.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

Lulus untuk tes ini adalah bahwa itu HANYA harus mengulangi teks testing CVE-2014-6278. Jika gema Anda kembali ke hi mommana saja itu pasti gagal.

BeowulfNode42
sumber
1
Bisakah kita menambahkan tes umum foo='() { echo not patched; }' bash -c foountuk ini? Sampai ekspor fungsi dimasukkan ke dalam namespace yang terpisah, kami tidak akan berhenti menjalankan dari satu bug parser ke yang berikutnya.
billyw
Apakah tes itu memiliki CVE? Apakah Anda memiliki referensi untuk menjelaskan masalah ini? Juga info semacam ini mungkin berasal dari salah satu pertanyaan lain tentang shellshock karena Q ini adalah tentang cara menguji keberhasilan atau kegagalan patch yang ada.
BeowulfNode42
Itu dari posting blog Michal Zalewski di beberapa Shellshock CVE mendatang ( lcamtuf.blogspot.com/2014/09/… ). Ini tes yang disarankan untuk CVE-2014-6278, yang masih non-publik. Sepertinya saya salah tentang generalisasi tes; Saya sudah menemukan kasus di mana tes Zalewski lulus tetapi tes CVE-2014-7187 gagal.
billyw
Dan di sini adalah pengungkapan lengkap tentang CVE-2014-6277 dan CVE-2014-6278, bersama dengan perintah untuk memeriksa mereka: seclists.org/fulldisclosure/2014/Oct/9
billyw
Satu hal yang perlu diperhatikan: meskipun versi BASH rentan, jika tidak ada yang menggunakannya (yaitu semua akun yang digunakan oleh daemon, seperti "www" atau "cangkir" atau apa pun) dikonfigurasikan dengan BASH sebagai shell default mereka, dan tidak ada kode Anda memanggil sistem () atau sejenisnya, memiliki versi yang rentan mungkin kurang berisiko, tetapi tetap saja meningkatkan BASH sesegera mungkin.
DTK
32

Ekspor variabel lingkungan buatan khusus yang akan dievaluasi secara otomatis oleh versi rentan Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Sekarang jalankan gema sederhana untuk melihat apakah Bash akan mengevaluasi kode dalam $ testbug meskipun Anda sendiri belum pernah menggunakan variabel itu:

$ bash -c "echo Hello"
VULNERABLE
Hello

Jika menunjukkan string "VULNERABLE", jawabannya jelas. Jika tidak, Anda tidak perlu khawatir dan versi Bash yang Anda tempel OK.

Harap dicatat beberapa tambalan telah dirilis oleh distribusi Linux utama dan terkadang mereka tidak memperbaiki kerentanan sepenuhnya. Terus periksa saran keamanan dan entri CVE untuk bug ini.

Giovanni Tirloni
sumber
5
Selain CVE-2014-6271, perbaikan yang tidak lengkap dari Red Hat khususnya memiliki sendiri yang juga layak berikut: CVE-2014-7169 .
DocMax
3
One-liner yang tidak mencemari shell Anda dan kebetulan bekerja walaupun Anda menggunakan shell login alternatif (yang mungkin tidak tahu export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki
1
Ada beberapa perincian spesifik Ubuntu di sini askubuntu.com/questions/528101/... - secara pribadi saya harus memutakhirkan dari Ubuntu 13,10 ke 14,04 untuk memperbaiki masalah
dodgy_coder
2

ShellShock secara praktis merupakan gabungan dari lebih dari satu kerentanan bash , dan saat ini ada juga malaware yang mengeksploitasi kerentanan ini , sehingga ShellShock dapat menjadi masalah yang masih terbuka, ada utas dengan pembaruan dari RedHat tentang masalah ini .

Redhat merekomendasikan yang berikut:

Jalankan perintah:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

Jika output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

Anda tidak memiliki perbaikan apa pun.

Jika output:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

Anda telah CVE-2014-6271memperbaikinya

Jika output Anda adalah:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

Anda tidak rentan.

Bagian lain dari pemeriksaan ShellShock adalah pemeriksaan kerentanan CVE-2014-7169 memastikan bahwa sistem dilindungi dari masalah pembuatan file. Untuk menguji apakah versi Bash Anda rentan terhadap CVE-2014-7169, jalankan perintah berikut:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

Jika sistem Anda rentan, waktu dan tanggal akan ditampilkan dan / tmp / echo akan dibuat.

Jika sistem Anda tidak rentan, Anda akan melihat output yang mirip dengan:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory
Eduard Florinescu
sumber
2

Saya menulis sebuah utilitas CLI bernama ShellShocker untuk menguji server web Anda untuk kerentanan pada skrip CGI. Untuk menguji situs Anda, Anda akan menjalankan:

python shellshocker.py <your-server-address>/<cgi-script-path>

yaitu

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

EDIT: utilitas ini sudah dihapus, maaf: '(

Liam Marshall
sumber
Tautan Anda sudah mati
SSK
@ SKK Maaf;) Kesalahan ketik.
Liam Marshall
Tautan Anda masih mati.
Mxx
Yap, maaf, saya mengambilnya. Itu dieksploitasi dengan cara yang tidak saya sukai.
Liam Marshall
1

Anda dapat mengirimkan URL CGI Anda ke tes online ini:

http://shellshock.iecra.org

pengguna245089
sumber
4
Adalah sopan untuk memberikan alasan untuk downvotes.
David
4
"Kami mencatat semua pemindaian" ??? Mengerikan. Saya akan mengunduh python dan menjalankannya sendiri.
Brad
1
@ brad setidaknya mereka memberitahumu. Saya yakin bahwa jika saya menyediakan layanan keamanan whitehat yang menawarkan layanan ini, saya mungkin menyimpan log (jika hanya sebuah penghitung tanpa rincian individu) tentang berapa banyak orang yang secara membabi buta memasukkan rincian situs mereka ke dalam situs web yang mengatakan akan untuk mencoba tes penetrasi, tanpa tahu banyak tentang keaslian situs yang menawarkan tes ... dan mereka ingin log siapa yang menguji apa jika seseorang menggunakan layanan mereka untuk menemukan situs rentan milik orang lain, juga ...
Rob Moir
-1

ketik env x = '() {:;}; gema rentan 'bash -c "gema ini adalah tes" dan jika ini kembali rentan dan ini adalah tes itu berarti bahwa mesin OSX / Linux Anda terpengaruh. Remedy adalah memperbarui ke versi bash terbaru.

Hen-Al
sumber
6
Kenapa sebagai root? Sama sekali tidak perlu.
Mat