Chúng tôi đã viết về PHP hệ sinh thái đóng gói trước đây.

Giống như PyPI dành cho Pythonistas, Gems dành cho người hâm mộ Ruby, NPM dành cho lập trình viên JavaScript hoặc LuaRocks dành cho Luaphiles, Packagist là một kho lưu trữ nơi những người đóng góp cho cộng đồng có thể xuất bản chi tiết về các gói PHP mà họ đã tạo.

Điều này giúp các lập trình viên PHP đồng nghiệp dễ dàng nắm giữ mã thư viện mà họ muốn sử dụng trong các dự án của riêng họ và tự động cập nhật mã đó nếu họ muốn.

Không giống như PyPI, nơi cung cấp các máy chủ của riêng mình nơi lưu trữ mã thư viện thực tế (hoặc LuaRocks, đôi khi lưu trữ chính mã nguồn của dự án và đôi khi liên kết đến các kho lưu trữ khác), Packagist liên kết đến, nhưng không tự giữ các bản sao của mã mà bạn cần tải về.

Có một nhược điểm khi làm theo cách này, đáng chú ý là các dự án được quản lý thông qua các dịch vụ mã nguồn nổi tiếng như GitHub không cần duy trì hai bản sao của bản phát hành chính thức của họ, điều này giúp tránh được vấn đề “trôi phiên bản” giữa các phiên bản. hệ thống kiểm soát mã nguồn và hệ thống đóng gói.

Và có một nhược điểm, đáng chú ý là chắc chắn có hai cách khác nhau mà các gói có thể bị bẫy.

Bản thân trình quản lý gói có thể bị tấn công, trong đó việc thay đổi một URL duy nhất có thể đủ để đánh lạc hướng người dùng của gói.

Hoặc kho lưu trữ mã nguồn được liên kết đến có thể bị tấn công, do đó những người dùng theo dõi những gì trông giống như đúng URL sẽ kết thúc bằng nội dung giả mạo.

Tài khoản cũ được coi là có hại

T tấn công (chúng tôi sẽ gọi nó như vậy, mặc dù tin tặc có liên quan không công bố mã bẫy mìn nào) đã sử dụng cái mà bạn có thể gọi là phương pháp kết hợp.

Kẻ tấn công đã tìm thấy bốn tài khoản Packagist cũ và không hoạt động mà bằng cách nào đó chúng đã lấy được mật khẩu đăng nhập.

Sau đó, họ xác định 14 dự án GitHub được liên kết bởi các tài khoản không hoạt động này và sao chép chúng vào một tài khoản GitHub mới được tạo.

Cuối cùng, họ đã điều chỉnh các gói trong hệ thống Packagist để trỏ đến kho lưu trữ GitHub mới.

Nhân bản các dự án GitHub là cực kỳ phổ biến. Đôi khi, các nhà phát triển muốn tạo một nhánh rẽ chính hãng (phiên bản thay thế) của dự án dưới sự quản lý mới hoặc cung cấp các tính năng khác; vào những thời điểm khác, các dự án rẽ nhánh dường như được sao chép vì những gì có thể được gọi là “lý do thể tích”, làm cho các tài khoản GitHub trông lớn hơn, tốt hơn, bận rộn hơn và cam kết hơn với cộng đồng (nếu bạn bỏ qua cách chơi chữ) so với thực tế.

Mặc dù tin tặc có thể đã chèn mã giả mạo vào nguồn GitHub PHP được nhân bản, chẳng hạn như thêm trình theo dõi, keylogger, cửa hậu hoặc phần mềm độc hại khác, nhưng có vẻ như tất cả những gì chúng thay đổi là một mục duy nhất trong mỗi dự án: một tệp có tên composer.json.

Tập tin này bao gồm một mục có tên description, thường chứa chính xác những gì bạn muốn thấy: một chuỗi văn bản mô tả mã nguồn dùng để làm gì.

Và đó là tất cả những gì hacker của chúng tôi đã sửa đổi, thay đổi văn bản từ một nội dung mang tính thông tin, chẳng hạn như Project PPP implements the QQQ protocol so you can RRR, để các dự án của họ thay vào đó được báo cáo:

 Được quản lý bởi XXX@XXXX.com. Ищу работу на позиции Bảo mật ứng dụng, Trình kiểm tra thâm nhập, Chuyên gia bảo mật mạng.

