การรั่วไหลของข้อมูลใน Slack AI ผ่านการฉีดพรอมป์ทางอ้อม

 (substack.com/promptarmor)
1 คะแนน โดย GN⁺ 2024-08-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Slack AI อาจทำตาม การฉีดพรอมป์ทางอ้อม ระหว่างกระบวนการค้นหาข้อความในเวิร์กสเปซด้วยคำถามภาษาธรรมชาติ ทำให้ผู้โจมตีอาจดึงข้อมูลจากช่องส่วนตัวที่ตนไม่มีสิทธิ์เข้าถึงได้
  • แก่นของปัญหาคือ LLM ไม่สามารถแยกความแตกต่างระหว่าง system prompt ของนักพัฒนา กับคำสั่งที่อยู่ในข้อความซึ่งแนบมากับผลการค้นหาได้อย่างน่าเชื่อถือ
  • ข้อความในช่องสาธารณะสามารถถูกค้นหาและดูได้แม้ผู้ใช้จะไม่ได้เข้าร่วมช่องนั้น ผู้โจมตีจึงสามารถฝังคำสั่งอันตรายในช่องสาธารณะที่มีเพียงตนเอง แล้วทำให้คำสั่งนั้นเข้าไปอยู่ใน context window ของ Slack AI ได้
  • ในการสาธิต API key ของช่องส่วนตัวถูกใส่เข้าไปในพารามิเตอร์ HTTP ของลิงก์ Markdown ในคำตอบของ Slack AI และการอ้างอิงแหล่งที่มาไม่ได้ชี้ไปยังช่องของผู้โจมตี ทำให้ ติดตามได้ยาก
  • ตั้งแต่วันที่ 14 สิงหาคม 2024 Slack AI เริ่มรวมไฟล์จากช่องและ DM ไว้ในคำตอบด้วย ทำให้พื้นผิวการโจมตีกว้างขึ้น และผู้ดูแลระบบสามารถจำกัด การตั้งค่าการเก็บรวบรวมไฟล์ ได้

ปัญหาการฉีดพรอมป์ทางอ้อมของ Slack AI

  • Slack AI เป็นฟีเจอร์ที่ให้ค้นหาข้อความ Slack ด้วยภาษาธรรมชาติได้ และก่อนวันที่ 14 สิงหาคม 2024 จะเก็บรวบรวมเฉพาะข้อความเท่านั้น
  • ตั้งแต่วันที่ 14 สิงหาคม 2024 เอกสารที่อัปโหลดและไฟล์ Google Drive เป็นต้น จะถูกรวมไว้ในคำตอบของ Slack AI ด้วย การเปลี่ยนแปลงนี้ทำให้ พื้นผิวการโจมตี กว้างขึ้น
  • ช่องโหว่นี้คือ prompt injection และหากระบุให้ชัดเจนยิ่งขึ้นคือ การฉีดพรอมป์ทางอ้อม
  • LLM อาจไม่สามารถแยกความแตกต่างระหว่าง system prompt ที่นักพัฒนาสร้างขึ้น กับบริบทอื่นที่แนบมากับคำถามของผู้ใช้ได้
    • หาก Slack AI เก็บรวบรวมคำสั่งในข้อความ เมื่อคำสั่งนั้นเป็นอันตราย ก็มีความเป็นไปได้ที่จะทำตามคำสั่งของผู้โจมตีแทนคำถามของผู้ใช้ หรือทำควบคู่ไปกับคำถามของผู้ใช้
  • ภัยคุกคามจากคนใน Slack เคยเป็นปัญหามาแล้วจากกรณีข้อมูล Slack รั่วของ Disney, Uber, EA, Twitter และอื่น ๆ และช่องโหว่นี้ทำให้ผู้โจมตีสามารถพยายามทำให้ข้อมูลรั่วไหลได้ แม้จะไม่ได้เข้าถึงช่องส่วนตัวหรือข้อมูลในนั้นโดยตรง

