Claude Cowork ทำให้ไฟล์ของผู้ใช้รั่วไหลออกไปภายนอก

 (promptarmor.com)
6 คะแนน โดย GN⁺ 2026-01-15 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใช้ประโยชน์จากช่องโหว่ในสภาพแวดล้อมรันโค้ดของ Claude Cowork ทำให้ผู้โจมตีสามารถ อัปโหลดไฟล์ของผู้ใช้ไปยังบัญชี Anthropic ของตนเอง ได้
  • ช่องโหว่นี้ เคยถูกรายงานแล้วในสภาพแวดล้อมแชตของ Claude.ai แต่ยังไม่ได้รับการแก้ไข และยังคงมีอยู่ใน Cowork เช่นเดิม
  • การโจมตีเกิดขึ้นผ่าน ไฟล์เอกสารที่มี prompt injection แบบซ่อนอยู่ และระหว่างที่ Cowork วิเคราะห์ไฟล์นั้น ก็จะส่งไฟล์ออกไปภายนอกโดยอัตโนมัติ
  • โดย ไม่มีการอนุมัติจากมนุษย์ Cowork ใช้ API key ของผู้โจมตีเพื่อ ทำข้อมูลรั่วไหลผ่าน Anthropic API
  • โครงสร้างนี้ทำให้ผู้ใช้ทั่วไปตกเป็นเป้าได้ง่าย และชี้ให้เห็นถึง ความเสี่ยงด้านความปลอดภัยของ AI agent และความสำคัญของการป้องกัน prompt injection

ภาพรวมของช่องโหว่

  • Claude Cowork คือ research preview ของ AI agent สำหรับงานทั่วไป ที่ Anthropic เปิดตัว และมีความสามารถในการเข้าถึงอินเทอร์เน็ต
  • PromptArmor สาธิตให้เห็นว่าสามารถทำให้ไฟล์ของผู้ใช้รั่วไหลออกไปภายนอกได้ โดยอาศัย ช่องโหว่ที่ยังไม่ได้รับการแก้ไขซึ่งคงอยู่ในสภาพแวดล้อมการเขียนโค้ดของ Cowork
    • ช่องโหว่นี้เคยถูก Johann Rehberger ค้นพบและเปิดเผยใน Claude.ai มาก่อน และ Anthropic รับทราบแล้วแต่ยังไม่แก้ไข
  • Anthropic เตือนว่าเมื่อใช้ Cowork ควร “ระวังพฤติกรรมที่อาจเข้าข่าย prompt injection” แต่ก็ถูกชี้ว่า เป็นข้อเรียกร้องที่แทบทำได้จริงยากสำหรับผู้ที่ไม่ใช่ผู้เชี่ยวชาญ
  • PromptArmor จัด การสาธิตแบบสาธารณะ เพื่อแจ้งเตือนผู้ใช้ถึงความเสี่ยงนี้

ห่วงโซ่การโจมตี (Attack Chain)

  • การโจมตีนี้อาศัยการใช้ allowlist ของ Anthropic API ในทางที่ผิด เพื่อส่งข้อมูลออกจากสภาพแวดล้อม VM ของ Claude ไปภายนอก
  1. ผู้ใช้ เชื่อมต่อโฟลเดอร์ภายในเครื่องที่มีไฟล์อสังหาริมทรัพย์ที่เป็นความลับเข้ากับ Cowork
  2. ผู้ใช้ อัปโหลดไฟล์เอกสาร (.docx) ที่มี prompt injection แบบซ่อนอยู่
    • เอกสารถูกปลอมเป็นไฟล์ ‘Skill’ และซ่อนอินเจกชันด้วย ตัวอักษรสีขาวขนาด 1 พอยต์ และระยะห่างบรรทัด 0.1
  3. ผู้ใช้ขอให้ Cowork วิเคราะห์ไฟล์ โดยใช้ ‘Skill’ ที่อัปโหลด
  4. อินเจกชันบังคับให้ Cowork รัน คำขอ cURL ที่ใช้ Anthropic API key ของผู้โจมตี เพื่ออัปโหลดไฟล์ของผู้ใช้ไปยังบัญชีของผู้โจมตี
    • ทำงานอัตโนมัติโดยไม่มีขั้นตอนอนุมัติจากมนุษย์
    • VM ของ Claude บล็อกเครือข่ายภายนอกส่วนใหญ่ แต่ Anthropic API ถูกอนุญาตให้ผ่านในฐานะปลายทางที่เชื่อถือได้
  5. ผู้โจมตีสามารถ ดูไฟล์ของเหยื่อและสนทนากับ Claude ได้จากบัญชี Anthropic ของตนเอง
    • ไฟล์ที่รั่วไหลมีทั้ง ข้อมูลทางการเงินและเลขประกันสังคม (SSN) บางส่วน

