Một phát hiện tình cờ về một cửa sau có khả năng ngăn chặn hàng nghìn ca lây nhiễm

[Bài đăng xuất hiện đầu tiên trên Deepfactor] Việc phát hiện ra cửa hậu xz ngày hôm qua là một sự tình cờ. Nhưng thật là một tai nạn may mắn. Diễn viên (hoặc những diễn viên mà chúng tôi chưa biết) đã nỗ lực chăm chỉ trong một thời gian dài và chỉ gần đây mới bắt đầu ghép tất cả các mảnh lại với nhau để tạo ra thứ đã được phát hiện ngày hôm qua. Cửa sau bị gọi không chính xác là ssh backdoor; điều này hơi sai lệch. OpenSSH không sử dụng xz, nhưng các nhà bảo trì phân phối Linux đã liên kết xz với sshd khi xây dựng nó (bề ngoài là để tích hợp dễ dàng hơn với systemd). Trên thực tế, xz được liên kết với nhiều gói đến mức không bao giờ có thể xác định đầy đủ phạm vi những gì cửa sau có thể đã thực hiện.

Tôi không phải nhà nghiên cứu bảo mật, cũng không phải kỹ sư đảo ngược. Andres Freund đã đăng lên danh sách gửi thư bảo mật oss rằng trong quá trình kiểm tra một số vấn đề hiệu suất ssh kỳ lạ và sự cố valgrind, cửa sau đã được phát hiện. Điều quan trọng cần lưu ý là Andres không phải là nhà nghiên cứu bảo mật (tiêu đề của phần này là nội dung do Andres viết trong tiết lộ); có nghĩa là, đây không phải là thứ đang được tích cực tìm kiếm mà là thứ gì đó tình cờ gặp được.

Đây là một khám phá vô cùng may mắn; như đã đề cập trước đó, xz được sử dụng ở mọi nơi. Mặc dù có khả năng ssh là mục tiêu có thể xảy ra nhưng chúng ta có thể không bao giờ biết được. Cửa sau đã chèn mã vào liblzma thông qua các thay đổi khó hiểu và khó hiểu được đưa vào tập lệnh cấu hình của xz. Mục đích đã nêu của thay đổi đó là cải thiện việc kiểm tra bằng cách sử dụng một số tệp .xz dựng sẵn làm tệp nhị phân kiểm tra. Trên thực tế, những tệp nhị phân thử nghiệm đó thực sự chứa mã được đưa vào sshd.

Bây giờ, hãy thành thật mà nói. Có bao nhiêu nhà phát triển đang kiểm tra từng tập lệnh cấu hình để tìm tất cả các phần phụ thuộc mà họ tự xây dựng? Libtool, autoconf, automake và bạn bè được tạo riêng để bạn không cần phải kiểm tra các tập lệnh cấu hình này bằng tay (và trong trường hợp này, không ai làm như vậy). Có lẽ tệ hơn, nếu bạn đang dựa vào các phụ thuộc có nguồn gốc từ bên thứ ba, bạn có thực sự tin tưởng rằng họ đang chăm chỉ làm điều đó không?

Những thay đổi này được Jia Tan dần dần đưa ra (có thể không phải tên thật và cũng có thể là một nhóm cá nhân hoặc một quốc gia) cùng với các tài khoản giả mạo khác xuất hiện trong vài năm qua đã khuyến khích những thay đổi. Đây chắc chắn là hành động của một cá nhân hoặc một nhóm đang chơi trò chơi lâu dài.

Có thông tin cho rằng vào cuối tháng 2, Jia Tan đã tiếp cận các nhà bảo trì bản phân phối Linux khác, gây áp lực buộc phải đưa các phiên bản cửa sau của xz vào bản phân phối của họ, dưới vỏ bọc là các tính năng mới tuyệt vời. Tại sao xz, một thư viện về cơ bản đã hoàn thiện tính năng trong nhiều năm, lại cần những tính năng mới tuyệt vời thì tôi lại không thể tin được, nhưng chúng ta đang ở đây. Bất chấp điều đó, thư viện cửa sau đã bắt đầu xâm nhập vào các bản phân phối phát hành và phiên bản xem trước của những người khác.

Và rồi tất cả chúng tôi đều thực sự may mắn khi phát hiện ra cửa sau. Nếu cửa sau không gây ra lỗi valgrind hoặc vấn đề về hiệu suất ssh, thì sáu tháng kể từ bây giờ, chúng tôi có thể đã phải đối mặt với hàng nghìn máy bị xâm phạm khi chúng dần dần nâng cấp lên các phiên bản phân phối mới. Hóa ra, một số bản phân phối đã bao gồm thư viện bị ảnh hưởng, nhưng phần lớn, hệ sinh thái đã tránh được một thảm họa lớn hơn.