Câu thứ hai, được viết một nửa bằng tiếng Nga, một nửa bằng tiếng Anh, có nghĩa là:

 Tôi đang tìm một công việc trong lĩnh vực Bảo mật ứng dụng...v.v.

Chúng tôi không thể nói thay cho tất cả mọi người, nhưng khi viết CV (lý lịch), chúng tôi không thấy điều này quá thuyết phục.

Ngoài ra, Nhóm đóng gói nói rằng tất cả các thay đổi trái phép hiện đã được hoàn nguyên và 14 dự án GitHub nhân bản đã không bị sửa đổi theo bất kỳ cách nào khác ngoài việc bao gồm lời mời làm việc của pwner.

Đối với giá trị của nó, tài khoản GitHub của chuyên gia Bảo mật ứng dụng tương lai vẫn hoạt động và vẫn có các dự án “phân nhánh” đó trong đó.

Chúng tôi không biết liệu GitHub vẫn chưa hoàn thành việc xóa tài khoản hoặc các dự án hay liệu trang web đã quyết định không xóa chúng hay chưa.

Xét cho cùng, việc giả mạo các dự án là phổ biến và được phép (ít nhất là khi các điều khoản cấp phép cho phép), và mặc dù mô tả một dự án mã không độc hại bằng văn bản Pwned by XXXX@XXXX.com là vô ích, nó hầu như không bất hợp pháp.

Phải làm gì?

• Đừng làm điều này. Bạn chắc chắn sẽ không thu hút được sự quan tâm của bất kỳ nhà tuyển dụng hợp pháp nào và (nếu chúng tôi thành thật mà nói) bạn thậm chí sẽ không gây ấn tượng với bất kỳ kẻ lừa đảo trên mạng nào.
• Đừng để các tài khoản không sử dụng hoạt động nếu bạn có thể giúp nó. Như chúng ta đã nói ngày hôm qua trên Ngày mật khẩu thế giới, hãy cân nhắc đóng các tài khoản mà bạn không cần nữa, với lý do bạn càng sử dụng ít mật khẩu thì càng ít bị đánh cắp.
• Không sử dụng lại mật khẩu trên nhiều tài khoản. Giả định của Packagist là mật khẩu bị lạm dụng trong trường hợp này nằm trong hồ sơ vi phạm dữ liệu từ các tài khoản khác mà nạn nhân đã sử dụng cùng một mật khẩu như trên tài khoản Packagist của họ.
• Đừng quên 2FA của bạn. Packagists kêu gọi tất cả người dùng của chính họ bật 2FA, do đó, chỉ một mật khẩu là không đủ để kẻ tấn công đăng nhập vào tài khoản của bạn và cũng khuyên bạn nên làm như vậy trên tài khoản GitHub của mình.
• Đừng mù quáng chấp nhận các bản cập nhật chuỗi cung ứng mà không xem xét tính chính xác của chúng. Nếu bạn có một trang web phụ thuộc gói phức tạp, thì bạn nên gạt bỏ trách nhiệm của mình sang một bên và để hệ thống tự động tìm nạp tất cả các bản cập nhật của bạn, nhưng điều đó chỉ khiến bạn và người dùng tuyến dưới của bạn gặp thêm rủi ro.

ĐÂY LÀ LỜI KHUYÊN TỪ NGÀY MẬT KHẨU THẾ GIỚI

• Phân phối nội dung và PR được hỗ trợ bởi SEO. Được khuếch đại ngay hôm nay.
• PlatoAiStream. Thông minh dữ liệu Web3. Kiến thức khuếch đại. Truy cập Tại đây.
• Đúc kết tương lai với Adryenn Ashley. Truy cập Tại đây.
• Mua và bán cổ phần trong các công ty PRE-IPO với PREIPO®. Truy cập Tại đây.
• nguồn: https://nakedsecurity.sophos.com/2023/05/05/php-packagist-supply-chain-poisoned-by-hacker-looking-for-a-job/