2 điểm bởi GN⁺ 2024-04-07 | 1 bình luận | Chia sẻ qua WhatsApp
  • Backdoor sshd của xz không chỉ dừng ở hook RSA_public_decrypt được phát hiện ban đầu, mà còn kích hoạt một phần đường dẫn mã bổ sung khó tiếp cận hơn
  • Luồng tấn công hoạt động bằng cách cài hook mm_answer_keyallowed bằng một lệnh bị thao túng, rồi dùng nhiều khóa công khai ssh-rsa giả để lắp ghép bộ đệm lệnh
  • “magic buffer” này chứa các lệnh backdoor bổ sung và 2 chữ ký ed448; chữ ký có tính đến digest SHA256 của host key và session_id của KEX
  • PoC hiện sử dụng thư viện client SSH paramiko đã được chỉnh sửa mạnh; lệnh 0x03 cho phép RCE dựa trên system() và thiết lập uid/gid
  • Việc vượt qua xác thực cũng đã được xác nhận; nếu ghi đè phản hồi mm_answer_authpassword bằng mm_keyallowed_backdoor cmd 1, có thể đăng nhập bằng mật khẩu bất kỳ

Đường dẫn backdoor được nối sâu hơn

  • Backdoor xz sshd bao gồm các chức năng sâu hơn so với hành vi được biết ban đầu, và một phần đã được kích hoạt trực tiếp
  • Điểm vào cốt lõi là hook RSA_public_decrypt
    • Khi gửi một lệnh được tạo đúng cách, một hook khác sẽ được cài vào hàm mm_answer_keyallowed của sshd
    • Sau đó, cung cấp nhiều khóa công khai ssh-rsa giả để ghép các mảnh “magic buffer” lại với nhau
  • “magic buffer” là bộ đệm chứa các lệnh backdoor bổ sung
    • Bên trong cũng có 2 chữ ký ed448
    • Các chữ ký này được xử lý salt bằng digest SHA256 của host key, tương tự chữ ký backdoor ở phía RSA_public_decrypt
    • Chữ ký cuối cùng cũng tính đến session_id dài 0x20 byte được dẫn xuất từ quá trình trao đổi khóa ban đầu (KEX) của SSH

PoC và vượt qua xác thực

  • PoC hiện được triển khai bằng thư viện client SSH paramiko đã được chỉnh sửa mạnh
  • Lệnh hiện đã được kích hoạt trong đường dẫn mã này là 0x03
    • Cho phép lại RCE cơ bản thông qua system()
    • Cũng hỗ trợ thiết lập uid/gid
  • Vẫn còn thêm mã cần được hiểu rõ, và vì một trong các lệnh backdoor của mm_answer_keyallowed cuối cùng cũng hook cả mm_answer_keyverify, có vẻ có thể vượt qua toàn bộ xác thực của phiên tương tác
  • Sau đó, việc vượt qua xác thực đã được xác nhận
    • mm_keyallowed_backdoor cmd 1 có thể ghi đè phản hồi của mm_answer_authpassword bằng giá trị do người dùng chỉ định
    • Nếu đặt phản hồi thành { u32(9), u8(13), u32(1), u32(0) }, có thể đăng nhập bằng bất kỳ mật khẩu nào