Liên kết tất cả mọi thứ vào sshd OpenSSH cơ sở, như được phân phối từ dự án OpenSSH, không yêu cầu bất kỳ thư viện bên thứ ba nào cho chức năng mặc định. Có lẽ do một số động cơ kinh doanh không xác định, sshd trong một số bản phân phối đã được liên kết với một loạt các thư viện dưới chiêu bài tăng chức năng. Mỗi khi một phần phụ thuộc được liên kết vào một ứng dụng như thế này, ứng dụng đó sẽ kế thừa tất cả các lỗi và vấn đề của phần phụ thuộc đó. Lý do được cho là để liên kết xz, trong trường hợp này, là để sshd trở nên dễ kiểm soát hơn bởi systemd. Quyết định này chính là nguyên nhân khiến các bản phân phối này gặp phải cửa sau. Khi systemd dần dần sử dụng vũ trụ Linux, chúng ta sẽ thấy ngày càng nhiều điều này.

Thí nghiệm của riêng tôi Để thử nghiệm chuẩn bị cho việc viết blog này, tôi đã tạo ra một số máy ảo và kiểm tra xem có bao nhiêu thư viện bên ngoài được liên kết vào sshd cho mỗi máy ảo. Kết quả làm tôi ngạc nhiên, nhưng tôi cho rằng lẽ ra tôi không nên ngạc nhiên như vậy.

| Phân phối | Số lượng phụ thuộc thư viện cho sshd | |------------------------|-------------- ----------------| | OpenBSD 7.5 (cơ bản) | 4 | | Alpine Linux 3.19 | 4 | | Gentoo | 5 (*) | | Oracle Linux 9.1 | 26 | | Rocky Linux 9.2 | 26 | | Ubuntu 22.04 | 26 | | CentOS 8 | 30 | | CentOS 7 | 47 |

(*) Đối với Gentoo, tôi đã tạo ra bản dựng mở openssh bằng cách sử dụng các cài đặt USE mặc định (ví dụ: bất cứ thứ gì mà sổ tay hướng dẫn sử dụng). Tùy thuộc vào cài đặt USE, kích thước này có thể lớn hơn trong một số trường hợp. Bản cài đặt Gentoo của tôi đang sử dụng OpenRC, không phải systemd.

Các giá trị trong bảng trước được thu thập bằng cách chạy ldd dựa vào tệp nhị phân openssh sshd và trừ đi số lượng những thứ phổ biến như ld.so, mục nhập vdso và chính tệp nhị phân đó.

Lưu ý: Nói chung, bạn không bao giờ nên chạy ldd với các tệp nhị phân không đáng tin cậy. Các thử nghiệm của tôi đã được thực hiện trong các máy ảo riêng biệt, dùng một lần vì lý do này.

Như bạn có thể thấy, một số bản phân phối cung cấp các tệp nhị phân sshd khá mỏng, chỉ liên kết trong những thứ như libc và pthread, trong khi các bản phân phối khác chỉ liên kết toàn bộ vũ trụ vào tệp nhị phân. Đúng là một số bản phân phối được liệt kê (ví dụ: CentOS 7) đã rất cũ và sắp hoặc đã qua EOL, nhưng bạn có thể thấy rằng có một bước nhảy vọt giữa các bản phân phối quan tâm đến độ mỏng và dấu chân bảo mật nhỏ hơn và những bản phân phối không quan tâm đến độ mỏng và dấu chân bảo mật nhỏ hơn. Theo thời gian, số lượng dường như giảm đi, nhưng ngay cả sshd mỏng nhất trong các bản phân phối cồng kềnh này cũng liên kết với số lượng phụ thuộc gấp 5-6 lần so với sshd mỏng nhất trong danh sách.

