Vụ backdoor XZ: Kết quả phân tích ban đầu

 (securelist.com)
2 điểm bởi GN⁺ 2024-04-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Backdoor XZ Utils/liblzma được công bố trên mailing list Openwall OSS-security vào ngày 29/3/2024, và rất có khả năng mục tiêu cuối cùng của kẻ tấn công là cấy khả năng thực thi mã từ xa vào máy chủ OpenSSH sshd trên các bản phân phối dựa trên systemd
  • Chuỗi lây nhiễm gồm quá trình chèn nhiều giai đoạn lợi dụng các tệp kiểm thử và hạ tầng build của kho XZ; thông qua build-to-host.m4, bad-3-corrupt_lzma2.xz, good-large_compressed.lzma, một tệp object độc hại được liên kết vào liblzma trong quá trình build
  • XZ 5.6.0 và 5.6.1 có chứa backdoor đã được phân phối trong các bản build beta/thử nghiệm của một số nhà cung cấp lớn, và CVE-2024-3094 được gán mức độ nghiêm trọng 10 điểm
  • Backdoor nhị phân được nạp bằng cách lạm dụng IFUNC của GLIBC và đường gọi cpuid; sau đó nó cố gắng hook các hàm liên quan đến OpenSSL/libcrypto để giám sát các kết nối tới máy bị nhiễm
  • Mã độc kiểm tra việc /usr/bin/sshd có đang chạy hay không và biến môi trường kill switch; đồng thời dùng xử lý chuỗi dựa trên trie, phân giải symbol động và vá runtime rtdl-audit để gây khó khăn cho phân tích và phát hiện

Tổng quan sự việc và phạm vi ảnh hưởng

  • Ngày 29/3/2024, việc phát hiện backdoor XZ được công bố qua một thông điệp trên mailing list Openwall OSS-security
  • XZ là một tiện ích nén được tích hợp trong nhiều bản phân phối Linux lớn
  • Trọng tâm rủi ro nằm ở chỗ liblzma chứa backdoor có thể được liên kết vớ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
    • Ubuntu, Debian, RedHat/Fedora Linux đã được vá để OpenSSH sử dụng các tính năng systemd, nên phụ thuộc vào thư viện này
    • Arch Linux và Gentoo được tổng kết là không bị ảnh hưởng
  • Rất có khả năng mục tiêu cuối cùng của kẻ tấn công là đưa vào khả năng thực thi mã từ xa qua sshd mà người khác không thể sử dụng
  • Khác với các cuộc tấn công chuỗi cung ứng khác thường xoay quanh một bản vá độc hại đơn lẻ, gói giả hoặc gói typosquatting, sự việc này gần với một chiến dịch nhiều giai đoạn suýt thành công trong việc xâm phạm máy chủ SSH trên toàn thế giới

Cách backdoor được đưa vào

  • Backdoor liblzma được chèn ở hai cấp độ bằng cách kết hợp quá trình build và các tệp kiểm thử
    • Mã nguồn hạ tầng build tạo gói cuối cùng bị sửa đổi bằng việc thêm build-to-host.m4
    • Các script và thành phần nhị phân ẩn trong tệp test case được trích xuất trong quá trình build
  • Luồng lây nhiễm xoay quanh ba tệp
    • build-to-host.m4: script build trích xuất script giai đoạn tiếp theo
    • bad-3-corrupt_lzma2.xz: tệp kiểm thử có ẩn shell script
    • good-large_compressed.lzma: tệp kiểm thử có ẩn object nhị phân độc hại
  • Thành phần nhị phân độc hại được trích xuất có thể được liên kết với thư viện hợp lệ trong quá trình biên dịch rồi được đưa vào các kho Linux
  • Các nhà cung cấp lớn đã phân phối thành phần độc hại này trong các bản build beta và thử nghiệm
  • Vụ xâm phạm XZ Utils được gán CVE-2024-3094, với mức độ nghiêm trọng tối đa là 10 điểm

