Table of Contents
Vào ngày 29 tháng 3 năm 2024, một
tin nhắn
trong danh sách gửi thư bảo mật OSS Openwall đã đánh dấu một khám phá quan
trọng đối với cộng đồng bảo mật thông tin, nguồn mở và Linux: việc phát hiện
ra một mã độc backdoor trong XZ. XZ là tiện ích nén được
tích hợp trong nhiều bản phân phối phổ biến của Linux.
Mối nguy hiểm đặc biệt của thư viện backdoor nằm ở việc nó được sử dụng bởi
tiến trình máy chủ OpenSSH sshd. Trên một số bản phân phối
dựa trên systemd, bao gồm Ubuntu, Debian và RedHat/Fedora Linux, OpenSSH được
vá để sử dụng các tính năng của systemd và do đó có sự phụ thuộc vào thư viện
này (lưu ý rằng Arch Linux và Gentoo không bị ảnh hưởng). Mục tiêu cuối cùng
của những kẻ tấn công rất có thể là giới thiệu khả năng thực thi mã từ xa cho
sshd mà không ai khác có thể sử dụng.
Không giống như các cuộc tấn công chuỗi cung ứng khác mà chúng tôi đã thấy
trong Node.js,
PyPI
,
FDroid
và Linux
Kernel
, chủ yếu bao gồm các bản vá độc hại nguyên tử, gói giả mạo và tên gói bị lỗi
chính tả, sự cố này là một hoạt động nhiều giai đoạn gần như đã thành công
trong việc xâm phạm SSH máy chủ trên quy mô toàn cầu.
Backdoor trong thư viện liblzma được giới thiệu ở hai cấp độ. Mã nguồn của cơ
sở hạ tầng xây dựng tạo ra các gói cuối cùng đã được sửa đổi một chút (bằng
cách giới thiệu tệp bổ sung build-to-host.m4) để trích xuất tập lệnh
giai đoạn tiếp theo bị ẩn trong tệp trường hợp thử nghiệm (bad-3-corrupt_lzma2. xz). Các tập lệnh này lần lượt trích xuất một thành phần nhị phân độc hại từ
một tệp trường hợp thử nghiệm khác (good-large_compression.lzma) được
liên kết với thư viện hợp pháp trong quá trình biên dịch để được chuyển đến
kho Linux. Các nhà cung cấp lớn lần lượt vận chuyển thành phần độc hại trong
các phiên bản beta và thử nghiệm. Sự xâm phạm của XX Utils được gán
CVE-2024–3094
với điểm nghiêm trọng tối đa là 10.
Dòng thời gian của sự kiện
Trang web 2024.01.19 XZ được nhà bảo trì mới chuyển đến các trang GitHub (jiaT75)
2024.02.15 “build-to-host.m4” được
thêm
vào .gitignore
2024.02.23 hai “test files” chứa các giai đoạn của tập lệnh độc hại là
được giới thiệu
2024.02.24 Xperia 5.6.0 được phát hành
2024.03.04 cửa sau dẫn đến
sự cố
với Valgrind
2024.03.09, hai “test files” được cập nhật, các chức năng CRC được sửa đổi, Sự
cố Valgrind đã được “fixed”
2024.03.09 Xperia 5.6.1 được phát hành
2024.03.28 lỗi được phát hiện, Debian và RedHat đã thông báo
2024.03.28 Debian
khôi phục
phiên bản Xperia 5.6.1 về 5.4.5-0.2
2024.03.29 một email được
xuất bản
trên danh sách gửi thư bảo mật OSS
2024.03.29 RedHat xác nhận Xperia có cửa hậu đã được
chuyển đi
trong Fedora Rawhide và Fedora Linux 40 beta
2024.03.30 Debian
tắt
các bản dựng và bắt đầu quá trình xây dựng lại nó
2024.04.02 Nhà phát triển chính của Xperia
nhận ra sự cố
cửa sau
Phân phối nguồn có backdoor
xz-5.6.0
| MD5 | c518d573a716b2b2bc2413e6c9b5dbde |
|---|---|
| SHA1 | e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b |
| SHA256 | 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875 |
xz-5.6.1
| MD5 | 5aeddab53ee2cbd694f901a080f84bf1 |
|---|---|
| SHA1 | 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7 |
| SHA256 | 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8 |
Phân tích lây nhiễm ban đầu
Kho git ZIP chứa một tập hợp các tệp kiểm tra được sử dụng khi kiểm tra mã
máy nén/giải nén để xác minh rằng nó hoạt động bình thường. Tài khoản có
tên Jia Tan hay “
jiaT75 “,
committed
hai tệp thử nghiệm ban đầu có vẻ vô hại nhưng lại được dùng làm mồi nhử để
cấy cửa sau.
Các tập tin liên quan là:
- bad-3-corrupt_lzma2.xz (86fc2c94f8fa3938e3261d0b9eb4836be289f8ae)
- good-large_compressed.lzma (50941ad9fd99db6fca5debc3c89b3e899a9527d7)
Các tệp này nhằm mục đích chứa các tập lệnh shell và chính đối tượng nhị
phân backdoor. Tuy nhiên, chúng ẩn trong dữ liệu không đúng định dạng và
kẻ tấn công biết cách trích xuất chúng đúng cách khi cần.
Giai đoạn 1 – Tập lệnh xây dựng trên máy chủ được sửa đổi
Khi bản phát hành đã sẵn sàng, kho lưu trữ Github chính thức sẽ phân
phối các tệp nguồn của dự án. Ban đầu, các bản phát hành này trên kho lưu
trữ, ngoài việc chứa các tệp thử nghiệm độc hại, vô hại vì chúng không có cơ
hội thực thi. Tuy nhiên, kẻ tấn công dường như chỉ thêm mã độc khởi động quá
trình lây nhiễm khi các bản phát hành có nguồn gốc từ
https://xz[.]tukaani.org, thuộc quyền kiểm soát của Jia Tan.
URL này được hầu hết các bản phân phối sử dụng và khi tải xuống, nó đi kèm
với một tệp có tên build-to-host.m4 chứa mã độc.
build-to-host.m4 (c86c8f8a69c07fbec8dd650c6604bf0c9876261f) được thực thi trong quá trình xây dựng và thực thi một dòng mã sửa và
giải nén tệp đầu tiên được thêm vào thư mục kiểm tra:
|
| Dòng mã đã được giải mã trong build-to-host.m4 |
Dòng mã này thay thế dữ liệu “broken” từ bad-3-corrupt_lzma2.xz bằng
lệnh tr và chuyển đầu ra
sang lệnh xz -d để giải
nén dữ liệu. Dữ liệu được giải nén chứa tập lệnh shell sẽ được thực thi sau
bằng cách sử dụng /bin/bash, được kích hoạt bởi tệp .m4 này.
Giai đoạn 2 – Tập lệnh shell được chèn
Tập lệnh độc hại được chèn bởi tệp mã độc .m4 sẽ xác minh
rằng nó đang chạy trên máy Linux và nó cũng đang chạy trong quá trình xây
dựng dự định.
|
| Nội dung tập lệnh được chèn |
Để thực hiện giai đoạn tiếp theo, nó sử dụng
good-large_compression.lzma, thực sự được nén chính xác bằng XZ,
nhưng chứa dữ liệu rác bên trong dữ liệu được giải nén.
Quy trình loại bỏ dữ liệu rác như sau: hàm
eval thực thi đường dẫn
đầu, với mỗi lệnh head bỏ
qua 1024 byte tiếp theo hoặc trích xuất 2048 hoặc 724 byte tiếp theo.
Tổng cộng, các lệnh này đã trích xuất 33.492 byte (
2048*16 + 724 byte). Lệnh
tail sau đó giữ lại 31.265
byte cuối cùng của tệp và bỏ qua phần còn lại.
Sau đó, lệnh tr áp dụng
thay thế cơ bản cho đầu ra để giải mã nó. Lệnh XZ thứ hai giải nén các byte
đã chuyển đổi dưới dạng luồng lzma thô , sau đó kết quả được chuyển
vào shell.
Giai đoạn 3 – Khai thác backdoor
Tập lệnh shell giai đoạn cuối thực hiện nhiều kiểm tra để đảm bảo rằng nó
đang chạy trong môi trường mong đợi, chẳng hạn như liệu dự án có được cấu
hình để sử dụng IFUNC hay không (điều này sẽ được thảo luận trong các phần
tiếp theo).
Nhiều bước kiểm tra khác được thực hiện trong giai đoạn này bao gồm việc xác
định xem GCC có được sử dụng để biên dịch hay dự án có chứa các tệp cụ thể
sẽ được tập lệnh sử dụng sau này hay không.
Trong giai đoạn này, nó trích xuất chính mã nhị phân backdoor, một
object file
hiện được ẩn trong cùng một tệp good-large_compression.lzma, nhưng ở
một độ lệch khác.
Đoạn mã sau xử lý việc này:
|
| Lệnh một phần được sử dụng ở giai đoạn tập lệnh cuối cùng |
Quá trình trích xuất hoạt động thông qua một chuỗi các lệnh, với kết quả của
mỗi lệnh đóng vai trò là đầu vào cho lệnh tiếp theo. Mã một lớp được định
dạng được hiển thị bên dưới:
|
| Trích xuất cửa sau được định dạng một lớp |
Ban đầu, tệp good-large_compression.lzma được giải nén bằng chính
công cụ XZ. Các bước tiếp theo liên quan đến việc gọi một chuỗi lệnh
gọi head với hàm “
eval $i” (giống như trích xuất giai đoạn 3).
Sau đó, thuật toán giống RC4 tùy chỉnh được sử dụng để giải mã dữ liệu nhị
phân chứa một tệp nén khác. Tệp nén này cũng được giải nén bằng tiện ích XZ.
Sau đó, tập lệnh sẽ xóa một số byte khỏi phần đầu của dữ liệu được giải nén
bằng cách sử dụng các giá trị được xác định trước và lưu kết quả vào đĩa
dưới dạng liblzma_la-crc64-fast.o, đây là tệp backdoor được sử dụng
trong quá trình liên kết.
Cuối cùng, tập lệnh sửa đổi hàm is_arch_extension_supported từ tệp
crc_x86_clmul.h trong liblzma, để thay thế lệnh gọi hàm
__get_cpuid bằng _get_cpuid , xóa một ký tự gạch dưới.
Việc sửa đổi này cho phép nó được liên kết vào thư viện (chúng ta sẽ thảo
luận vấn đề này chi tiết hơn trong phần tiếp theo). Toàn bộ chuỗi lây nhiễm
bản dựng có thể được tóm tắt theo sơ đồ sau:
Phân tích backdoor nhị phân
Một kịch bản tải lén lút
Trong mã gốc, có hai hàm đặc biệt được sử dụng để tính CRC của dữ
liệu đã cho: lzma_crc32 và lzma_crc64. Cả hai hàm này đều
được lưu trữ trong bảng ký hiệu ELF với loại
IFUNC
, một tính năng được cung cấp bởi Thư viện GNU C (GLIBC). IFUNC cho phép
các nhà phát triển tự động chọn đúng chức năng để sử dụng. Lựa chọn này
diễn ra khi trình liên kết động tải thư viện dùng chung.
Lý do XZ sử dụng điều này là vì nó cho phép xác định xem có nên sử dụng
phiên bản tối ưu hóa của hàm lzma_crcX hay không. Phiên bản được
tối ưu hóa yêu cầu các tính năng đặc biệt từ bộ xử lý hiện đại (CLMUL,
SSSE3, SSE4.1). Các tính năng đặc biệt này cần được xác minh bằng cách đưa
ra lệnh cpuid, lệnh này được gọi bằng cách sử dụng trình bao
bọc/nội tại
__get_cpuid
do GLIBC cung cấp và tại thời điểm này, cửa sau tận dụng lợi thế để tự
tải.
Backdoor được lưu trữ dưới dạng tệp đối tượng và mục tiêu chính của nó là
được liên kết với tệp thực thi chính trong quá trình biên dịch. Tệp đối
tượng chứa ký hiệu _get_cpuid , vì các tập lệnh shell được chèn sẽ
loại bỏ một ký hiệu gạch dưới khỏi mã nguồn ban đầu, có nghĩa là khi mã
gọi _get_cpuid, nó thực sự gọi phiên bản backdoor của nó.
|
| Điểm vào mã backdoor |
Phân tích mã backdoor
Mã backdoor ban đầu được gọi hai lần, vì cả lzma_crc32 và
lzma_crc64 đều sử dụng cùng một hàm được sửa đổi (_get_cpuid).
Để đảm bảo kiểm soát điều này, một bộ đếm đơn giản được tạo ra để xác minh
rằng mã đã được thực thi. Hoạt động độc hại thực sự bắt đầu khi
lzma_crc64 IFUNC gọi _get_cpuid, thấy giá trị bộ đếm 1 cho
biết rằng chức năng này đã được truy cập và bắt đầu một bước cuối cùng để
chuyển hướng đến điểm xâm nhập thực sự của mã độc này.
|
| Khởi tạo backdoor |
Để khởi tạo mã độc, trước tiên, backdoor khởi tạo một vài cấu trúc chứa
thông tin cốt lõi về quy trình đang chạy. Về cơ bản, nó định vị địa chỉ Bảng
offset toàn cầu (GOT) bằng cách sử dụng các offset được mã hóa cứng và sử dụng thông tin này để
tìm con trỏ cpuid bên trong nó.
|
| GOT mã sửa đổi |
GOT chứa phần bù của các ký hiệu, bao gồm cả trình bao bọc cpuid. Sau
đó, backdoor hoán đổi các con trỏ tới chức năng chính của mã độc hại và gọi nó
như thể nó đang gọi cpuid.
Hành vi cốt lõi
Mục tiêu chính của backdoor là kết nối thành công các chức năng cụ thể cho
phép nó giám sát mọi kết nối với máy bị nhiễm. Các chức năng mục tiêu bao gồm:
| Chức năng nhắm mục tiêu | Sự miêu tả |
|---|---|
| RSA_public_decrypt | Được libcrypto sử dụng để giải mã văn bản mã hóa được ký bằng khóa riêng |
| EVP_PKEY_set1_RSA | Được libcrypto sử dụng để đặt khóa RSA của một ngữ cảnh nhất định |
| RSA_get0_key | Được libcrypto sử dụng để lấy khóa RSA |
Tuy nhiên, việc kết nối tất cả các chức năng này không phải là một nhiệm vụ
đơn giản và dễ hiểu đối với backdoor. Nó liên quan đến việc truy cập vào
nhiều cấu trúc bên trong và thao túng các cấu trúc dành riêng cho quy trình
cho đến khi đạt được mục tiêu và nó cũng cần phải tàng hình nhất có thể,
điều đó có nghĩa là mã độc chứa nhiều bước kiểm tra để tránh bị phân tích.
Kiểm tra môi trường thực thi
Đầu tiên, nó phân tích cú pháp
ld-linux (trình liên kết
động), chịu trách nhiệm chính trong việc phân giải động các địa chỉ ký hiệu
trong bộ nhớ. Nó cũng trích xuất nhiều thông tin khác nhau về môi trường và
xác minh rằng quy trình hiện tại mà cửa hậu đang chạy phù hợp với các tiêu
chí thực thi của nó, đó là:
- Quá trình hiện tại là /usr/bin/sshd
- Kiểm tra xem kill switch có tồn tại không
Nó trích xuất tên của quy trình hiện tại từ argv[0] và cũng phân tích
tất cả các biến môi trường của quy trình để xem liệu có bất kỳ biến nào
trong số chúng có trong bảng chuỗi bên trong của nó hay không. Nếu tìm thấy
kết quả trùng khớp hoặc quy trình không phải là sshd , mã độc sẽ tạm
dừng quá trình thực thi của nó.
|
| Kiểm tra môi trường quy trình |
Biến duy nhất bên trong bảng riêng của nó là
yolAbejyiejuvnup=Evjtgvsh5okmkAvj , trong ngữ cảnh này đóng vai trò là
một kill switch.
Cấu trúc trie
Một trong những tính năng đặc biệt của backdoor là việc sử dụng cấu trúc
trie
duy nhất cho các hoạt động chuỗi. Thay vì so sánh trực tiếp các chuỗi hoặc
sử dụng hàm băm chuỗi để khớp với một hằng số cụ thể (ví dụ: tên của hàm thư
viện), mã sẽ thực hiện tra cứu trie và kiểm tra xem kết quả có bằng một số
hằng số nhất định hay không. Ví dụ: giá trị ma thuật cho tiêu đề ELF dẫn đến
kết quả là trie trả về 0x300 và tên của hàm hệ thống được khớp
với giá trị trả về là 0x9F8. Trie không chỉ được sử dụng để so sánh:
một số hàm nhất định sử dụng con trỏ tới chuỗi (ví dụ: ssh-2.0) tìm
kiếm các chuỗi này trong hệ nhị phân máy chủ bằng cách sử dụng trie, do đó
sẽ không có dữ liệu đáng ngờ nào trong phần thân của backdoor.
Việc triển khai trie sử dụng mặt nạ bit 16 byte, mỗi nửa tương ứng với phạm
vi đầu vào byte 0x00-0x3F và 0x40-0x7F và các nút lá trie 2
byte, 3 bit trong số đó là cờ (hướng, kết thúc) và phần còn lại là dành
riêng cho giá trị (hoặc vị trí của nút tiếp theo).
|
| Một phần của hàm tra cứu trie thực hiện khớp bitmap |
Trình phân giải biểu tượng
Có ít nhất ba quy trình liên quan đến trình phân giải ký hiệu được cửa sau
sử dụng để định vị cấu trúc Biểu tượng ELF, chứa thông tin như tên ký hiệu
và phần bù của nó. Tất cả các hàm phân giải ký hiệu đều nhận được một khóa
để tìm kiếm trong bộ ba.
|
| Ví dụ về trình phân giải biểu tượng |
Một trong các hàm phân giải cửa sau sẽ lặp qua tất cả các ký hiệu và xác minh
xem ký hiệu nào có khóa mong muốn. Nếu được tìm thấy, nó sẽ trả về cấu trúc
Elf64_Sym, cấu trúc này sau này sẽ được sử dụng để điền vào cấu trúc
bên trong của cửa sau chứa tất cả các con trỏ hàm cần thiết. Quá trình này
tương tự như quy trình thường thấy trong các mối đe dọa Windows với quy trình
băm API.
Cửa sau tìm kiếm nhiều chức năng từ thư viện libcrypto (OpenSSL), vì chúng
sẽ được sử dụng trong các quy trình mã hóa sau này. Nó cũng theo dõi xem nó
có thể tìm và giải quyết bao nhiêu chức năng; điều này xác định liệu nó có
đang thực thi đúng hay nên dừng lại.
Một trình phân giải biểu tượng thú vị khác lạm dụng hàm
lzma_alloc, một phần của thư viện liblzma. Hàm này đóng vai trò
trợ giúp cho các nhà phát triển trong việc phân bổ bộ nhớ một cách hiệu quả
bằng cách sử dụng bộ cấp phát mặc định (malloc) hoặc bộ cấp phát tùy chỉnh.
Trong trường hợp cửa hậu của Xperia, chức năng này bị lạm dụng để sử dụng bộ
cấp phát giả. Trong thực tế, nó hoạt động như một trình phân giải biểu tượng
khác. Trên thực tế, tham số dành cho “kích thước phân bổ” là khóa ký hiệu
bên trong trie. Thủ thuật này nhằm mục đích làm phức tạp việc phân tích
backdoor.
|
| Trình phân giải biểu tượng sử dụng cấu trúc cấp phát giả |
Backdoor tự động phân giải các ký hiệu của nó trong khi thực thi; nó không
nhất thiết phải làm như vậy cùng một lúc hoặc chỉ khi cần sử dụng chúng. Các
ký hiệu/chức năng được giải quyết bao gồm từ các hàm OpenSSL hợp pháp đến các
hàm như hệ thống, được sử dụng để thực thi các lệnh trên máy.
Móc Symbind
Như đã đề cập trước đó, mục tiêu chính của việc khởi tạo backdoor là kết nối
thành công các hàm. Để làm như vậy, cửa sau sử dụng
rtdl-audit, một tính năng của trình liên kết động cho phép tạo các thư viện chia sẻ tùy
chỉnh để nhận thông báo khi một số sự kiện nhất định xảy ra trong trình liên
kết, chẳng hạn như độ phân giải biểu tượng. Trong trường hợp điển hình, nhà
phát triển sẽ tạo thư viện dùng chung theo hướng dẫn
rtdl-audit manual. Tuy nhiên, cửa sau của chọn thực hiện một bản vá thời gian chạy trên
các giao diện đã đăng ký (mặc định) được tải trong bộ nhớ, từ đó chiếm quyền
điều khiển quy trình phân giải biểu tượng.
|
| bản vá thời gian chạy dl-audit |
Cấu trúc được tạo ra một cách độc hại
audit_iface, được lưu trữ trong biến toàn cục dl_audit trong vùng bộ nhớ của
trình liên kết động, chứa địa chỉ gọi lại symbind64, được gọi bởi
trình liên kết động. Nó gửi tất cả thông tin biểu tượng đến bộ điều khiển
cửa sau, sau đó bộ phận này được sử dụng để lấy địa chỉ độc hại cho các chức
năng mục tiêu, từ đó đạt được hooking.
|
| Vị trí nối bên trong lệnh gọi lại đã sửa đổi của Symbind |
Địa chỉ cho dl_audit và dl_naudit, chứa số lượng giao diện
kiểm tra có sẵn, có được bằng cách phân tách cả hai hàm
dl_main và
dl_audit_symbind_alt. Backdoor chứa một
bộ dịch mã tối giản bên trong được sử dụng để giải mã lệnh. Nó sử
dụng rộng rãi nó, đặc biệt là khi tìm kiếm các giá trị cụ thể như địa chỉ
*audit.
|
| mã săn dl_nautit |
Địa chỉ dl_naudit được tìm thấy bởi một trong các lệnh
mov trong mã hàm
dl_main truy cập vào nó. Với
thông tin đó, backdoor sẽ tìm kiếm quyền truy cập vào địa chỉ bộ nhớ và lưu
nó.
Nó cũng xác minh xem địa chỉ bộ nhớ thu được có giống với địa chỉ được truy
cập bởi hàm
dl_audit_symbind_alt trên
một offset nhất định hay không. Điều này cho phép nó giả định một cách an toàn
rằng nó thực sự đã tìm thấy địa chỉ chính xác. Sau khi tìm thấy địa chỉ
dl_naudit, nó có thể dễ dàng tính toán vị trí của dl_audit, vì
cả hai địa chỉ này được lưu cạnh nhau trong bộ nhớ.
Phần kết luận
Trong bài viết này, chúng tôi đã đề cập đến toàn bộ quá trình tạo cửa sau
liblzma (XZ) và đi sâu vào phân tích chi tiết về mã nhị phân để
đạt được mục tiêu chính của nó: móc nối.
Rõ ràng là backdoor này rất phức tạp và sử dụng các phương pháp phức tạp để
tránh bị phát hiện. Chúng bao gồm việc cấy ghép nhiều giai đoạn vào kho lưu
trữ XZ, cũng như mã phức tạp có trong chính tệp nhị phân.
Vẫn còn nhiều điều cần khám phá về phần bên trong của backdoor, đó là lý do
tại sao chúng tôi quyết định trình bày phần này như Phần I của loạt bài
về backdoor XZ.
Các sản phẩm của Kaspersky phát hiện các đối tượng mã độc liên quan đến cuộc
tấn công như HEUR:Trojan.Script.XZ và Trojan.Shell.XZ. Ngoài ra,
Kaspersky Endpoint Security cho Linux còn phát hiện mã độc hại trong bộ nhớ xử
lý SSHD dưới dạng MEM:Trojan.Linux.XZ (như một phần của nhiệm vụ Quét
các khu vực quan trọng).
Các dấu hiệu của sự thỏa hiệp
Quy tắc yara
rule liblzma_get_cpuid_function {
meta:
description = "Rule to find the malicious get_cpuid function CVE-2024-3094"
author = "Kaspersky Lab"
strings:
$a = { F3 0F 1E FA 55 48 89 F5 4C 89 CE 53 89 FB 81 E7 00 00 00 80 48 83 EC 28 48 89 54 24 18 48 89 4C 24 10 4C 89 44 24 08 E8 ?? ?? ?? ?? 85 C0 74 27 39 D8 72 23 4C 8B 44 24 08 48 8B 4C 24 10 45 31 C9 48 89 EE 48 8B 54 24 18 89 DF E8 ?? ?? ?? ?? B8 01 00 00 00 EB 02 31 C0 48 83 C4 28 5B 5D C3 }
condition:
$a
}
Các thư viện có backdoor đã biết
Debian Sid liblzma.so.5.6.0
72e8163734d586b6360b24167a3aff2a3c961efb
319feb5a9cddd81955d915b5632b4a5f8f9080281fb46 e2f6d69d53f693c23ae
Debian Sid liblzma.so.5.6.1
8a75968834fc11ba774d7bbdc566d272ff45476c
605861f833fc181c7cdcabd5577ddb8989bea332648a 8f498b4eef89b8f85ad4
Các tập tin liên quan
d302c6cb2fa1c03c710fa5285651530f, liblzma.so.5
4f0cf1d2a2d44b75079b3ea5ed28fe54, liblzma.so.5.6.0
153df9727a2729879a26c1995007ffbc, liblzma.so.5.6.0 .patch
53d82bb511b71a5d4794cf2d8a2072c1, liblzma.so.5.6.1
212ffa0b24bb7d749532425a46764433, liblzma_la-crc64-fast.o
Các thành phần được phân tích
35028f4b5c6673d6f2e1a80f02944fb2, bad-3-corrupt_lzma2.xz
b4dd2661a7c69e85f19216a6dbbb1664, build-to-host.m4, good-large_compression.lzma
Nguồn: securelist.com
Backup: archive.org