Bài liên quan
Một dạng tấn công mới xuất hiện và đặc biệt nguy hiểm đối với các hệ điều hành Linux/Unix, đó là tấn công với tên gọi Shellshock dựa trên một lỗ hổng an toàn của hệ vỏ Bash trong Linux/Unix. Sau khi xem xét lịch sử mã nguồn, người ta đã phát hiện rằng lỗ hổng an toàn này đã tồn tại từ nhiều năm trước đây. Tuy nhiên, tấn công khai thác lỗ hổng này mới chỉ được công bố rộng rãi trên thế giới từ tháng 9/2014. Ngoài ra, còn có một số lỗ hổng an toàn khác trong Linux kernel.
Lỗ hổng Shellshock
Năm 2014, vấn đề an toàn cho các hệ thống thông tin nói chung đang là vấn đề nóng trên toàn thế giới. Đầu tiên là sự kiện về lỗ hổng an toàn được gọi là “Trái tim rỉ máu” – Heart Bleed. Theo Mark J. Cox, một trong các tác giả của thư viện mã nguồn mở về mật mã OpenSSL, Neel Mehta thuộc nhóm bảo mật của Google đã báo cáo một lỗ hổng đặc biệt nghiêm trọng liên quan đến vấn đề cài đặt của phần mở rộng HeartBeat vào ngày 01/4/2014. Lỗi này được đặt tên là HeartBleed bởi một kỹ sư tại công ty an ninh mạng Codenomicon, Phần Lan. Heart Bleed được tìm ra bởi các chuyên gia bảo mật của Google và Codenomicon.
Ảnh hưởng của lỗ hổng Heart Bleed là đặc biệt nghiêm trọng. Các phần mềm sử dụng OpenSSL là các máy chủ web mã nguồn mở như Apache và Nginx, chiếm tới 66% thị phần của các trang web hoạt động trên Internet (theo một cuộc khảo sát Web Server của Netcraft vào tháng 4/2014). Hơn nữa OpenSSL được sử dụng để bảo vệ nhiều ứng dụng khác như máy chủ email (SMTP, POP và IMAP), máy chủ talk (giao thức XMPP), mạng riêng ảo (SSL VPN), các thiết bị mạng và nhiều loại phần mềm phía khách hàng.
Những bàn luận xung quanh lỗ hổng “Trái tim rỉ máu” chưa lắng xuống, thì vào ngày 12/9/2014, Stephane Chazelas đã lại phát hiện ra một lỗ hổng nghiêm trọng khác liên quan đến hệ vỏ Bash của các HĐH dựa trên Unix, được đặt tên là Shellshock (hay Bashdoor) [1]. Rất nhiều ứng dụng trên Internet, các Web server, sử dụng hệ vỏ Bash của HĐH Linux/Unix để xử lý các câu lệnh. Điều này cho phép kẻ tấn công có thể lợi dụng lỗ hổng trong Bash để thực hiện một câu lệnh bất kỳ. Kết quả là kẻ tấn công có thể đoạt được quyền truy cập hợp pháp vào hệ thống.
Những phân tích lịch sử mã nguồn của hệ vỏ Bash chỉ ra rằng, lỗ hổng đã tồn tại từ năm 1992. Nguyên nhân là do Bash cho phép thực thi câu lệnh thông qua các biến môi trường (điều này gần giống như lỗi SQL Injection). Lỗ hổng Shellshock đầu tiên được NIST định danh bởi CVE-2014-6271 với thang điểm cao nhất, điểm 10. Chỉ sau một vài ngày khi lỗ hổng này được công khai, có rất nhiều các biến thể khác nhau của nó đã xuất hiện (CVE-2014-6277, CVE-2014-6278, CVE-2014-7169, CVE-2014-7186 và CVE-2014-7187). Những kẻ tấn công có thể khai thác các lỗ hổng này trong vài giờ, chiếm quyền điều khiển các máy tính và tạo ra một hệ thống botnet để thực hiện tấn công DDoS. Có hàng triệu tấn công đã được các công ty an toàn mạng thông báo sau một vài ngày lỗ hổng đầu tiên được công bố. Shellshock được đánh giá nguy hiểm hơn cả lỗ hổng “Trái tim rỉ máu” do mức độ tác động nghiêm trọng của nó.
Lỗ hổng Shellshock trong hệ vỏ BASH của LINUX/UNIX
Bash là một hệ vỏ mã nguồn mở được sử dụng bởi nhiều hệ thống dựa trên Unix. Bash cho phép thực thi các câu lệnh và các kịch bản dòng lệnh (command scripts). Bash thường được cài đặt mặc định trên các HĐH dựa trên Unix. Trong các HĐH dựa trên Unix và các HĐH mà Bash hỗ trợ (OS X chẳng hạn), mỗi một chương trình đều có một danh sách các cặp tham số (tên/giá trị) được gọi là các biến môi trường.
Các phân tích mã nguồn chỉ ra rằng, lỗ hổng Shellshock tồn tại từ phiên bản 1.13 năm 1992 đến phiên bản 4.3 hiện nay. Khi một chương trình gọi một chương trình khác, nó sẽ tạo ra các biến môi trường cho chương trình mới. Bash duy trì một danh sách các hàm nội tại mà chúng sẽ được thực thi bên trong chương trình. Bash hoạt động với hai vai trò, vừa là bộ thông dịch lệnh, vừa như là một lệnh nên có thể tự thực thi lệnh Bash bên trong nó. Khi điều này xảy ra, các biến môi trường và các định nghĩa hàm có thể được trích xuất (export) từ tiến trình ban đầu sang tiến trình mới. Các định nghĩa hàm được trích xuất bằng cách ghi mã của chúng trong danh sách biến môi trường, mà giá trị của chúng được để trong dấu ngoặc kép (“()”) theo sau định nghĩa hàm. Tiến trình mới của Bash sẽ quét danh sách các biến môi trường của nó và lấy giá trị theo định dạng này để chuyển vào các hàm nội tại của nó. Bash thực hiện việc chuyển đổi này bằng cách tạo ra các phân đoạn mã từ các giá trị trong biến môi trường và thực thi từng phân đoạn mã này, điều đó tạo ra các hàm kiểu “on-the-fly”. Tuy nhiên, Bash lại không kiểm tra tính hợp lệ của các phân đoạn mã (theo định nghĩa hàm). Như vậy, đây là cơ hội để thực thi Bash với một giá trị được lựa chọn trước trong danh sách các biến môi trường của nó. Kẻ tấn công có thể thực hiện một câu lệnh bất kỳ trong bộ thông dịch lệnh của Bash.
Lỗ hổng Shellshock có thể được hiểu và kiểm tra qua việc thực hiện câu lệnh sau đây trong môi trường dòng lệnh của Bash:
| env x=’() {:;}; echo vulnerable!’ bash -c “echo this is a test” |
Đối với các hệ thống sử dụng các phiên bản Bash bị lỗ hổng này, sau khi thực hiện lệnh trên, màn hình sẽ hiện ra chữ “vulnerable!” giống như kết quả thực hiện lệnh “echo vulnerable!” từ dòng lệnh của Bash thông thường. Ở đây ta thấy câu lệnh này đã được nhúng vào trong biến môi trường “x”.
Lỗ hổng Bash như trên lần đầu tiên được phát hiện và được định danh là lỗ hổng CVE-2014-6271. Có nhiều bản vá đã được đưa ra để khắc phục lỗ hổng này, tuy nhiên sau đó vẫn có những báo cáo về các lỗ hổng khác có liên quan. Sau đó, ngày 26/9/2014, các nhà phân phối mã nguồn mở là David A. Wheeler và Norihiro Tanaka đã công bố rằng, các bản vá đưa ra là chưa đủ để khắc phục lỗ hổng này và còn rất nhiều vấn đề an toàn khác liên quan đến bộ phân tích câu lệnh của trình biên dịch Bash có thể bị khai thác. Ngày 27/9/2014, Michał Zalewski đã thông báo rằng anh ta đã khám phá ra nhiều lỗ hổng khác liên quan đến việc Bash được biên dịch mà không có quá trình ngẫu nhiên hóa cách bố trí không gian địa chỉ.
Dưới đây là một ví dụ về việc khai thác để chứng tỏ rằng bản vá cho lỗ hổng CVE-2014-6271 không có tác dụng:
| env X=’() { (a)=>\’ sh -c “echo date”; cat echo |
Kết quả trên màn hình xuất hiện:
| $ X=’() { (a)=>\’ bash -c “echo date”
bash: X: line 1: syntax error near unexpected token `=’
bash: X: line 1: `’
bash: error importing function definition for `X’
$ cat echo
Fri Sep 26 01:37:16 UTC 2014
|
Hệ thống hiển thị cảnh báo “syntax error” cho thấy lỗ hổng CVE-2014-6271 đã được vá, nhưng vẫn tạo ra một file có tên là “echo” với nội dung của file là kết quả của câu lệnh “date”.
Ảnh hưởng của shellshock
Máy chủ dựa trên CGI (CGI-based Web Server): Khi một máy chủ Web sử dụng giao thức Common Gateway Interface (CGI), nó sẽ đưa ra nhiều chi tiết của một yêu cầu cho một chương trình điều khiển trong danh sách biến môi trường. Ví dụ, biến HTTP_USER_AGENT có một giá trị mà theo cách sử dụng thông thường, sẽ định danh chương trình gửi yêu cầu. Nếu chương trình điều khiển yêu cầu là một đoạn mã của Bash (scripts), hoặc nếu nó được thực thi dưới câu lệnh system() của Bash, thì Bash sẽ nhận được các biến môi trường thông qua các máy chủ và sẽ xử lý chúng theo cách ở trên. Điều này cung cấp cho kẻ tấn công cách thức khai thác lỗ hổng Shellshock. Như vậy, các kịch bản CGI sẽ đặc biệt nguy hiểm đối với máy chủ Web nếu nó không được kiểm tra cẩn thận.
Máy chủ SSH (SSH server): OpenSSH có đặc tính “ForceCommand” cho phép một câu lệnh cố định thực thi khi người dùng đăng nhập. Câu lệnh cố định này được thực thi ngay cả khi người dùng đã xác định các lệnh khác, nên được chạy (đặt trong biến môi trường SSH_ORIGINAL_COMMAND). Khi câu lệnh “ForceCommand” thực hiện trong môi trường Bash, Bash sẽ phân tích biến môi trường SSH_ORIGINAL_COMMAND và thực hiện các lệnh được nhúng trong đó. Như vậy kẻ tấn công có thể lợi dụng lỗ hổng Shellshock để thực hiện các lệnh không bị giới hạn trong một tập các lệnh đã được giới hạn.
Hệ thống DHCP: Một vài máy khách DHCP có thể truyền các lệnh cho Bash; một hệ thống có thể bị tấn công khi thực hiện kết nối tới một mạng Wifi mở. Một máy khách DHCP gửi yêu cầu tới máy chủ DHCP và nhận lại địa chỉ IP, nhưng nó cũng có thể chứa các tùy chọn khác và tạo ra một lỗi Shellshock nhằm thực hiện một lệnh Bash trên hệ thống máy khách DHCP.
Hệ thống Email: Chẳng hạn một hệ thống Qmail chạy trên Unix, có thể bị tấn công nếu như máy chủ mail cho phép đưa vào môi trường Bash những đầu vào không được kiểm tra.
Hệ thống các máy tính độc lập: Lỗ hổng Shellshock cũng có thể ảnh hưởng đến các máy tính độc lập không trực tiếp truy cập Internet nhưng có sử dụng Bash.
Giao diện IBM console: Các giao diện console quản lý phần cứng của IBM cũng có thể bị tấn công. IBM cũng đã công bố các bản vá cho thiết bị của mình [2].
Các lỗ hổng an toàn của LINUX KERNEL
Ngoài các vấn đề về an toàn cho hệ vỏ (giống như hệ vỏ Bash ở trên), an toàn mức ứng dụng, an toàn dịch vụ, thì an toàn cho Kernel là một trong những vấn đề trọng tâm cần chú ý khi xây dựng và phát triển các ứng dụng dựa trên HĐH mã nguồn mở Linux/Unix. Những lỗ hổng được liệt kê dưới đây, không chỉ ảnh hưởng cho các hệ thống máy tính cài Linux thông thường mà có thể tác động tới các hệ thống nhúng sử dụng Linux, các routers, các thiết bị không dây cài Linux OS.
Đã có khoảng 1200 lỗ hổng đối với Linux kernel kể từ năm 1999 đến 2014 được công bố công khai trên trang web http://www.cvedetails.com, với mức độ nguy hiểm được xếp hạng tăng dần theo thang điểm từ 1 đến 10. Trong đó, lỗi tấn công DDoS chiếm 60%, tấn công tràn bộ đệm chiếm 16%, tấn công khai thác bộ nhớ và thực thi mã lệnh là 10,5%. Ví dụ, Linux kernel phiên bản 3.2.17, có tổng cộng 188 lỗ hổng từ khi phiên bản này xuất hiện cho đến phiên bản mới nhất 3.16.x, trong đó số các lỗ hổng có điểm số lớn hơn 5 là 58 (chiếm khoảng 30%). Đặc biệt có những lỗ hổng được đánh giá đặc biệt nguy hiểm (điểm 10) được liệt kê trong bảng dưới đây.
Thay cho lời Kết
Với sự xuất hiện của lỗ hổng nghiêm trọng của hệ vỏ Bash trên các HĐH Linux/Unix và những lỗ hổng hiện tại của Linux kernel thì việc nghiên cứu, xây dựng các phần mềm ứng dụng cũng như các phần mềm an ninh an toàn thông tin dựa các HĐH mã nguồn mở là một hướng đi đúng đắn và thích hợp. Bên cạnh đó, chúng ta cần phải có những nghiên cứu, đánh giá an toàn tổng thể cho các hệ thống CNTT đã và đang được xây dựng.
TS. Nguyễn Quốc Toàn
Post a Comment