สงครามเงาข้อมูลในยุค LLM โอเพนซอร์ส

คลื่นแห่งการละเมิดที่เปิดโปงช่องโหว่

การนำ Large Language Models (LLMs) แบบโอเพนซอร์ส เช่น DeepSeek และ Ollama มาใช้อย่างรวดเร็วกลายเป็นดาบสองคม ในขณะที่ธุรกิจต่างๆ กำลังใช้ประโยชน์จากเครื่องมืออันทรงพลังเหล่านี้เพื่อเพิ่มประสิทธิภาพ ความเปิดกว้างที่เป็นตัวขับเคลื่อนการเติบโตของ LLMs ก็กำลังสร้างความเสี่ยงด้านความปลอดภัยของข้อมูลควบคู่กันไป รายงานล่าสุดที่รวบรวมโดย NSFOCUS Xingyun Lab แสดงให้เห็นภาพที่ชัดเจน: ในช่วงสองเดือนแรกของปี 2025 โลกได้เห็นการละเมิดข้อมูลที่สำคัญห้าครั้งซึ่งเชื่อมโยงโดยตรงกับ LLMs เหตุการณ์เหล่านี้ส่งผลให้ข้อมูลที่ละเอียดอ่อนจำนวนมหาศาลรั่วไหล ตั้งแต่ประวัติการแชทที่เป็นความลับและ API keys ไปจนถึงข้อมูลประจำตัวของผู้ใช้ที่สำคัญ เหตุการณ์เหล่านี้เป็นสัญญาณเตือน โดยเน้นย้ำถึงช่องโหว่ด้านความปลอดภัยที่มักถูกมองข้ามซึ่งซ่อนอยู่ภายใต้พื้นผิวของเทคโนโลยี AI ที่ล้ำสมัย การสำรวจนี้จะแจกแจงเหตุการณ์ทั้งห้านี้ วิเคราะห์วิธีการโจมตี จับคู่กับกรอบ MITRE ATT&CK ที่กำหนดไว้ และเปิดเผยจุดบอดด้านความปลอดภัยที่องค์กรต่างๆ ต้องแก้ไขอย่างเร่งด่วน

เหตุการณ์ที่ 1: ฐานข้อมูลที่กำหนดค่าผิดพลาดของ DeepSeek – หน้าต่างสู่การสนทนาส่วนตัว

ไทม์ไลน์: 29 มกราคม 2025

ขนาดของการรั่วไหล: ข้อมูลบันทึกหลายล้านบรรทัด รวมถึงประวัติการแชทที่ละเอียดอ่อนและ access keys

การเปิดเผยเหตุการณ์:

ทีมวิจัยด้านความปลอดภัยที่ Wiz เป็นผู้ริเริ่มการค้นพบนี้ พวกเขาระบุบริการ ClickHouse ที่เปิดเผยซึ่งสามารถเข้าถึงได้บนอินเทอร์เน็ตสาธารณะ การตรวจสอบเพิ่มเติมยืนยันว่าบริการนี้เป็นของ DeepSeek สตาร์ทอัพ AI สัญชาติจีน ClickHouse ซึ่งออกแบบมาเพื่อการจัดการชุดข้อมูลขนาดใหญ่ในการประมวลผลเชิงวิเคราะห์อย่างมีประสิทธิภาพ กลายเป็นประตูสู่ข้อมูลภายในของ DeepSeek อย่างน่าเสียดาย นักวิจัยเข้าถึงสตรีมบันทึกของ DeepSeek ประมาณหนึ่งล้านบรรทัด เผยให้เห็นขุมทรัพย์ของข้อมูลที่ละเอียดอ่อน รวมถึงบันทึกการแชทในอดีตและ access keys ที่สำคัญ

Wiz แจ้งเตือน DeepSeek ถึงช่องโหว่ทันที นำไปสู่การดำเนินการทันทีและการกำจัดบริการ ClickHouse ที่เปิดเผยอย่างปลอดภัย

การวิเคราะห์การโจมตี:

ปัญหาหลักอยู่ที่ช่องโหว่ของ ClickHouse ต่อการเข้าถึงโดยไม่ได้รับอนุญาต ClickHouse ซึ่งเป็นระบบจัดการฐานข้อมูลแบบคอลัมน์โอเพนซอร์ส มีความยอดเยี่ยมในการสืบค้นและวิเคราะห์ชุดข้อมูลขนาดใหญ่แบบเรียลไทม์ ซึ่งมักใช้สำหรับการวิเคราะห์บันทึกและพฤติกรรมผู้ใช้ อย่างไรก็ตาม เมื่อปรับใช้โดยไม่มีการควบคุมการเข้าถึงที่เหมาะสม อินเทอร์เฟซ API ที่เปิดเผยจะอนุญาตให้ ทุกคน เรียกใช้คำสั่งที่เหมือน SQL

แนวทางของทีมรักษาความปลอดภัย Wiz เกี่ยวข้องกับการสแกนโดเมนย่อยที่เชื่อมต่ออินเทอร์เน็ตของ DeepSeek อย่างเป็นระบบ ในขั้นต้นเน้นที่พอร์ตมาตรฐาน 80 และ 443 พวกเขาพบทรัพยากรเว็บทั่วไป เช่น อินเทอร์เฟซแชทบอทและเอกสาร API เพื่อขยายการค้นหา พวกเขาขยายไปยังพอร์ตที่ไม่ธรรมดา เช่น 8123 และ 9000 ในที่สุดก็เปิดเผยบริการที่เปิดเผยบนโดเมนย่อยหลายแห่ง

ข้อมูลบันทึกที่ถูกบุกรุก ซึ่งย้อนหลังไปถึงวันที่ 6 มกราคม 2025 มีข้อมูลที่ละเอียดอ่อนมากมาย: บันทึกการโทร บันทึกข้อความสำหรับ endpoints API ภายในของ DeepSeek ประวัติการแชทโดยละเอียด API keys รายละเอียดระบบแบ็กเอนด์ และข้อมูลเมตาการดำเนินงาน

VERIZON Event Classification: Miscellaneous Errors

MITRE ATT&CK Framework Mapping:

• T1590.002 (Collect Victim Network Information - Domain Name Resolution): ผู้โจมตีอาจใช้ชื่อโดเมนหลักเพื่อแจกแจงโดเมนย่อย
• T1046 (Web Service Discovery): ผู้โจมตีระบุพอร์ตและบริการที่เปิดอยู่ซึ่งเชื่อมโยงกับโดเมนเป้าหมาย
• T1106 (Native Interface): ผู้โจมตีใช้ประโยชน์จาก ClickHouse API เพื่อโต้ตอบกับฐานข้อมูล
• T1567 (Data Exfiltration via Web Service): ผู้โจมตีใช้ ClickHouse API เพื่อขโมยข้อมูล

เหตุการณ์ที่ 2: การโจมตีห่วงโซ่อุปทานของ DeepSeek – ม้าโทรจันในโค้ด

ไทม์ไลน์: 3 กุมภาพันธ์ 2025

ขนาดของการรั่วไหล: ข้อมูลประจำตัวของผู้ใช้และตัวแปรสภาพแวดล้อม

การเปิดเผยเหตุการณ์:

การโจมตีเริ่มต้นในวันที่ 19 มกราคม 2025 เมื่อผู้ใช้ที่เป็นอันตราย ซึ่งระบุว่าเป็น “bvk” อัปโหลดแพ็คเกจ Python ที่เป็นอันตรายสองแพ็คเกจชื่อ “deepseek” และ “deepseekai” ไปยังที่เก็บ PyPI (Python Package Index) ยอดนิยม

ทีมข่าวกรองภัยคุกคามที่ Positive Technologies Expert Security Center (PT ESC) ตรวจพบกิจกรรมที่น่าสงสัยนี้ในวันเดียวกัน การวิเคราะห์ของพวกเขายืนยันลักษณะที่เป็นอันตรายของแพ็คเกจ และพวกเขาแจ้งผู้ดูแลระบบ PyPI ทันที