ห่วงโซ่การรั่วไหลของข้อมูลผ่านการฉีดในช่องสาธารณะ

  • คำถามของผู้ใช้ใน Slack AI สามารถค้นหาข้อมูลจากทั้งช่องสาธารณะและช่องส่วนตัวพร้อมกันได้
  • จากคำตอบของ Slack ข้อความที่โพสต์ในช่องสาธารณะสามารถถูกสมาชิกทุกคนในเวิร์กสเปซค้นหาและดูได้ แม้ผู้ใช้จะไม่ได้เข้าร่วมช่องนั้น และนี่เป็นพฤติกรรมที่ตั้งใจไว้ในแอปพลิเคชัน Slack AI
  • ลำดับการโจมตีที่สาธิตมีดังนี้
    • ผู้ใช้ใส่ API key ไว้ในช่องส่วนตัวที่มีเพียงตนเอง หรือในข้อความถึงตัวเอง
    • ผู้โจมตีสร้างช่องสาธารณะที่มีเพียงตนเองและโพสต์คำสั่งอันตราย
    • เมื่อผู้ใช้ถาม Slack AI เกี่ยวกับ API key ข้อความของผู้ใช้และข้อความของผู้โจมตีจะเข้าไปอยู่ใน context window เดียวกัน
    • Slack AI ทำตามคำสั่งของผู้โจมตีและสร้างลิงก์ Markdown ที่มีข้อความ “click here to reauthenticate”
    • พารามิเตอร์ HTTP ของลิงก์มี API key ส่วนตัวอยู่ และเมื่อผู้ใช้คลิก ผู้โจมตีซึ่งเป็นเจ้าของ URL อันตรายจะตรวจสอบค่าได้จาก log
  • ช่องสาธารณะของผู้โจมตีถือเป็นช่องสาธารณะแม้จะมีสมาชิกเพียงคนเดียวคือผู้โจมตี และผู้ใช้รายอื่นจะเห็นได้ก็ต่อเมื่อค้นหาโดยตรง
  • ในองค์กรขนาดใหญ่ การมีช่องสาธารณะกระจัดกระจายจำนวนมาก ทำให้สมาชิกทีมติดตามได้ยากแม้กระทั่งช่องที่ตนอยู่ และช่องสาธารณะแบบคนเดียวที่ผู้โจมตีสร้างขึ้นยิ่งสังเกตเห็นได้ยากกว่า
  • การโจมตีนี้ไม่ใช่การส่งข้อความหา用户ให้ “ส่ง API key มา” แบบง่าย ๆ แต่เป็นการสั่ง LLM ให้ทำงานต่อไปนี้
    • เพิ่ม API key ที่ผู้โจมตีเข้าถึงไม่ได้เป็นพารามิเตอร์ HTTP ของลิงก์อันตราย
    • เรนเดอร์เป็นลิงก์ Markdown ที่มีข้อความ “click here to reauthenticate”

การอ้างอิงแหล่งที่มาอาจปกปิดร่องรอยการโจมตีได้

  • ในการสาธิตการรั่วไหลของข้อมูล การอ้างอิงแหล่งที่มา [1] ของ Slack AI ชี้ไปเฉพาะช่องส่วนตัวที่ผู้ใช้ใส่ API key ไว้ ไม่ใช่ช่องของผู้โจมตี
  • หากการอ้างอิงแหล่งที่มาทำงานอย่างถูกต้อง ควรอ้างอิงทุกข้อความที่มีส่วนต่อคำตอบ แต่ในการสาธิต ข้อความของผู้โจมตีไม่ได้ถูกรวมอยู่ในแหล่งที่มา
  • ข้อความของผู้โจมตีไม่ปรากฏในหน้าแรกของผลการค้นหาด้วย ทำให้เหยื่อสังเกตเห็นข้อความดังกล่าวได้ยากหากไม่เลื่อนดูหลายหน้า
  • ผลการค้นหายังเปิดเผยข้อความอื่น ๆ ที่เกี่ยวข้องกับ API key ด้วย แสดงให้เห็นว่าผู้โจมตีสามารถพยายามทำให้ ความลับใด ๆ รั่วไหลได้ แม้จะไม่ได้ระบุค่าความลับเฉพาะเจาะจงอย่างแม่นยำ

ห่วงโซ่ฟิชชิงผ่านการฉีดในช่องสาธารณะ

  • ด้วยวิธีเดียวกัน Slack AI สามารถถูกทำให้เรนเดอร์ ลิงก์ฟิชชิง ให้ผู้ใช้ในรูปแบบ Markdown แทนการทำข้อมูลรั่วไหลได้
  • ผู้โจมตีใส่ข้อความอันตรายลงในช่องสาธารณะที่ผู้ใช้ไม่ได้อยู่ และยกสถานการณ์การสรุปข้อความประจำวันของผู้ใช้รายหนึ่งเป็นตัวอย่าง
  • ข้อความอันตรายสามารถอ้างถึงบุคคลใดก็ได้
    • หากอ้างถึงผู้ดูแลระบบเหมือนในตัวอย่าง ก็สามารถนำไปใช้กับ spear phishing ที่มุ่งเป้าไปยังผู้บริหารได้
    • นอกจากนี้ยังสามารถอ้างถึงผู้รายงานโดยตรงคนสำคัญได้เช่นกัน
  • เมื่อผู้ใช้ถาม Slack AI เกี่ยวกับข้อความของบุคคลนั้น ลิงก์ฟิชชิง “click here to reauthenticate” จะถูกเรนเดอร์ออกมา
  • ในกรณีฟิชชิงนี้ Slack AI แสดงข้อความที่ถูกฉีดไว้ในแหล่งที่มา และพฤติกรรมการอ้างอิงแหล่งที่มาดูมีลักษณะ ขึ้นกับความน่าจะเป็น ค่อนข้างมาก

