Backdoor XZ: “Không phải vượt qua xác thực mà là RCE, có cổng kiểm soát và không thể phát lại”

 (bsky.app)
1 điểm bởi GN⁺ 2024-03-31 | 1 bình luận | Chia sẻ qua WhatsApp
  • Theo phân tích sơ bộ bằng kỹ thuật dịch ngược về backdoor xz, hành vi này không đơn thuần là vượt qua xác thực mà gần với thực thi mã từ xa (RCE)
  • Trọng tâm là luồng trong đó RSA_public_decrypt bị hook xác minh chữ ký của host key máy chủ bằng một khóa Ed448 cố định
  • Nếu vượt qua bước xác minh chữ ký, payload có thể được chuyển cho system() để thực thi
  • Phân tích là kết quả sơ bộ được chia sẻ sau khi được cho phép; bài đăng Bluesky có bao gồm bài đăng được trích dẫn hoặc nội dung nhúng
  • Backdoor được tóm tắt là có dạng có cổng kiểm soát và không thể phát lại, nên cần được nhìn nhận khác với các cuộc tấn công chỉ đơn giản tái sử dụng cùng một đầu vào

Luồng thực thi của backdoor xz

  • Phân tích sơ bộ bằng kỹ thuật dịch ngược được chia sẻ sau khi được cho phép tập trung vào RSA_public_decrypt bị hook
    • Xác minh chữ ký đối với host key của máy chủ bằng một khóa Ed448 cố định
    • Sau khi xác minh, chuyển payload cho system()