ผู้ดูแลระบบ PyPI ลบแพ็คเกจที่เป็นอันตรายออกอย่างรวดเร็วและแจ้ง PT ESC แม้จะมีการตอบสนองอย่างรวดเร็ว สถิติเปิดเผยว่ามัลแวร์ถูกดาวน์โหลดมากกว่า 200 ครั้งใน 17 ประเทศผ่านช่องทางต่างๆ แพ็คเกจที่เป็นอันตรายถูกแยกออกในเวลาต่อมา

การวิเคราะห์การโจมตี:

แพ็คเกจที่เป็นอันตรายที่อัปโหลดโดย “bvk” มุ่งเน้นไปที่วัตถุประสงค์หลักสองประการ: การรวบรวมข้อมูลและการขโมยตัวแปรสภาพแวดล้อม ข้อมูลที่ถูกขโมยรวมถึงข้อมูลที่ละเอียดอ่อน เช่น ข้อมูลประจำตัวฐานข้อมูล, API keys และข้อมูลประจำตัวการเข้าถึงสำหรับ S3 object storage เพย์โหลดที่เป็นอันตรายถูกทริกเกอร์เมื่อใดก็ตามที่ผู้ใช้เรียกใช้ DeepSeek หรือ Deepseekai จากบรรทัดคำสั่ง

ผู้โจมตีใช้ PipeDream เป็นเซิร์ฟเวอร์ command-and-control เพื่อรับข้อมูลที่ถูกขโมย เหตุการณ์นี้เน้นย้ำถึงปัจจัยสนับสนุนหลายประการ:

• Dependency Confusion Attack: ผู้โจมตีใช้ประโยชน์จากความแตกต่างของลำดับความสำคัญระหว่างแพ็คเกจส่วนตัวขององค์กรและแพ็คเกจสาธารณะที่มีชื่อเดียวกัน
• Package Name Impersonation: แพ็คเกจที่เป็นอันตรายเลียนแบบชื่อแบรนด์ของ DeepSeek ซึ่งเป็นบริษัท AI ที่มีชื่อเสียง เพื่อหลอกลวงผู้ใช้
• PyPI Registration Weakness: กระบวนการลงทะเบียน PyPI ขาดการตรวจสอบตัวตนของผู้พัฒนาและความถูกต้องของชื่อแพ็คเกจที่มีประสิทธิภาพ
• Developer Security Awareness: นักพัฒนาอาจติดตั้งแพ็คเกจที่เป็นอันตรายที่มีชื่อคล้ายกันโดยไม่ได้ตั้งใจ

VERIZON Event Classification: Social Engineering

MITRE ATT&CK Framework Mapping:

• T1593.003 (Search Open Websites/Domains - Search Publicly Available Dependency Repository): ผู้โจมตีค้นหาข้อมูลบน PyPI
• T1195.002 (Supply Chain Compromise - Compromise Software Supply Chain): ผู้โจมตีใช้มัลแวร์ที่ปลอมตัวเป็น Python dependencies และอัปโหลดไปยัง PyPI
• T1059.006 (Command and Scripting Interpreter - Python): ผู้โจมตีฝังโค้ดที่เป็นอันตรายในแพ็คเกจ ซึ่งเมื่อดำเนินการแล้ว จะรั่วไหลข้อมูลที่ละเอียดอ่อน
• T1041 (Exfiltration Over C2 Channel): ผู้โจมตีขโมยข้อมูลที่ละเอียดอ่อนผ่านช่องทาง PipeDream C2

เหตุการณ์ที่ 3: การจี้ LLM – DeepSeek ตกเป็นเป้าหมายการขโมยทรัพยากร

ไทม์ไลน์: 7 กุมภาพันธ์ 2025

ขนาดของการรั่วไหล: โทเค็นโมเดลประมาณ 2 พันล้านโทเค็นถูกใช้อย่างผิดกฎหมาย

การเปิดเผยเหตุการณ์:

ทีมวิจัยภัยคุกคาม Sysdig ค้นพบการโจมตี LLMs แบบใหม่ที่เรียกว่า “LLM jacking” หรือ “LLM hijacking” ในเดือนพฤษภาคม 2024

