Lỗ hổng Shellshock là gì? Cơ chế, tác động và cách khắc phục

Một lỗi trong cách Bash xử lý biến môi trường đã tồn tại nhiều năm trước khi được công bố năm 2014. Do Bash được triển khai rộng trên nhiều hệ thống Unix-like, lỗ hổng Shellshock nhanh chóng trở thành một vấn đề an ninh nghiêm trọng. 

Bài viết dưới đây giải thích Shellshock là gì, vì sao lỗi này có thể bị khai thác từ xa trong một số điều kiện, cách kiểm tra và khắc phục cũng như mức độ liên quan của nó với hệ thống hiện nay. 

Lỗ hổng Shellshock là gì?

Shellshock (CVE-2014-6271) là lỗ hổng thực thi mã từ xa (Remote Code Execution, RCE) trong GNU Bash, được công bố ngày 24/9/2014. Lỗi do nhà nghiên cứu Stéphane Chazelas phát hiện. Theo mô tả của NVD, các phiên bản GNU Bash đến 4.3 chưa được vá bị ảnh hưởng. Mức độ ảnh hưởng cụ thể cần đối chiếu với bản phân phối và bản vá của nhà cung cấp, vì nhiều bản phân phối vá lỗi nhưng vẫn giữ nguyên số phiên bản của gói.

Về mức độ nghiêm trọng, CVE-2014-6271 được đánh giá 9,8/10 theo thang CVSS v3.1, thuộc nhóm Critical. Điểm số này cần được đọc cùng bối cảnh khai thác thực tế, vì khả năng bị tấn công phụ thuộc vào cách hệ thống đưa dữ liệu bên ngoài vào Bash.

Bash (Bourne-Again Shell) là trình thông dịch dòng lệnh dùng để chạy lệnh và script. Vào thời điểm lỗi được công bố, Bash được triển khai rất rộng trên các hệ thống Unix-like. Nhiều bản phân phối Linux và các phiên bản OS X khi đó sử dụng Bash, khiến phạm vi hệ thống cần kiểm tra rất lớn. Cơ quan CISA của Mỹ cũng lưu ý rằng nhiều hệ điều hành kiểu UNIX, gồm các bản phân phối Linux và Apple Mac OS X, có Bash và có khả năng bị ảnh hưởng.

Nguyên nhân gốc của Shellshock

Bash cho phép truyền một hàm sang tiến trình con thông qua biến môi trường. Khi một phiên Bash mới khởi động, nó đọc các biến này và nạp lại định nghĩa hàm. Lỗi nằm ở chỗ các phiên bản chưa vá không dừng lại sau phần định nghĩa hàm. Phần văn bản đi sau đó cũng bị xử lý như một lệnh và được thực thi ngay khi Bash khởi tạo môi trường.

Hệ quả là lệnh này chạy với đúng quyền của tiến trình đang gọi Bash. Nếu tiến trình đó là một dịch vụ chạy với quyền cao, tác động có thể nghiêm trọng hơn. Cần lưu ý rằng lỗi không nằm ở một tính năng cụ thể của máy chủ web hay dịch vụ SSH. Đây là cách Bash phân tích biến môi trường, còn các thành phần khác chỉ trở thành "cửa vào" khi chúng chuyển dữ liệu bên ngoài vào biến môi trường của tiến trình Bash.

Vì sao Shellshock có thể bị khai thác từ xa?

Có Bash chưa vá không tự động đồng nghĩa với việc hệ thống có thể bị tấn công từ Internet. Điều kiện quan trọng là một thành phần bên ngoài đưa dữ liệu do bên khác kiểm soát vào biến môi trường, sau đó tiến trình Bash được gọi. NVD nêu một số tình huống điển hình dưới đây.

Web server và CGI

CGI là cơ chế cho phép máy chủ web chạy một chương trình bên ngoài để tạo nội dung. Máy chủ truyền thông tin từ yêu cầu HTTP sang chương trình đó dưới dạng biến môi trường. Với các module như mod_cgi và mod_cgid của Apache HTTP Server, nếu chương trình được gọi là một script Bash hoặc có gọi đến Bash, dữ liệu lấy từ yêu cầu của người dùng có thể đi vào môi trường của Bash. Đây là kịch bản khiến lỗ hổng có thể bị khai thác từ xa qua mạng.

OpenSSH, DHCP và các vector khác

