Cảnh báo: AI độc hại tấn công RubyGems qua lỗ hổng thực thi mã từ xa trong YARD

Hôm nay, cả Reuters và Wall Street Journal đều đưa tin về các tác nhân AI "nổi loạn" của OpenAI đang tấn công RubyGems.org. Trang https://www.rubyhack.ai/ có một bài viết phân tích rất tuyệt vời và bạn nên đọc nó. Tôi chỉ muốn viết nhanh một bài về vấn đề này vì nó thực sự quá điên rồ.

Tóm tắt: Có vẻ như các Bot của OpenAI đã biết về lỗ hổng bộ nhớ đệm (caching) này, cố gắng tận dụng nó, đồng thời chạy một số đoạn mã cào dữ liệu web (web scraping) kỳ lạ trên RubyDoc.info.

Quay lại tháng 5, socket.dev đã báo cáo về một "Chiến dịch GemStuffer", nơi một ai đó (tôi đoán là OpenAI) đã tải lên hàng tấn các gem rác lên RubyGems.org. Vì lý do nào đó, các gem này sẽ cào dữ liệu từ các trang web chính phủ Anh, sau đó đóng gói lại dữ liệu đó thành các gem và cố gắng tải chúng lên RubyGems.

Thành thật mà nói, tôi đã không suy nghĩ nhiều về điều này (hoặc thậm chí không tìm hiểu kỹ) cho đến khi Sydney Von Arx và Spencer Kitts (cả hai đều là đồng tác giả trên https://www.rubyhack.ai) liên hệ với tôi để hỏi về RubyGems. Tôi đã nghĩ những tuyên bố của họ hoàn toàn viển vông cho đến khi tôi thực sự đọc mã nguồn trong các gem "GemStuffer" này.

Sau khi đọc mã nguồn trong các gem này, có một vài điểm khiến tôi chú ý.

Tài liệu YARD

Đầu tiên, các gem này tận dụng tài liệu YARD để thực thi mã tùy ý trên máy chủ. Trong hầu hết các ví dụ, bạn sẽ thấy một tệp.yardopts trông như thế này:

Đây là liên kết đến một ví dụ.

Nếu bạn đã cài đặt YARD và bạn cài đặt gem này, thì YARD sẽ tải và chạy bất cứ thứ gì nằm trong./script.rb từ bên trong gem. Tôi nghĩ việc các phần mở rộng C thực thi extconf.rb (về cơ bản là một vector RCE) đã là kiến thức khá phổ biến, nhưng tôi đã rất ngạc nhiên khi phát hiện ra rằng một công cụ tài liệu cũng làm điều tương tự.

Tuy nhiên, sẽ chẳng ai đi cài đặt một gem có tên là slnleaker5 cả, vậy tại sao điều này lại quan trọng? Chà, bất cứ khi nào một Gem được xuất bản, RubyDoc.info sẽ tải xuống gem đó và xử lý tài liệu YARD. RubyDoc.info sẽ thực thi mã tùy ý bên trong một container Docker. Mặc dù vậy, container Docker vẫn có quyền truy cập mạng, vì vậy các gem này có thể thoải mái thực hiện việc cào dữ liệu web từ bên trong container.

Nói cách khác, nếu bạn xuất bản một gem trên RubyGems.org, bạn có thể thực thi mã tùy ý trên RubyDoc.info.

Khai thác bộ nhớ đệm Fastly

Tôi đã đề cập trước đó rằng các gem này sẽ cố gắng cào một số trang web và sau đó tải lên dữ liệu mà chúng đã cào được bằng cách đóng gói nó dưới dạng một gem. Đây là một đoạn trích từ một trong những gem đó. Tôi đã làm sạch mã một chút để dễ hiểu hơn, nhưng mã gốc nằm ở đây:

Các bình luận trong mã có ghi (Aaron) là những bình luận tôi viết để giúp mọi người dễ hiểu hơn. Bình luận đầu tiên được lấy trực tiếp từ nguồn. Đoạn mã trên cố gắng thực hiện hai yêu cầu. Yêu cầu đầu tiên là một yêu cầu GET đơn giản. Nó cố gắng tìm nạp một đường dẫn từ RubyGems.org, sau đó tìm kiếm một khóa trong phần thân phản hồi khớp với biểu thức chính quy /rubygems_[a-f0-9]{20,}/. Nếu biểu thức chính quy đó không khớp, nó sẽ quay lại sử dụng một KEY toàn cục. Yêu cầu thứ hai cố gắng tải gem lên thông qua POST.

Điều này dẫn tôi đến điểm điên rồ thứ hai khiến tôi chú ý. Đoạn mã này đang cố gắng tìm nạp một khóa xác thực được lưu trong bộ nhớ đệm từ RubyGems.org. Nếu điều này nghe có vẻ quen thuộc, thì đúng là như vậy. Đó chính xác là vấn đề bảo mật đã được giải quyết trong bài viết này từ RubyGems.org được đăng vào tháng 7.

Nói cách khác, có vẻ như các bot của OpenAI đã biết về vấn đề này và cố gắng khai thác nó.

Thật là một thời đại đầy bất ngờ 🙃