ภายในเดือนกันยายน 2024 Sysdig รายงานความถี่และความชุกของการโจมตีเหล่านี้ที่เพิ่มขึ้น โดย DeepSeek กลายเป็นเป้าหมายมากขึ้น

ในวันที่ 26 ธันวาคม 2024 DeepSeek ได้เปิดตัวโมเดลขั้นสูง DeepSeek-V3 ไม่นานหลังจากนั้น ทีม Sysdig พบว่า DeepSeek-V3 ถูกนำไปใช้ในโครงการ OpenAI reverse proxy (ORP) ที่โฮสต์บน Hugging Face

ในวันที่ 20 มกราคม 2025 DeepSeek ได้เปิดตัวโมเดลการอนุมานที่เรียกว่า DeepSeek-R1 ในวันถัดมา โครงการ ORP ที่สนับสนุน DeepSeek-R1 ก็ปรากฏขึ้น และผู้โจมตีเริ่มใช้ประโยชน์จากมัน โดยเติม API keys ของ DeepSeek ลงใน ORP หลายตัว

การวิจัยของ Sysdig ระบุว่าจำนวนโทเค็นโมเดลขนาดใหญ่ทั้งหมดที่ถูกใช้อย่างผิดกฎหมายผ่าน ORP เกิน 2 พันล้านโทเค็น

การวิเคราะห์การโจมตี:

LLM hijacking เกี่ยวข้องกับผู้โจมตีที่ใช้ประโยชน์จากข้อมูลประจำตัวคลาวด์ที่ถูกขโมยเพื่อกำหนดเป้าหมายบริการ LLM ที่โฮสต์บนคลาวด์ ผู้โจมตีใช้ประโยชน์จาก OAI (OpenAI) reverse proxy และข้อมูลประจำตัวที่ถูกขโมยเพื่อขายการเข้าถึงบริการ LLM ที่เหยื่อสมัครรับบริการ ส่งผลให้เกิดค่าใช้จ่ายบริการคลาวด์จำนวนมากสำหรับเหยื่อ

OAI reverse proxy ทำหน้าที่เป็นจุดจัดการกลางสำหรับการเข้าถึงบัญชี LLM หลายบัญชี โดยปิดบังข้อมูลประจำตัวและกลุ่มทรัพยากรพื้นฐาน ผู้โจมตีสามารถใช้ LLMs ราคาแพง เช่น DeepSeek โดยไม่ต้องจ่ายเงิน โดยส่งคำขอผ่าน reverse proxy ใช้ทรัพยากร และข้ามค่าบริการที่ถูกต้อง กลไกพร็อกซีซ่อนตัวตนของผู้โจมตี ทำให้พวกเขาสามารถใช้ทรัพยากรคลาวด์ในทางที่ผิดโดยไม่มีใครตรวจพบ

ในขณะที่ OAI reverse proxy เป็นองค์ประกอบที่จำเป็นสำหรับ LLM hijacking องค์ประกอบสำคัญคือการขโมยข้อมูลประจำตัวและ keys สำหรับบริการ LLM ต่างๆ ผู้โจมตีมักใช้ประโยชน์จากช่องโหว่ของบริการเว็บแบบดั้งเดิมและข้อผิดพลาดในการกำหนดค่า (เช่น ช่องโหว่ CVE-2021-3129 ในเฟรมเวิร์ก Laravel) เพื่อขโมยข้อมูลประจำตัวเหล่านี้ เมื่อได้รับแล้ว ข้อมูลประจำตัวเหล่านี้จะให้สิทธิ์การเข้าถึงบริการ LLM บนคลาวด์ เช่น Amazon Bedrock, Google Cloud Vertex AI และอื่นๆ

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

VERIZON Event Classification: Basic Web Application Attacks

MITRE ATT&CK Framework Mapping:

• T1593 (Search Open Websites/Domains): ผู้โจมตีใช้วิธี OSINT (Open-Source Intelligence) เพื่อรวบรวมข้อมูลเกี่ยวกับบริการที่เปิดเผย
• T1133 (External Remote Services): ผู้โจมตีระบุช่องโหว่ในบริการที่เปิดเผย
• T1586.003 (Compromise Accounts - Cloud Accounts): ผู้โจมตีใช้ประโยชน์จากช่องโหว่เพื่อขโมย LLM service หรือ cloud service credentials
• T1588.002 (Obtain Capabilities - Tool): ผู้โจมตีปรับใช้เครื่องมือ OAI reverse proxy แบบโอเพนซอร์ส
• T1090.002 (Proxy - External Proxy): ผู้โจมตีใช้ซอฟต์แวร์ OAI reverse proxy เพื่อจัดการการเข้าถึงบัญชี LLM หลายบัญชี
• T1496 (Resource Hijacking): ผู้โจมตีเปิดการโจมตี LLM injection เพื่อจี้ทรัพยากร LLM

เหตุการณ์ที่ 4: การละเมิดข้อมูล OmniGPT – ข้อมูลผู้ใช้ถูกขายบน Dark Web

ไทม์ไลน์: 12 กุมภาพันธ์ 2025

ขนาดของการรั่วไหล: ข้อมูลส่วนบุคคลของผู้ใช้มากกว่า 30,000 คน รวมถึงอีเมล หมายเลขโทรศัพท์ API keys, encryption keys, credentials และข้อมูลการเรียกเก็บเงิน

การเปิดเผยเหตุการณ์:

ในวันที่ 12 กุมภาพันธ์ 2025 ผู้ใช้ชื่อ “SyntheticEmotions” โพสต์บน BreachForums โดยอ้างว่าได้ขโมยข้อมูลที่ละเอียดอ่อนจากแพลตฟอร์ม OmniGPT และเสนอขาย ข้อมูลที่รั่วไหลรายงานว่ารวมถึงอีเมล หมายเลขโทรศัพท์ API keys, encryption keys, credentials และข้อมูลการเรียกเก็บเงินสำหรับผู้ใช้ OmniGPT กว่า 30,000 คน พร้อมด้วยบทสนทนาของพวกเขากับแชทบอทกว่า 34 ล้านบรรทัด นอกจากนี้ ลิงก์ไปยังไฟล์ที่อัปโหลดไปยังแพลตฟอร์มก็ถูกบุกรุก ซึ่งบางไฟล์มีข้อมูลที่ละเอียดอ่อน เช่น บัตรกำนัลและข้อมูลการเรียกเก็บเงิน

การวิเคราะห์การโจมตี:

ในขณะที่เวกเตอร์การโจมตีที่แม่นยำยังไม่เปิดเผย ประเภทและขอบเขตของข้อมูลที่รั่วไหลบ่งชี้ถึงความเป็นไปได้หลายประการ: SQL injection, การละเมิด API หรือการโจมตีทางวิศวกรรมสังคมอาจทำให้ผู้โจมตีเข้าถึงฐานข้อมูลแบ็กเอนด์ได้ นอกจากนี้ยังเป็นไปได้ว่าแพลตฟอร์ม OmniGPT มีการกำหนดค่าที่ผิดพลาดหรือช่องโหว่ที่อนุญาตให้ผู้โจมตีข้ามการรับรองความถูกต้องและเข้าถึงฐานข้อมูลที่มีข้อมูลผู้ใช้โดยตรง