การเปลี่ยนแปลงการเก็บรวบรวมไฟล์วันที่ 14 สิงหาคม และความจำเป็นในการเปิดเผย

  • วันที่ 14 สิงหาคม 2024 Slack AI ได้นำการเปลี่ยนแปลงที่รวมไฟล์จากช่องและ DM ไว้ในคำตอบของ Slack AI มาใช้
  • Slack เปิดให้เจ้าของและผู้ดูแลระบบจำกัดฟีเจอร์นี้ได้
  • เมื่อมีการรวมไฟล์ ผู้โจมตีอาจไม่จำเป็นต้องโพสต์คำสั่งอันตรายลงในข้อความ Slack โดยตรง
    • หากผู้ใช้ดาวน์โหลด PDF ที่มีคำสั่งอันตรายซ่อนอยู่ด้วยข้อความสีขาว แล้วอัปโหลดขึ้น Slack ก็อาจเกิดผลลัพธ์ต่อเนื่องแบบเดียวกันได้
  • การโจมตีที่อาศัยไฟล์ไม่ได้ถูกทดสอบยืนยันอย่างชัดเจนในการทดสอบก่อนวันที่ 14 สิงหาคม แต่จากฟังก์ชันที่เคยสังเกตพบก่อนหน้านี้ ถือว่ามีความเป็นไปได้สูง
  • ผู้ดูแลระบบสามารถจำกัดฟีเจอร์การเก็บรวบรวมเอกสารของ Slack AI ได้จนกว่าปัญหาจะได้รับการแก้ไข: https://slack.com/help/articles/…

ไทม์ไลน์การเปิดเผยอย่างรับผิดชอบและคำตอบของ Slack

  • ไทม์ไลน์การเปิดเผยอย่างรับผิดชอบมีดังนี้
    • 14 สิงหาคม: รายงานครั้งแรก
    • 15 สิงหาคม: Slack ขอข้อมูลเพิ่มเติม
    • 15 สิงหาคม: PromptArmor ส่งวิดีโอและภาพหน้าจอเพิ่มเติม และแจ้งความตั้งใจที่จะเปิดเผยเนื่องจากความร้ายแรงของประเด็นและการเปลี่ยนแปลงของ Slack AI เมื่อวันที่ 14 สิงหาคม
    • 16 สิงหาคม: Slack ส่งคำถามเพิ่มเติม
    • 16 สิงหาคม: PromptArmor ส่งคำตอบเพื่อชี้แจง
    • 19 สิงหาคม: Slack ระบุว่าจากผลการตรวจสอบ หลักฐานยังไม่เพียงพอ และตอบว่าข้อความในช่องสาธารณะเป็นพฤติกรรมที่ตั้งใจไว้ ซึ่งสมาชิกเวิร์กสเปซสามารถค้นหาและดูได้โดยไม่ขึ้นกับว่าตนเข้าร่วมช่องนั้นหรือไม่
  • ทีมความปลอดภัยของ Slack ตอบสนองอย่างรวดเร็วและแสดงให้เห็นว่าพยายามทำความเข้าใจปัญหา
  • Prompt injection เป็นพื้นที่ใหม่และมีความเข้าใจผิดมากในวงการโดยรวม ดังนั้นอาจต้องใช้เวลาที่อุตสาหกรรมจะทำความเข้าใจร่วมกัน
  • เมื่อพิจารณาจากการใช้งาน Slack อย่างแพร่หลายและปริมาณข้อมูลลับภายใน Slack การโจมตีนี้ส่งผลอย่างมีนัยสำคัญต่อสถานะความปลอดภัยของ AI
  • โดยเฉพาะหลังการเปลี่ยนแปลงวันที่ 14 สิงหาคม พื้นผิวความเสี่ยงเพิ่มขึ้นอย่างมาก จึงจำเป็นต้องเปิดเผยเพื่อให้ผู้ใช้สามารถลดการเปิดเผยข้อมูลได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-21