Phân loại và hạn chế

  • Hành vi này được phân loại là thực thi mã từ xa (RCE) chứ không phải vượt qua xác thực
  • Backdoor được tóm tắt là có đặc tính gated/unreplayable
  • Bài đăng Bluesky gốc có bao gồm bài đăng được trích dẫn hoặc nội dung nhúng khác

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-31
Ý kiến trên Hacker News

  • Có kết quả reverse engineering bổ sung về vụ này. Nó chứa thông tin ánh xạ lại symbol được trích xuất từ prefix trie mà backdoor dùng để che giấu chuỗi, và có vẻ bản thân phần reverse engineering/phân tích cũng là thứ mà nó cố né tránh
    https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
    Danh sách đầy đủ các chuỗi đã giải mã nằm ở đây
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
    Nhìn từ góc độ không rành nội bộ OpenSSL, giá trị N dường như được lấy từ trường n của rsa_st
    https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
    Giá trị này là BIGNUM, và có vẻ là kiểu có độ dài biến thiên
    https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
    Backdoor lấy giá trị này từ chứng chỉ nhận từ kẻ tấn công từ xa, thử giải mã bằng ChaCha20, và nếu thành công thì chuyển cho system(). system() gần như chỉ là một wrapper đơn giản chạy một dòng script shell với quyền của người dùng mà tiến trình hiện tại đang chạy
    Nếu tôi hiểu đúng, chuyện này còn tệ hơn việc vượt qua khóa công khai. Nếu là vượt qua khóa công khai, về lý thuyết chỉ lấy được quyền của người dùng đang cố đăng nhập, và trong các cấu hình SSH được gia cố, rất có khả năng đăng nhập root đã bị chặn
    Nhưng đây là thực thi mã từ xa trong chính ngữ cảnh của tiến trình sshd, nên nếu sshd đang chạy dưới root thì payload cũng có thể chạy dưới root. Với một vụ thực thi mã từ xa lan rộng, trên thực tế gần như đây là kịch bản tệ nhất

    • Sandboxing phù hợp, SELinux và các biện pháp giảm thiểu có thể ngăn kẻ tấn công làm gì đó với quyền root. Tuy nhiên áp dụng sandbox hiệu quả cho daemon SSH là việc rất khó
    • Thật kinh khủng. Tôi còn không hình dung nổi làm sao người ta quyết định sẽ làm gì với quyền trên 1 tỷ máy tính

  • Tôi tò mò nếu backdoor này không bị phát hiện vì vấn đề hiệu năng thì về sau khả năng bị phát hiện sẽ là bao nhiêu. Tôi hiểu vấn đề hiệu năng là một sai sót/lỗi có thể sửa trong mã, nên việc liệu có công cụ nào bắt được nó hay không cũng rất quan trọng
    Câu hỏi kiểu này liên quan nhiều đến việc hiểu đây có phải là backdoor đầu tiên thuộc loại này hay chỉ là cái đầu tiên bị lộ

    • Từ trải nghiệm từng làm việc khoảng 1 năm trong môi trường có rất nhiều tác nhân IT độc hại, tôi cho rằng khả năng bị phát hiện luôn khá cao. Giữ bí mật đòi hỏi một lượng năng lượng khó tưởng tượng, và duy trì tính nhất quán của sự thật cũng vậy
      Chỉ một sai lầm nhỏ cũng có thể làm mọi thứ sụp đổ, và đôi khi chỉ một câu thôi cũng đủ khởi động phản ứng dây chuyền, làm lộ một kế hoạch được sắp xếp tinh vi
      Điều tra tội phạm diễn ra như vậy hằng ngày. Công việc cảnh sát có hạn chế về nguồn lực, nhưng phần mềm thì mỗi ngày đều được những người phân tích vì sở thích, các chuyên gia liên tục phân tích như một thú vui, và các chuyên gia phân tích chuyên nghiệp soi xét
      Rốt cuộc rất có khả năng đến một lúc nào đó nó sẽ bị phát hiện
      Cuộc tấn công XZ được thực hiện rất tốt, gần như là một kiệt tác. Sẽ không ngạc nhiên nếu có cơ quan nhà nước tham gia. Nhưng đồng thời nó cũng cực kỳ may mắn. Nếu bất kỳ điểm nào trong số những thứ hiện đang bị đánh dấu là vấn đề được phát hiện, không chỉ tôi mà nhiều đồng nghiệp hẳn đã bắt đầu một cuộc truy vết dài
      Một kết luận có thể rút ra là nếu xz/liblzma không phải mã nguồn mở thì việc tìm ra vấn đề như vậy đã là bất khả thi. Tất nhiên cũng chính vì nó là mã nguồn mở nên chuyện này mới có thể xảy ra ngay từ đầu, nhưng hãy thử tưởng tượng nếu thứ này nằm bên trong Windows hay MacOS
    • Nếu exploit không được sử dụng thì xác suất bị phát hiện hẳn khá thấp. Chúng đã chọn chỗ giấu rất khéo. Trên thực tế nó nằm ngoài codebase, nơi auditor không nhìn tới
      Tuy nhiên nếu không dùng thì không đạt được mục đích. Càng dùng nhiều, khả năng bị phát hiện về sau càng tăng. Có thể so sánh với SolarWinds
    • Tôi nghĩ trong vài tháng tới sẽ có rất nhiều người suy nghĩ cực kỳ nhiều theo hướng này. Vấn đề là code review hay một loại phân tích hành vi nào đó
      Cá nhân tôi thấy lệnh gọi system() hơi cẩu thả, và một trình quét chức năng nhị phân có lẽ đã có thể tìm ra đường dẫn đó
    • Tôi nghĩ vụ này hẳn rất khó bắt. Bản vá sshd diễn ra ở thời điểm linking, một giai đoạn có thể chấp nhận được, và nếu phân tích này đúng thì nó cũng không phải backdoor kiểu master key, nên không có dấu vết audit đăng nhập thông thường. Hơn nữa việc sshd khởi động tiến trình khác tự nó đương nhiên có thể được cho phép
      Một policy SELinux cực kỳ chặt có thể bắt việc sshd thực thi thứ gì đó không phải shell, nhưng mức gia cố như vậy hẳn rất hiếm
      Vấn đề phát hiện từ bên ngoài mục tiêu thực ra cũng đã được thử nghiệm. Nhiều người đã xem payload bằng valgrind và các công cụ tương tự nhưng không thấy. Nó cũng được bảo vệ khá tốt để không bị phát hiện trong môi trường debug. Lý do là hạ tầng lộ ra bên dưới payload không tương thích với các công cụ như ASan
      Ngay cả khi được liên kết, mã chạy từ rất lâu trước main(), nên dù dò quanh liblzma bằng debugger, thông thường bạn cũng không quan sát được cảnh nó chạy
      Với strace thì có thể thấy mọi syscall sau khi tiến trình được tạo và hoạt động của linker. Nhưng theo những gì đã nắm được tới nay, payload dường như không thực hiện syscall ở giai đoạn đó để quyết định có kích hoạt hay không, mà có vẻ nó xem argv, environ và các thứ tương tự
    • Một nhánh liên tưởng thú vị là cuộc tấn công Ken Thompson cũng được phát hiện do một lỗi hiệu năng bộ nhớ trong PWB
      [0] https://en.wikipedia.org/wiki/PWB/UNIX
      [1] https://news.ycombinator.com/item?id=38020792

  • Có vẻ có một chuỗi được mã hóa bên trong payload nhị phân
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
    Chuỗi này hoạt động như một kill switch
    https://piaille.fr/@zeno/112185928685603910
    Nếu thật vậy, một biện pháp giảm thiểu có thể là như sau

    echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment
    • Nhất định phải có -a. Nếu không, bạn có thể xóa sạch file môi trường. Và thông thường, cách đúng là nâng cấp lên phiên bản không có mã độc rồi khởi động lại
    • Quá kỳ lạ. Rất có mùi của một tác nhân nhà nước muốn để lại cách bảo vệ hệ thống của chính họ

  • Có thể giải thích ngắn gọn backdoor này chính xác làm gì không? Hiện đã biết chưa? Có vẻ bản thân backdoor không phải là payload; tôi thắc mắc liệu có cần một file nén độc hại, hay nó hook vào tiến trình sshd để lắng nghe các gói độc hại từ kẻ tấn công từ xa
    Bài gốc nghe như thể kẻ tấn công có thể gửi payload độc hại ở giai đoạn trước xác thực của phiên SSH, nhưng tôi cũng không hiểu vì sao lại nói exploit có thể sẽ không bao giờ xuất hiện. Nếu có thể reverse engineer mã thì chẳng phải cũng có thể viết proof of concept sao?
    Rốt cuộc kẻ tấn công điều khiển máy có backdoor này bằng cách nào?

    • Hãy hình dung một cánh cửa sẽ mở nếu gõ đúng cách. Với người không biết kiểu gõ bí mật, nó chỉ trông và hoạt động như một bức tường. Nếu không có kiểu gõ bí mật, thậm chí có thể không có cách nào chứng minh nó mở được ngay từ đầu
      Tình huống ở đây cũng tương tự. Trước khi làm điều đáng ngờ, xz cố gắng giải mã một số dữ liệu. Vì là cơ chế bất đối xứng, nó có thể xác minh việc giải mã mà không cần cung cấp khóa mã hóa bí mật, do nó có khóa công khai tương ứng
      Việc tìm ra khóa bí mật trên thực tế là bất khả thi, và nếu giải mã payload thất bại thì nó không có hành vi khác biệt dễ thấy, nên mã exploit có thể sẽ không bao giờ được công bố. Cách duy nhất để tạo mã exploit là bằng cách nào đó phát hiện được khóa bí mật, và trên thực tế gần như chỉ khi nhà phát triển backdoor làm rò rỉ nó
    • Theo những gì tôi đã đọc, vector tấn công có vẻ như sau. Khi sshd khởi động, nó tải libsystemd, và thư viện này tải thư viện XZ có chứa mã bị hack
      Thư viện XZ chèn các phiên bản riêng của nó cho các hàm OpenSSL dùng để xác minh chữ ký RSA
      Khi ai đó đăng nhập SSH và trình ra một chứng chỉ SSH đã ký để xác thực, các hàm bị sửa đổi đó được gọi
      Chứng chỉ có thể chứa các thông tin khẳng định như tên người dùng hoặc vai trò trong quy trình đăng nhập bình thường, và thông tin này được dùng để xác định chứng chỉ có hợp lệ cho đăng nhập của một người dùng cụ thể hay không. Nhưng nếu hàm bị sửa đổi phát hiện chứng chỉ được ký bằng một khóa tấn công cụ thể, nó sẽ lấy một số trường con trong chứng chỉ và thực thi chúng như lệnh hệ thống. Ngữ cảnh thực thi là sshd, tức người dùng root
      Đáng tiếc là ta không biết khóa ký của kẻ tấn công, chỉ biết khóa công khai mà mã bị hack dùng để xác minh. Về cơ bản, kẻ tấn công có thể thực thi lệnh tùy ý với quyền root trên hệ thống bị nhiễm, và dấu vết nhiều lắm cũng chỉ là một lần đăng nhập thất bại. Với hệ thống lộ ra Internet, những lần thử như vậy vốn đã rất nhiều
    • Có vẻ vẫn chưa biết chính xác nó làm gì. Tuy nhiên, tôi hiểu phần “không thể phát lại” như sau: nếu payload sai hoặc chữ ký bằng khóa của kẻ tấn công không được xác minh, backdoor sẽ quay lại hoạt động bình thường
      Điểm then chốt là cần chữ ký bằng khóa của kẻ tấn công. Chừng nào khóa đó không bị rò rỉ hoặc thuật toán RSA không bị phá, các nhà nghiên cứu khác hay bên thứ ba không thể lợi dụng backdoor này. Nếu RSA bị phá thì sẽ có vấn đề lớn hơn chuyện này rất nhiều
    • Nếu mật mã khóa công khai đã được dùng đúng cách và không có lỗi có thể khai thác, thì dù reverse engineer cũng không thể tạo proof of concept
    • Exploit được phát tán là nhị phân chứ không phải mã nguồn, và được giấu tinh vi trong dữ liệu kiểm thử. Nó còn xác minh payload bằng một khóa riêng chưa được công khai
      Hiện tại chỉ kẻ tấn công mới có thể chạy exploit, nên cũng không thể scan. Ngoại trừ các hiệu ứng phụ như suy giảm hiệu năng, nó khó bị phát hiện; thực tế nó cũng đã được phát hiện theo cách đó

  • Thật khó hiểu khi một gói quan trọng mà rất nhiều máy chủ Linux dùng hằng ngày lại không thể được tác giả gốc bảo trì vì thiếu kinh phí. Mã nguồn mở cần có điều gì đó thay đổi
    Một giải pháp có thể là một giấy phép buộc các công ty hoặc tổ chức kinh doanh từ một quy mô nhất định trở lên phải trả chi phí bảo trì

    • Mọi người phản đối mạnh các giấy phép như vậy. Sẽ bắt đầu làn sóng phản đối lớn rằng “nó không còn tự do nữa”, và chủ thể đó sẽ bị tẩy chay
    • Tôi tò mò liệu thực sự là thiếu kinh phí, hay là burnout
    • Đạo luật Cyber Resilience Act được đề xuất của EU đang tự nhận là giải pháp. Nói ngắn gọn, nhà cung cấp phải chịu trách nhiệm về các lỗ hổng trong suốt vòng đời sản phẩm, dù đó là tường lửa hay máy nướng bánh mì
      Vì vậy nhà cung cấp sẽ có động lực giữ cho mã nguồn mở an toàn. Chẳng hạn trả tiền cho maintainer, thuê audit mã, hoặc tuyển nhân viên toàn thời gian để đóng góp
    • Quan trọng và cần thiết là hai chuyện khác nhau. Gói này không hẳn là quan trọng, mà là gói cần thiết
    • Khó hiểu vì sao lại cần một thứ phức tạp như xz. Mã của bzip2 nhỏ, và có lẽ chỉ cần một phần rất nhỏ thời gian của một người là đủ bảo trì

  • Hiện nếu vào kho xz thì nó đã bị vô hiệu hóa vì vi phạm điều khoản sử dụng của GitHub. Việc vô hiệu hóa là đương nhiên, nhưng tôi mong GitHub giữ lại mã và lịch sử, hiển thị banner, rồi chỉ chặn các chức năng có thể bị lạm dụng
    Như vậy các nhà nghiên cứu và những người khác có thể học về exploit. Trong những tình huống nhỏ hơn, nếu một thư viện đang lưu trữ mã độc rồi kho bị gỡ xuống, người ta có thể chỉ bỏ qua và coi như không có gì đáng kể

    • Có lẽ họ không muốn các công cụ tự động tải nó xuống
    • Có thể xem sự kiện GitHub của kho đó dưới dạng CSV tại đây: https://github.com/emirkmo/xz-backdoor-github
      Nếu quan tâm đến mã nguồn thì dễ tìm thôi. Mã này và kho Git được liên kết trong nhiều kho Git trên khắp thế giới, và mã nguồn cũng đã được đóng gói nhiều lần trong các bản phát hành
    • xz có mirror Git riêng, nên có thể xem mọi commit

  • Với tư cách là người trên thực tế đang bảo trì một game mã nguồn mở không mấy nổi tiếng, tôi đã chứng kiến các lập trình viên đến rồi đi. Đóng góp nào có giá trị thì tôi cứ merge hết
    Một số cộng tác viên đào khá sâu vào tính năng trong tình trạng C và C++ trộn lẫn với đủ kiểu phong cách viết code. Không phải lúc nào tôi cũng nắm hết mọi chi tiết triển khai, nhưng trong thâm tâm vẫn có suy nghĩ rằng nếu ai đó cài một backdoor thật sự xấu xa vào thì dự án sẽ tiêu đời
    May là game này quá obscure và bề mặt tấn công cũng rất nhỏ. Dù vậy, chuyện này đã khiến tôi thôi bị cám dỗ bởi ý định ký các binary Windows chỉ vì thiện chí
    Backdoor xz này thật sự là một cơn ác mộng khổng lồ, và tôi thấy tiếc cho các nhà phát triển ban đầu cũng như tất cả những ai bị cuốn vào chuyện này

    • Tất nhiên điều đó đúng, nhưng đây không chỉ là vấn đề của phần mềm. Thật ra tôi cũng không chắc có thể gọi nó là “vấn đề” theo một nghĩa đáng kể nào không
      Khi đang đi bộ trên đường rừng, một chiếc xe chạy ngang qua có thể cứ thế tông bạn. Tài xế nhiều khả năng sẽ không bị bắt, bạn không có cách nào ngăn lại, và cũng chẳng có cảnh sát bên cạnh. Kịch bản này đáng sợ hơn backdoor phần mềm nhiều, nhưng thực ra đó là mức rủi ro tối thiểu mà ta phải chấp nhận để sống và làm điều gì đó. Trên thực tế những chuyện như vậy cũng xảy ra
      Nhưng rốt cuộc, đại đa số con người không chủ động tìm cách hại người khác. Mọi việc con người làm xưa nay đều luôn dựa trên giả định đó, và hiện giờ vẫn vậy
      Ảo tưởng rằng chỉ cần review code nghiêm ngặt hơn một chút, dùng nhiều linter, CI và khớp mẫu hơn, phổ biến ký code hơn, xác minh danh tính mọi người thì sẽ ngăn được những chuyện này mới là vấn đề thật sự. Đó là triệu chứng của kiểu hoang tưởng Silicon Valley rằng thế giới có thể và nên được quản lý, kiểm soát ở mọi cấp độ chi tiết. Những “phương thuốc” như vậy có thể còn tệ hơn rất nhiều so với bất kỳ căn bệnh nào mà chúng muốn ngăn chặn
    • Pieter Hintjens quá cố của ZeroMQ từng ủng hộ một thực hành gọi là Optimistic Merging. Đó là cách merge đóng góp ngay lập tức mà không chờ code review hay kết quả CI. Cách tiếp cận đặt tiêu chuẩn merge lỏng lẻo không hẳn là hoàn toàn lạc lõng
      [1]: http://hintjens.com/blog:106
      Tôi hiểu lợi ích của việc tạo ra một cộng đồng nơi người đóng góp thấy vui khi tham gia dự án. Nhưng tôi có cảm giác cách này khiến dự án phình to mà không có tầm nhìn hay hướng đi rõ ràng, và cuối cùng đặt gánh nặng quá mức lên maintainer để đưa đóng góp của người khác về một tiêu chuẩn chung
      Việc review code thực sự bị đẩy sang một thời điểm không xác định trong tương lai, khi đó cũng không biết review có kỹ lưỡng hay không, ai sẽ chịu trách nhiệm thực hiện hoặc sửa vấn đề. Rốt cuộc nghe như một công thức cho sự hỗn loạn, nơi không thể kiểm soát thứ gì được phát hành đến người dùng
      Cũng có vấn đề phát tán mã độc. Vấn đề này cũng xuất hiện trong phần bình luận của bài blog đó, và Pieter mô tả đúng kịch bản giống hệt vụ xz
      “Giả sử Mallory kiên nhẫn, gian dối và đủ lâu để hành xử như một người đóng góp hợp lệ nhằm giành quyền kiểm soát dự án, rồi từ từ cài backdoor. Khi đó code review cẩn thận cũng không giúp được gì. Mallory chỉ cần giành đủ niềm tin để trở thành maintainer; đó không phải là câu hỏi có thể hay không, mà là bằng cách nào.”
      Ông kết luận rằng “phòng thủ tốt nhất là quy mô và sự đa dạng của cộng đồng”
      Nhưng tôi cho rằng code review cẩn thận thực sự có thể làm giảm khả năng chuyện như vậy xảy ra. Nếu review kỹ mọi đóng góp, dù từ người đóng góp được tin cậy hay người bên ngoài, thì khả năng phát hiện sớm các hành vi lạ hoặc các commit nói là “làm A” nhưng thực tế lại làm B sẽ cao hơn
      Việc Optimistic Merging có dẫn đến một cộng đồng lớn hơn và đa dạng hơn hay không cũng còn gây tranh cãi. Có rất nhiều dự án vẫn có cộng đồng sôi động dù có hướng dẫn đóng góp nghiêm ngặt. Và nó không trả lời được sẽ bắt các patch độc hại khi nào và bằng cách nào
      Vấn đề của xz không phải là cộng đồng nhỏ, mà là không có cộng đồng. Một tác nhân độc hại duy nhất đã giành được quyền kiểm soát dự án, và gần như không có sự giám sát của bất kỳ ai khác. Hướng dẫn đóng góp không phải là yếu tố quyết định quy mô cộng đồng, và dù có dùng Optimistic Merging hay không thì chuyện này vẫn sẽ xảy ra
      [2]: http://hintjens.com/blog:106/comments/show#post-2409627
    • Tôi luôn ngạc nhiên khi thấy các công ty bỏ ra nỗ lực khổng lồ cho bảo mật biên mạng, nhưng trong tổ chức phát triển thì lại thường xuyên brew install cask hoặc cài extension cho vi/emacs/vscode
      Rust có thể được xem là ngôn ngữ/cộng đồng lập trình an toàn nhất theo mặc định, với thiết kế ưu tiên bảo mật đến mức gần như không cho nghịch pointer. Vậy mà đường dẫn cài đặt phổ biến và được khuyến nghị nhất lại như thế này, và chính tôi cũng là kẻ đạo đức giả hoàn toàn vì thường xuyên làm vậy
      https://www.rust-lang.org/tools/install
      Đây chỉ là một ví dụ. Thói quen tự mở cửa cho thực thi mã từ xa theo kiểu “hãy curl cái này rồi pipe vào sh”, trong khi đồng thời tranh cãi về block unsafe của ai đó, đã trở thành phản xạ cơ bắp của quá nhiều người
    • Thành thật mà nói, việc nhận ra thiện chí của chúng ta bị lợi dụng chỉ là vấn đề thời gian. Những hành vi như “đập nhanh, sửa nhanh” hay “ai muốn lấy quyền sở hữu dự án của tôi không?” chẳng khác nào mời gọi rắc rối, nhưng khi mã nguồn mở vẫn là thứ lao động tình yêu không lương dành cho việc code, cũng khó tưởng tượng có thể sống thiếu những điều đó
      Thật đáng tiếc khi chuyện này xảy ra, nhưng không đáng ngạc nhiên. Tôi hy vọng sẽ có những công cụ tốt hơn để đối phó với các tác nhân độc hại kiểu này, và cũng là mã nguồn mở

  • Có những câu hỏi mà backdoor này đặt ra. Còn những backdoor nào khác do cùng nhóm hoặc nhóm tương tự cài vào? Có bao nhiêu nhóm như vậy đang hoạt động? Có bao nhiêu dependency dễ bị tổn thương trước kiểu tấn công xâm nhập này? Bề mặt tấn công cho các chiến dịch bí mật kiểu này trong ngành của chúng ta lớn đến mức nào?
    Việc lập đồ thị cho các dịch vụ mạng chủ chốt như apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix, toàn bộ dependency của chúng, và toàn bộ đồ thị committer của các dependency đó có thể là bước đầu để xác định nơi nào có giá trị cao nhất nhưng ít bị giám sát nhất.
    Không thể nào đây là lần đầu tiên có ai đó thử làm việc như vậy. Đây chỉ là trường hợp đầu tiên bị lộ vì thất bại. Chúng ta biết từng có backdoor được thử đưa vào kernel Linux rồi bị phát hiện, nhưng đây là tấn công từ xa và có tính chất hoàn toàn khác.

    • Tại sao lại quyết định tạo backdoor thay vì dùng zero-day như mọi người vẫn làm?
      Tại sao không phát tán thứ gì đó trông vô hại, nếu bị phát hiện thì có thể giống như bug, mà lại triển khai một backdoor đầy đủ chức năng và còn cố che giấu cả cách phát tán?
      Đây hẳn là một quyết định có chủ ý. Lý do có thể cho manh mối về mục tiêu của họ là gì.
    • Debian cũng cần tự hỏi vì sao họ lại patch để một dịch vụ chạy bằng root và nhận kết nối từ Internet phải load các thư viện không cần thiết.

  • Điều này có vẻ nghĩa là để quét exploit từ xa, chúng ta cần khóa riêng của kẻ tấn công, thứ mà chúng ta không có. Lựa chọn còn lại chỉ là chạy script phát hiện cục bộ.

    • Một cách cực kỳ tệ mà một số scanner có thể chọn là: nếu máy chủ cung cấp xác thực RSA thì đánh dấu là “có khả năng dễ bị tổn thương”. Phần lớn SSH server đều cung cấp xác thực RSA, và thực tế SecSH RFC cũng nói đây là thứ bắt buộc phải triển khai. Làm vậy có thể khuyến khích mọi người quay lại dùng xác thực bằng mật khẩu.
      Trừ khi phát hiện ra vấn đề này đã lan rộng trên các hệ thống thực tế, cách đó còn có vẻ tệ hơn chuyện những “chuyên gia” tương tự trước đây từng yêu cầu đổi mật khẩu hằng năm, khiến bảo mật thực tế kém đi nhưng bảo mật trên giấy tờ trông tốt hơn.
    • Vì có vẻ mã kiểm tra chữ ký chỉ chạy khi public key của client khớp với một fingerprint cụ thể, có thể phát hiện bằng thông tin timing.
      Việc kiểm tra chữ ký của backdoor sẽ mất khoảng 100µs, nên key có fingerprint khớp sẽ cần thời gian xử lý lâu hơn key không khớp đúng bằng khoảng đó. Chênh lệch thời gian này ít nhất là có thể phát hiện được trên LAN, và cũng có thể phát hiện qua Internet nếu scanner chạy ở vị trí gần mục tiêu.
      Những hệ thống chặn IP client sau nhiều lần xác thực thất bại sẽ khiến việc quét khó hơn.
      (https://bench.cr.yp.to/results-sign.html ghi xác minh Ed448 mất khoảng 400 nghìn chu kỳ, tương đương 100µs ở 4GHz)
    • Tweet nói là “không thể phát lại”. Tôi tò mò vì sao không thể phát lại. Có phải sshd có backdoor đưa ra một challenge nào đó rồi kẻ tấn công phải ký lên nó không?

  • Có thể là ý kiến không được ưa chuộng, nhưng tôi không thể không thán phục toàn bộ chiến dịch này. Tất nhiên là tôi lên án, nhưng vẫn phải thán phục. Từ ý tưởng đến thực thi, nó thật sự giống một tác phẩm nghệ thuật, và việc nó bị bắt sớm như vậy là một may mắn cực lớn.

    • Nếu payload không tạo ra hiện tượng SSH login ngẫu nhiên bị khựng 0,5 giây, có lẽ nó đã không bị phát hiện trong một thời gian dài.
      Lần sau, có khả năng kẻ tấn công sẽ tạo payload không gây ra những đợt tăng độ trễ kỳ lạ trong các tác vụ có người đang chờ.
      Không hiểu sao tôi lại nhớ đến chuyện Kim Dotcom phát hiện mình là mục tiêu nghe lén trái phép. Lý do là ping của ông ấy trong MW3 đột nhiên tăng mạnh. Điều tra ra thì chỉ riêng packet của ông ấy bị định tuyến vòng qua văn phòng GCSB ở một nơi rất xa về mặt vật lý. GCSB không có quyền nghe lén thường trú nhân New Zealand. Cuối cùng ông ấy nhận được lời xin lỗi cá nhân từ Thủ tướng New Zealand.
    • “Dù sao thì kẻ lẽ ra không bao giờ được merge đó đã làm một việc vĩ đại. Khủng khiếp, nhưng vĩ đại.”
      Tôi nghĩ phần tài tình nhất là lựa chọn dự án để xâm nhập. Khi đọc lại muộn màng cuộc thảo luận pull request IFUNC của “Hans”, thật đau lòng, nhưng nó cho thấy rất rõ vì sao dự án này được chọn.
      Tôi muốn biết phía sau “Jia” và “Hans” có bao nhiêu người, và họ đã phân tích, xây dựng chiến lược cho giao tiếp cũng như đóng góp code như thế nào. Một số khía cạnh như các nhân cách thứ ba giả vờ gây áp lực trên mailing list trông có vẻ được dựng hơi vụng.
      Vì vậy vẫn có khả năng đây là một nhóm nhỏ tinh vi, thậm chí là một cá nhân đơn độc. Nếu là tác nhân nhà nước, tôi nghĩ họ sẽ có những người làm việc cả ngày để tạo và duy trì các nhân cách giả cho kiểu chiến dịch này.
      Nếu ai đó nghĩ rằng “ba người dùng này thúc ép hơi thô lỗ một cách kỳ lạ, họ là ai vậy? Các tài khoản đều được tạo cùng thời điểm. Đáng ngờ. Tại sao ai đó lại cố dùng tài khoản giả để thúc ép mạnh chuyện này như thế? Phải điều tra mới được”, thì họ đã gặp rắc rối. So với toàn bộ công sức bỏ ra, phần đó là bất cẩn, hoặc kế hoạch kém, hoặc thiếu ngân sách.
    • Tôi đồng ý, nhưng phần social engineering thì đặc biệt tàn nhẫn.
    • Tôi không nghĩ đó là ý kiến quá không được ưa chuộng. Đây là một cuộc tấn công rất ấn tượng ở nhiều mặt. Nó tinh vi, được xây dựng trong nhiều năm, và nếu kẻ tấn công không mắc lỗi gây suy giảm hiệu năng kỳ lạ khiến người ta điều tra, có lẽ chúng ta đã không biết.
      Thêm một giả thuyết kịch tính: có thể kẻ tấn công đã sợ “quả bom hạt nhân thông tin” mà mình sắp kích nổ nên cố tình làm hỏng.
      Có thể vừa ghê tởm kết quả cuối cùng, vừa công nhận độ phức tạp của cuộc tấn công.
    • Tôi không biết “thán phục” có phải là đúng từ không, nhưng đúng là một chiến dịch khá ấn tượng.