เมื่อ AI ไม่ใช่จุดอ่อน: การเปิดเผยข้อมูลผู้สมัครของ McHire
นักวิจัยพยายามโจมตีแชทบอท AI สำหรับการจ้างงานของ McDonald's ด้วยการฉีดพรอมต์แต่ล้มเหลว จากนั้นพวกเขาเข้าสู่ระบบด้วยรหัสผ่าน 123456 และได้ข้อมูลผู้สมัครประมาณ 64 ล้านรายการ บทเรียนที่ได้นั้นตรงกันข้ามกับสิ่งที่ URL สื่อถึง
เกิดอะไรขึ้น
ในเดือนมิถุนายน 2025 นักวิจัยด้านความปลอดภัย Ian Carroll และ Sam Curry ได้เปิดเผยช่องโหว่ใน McHire ซึ่งเป็นแพลตฟอร์มการจ้างงานของ McDonald's ที่สร้างโดย Paradox.ai และใช้โดยแฟรนไชส์ส่วนใหญ่ของ McDonald's รายงานสาธารณะจาก Wired และ BleepingComputer ระบุว่าชุดข้อมูลที่ถูกเปิดเผยมีผู้สมัครงานประมาณ 64 ล้านคน พร้อมชื่อ ที่อยู่อีเมล หมายเลขโทรศัพท์ และบันทึกการสนทนาที่สามารถเข้าถึงได้โดยทุกคนที่ใช้วิธีเดียวกับที่นักวิจัยทำ
หัวข้อข่าวที่แพร่กระจายเร็วที่สุดระบุว่านี่เป็นการโจมตีแบบฉีดพรอมต์บนแชทบอท "Olivia" การระบุเช่นนั้นไม่ถูกต้อง นักวิจัยกล่าวว่าพวกเขาพยายามฉีดพรอมต์ก่อนและล้มเหลว: บอทถูกจำกัดอย่างเข้มงวดให้ตอบกลับด้วยข้อความที่กำหนดไว้ล่วงหน้าและไม่เคยมีข้อมูลแบ็คเอนด์ที่สามารถหลอกให้รั่วไหลได้ การประนีประนอมนี้ไม่เกี่ยวข้องกับโมเดลภาษาเลย
จุดเข้าใช้งานจริงคือหน้าเข้าสู่ระบบของผู้ดูแลระบบ Paradox.ai บน McHire ซึ่งสามารถเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ นักวิจัยลองใช้ข้อมูลรับรอง "123456" / "123456" บนบัญชีทดสอบที่ตามรายงานสาธารณะระบุว่ายังคงใช้งานอยู่ตั้งแต่ปี 2019 พวกเขาสามารถเข้าสู่ระบบได้
เมื่อเข้าไปข้างใน การอ้างอิงวัตถุโดยตรงที่ไม่ปลอดภัย (IDOR) แบบคลาสสิกบน API ของผู้สมัครทำให้พวกเขาสามารถเพิ่มรหัสตัวเลขและดึงบันทึกของผู้สมัครคนใดก็ได้ ไม่มีการใช้ประโยชน์จากโมเดล ไม่มีเทคนิคใหม่ ไม่มี zero-day ข้อมูลรับรองเริ่มต้นบวกกับการอ้างอิงวัตถุที่ไม่มีการรับรองความถูกต้อง
ทำไมรูปแบบนี้จึงเกิดขึ้นซ้ำๆ
ความล้มเหลวที่น่าสนใจในที่นี้ไม่ใช่ทางเทคนิค แต่เป็นทางองค์กร แชทบอทเป็นส่วนประกอบที่มองเห็นได้ซึ่งเป็น "AI" ดังนั้นจึงได้รับความสนใจด้านความปลอดภัย แผงควบคุมเว็บที่น่าเบื่อที่อยู่เบื้องหลังเป็นรัศมีการระเบิดที่แท้จริง และแทบไม่มีใครมองในแง่นั้นเลย
สิ่งนี้เกิดขึ้นเมื่อใดก็ตามที่ผู้ซื้อปฏิบัติต่อผู้จำหน่าย AI ในฐานะผลิตภัณฑ์ AI แทนที่จะเป็นแอปพลิเคชัน SaaS ที่มีโมเดลอยู่ โมเดลจะได้รับการตรวจสอบโดยทีมแดง คอนโซลผู้ดูแลระบบ, API ของผู้สมัคร, ที่เก็บข้อมูล, การบันทึกการตรวจสอบ, นโยบายการหมุนเวียนข้อมูลรับรอง — สิ่งที่มีโหมดความล้มเหลวที่รู้จักกันมานานหลายทศวรรษ — ถูกมองว่าเป็นเพียงระบบท่อประปา
โครงสร้างแรงจูงใจของผู้จัดจำหน่ายก็เสริมสร้างสิ่งนี้ ผู้จำหน่าย AI จัดส่งอย่างรวดเร็ว มักจะก่อนที่จะมีโปรแกรมความปลอดภัยที่สมบูรณ์ และทีมจัดซื้อของลูกค้าจะสอบถามเกี่ยวกับพฤติกรรมของโมเดลมากกว่าเกี่ยวกับแอปพลิเคชันโดยรอบ บัญชีทดสอบตั้งแต่ปี 2019 ที่มีรหัสผ่าน "123456" รอดมาได้หลายปีเพราะไม่มีใครกำหนดขอบเขตการตรวจสอบเพื่อค้นหามัน
การละเมิด AI ที่แพงที่สุดในอีกสองปีข้างหน้าจะไม่ใช่การใช้ประโยชน์จากโมเดล แต่จะเป็นช่องโหว่ของเว็บยุค 1990 ในแอปพลิเคชันที่ห่อหุ้มโมเดล
แผนการโจมตีของแฮกเกอร์ทีละขั้นตอน
ลำดับที่เปิดเผยนั้นสั้น และนั่นคือส่วนที่น่าอึดอัดใจ ผู้โจมตีที่มีทักษะไม่จำเป็นต้องมีชุดของเทคนิคใหม่ๆ
ขั้นตอนที่ 1: ระบุพื้นผิวของผู้จำหน่าย AI
ระบุผู้จำหน่ายบุคคลที่สามที่อยู่เบื้องหลังแชทบอทที่มองเห็นได้ ในกรณีนี้ บอทระบุว่าสร้างโดย Paradox.ai ซึ่งชี้ไปยังพื้นผิวการดูแลระบบที่แยกต่างหาก — หน้าเข้าสู่ระบบบนโดเมน McHire เดียวกัน
ขั้นตอนที่ 2: ลองใช้ข้อมูลรับรองที่ชัดเจน
ข้อมูลรับรองเริ่มต้นและอ่อนแอเป็นวิธีโจมตีแผงควบคุมของผู้ดูแลระบบผู้จำหน่ายที่ให้ผลตอบแทนสูงสุด รายงานระบุว่าบัญชีทดสอบเดียวที่มี "123456" / "123456" ก็เพียงพอแล้ว
ขั้นตอนที่ 3: เปลี่ยนจากผู้ดูแลระบบเป็นข้อมูล
บทบาทของผู้ดูแลระบบเปิดเผย API ของผู้สมัครภายใน API ใช้ตัวระบุตัวเลขตามลำดับและไม่ได้ตรวจสอบว่าบัญชีที่เรียกใช้ได้รับอนุญาตให้อ่านผู้สมัครแต่ละรายหรือไม่ การวนซ้ำ ID จะส่งคืนบันทึกตามอำเภอใจ
ขั้นตอนที่ 4: ยืนยันขอบเขตและเปิดเผย
นักวิจัยหยุดที่การพิสูจน์ผลกระทบ ตรวจสอบขนาดของชุดข้อมูล และรายงานไปยัง Paradox.ai และ McDonald's Paradox.ai ปิดใช้งานบัญชีทดสอบและรายงานว่าแก้ไข IDOR ได้ภายในไม่กี่ชั่วโมงหลังจากการเปิดเผย
สิ่งที่ผู้ป้องกันพลาดไป
สามสิ่ง โดยเรียงตามลำดับความรุนแรงที่ลดลงโดยประมาณ
ประการแรก ไม่มีการจัดการข้อมูลรับรองบนพื้นผิวผู้ดูแลระบบของผู้จำหน่าย บัญชีทดสอบที่สร้างขึ้นก่อนการใช้งานจริง ด้วยรหัสผ่านตัวเลขหกหลัก สามารถเข้าถึงได้จากอินเทอร์เน็ตสาธารณะห้าปีหลังจากสร้างขึ้น การตรวจสอบข้อมูลรับรองเป็นระยะๆ จะพบสิ่งนี้
ประการที่สอง ไม่มีการตรวจสอบการอนุญาตบน API ของผู้สมัคร IDOR เป็นหนึ่งในช่องโหว่ของเว็บที่เก่าแก่ที่สุดและมีเอกสารประกอบอย่างดีที่สุดในแค็ตตาล็อก OWASP ความจริงที่ว่าการเรียกผู้ดูแลระบบที่ได้รับการรับรองความถูกต้องส่งคืนบันทึกผู้สมัครตามอำเภอใจหมายความว่า API บังคับใช้การรับรองความถูกต้องแต่ไม่ใช่การอนุญาต
ประการที่สาม ไม่มีการตรวจสอบความปลอดภัยของพื้นผิวที่น่าเบื่อ แชทบอทได้รับความสนใจเพราะเป็น AI การเข้าสู่ระบบของผู้ดูแลระบบ, เกตเวย์ API และการจัดเก็บข้อมูล PII 64 ล้านรายการไม่ได้รับการตรวจสอบอย่างละเอียดเท่ากัน — ที่ McDonald's, ที่ Paradox.ai หรือที่แฟรนไชส์ที่ใช้งาน McHire
รายการตรวจสอบการป้องกันเชิงปฏิบัติ
การแก้ไขนั้นไม่น่าตื่นเต้น แต่เป็นสิ่งที่สามารถป้องกันเหตุการณ์นี้ได้
- จัดทำรายการพื้นผิวการรับรองความถูกต้องทั้งหมดที่เปิดเผยโดยผู้จำหน่าย AI ที่คุณใช้ รวมถึงแผงควบคุมของผู้ดูแลระบบ สภาพแวดล้อมการทดสอบ และเครื่องมือสนับสนุนลูกค้า ปฏิบัติต่อสิ่งเหล่านี้เหมือนแอปพลิเคชันเว็บที่เป็นทรัพย์สินสำคัญ ไม่ใช่เหมือนระบบท่อประปาสำหรับโมเดล
- กำหนดให้ผู้จำหน่ายรับรองเป็นลายลักษณ์อักษรว่าไม่มีข้อมูลรับรองเริ่มต้นหรือข้อมูลรับรองที่ใช้ร่วมกันในการผลิต และบัญชีทดสอบที่สร้างขึ้นระหว่างการเริ่มต้นใช้งานจะถูกลบเมื่อเริ่มใช้งานจริง
- เรียกใช้การทดสอบ IDOR/BOLA ที่ได้รับการรับรองความถูกต้องกับ API ทุกตัวที่ผู้จำหน่ายเปิดเผย โดยเฉพาะ API ที่ส่งคืนบันทึกต่อผู้ใช้ OWASP API Security Top 10 จัดอันดับสิ่งนี้เป็นอันดับ 1 ด้วยเหตุผลที่ดี
- บังคับใช้ SSO กับผู้ให้บริการข้อมูลประจำตัวของคุณสำหรับพื้นผิวผู้ดูแลระบบของผู้จำหน่ายทุกราย เพื่อให้ข้อมูลรับรองไม่สามารถเปลี่ยนแปลงได้อย่างอิสระ และบัญชีเก่าจะถูกปิดเมื่อพนักงานลาออก
- จำกัดสิทธิ์เซสชันของผู้ดูแลระบบ เพื่อไม่ให้บัญชีผู้ดูแลระบบที่ถูกบุกรุกเพียงบัญชีเดียวสามารถแจกแจงชุดข้อมูลผู้สมัครหรือลูกค้าทั้งหมดได้
- กำหนดให้ผู้จำหน่ายบันทึกและแจ้งเตือนเกี่ยวกับรูปแบบการอ่านจำนวนมากกับ API ที่ละเอียดอ่อน การดึงบันทึกผู้สมัครหลายสิบล้านรายการไม่ควรดูเหมือนวันปกติ
การทดสอบเชิงรุกสมัยใหม่จะจับสิ่งนี้ได้อย่างไร
การมีส่วนร่วมเชิงรุกที่กำหนดขอบเขตและได้รับอนุญาตกับพื้นผิวผู้จำหน่าย McHire — ไม่ใช่กับแชทบอท — จะพบสิ่งนี้ได้ในบ่ายวันแรก การตรวจสอบที่เกี่ยวข้องเป็นที่รู้จักกันดี: การสเปรย์ข้อมูลรับรองกับการเข้าสู่ระบบของผู้ดูแลระบบ, การควบคุมการเข้าถึงแนวนอนที่ได้รับการรับรองความถูกต้องบน API ที่มีพารามิเตอร์ทุกตัว และการตรวจสอบบัญชีทดสอบและขั้นตอนการรีเซ็ต
ตัวโมเดลเองไม่จำเป็นต้องมีทีมแดงในเรื่องนี้ โมเดลทำงานได้อย่างถูกต้อง การป้องกันของแชทบอททำงานได้ดี บทเรียนคือการตรวจสอบความปลอดภัยของแอปพลิเคชันอย่างละเอียดของผลิตภัณฑ์ที่ห่อหุ้มจะแจ้งเตือนทุกขั้นตอนของห่วงโซ่การสังหารก่อนที่จะใช้งานจริง
สิ่งที่ต้องจับตาดูต่อไป
คาดว่าจะเกิดเหตุการณ์เช่นนี้มากขึ้น ผู้จำหน่าย AI กำลังดูดซับขั้นตอนการทำงานที่ละเอียดอ่อนมากขึ้น — การจ้างงาน, การเรียกร้อง, การบริการลูกค้า, การจัดตารางเวลา — และคอนโซลการดูแลระบบแบ็คเอนด์รอบขั้นตอนการทำงานเหล่านั้นตอนนี้มีข้อมูลส่วนบุคคลที่ได้รับการควบคุมจำนวนมากที่เคยอยู่ในระบบที่เข้าถึงได้ยากกว่า
สองสิ่งที่ต้องจับตาดูในโปรแกรมของคุณเอง: ผู้จำหน่าย AI รายใดที่ถือครองข้อมูลส่วนบุคคลที่ได้รับการควบคุมจำนวนมากที่สุดในนามของคุณ และสิทธิ์ตามสัญญาของคุณในการทดสอบพื้นผิวผู้ดูแลระบบของพวกเขาเป็นอย่างไร หากคุณไม่สามารถเรียกใช้การตรวจสอบความปลอดภัยของแอปพลิเคชันที่ได้รับการรับรองความถูกต้องกับแผงควบคุมของผู้จำหน่ายได้ คุณกำลังเชื่อว่าบัญชีทดสอบถัดไปถูกลบไปแล้ว, API ถัดไปบังคับใช้การอนุญาต และรหัสผ่านเริ่มต้นถัดไปถูกหมุนเวียน การเปิดเผยของ McHire แสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อความเชื่อมั่นนั้นถูกวางผิดที่
How Global Rail Suite catches this
The McHire breach was two boring failures, not a clever AI attack. Each one maps to a specific Global Rail Suite surface.
An admin account (123456 / 123456) was left in production from 2019.
The Default Credential Probe tries a curated list of vendor defaults against any login surface you authorize, stops at first hit, and never stores the password.
→ Active probes → Default credential probeThe applicant API let any authenticated session read records by id (IDOR / BOLA).
The API Authorization Probe substitutes neighbour ids with your own session and flags responses you should not be able to read. Stores only sanitized metadata — never response bodies.
→ Active probes → API authorization probeThe chatbot was a third-party vendor (Paradox.ai) that was never audited.
AI Systems inventory tracks every AI vendor with role, data flows, and outstanding obligations — vendors without a signed DPA or risk assessment surface as findings.
→ Audit → AI systemsNo alert fired when ~64M records were enumerated.
The SOC bulk-read rule (MITRE T1530) raises a high-severity incident when a single actor pulls >1000 records from one endpoint within 10 minutes.
→ Live SOC → dashboard
Do this today
- •Run the default-credential probe against any admin/console URL you own.
- •Pick one user-id-keyed API endpoint and run the IDOR probe with your own token.
- •Confirm every AI vendor is in your AI Systems inventory with a signed DPA.
- •Set the bulk-read SOC rule threshold for your highest-value data API.
บทความที่เกี่ยวข้อง
ปัญหาการหลอนของ AI: เมื่อแชทบอทสร้างข้อมูลนโยบายที่ผิดพลาดและบริษัทต้องแบกรับผลกระทบ
แชทบอท AI กำลังสร้างข้อมูลนโยบายและส่วนลดที่ไม่ถูกต้อง ซึ่งนำไปสู่ความสูญเสียทางการเงินและความท้าทายทางกฎหมายสำหรับบริษัทต่างๆ การวิเคราะห์เชิงลึกสำหรับผู้นำด้านความปลอดภัยนี้จะสำรวจรูปแบบเหตุการณ์ สาเหตุหลัก และกลยุทธ์การป้องกันที่สำคัญ
การเจลเบรก AI ระดับองค์กร: ช่องโหว่ของ Agentic ทำให้ข้อมูลภายในรั่วไหลได้อย่างไร
การเกิดขึ้นของผู้ช่วย AI ในองค์กรนำมาซึ่งประสิทธิภาพที่ไม่เคยมีมาก่อน แต่ก็เป็นช่องทางโจมตีใหม่ด้วยเช่นกัน เหตุการณ์ล่าสุดเผยให้เห็นรูปแบบที่สำคัญ: การเจลเบรกที่ซับซ้อนกำลังเปิดเผยข้อมูลภายในที่ละเอียดอ่อน ไม่ใช่แค่ผ่านพฤติกรรมที่ไม่เหมาะสมของโมเดล แต่โดยการบิดเบือนความสามารถของ AI agent ในการโต้ตอบกับระบบองค์กรที่ผสานรวมกัน การวิเคราะห์นี้เจาะลึกกลไกของการโจมตีเหล่านี้และสรุปกลยุทธ์การป้องกันที่สำคัญสำหรับ CISO และวิศวกรความปลอดภัย
การรั่วไหลเงียบ: เอเจนต์ LLM ที่ควบคุมไม่ได้กำลังเผาผลาญงบประมาณโดยไม่รู้ตัวได้อย่างไร
การเจาะลึกรูปแบบเหตุการณ์ของเอเจนต์ LLM ที่ควบคุมไม่ได้ ซึ่งก่อให้เกิดการใช้จ่ายทางการเงินจำนวนมากผ่านการใช้โทเค็นที่มากเกินไป โดยพิจารณาถึงช่องโหว่ทางเทคนิคและกลยุทธ์การป้องกัน