ความทนทานแยกตามโมเดล (Model-specific Resilience)

  • การโจมตีข้างต้นถูกสาธิตบนโมเดล Claude Haiku
  • Claude Opus 4.5 มีความทนทานต่ออินเจกชันสูงกว่า แต่ในสภาพแวดล้อม Cowork ก็ยังสามารถใช้ประโยชน์จาก ช่องโหว่การอัปโหลดไฟล์เดียวกันผ่าน indirect prompt injection ได้
    • ในการทดสอบ มีการสมมติสถานการณ์ที่ผู้ใช้อัปโหลดคู่มือการเชื่อมต่อที่เป็นอันตราย ทำให้ บันทึกลูกค้ารั่วไหลไปยังบัญชีของผู้โจมตี

การปฏิเสธการให้บริการผ่านไฟล์ที่มีรูปแบบผิด (DOS via Malformed Files)

  • API ของ Claude จะ เกิดข้อผิดพลาดซ้ำ ๆ เมื่อส่วนขยายไฟล์ไม่ตรงกับรูปแบบจริงของไฟล์
    • ตัวอย่าง: หากพยายามอ่านไฟล์ข้อความธรรมดาที่มีนามสกุล .pdf จะทำให้ทุกบทสนทนาหลังจากนั้นเกิด API error
  • ข้อผิดพลาดนี้สามารถถูกนำไปใช้เป็น การโจมตีแบบปฏิเสธการให้บริการ (DOS) ที่มีขอบเขตจำกัดผ่าน indirect prompt injection ได้
    • โดยชักจูงให้สร้างและอัปโหลดไฟล์ที่ผิดรูปแบบ เพื่อให้ เกิดการแจ้งเตือนข้อผิดพลาดทั้งใน Claude client และ Anthropic console

ความเสี่ยงจากการขยายขอบเขตของเอเจนต์ (Agentic Blast Radius)

  • Cowork ถูกออกแบบมาให้โต้ตอบกับสภาพแวดล้อมงานประจำวันอย่างกว้างขวาง เช่น เบราว์เซอร์, MCP server, การควบคุม AppleScript เป็นต้น
  • ด้วยเหตุนี้ ความเป็นไปได้ที่ ข้อมูลอ่อนไหวและข้อมูลที่ไม่น่าเชื่อถือจะถูกประมวลผลปะปนกัน จึงสูงขึ้น
  • พื้นที่โจมตีของ prompt injection กำลังขยายตัวอย่างต่อเนื่อง และ ควรระมัดระวังเมื่อตั้งค่า connector
  • แม้การสาธิตครั้งนี้จะไม่ได้ใช้ connector แต่ connector อาจกลายเป็นปัจจัยเสี่ยงหลักสำหรับผู้ใช้ทั่วไป

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

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

 
laeyoung 2026-01-15

ในบทความรีวิว Claude Coworkที่ Simon Willison เขียน ก็มีความกังวลเกี่ยวกับการโจมตีแบบ prompt injection อยู่แล้ว แต่มาเร็วจริง ๆ
 