Dòng thời gian chính

  • 19/1/2024: Maintainer mới jiaT75 chuyển website XZ sang GitHub Pages
  • 15/2/2024: build-to-host.m4 được thêm vào .gitignore
  • 23/2/2024: Hai “tệp kiểm thử” chứa giai đoạn script độc hại được thêm vào
  • 24/2/2024: XZ 5.6.0 được phát hành
  • 26/2/2024: Một commit cản trở tính năng bảo mật Landlock được đưa vào CMakeLists.txt
  • 4/3/2024: Backdoor gây ra vấn đề liên quan đến Valgrind
  • 9/3/2024: Hai tệp kiểm thử được cập nhật, hàm CRC được sửa đổi và vấn đề Valgrind được “khắc phục”
  • 9/3/2024: XZ 5.6.1 được phát hành
  • 28/3/2024: Lỗi được phát hiện và thông báo cho Debian cùng RedHat
  • 28/3/2024: Debian rollback XZ 5.6.1 về phiên bản 5.4.5-0.2
  • 29/3/2024: Email công khai được đăng lên mailing list OSS-security
  • 29/3/2024: RedHat xác nhận XZ có chứa backdoor đã được phân phối trong Fedora Rawhide và Fedora Linux 40 beta
  • 30/3/2024: Debian dừng build và bắt đầu quy trình rebuild
  • 2/4/2024: Nhà phát triển chính của XZ thừa nhận sự cố backdoor

Ba giai đoạn của chuỗi lây nhiễm

  • Giai đoạn 1: build-to-host.m4 bị sửa đổi

    • Các bản phát hành trên kho GitHub chính thức của XZ có chứa tệp kiểm thử độc hại, nhưng ban đầu vô hại vì các tệp này không có cơ hội được thực thi
    • Mã độc bootstrap quá trình lây nhiễm dường như nằm trong bản phát hành được cung cấp từ xz[.]tukaani.org, do jiaT75 kiểm soát
    • Hầu hết các bản phân phối dùng URL này, và bản phát hành tải về có chứa tệp build-to-host.m4 mang mã độc
    • build-to-host.m4 chạy trong quá trình build; nó dùng tr để sửa dữ liệu “hỏng” trong bad-3-corrupt_lzma2.xz, rồi giải nén bằng xz -d
    • Kết quả giải nén chứa một shell script sẽ được thực thi sau đó bằng /bin/bash

  • Giai đoạn 2: Shell script được chèn vào

    • Script do tệp .m4 độc hại chèn vào kiểm tra xem nó có đang chạy trên máy Linux và trong đúng tiến trình build dự kiến hay không
    • good-large_compressed.lzma được dùng để chạy giai đoạn tiếp theo
    • Tệp này được nén hợp lệ bằng XZ, nhưng trong dữ liệu giải nén có chứa dữ liệu rác
    • Script thực thi pipeline head bằng eval để trích xuất dữ liệu
    • Mỗi lệnh head bỏ qua 1024 byte tiếp theo, hoặc trích xuất 2048 byte hoặc 724 byte tiếp theo
    • Tổng cộng 33.492 byte được trích xuất
    • tail giữ lại 31.265 byte cuối của tệp và bỏ qua phần còn lại
    • Sau đó, tr áp dụng phép thay thế cơ bản để gỡ rối obfuscation, lệnh XZ thứ hai giải nén các byte đã chuyển đổi thành luồng lzma raw, rồi chuyển kết quả cho shell

  • Giai đoạn 3: Trích xuất object backdoor

    • Shell script ở giai đoạn cuối kiểm tra nhiều điều kiện để xác nhận nó đang chạy trong môi trường dự kiến
    • Kiểm tra xem dự án có được cấu hình để sử dụng IFUNC hay không
    • Kiểm tra xem có được biên dịch bằng GCC hay không
    • Sau đó kiểm tra xem các tệp cụ thể mà script sẽ dùng có tồn tại trong dự án hay không
    • Giai đoạn này trích xuất một tệp object ẩn ở một offset khác trong good-large_compressed.lzma
    • Quy trình trích xuất chạy tuần tự nhiều lệnh, chuyển đầu ra của mỗi lệnh thành đầu vào cho lệnh tiếp theo
    • Trích xuất good-large_compressed.lzma bằng công cụ XZ
    • Sử dụng eval $i và nhiều lệnh gọi head
    • Giải mã dữ liệu nhị phân bằng một thuật toán tùy chỉnh giống RC4
    • Trích xuất lại tệp nén đã giải mã bằng XZ
    • Loại bỏ một số byte ở phần đầu rồi lưu kết quả thành liblzma_la-crc64-fast.o
    • Cuối cùng, script sửa hàm is_arch_extension_supported trong tệp crc_x86_clmul.h của liblzma
    • Thay lệnh gọi __get_cpuid bằng _get_cpuid, loại bỏ một dấu gạch dưới
    • Thay đổi này cho phép object backdoor được liên kết vào thư viện