ไฟล์ “Messages.txt” ที่เกี่ยวข้องกับการรั่วไหลครั้งที่สองมี API keys, ข้อมูลประจำตัวฐานข้อมูล และข้อมูลบัตรชำระเงิน ซึ่งอาจเปิดใช้งานการบุกรุกเพิ่มเติมในระบบอื่นหรือการแก้ไขข้อมูล เอกสารบางฉบับที่ผู้ใช้แพลตฟอร์มอัปโหลดมีข้อมูลลับทางการค้าและข้อมูลโครงการที่ละเอียดอ่อน ซึ่งก่อให้เกิดความเสี่ยงต่อการดำเนินธุรกิจหากนำไปใช้ในทางที่ผิด เหตุการณ์นี้เป็นเครื่องเตือนใจที่ชัดเจนถึงความจำเป็นในการเพิ่มความปลอดภัยของข้อมูลและการปกป้องความเป็นส่วนตัวภายในภาค AI และ big data ผู้ใช้ควรใช้ความระมัดระวังอย่างยิ่งเมื่อใช้แพลตฟอร์มเหล่านี้ และองค์กรต้องกำหนดนโยบายการใช้ข้อมูลที่เข้มงวด โดยใช้มาตรการต่างๆ เช่น การเข้ารหัส การลดข้อมูล และการไม่เปิดเผยตัวตนสำหรับข้อมูลที่ละเอียดอ่อน การไม่ทำเช่นนั้นอาจนำไปสู่ผลกระทบทางกฎหมาย ชื่อเสียง และเศรษฐกิจที่สำคัญ

VERIZON Event Classification: Miscellaneous Errors

MITRE ATT&CK Framework Mapping:

• T1071.001 (Application Layer Protocol - Web Protocols): ผู้โจมตีอาจเข้าถึงข้อมูลผู้ใช้ที่รั่วไหลและข้อมูลที่ละเอียดอ่อนผ่านเว็บอินเทอร์เฟซของ OmniGPT
• T1071.002 (Application Layer Protocol - Application Programming Interfaces): API keys และข้อมูลประจำตัวฐานข้อมูลที่รั่วไหลอาจทำให้ผู้โจมตีเข้าถึงระบบผ่าน API ของแพลตฟอร์มและดำเนินการที่ไม่ได้รับอนุญาต
• T1071.002 (Application Layer Protocol - Service Execution): ผู้โจมตีอาจละเมิดบริการระบบหรือ daemons เพื่อดำเนินการคำสั่งหรือโปรแกรม
• T1020.003 (Automated Exfiltration - File Transfer): ลิงก์ไฟล์ที่รั่วไหลและไฟล์ที่ผู้ใช้อัปโหลดที่ละเอียดอ่อนอาจเป็นเป้าหมายสำหรับผู้โจมตีในการดาวน์โหลด โดยได้รับข้อมูลที่ละเอียดอ่อนมากขึ้นสำหรับการโจมตีครั้งต่อไป
• T1083 (File and Directory Discovery): ผู้โจมตีสามารถใช้ข้อมูลที่รั่วไหลเพื่อรับข้อมูลทางธุรกิจที่สำคัญเพิ่มเติม

เหตุการณ์ที่ 5: ข้อมูลประจำตัว DeepSeek รั่วไหลใน Common Crawl – อันตรายของการ Hard-Coding

ไทม์ไลน์: 28 กุมภาพันธ์ 2025

ขนาดของการรั่วไหล: API keys, credentials และ authentication tokens ของ DeepSeek ที่ถูกต้องประมาณ 11,908 รายการ

การเปิดเผยเหตุการณ์:

ทีมรักษาความปลอดภัย Truffle ใช้เครื่องมือโอเพนซอร์ส TruffleHog เพื่อสแกนข้อมูล 400 TB จากเดือนธันวาคม 2024 ใน Common Crawl ซึ่งเป็นฐานข้อมูล crawler ที่ครอบคลุมหน้าเว็บ 2.67 พันล้านหน้าจากโฮสต์ 47.5 ล้านโฮสต์ การสแกนเปิดเผยสิ่งที่น่าตกใจ: API keys, credentials และ authentication tokens ของ DeepSeek ที่ถูกต้องประมาณ 11,908 รายการถูก hard-coded โดยตรงในหน้าเว็บจำนวนมาก

การศึกษายังเน้นย้ำถึงการรั่วไหลของ API keys ของ Mailchimp โดยพบ keys ประมาณ 1,500 keys ที่ hard-coded ในโค้ด JavaScript Mailchimp API keys มักถูกใช้ประโยชน์สำหรับการโจมตีแบบฟิชชิ่งและการโจรกรรมข้อมูล

การวิเคราะห์การโจมตี:

Common Crawl ซึ่งเป็นฐานข้อมูล web crawler ที่ไม่แสวงหาผลกำไร จะจับภาพและเผยแพร่ข้อมูลจากหน้าอินเทอร์เน็ตเป็นประจำ โดยจะจัดเก็บข้อมูลนี้ในไฟล์ WARC (Web ARChive) โดยรักษา HTML ดั้งเดิม โค้ด JavaScript และการตอบสนองของเซิร์ฟเวอร์ ชุดข้อมูลเหล่านี้มักใช้ในการฝึกโมเดล AI การวิจัยของ Truffle เปิดเผยปัญหาสำคัญ: การฝึกโมเดลบน corpora ที่มีช่องโหว่ด้านความปลอดภัยอาจนำไปสู่โมเดลที่สืบทอดช่องโหว่เหล่านั้น แม้ว่า LLMs เช่น DeepSeek จะใช้มาตรการรักษาความปลอดภัยเพิ่มเติมในระหว่างการฝึกและการปรับใช้ แต่การมีอยู่ของช่องโหว่ที่ hard-coded อย่างแพร่หลายในข้อมูลการฝึกสามารถทำให้ “unsafe” practices ดังกล่าวเป็นเรื่องปกติสำหรับโมเดลได้

Hard-coding ซึ่งเป็นแนวทางปฏิบัติในการเขียนโค้ดทั่วไปแต่ไม่ปลอดภัย เป็นปัญหาที่แพร่หลาย ในขณะที่สาเหตุหลักนั้นเรียบง่าย แต่ความเสี่ยงนั้นรุนแรง: การละเมิดข้อมูล การหยุดชะงักของบริการ การโจมตีห่วงโซ่อุปทาน และด้วยการเพิ่มขึ้นของ LLMs ภัยคุกคามใหม่ – LLM hijacking ดังที่ได้กล่าวไว้ก่อนหน้านี้ LLM hijacking เกี่ยวข้องกับผู้โจมตีที่ใช้ข้อมูลประจำตัวที่ถูกขโมยเพื่อใช้ประโยชน์จากบริการ LLM ที่โฮสต์บนคลาวด์ ส่งผลให้เกิดความสูญเสียทางการเงินจำนวนมากสำหรับเหยื่อ

VERIZON Event Classification: Miscellaneous Errors

MITRE ATT&CK Framework Mapping:

• T1596.005 (Search Open Technical Database - Scan Databases): ผู้โจมตีรวบรวมข้อมูลจากฐานข้อมูล crawler สาธารณะ
• T1588.002 (Obtain Capabilities - Tool): ผู้โจมตีปรับใช้เครื่องมือค้นหาข้อมูลที่ละเอียดอ่อน
• T1586.003 (Compromise Accounts - Cloud Accounts): ผู้โจมตีใช้เครื่องมือค้นหาข้อมูลที่ละเอียดอ่อนเพื่อค้นหา credentials ที่ละเอียดอ่อนในฐานข้อมูลสาธารณะ
• T1090.002 (Proxy - External Proxy): ผู้โจมตีใช้ซอฟต์แวร์ OAI reverse proxy เพื่อจัดการการเข้าถึงบัญชี LLM หลายบัญชี
• T1496 (Resource Hijacking): ผู้โจมตีเปิดการโจมตี LLM injection เพื่อจี้ทรัพยากร LLM

การป้องกันการรั่วไหลของข้อมูล LLM: แนวทางที่หลากหลาย

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

การเสริมสร้างความแข็งแกร่งให้กับห่วงโซ่อุปทาน:

ใช้ได้กับเหตุการณ์ที่ II (การโจมตีแพ็คเกจ dependency ที่เป็นอันตราย) และเหตุการณ์ที่ V (การละเมิดข้อมูลสาธารณะ):

1. การตรวจสอบความถูกต้องของ Dependency Packages ที่เชื่อถือได้:

   • ใช้เครื่องมือเช่น PyPI/Sonatype Nexus Firewall เพื่อสกัดกั้นแพ็คเกจ dependency ที่ไม่ได้ลงนามหรือมีที่มาที่น่าสงสัย
   • ห้ามการดึง dependencies โดยตรงจาก repositories สาธารณะในสภาพแวดล้อมการพัฒนา กำหนดให้ใช้ corporate private repository proxies (เช่น Artifactory)