1 bình luận

 
GN⁺ 2024-04-07
Các ý kiến trên Hacker News
  • https://threadreaderapp.com/thread/1776691497506623562.html

  • Vụ này kỳ lạ ở chỗ, một mặt trông rất chuyên nghiệp, mặt khác lại khá nghiệp dư
    Họ đã xây dựng một danh tính đáng tin cậy trong thời gian dài đến mức trở thành maintainer của một gói quan trọng, thực hiện một cuộc tấn công social engineering có vẻ có nhiều người tham gia, không để lộ danh tính thật hay nguồn gốc tấn công, và kỹ thuật làm rối cũng tinh vi
    Thế nhưng việc bug và hồi quy hiệu năng lọt vào bản production lại trông cẩu thả. Nếu một tổ chức được nhà nước hậu thuẫn thật sự có năng lực, tôi nghĩ họ hẳn đã kiểm thử đầy đủ một cách riêng tư trước khi gửi lên dự án công khai, để loại bỏ tình trạng suy giảm hiệu năng dễ gây nghi ngờ

    • Có lẽ kỳ vọng quá cao khi nghe nói “được nhà nước hậu thuẫn”. Tổ chức lớn rốt cuộc cũng giống các tổ chức lớn khác, gặp quan liêu, deadline, chu kỳ phát hành và vấn đề giao tiếp giữa các nhóm
      Vụ “có thể là backdoor” gần đây trên iOS cũng cho thấy các tổ chức tích trữ nhiều lỗ hổng không phải lúc nào cũng quá bận tâm khi phải đốt đi một vài cái
    • Việc những người phát triển mã không đồng thời chạy Valgrind để theo dõi hiệu năng không phải là điều khó tin
      Mục tiêu là server và appliance; có bao nhiêu server hay appliance chạy Valgrind trên image mặc định chứ. Nhìn lại thì sẽ nghĩ “sao họ không nghĩ ra nhỉ”, nhưng rất có thể họ đã kiểm thử trên các system image mà họ nhắm tới, chứ không phải image tùy biến của một developer thông thường
    • Ngày 2024-02-29 có một PR được mở để không link liblzma vào libsystemd [0]
      Kevin Beaumont suy đoán rằng “Jia Tan” thấy việc này và lập tức nhận ra backdoor có thể bị vô hiệu hóa, nên đã vội vàng để không làm mất khối lượng công việc khổng lồ đã bỏ vào exploit này [1], và có vẻ nhận định đó đúng
      Do áp lực deadline đó, 5.6.0 đã bị crash, và họ không đủ thời gian để tinh chỉnh nhằm giảm hoặc loại bỏ hồi quy hiệu năng, vốn là nguyên nhân cốt lõi khiến vụ này bị phát hiện
      [0]: https://github.com/systemd/systemd/pull/31550
      [1]: https://doublepulsar.com/inside-the-failed-attempt-to-backdo...
    • Nếu ngay cả Google cũng có thể thản nhiên phát hành Gemini, thì việc một tổ chức trong bóng tối như vậy thất bại theo cách tinh vi hơn có gì khó tin đến thế không
      Như Patrick McKenzie từng chỉ ra ở nơi khác, các tổ chức tội phạm cũng vận hành bằng ủy ban và đồng thuận tương tự các tổ chức phi tội phạm. Nhìn như vậy thì việc con tàu chìm vì suy giảm hiệu năng do phình to chức năng cũng dễ hiểu. Những công ty tôi từng làm còn mắc các lỗi nghiệp dư hơn nhiều
    • Ngay cả các tổ chức được nhà nước hậu thuẫn có năng lực cũng có thể gặp sự cố. Các cơ quan tình báo đôi khi cũng không lạnh lùng và tài giỏi như ta tưởng. Những nỗ lực ám sát của Kremlin ở Anh gần như là một vở hài kịch của các sai lầm [1]
      Có lẽ một backdoor khác hoặc phương thức truy cập thay thế mà họ đang dùng đã bị chặn, nên họ cần gấp một lối vào mới
      [1] https://en.wikipedia.org/wiki/Poisoning_of_Alexander_Litvine...
  • Điều thật sự thú vị ở đây là mức độ tinh vi, nhưng cuối cùng lại bị bắt vì một hồi quy hiệu năng khá dễ thấy
    Tôi nhớ đến một câu trích trong một chương trình tội phạm có thật: “Có cả triệu cách để bị bắt vì giết người, và nếu bạn nghĩ ra được một nửa trong số đó thì bạn đã là thiên tài rồi”

    • Nếu giả định phía sau tài khoản là một nhóm thì sẽ dễ hiểu hơn. Có người phát triển chức năng, rồi một người khác bất cẩn hơn hoặc ít kinh nghiệm hơn có thể đã tích hợp nó
      Một người khác nữa có thể đã quản lý các tài khoản giả và tương tác trong bình luận cũng như PR
    • Có thể tôi ngây thơ hoặc quá cả tin, nhưng mỗi lần lo rằng các backdoor như thế này đã lan rộng, tôi lại nghĩ đến điều này
      Không rõ lần này chỉ là xui xẻo nên bị phát hiện, hay những cuộc tấn công kiểu này thật sự quá khó để thành công. Tôi hy vọng là vế sau, nhưng thật ra không thể biết được
    • Nếu tôi nhớ đúng, hồi quy hiệu năng chỉ xảy ra khi mã được biên dịch với -fno-omit-frame-pointer, vốn không phải mặc định. https://mastodon.social/@AndresFreundTec/112187000944648334
    • Nếu có đủ thời gian và kiểm thử cục bộ nhiều hơn, rất có thể họ đã thành công
      Tôi tin chắc rằng bản vá của @teknoraver cho libsystemd đã làm thay đổi mốc deadline của họ
    • Câu “nếu nghĩ ra được một nửa” cũng áp dụng cho phía đang cố phá án giết người chứ?
  • Khi đọc nhiều bài viết kỹ thuật đào sâu chi tiết về những vụ như thế này, tôi thường thắc mắc vì sao ai cũng nói “chắc chắn đây là do nhà nước hậu thuẫn”, “hãy nhìn timestamp đi, bằng chứng không thể phản bác”
    Đúng là vụ xz là một cuộc tấn công âm thầm và được chuẩn bị công phu trong thời gian dài, nhưng liệu có thật sự cần điều gì đó vượt quá một cá nhân rất giỏi không? Việc những cá nhân ngẫu nhiên trên mạng có thể phân tích và hiểu được nó cũng có nghĩa là nó nằm trong phạm vi một người có thể hiểu
    Vì sao không thể là khả năng một người thông minh nhưng bất mãn đã đơn độc làm việc này?

    • Yếu tố lớn nhất khiến người ta nghĩ đến tác nhân nhà nước là quy mô phần thưởng kỳ vọng so với thời gian bỏ vào tấn công social engineering
      Một kế hoạch kiếm tiền theo cách này là phi lý. Điều đó không loại trừ khả năng một tác nhân phi lý trí hoặc một cá nhân có động cơ không phải tiền bạc, nhưng nó khiến tác nhân nhà nước trông như ứng viên có khả năng cao
      Nếu thành công, giá trị có thể đem bán sẽ cực lớn, nhưng xác suất cài exploit vào hạ tầng trọng yếu rồi không bị phát hiện đủ lâu để khách hàng mua và dùng là rất thấp. Nhà nước có thể chịu được các “moonshot”, còn cá nhân thì tôi nghĩ thường sẽ tìm mục tiêu có kỳ vọng lợi ích cao hơn
      Tất nhiên, điều đó không có nghĩa đây là một tác nhân nhà nước có năng lực cao hoặc đã phân bổ nhiều tài nguyên
    • Đồng ý. Vụ hack này cần rất nhiều kỹ năng, quyết tâm và thời gian
      Nhưng chẳng phải điều đó cũng đúng với khá nhiều nhà phát triển mã nguồn mở sao. Động cơ cũng rõ ràng. Exploit này hẳn có giá hàng triệu đô la trên chợ đen
    • Không có gì cả. Không ai biết hắn là ai
    • Tôi tò mò bạn thấy cụm “bằng chứng không thể phản bác” ở đâu
      Tôi thấy nhiều suy đoán từ những người am hiểu, nhưng chưa thấy cách diễn đạt như vậy
  • Có bài nào tổng hợp về chính phần làm rối mã của backdoor không? Ý tôi là backdoor thực sự, không phải build script dùng để cài đặt
    Tôi đã đưa binary vào Ghidra và lướt qua các hàm tìm được, nhưng vì không quen với cơ chế ifunc dùng để chặn luồng thực thi nên đã bỏ cuộc và để người khác làm
    Vì có chức năng chống debug nên tôi nghĩ mã cũng đã bị làm rối. Do được phân phối dưới dạng binary mờ đục, tôi đã nghĩ ít nhất một phần mã được mã hóa bằng khóa mà chúng ta không có, giống như một phần payload của STUXNET

    • Chưa có phân tích hoàn chỉnh về chính backdoor. Một số cơ chế chống debug có thể né bằng flag, nhưng lần này nó được xử lý ở giai đoạn biên dịch, nên khó hơn một chút
      Có chức năng chống debug không có nghĩa là mã nhất thiết đã bị làm rối. Như đã nói ở trên, vì nó diễn ra tại thời điểm build. Kiểu như đã đặt bẫy ngay trong nhà mình rồi
      Vụ này cho thấy vấn đề xảy ra khi trình quản lý gói không lấy source từ đúng nguồn
  • Tôi không theo dõi vụ này thật sát, nhưng thấy rất lạ là gần như không nghe thảo luận gì về thủ phạm vụ hack

    • “Tuy nhiên, tôi cho rằng thực ra hắn đến từ múi giờ UTC+02 mùa đông/UTC+03 DST, tức khu vực bao gồm Đông Âu (EET) hoặc Israel (IST)”
      https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
    • Đã có nhiều suy đoán. Khả năng cao là nhiều người hơn là một người, và có vẻ có thể là nhóm ransomware hoặc cơ quan tình báo nhà nước
    • Sẽ thú vị nếu phân tích ngữ nghĩa các trao đổi của những persona trực tuyến liên quan, giống như khi phân tích Satoshi, để ước đoán hướng văn hóa
      Nếu xem liệu văn phong có khác đi theo thời gian hay không, cũng có thể biết liệu nhiều người có cùng hoạt động dưới một persona hay không. Cũng có khá nhiều mã đã commit, nên đáng xem xét liệu có hơn một người tham gia thông qua khác biệt về phong cách code hay không
    • Thảo luận cái gì? Chẳng có gì được biết cả
  • Khá may là vụ này bị phát hiện trước khi lan rộng
    Không chỉ vì lý do hiển nhiên là chúng ta không muốn một thực thể không rõ danh tính có thực thi mã từ xa trên hạ tầng của mình. Nếu mọi người tiếp tục đào sâu, cuối cùng có khả năng họ sẽ tạo ra payload cho phép bất kỳ ai cũng dùng được backdoor
    Một thực thể có quyền truy cập đã là tệ, nhưng việc ai cũng có thể truy cập còn tệ hơn nhiều

    • Nếu payload là khóa RSA riêng tư thì chẳng phải gần như không thể sao?
  • Liên kết có thể xem thay cho thereaderapp.com:
    https://nitter.poast.org/bl4sty/status/1776691497506623562

  • Thật ngạc nhiên là sau vài ngày mà vẫn chưa được giải hoàn toàn
    Khi con mắt của cả thế giới đang đổ dồn vào và các mảnh ghép cốt lõi về lý thuyết đều đã công khai, việc nó trụ được đến mức này có nghĩa là phần làm rối mã đã được thực hiện khá tốt

  • Điều khiến tôi lo trong vụ này là tính chất đường dài
    Thứ nhất, kẻ đó đã chờ thời trong thời gian dài để xây dựng “hạ tầng” tạo backdoor. Thứ hai, sau khi exploit thực sự lan vào production, hẳn chúng còn chuẩn bị một cuộc chơi dài hạn khác. Cách đúng để dùng tiền trúng xổ số là đem đi đầu tư mà
    Thứ ba, tôi tự hỏi liệu những trò chơi như vậy hiện vẫn đang diễn ra không. Đáng sợ