Cách backdoor nhị phân được nạp

  • Mã XZ gốc có các hàm đặc biệt lzma_crc32 và lzma_crc64 để tính CRC
  • Hai hàm này được lưu trong bảng symbol ELF dưới dạng kiểu IFUNC của GLIBC
    • IFUNC cho phép dynamic linker chọn động hàm sẽ dùng khi nạp shared library
    • XZ dùng tính năng này để kiểm tra các tính năng bộ xử lý hiện đại như CLMUL, SSSE3, SSE4.1 rồi quyết định có dùng hàm CRC đã tối ưu hay không
  • Việc kiểm tra tính năng bộ xử lý cần lệnh cpuid, và wrapper __get_cpuid do GLIBC cung cấp được gọi
  • Khi script độc hại đổi __get_cpuid thành _get_cpuid, lệnh gọi trong mã được liên kết tới symbol _get_cpuid trong tệp object backdoor
  • Mã backdoor ban đầu được gọi hai lần vì lzma_crc32 và lzma_crc64 dùng cùng hàm đã sửa _get_cpuid
    • Nó dùng một bộ đếm đơn giản để kiểm tra xem đã chạy hay chưa
    • Nếu IFUNC lzma_crc64 gọi _get_cpuid và giá trị bộ đếm là 1, giai đoạn chuyển hướng tới entry point cuối cùng sẽ bắt đầu

Hành vi runtime và mục tiêu hook

  • Backdoor khởi tạo các cấu trúc chứa thông tin cốt lõi về tiến trình đang chạy
  • Nó dùng các offset hard-code để tìm địa chỉ Global Offset Table (GOT), rồi tìm con trỏ cpuid bên trong
  • Sau đó, nó thay con trỏ bằng hàm độc hại chính, từ đó gọi hàm độc hại như thể đang gọi cpuid
  • Mục tiêu chính là hook các hàm cụ thể để có thể giám sát các kết nối đi vào máy bị nhiễm
  • Các hàm mục tiêu liên quan đến libcrypto
    • RSA_public_decrypt: được dùng khi giải mã bản mã đã được ký bằng khóa riêng
    • EVP_PKEY_set1_RSA: được dùng khi thiết lập khóa RSA cho một context cụ thể
      • Không có trong các phiên bản máy chủ SSH mới, nhưng được dùng trong công cụ tạo khóa SSH độc lập
    • RSA_get0_key: được dùng khi lấy khóa RSA
  • Quá trình hook cần truy cập nhiều cấu trúc nội bộ và thao tác cấu trúc theo từng tiến trình; mã độc cũng thực hiện các kiểm tra để né phân tích

Kiểm tra môi trường thực thi và kỹ thuật né phân tích

  • Kiểm tra sshd và kill switch

    • Backdoor trước tiên phân tích dynamic linker ld-linux, nơi phân giải động địa chỉ symbol
    • Kiểm tra xem môi trường thực thi hiện tại có đáp ứng tiêu chí hay không
    • Kiểm tra xem tiến trình hiện tại có phải /usr/bin/sshd hay không
    • Kiểm tra xem kill switch có tồn tại hay không
    • Tên tiến trình hiện tại được trích xuất từ argv[0]
    • Nó phân tích toàn bộ biến môi trường của tiến trình để xem có khớp với giá trị trong bảng chuỗi nội bộ hay không
    • Nếu có biến môi trường khớp hoặc tiến trình không phải sshd, mã độc sẽ dừng thực thi
    • Biến duy nhất trong bảng nội bộ, yolAbejyiejuvnup=Evjtgvsh5okmkAvj, trong ngữ cảnh này hoạt động như kill switch

  • Xử lý chuỗi dựa trên trie

    • Một đặc điểm của backdoor là dùng một cấu trúc trie duy nhất cho các thao tác chuỗi
    • Thay vì so sánh trực tiếp các hằng như tên hàm hoặc so sánh bằng hash chuỗi, nó kiểm tra xem kết quả tra cứu trie có bằng một giá trị hằng cụ thể hay không
    • Magic value của header ELF trả về 0x300 từ trie
    • Tên hàm system khớp với giá trị trả về 0x9F8
    • Trie không chỉ dùng để so sánh mà còn để tìm chuỗi trong binary host
    • Ví dụ, với hàm dùng con trỏ chuỗi như ssh-2.0, backdoor tìm chuỗi đó trong binary host để không để lại dữ liệu đáng ngờ trong phần thân backdoor
    • Cách triển khai dùng bitmask 16 byte
    • Mỗi nửa tương ứng với dải byte đầu vào 0x00-0x3F, 0x40-0x7F
    • Node lá của trie dài 2 byte; 3 bit được dùng làm cờ, phần còn lại dành cho giá trị hoặc vị trí node tiếp theo