2. การตรวจสอบภัยคุกคามห่วงโซ่อุปทาน:

   • รวมเครื่องมือเช่น Dependabot/Snyk เพื่อสแกนหาช่องโหว่ของ dependency โดยอัตโนมัติและบล็อกการนำส่วนประกอบที่มีความเสี่ยงสูงเข้ามา
   • ตรวจสอบลายเซ็นโค้ดของแพ็คเกจโอเพนซอร์สเพื่อให้แน่ใจว่าค่าแฮชตรงกับค่าอย่างเป็นทางการ

3. การทำความสะอาดแหล่งข้อมูล:

   • ในระหว่างการรวบรวมข้อมูลการฝึก ให้กรองข้อมูลที่ละเอียดอ่อนออกจากชุดข้อมูลสาธารณะ (เช่น Common Crawl) โดยใช้นิพจน์ทั่วไปและเครื่องมือแก้ไขที่ใช้ AI เพื่อการตรวจสอบซ้ำ

การใช้สิทธิ์ขั้นต่ำและการควบคุมการเข้าถึง:

ใช้ได้กับเหตุการณ์ที่ I (ข้อผิดพลาดในการกำหนดค่าฐานข้อมูล) และเหตุการณ์ที่ IV (การละเมิดข้อมูลเครื่องมือของบุคคลที่สาม):

• เปิดใช้งานการรับรองความถูกต้อง TLS แบบสองทิศทางตามค่าเริ่มต้นสำหรับฐานข้อมูล (เช่น ClickHouse) และป้องกันการเปิดเผยพอร์ตการจัดการบนเครือข่ายสาธารณะ
• ใช้โซลูชันเช่น Vault/Boundary เพื่อแจกจ่าย credentials ชั่วคราวแบบไดนามิก หลีกเลี่ยงการเก็บรักษา key แบบคงที่ในระยะยาว
• ปฏิบัติตามหลักการของสิทธิ์ขั้นต่ำ โดยจำกัดการเข้าถึงของผู้ใช้เฉพาะทรัพยากรที่จำเป็นผ่าน RBAC (Role-Based Access Control)
• ใช้ IP whitelisting และ rate limiting สำหรับการเรียก API ไปยังเครื่องมือของบุคคลที่สาม (เช่น OmniGPT)

การรับรองการป้องกันข้อมูลที่ละเอียดอ่อนตลอดวงจรชีวิต:

ใช้ได้กับเหตุการณ์ที่ III (LLM hijacking):

• การแก้ไขและการเข้ารหัสข้อมูล: บังคับใช้การเข้ารหัสระดับฟิลด์ (เช่น AES-GCM) สำหรับข้อมูลอินพุตและเอาต์พุตของผู้ใช้ ปิดบังฟิลด์ที่ละเอียดอ่อนในบันทึก
• เปิดใช้งานการแก้ไขแบบเรียลไทม์สำหรับเนื้อหาเชิงโต้ตอบของ LLMs (เช่น การแทนที่หมายเลขบัตรเครดิตและหมายเลขโทรศัพท์ด้วยตัวยึดตำแหน่ง)

มาตรการป้องกันเหล่านี้ รวมกับการตรวจสอบความปลอดภัยอย่างต่อเนื่องและการวางแผนรับมือกับเหตุการณ์ เป็นสิ่งจำเป็นสำหรับการลดความเสี่ยงที่เกี่ยวข้องกับการใช้ LLMs ที่เพิ่มขึ้น “สนามรบที่มองไม่เห็น” ของความปลอดภัย LLM ต้องการความระมัดระวังอย่างต่อเนื่องและแนวทางเชิงรุกเพื่อปกป้องข้อมูลที่ละเอียดอ่อนในภูมิทัศน์ทางเทคโนโลยีที่พัฒนาอย่างรวดเร็วนี้