ความคิดเห็นใน Hacker News

  • ประเด็นสำคัญตรงนี้คือการเข้าใจ เส้นทางการรั่วไหล
    Slack สามารถเรนเดอร์ลิงก์ Markdown ได้ และ URL จะถูกซ่อนไว้หลังข้อความลิงก์
    ในกรณีนี้ ผู้โจมตีทำให้ Slack AI แสดงลิงก์อย่าง “คลิกที่นี่เพื่อยืนยันตัวตนอีกครั้ง” ให้ผู้ใช้เห็น โดย URL ของลิงก์นั้นชี้ไปยังเซิร์ฟเวอร์ของผู้โจมตี และใส่ข้อมูลส่วนตัวที่อยู่ในบริบทที่ Slack AI เข้าถึงได้ไว้ใน query string
    หากผู้ใช้หลงเชื่อและคลิกลิงก์ ข้อมูลก็จะรั่วไปยังล็อกของเซิร์ฟเวอร์ผู้โจมตี
    มีบทความที่อธิบายการโจมตีนี้อยู่ที่นี่: https://simonwillison.net/2024/Aug/20/data-exfiltration-from...

    • สำหรับบอตอย่าง Slack, Discord, Teams, Telegram จริง ๆ แล้วยังมีเส้นทางรั่วไหลอีกแบบคือ การคลี่พรีวิวลิงก์
      ผู้โจมตีแค่ทำให้มีการเรนเดอร์ไฮเปอร์ลิงก์ก็พอ ไม่จำเป็นต้องมีการคลิกด้วยซ้ำ
      ประเด็นนี้และวิธีบรรเทาถูกพูดถึงไว้ที่นี่: https://embracethered.com/blog/posts/2024/the-dangers-of-unf...
      ดังนั้นหวังว่า Slack AI จะไม่คลี่ลิงก์โดยอัตโนมัติ
    • ถ้าแพลตฟอร์มเรนเดอร์แท็ก img หรือสิ่งที่เทียบเท่าแบบไม่คิดหน้าคิดหลัง จะยิ่งแย่ลงไปอีก
      เพราะจะทำให้ ข้อมูลรั่วไหล ได้เพียงแค่แสดงรูปภาพใน UI โดยไม่ต้องให้ผู้ใช้มีปฏิสัมพันธ์ใด ๆ
    • แก่นที่ควรเข้าใจจริง ๆ คือแม้ข้อมูลผู้ใช้จะถูกขโมยไป ก็แทบไม่มี ความรับผิดชอบต่อผลลัพธ์ที่มีความหมาย เลย
      ตอนนี้บริษัทเทคโนโลยีรายใหญ่ทั้งหมดมีใบอนุญาตพ้นผิดโดยพฤตินัย ต่อให้ทำพังก็แทบแตะต้องไม่ได้
    • ส่วนที่ตอนแรกใช้เวลาทำความเข้าใจคือ เมื่อผู้ใช้ค้นหาใน Slack หรือให้ AI ค้นหาแทน ขอบเขตการค้นหาคือ ทุกช่องสาธารณะ และ “ช่องส่วนตัวที่มีเฉพาะผู้ใช้นั้นเข้าถึงได้”
      โมเดลสิทธิ์ไม่ได้เปลี่ยน และสิ่งที่พังไม่ใช่ตรงนั้น
      สิ่งที่เกิดขึ้นจริงคือผู้ใช้ประสงค์ร้ายใช้ช่องสาธารณะเพื่อทำ prompt injection และเมื่อผู้ใช้อีกคนค้นหา ผู้ใช้ประสงค์ร้ายก็ยังเข้าถึงข้อมูลนั้นไม่ได้ แต่ prompt injection จะเปลี่ยนผลลัพธ์ AI ที่ผู้ใช้ “ปกติ” เดิมควรเห็นให้กลายเป็นลิงก์ไปยังเว็บไซต์อันตราย
      สุดท้ายมันใกล้เคียงกับความพยายามฟิชชิงที่ AI สร้างขึ้น
      ถ้าดูรายละเอียดแล้ว ดูเหมือนจะนำไปใช้โจมตีจริงได้ค่อนข้างยาก เพราะ prompt injection อันตรายที่เตรียมไว้ล่วงหน้าต้องเข้ากันได้ค่อนข้างดีกับสิ่งที่ผู้ใช้ปกติจะค้นหา
      ถึงอย่างนั้น มันก็แสดงให้เห็นโลกแบบ อลิซในแดนมหัศจรรย์ ของ LLM prompt injection ได้ดี นั่นคือการแยกคำสั่งกับข้อมูลออกจากกันนั้นโดยเนื้อแท้แทบเป็นไปไม่ได้
    • ถ้าอ่านแค่ถ้อยคำตอนต้น จะฟังเหมือนผู้โจมตีสามารถหลอก AI ให้เปิดเผยข้อมูลช่องส่วนตัวของผู้ใช้อื่นได้ แต่จริง ๆ ไม่ใช่แบบนั้น
      แต่เป็นการหลอก AI ให้ไป ฟิชชิง ผู้ใช้อื่น และถ้าผู้ใช้นั้นหลงเชื่อฟิชชิง ก็จะเปิดเผยข้อมูลส่วนตัวให้ผู้โจมตี
      นี่ก็ไม่เชิงเป็นฟิชชิงเชิงรุก แต่ใกล้กับ “คำตอบฟิชชิง” มากกว่า ต้องคาดหวังให้ผู้ใช้เป้าหมายถามถึงข้อมูลส่วนตัวของตนเอง และยังต้องหลงเชื่อความพยายามฟิชชิงด้วย
      แถมข้อมูลลับนั้นต้องถูกป้อนไว้ก่อนหน้านี้แล้ว
      เมื่อคิดถึงปริมาณข้อมูลความไว้วางใจที่ Slack มี กลยุทธ์ AI ดูค่อนข้างบ้าบิ่น แต่เงื่อนไขที่จะทำให้เกิดขึ้นได้นั้นดูอ่อนกว่าที่รู้สึกจากบทนำและพาดหัวมาก

  • เรื่องสิทธิ์ของช่องดูเหมือนจะทำให้การถกเถียงซับซ้อนเกินจำเป็น ใจความคือแบบนี้
    ผู้ใช้ A ค้นหาอะไรบางอย่างด้วย Slack AI
    ผู้ใช้ B เคยฝังข้อความไว้ก่อนหน้าเพื่อสั่ง AI ว่าถ้าเจอคำค้นหานั้นให้ส่งลิงก์อันตรายกลับไป
    AI ส่งลิงก์อันตรายให้ผู้ใช้ A และ A คลิกลิงก์นั้น
    แน่นอนว่าอาจได้ผลแบบเดียวกันผ่านเส้นทางวิศวกรรมสังคมอื่น ๆ แต่ LLM ทำให้ประสบการณ์ทั้งหมดนี้ อันตรายขึ้นอีกระดับ

    • สรุปนี้ขาดขั้นตอนสำคัญไป Slack AI แนบ ข้อมูลส่วนตัว ของผู้ใช้เข้าไปกับลิงก์อันตราย
      เพราะตัวลิงก์ที่ถูกฝังไว้ไม่ได้มีข้อมูลนั้นอยู่
      แถมยังแนบแหล่งที่มาว่า “เนื้อหานี้มาจากข้อความ Slack ของคุณ” ให้อีกต่างหาก
    • เรื่องสิทธิ์ของช่องไม่ได้ไม่จำเป็นเลย เพราะมันอธิบายแก่นสำคัญว่าช่องโหว่นี้ทำงานอย่างไร
      เมื่อผู้ใช้ A ค้นหาด้วย AI Slack จะค้นหา (1) ช่องส่วนตัวของเขา ซึ่งอาจมีข้อมูลลับที่อ่อนไหว และ (2) ช่องสาธารณะทั้งหมด
      ตรงนี้สถานที่ที่ผู้ใช้ไม่ดี B สามารถใส่ข้อความ prompt injection ได้คือช่องสาธารณะ และจุดสำคัญคือรวมถึงช่องสาธารณะที่ผู้ใช้ A ไม่เคยเข้าร่วมหรือเคยเห็นเลยด้วย
      เหตุผลที่ช่องโหว่นี้เกิดขึ้นได้คือผู้ใช้ B สามารถสร้างช่องสาธารณะที่มีแต่ตัวเองอยู่ได้ ทำให้โอกาสที่คนอื่นจะพบเห็นต่ำมาก
    • วิศวกรรมสังคมอย่างไรก็ยังสังเกตได้ง่ายกว่าการที่เสิร์ชเอนจินที่บริษัทอนุมัติแสดง ลิงก์อันตราย มาก

  • บริษัทต่าง ๆ รู้อยู่แล้วว่าการแทรก prompt ทำได้ แต่ก็ยังเสียบ LLM เข้าไปกับทุกอย่างแบบ YOLO อย่างนั้นหรือ? นี่มันบ้าชัด ๆ
    ผ่านมาเกือบ 2 ปีแล้วนับตั้งแต่ GPT-3 ทั้งที่บอกว่าอยู่ก่อนหน้า “การปฏิวัติ” แต่ก็ยังทำให้ LLM แยก อินพุตที่เชื่อถือได้กับอินพุตที่ไม่น่าเชื่อถือ ไม่ได้

    • เรายังทำให้บริษัทต่าง ๆ ใส่ใจความปลอดภัยจริง ๆ ไม่ได้เลย แต่ตอนนี้ฝ่ายการตลาด/ฝ่ายขายทั่วโลกกำลังขายเรื่องนี้ให้ผู้บริหารว่า “ถ้าใช้สิ่งนี้ ก็ไล่ทุกคนออกได้”
      ถ้าขายการเอาส้อมเสียบปลั๊กไฟด้วยวิธีเดียวกัน โครงข่ายไฟฟ้าทั่วโลกคงล่มภายในคืนเดียว
      “AI”/LLM เป็น ส่วนผสมแห่งหายนะที่สมบูรณ์แบบ เพราะดูดีพอจะดึงดูดสายธุรกิจได้ ขณะเดียวกันก็สร้างปัญหามหึมาให้ฝั่งเทคนิคจริง ๆ
    • ค่อนข้างแปลกที่คนจำนวนมากอยากเชื่อว่า “เวทมนตร์ใหม่สุดเจ๋งกำลังจะมาถึงในไม่ช้าไม่ทางใดก็ทางหนึ่ง” และทุกคนก็ยังทำเหมือนมันเป็นเรื่องแน่นอน ทั้งที่มีเงินจริง ๆ เป็นเดิมพัน
      ปัญหาที่พื้นฐานกว่านั้นคืออัลกอริทึมแกนกลางไม่ได้แยกแยะหรือติดตามแหล่งที่มาต่าง ๆ เลย
      prompt, อินพุตของผู้ใช้ ไปจนถึงเอาต์พุตที่มันสร้างขึ้นเองในช่วงก่อนหน้าของบทสนทนา ทั้งหมดเป็นเพียงกระแสข้อมูลก้อนใหญ่ก้อนเดียว
      “prompt engineering” ส่วนใหญ่ดูเหมือนเป็นการพยายามสร้างเวทีให้ข้อความแทรกของฉันมีพลังเหนือข้อความแทรกอื่น ๆ
      โมเดลไม่มีแนวคิดเรื่องตัวเอง/ผู้อื่นในทางปฏิบัติ จึงแทบไม่มีจุดตั้งต้นที่จะใช้แยกประโยคจริงออกจากประโยคเท็จด้วยซ้ำ ไม่ต้องพูดถึงปัญหาที่ใหญ่กว่านั้นอย่างการแยกผู้อื่นที่ดีกับผู้อื่นที่ไม่ดี
      นี่เป็นคนละปัญหากับการลอกเลียนแบบแบบผิวเผินสไตล์ “ห้องภาษาจีน” เช่นเดียวกัน เอาต์พุตว่า “ฉันรักคุณ” ไม่ได้หมายถึงอารมณ์ความรู้สึก และ “ช่วยด้วย ฉันเป็นมนุษย์ที่ติดอยู่ในโรงงาน LLM” ก็แน่นอนว่าไร้สาระ อย่างน้อยก็ถ้าคุณกำลังรันโมเดลในเครื่องอยู่
    • ทั้งบริษัทและรัฐบาลต่างกำลังแข่งกันส่งข้อมูลของตัวเองและข้อมูลของพวกเราไปยังศูนย์ข้อมูลของ AWS, OpenAI, MSFT, Google, Meta, Salesforce, nVidia
    • กระแส AI ตั้งอยู่บนการขโมยหรือใช้ข้อมูลในทางที่ผิดในระดับมหาศาล เพื่อปั้นตัวเลขให้ชนชั้นนักลงทุน
      ถ้ายัดข้อมูลลูกค้าและข้อมูลกรรมสิทธิ์เข้าไปจนเกิด data breach ตามที่ Schmidt ว่าไว้ มันจะทำเงินหลายแสนล้านดอลลาร์ให้คนส่วนน้อย และทนายก็จะมาจัดการเก็บกวาดทีหลัง
      บริษัทที่พยายามต้านทานจะถูกนักวิเคราะห์การลงทุนและผู้จัดการกองทุนที่การเงินผูกอยู่กับขยะ AI กลบฝังไป

  • “การโจมตีทำงานได้แม้เหยื่อไม่ได้อยู่ในช่องสาธารณะ” นี่น่าสนใจขึ้นมาแล้ว
    ยังมีส่วนที่ว่า “แหล่งที่มา [1] ไม่ได้ชี้ไปยังช่องของผู้โจมตี แต่ชี้เฉพาะช่องส่วนตัวที่ผู้ใช้ใส่ API key ไว้เท่านั้น ซึ่งละเมิดพฤติกรรมการอ้างอิงที่ถูกต้องที่ว่าทุกข้อความที่มีส่วนต่อคำตอบควรถูกอ้างถึง” ด้วย
    ผมไม่เข้าใจจริง ๆ ว่าทำไมใครถึงคาดหวังว่า การอ้างอิงแหล่งที่มา ของ LLM จะถูกต้อง
    มันดูเหมือนเป็นอุปกรณ์ไว้หลอกมนุษย์มากกว่าเสมอ และแค่ทำให้เชื่อว่าเอาต์พุตมีแนวโน้มถูกต้องมากขึ้น แต่ไม่ได้ช่วยเพิ่มความแม่นยำ
    กลับกันยังดูมีโอกาสทำให้ความแม่นยำของคำตอบแย่ลงด้วย เพราะเพิ่มต้นทุนการประมวลผล ขนาด context และอื่น ๆ
    นี่ดูห่างจากสถานการณ์ที่ Slack ใส่ link expansion เข้าไปในคำตอบ AI อย่างใจดีแค่ไม่กี่นิ้วเอง ทำไมจะไม่ทำล่ะ?
    ถ้าอย่างนั้นก็ไม่จำเป็นต้องคลิกลิงก์ด้วยซ้ำ แค่เห็นก็รั่วออกไปอัตโนมัติแล้ว

    • ผมมองว่าการอ้างอิงมีประโยชน์ เพราะช่วยตรวจได้ว่า LLM แค่ hallucinate ขึ้นมาหรือไม่
      ประเด็นสำคัญไม่ใช่เห็นการอ้างอิงแล้วเชื่อทันที แต่คือสามารถ ตรวจสอบข้อเท็จจริง ได้
      Kagi FastGPT เป็น LLM ตัวแรกที่ผมเคยใช้แล้วชอบ เพราะผมปฏิบัติต่อมันเหมือนสรุปแหล่งที่มา แล้วไปยืนยันจากแหล่งปฐมภูมิได้
      ดีกว่าการคุ้ยหาแหล่งที่มาที่เกี่ยวข้องน้อยลงเรื่อย ๆ ซึ่งกำลังทำให้อินเทอร์เน็ตปนเปื้อน
    • การทำให้การอ้างอิงของ LLM ทำงานถูกต้องเป็นไปได้ ตัวอย่างเช่น รับ prompt ของผู้ใช้แล้วให้ LLM แปลงเป็น Elastic Search query จากนั้นใช้ Elastic Search หรือเครื่องมือคล้ายกันค้นหาแหล่งที่มาที่มีคีย์เวิร์ด แล้วให้ LLM จำกัดคำตอบให้อยู่กับข้อมูลในหน้านั้น และแทรกการอ้างอิงโดยอิงผลลัพธ์ขั้นที่ 2 ที่รู้ว่าเป็นแหล่งที่มาจริง
      อย่างน้อยถ้าผมออกแบบแบบซื่อ ๆ ก็คงทำประมาณนี้
      แก่นสำคัญคือการจำกัดความรู้ของ LLM ให้อยู่กับข้อมูลในแหล่งที่มา
      จากนั้นข้อกังวลในทางปฏิบัติที่เหลือก็จะมีเรื่อง hallucination กับคุณค่าของข้อมูลที่ Elastic Search ดันขึ้นมา
      แต่แนวทางนี้ก็ละเลยข้อดี ถ้ามี ของการอนุญาตให้เข้าถึงคลังข้อความทั้งหมดอย่างอิสระ

  • ผมไม่ค่อยเข้าใจเรื่องนี้ แฮกเกอร์ต้องอยู่ในองค์กรนั้นตั้งแต่แรกถึงจะทำแบบนี้ได้ไม่ใช่หรือ?
    ผมไม่แน่ใจว่าเรื่องที่อธิบายไว้มีโอกาสเกิดขึ้นจริงและสร้างผลกระทบที่มีความหมายมากแค่ไหน
    ผมรู้ว่า LLM ไม่น่าเชื่อถือ (https://www.lycee.ai/blog/ai-reliability-challenge) และมีความยุ่งยากในการใช้งาน แต่การโจมตีนี้ดูไม่สำคัญนัก
    ผมพลาดอะไรไปหรือเปล่า?

    • เมื่อ Slack AI รวมเอกสารที่อัปโหลดเข้าไปในฟังก์ชันค้นหาแล้ว แฮกเกอร์ก็ไม่จำเป็นต้องโพสต์ข้อความแชตได้ด้วยซ้ำ
      แค่หลอกใครสักคนในองค์กรนั้นให้อัปโหลดเอกสารที่มี คำสั่งอันตราย ซ่อนอยู่ในข้อความแฝงก็พอ
    • ต้องอยู่ใน Slack workspace เดียวกัน แต่ไม่จำเป็นต้องสังกัดองค์กรเดียวกัน

  • ถ้าปล่อยผู้ใช้ประสงค์ร้ายเข้าไปใน Slack instance แล้ว ก็ไม่จำเป็นต้องใช้ prompt injection ของ AI ที่หวือหวาอะไรเลย
    แค่เปลี่ยนชื่อกับรูปโปรไฟล์ให้เหมือน CEO/CTO แล้วส่งข้อความถึงวิศวกรทุกคนว่า “ต้องเข้าถึง AWS ด่วน แต่หาข้อมูลรับรองไม่เจอ ส่ง key มาให้หน่อยได้ไหม?”
    ผมรับประกันได้ว่าอย่างน้อยหนึ่งคนต้องหลงกล

    • เป็นข้อสังเกตที่มีเหตุผล แต่ต้องคำนึงว่ามี Slack workspace จำนวนมากที่ไม่ใช่บัญชีบริษัท เช่น สำหรับโครงการโอเพนซอร์ส หรือกลุ่ม networking/เพื่อนร่วมวิชาชีพ
      ในกรณีแบบนั้น โดยพื้นฐานแล้วพวกเขาไม่ได้ไว้วางใจให้ผู้ใช้เหล่านั้นมีข้อมูลรับรองส่วนตัว
      แต่ก็จริงที่ workspace แบบ non-enterprise ก็มีโอกาสน้อยที่จะจ่ายเงินส่วนเสริม AI เดือนละ 20 ดอลลาร์ต่อคน

  • การใส่ API key เป็น ส่วนหนึ่งของชื่อโดเมน แบบ “เศษกระดาษสีโปรย” จะดีกว่าไหม?
    แบบนั้น key อาจรั่วไหลได้โดยไม่ต้องคลิก เพราะ DNS prefetching ของเบราว์เซอร์

    • ถ้าไม่รู้ล่วงหน้าว่าโดเมนจะเป็นอะไร แล้วจะเป็นเจ้าของเซิร์ฟเวอร์ได้อย่างไร? ผมอาจเข้าใจผิดก็ได้
      อ้อ wildcard subdomain สินะ? ถ้า Slack prefetch สิ่งนั้นจริง ๆ ก็ค่อนข้างน่ากลัว

  • ทันทีที่มีผู้ใช้ประสงค์ร้ายเข้ามาในเวิร์กสเปซ ก็ถือว่าจบแล้วไม่ใช่หรือ?
    ผู้ใช้คนนั้นสามารถเปลี่ยนรูป/ชื่อแล้วขอ API key โดยตรง ส่งลิงก์ฟิชชิง หรือพยายามทำ social engineering ได้เต็มที่เหมือนกับระบบส่งข้อความแบบทันทีใด ๆ

    • มี Slack สาธารณะของบริษัท SaaS อยู่มากมาย
      ฟิชชิงเป็นสิ่งที่ผู้ใช้ที่จริงจังน่าจะตรวจจับได้ โดยเฉพาะถ้าข้อความดูน่าสงสัย แต่การรั่วไหลผ่าน AI ทางอ้อมไม่ได้ทำให้ผู้ใช้เข้าสู่โหมดระวังตัว
      แค่เผลอคลิกครั้งเดียวก็เพียงพอแล้ว

  • ขอเริ่มด้วยการยอมรับว่าผมไม่ถนัดด้านความปลอดภัยนัก อย่างไรก็ตาม การรั่วไหลนี้ดูเหมือนต้องมีสิทธิ์เข้าถึงเวิร์กสเปซ Slack ก่อนจึงจะทำงานได้
    พูดอีกอย่างคือ ผู้ใช้ประสงค์ร้ายก็เคลื่อนไหวอยู่ข้างในอยู่แล้ว
    กรณีแบบนั้นดูจะเกิดได้สองแบบ คือเป็นสมาชิกขององค์กรอยู่แล้วแต่ต้องการเผาทุกอย่างให้พัง หรือไม่ก็เจาะโมเดลความปลอดภัยขององค์กรจนเข้ามาอยู่ในเวิร์กสเปซ Slack ที่เดิมไม่ควรอยู่ได้
    ไม่ว่าจะทางไหน องค์กรนั้นก็มีปัญหาใหญ่กว่า LLM injection แล้ว
    คนที่ query Slack เพื่อหาข้อมูลลับก็ควรยอมรับความเสี่ยงของผลลัพธ์ที่ตนหาในระดับหนึ่ง Slack ไม่ใช่ เครื่องมือจัดการความลับ
    บทความแสดงให้เห็นชัดว่า Slack สามารถจัดการเรื่องนี้ให้ดีขึ้นได้อย่างไร แต่ท้ายที่สุดก็เหมือนแพตช์ปัญหาหนึ่งไปพร้อมกับมองข้ามปัญหาความปลอดภัยที่ใหญ่กว่า

    • ผมเห็นองค์กรจำนวนไม่น้อยที่ให้บริการ community Slack ซึ่งเชิญคนที่ไม่ใช่พนักงานเข้ามาคุยกัน และผมเองก็อยู่ในที่แบบนั้นอยู่หลายแห่ง

  • รู้สึกว่าบทความไม่ได้แสดงเนื้อหาได้สมกับชื่อเรื่องนัก
    ถึงอย่างนั้น แนวคิดที่ว่า “ถ้าหลอก AI ด้วย social engineering ก็สามารถฟิชชิงผู้ใช้ได้” เองก็น่าสนใจ