Phân giải symbol và hook rtdl-audit

  • Routine phân giải symbol

    • Backdoor có ít nhất 3 routine phân giải symbol để tìm cấu trúc ELF Symbol
    • Tất cả hàm phân giải symbol đều nhận khóa cần tìm trong trie làm đầu vào
    • Một hàm phân giải duyệt qua toàn bộ symbol để tìm symbol có khóa mong muốn, và nếu tìm thấy thì trả về cấu trúc Elf64_Sym
    • Cấu trúc này sau đó được dùng để điền vào các cấu trúc nội bộ của backdoor, lưu trữ các con trỏ hàm cần thiết
    • Quá trình này tương tự routine API hashing thường thấy trong các mối đe dọa trên Windows
    • Sau đó backdoor tìm kiếm nhiều hàm OpenSSL libcrypto sẽ dùng trong routine mã hóa
    • Nó theo dõi số lượng hàm đã tìm và phân giải, rồi dùng giá trị này để quyết định có thực thi bình thường hay dừng lại

  • Allocator giả lạm dụng lzma_alloc

    • Một trình phân giải symbol khác lạm dụng hàm lzma_alloc của chính liblzma
    • lzma_alloc là hàm giúp cấp phát bộ nhớ hiệu quả bằng allocator mặc định là malloc hoặc allocator tùy chỉnh
    • Trong backdoor XZ, allocator giả khiến hàm này hoạt động như một trình phân giải symbol khác
    • Tham số vốn dùng làm “kích thước cấp phát” thực tế được dùng làm khóa symbol trong trie
    • Thủ thuật này nhằm làm cho việc phân tích backdoor khó hơn
    • Backdoor phân giải động symbol trong khi chạy, không bị giới hạn ở cách phân giải toàn bộ symbol một lần hoặc chỉ phân giải khi cần
    • Mục tiêu phân giải bao gồm từ các hàm OpenSSL hợp lệ cho đến các hàm như system dùng để thực thi lệnh trên máy

  • Vá runtime rtdl-audit

    • Backdoor dùng tính năng rtdl-audit của dynamic linker để hook hàm
    • Thông thường, rtdl-audit là tính năng cho phép nhà phát triển tạo shared library tùy chỉnh để nhận thông báo về các sự kiện linker như phân giải symbol
    • Backdoor XZ không tạo shared library riêng; thay vào đó, nó vá runtime giao diện mặc định đã được đăng ký trong bộ nhớ để chiếm quyền routine phân giải symbol
    • Cấu trúc audit_iface độc hại được lưu trong biến toàn cục dl_audit của vùng nhớ dynamic linker chứa địa chỉ callback symbind64
    • Khi dynamic linker gọi callback này, toàn bộ thông tin symbol sẽ rơi vào quyền kiểm soát của backdoor; với các hàm mục tiêu, nó trả về địa chỉ độc hại để hoàn tất việc hook
    • Địa chỉ dl_audit và dl_naudit được lấy bằng cách disassemble các hàm dl_main và dl_audit_symbind_alt
    • Backdoor chứa một disassembler tối giản nội bộ để giải mã lệnh, được dùng rộng rãi khi tìm các giá trị cụ thể như địa chỉ *audit

