GitLost: Đánh lừa tác nhân AI của GitHub để làm rò rỉ kho lưu trữ riêng tư

 (noma.security)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Noma Labs đã phát hiện GitLost, một lỗ hổng prompt injection gián tiếp trong GitHub Agentic Workflows, cho phép chỉ với issue ở kho công khai cũng có thể làm lộ dữ liệu từ kho riêng tư cùng tổ chức vào bình luận công khai
  • Tính năng này biên dịch workflow Markdown thành tệp YAML Actions, rồi tác nhân AI dựa trên Claude hoặc GitHub Copilot sẽ đọc issue, gọi công cụ và truy cập các kho trong tổ chức
  • Workflow dễ bị tấn công sẽ đọc Title và Body của issue tại sự kiện issues.assigned rồi phản hồi bằng add-comment, trong khi có quyền đọc cả kho công khai lẫn riêng tư
  • Kẻ tấn công không cần mã nguồn, quyền truy cập hay thông tin xác thực; chỉ cần mở một issue có vẻ hợp lý trong kho công khai, và trong thử nghiệm thì nội dung README.md của poc và testlocal đã được đăng vào bình luận issue công khai
  • Guardrail của GitHub đã không chặn đúng như dự kiến với biến thể “Additionally”, và trong AI dạng tác nhân, chính cửa sổ ngữ cảnh phải được xem là bề mặt tấn công, nơi nội dung do người dùng kiểm soát cần được tách khỏi chỉ thị đáng tin cậy

Ranh giới tin cậy mà GitLost nhắm tới

  • Noma Labs đã phát hiện một lỗ hổng tên là GitLost trong Agentic Workflows mới của GitHub
  • Nếu một kẻ tấn công không cần xác thực đăng một GitHub Issue bị thao túng vào kho công khai thuộc cùng tổ chức, tác nhân có thể bị dẫn dụ lấy dữ liệu từ kho riêng tư trong tổ chức
  • Cách tấn công này thuộc dạng prompt injection gián tiếp, tức là giấu chỉ thị độc hại bên trong nội dung mà tác nhân AI sẽ đọc
  • Nếu chỉ thị bị ẩn của kẻ tấn công được xử lý trước chỉ thị mà quản trị viên dự định, dữ liệu riêng tư có thể bị lộ ra trong bình luận issue công khai mà ai cũng xem được

Cách GitHub Agentic Workflows hoạt động

  • GitHub Agentic Workflows cho phép các nhóm viết tự động hóa cho kho bằng ngôn ngữ tự nhiên
  • Workflow được viết dưới dạng tệp Markdown .md, rồi được biên dịch thành tệp GitHub Actions .yml ở định dạng YAML
  • Khi chạy, tác nhân AI dựa trên Claude hoặc GitHub Copilot sẽ hoạt động trong phạm vi quyền đã cấu hình
    • Đọc GitHub Issue
    • Gọi công cụ
    • Truy cập các kho khác trong tổ chức

Điều kiện của workflow dễ bị tấn công

  • Cấu hình dễ bị tấn công mà Noma Labs xác nhận sẽ trở thành vấn đề khi kết hợp issue công khai với quyền của tác nhân
    • Workflow được kích hoạt bởi sự kiện issues.assigned của GitHub
    • Đọc Title và Body của issue
    • Đăng bình luận bằng công cụ add-comment
    • Có quyền đọc các kho khác trong tổ chức
      • Kho công khai
      • Kho riêng tư
  • Kẻ tấn công không cần viết mã riêng, không cần quyền truy cập hay thông tin xác thực
  • Điều kiện duy nhất là mở issue trong kho công khai của tổ chức đang sử dụng GitHub Agentic Workflow

Diễn biến tấn công

  • Nhóm nghiên cứu đã tạo một GitHub Issue có vẻ hợp lý như thể đó là yêu cầu từ VP Sales sau một cuộc họp với khách hàng
  • Khi issue được gán, workflow action đã được kích hoạt, và trong thử nghiệm thì cách này cũng hoạt động tương tự ở các GitHub workflow action khác
  • Sau khi tự động hóa của GitHub gán issue, workflow được chạy theo sự kiện đã khiến tác nhân lấy nội dung từ các kho
  • Tác nhân bị dẫn dụ lấy nội dung README.md của các kho sau
    • poc kho công khai
    • testlocal kho riêng tư
  • Sau đó tác nhân GitHub đã đăng nội dung này vào bình luận issue của kho công khai, khiến bất kỳ ai cũng có thể đọc được