NVD cũng ghi nhận tính năng ForceCommand của OpenSSH sshd, vốn dùng để giới hạn người dùng chỉ được chạy một lệnh cố định. Trong trường hợp này, người dùng cần được xác thực trước, nên phạm vi rủi ro hẹp hơn so với CGI. Một số script do DHCP client chạy khi nhận cấu hình mạng cũng được nêu là có thể bị ảnh hưởng. Ngoài ra, mô tả của NVD đề cập chung các tình huống mà môi trường được thiết lập khi vượt qua ranh giới đặc quyền trước lúc Bash thực thi.

Shellshock không chỉ có một CVE: chuỗi lỗ hổng liên quan

CVE-2014-6271 là lỗ hổng ban đầu. Bản sửa đầu tiên chưa xử lý toàn bộ vấn đề, nên CVE-2014-7169 được công bố cho lỗi tương tự vẫn còn sau bản vá. Quá trình rà soát Bash sau đó phát hiện thêm CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 và CVE-2014-6278. Vì vậy, chỉ áp dụng bản vá đầu tiên là chưa đủ.

CISA liệt kê cả sáu CVE này trong cảnh báo về Shellshock và khuyến nghị quản trị viên theo dõi các bản vá cập nhật từ nhà cung cấp. Các bản vá được phát hành liên tiếp trong những ngày cuối tháng 9/2014.

Các bản vá hoàn chỉnh thay đổi cách Bash nhận diện và nhập các hàm được xuất từ biến môi trường, đồng thời siết việc phân tích phần nội dung đi sau định nghĩa hàm. Một số triển khai dùng namespace riêng như BASH_FUNC_ để tránh coi biến môi trường thông thường là hàm của Bash. Cách triển khai cụ thể có thể khác nhau giữa các nhà cung cấp.

Hệ thống nào có thể bị ảnh hưởng?

Phạm vi ảnh hưởng nên được xác định theo điều kiện khai thác, không chỉ theo hệ điều hành. Bảng dưới đây tóm tắt các nhóm thành phần cần rà soát.

Rủi ro phụ thuộc vào việc dữ liệu bên ngoài có đi vào biến môi trường của tiến trình Bash hay không. Với thiết bị nhúng và hệ thống cũ, vấn đề thường nằm ở chỗ không còn bản cập nhật hoặc không ai theo dõi phiên bản Bash bên trong. Nhóm này cần được kiểm kê riêng.

Cách kiểm tra và khắc phục Shellshock

Xác định Bash và trạng thái bản vá

Bước đầu là kiểm kê nơi Bash đang được cài đặt và đang được gọi. Lệnh bash --version cho biết phiên bản, nhưng số phiên bản chưa đủ để kết luận. Nhiều bản phân phối vá lỗi theo cách backport và vẫn giữ số phiên bản gốc. Vì vậy cần đối chiếu với changelog của gói hoặc trang theo dõi bảo mật của nhà cung cấp, xem đã có CVE-2014-6271 và các CVE liên quan hay chưa.

Với hệ thống dùng gói RPM, có thể xem changelog của gói bằng lệnh sau. Trên Debian và Ubuntu, thông tin tương tự nằm trong changelog của gói bash.

rpm -q --changelog bash

Trong môi trường doanh nghiệp, các công cụ quản lý lỗ hổng được cấp phép giúp kiểm tra trên diện rộng. Ví dụ, Qualys đã công bố các tín hiệu phát hiện riêng cho Shellshock và các CVE liên quan. Không nên tự chạy chuỗi thử khai thác lên hệ thống production hoặc hệ thống không thuộc quyền quản lý của mình.

Cập nhật Bash theo hướng dẫn của nhà cung cấp

Cách khắc phục chính là cập nhật gói Bash từ kho chính thức của bản phân phối. Các bản phân phối Linux lớn và Apple đã phát hành bản vá từ tháng 9/2014. Trên Debian và Ubuntu, có thể cập nhật riêng gói Bash bằng lệnh sau. Các bản phân phối khác dùng lệnh tương đương của trình quản lý gói.

sudo apt-get update && sudo apt-get install --only-upgrade bash

Sau khi cập nhật, cần kiểm tra lại trạng thái bản vá theo cách nêu ở phần trên. Nên làm theo hướng dẫn của nhà cung cấp về việc có cần khởi động lại dịch vụ hay không.

Biện pháp giảm thiểu bổ sung

Các biện pháp dưới đây là lớp bảo vệ bổ sung, không thay thế việc vá lỗi.

- Dùng tường lửa ứng dụng web (WAF) để chặn các mẫu yêu cầu bất thường liên quan đến Shellshock.

- Tắt CGI nếu không sử dụng và cân nhắc tránh dùng script Bash cho các chương trình CGI.

