Làm cách nào để kiểm tra xem máy chủ của tôi có dễ bị lỗi ShellShock không?


80

Làm cách nào tôi có thể đảm bảo cài đặt Bash của mình không dễ bị lỗi ShellShock nữa sau khi cập nhật?



Xin lưu ý rằng có hai lỗ hổng khác trong bash vẫn chưa được vá (CVE-2014-7186 và CVE-2014-7187).
Deer Hunter

Các bản vá sửa CVE-2014-7186 và CVE-2014-7187 có sẵn kể từ không lâu sau khi Deer Hunter đăng bình luận của mình. Nếu bạn có bản vá được cung cấp cho CVE-2014-7169, bạn có thể đã có đủ để chặn 7186/7187, hãy kiểm tra hệ thống của bạn bằng các lệnh bên dưới và xem. Ngoài ra kiểm tra bất kỳ cập nhật bảo mật hơn cho bản phân phối của bạn.
BeowulfNode42

Câu trả lời:


83

Để kiểm tra lỗ hổng CVE-2014-6271

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

nó KHÔNG nên lặp lại từ dễ bị tổn thương.


Để kiểm tra lỗ hổng CVE-2014-7169
(cảnh báo: nếu lỗi của bạn, nó sẽ tạo hoặc ghi đè lên một tệp có tên /tmp/echobạn có thể xóa sau và cần xóa trước khi kiểm tra lại)

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

Nó nên nói từ ngày sau đó phàn nàn với một tin nhắn như thế nào cat: echo: No such file or directory. Nếu thay vào đó, nó cho bạn biết thời gian hiện tại là gì thì hệ thống của bạn dễ bị tấn công.


Để kiểm tra 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"

nó KHÔNG nên lặp lại văn bản CVE-2014-7186 vulnerable, redir_stack.


Để kiểm tra 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"

nó KHÔNG nên lặp lại văn bản CVE-2014-7187 vulnerable, word_lineno.


Để kiểm tra CVE-2014-6277. Tôi không chắc chắn 100% về điều này vì nó dường như dựa vào một hệ thống được vá một phần mà tôi không còn có quyền truy cập.

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

Một kết quả vượt qua trên cái này là nó CHỈ lặp lại văn bản testing CVE-2014-6277. Nếu nó chạy perl hoặc nếu nó phàn nàn rằng perl không được cài đặt thì đó chắc chắn là một lỗi. Tôi không chắc chắn về bất kỳ đặc điểm thất bại nào khác vì tôi không còn có bất kỳ hệ thống nào chưa được vá.


Để kiểm tra CVE-2014-6278. Một lần nữa, tôi không chắc chắn 100% nếu thử nghiệm này vì tôi không còn bất kỳ hệ thống nào chưa được vá.

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

Một vượt qua cho bài kiểm tra này là nó CHỈ nên trả lại văn bản testing CVE-2014-6278. Nếu tiếng vang của bạn trở lại hi mombất cứ nơi nào chắc chắn là một thất bại.


1
Chúng ta có thể thêm bài kiểm tra chung foo='() { echo not patched; }' bash -c foonày không? Cho đến khi xuất khẩu hàm được đặt trong một không gian tên riêng biệt, chúng tôi sẽ không ngừng chạy từ một lỗi trình phân tích cú pháp sang lỗi tiếp theo.
billyw

Bài kiểm tra đó có CVE không? Bạn có bất kỳ tài liệu tham khảo để mô tả vấn đề này? Ngoài ra loại thông tin này có thể thuộc về một trong những câu hỏi khác về shellshock do Q này là về cách kiểm tra sự thành công hay thất bại của các bản vá hiện có.
BeowulfNode42

Đó là từ bài đăng trên blog của Michal Zalewski trên một số CVE của Shellshock sắp tới ( lcamtuf.blogspot.com/2014/09/ khăn ). Đây là thử nghiệm được đề xuất của anh ấy cho CVE-2014-6278, vẫn chưa được công khai. Dường như tôi đã sai về tính tổng quát của bài kiểm tra; Tôi đã gặp trường hợp thử nghiệm của Zalewski nhưng thử nghiệm CVE-2014-7187 không thành công.
billyw

Và đây là những tiết lộ đầy đủ trên bản tin CVE-2014-6277 và CVE-2014-6278, cùng với các lệnh để kiểm tra đối với họ: seclists.org/fulldisclosure/2014/Oct/9
billyw

Một điểm lưu ý: ngay cả khi phiên bản BASH dễ bị tấn công, nếu không có gì sử dụng nó (tức là tất cả các tài khoản được sử dụng bởi daemon, chẳng hạn như "www" hoặc "cup" hoặc bất cứ thứ gì) đều được cấu hình với BASH làm vỏ mặc định của chúng và không mã của bạn gọi hệ thống () hoặc tương tự, có phiên bản dễ bị tổn thương có thể ít rủi ro hơn, nhưng vẫn có thể nâng cấp BASH càng sớm càng tốt.
DTK

