Xz/liblzma: Giải thích lớp làm rối ở giai đoạn Bash

Giải thích lớp làm rối ở giai đoạn Bash

• Đã phát hiện backdoor trong xz/liblzma. Nó ảnh hưởng đến máy chủ OpenSSH.
• Thay vì tập trung vào tệp nhị phân có chứa backdoor, bài viết chú ý đến phần bash ban đầu và phương pháp làm rối đơn giản nhưng khéo léo đã được sử dụng.
• Bài viết này giải thích cách giai đoạn bash được làm rối và trích xuất.

Trước khi bắt đầu

• Hai phiên bản của xz/liblzma (5.6.0 và 5.6.1) bị ảnh hưởng. Có một số khác biệt nhỏ.
• Phần bash được chia thành ba giai đoạn (hoặc bốn giai đoạn?) và mỗi giai đoạn được đặt tên từ Stage 0 đến Stage 2.
• Bài viết cũng sẽ đề cập đến "Stage 3", nhưng có thể nó vẫn chưa được triển khai hoàn toàn.
• Các giai đoạn đã bị làm rối/mã hóa và backdoor nhị phân ở phía sau được giấu trong hai tệp kiểm thử.

Stage 0

• Bắt đầu từ tệp m4/build-to-host.m4. Đoạn mã này được thực thi ở đâu đó trong quá trình build để trích xuất script Stage 1.
• Nó đọc các byte từ tệp kiểm thử, gửi chúng ra đầu ra chuẩn và dùng lệnh tr để ánh xạ ký tự sang ký tự khác.

Stage 1

• Một tệp bash bắt đầu bằng "####Hello####". Nó được thiết kế để chỉ chạy trên Linux.
• Nó dùng eval để trích xuất srcdir từ config.status, đồng thời chứa một chuỗi lệnh head phức tạp nhằm bỏ qua các byte cụ thể rồi xuất ra.
• Nó dùng lệnh tr để áp dụng một mật mã thay thế đơn giản, sau đó giải nén bằng lệnh xz và thực thi.

Stage 2

• Stage 2 là script bash chỉnh sửa quy trình biên dịch thực tế.
• Có vẻ như tồn tại một hệ thống "mở rộng/vá" để có thể chạy script mới mà không cần tiếp tục chỉnh sửa các tệp kiểm thử.
• Nó bao gồm mã để trích xuất các tệp .o và tích hợp chúng vào quá trình biên dịch/liên kết.

Tóm tắt

• Quá trình này được che giấu rất kỹ và được cấu thành một cách phức tạp chỉ bằng các công cụ dòng lệnh tiêu chuẩn.
• Với cách thực thi 3 giai đoạn và hệ thống "mở rộng", nó được thiết kế để chuẩn bị cho tương lai và tránh phải thay đổi lại các tệp kiểm thử nhị phân.
• Việc một cuộc tấn công như vậy lại được phát hiện một cách tình cờ để lại rất nhiều câu hỏi cho cộng đồng bảo mật.

Ý kiến của GN⁺

• Bài viết này nhấn mạnh tầm quan trọng của bảo mật phần mềm và các cuộc tấn công chuỗi cung ứng. Nó giúp nhận thức rõ các lỗ hổng có thể phát sinh trong quá trình build phần mềm, đồng thời nhắc lại tầm quan trọng của việc rà soát mã và kiểm toán bảo mật.
• Kỹ thuật làm rối và phương thức tấn công nhiều giai đoạn cho thấy kẻ tấn công có thể xâm nhập hệ thống một cách tinh vi đến mức nào. Những kỹ thuật này cũng có giá trị học thuật đối với các chuyên gia bảo mật.
• Một số công cụ hoặc dự án bảo mật khác có chức năng tương tự gồm OWASP Dependency-Check và Sonatype Nexus Platform. Chúng giúp xác định các lỗ hổng bảo mật trong các phụ thuộc phần mềm.
• Khi áp dụng các kỹ thuật này, cần tăng cường bảo mật ở mọi giai đoạn của chuỗi cung ứng phần mềm. Lợi ích là nâng cao độ an toàn của hệ thống, nhưng bất lợi là nếu kẻ tấn công sử dụng các phương thức này thì việc phát hiện có thể rất khó.
• Sự việc này cho thấy cả điểm mạnh lẫn điểm yếu của cộng đồng mã nguồn mở. Việc rà soát và đóng góp dựa trên cộng đồng rất quan trọng đối với sự phát triển và bảo mật của dự án, nhưng đồng thời cũng tồn tại rủi ro từ những người đóng góp có ý đồ xấu.