- Áp dụng nguyên tắc đặc quyền tối thiểu cho các dịch vụ gọi đến Bash.

- Kiểm kê và cách ly các thiết bị cũ chưa thể cập nhật.

- Giám sát nhật ký hệ thống để phát hiện hành vi bất thường.

Shellshock còn ảnh hưởng đến hệ thống hiện nay không? 

Các bản phân phối Linux lớn và Apple đã phát hành bản vá từ tháng 9/2014, nên hệ thống hiện đại được cập nhật đều đặn thường không còn dễ bị tổn thương. Tuy vậy, chủ đề này không chỉ mang tính lịch sử. CVE-2014-6271 hiện vẫn nằm trong danh mục Known Exploited Vulnerabilities (KEV) của CISA, tức là có bằng chứng về việc lỗ hổng từng bị khai thác trong thực tế.

Những nhóm cần lưu ý gồm thiết bị nhúng, thiết bị chuyên dụng (appliance) đời cũ, máy chủ không còn được bảo trì, cùng máy ảo mẫu hoặc image container cũ vẫn chứa phiên bản Bash chưa vá. Vì lỗ hổng đã được công bố công khai từ lâu, mọi hệ thống chưa vá nên được coi là có rủi ro và cần được xử lý.

Bài học cho quản trị hệ thống

Shellshock cho thấy rủi ro có thể nằm ở phần mềm nền tảng ít được để ý, thay vì chỉ ở ứng dụng. Có bốn bài học chính.

- Quản lý tài sản và phiên bản: cần biết hệ thống nào đang dùng thành phần nào, kể cả những thành phần nền như Bash.

- Không tin dữ liệu từ bên ngoài đi vào môi trường thực thi: dữ liệu từ yêu cầu HTTP hay mạng cần được xử lý cẩn thận trước khi chạm đến trình thông dịch.

- Vá đầy đủ, không dừng ở bản vá đầu tiên: chuỗi CVE liên quan cho thấy bản sửa ban đầu có thể chưa xử lý hết vấn đề.

- Phòng thủ nhiều lớp: WAF, đặc quyền tối thiểu và giám sát giúp giảm thiệt hại khi một lớp bị vượt qua.

Câu hỏi thường gặp về Shellshock (FAQs)

Hệ thống không chạy web server có bị ảnh hưởng không? Vẫn có thể có Bash chưa vá trên hệ thống. Khả năng bị khai thác từ xa phụ thuộc vào các thành phần như CGI, ForceCommand của SSH hay script DHCP client. Không nên loại trừ rủi ro chỉ vì không có web server, và vẫn nên cập nhật Bash.

Shellshock khác Heartbleed như thế nào? Heartbleed là lỗi trong thư viện OpenSSL, cho phép đọc trái phép dữ liệu từ bộ nhớ của tiến trình. Shellshock nằm trong Bash và cho phép thực thi lệnh. Hai lỗ hổng cùng được biết đến rộng rãi vào năm 2014 nhưng có bản chất kỹ thuật khác nhau.

Đã dùng bản phân phối mới thì có cần lo về Shellshock không? Nếu hệ thống được cập nhật đều đặn, các bản vá đã có từ năm 2014. Tuy vậy, vẫn nên kiểm tra các thiết bị cũ, máy ảo mẫu và image container cũ, vì chúng có thể chứa phiên bản Bash chưa được vá.

Kết luận

Shellshock là lỗ hổng thực thi mã từ xa trong Bash, xuất phát từ cách Bash xử lý biến môi trường. Nguy cơ thực tế phụ thuộc vào việc dữ liệu bên ngoài có đi vào biến môi trường của tiến trình Bash hay không, thông qua các thành phần như CGI, ForceCommand hoặc script DHCP client. Vì đây là một chuỗi CVE, việc vá cần đầy đủ chứ không dừng ở bản sửa đầu tiên. Với hệ thống hiện đại, rủi ro chủ yếu còn lại nằm ở thiết bị cũ và hệ thống không được bảo trì, nên việc kiểm kê và cập nhật vẫn có giá trị thực tế.

Để tìm hiểu thêm về dịch vụ, vui lòng liên hệ đến Viettel IDC:

- Hotline: 1800.8088 (miễn phí cước gọi)

- Fanpage: https://www.facebook.com/viettelidc

- Website: https://viettelidc.com.vn/

Viettel IDC - Nhà cung cấp dẫn đầu về giải pháp Trung tâm dữ liệu và Điện toán đám mây tại Việt Nam