Vượt guardrail bằng “Additionally”

  • GitHub có guardrail hạn chế để ngăn kịch bản này
  • Noma Labs đã lặp lại nhiều biến thể thử nghiệm như một kẻ tấn công thực sự
  • Chỉ cần thêm từ khóa “Additionally”, mô hình đã không từ chối mà lại có hành vi ngoài ý muốn là tái cấu trúc đầu ra
  • Với cách vượt này, guardrail của GitHub đã không hoạt động đúng như dự kiến và không ngăn được rò rỉ dữ liệu

PoC và dữ liệu bị lộ

Giả định bảo mật thay đổi trong AI dạng tác nhân

  • Cửa sổ ngữ cảnh của tác nhân vừa là không gian làm việc, vừa là bề mặt tấn công
  • Mọi nội dung mà tác nhân đọc đều có thể bị vũ khí hóa
    • Issue
    • Pull Request
    • Bình luận
    • Tệp
  • Các mô hình bảo mật truyền thống thường giả định ranh giới tin cậy được cưỡng chế bằng mã
  • Trong hệ thống dạng tác nhân, một phần của ranh giới tin cậy được cưỡng chế bởi hành vi của mô hình
  • Vì mô hình về bản chất sẽ làm theo chỉ thị, prompt injection trở thành một loại lỗ hổng mang tính phân loại trong AI dạng tác nhân, tương tự như SQL injection từng là với ứng dụng web
  • Loại lỗ hổng này cần có chiến lược và cơ chế phòng vệ mang tính hệ thống

