Backdoor XZ: thời gian, thời gian bị nguyền rủa, và những trò lừa
(rheaeve.substack.com)- Xung quanh backdoor trong tarball xz/liblzma, múi giờ và mô hình làm việc trong các Git commit của Jia Tan đã được dùng như manh mối để suy đoán khu vực hoạt động thực tế
- Thời điểm commit có thể bị chỉnh sửa bằng
GIT_AUTHOR_DATEvàGIT_COMMITTER_DATE, nhưng thay vì làm giả toàn bộ mốc thời gian cho hợp lý thì có khả năng chỉ đổi múi giờ sẽ dễ hơn - Phần lớn trong số 440 commit của Jia Tan được ghi là UTC+08, nhưng một số bản ghi UTC+02·UTC+03 lại trùng khớp với chuyển đổi giờ mùa đông·mùa hè kiểu Đông Âu
- Việc chuyển múi giờ vào ngày 6/10/2022 và 27/6/2023 diễn ra trong khoảng cách quá ngắn để có thể dễ dàng giải thích bằng việc di chuyển thực tế, làm giả thuyết đi lại đơn thuần kém thuyết phục hơn
- Một số commit +0200 dường như là patch do Lasse Collin áp dụng bằng
git am, nên trong luồng patch qua email, độ tin cậy của thông tin múi giờ có giới hạn
Backdoor XZ và đối tượng phân tích
- Backdoor được phát hiện trong tarball xz/liblzma được xem là một sự cố làm lung lay mạnh niềm tin vào hệ sinh thái phần mềm tự do
- Có nhận định rằng backdoor có thể đã được cài vào bởi Jia Tan, người từng là maintainer lâu năm của xz
- Trong cộng đồng, gần như không có thông tin nào được biết về Jia Tan ngoài cái tên, và ngay cả cái tên đó cũng có thể không phải thật
- Đối tượng phân tích là hoạt động GitHub của JiaT75 và dấu thời gian commit trong kho mã xz
- Bài viết công khai làm điểm khởi đầu là bài đăng trên mailing list oss-security
Vì sao khó làm giả timestamp Git
- Thời gian commit Git có thể thay đổi bằng các biến môi trường
GIT_AUTHOR_DATEvàGIT_COMMITTER_DATE - Với các commit chưa push, cũng có thể sửa ngày về sau bằng amend
- Tuy vậy, việc làm giả dữ liệu thời gian sao cho hợp lý đi kèm nhiều ràng buộc
- Nếu push các commit trông như được tạo trong tương lai, điều đó có thể gây nghi ngờ
- Các commit trông như cũ hơn cả thảo luận công khai liên quan cũng là điều không tự nhiên
- Để tránh các ràng buộc này, có thể phải giữ lại commit, từ đó làm chậm quá trình phát triển dự án
- Thay vì điều chỉnh thời điểm thực tế, việc chỉ thay đổi múi giờ có thể giúp ngụy trang dễ hơn mà không cần tính toán hoặc trì hoãn commit
Bản ghi UTC+08 và khả năng UTC+02/03
- Phần lớn commit của Jia Tan, tổng cộng 440 commit, được lưu với timestamp UTC+08
- UTC+08 nhiều khả năng là CST của Trung Quốc, nhưng Indonesia, Philippines và Tây Úc cũng thuộc cùng múi giờ
- Cái tên Jia Tan có thể là tín hiệu nhằm tạo cảm giác là người châu Á, đặc biệt là người Trung Quốc
- Có giả thuyết rằng khu vực hoạt động thực tế có thể là nơi dùng UTC+02 vào mùa đông / UTC+03 vào mùa hè
- Khu vực đó bao gồm EET ở Đông Âu, IST của Israel, v.v.
- Nếu hiệu chỉnh các bản ghi UTC+08 theo chuẩn UTC+02/03, mô hình làm việc sẽ trở thành khoảng từ 9 giờ sáng đến 6 giờ chiều khá bình thường
- Nếu không hiệu chỉnh, sẽ thành kiểu làm việc vào nửa đêm thứ Ba và 1 giờ sáng, kém tự nhiên hơn
Manh mối lộ ra từ việc chuyển múi giờ
- Một số commit có thể là kết quả của việc Jia Tan quên đổi lại múi giờ
- Có xác nhận 3 commit UTC+02 và 6 commit UTC+03
- UTC+02 khớp với giờ mùa đông trong tháng 2 và tháng 11
- UTC+03 khớp với giờ mùa hè vào tháng 6, tháng 7 và đầu tháng 10
- Điều này phù hợp với chuyển đổi giờ mùa hè ở Đông Âu, tức là mô hình +0200 sau cuối tuần cuối cùng của tháng 10 và +0300 sau Chủ nhật cuối cùng của tháng 3
- Múi giờ này dường như cũng trùng với múi giờ của Lasse Collin và Hans Jansen
- Trong cập nhật ngày 2/4, bài viết bổ sung theo góp ý của Joey Hess rằng nhiều trường hợp như vậy là các commit mà committer là Lasse Collin
- Tuy vậy, hiện tượng này không xuất hiện ở mọi commit của Jia do Lasse commit, và nhiều trường hợp vẫn được ghi là +0800
- Vì vậy, vẫn chưa rõ các commit +02/03 là do sơ suất hay chỉ là thay đổi workflow đơn thuần
Khoảng cách khó xem là di chuyển thực tế
- Cách giải thích rằng một người sống ở UTC+08 thỉnh thoảng bay sang khu vực UTC+02/03 không khớp tốt với chi tiết timestamp
- Ngày 6/10/2022 có một commit lúc 21:53:09 +0300, sau đó là commit lúc 17:00:38 +0800
- Chênh lệch giữa hai commit là khoảng 11 giờ
- Từ Trung Quốc tới Đông Âu hoặc Trung Đông, riêng thời gian bay tối thiểu cũng vào khoảng 10–12 giờ, mà chuyến bay thẳng lại hiếm nên có thể còn lâu hơn
- Ngày 27/6/2023 có commit lúc 23:38:32 +0800 và tiếp theo là commit lúc 17:27:09 +0300
- Chênh lệch giữa hai commit chỉ ở mức vài phút
- Những lần chuyển đổi như vậy củng cố khả năng Jia Tan thực ra không ở khu vực CST UTC+08
Mẫu ngày nghỉ và làm việc trong tuần
- Mẫu ngày nghỉ cũng có vẻ phù hợp với Đông Âu hơn là Trung Quốc
- Danh sách ngày nghỉ của Trung Quốc được tham chiếu từ thông báo ngày nghỉ năm 2023 của Bank of China Indonesia
- Có ghi nhận làm việc vào những ngày được nêu là ngày lễ ở Trung Quốc
- 29/9/2023: Tết Trung thu
- 5/4/2023: Tết Thanh minh
- 22–27/1/2023, v.v.: kỳ nghỉ Tết Nguyên đán
- Liên quan đến ngày lễ ở Đông Âu, có nhận định rằng không có bản ghi làm việc vào Giáng sinh 25/12, cũng như dịp năm mới 31/12 và 1/1
- Các ngày làm việc phổ biến nhất của Jia là thứ Ba 86 lần, thứ Tư 85 lần, thứ Năm 89 lần và thứ Sáu 79 lần
Lưu ý về tên và việc áp dụng patch
- Có ý kiến rằng nếu “Jia Cheong Tan” là tên thật thì đây không thể là cách Latinh hóa hợp lệ của một tên chữ Hán dùng ở Trung Quốc, mà gần với cách viết ở Đông Nam Á như Malaysia hơn
- Cách viết “Cheong” không được dùng trong tiếng Trung hiện đại, và cũng có ví dụ cho thấy kiểu ghi tiếng Anh của Trung Quốc thường viết liền các ký tự trong tên
- Ví dụ là “Yangqing Jia” chứ không phải “Yang Qing Jia”
- Tuy nhiên, hai commit +0200 là
de5c5e4,e446ab7acó committer là Lasse Collin, và dường như là patch do Jia gửi qua email rồi được áp dụng bằnggit am - Các commit đó cùng một số commit lân cận có cùng timestamp, điều này phù hợp với trường hợp áp dụng một nhóm file patch bằng
git am - Khi patch được gửi qua email, rất khó dựa vào thông tin múi giờ, nên một phần phân tích này trở nên kém chắc chắn hơn
1 bình luận
Các ý kiến trên Hacker News
Nếu đây là một cuộc tấn công được nhà nước hậu thuẫn, rất có thể đã có người/bộ phận viết mã và tin nhắn trên mailing list, cùng một nhóm riêng điều chỉnh thời điểm và timestamp mà những sản phẩm đó xuất hiện trên Internet sao cho khớp với “câu chuyện phù hợp với thiết lập của dự án”.
Đôi khi họ cũng có thể cố tình cài “sai sót” để gợi ý cho điều tra viên về một địa điểm được chọn khác, chứ không phải vị trí thật.
Một bài viết khác[1] cũng nêu khả năng các tài khoản bất ngờ xuất hiện đã tạo cảm giác cấp bách để thúc đẩy việc chuyển giao quyền quản lý sớm hơn.
[1] https://connortumbleson.com/2024/03/31/watching-xz-unfold-fr...
qua: https://news.ycombinator.com/item?id=39888854
Có thể tìm phần liên quan bằng cụm "Progress will not happen until there is new maintainer".
Bao gồm cả việc khiến hoạt động trông như diễn ra từ một vị trí cụ thể, đồng thời dàn dựng sao cho không có vẻ là hơn một người.
Tôi không nghĩ là người Đông Âu, nhưng xét UTC+0200/+0300 thì ở châu Âu có Phần Lan, ba nước Baltic, Ukraine, Romania, Moldova, Hy Lạp là phù hợp.
Đi xuống thêm một chút thì cũng bao gồm một vùng khá lớn ở Trung Đông, kể cả Israel.
Tuy nhiên ở Phần Lan người ta thường chuộng tháng 7 hơn nên điều này ít phổ biến hơn.
Nhìn bề ngoài thì có vẻ hợp lý.
Đặc biệt Unit 8200 của IDF có danh tiếng khá nổi bật.
Không có ý nói các nước khác không có năng lực, và cuộc tấn công này cũng không nhất thiết trông như việc cần đến tài nguyên cấp NSA hay GCHQ. Thực tế có thể chỉ là một con sói đơn độc, nhưng vẫn đáng chú ý.
Những thế lực có tài nguyên và động cơ gần như vô hạn có thể dựng chiến dịch cờ giả để hướng trách nhiệm về một phía nhất định. Họ rất giỏi xóa dấu vết, và ngay cả các nhà nghiên cứu bảo mật lão luyện nhất cũng có thể mất nhiều tháng hoặc nhiều năm mới đi đến một phỏng đoán có cơ sở về ai là kẻ chịu trách nhiệm.
Vì vậy việc cố tìm ra “ai đã làm” gần như là lãng phí thời gian.
Bài học là thế này: đừng vì bất kỳ lý do gì đưa phần mềm tối tân chưa được kiểm chứng vào môi trường vận hành; penetration tester của tổ chức phải thường xuyên thử phá stack và báo kết quả cho tổ chức cũng như maintainer gói; maintainer phần mềm tự do/mã nguồn mở cần audit mã mới nhạy cảm về bảo mật ở mỗi bản phát hành; và hãy quyên góp cho maintainer.
May mắn là nó chưa vào stable, và chúng ta chỉ suýt nữa thì gặp một Chernobyl bảo mật trong hệ thống, may mắn tránh được vào phút chót.
Có những người đang cố thuyết phục mọi người rằng một thế lực cụ thể là bên chịu trách nhiệm, và trong đó có mục đích địa chính trị. Ví dụ, trong bối cảnh ở Mỹ đang có thảo luận về việc cấm sở hữu nước ngoài đối với các web app phổ biến, sẽ tiện lợi đến mức nào cho một chính phủ hoặc doanh nghiệp hưởng lợi từ đạo luật đó nếu một người dùng GitHub có tên kiểu Trung Quốc commit một vector tấn công với timestamp trông như đến từ PRC.
Ngay cả khi thực sự là ai đó ở Trung Quốc đại lục, nếu được nhà nước hậu thuẫn thì dù có truy tố và yêu cầu dẫn độ, khả năng bị giao cho cảnh sát tư pháp Mỹ cũng gần như không có. Ngược lại, người đó thậm chí có thể bị “bịt miệng” để thông tin về tổ chức lớn hơn không rơi vào tay đối phương.
Ngoài các âm mưu kiểu phim Bond, kiến thức đó không có nhiều chỗ áp dụng trong thực tế. Ta thường đã biết người dùng đến từ đâu, và cũng có thể chặn theo khu vực. Nếu không, thì cần chuẩn bị cho các mối đe dọa khác đến từ khu vực đó.
GMT+8, cấu trúc tên (tên kiểu tiếng Trung/phương ngữ pha trộn + họ Hokkien), và các dấu hiệu[1] cho thấy đã truy cập từ nơi có vẻ là exit VPN hoặc máy chủ hosting ở Singapore, dù thật hay ngụy trang, đều khớp với danh tính người Singapore.
Vì vậy cũng nên tiếp nhận có chọn lọc nhận định của nguồn [1] rằng “cái tên nghe như giả”. Người Trung Quốc đại lục không phải lúc nào cũng hiểu rõ các cộng đồng Hoa kiều.
Nhiều ngày lễ được nhắc đến cũng không phải ngày nghỉ lễ của Singapore[2]. Ngày 24/1 là ngày nghỉ lễ, nhưng nếu áp dụng mẫu hình “làm việc vào ngày làm việc” thì ngày 22/1 là Chủ nhật nhưng lại được đánh dấu là có làm việc.
Sẽ thú vị nếu xem thêm các bài viết của Jia Tan, đặc biệt là các bài cũ hơn. Có thể có những thói quen ngôn ngữ khá rõ để phân biệt người Singapore, người Trung Quốc đại lục, người nói các ngôn ngữ Slav khác nhau, và người bản ngữ tiếng Anh.
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdo...
[2] https://www.mom.gov.sg/employment-practices/public-holidays
Tất nhiên mẫu rất nhỏ nên không thể suy diễn quá nhiều.
Gần 10% người Singapore mang họ Tan.
[1] [https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_f...](https://en.wikipedia.org/wiki/File:Singaporean_surnames_by_frequency.png)
Tạm gác mức độ nghiêm trọng của vấn đề sang một bên, tôi hoàn toàn bị cuốn vào khía cạnh như truyện trinh thám của sự việc này
Quá trình Internet lần ra “ai, bằng cách nào, vì sao” thật thú vị
Từ vài năm trước, chính vì lý do này mà tôi đã ánh xạ
gctrong terminal thànhTZ=UTC0 git commitKhông cần đổi giờ hệ thống hay cấu hình git. Có thể có cách tốt hơn trong cấu hình toàn cục, nhưng
cũng không phải vì lý do xấu. Tôi đi du lịch khá nhiều và không muốn để lộ lịch trình du lịch trong các kho công khai
Không chỉ đặt múi giờ về UTC mà còn đặt giờ thành 00:00, nên commit chỉ còn thông tin ngày. Tôi nghĩ thông tin được lưu vĩnh viễn trong commit git chỉ cần đến mức ngày là đủ, không cần để lộ thời điểm commit chính xác
alias git='TZ=UTC0 git'Việc đó cần thao tác thủ công, và tôi cũng không dùng dịch vụ định vị
Tội Jia thật. Hai năm làm việc đổ sông đổ biển hết
Jia, nếu đang đọc điều này thì hãy nhớ rằng bạn bỏ lỡ 100% những cú sút mình không thử. Ngẩng đầu lên nào, người anh em
“Ai lại thường xuyên làm việc vào sáng sớm?”
Tôi
“Nếu là hacker thì làm việc vào buổi chiều và khuya nghe hợp lý hơn nhiều”
Ở đây nếu thay hacker bằng người trẻ thì có lẽ đúng hơn
Tôi 41 tuổi và trong 10 năm qua chắc số ngày tôi thức dậy trước 7 giờ sáng chỉ khoảng 20 lần là cùng. Một nửa lý do tôi vẫn chịu nổi công việc máy tính là vì đây là một trong số ít nghề mà hầu hết các ngày tôi có thể làm theo lịch 11 giờ sáng–7 giờ tối mà vẫn làm tốt
Có người hợp buổi sáng và có người hợp ban đêm. Ai cũng có nhịp của mình, không phải chuyện để phán xét, và nó cũng không tự nhiên thay đổi hay buộc phải thay đổi khi già đi
c/hacker/younger personnày là gì vậy? Tôi biết phép thay thếs/a/b/củased, nhưng chưa biết cái bắt đầu bằngcBuổi sáng có nhiều sự gián đoạn kiểu phải đối phó với “người dậy sớm”, còn từ sau bữa trưa đến tối thì ít việc chen ngang hơn nhiều
Bốn giờ không bị gián đoạn có thể làm được nhiều việc hơn hẳn một ca 8 tiếng đầy điện thoại và email ngẫu nhiên. Tôi cũng không còn trẻ nữa, nhưng có những việc tôi làm ban đêm vì khi không bị quấy rầy và đã có vài giờ nghĩ lắt nhắt trước đó, tôi có thể hoàn thành trong một nửa thời gian
Nếu bạn có những buổi sáng yên bình thì tôi ghen tị đấy
“Vào thứ Ba, ngày 27 tháng 6 năm 2023, có hai commit lúc 23:38:32 +0800 và 17:27:09 +0300. Tính ra thì giữa hai commit có khoảng 9 giờ chênh lệch”
Nhưng 17:27:09 +0300 là 22:27:09 +0800, vậy chẳng phải hai commit chỉ cách nhau khoảng 1 giờ sao?
“Quyết định hơn, vào ngày 6 tháng 10 năm 2022 có một commit lúc 21:53:09 +0300 theo sau bởi commit lúc 17:00:38 +0800. Hai thời điểm này chỉ cách nhau vài phút!”
Không phải. Cái này gần 10 giờ chênh lệch
Có vẻ tác giả đã vô tình viết đảo hai phân tích, hoặc tính múi giờ không giỏi
Nếu đó là người Mỹ, hoặc người ở một khu vực hoàn toàn khác, giả làm người Đông Âu đang giả làm người Trung Quốc thì sao?
Nếu muốn ngụy trang điều gì đó, ít nhất họ cũng sẽ thêm một lớp vòng vèo nữa
Với cấu trúc như vậy thì dù có rò rỉ kiểu này cũng chẳng có chuyện gì xảy ra
Tôi là một trong các tác giả của bài gốc. Tôi đã nhận được nhiều ý tưởng hữu ích cho các phân tích sau này, và xin trả lời bốn phản biện xuất hiện thường xuyên như sau
Tôi đồng ý rằng không rõ đó là một người hay nhiều người. Tuy nhiên, ngay cả nếu là một nhóm, cách tiếp cận theo múi giờ vẫn có thể cho biết nhóm đó ở đâu. Thời gian hoạt động trông quá giống giờ làm việc chính quy, hơn là một nhóm rải khắp thế giới
Tất nhiên cũng có khả năng thời gian commit đã bị chỉnh, hoặc commit/upload được thực hiện bằng script hẹn giờ. Dù vậy, để thực sự che giấu chênh lệch múi giờ lớn thì phải đưa vào độ trễ rất lớn, nên tôi nghĩ về thực tế là khó. xz không được phát triển trong chân không, mà được phát triển trong lúc phản hồi các sự kiện trực tuyến như việc mở issue hay bài đăng trên mailing list
Hai ví dụ đúng là đã bị viết lẫn. Hai thời điểm mà chúng tôi nói là chênh khoảng 10 giờ thực ra chỉ cách vài phút, còn các thời điểm nói là cách vài phút thì lại chênh khoảng 10 giờ. Chúng tôi sẽ cập nhật
Cuối cùng, đúng là UTC+2/3 không chỉ là Đông Âu mà còn bao gồm một phần Trung Đông. Chúng tôi cũng đã làm rõ điểm này trong bản cập nhật bài viết