32

Xuất một biến môi trường được chế tạo đặc biệt sẽ được đánh giá tự động bởi các phiên bản dễ bị tổn thương của Bash:

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

Bây giờ hãy thực hiện một tiếng vang đơn giản để xem Bash sẽ đánh giá mã trong $ testorms mặc dù bạn chưa sử dụng biến đó:

$ bash -c "echo Hello"
VULNERABLE
Hello

Nếu nó hiển thị chuỗi "VULNERABLE", câu trả lời là rõ ràng. Mặt khác, bạn không cần phải lo lắng và phiên bản vá lỗi của Bash vẫn ổn.

Xin lưu ý rằng nhiều bản vá đã được phát hành bởi các bản phân phối chính của Linux và đôi khi chúng không khắc phục hoàn toàn lỗ hổng. Tiếp tục kiểm tra các tư vấn bảo mật và mục CVE cho lỗi này.


5
Ngoài CVE-2014-6271, bản sửa lỗi chưa hoàn chỉnh từ Red Hat nói riêng cũng có giá trị riêng của nó cũng có giá trị sau: CVE-2014-7169 .
DocMax

3
Một lớp lót không làm ô nhiễm vỏ env của bạn và tình exportenv testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
cờ

1
Có một số chi tiết cụ thể Ubuntu đây askubuntu.com/questions/528101/... - Cá nhân tôi đã phải nâng cấp từ Ubuntu 13,10-14,04 để khắc phục vấn đề
dodgy_coder

2

ShellShock thực tế là sự kết hợp của nhiều hơn một lỗ hổng của bash , và tại thời điểm này cũng có ý thức về việc khai thác lỗ hổng này , vì vậy ShellShock có thể là một vấn đề vẫn đang mở, có một luồng với các cập nhật từ RedHat về vấn đề này .

Redhat khuyến nghị như sau:

Chạy lệnh:

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

Nếu đầu ra là:

$ 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

bạn không có bất kỳ sửa chữa.

Nếu đầu ra là:

$ 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

bạn đã CVE-2014-6271sửa

Nếu đầu ra của bạn là:

$ 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

bạn không dễ bị tổn thương

Phần khác của kiểm tra ShellShock là kiểm tra lỗ hổng CVE-2014-7169 đảm bảo hệ thống được bảo vệ khỏi sự cố tạo tệp. Để kiểm tra xem phiên bản Bash của bạn có dễ bị CVE-2014-7169 không, hãy chạy lệnh sau:

$ 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

Nếu hệ thống của bạn dễ bị tấn công, thời gian và ngày sẽ hiển thị và / tmp / echo sẽ được tạo.

Nếu hệ thống của bạn không dễ bị tấn công, bạn sẽ thấy đầu ra tương tự như:

$ 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

2

Tôi đã viết một tiện ích CLI có tên ShellShocker để kiểm tra máy chủ web của bạn về các lỗ hổng trên các tập lệnh CGI. Để kiểm tra trang web của bạn, bạn sẽ chạy:

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

I E

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

EDIT: tiện ích này đã bị gỡ xuống, xin lỗi: '(


Liên kết của bạn đã chết
SSK

@SSK Xin lỗi;) Lỗi.
Liam Marshall

Liên kết của bạn vẫn còn chết.
Mxx

Yep, xin lỗi, tôi đã đưa nó xuống. Nó đã được khai thác theo những cách tôi không thích.
Liam Marshall

1

Bạn có thể gửi URL CGI của mình cho bài kiểm tra trực tuyến này:

http://shellshock.iecra.org


4
Đó là lịch sự để cung cấp lý do cho downvote.
David

4
"Chúng tôi đăng nhập tất cả các lần quét" ??? Rùng mình. Tôi sẽ tải con trăn và tự chạy nó.
Brad

1
@brad ít nhất họ đang nói với bạn. Tôi chắc chắn rằng nếu tôi đang cung cấp dịch vụ bảo mật trắng cung cấp dịch vụ này, tôi có thể giữ một bản ghi (nếu chỉ là một bộ đếm không có chi tiết riêng lẻ) về việc có bao nhiêu người mù nhập chi tiết trang web của họ vào một trang web cho biết nó sẽ hoạt động để thử kiểm tra thâm nhập, mà không biết nhiều về tính xác thực của trang web cung cấp thử nghiệm ... và họ muốn có nhật ký kiểm tra xem ai đã sử dụng dịch vụ của họ để tìm các trang dễ bị tổn thương thuộc về người khác, ...
Rob Moir

-1

gõ env x = '() {:;}; echo dễ bị tổn thương 'bash -c "echo đây là một thử nghiệm" và nếu điều này trở lại dễ bị tổn thương và đây là một thử nghiệm thì có nghĩa là máy OSX / Linux của bạn bị ảnh hưởng. Biện pháp khắc phục là cập nhật lên phiên bản bash mới nhất.


6
Tại sao là root? Hoàn toàn không cần thiết.
Mat
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.