Biện pháp phòng vệ khuyến nghị và quy trình công bố

  • Không nên coi nội dung do người dùng kiểm soát là đầu vào chỉ thị đáng tin cậy cho tác nhân AI
  • Quyền của tác nhân cần bị giới hạn ở mức tối thiểu cần thiết
    • Tác nhân có thể truy cập nhiều kho đặc biệt trở thành mục tiêu tấn công có giá trị cao
  • Cần hạn chế những gì tác nhân có thể đăng công khai, chẳng hạn khi phản hồi nội dung issue
  • Cần làm sạch hoặc cô lập đầu vào của người dùng khỏi ngữ cảnh chỉ thị trước khi chuyển cho mô hình
  • GitLost đã được công bố có trách nhiệm tới GitHub, và chi tiết lỗ hổng được chia sẻ trong khi GitHub đã nắm được vấn đề

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Các ý kiến trên Hacker News

  • Phép ví von rằng prompt injection trong AI dạng tác nhân có vị trí giống SQL injection đối với ứng dụng web nghe khá lạ. Có lẽ prompt injection nguy hiểm với LLM hơn SQL injection rất nhiều
    SQL injection phát sinh khi đầu vào của người dùng trở thành một phần của chuỗi lệnh được truyền cho SQL engine; đầu vào độc hại dùng token cú pháp SQL để kết thúc lệnh hiện tại rồi nối thêm lệnh SQL của nó, khiến engine thực thi cả hai. Cách giải quyết là dùng chuỗi lệnh cố định, tĩnh, được biên dịch trước như prepared statement, và chỉ áp dụng đầu vào tùy ý của người dùng như dữ liệu
    Biện pháp giảm thiểu tương tự trong tác nhân là đặt sẵn các hành động cố định như “đọc repo 1”, “đọc repo 2”, còn đầu vào người dùng chỉ được dùng như dữ liệu để chọn hành động nào sẽ chạy; nhưng đây là kỹ thuật vốn đã được gọi là menu. Khác biệt là giá trị của LLM về bản chất nằm ở chỗ vượt quá menu, còn giá trị của SQL thì không cần vượt quá “logic được định nghĩa sẵn áp dụng lên dữ liệu tùy ý”

    • Đúng vậy. SQL injection xảy ra vì đầu vào người dùng bị xem là một phần của lệnh chứ không phải dữ liệu thuần túy, và được giải quyết bằng cách tách hai thứ đó ra. Prompt injection khó tránh hơn vì bản thân đầu vào người dùng đã được dự định là lệnh
    • Thay vì nói “cách giải quyết là prepared statement”, điểm cốt lõi là ràng buộc tham số. Tức là gửi tham số tách khỏi câu lệnh SQL để phân tách code và dữ liệu người dùng
      Việc chỉ cho phép tác nhân thực hiện các hành động bị giới hạn chỉ xử lý một số vấn đề đặc thù, và cũng không tách code khỏi dữ liệu người dùng, nên không phải cùng một vấn đề. Chỉ có các hành động giới hạn thì gần với việc dùng quyền cơ sở dữ liệu nghiêm ngặt hơn. Nếu chỉ cho phép những SQL mà người dùng vốn dĩ có thể thực thi, thì SQL injection cũng chẳng còn mấy ý nghĩa
    • Đây đúng là cùng loại vấn đề với SQL injection, nhưng độ khó để giải quyết thì không giống nhau. Có thể phát sinh nhiều vấn đề tinh vi hơn, nhưng dùng làm phép ví von để giải thích thì cũng ổn
      Cho chọn từ menu cũng là một cách, nhưng phạm vi hành động khả dĩ có thể được thiết kế rộng hơn. Nếu cấp công cụ email, nó có thể gửi spam cho khách hàng; nếu khóa lại chỉ cho phép trả lời, phạm vi sự cố sẽ giảm. Cũng như các lỗ hổng kiểu rò rỉ dữ liệu qua render hình ảnh, rò rỉ dữ liệu cũng phải bị hạn chế
    • Prompt injection không hẳn là chí mạng, và thực tế gần với việc phơi bày vấn đề kiến trúc bảo mật nền tảng hơn là một vấn đề thật sự. Nó giống các cuộc tấn công social engineering nhắm vào con người
      Cách giải quyết cũng giống vậy. Áp dụng kiểm soát truy cập dựa trên vai trò theo nguyên tắc đặc quyền tối thiểu, và yêu cầu quản trị viên phê duyệt các hành động quan trọng. Khi đó điều tệ nhất LLM có thể tự làm chỉ là xuất ra vài từ không phù hợp
    • Tôi không chắc đây có phải vấn đề sâu như mọi người nghĩ hay không. SQL injection cũng nguy hiểm y hệt, vì nó mở quyền truy cập không giới hạn vào mọi thao tác cơ sở dữ liệu mà người dùng truy vấn có thể thực hiện
      Một biện pháp giảm thiểu là prepared statement, nhưng một biện pháp khác là không cho bất kỳ người dùng nào truy cập toàn bộ cơ sở dữ liệu. Người dùng chỉ đọc thì không được phép DROP TABLE, bất kể có SQL injection hay không
      Tác nhân này có quyền đọc không giới hạn và không có khái niệm “người nhận” của câu trả lời. Nếu đưa quyền của người nhận vào, việc tự động từ chối quyền đọc sẽ khá đơn giản. Đó không phải giải pháp duy nhất, nhưng không khó để nghĩ ra hướng giải quyết như vậy
      Ví dụ “menu” cũng có nghĩa là chẳng có gì thay đổi. Dù là LLM hay nhân viên con người, thứ được phép vẫn chỉ là một tập hành động cố định có kiểm soát. Độ tự do chủ yếu nằm ở cách diễn đạt, còn cấp quyền là tập cố định. Tôi không hiểu vì sao nó phải vượt quá menu

  • Tôi không hiểu tại sao đây lại là lỗ hổng của GitHub. Các nhà nghiên cứu đã cấp cho agent quyền truy cập kho riêng tư, rồi để nó trả lời câu hỏi trong kho công khai, nên đương nhiên có thể trích xuất thông tin riêng tư
    Nó giống như tạo một tác vụ CI thông thường có quyền truy cập vào giá trị bí mật rồi chạy tác vụ đó từ PR công khai. Nếu bạn cấu hình GitHub để mã công khai hoặc chỉ dẫn LLM được chạy trong ngữ cảnh có thể truy cập dữ liệu nhạy cảm, thì dữ liệu sẽ bị rò rỉ. Đó không phải lỗi của GitHub, mà là lỗi của người cấu hình

    • Có vẻ họ đã giả định quyền chỉ bị giới hạn ở kho đang được hỏi hiện tại, không bao gồm cả kho riêng tư. Tôi hiểu được lập luận của cả hai phía
    • GitHub không thật sự giúp việc cấu hình quyền truy cập của agent trở nên an toàn một cách dễ dàng. Token truy cập thông thường và thông tin xác thực của app không có đủ kiểm soát chi tiết để cho truy cập trực tiếp vào kho riêng tư
      Dù siết chặt phạm vi token, quyền truy cập kho công khai vẫn luôn được cho phép, và chẳng hạn vẫn còn đường rò rỉ qua issue trong kho công khai. Muốn an toàn thì phải bổ sung bằng một proxy MITM triển khai kiểm soát nghiêm ngặt hơn những gì GitHub cung cấp
      GitHub Agentic workflows lẽ ra là giải pháp chính thức tuyến đầu cho vấn đề này, nhưng có vẻ vẫn còn nhiều việc phải làm, cả về mô hình bảo mật lẫn khả năng sử dụng an toàn
      Chi tiết: https://haulos.com/blog/do-not-give-your-agent-github-access...
    • Cốt lõi của những cuộc tấn công prompt injection kiểu này là vấn đề không giới hạn đúng phạm vi quyền của agent. Trong trường hợp này, tùy theo việc agent thực sự cần làm, có thể đặt agent workflow riêng cho từng kho, hoặc có một agent với quyền truy cập kho rộng hơn nhưng chỉ cho phép người dùng trong danh sách cho phép kích hoạt
      Cách này vẫn tương thích với phát triển công khai, vẫn cho phép người ngoài mở issue công khai, đồng thời phản ánh mức độ tin cậy dành cho từng người dùng. Nếu suy nghĩ kỹ, hẳn còn nhiều lựa chọn hơn
      Để làm vậy cần hỗ trợ kỹ thuật cho việc chỉ định phạm vi và quyền ở mức tinh vi, đồng thời phải dành thời gian cân nhắc xem muốn đạt được gì với agent và quyền/tính năng tối thiểu cần thiết là gì
      Điều đầu tiên có vẻ sẽ đến. Việc dùng agent hiện vẫn là thời kỳ miền Tây hoang dã. Sẽ rất thú vị xem những abstraction nào sẽ giảm ma sát khi con người thiết kế agent, tìm và định nghĩa phạm vi/quyền; và interface nào sẽ cân bằng giữa độ chi tiết và tính dễ dùng khi hạn chế năng lực của agent
      Điều thứ hai luôn là trở ngại cốt lõi ngăn cản việc xây dựng phần mềm chất lượng cao. Việc dành thời gian suy nghĩ và triển khai đúng đi ngược trực diện với kiểu “di chuyển nhanh và phá vỡ mọi thứ”, ném agent vào mọi nơi
    • Có cách nào tách quyền truy cập theo từng agentic workflow, để một cái truy cập dữ liệu nhạy cảm còn cái khác chỉ truy cập dữ liệu công khai không? Mặc định có giới hạn phạm vi chỉ trong kho hiện tại không? GitHub có cảnh báo phù hợp về rủi ro khi kết hợp quyền truy cập dữ liệu kho riêng tư với agentic workflow không?
      Nếu câu trả lời cho bất kỳ câu hỏi nào trong số này là “không”, thì đó là vấn đề. GitHub Workflows cổ điển cũng có rất nhiều chuyện leo thang đặc quyền thông qua workflow kích hoạt bởi PR, nhưng đó là chủ đề riêng
    • Nhìn từ góc độ quyền hạn, LLM chỉ là một terminal ngu ngốc. Điều bạn muốn trông giống như tạo quyền tổng hợp tức thời dựa trên prompt, nhưng đây không phải là giải pháp kiểu “câu chuẩn bị sẵn”, mà gần với “tôi sẽ làm sạch câu SQL của người dùng bằng regex” hơn. Ta đều biết kết cục của chuyện đó
      Giải pháp thật sự là làm UI kiểm soát quyền theo từng prompt tốt hơn. Cần có thể dễ dàng bật/tắt tùy chọn “bao gồm kho riêng tư của tôi” giống như chọn “có tìm kiếm web hay không”

  • Thật buồn cười khi các nhà nghiên cứu vượt qua guardrail mà GitHub khoe khoang chỉ bằng một từ như “Additionally”. Điều đó cho thấy nỗ lực dựng ranh giới bảo mật mạnh bên trong cửa sổ ngữ cảnh của LLM chắc chắn sẽ thất bại
    Về bản chất, mô hình được tạo ra để làm theo chỉ dẫn, nên nếu trộn quy tắc hệ thống với đầu vào người dùng, chỉ dẫn mới hơn hoặc dai dẳng hơn sẽ thắng

  • Tại sao phần “công bố có trách nhiệm” lại không nói khi nào đã được sửa, hay GitHub đã thừa nhận hay bác bỏ? Họ nói GitLost đã được công bố có trách nhiệm cho GitHub và chia sẻ chi tiết trong khi GitHub đã biết, vậy là vẫn chưa sửa à?

    • Đây không phải lỗi phần mềm thông thường, và cũng không thể “sửa” theo cùng cách như không thể “sửa” chuyện nhân viên hỗ trợ thông thường bị lừa. Câu trả lời là không cho LLM truy cập đồng thời đầu vào không đáng tin cậy và dữ liệu nhạy cảm
    • Tôi tò mò không biết tác giả bài gốc có thử nghiệm khi bật cấu hình dưới đây không. Có một thiết lập đúng nghĩa để chặn chuyện này. Tôi muốn biết đây là thiết lập được tạo ra do báo cáo này, hay là sự bất cẩn của người báo cáo khi không nhắc tới nó
      https://github.github.com/gh-aw/reference/cross-repository/#...
    • Sửa cái gì? Chỉ là đã cấp cho LLM cả quyền truy cập dữ liệu riêng tư lẫn khả năng đọc bình luận công khai. Đơn giản là cấu hình sai

  • Các tập đoàn lớn như Microsoft đang gắn AI vào mọi sản phẩm để tuyên bố rằng giờ họ là công ty AI, do áp lực từ nhà đầu tư. Tương tự những gì Adobe đã làm
    Người tiêu dùng đang mệt mỏi với những tích hợp AI nửa vời kiểu này, và có vẻ sắp đến điểm giới hạn

    • Tôi thì xong rồi. Đã chuyển sang Forgejo. Tuyệt vời, và mọi thứ hoạt động tốt hơn
      Nói nghiêm túc, mọi thứ phản hồi tức thì khi bấm chỗ này chỗ kia, CI gắn runner cũng chạy đẹp. Tài liệu thiết lập runner có thể rõ hơn một chút, nhưng ngoài ra mọi thứ đều quá mượt
    • Microsoft là công ty đại chúng. Nhà đầu tư nào đang gây áp lực để họ phá GitHub bằng các tính năng AI không ai muốn? Việc đó diễn ra ở cuộc họp nào?
    • Tôi đồng ý, nhưng tôi thấy các sản phẩm AI cho doanh nghiệp khá ấn tượng. Nhà đầu tư và người tiêu dùng thì không biết rõ, còn nhân viên thì không thể giao dịch
      Doanh thu là có thật và ấn tượng, đang thay thế doanh thu từ người tiêu dùng/theo chỗ ngồi. Thị trường vẫn đang hạ bội số SaaS, và tôi nghĩ đánh giá đó là đúng. Nếu tách riêng doanh thu trong báo cáo quý, có một câu chuyện tăng trưởng lớn đến từ hiệu quả thực tế

  • Tôi không hiểu vì sao một action chạy trong ngữ cảnh kho công khai lại có quyền truy cập kho riêng tư. Nhìn workflow thì có vẻ nó dùng github token, thứ thường không được cấp quyền vào kho riêng tư
    Hay bản thân agent somehow có quyền cao hơn? Nếu vậy thì là cấu hình agent sai. Chúng ta đã biết không nên tin rằng agent sẽ cưỡng chế điều gì đó

  • Bài này đọc giống marketing của Noma. Có tên dễ thương, logo, tiêu đề câu view, và cả giọng điệu kịch tính như nhắm tới độc giả không chuyên kỹ thuật
    Nếu hỏi lỗ hổng thực sự là gì, thì đó là: đưa dữ liệu riêng tư cho LLM rồi để bất kỳ ai tương tác với nó thì dữ liệu có thể bị rò rỉ. Quá hiển nhiên

  • Những người như vậy rồi sẽ cấp cho LLM quyền ghi toàn bộ ổ đĩa và phàn nàn rằng nó đã thực hiện thao tác phá hoại
    Nếu muốn AI agent không đọc kho riêng tư thì chỉ cần không cấp quyền truy cập kho riêng tư cho nó. Đây không phải vấn đề vượt quyền, mà là vấn đề prompt injection, và không thể giải quyết một cách đáng tin cậy ở tầng agent

  • Hoặc đây là vấn đề đã được giải quyết rồi, hoặc GitHub vẫn chưa giải quyết được và trong thời gian đó các tác nhân độc hại sẽ thử khai thác lỗ hổng trên các kho
    Vì số lượng kho rất lớn nên xác suất rò rỉ khác 0 có thể xảy ra. Tuy nhiên, giống như nạn nhân lừa đảo, gần như sẽ chẳng ai thừa nhận mình bị rò rỉ