Bạn không thể có lỗi trong mã mà bạn không có Một trong những vấn đề khi liên kết trong một danh sách lớn các phần phụ thuộc là bạn gặp phải các lỗ hổng liên quan đến từng phần phụ thuộc, ngay cả khi bạn không muốn hoặc không cần chức năng từ phần phụ thuộc đó. Điều này làm cho việc theo dõi và vá các lỗ hổng trong ứng dụng của bạn trở nên khó khăn hơn mức cần thiết. Ví dụ: một số bản phân phối được liệt kê ở trên được liên kết vào thư viện sshd để hỗ trợ Kerberos và đăng nhập thẻ thông minh. Có bao nhiêu cài đặt yêu cầu điều đó? 5%? 10%? Tuy nhiên, để đáp ứng tất cả các trường hợp sử dụng kinh doanh có thể xảy ra, các bản phân phối này đã quyết định rằng mọi người sẽ nhận được sự hỗ trợ đó, để đề phòng. Điều này hiện sẽ phơi bày mọi lỗ hổng trong các thư viện đó cho toàn bộ cộng đồng.

vậy, bạn có thể làm gì? Rất ít người sẽ xây dựng sshd của riêng họ độc lập với nhà bảo trì phân phối vì việc đi theo con đường đó dẫn đến một loạt vấn đề đau đầu khác. Vì vậy, về cơ bản, chúng tôi đang mắc kẹt với các gói có thể dễ bị tấn công mà không phải do lỗi của chúng tôi.

Giúp đỡ! Một trong những điều chúng tôi làm tại Deepfactor là giúp khách hàng hiểu rõ tình trạng dễ bị tổn thương và mức độ ưu tiên khắc phục dựa trên phân tích mức sử dụng trong thời gian chạy. Chúng tôi có thể cho bạn biết cụ thể phần phụ thuộc dễ bị tổn thương nào đã được tải vào bộ nhớ và được thực thi, để khi những điều như thế này xảy ra, bạn có thể nhanh chóng đưa biện pháp khắc phục quan trọng nhất lên đầu danh sách. Ngược lại, chúng tôi cũng có thể cho bạn biết những gì không được sử dụng, để bạn có thể loại bỏ những quả mìn như vậy khỏi môi trường của mình. Mặc dù các công cụ SCA cũ (chúng tôi gọi là SCA 1.0) có thể liệt kê những phần phụ thuộc mà bạn có trong môi trường của mình, nhưng chúng không thể cho bạn biết những gì thực sự được sử dụng, điều này rất quan trọng trong trường hợp này.

Suy nghĩ cuối cùng Tôi tin rằng kiểu tấn công chuỗi cung ứng này sẽ tiếp tục chừng nào chúng ta còn sử dụng phổ biến các kho lưu trữ mà những người bảo trì đã mất hứng thú với việc bảo trì hoặc đã bỏ hoàn toàn mã. Có nhiều thư viện nguồn mở khác ngoài xz thuộc danh mục này và ngay cả khi một thư viện được sử dụng phổ biến vẫn được duy trì cho đến ngày nay, không có gì đảm bảo rằng điều này sẽ tiếp tục. Nếu người bảo trì không quan tâm đến việc duy trì mã của họ và một người ngẫu nhiên đến và bày tỏ sự quan tâm đến việc đảm nhận công việc bảo trì, tại sao người bảo trì ban đầu không nói ""chắc chắn rồi, cố gắng""? Cho đến khi vấn đề này được giải quyết (và tôi không chắc là nó sẽ như vậy), các công cụ như Deepfactor sẽ tỏ ra có giá trị trong việc bảo vệ bạn bằng cách cho bạn biết mức độ nguy hiểm của bạn và thứ tự bạn nên khắc phục sự cố.

TÁC GIẢ

Về ABN Asia: Ai Base Network (ABN), ABN Asia được thành lập từ năm 2012, là một công ty xuất phát từ học thuật, do những giảng viên, cựu du học sinh Hungary, Hà Lan, Nga, Đức, và Nhật Bản sáng lập. Chúng tôi chia sẻ đam mê chung và tầm nhìn vững chắc về công nghệ, mang đến sự đổi mới và chất lượng đỉnh cao cho khách hàng. Phương châm của chúng tôi là: Tốt hơn. Nhanh hơn. An toàn hơn. Trong nhiều trường hợp: Rẻ hơn.

Hãy liên hệ với chúng tôi khi Quý doanh nghiệp có các nhu cầu về dịch vụ công nghệ thông tin, tư vấn chuyển đổi số, tìm kiếm các giải pháp phần mềm phù hợp, hoặc nếu Quý doanh nghiệp có đấu thầu CNTT (RFP) để chúng tôi tham dự. Quý doanh nghiệp có thể liên hệ với chúng tôi qua địa chỉ email [email protected]. Chúng tôi sẵn lòng hỗ trợ với mọi nhu cầu công nghệ của Quý doanh nghiệp.

© ABN ASIA