Các bản phân phối backdoor đã xác nhận và thông tin phát hiện

  • Bản phân phối mã nguồn có chứa backdoor

    • xz-5.6.0
      • MD5: c518d573a716b2b2bc2413e6c9b5dbde
      • SHA1: e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b
      • SHA256: 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875
    • xz-5.6.1
      • MD5: 5aeddab53ee2cbd694f901a080f84bf1
      • SHA1: 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7
      • SHA256: 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8

  • Artifact chính đã được phân tích

    • bad-3-corrupt_lzma2.xz: 86fc2c94f8fa3938e3261d0b9eb4836be289f8ae
    • build-to-host.m4: b4dd2661a7c69e85f19216a6dbbb1664
    • good-large_compressed.lzma: 540c665dfcd4e5cfba5b72b4787fec4f
    • liblzma_la-crc64-fast.o: 212ffa0b24bb7d749532425a46764433

  • Thư viện đã biết có chứa backdoor

    • Debian Sid liblzma.so.5.6.0
      • MD5: 4f0cf1d2a2d44b75079b3ea5ed28fe54
      • SHA1: 72e8163734d586b6360b24167a3aff2a3c961efb
      • SHA256: 319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
    • Debian Sid liblzma.so.5.6.1
      • MD5: 53d82bb511b71a5d4794cf2d8a2072c1
      • SHA1: 8a75968834fc11ba774d7bbdc566d272ff45476c
      • SHA256: 605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4

  • Tên phát hiện

    • Các sản phẩm Kaspersky phát hiện các đối tượng độc hại liên quan đến cuộc tấn công là HEUR:Trojan.Script.XZ và Trojan.Shell.XZ
    • Kaspersky Endpoint Security for Linux phát hiện mã độc trong bộ nhớ tiến trình SSHD là MEM:Trojan.Linux.XZ như một phần của tác vụ Critical Areas Scan
    • Quy tắc Yara được cung cấp là quy tắc liblzma_get_cpuid_function nhằm tìm hàm get_cpuid độc hại liên quan đến CVE-2024-3094

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-13
Các ý kiến trên Hacker News

  • Câu này có vẻ còn nói giảm đi so với những gì thực sự đã xảy ra
    Điều đáng sợ hơn khía cạnh kỹ thuật của backdoor là quy mô và mức độ của social engineering. Backdoor là sản phẩm cuối cùng, và việc nó được đưa vào là vì tại thời điểm đó toàn bộ dự án xz về cơ bản đã bị các tác nhân độc hại, tức “Jia Tan” và những người xung quanh, kiểm soát trong thời gian dài. Họ đã tiến hành chiến tranh tâm lý với maintainer hơn một năm, mà maintainer hay bất kỳ ai khác đều không nhận ra
    Chuyện như tiểu thuyết gián điệp, và nếu việc như thế này có thể xảy ra thì không khỏi tự hỏi hiện giờ ở các dự án khác còn đang diễn ra những gì
    Bản thân mã backdoor cũng thể hiện cùng một lối tư duy. Nó không chỉ cố tỏ ra vô hại, mà còn chủ động tạo ra một câu chuyện về việc bề ngoài nó đang làm gì thông qua commit message, comment, tên biến, lựa chọn lệnh..., trong khi thực tế lại khiến nó làm một việc hoàn toàn khác. Cấu trúc này khiến người đầu tiên xem mã nghi ngờ cách hiểu của chính mình, rồi nghi ngờ là bug, và phải rất lâu sau mới nghi ngờ có ác ý

    • Thật sự là mức độ khó tin. Nghe có thể giống thuyết âm mưu, nhưng tôi cũng tự hỏi liệu có phải đã có một chiến dịch tâm lý ngoài đời thực nào đó khiến tác giả gốc không còn thời gian, rồi cuối cùng chuyển quyền sở hữu cho kẻ xấu hay không
      Hy vọng bất kỳ cơ quan tình báo nào cũng đang điều tra vụ này sâu hơn
    • Mong rằng chúng ta rút ra bài học từ việc này. Thực tế có rất nhiều chuyện đang xảy ra. Trong số các cơ quan được chính phủ tài trợ và các tổ chức chợ đen trên khắp thế giới, có nhiều nơi coi việc có được backdoor là nhiệm vụ, và họ cũng có đủ tiền. Đó là công việc của họ
      Thật bực khi trong mọi thread HN về backdoor, khả năng này lại bị phủ nhận như thể đó là hoang tưởng hay đội mũ giấy bạc. Người ta đối xử với nó như chuyện không xảy ra, nhưng lần này chỉ là một trường hợp cụ thể bị bắt quả tang, còn những trường hợp chưa bị phát hiện thì nhiều vô kể
      Vụ này là dự án open source nên việc phát hiện còn tương đối dễ hơn, vậy mà vẫn là may mắn. Giờ thử nghĩ đến các sản phẩm closed source: việc cài backdoor chỉ còn là bài toán xâm nhập hoặc gây sức ép lên một tổ chức. Những chuyện như vậy xảy ra thường xuyên. Không ai muốn tin, nhưng nó phổ biến. Ai từng làm ở công ty hạ tầng công nghệ hẳn đều có vài câu chuyện. Khó nói ra vì NDA hoặc những lý do còn nghiêm trọng hơn, nhưng nó thực sự xảy ra
    • Hoàn toàn đồng ý với điểm rằng nó khiến người xem mã nghi ngờ cách hiểu của chính mình. Sự thao túng, tỉ mỉ, kiên nhẫn và dai dẳng được đưa vào việc này thật đáng kinh ngạc
      Đây có thể là kết quả từ sự ám ảnh của một ai đó, hoặc là công việc của một công ty an ninh tư nhân hay tác nhân nhà nước làm những việc kiểu này với nhiều dự án như một công việc từ 9 giờ đến 5 giờ

  • Việc sự chú ý cho đến nay tập trung vào chuyện backdoor hoạt động thành công ra sao và đạt mục tiêu bằng cách nào là điều dễ hiểu
    Dù vậy, tôi cũng muốn xem phân tích sâu hơn về các sai lầm và những phần bị thiết kế quá mức. Trong cuộc phỏng vấn của Bryan Cantril [1], Andrés nói thứ này giống như linh kiện backdoor có sẵn chứ không hẳn được làm ra với hiểu biết đầy đủ về cách nó sẽ được phân phối, nên có nhiều chỗ ngớ ngẩn. Ví dụ như tra cứu bảng symbol đã khiến anh ấy bắt đầu điều tra
    Tương tự, tôi cũng tò mò vì sao lại cắt 48 byte bằng RC4 [2]
    Tôi muốn nghe thêm về việc nếu có nhiều thời gian hơn hoặc đội ngũ tốt hơn thì họ có thể làm tốt hơn thế nào, hoặc họ đã sai nghiêm trọng hơn ở đâu
    [1] https://youtu.be/jg5F9UupL6I?si=gvXsYFXgagkGOMd4
    [2] https://twitter.com/matthew_d_green/status/17744729080201014...

  • Nếu tôi hiểu đúng, một biện pháp hardening hữu ích có lẽ là để mỗi thư viện liên kết động có GOT riêng, và sau khi liên kết động kết thúc thì đánh dấu bảng là chỉ đọc. Tức là ngăn việc patch các mục ifunc của bên kia vượt qua ranh giới động
    Làm vậy có thể cải thiện bảo mật chuỗi cung ứng cho phần mã được liên kết vào đâu đó nhưng không được thực thi
    Xa hơn nữa, có lẽ nên triển khai ifunc theo kiểu khai báo, để không gây ra thực thi mã tùy ý trong từng thư viện được liên kết. Vì tương thích ngược nên hiện tại việc triển khai sẽ khó, nhưng về dài hạn có vẻ có thể đưa vào theo từng lớp. Ví dụ, nếu một thư viện được build với bit tính năng “ifunc liên kết khai báo”, thì dynamic linker sẽ cho chạy thất bại khi không phải mọi thư viện được liên kết đều có cùng cờ tính năng đó

    • Nhìn từ góc khác, hệ thống build mới là vấn đề
      Hiện nay hầu hết các bản build thư viện chạy những script cực kỳ phức tạp và khó hiểu, đòi hỏi môi trường Turing-complete. Điều này trao cho kẻ tấn công một bề mặt tấn công vô tận, và nếu quá trình build bị chiếm đoạt thì cơ hội sẽ xuất hiện
      Chuyển sang quy trình build khai báo, trong đó trình chạy chỉ là một máy trạng thái bị giới hạn, sẽ hữu ích. Yêu cầu mọi khối nguồn đều phải tái lập được cũng đáng cân nhắc
    • Vừa đúng vừa không, nhưng chủ yếu là không. Cách này sẽ ngăn việc dùng ifunc đơn giản theo kiểu này, nhưng điều quan trọng là tác giả backdoor này đã có thể tiêm mã tùy ý vào một thư viện đi vào không gian địa chỉ của một tiến trình nhạy cảm
      Từ thời điểm đó trở đi, mọi phòng thủ đều vô hiệu. Nếu muốn, họ có thể remap GOT thành ghi được, và dù hành vi đó có thể bị phát hiện là “đáng ngờ” hoặc hệ điều hành có thể chặn việc chuyển đổi, mã đã bị tiêm vẫn có thể đảo ngược luồng điều khiển bằng hàng trăm cách khác. Đọc/ghi tùy ý, thực thi mã, mọi thứ đều có thể. Không có biện pháp giảm thiểu bảo mật nào có thể ngăn một mức độ xâm phạm như thế này. Nếu muốn, nó có thể rò rỉ private key và gửi thẳng cho kẻ tấn công, hoặc bật shell. Cố thiết kế bảo vệ ở giai đoạn này là công cốc
    • Đáng tiếc là việc đánh dấu bảng là chỉ đọc sau khi hoàn tất liên kết động sẽ không hoạt động. Liên kết động là dạng trì hoãn, nên không có thời điểm nào gọi là “hoàn tất”
      Con trỏ hàm đúng được nạp khi nó được gọi lần đầu và được chèn vào bảng thay cho stub, và thời điểm đó có thể ở một tương lai xa tùy ý. Trên thực tế, trong các hệ sinh thái thư viện lớn như ứng dụng gtk, phần lớn các hàm được liên kết hoàn toàn không bao giờ được gọi
    • Nếu build cho kiến trúc máy chủ đích thì có thể tắt hoàn toàn ifunc mà không thiệt hại gì. Trên Gentoo, việc build với -march=native là phổ biến, và chỉ cần đặt -multiarch trong USE flag của glibc là dễ dàng vô hiệu hóa ifunc. Tôi chưa thấy tác động tiêu cực nào
    • Có ngôn ngữ lập trình nào có thể sandbox việc import thư viện không?

  • Về 3 giai đoạn đầu, bài này không bổ sung nhiều so với những gì đã được biết trong 2 tuần qua. Có thể xem là một bài tổng hợp tốt kèm sơ đồ luồng
    Nhưng phần phân tích binary chi tiết đến mức đó thì có vẻ mới
    Mã nguồn xuất hiện trong đó được tạo ra như thế nào? Họ chạy disassembler, hiểu mã đang làm gì rồi đổi toàn bộ tên thành các tên mang tính mô tả à? Nếu làm được trong 2 tuần thì có vẻ là một thành quả đáng kể

    • Tác giả là GReAT
      Global Research & Analysis Team, Kaspersky Lab
      https://securelist.com/author/great/
      Vì người viết có vẻ là đội phân tích malware của Kaspersky Lab, khả năng cao là họ khá giỏi reverse engineering binary
    • Công cụ trong ảnh chụp màn hình nền trắng là IDA Pro, một decompiler
      https://hex-rays.com/ida-pro/

  • Điều tôi thật sự tò mò là chính xác điều gì đã gây ra độ trễ ban đầu của SSH, thứ đã khơi mào cuộc điều tra xz. Ai đã tìm ra chưa?

    • Nó thực hiện thêm một phép toán ECC cho mỗi kết nối, nhưng trên CPU hiện đại thì việc đó không đến mức mất 500ms
      Theo những người đã reverse engineering mã, thông điệp lệnh cũng phải được ràng buộc với SSH host key. Vì vậy nếu host key là khóa RSA, có thể nó cũng thực hiện thêm một phép giải mã RSA cho mỗi kết nối
      Nếu vậy thì có lẽ đủ để là nguyên nhân gây trễ
    • Cũng có thể là cố ý
      Đây là một cách dễ để từ bên ngoài biết máy chủ có bị nhiễm hay không mà không cần thử chèn mã trước

  • Các tác giả hiểu rất sâu về cấu trúc nội bộ của glibc. Đây là loại nội dung chỉ có thể biết nếu đã vùi mình vào mã nguồn, và cũng có nhiều kỹ thuật mới
    Custom ELF parser và disassembler phức tạp đến mức khó hình dung rằng mã đó chưa từng được dùng ở đâu khác trong quá khứ, hoặc sẽ không được dùng lại trong tương lai
    Tôi tự hỏi liệu vụ này có nhận được cuộc điều tra nghiêm túc đúng mức hay không, nhưng có vẻ là không

  • Đã có ai phân tích lỗi của backdoor rốt cuộc đã gây ra lỗi Valgrind và làm SSH chậm đi, khiến vụ này bị lộ chưa?

    • Có vẻ rõ ràng đó là một thao tác ghi bộ nhớ sai: https://www.mail-archive.com/valgrind-users@lists.sourceforg...
      Bản “sửa” cho Valgrind là vô hiệu hóa ifunc, và kết quả là backdoor bị vô hiệu hóa nên lỗi biến mất
      Theo tôi biết, việc chậm đi bắt nguồn từ tất cả các thao tác tra cứu symbol và instruction mà backdoor thực hiện

  • Nhìn theo hướng bất ngờ, xét đến công sức kẻ tấn công đã bỏ ra trong script và code để tránh bị phát hiện, toàn bộ dự án này có thể chỉ là mồi đánh lạc hướng, hoặc là phương án dự phòng trong khi nhiều nỗ lực khác đang diễn ra đồng thời
    Làm sao để đi trước những thứ như thế này một bước? Việc cộng đồng tập trung vào SSHD có ảnh hưởng đến các phần khác của toàn hệ thống không? Còn các khía cạnh kỹ thuật hoặc xã hội khác thì sao?
    Mũ giấy bạc thì thú vị đấy

    • Tôi không lạc quan. Hầu như không ai thực sự audit nội dung các binary flatpak trên Flathub. Chúng có thật sự được build từ source không? Kiểu như tác giả nói là có và tự chứng minh vậy. Có khi thậm chí không cần cơ chế phân phối tinh vi như backdoor này
    • Có thể tự viết mọi thứ và có một đội chuyên trách gồm các developer đã được xác minh
      Hoặc mua phần mềm closed-source từ nơi như Microsoft, rồi hy vọng họ có tài nguyên và ý chí để rà soát mã nghiêm ngặt hơn
      Và tất nhiên luôn có cách là có một đội vận hành bảo mật giỏi để phát hiện hoạt động mạng bất thường và các nỗ lực leo thang đặc quyền
    • Một cách để đi trước các backdoor tương tự mà tôi nghĩ đến là bọc traffic sshd bằng đường hầm spiped. Spiped được compile từ source và liên kết tĩnh, còn phiên bản ổn định cuối cùng là từ năm 2021
    • Ý tưởng mũ giấy bạc của tôi là hãy nghi ngờ các contributor mã nguồn mở. Không phải vì họ đến từ một quốc gia cụ thể, cũng không phải vì có vẻ chưa ai từng gặp họ ngoài đời
      Chỉ là những contributor không có lịch sử hay dấu vết nào ngoài dự án họ đang làm nên được xem là dấu hiệu cảnh báo trong tương lai
    • Không cần mũ giấy bạc. Các dự án FOSS đã bị cài backdoor từ trước khi chúng trở nên nổi tiếng, điểm khác biệt lần này là việc đó do tác nhân được nhà nước hậu thuẫn thực hiện
      Các nhóm cũ như GOBBLES, ADM, ac1db1tch3z, ~el8 cũng từng làm những việc như vậy, và cả các “nhà nghiên cứu bảo mật” tư nhân như isec.pl cũng thế
      Lần này thành vấn đề vì các tác nhân nhà nước đang lợi dụng chủ nghĩa tư bản doanh nghiệp, thứ đã tạo ra một thời đại trong đó các dự án nền tảng được duy trì bằng mức thù lao thấp. Những kẻ xấu gần như có nguồn lực vô hạn để đạt mục tiêu
      Điều đó rốt cuộc đã tạo ra nhu cầu và sự ra đời của các tổ chức như NSO, Zerodium
      Trước đó, exploit và backdoor hầu như không có giá trị, còn hacker thì kỳ vọng được các công ty như Qualys tài trợ hoặc tuyển dụng

  • Tôi đã xem vài phân tích của Google về các vụ hack lỗ hổng zero-day, chúng cũng xuất sắc đến mức phi thực tế, nhưng vụ hack lần này có lẽ sẽ thuộc hàng đỉnh nhất từ trước đến nay

  • Tôi thấy kho xz đã được đưa trở lại GitHub, và Lasse cùng một contributor mới đang dọn dẹp. Họ đã loại bỏ hỗ trợ ifunc và commit mã tạo file test vào kho để có thể tạo file test mà không cần blob. Có vẻ họ đang làm theo hướng tốt