GN⁺ 2026-01-15
ความคิดเห็นจาก Hacker News

  • ถ้าพบว่ามีการนำ Anthropic API ไปใช้ในทางที่ผิด ก็แค่อัปโหลด API key นั้นขึ้น GitHub Gist หรือรีโพสาธารณะ
    Anthropic เป็นพาร์ตเนอร์ด้านการสแกนของ GitHub ดังนั้นคีย์จะถูกเพิกถอนแทบจะทันที
    จากนั้นค่อยลบ Gist ทิ้งก็ได้ และผู้ให้บริการรายอื่นอย่าง OpenAI ก็ทำงานคล้ายกัน
    เอกสารที่เกี่ยวข้อง: Anthropic API Key Best Practices, GitHub Secret Scanning Patterns

    • ถ้าบริการ token scanning ของ GitHub ล่มก็จะเสี่ยง จึงไม่ค่อยแนะนำ
      ทางที่เหมาะกว่าคือ GitHub ควรมี API กลางสำหรับเพิกถอนโทเคน
      หรือไม่ก็เปิดใช้ฟังก์ชันเพิกถอนจากรีโพส่วนตัวได้โดยตรงจะดีกว่า
    • มันให้ความรู้สึกเหมือน เล่นหมากรุกกับแฮ็กเกอร์
    • ก็เพิกถอนคีย์จาก Anthropic console ตรง ๆ ได้อยู่แล้ว เลยสงสัยว่าทำไมต้องทำให้ซับซ้อนแบบนี้
    • คิดว่าเป็น วิธีแก้ที่แยบยลมาก ไม่เคยได้ยินวิธีนี้มาก่อน
    • แต่ถ้าผู้โจมตีขโมยไฟล์แล้วส่งต่อไปยังบัญชี Anthropic ของตัวเอง สุดท้ายก็เท่ากับว่า คนทั้งโลกเข้าถึงบัญชีนั้นได้ ซึ่งอันตรายมาก

  • ในเดโมมีการสาธิต prompt injection ผ่านไฟล์ .docx ที่ซ่อนข้อความด้วยขนาดตัวอักษรเล็กมาก แต่ในทางปฏิบัติ แค่ไฟล์ Markdown ธรรมดาก็พอแล้ว
    ตัวอย่างเช่น แค่ใส่คำอธิบายว่า “Claude กำลังเรียนรู้เทคนิคการเจรจาเงินกู้” คนจำนวนมากก็น่าจะใช้โดยไม่เปิดดูด้วยซ้ำ
    ในแง่ที่ว่าไฟล์ .md ดูน่าสงสัยน้อยกว่า .docx มันอาจยิ่งมีประสิทธิภาพกว่า

    • เหมือนสถานการณ์แบบ “หมีฉลาด vs ถังขยะที่เปิดไม่ออก”
    • แต่ไม่ใช่ว่าผู้ใช้ทุกคนจะคิดแบบนั้น
      เช่น ในบางอุตสาหกรรม ทุกวันนี้ยังมองว่า DOCX ปกติกว่า PDF
      ในสภาพแวดล้อมแบบนั้น ไฟล์ .md อาจกลับดูเหมือนเครื่องมือของแฮ็กเกอร์มากกว่า

  • ปัญหาแบบนี้เป็นสิ่งที่คาดไว้ตั้งแต่แรกแล้ว
    ตราบใดที่ prompt injection ยังแก้ไม่ได้ มันก็จะเกิดซ้ำไปเรื่อย ๆ
    ถ้าลองนึกภาพ HN ในปี 1999 บรรยากาศก็คงคล้าย ปฏิกิริยาแรก ๆ ต่อ SQL injection แบบ “Bobby Tables ลบฐานข้อมูลทิ้ง”

    • การเปรียบเทียบน่าสนใจ แต่ก็ไม่แม่นนัก
      ช่วงต้นยุค 2000 เราก็บอกกันอยู่แล้วว่าให้ใช้ parameterized SQL แทน string interpolation
      ตอนนี้เครื่องมือที่จำเป็นก็มีครบแล้ว ปัญหาคือผู้คน ให้ความสำคัญกับความเร็วมากกว่าความปลอดภัย
      ที่น่าขันคือผู้ที่เริ่มการแข่งขันนี้กลับเป็น OpenAI ซึ่งเคยเน้นเรื่องความปลอดภัยและ alignment
    • สงสัยว่าน่าจะแก้ได้แบบ input sanitization เหมือน SQL injection หรือเปล่า
      เช่น เอาอินพุตของผู้ใช้ไปครอบด้วยโทเคนบางอย่างอย่าง (@##)(JF) แล้วทำให้คำสั่งข้างในไม่ถูกเรียกใช้
      ฟังดูเหมือนใช้แค่ find/replace ง่าย ๆ ก็พอ เลยสงสัยว่าฉันพลาดอะไรไปหรือเปล่า
    • ปัญหาที่ลึกกว่านั้นคือ มันอาจเป็นสิ่งที่ ต่อให้ฉลาดขึ้นก็ยังแก้ไม่ได้
      ยิ่ง AI ฉลาดขึ้น ความเสี่ยงอาจยิ่งมากขึ้นด้วยซ้ำ
    • ผมกำลังทดลองใช้แพตเทิร์น Prepared Statement สำหรับเอเจนต์
      คือก่อนเรียกแต่ละเครื่องมือ ต้องยื่น “warrant” ที่มีลายเซ็นก่อน เพื่อจำกัดให้รันได้เฉพาะคำสั่งที่อนุญาต
      ทำให้ถึงจะเกิด prompt injection ก็ยัง ถูกบล็อกเชิงกลไก ได้

  • ให้ความรู้สึกเหมือนบั๊ก autorun แบบ “ถ้าดูน่าสงสัย ก็รันไฟล์มันเหมือนเป็นโปรแกรมไปเลย” กลับมาอีกครั้ง
    สมัย Windows XP ก็เคยปวดหัวกับเรื่องแบบนี้ จนสุดท้าย Microsoft ต้องหยุด autorun
    ระบบที่อิงกับพรอมป์ตก็ควร แยกให้ชัดว่าอะไรเชื่อถือได้

  • คิดว่าปัญหาคือบริษัท AI แค่ “ยอมรับว่ามีความเสี่ยง” แล้วก็ผลักให้ผู้ใช้ต้องปฏิบัติตาม ข้อควรระวังที่ไม่สมจริง

    • คำอธิบายส่วนใหญ่มักยกตัวอย่างเป็น “SQL injection” แต่จริง ๆ แล้วผมว่า ใกล้กับ phishing มากกว่า
      เช่น ถ้าสร้าง “บอทคุณยาย” มาช่วยจัดการอีเมล มันก็อาจโดน อีเมลหลอกลวงเจ้าชายไนจีเรีย หลอกได้
    • สุดท้ายก็แทบไม่ต่างจากการบอกว่า “ถ้าอยากใช้ผลิตภัณฑ์นี้อย่างปลอดภัย ก็ อย่าใช้มันเลย”

  • ดูเหมือนว่านี่เป็นปัญหาที่เกิดจากระบบ ‘สกิล’ ของ Claude ที่เป็นนัย
    มันไม่ได้ชัดเจนแบบคำสั่ง /slash แต่มีเพียงคำแนะนำประมาณ “วิธีแยกไฟล์ออกมา”
    เพราะงั้นแค่มีคำว่า “decompress” หรือ “extract” ก็อาจถูกสั่งให้รันอัตโนมัติได้
    โครงสร้างแบบนี้ทำให้ prompt injection แอบยัดความสามารถใหม่เข้ามา ได้ง่าย
    ดังนั้นจึงควรเปลี่ยนไปใช้ ระบบเครื่องมือที่ลงทะเบียนแบบชัดเจนและคงที่
    เช่น สร้างเครื่องมืออย่าง Extract(path) แล้วทำ whitelist ให้ใช้ได้เฉพาะ Read หรือ Bash("tar *")
    แบบนี้ยังเพิ่มขั้นตอนอนุมัติโดยมนุษย์ได้ด้วย และจะไม่มีการลงทะเบียนเครื่องมือใหม่ระหว่างเซสชัน

  • กรณีก่อนหน้านี้ที่เกี่ยวข้องและคำตอบอย่างเป็นทางการของ Anthropic สรุปไว้ในบล็อกโพสต์นี้

  • เป็นประเด็นที่ต่างออกไปนิดหน่อย แต่สงสัยว่ามีที่ไหนบ้างที่ให้บริการ PoC การรั่วไหลของข้อมูลแบบเป็นบริการ
    โดยเฉพาะอยากลองทดสอบ payload อันตรายใน CLAUDE.md ตอนที่ Claude รันอยู่ในสภาพแวดล้อม CI ภายนอก

  • กิจกรรมล่าสุดของ promptarmor น่าประทับใจมาก
    มีบทบาทสำคัญในการทำให้ทีมผลิตภัณฑ์ต้องรับผิดชอบเรื่องคุณภาพ

    • แต่พวกเขาก็มีผลประโยชน์ในการ ใช้การตลาดแบบปลุกความกลัว เพื่อขายสินค้า
      การโจมตีจริงต้องอาศัยให้เหยื่ออนุญาตให้ Claude เข้าถึงโฟลเดอร์ที่มีข้อมูลอ่อนไหว และถูกหลอกให้อัปโหลด DOCX ที่มี prompt injection ซ่อนอยู่แบบมองไม่เห็น
      แถมเนื้อหาของ injection ก็ยังจะโผล่ให้ผู้ใช้เห็นตอนแสดงผลแบบ Markdown
      ผู้โจมตีต้องใช้ API key ของตัวเอง จึง ตามรอยได้
      การโจมตีนี้ใช้ได้กับ Haiku เวอร์ชันเก่าเท่านั้น
      สุดท้ายแล้วเลยดูเหมือน promptarmor พูดเกินจริงเพื่อขายของ

  • ทีมของเราจำกัดให้ agent VM สื่อสารได้แค่ pip, npm, apt
    และคอยมอนิเตอร์ ขนาดของคำขอขาออก เพื่อป้องกันการรั่วไหลของข้อมูลที่ผิดปกติ

    • แต่นี่ไม่ใช่วิธีแก้ที่ต้นเหตุ
      ปัญหาสามชั้นเรื่อง การใช้ AI ในทางที่ผิด การรั่วไหล และความเป็นอิสระของมัน ไม่ได้แก้ได้ด้วยการปิดกั้นแค่ด้านเดียว
      แม้แต่คำขอขนาดเล็กก็ยังเข้ารหัสความลับไว้ได้ และ AI ที่ไม่ aligned ก็จะหาช่องทางรั่วไหลแบบนี้ได้เอง
    • เป็นแนวทางที่น่าสนใจ แต่ก็สงสัยว่าผู้โจมตีอาจอัปโหลด codebase ของผู้ใช้ทั้งชุดเป็นแพ็กเกจ ได้ด้วยหรือไม่