การข้ามขั้นตอนการล็อก: จุดอ่อนของ Claude Code CLI ทำให้กระบวนการใดๆ บน macOS สามารถอ่านข้อมูลประจำตัวที่จัดเก็บไว้ได้ 

Silverfort งานวิจัย เราได้รายงานเรื่องนี้ให้ Anthropic ทราบภายใต้หลักการเปิดเผยข้อมูลอย่างเป็นระบบ โพสต์นี้เป็นคู่มือการป้องกัน: วิธีการทำงานของจุดอ่อน และวิธีที่ฝ่ายป้องกันตรวจจับจุดอ่อนนั้นได้
Silverfort ภาพ
บล็อกวิจัยพวงกุญแจ CLI ของ Claude Code

บทสรุปผู้บริหาร

การขอ Silverfort ทีมวิจัยค้นพบว่า วิธีที่ Anthropic จัดเก็บข้อมูลประจำตัว Claude Code CLI บน macOS ทำให้กระบวนการใดๆ ที่ทำงานภายใต้สิทธิ์ของผู้ใช้เอง สามารถขโมยข้อมูลประจำตัวบัญชี Anthropic ของผู้ใช้ และโดยนัยเดียวกัน ข้อมูลประจำตัวเซิร์ฟเวอร์ MCP ที่เชื่อมต่ออยู่ได้ การอ่านแบบเงียบๆ เพียงครั้งเดียวจะส่งคืนชุดข้อมูลทั้งหมด ซึ่งผู้โจมตีสามารถเล่นซ้ำจากเครื่องอื่นเพื่อกระทำการเสมือนเป็นผู้ใช้ได้

macOS Keychain มีกลไกการจัดเก็บข้อมูลที่ปลอดภัยอย่างเหมาะสม ซึ่งกำหนดให้ผู้ใช้ต้องป้อนรหัสผ่านหรือยืนยันตัวตนด้วยไบโอเมตริกอีกครั้งก่อนที่จะเปิดเผยข้อมูลลับให้กับกระบวนการที่ร้องขอ Claude Desktop ใช้กลไกนี้อย่างถูกต้อง หากกระบวนการอื่นพยายามเข้าถึงข้อมูลประจำตัวที่จัดเก็บไว้ macOS จะแจ้งให้ผู้ใช้ยืนยันตัวตนอีกครั้ง แต่ Claude Code CLI ไม่ได้ทำเช่นนั้น มันถูกออกแบบมาในลักษณะที่อนุญาตให้กระบวนการในโหมดผู้ใช้ใดๆ ก็ตามดึงข้อมูลประจำตัวได้โดยไม่ต้องแจ้งให้ยืนยันตัวตนอีกครั้ง และเราจะอธิบายรายละเอียดเกี่ยวกับเรื่องนี้ในบล็อกนี้

นี่ไม่ใช่ช่องโหว่ทางเทคนิค แต่เป็นข้อบกพร่องในการออกแบบการใช้งาน ซึ่งเป็นจุดอ่อนด้านความปลอดภัย: ข้อมูลประจำตัวที่ควรต้องมีการตรวจสอบสิทธิ์ซ้ำกลับไม่ต้องทำเช่นนั้น การใช้ประโยชน์จากข้อบกพร่องนี้ไม่จำเป็นต้องใช้เทคนิคที่ซับซ้อนไปกว่าการ "เรียกใช้โค้ดในฐานะผู้ใช้" ซึ่งเป็นเกณฑ์ที่ต่ำกว่าการยกระดับสิทธิ์มาก ข้อบกพร่องในการออกแบบนี้ส่งผลกระทบต่อผู้ใช้ macOS ทุกคนที่ใช้งาน Claude Code CLI (ไม่ใช่ผู้ใช้ Desktop และผู้ใช้ Windows/Linux CLI เนื่องจากผู้ใช้เหล่านั้นใช้พื้นที่จัดเก็บข้อมูลแบบไฟล์ ซึ่งระบบป้องกันไวรัส/EDR ที่มีอยู่ควรตรวจสอบการเปลี่ยนแปลงแก้ไขอยู่แล้ว)

ผลลัพธ์โดยรวมคือ: หากมีโค้ดที่เป็นอันตรายทำงานอยู่ภายใต้บัญชีของผู้ใช้ โค้ดนั้นจะสามารถอ่านข้อมูลประจำตัวของ Claude ได้อย่างเงียบ ๆ โดยไม่ต้องมีการยกระดับสิทธิ์ ไม่มีการแจ้งให้ป้อนรหัสผ่าน ไม่มีการแจ้งเตือน และสามารถเข้าถึงเซิร์ฟเวอร์ MCP ได้ ใน macOS นั้น Keychain เป็นวิธีการที่ดีกว่าเมื่อเทียบกับการจัดเก็บข้อมูลแบบไฟล์ แต่เนื่องจาก Claude Code CLI ข้ามขั้นตอนการตรวจสอบสิทธิ์ใหม่ ข้อได้เปรียบนั้นจึงหายไป และไม่มีฮิวริสติกของโปรแกรมป้องกันไวรัสใดที่คอยตรวจสอบสิ่งนี้ในลักษณะเดียวกับฮิวริสติกการเข้าถึงไฟล์ในแพลตฟอร์มอื่น ๆ หากปลายทางถูกยึดครอง ผู้โจมตีจะสามารถเข้าถึงบัญชี Anthropic ของผู้ใช้และเซิร์ฟเวอร์ MCP ที่เชื่อมต่ออยู่ และสามารถมีอิทธิพลต่อทุกสิ่งที่เซิร์ฟเวอร์เหล่านั้นควบคุม ไม่ว่าจะเป็นโค้ดเบสของบริษัทใน GitHub ฐานความรู้ใน Atlassian หรือตัวเชื่อมต่อ MCP ที่สำคัญอื่น ๆ

Silverfort ได้รายงานข้อค้นพบนี้เมื่อวันที่ 25 มิถุนายน ให้กับ Anthropic ผ่านทาง HackerOne โดยปฏิบัติตามหลักการเปิดเผยข้อมูลอย่างรับผิดชอบ Anthropic ตอบกลับอย่างรวดเร็ว และหลังจากหารือกับทีมงานแล้ว พวกเขายืนยันว่ากำลังติดตามการปรับปรุงการควบคุมการเข้าถึงของ Keychain ให้เข้มงวดขึ้นเพื่อเป็นการเพิ่มความปลอดภัย และคิดว่าเป็นการเปลี่ยนแปลงที่ "คุ้มค่าที่จะทำ" Anthropic ไม่ได้คัดค้าน Silverfort เผยแพร่ผลงานวิจัย

คำแนะนำสำหรับผู้พิทักษ์
จนกว่าจะมีการแก้ไขปัญหานี้ องค์กรที่ใช้งาน Claude Code CLI บน macOS ควรตั้งค่าการแจ้งเตือนทุกครั้งที่มีการใช้โทเค็นเดียวกันในเครื่องต่างๆ นอกเหนือจากการตรวจจับและตอบสนองแบบดั้งเดิมแล้ว องค์กรควรพิจารณาใช้แพลตฟอร์มความปลอดภัยด้านข้อมูลประจำตัวที่สามารถควบคุมการใช้ข้อมูลประจำตัวแบบคงที่หรือชั่วคราว และแจ้งเตือนเมื่อมีการใช้โทเค็นเดียวกันจากเครื่องสองเครื่องที่แตกต่างกัน ซึ่งเป็นตัวบ่งชี้ที่ชัดเจนของการใช้ข้อมูลประจำตัวที่ถูกขโมย ทีมรักษาความปลอดภัยควรตรวจสอบการเข้าถึงกระบวนการที่ผิดปกติหรือไม่คาดคิดไปยังรายการ Keychain ที่ใช้โดย Claude Code CLI รูปแบบการเข้าถึงที่ผิดปกติไปยังที่เก็บข้อมูลประจำตัวนี้เป็นตัวบ่งชี้ที่สำคัญของการถูกโจมตีที่อาจเกิดขึ้น และควรได้รับการพิจารณาเป็นสัญญาณเตือนสำหรับการตรวจสอบ

พื้นหลัง

ปัจจุบันเอเจนต์การเขียนโค้ด AI มีข้อมูลประจำตัวจริงแล้ว ในการทำงาน พวกมันต้องล็อกอินและเก็บโทเค็นไว้ในเครื่อง และ... โค้ด CLI ของ Claude Claude ก็เช่นกัน เมื่อคุณใช้งาน มันจะลงชื่อเข้าใช้ด้วยชุด OAuth ซึ่งประกอบด้วยโทเค็นการเข้าถึงที่มีอายุสั้นและโทเค็นรีเฟรชที่มีอายุยาวนาน โทเค็นรีเฟรชเป็นส่วนที่คุณควรระวัง เพราะมันสามารถแลกเปลี่ยนเป็นโทเค็นการเข้าถึงใหม่ได้จนกว่าจะมีคนยกเลิก ดังนั้นมันจึงไม่ใช่เซสชันชั่วคราว แต่มันคือการเข้าถึงบัญชีแบบถาวรที่อยู่บนแล็ปท็อป

ตำแหน่งที่จัดเก็บชุดข้อมูล OAuth นั้นขึ้นอยู่กับระบบปฏิบัติการของคุณ บนสองในสามแพลตฟอร์ม (Linux และ Windows) มันจะเป็นไฟล์ธรรมดาบนดิสก์ ส่วนบน macOS มันจะถูกเก็บไว้ใน Keychain ของระบบปฏิบัติการ ซึ่งเป็นสิ่งที่ควรทำ แต่มีข้อเสียคือ โดยค่าเริ่มต้น รายการนั้นจะถูกล็อกไว้กับโปรแกรมที่สร้างมันขึ้นมา และในที่นี้ นั่นคือเครื่องมือรักษาความปลอดภัยที่กระบวนการใดๆ ก็สามารถเรียกใช้งานได้ ดังนั้น ตัวล็อกจึงมีอยู่แต่ไม่เคยล็อกจริงๆ และกระบวนการใดๆ ภายใต้บัญชีของคุณก็จะได้รับโทเค็นโดยไม่ต้องให้ผู้ใช้ป้อนรหัสผ่านเพิ่มเติม

เราจะติดตามการใช้ข้อมูลรับรอง CLI ของ Claude Code ในทั้งสามแพลตฟอร์ม ตรวจสอบข้อบกพร่องของ macOS อย่างละเอียด กล่าวถึงเทคนิคขนาดเล็กสำหรับการนำบันเดิลที่ถูกขโมยมาใช้ซ้ำ และปิดท้ายด้วยคำถามที่ทุกองค์กรจะถาม: ระบบใหม่นี้ไม่ได้... เกตเวย์แอป Claude ทำให้เรื่องนี้ไม่สำคัญไปเลยหรือ? คำตอบสั้นๆ คือ ไม่

ความลับในแฟ้มฟังดูแย่กว่า แต่เป็นสิ่งที่คุณสามารถรับชมได้

บน Linux และ Windows ข้อมูลประจำตัวจะถูกบันทึกไว้ในไฟล์ JSON ที่เป็นข้อความธรรมดา โดยไม่มีการใช้คีย์สโตร์ของระบบปฏิบัติการ ฟังดูเหมือนเป็นวิธีการที่อ่อนแอกว่า แต่ไฟล์ข้อมูลประจำตัวบนดิสก์เป็นปัญหาที่ผู้ป้องกันรู้วิธีจัดการอยู่แล้ว มันเป็นเป้าหมายคลาสสิก และเครื่องมือปลายทางอย่างเช่นโปรแกรมป้องกันไวรัสและ EDR สามารถตรวจสอบกระบวนการที่เข้าถึงไฟล์ที่มีโทเค็นได้ มีตำแหน่งที่ทราบแน่ชัดในการติดตั้งตัวควบคุมและมีสิ่งที่เป็นรูปธรรมที่จะแจ้งเตือน แต่บน macOS ระบบความปลอดภัยนั้นจะหายไป ดังที่เราจะได้เห็นต่อไป

เอกสารประกอบการใช้งาน Claude Code CLI ระบุตำแหน่งที่ไฟล์อยู่:

“บนระบบ Linux ข้อมูลประจำตัวจะถูกจัดเก็บไว้ใน ~/.claude/.credentials.json โดยใช้โหมดไฟล์ 0600”

“บนระบบปฏิบัติการ Windows ข้อมูลประจำตัวจะถูกจัดเก็บไว้ใน %USERPROFILE%\.claude\.credentials.json และสืบทอดการควบคุมการเข้าถึงจากไดเร็กทอรีโปรไฟล์ผู้ใช้ของคุณ ซึ่งโดยค่าเริ่มต้นจะจำกัดการเข้าถึงไฟล์ไว้เฉพาะบัญชีผู้ใช้ของคุณเท่านั้น”

มีข้อแม้ประการหนึ่ง: CLAUDE_CONFIG_DIR ย้ายไฟล์นี้ไปยังที่อื่น ดังนั้นกฎการตรวจจับที่กำหนดเส้นทางแบบตายตัวจะพลาดการติดตั้งเหล่านั้น

ภายในไฟล์นั้นมีทุกสิ่งที่มีค่าควรแก่การนำไปใช้ ได้แก่ โทเค็นการเข้าถึง OAuth (sk-ant-oat…) โทเค็นรีเฟรชที่มีอายุการใช้งานยาวนาน (sk-ant-ort…) การประทับเวลา expiresAt และขอบเขตของโทเค็น นอกจากนี้ ที่เก็บข้อมูลเดียวกันยังเก็บโทเค็น OAuth ของเซิร์ฟเวอร์ MCP และรหัสลับปลั๊กอินที่คุณเชื่อมต่อไว้ด้วย โทเค็นรีเฟรชเป็นสิ่งสำคัญที่สุด เพราะการอ่านเพียงครั้งเดียวจะทำให้คุณได้รับสิทธิ์การเข้าถึงบัญชีอย่างถาวร สำหรับ Linux และ Windows นี่คือคำแนะนำบางประการเกี่ยวกับสิ่งที่คุณควรระวัง:

  • การตรวจสอบความสมบูรณ์ของไฟล์ ดำเนินการ ~/.claude/.credentials.json (และ CLAUDE_CONFIG_DIR ตัวแปร) เป็นวัตถุที่ละเอียดอ่อน การแจ้งเตือนที่คุณต้องการคือการอ่านหรือเปิดโดยกระบวนการใดๆ ที่ไม่ใช่ไบนารีของ claude บน Linux คุณสามารถทำได้ด้วยการตรวจสอบ auditd (auditctl -w /home/*/.claude/.credentials.json -p rwa -k claude_credsหรือใช้ eBPF open telemetry บน Windows ให้ใช้การตรวจสอบการเข้าถึงวัตถุ (Event ID 4663) ร่วมกับ SACL หรือ EDR file-read telemetry
  • สิทธิ์การเข้าถึงเปลี่ยนแปลงไป ไฟล์ Linux ควรคงอยู่ที่เดิม 0600หากข้อความนั้นกลายเป็นข้อความที่กลุ่มหรือคนทั้งโลกสามารถอ่านได้ นั่นก็เป็นสัญญาณเตือนภัยอย่างหนึ่งแล้ว
  • ลายเซ็นเนื้อหา ให้ถือว่าคำนำหน้า sk-ant-oat (การเข้าถึง) และ sk-ant-ort (การรีเฟรช) เป็นตัวบ่งชี้ข้อมูลประจำตัวสำหรับ DLP และ AV ให้ทำเครื่องหมายคำนำหน้าเหล่านี้ในไฟล์นอกไดเร็กทอรีการกำหนดค่า ในไฟล์เก็บถาวร ในคลิปบอร์ด และในการรับส่งข้อมูลขาออก การตรวจพบคำนำหน้า refresh-token ถือเป็นเรื่องร้ายแรงที่สุด
  • มุมมองด้านอัตลักษณ์ สัญญาณที่ดีที่สุดไม่ได้อยู่ที่ปลายทางเลย โทเค็นที่ปรากฏขึ้นครั้งแรกบนโฮสต์หนึ่งแล้วปรากฏขึ้นจากอีกโฮสต์หนึ่งนั้นเป็นตัวบ่งชี้การขโมยแบบคลาสสิก คอยสังเกตว่าเซสชัน OAuth เดียวกันปรากฏขึ้นจากอุปกรณ์ สถานที่ หรือ IP ใหม่หลังจากอ่านข้อมูลในเครื่องไม่นาน การตรวจจับการนำกลับมาใช้ซ้ำข้ามโฮสต์แบบนี้คือสิ่งที่แพลตฟอร์มตรวจจับภัยคุกคามด้านอัตลักษณ์มีไว้เพื่ออะไร

เก็บไฟล์ที่แนบมาด้วย ~/.claude.jsonอยู่ในเรดาร์ของคุณด้วยเช่นกัน ไม่ใช่ร้านค้าลับ แต่เป็นร้านค้าที่เก็บข้อมูลประจำตัวบัญชี (oauthAccount,userIDซึ่งเป็นอีกครึ่งหนึ่งของช่วงการประชุมเชิงปฏิบัติการ รายละเอียดเพิ่มเติมอยู่ในหัวข้อถัดไป

กุญแจที่ล็อกไม่อยู่: บน macOS แนวคิดของ Keychain นั้นถูกต้อง แต่ต้องนำไปใช้งานอย่างถูกต้องด้วย

macOS แหวกรูปแบบนั้นโดยที่ CLI เก็บข้อมูลรับรองไว้ใน Keychain แทนที่จะเก็บไว้ในไฟล์อื่น .credentials.json ไฟล์ เอกสารระบุไว้อย่างชัดเจน:

“บน macOS ข้อมูลประจำตัวจะถูกจัดเก็บไว้ใน macOS Keychain ที่เข้ารหัสไว้”

นี่คือสัญชาตญาณที่ถูกต้องแล้ว พื้นที่จัดเก็บข้อมูลที่เข้ารหัสและได้รับการปกป้องโดยระบบปฏิบัติการย่อมดีกว่าไฟล์ธรรมดาเสมอ แต่ความปลอดภัยของรายการใน Keychain นั้นขึ้นอยู่กับรายการควบคุมการเข้าถึง (ACL) ที่แนบมาด้วย และนี่คือจุดที่รายการนี้มีปัญหา

Claude Code CLI สร้างรายการ Keychain โดยการเรียกใช้คำสั่ง shell /usr/bin/security add-generic-passwordและมันไม่ได้ส่งผ่านอาร์กิวเมนต์การควบคุมการเข้าถึงใดๆ: ไม่มี -T เพื่อเชื่อถือแอปพลิเคชันเฉพาะ ไม่มี -A เพื่ออนุญาตแอปพลิเคชันใดๆ ดังนั้นรายการจึงสืบทอดรายการควบคุมการเข้าถึง (ACL) เริ่มต้นของ Keychain หน้าคู่มือ OSHCL(1) อธิบายรายละเอียดว่าค่าเริ่มต้นนั้นทำอะไร:

“โดยค่าเริ่มต้น แอปพลิเคชันที่สร้างรายการจะได้รับอนุญาตให้เข้าถึงข้อมูลโดยไม่มีการแจ้งเตือน คุณสามารถลบสิทธิ์การเข้าถึงเริ่มต้นนี้ได้โดยการระบุพาธของแอปที่ว่างเปล่าอย่างชัดเจน: -T “”.”

ในเส้นทางการทำงานของโค้ดนี้ แอปพลิเคชันที่สร้างรายการนั้นคือ /usr/bin/security ตัวมันเอง ดังนั้นผู้อ่านที่เชื่อถือได้ซึ่งบันทึกไว้ในรายการนั้นคือ /usr/bin/securityนั่งอยู่ใน apple-tool: พาร์ติชั่นที่ macOS สงวนไว้สำหรับเครื่องมือที่ลงนามโดย Apple เอง ค่าเริ่มต้นนี้แหละคือปัญหาทั้งหมด /usr/bin/security เป็นเครื่องมือบรรทัดคำสั่งอเนกประสงค์ที่ลงนามโดย Apple และกระบวนการใดๆ ที่ทำงานภายใต้บัญชีของคุณสามารถเรียกใช้ได้โดยไม่ต้องมีสิทธิ์พิเศษใดๆ ACL ที่มีผู้อ่านที่เชื่อถือได้เพียงรายเดียวคือ security เครื่องมือนี้พึงพอใจกับกระบวนการใดๆ ที่ดำเนินการอยู่ security เครื่องมือ ซึ่งหมายถึงทุกกระบวนการบนเครื่อง ACL มีไว้เพื่อควบคุมว่าโปรแกรมใดบ้างที่สามารถอ่านข้อมูลลับได้ ในทางปฏิบัติ มันไม่ได้ควบคุมอะไรเลย เพราะโปรแกรมใดๆ ก็สามารถอ่านได้โดยการสั่งให้ไบนารีมาตรฐานทำการอ่าน

ผลลัพธ์ที่ได้คือข้อความบรรทัดเดียวที่อ่านได้โดยไม่ต้องพูดอะไร:

security find-generic-password -s "Claude Code-credentials" -a "$USER" -w

ไม่ต้องใช้ Touch ID ไม่มีการแจ้งให้ป้อนชื่อผู้ใช้และรหัสผ่าน ไม่มีการยกระดับสิทธิ์ ข้อมูลประจำตัวในรูปแบบ JSON จะถูกส่งกลับมาครบถ้วน ได้แก่ โทเค็นการเข้าถึง โทเค็นรีเฟรชที่มีอายุการใช้งานยาวนาน และรหัสลับ MCP หรือปลั๊กอินใดๆ ที่ใช้รายการเดียวกัน

ภาพพวงกุญแจ 1
รายการ Keychain ของ Claude Code CLI: security เป็นรายการเดียวใน ACL ดังนั้นการสอบถามเพียงครั้งเดียวโดยไม่ต้องมีการแจ้งเตือนใดๆ จะทำให้กระบวนการในโหมดผู้ใช้สามารถอ่านโทเค็นได้

Anthropic ทำสิ่งนี้ได้ดีอยู่แล้วใน Claude Desktop ดังนั้นทำไมถึงจะทำไม่ได้ใน Claude Code CLI?

หลักฐานที่ชัดเจนที่สุดว่านี่เป็นการเลือกวิธีการใช้งานมากกว่าข้อจำกัดของ macOS ก็คือ Anthropic ทำได้อย่างถูกต้องแล้วใน Claude Desktop Claude Desktop ทำงานบนระบบปฏิบัติการเดียวกัน สำหรับผู้ใช้คนเดียวกัน และปกป้องความลับประเภทเดียวกัน โดยใช้ Electron safeStorage และการออกแบบนี้ควรค่าแก่การอธิบาย เพราะมันไม่เหมือนกับการใช้งานผ่าน CLI safeStorage Electron จะเก็บคีย์การเข้ารหัสไว้ใน Keychain และจัดเก็บโทเค็นจริงในรูปแบบข้อความที่เข้ารหัสแล้วในไฟล์บนดิสก์ เอกสารของ Electron อธิบายถึงวิธีการปกป้องคีย์นั้นไว้ดังนี้:

“รหัสการเข้ารหัสจะถูกจัดเก็บไว้ใน Keychain Access สำหรับแอปของคุณในลักษณะที่ป้องกันไม่ให้แอปพลิเคชันอื่นโหลดรหัสเหล่านั้นได้โดยไม่ได้รับอนุญาตจากผู้ใช้”

รายการ Keychain ที่เก็บคีย์นั้นจะแสดงเฉพาะแอป Claude ที่ลงนามแล้วใน ACL ของมัน และพาร์ติชันนั้นถูกตรึงไว้กับทีมพัฒนาของ Anthropic ดังนั้นจึงไม่มีการอ่านข้อมูลด้านความปลอดภัยจากที่ใดก็ตาม มิเช่นนั้นจะถูกขอให้ป้อนรหัสผ่านเข้าสู่ระบบข้อความที่เข้ารหัสไว้ในดิสก์นั้นไร้ประโยชน์หากไม่มีกุญแจ และกุญแจก็ไม่สามารถสร้างขึ้นได้หากไม่มีการแจ้งเตือนนั้น

ภาพพวงกุญแจ 2
เมื่อใช้คำสั่งเดียวกันกับ Claude Desktop: macOS จะหยุดเพื่อขอรหัสผ่านสองครั้ง ผู้โจมตีที่ไม่สามารถตอบได้ก็จะไม่ได้อะไรเลย

การออกแบบทั้งสองแบบดูคล้ายกัน แต่การทำงานแตกต่างกันอย่างมาก CLI จะจัดเก็บโทเค็นไว้ใน Keychain พร้อมกับ ACL ที่อนุญาตให้กระบวนการใดๆ ก็ได้อ่านโทเค็นเหล่านั้น ในขณะที่ Claude Desktop จะจัดเก็บเพียงคีย์ไว้ใน Keychain ผูกคีย์นั้นเข้ากับลายเซ็นของตัวเอง และเก็บโทเค็นที่เข้ารหัสไว้ในไฟล์ที่ไม่สามารถใช้งานได้ด้วยตัวเอง ระบบปฏิบัติการเดียวกัน ผู้ใช้เดียวกัน ประเภทของความลับเดียวกัน: แบบหนึ่งสามารถอ่านได้โดยกระบวนการใดๆ อย่างเงียบๆ ในขณะที่อีกแบบหนึ่งต้องได้รับการอนุมัติจากผู้ใช้ ความแตกต่างอยู่ที่วิธีการสร้างรายการ Keychain และสิ่งที่มันปกป้อง

สาเหตุ: CLI มอบหมายการสร้างรายการให้กับ /usr/bin/security แทนที่จะใช้ API ของ Keychain Services ดั้งเดิมเพื่อผูกรายการเข้ากับลายเซ็นโค้ดของไบนารี Claude ซึ่งเป็นรูปแบบที่ Claude Desktop มีอยู่แล้ว เครื่องมือรักษาความปลอดภัยไม่สามารถผูกรายการเข้ากับโปรแกรมที่เรียกใช้งานได้ มีเพียง API ดั้งเดิมเท่านั้นที่ทำได้ ในแง่ของจุดอ่อน นี่คือ CWE-732 (การกำหนดสิทธิ์ที่ไม่ถูกต้องสำหรับทรัพยากรที่สำคัญ) และ CWE-522 (ข้อมูลประจำตัวที่ได้รับการปกป้องไม่เพียงพอ)

ภาพพวงกุญแจ 3
ไม่มีข้ออ้างเรื่องการลงนาม: การลงนามร่วมแสดงให้เห็นว่าทั้งสองไบนารี ทั้งเวอร์ชันเดสก์ท็อปและเวอร์ชัน CLI พร้อมที่จะใช้งาน Keychain อย่างถูกต้องเท่าเทียมกัน
หมายเหตุเกี่ยวกับขอบเขตการทำงาน ทั้งสองทิศทาง เรายืนยันเรื่องนี้แล้วใน Claude Code CLI เวอร์ชัน 2.1.185 เนื่องจากพฤติกรรมนี้เกิดขึ้นในเส้นทางการจัดเก็บข้อมูลประจำตัวหลัก จึงมีความเป็นไปได้สูงที่จะส่งผลกระทบต่อเวอร์ชันและวิธีการติดตั้งอื่นๆ ด้วยเช่นกัน แม้ว่าเราจะยังไม่ได้ทดสอบซ้ำในแต่ละเวอร์ชันก็ตาม นอกจากนี้ยังเป็นการเปิดเผยข้อมูลภายในผู้ใช้คนเดียวกัน ไม่ใช่การยกระดับสิทธิ์ และไม่ใช่บั๊กจากระยะไกล ฟังดูน่าสบายใจจนกระทั่งคุณนึกได้ว่า การเปิดเผยข้อมูลภายในผู้ใช้คนเดียวกันนั้นเป็นจุดที่โปรแกรมขโมยข้อมูล สคริปต์หลังการติดตั้งที่เป็นอันตราย หรือส่วนขยาย IDE ที่เป็นศัตรูทำงานอยู่แล้ว

สร้างเซสชันขึ้นใหม่โดยไม่ต้องแก้ไขไฟล์การกำหนดค่าแม้แต่ไฟล์เดียว

การอ่านโทเค็นเป็นเพียงครึ่งหนึ่งของการปลอมตัวเท่านั้น ในการปลอมตัวเป็นเหยื่อ Claude Code CLI จำเป็นต้องรู้ด้วยว่าใครกำลังล็อกอินอยู่ ซึ่งโดยปกติแล้วข้อมูลนี้จะอยู่ใน... oauthAccount บล็อกด้านใน ~/.claude.jsonวิธีที่เห็นได้ชัดที่สุดคือการขโมยไฟล์นั้นไปด้วย แต่มีวิธีที่สะอาดกว่าและทิ้งร่องรอยน้อยกว่ามาก ซึ่งคุ้มค่าที่จะลองทำดู เพราะคำอธิบายที่เห็นได้ชัดว่าทำไมมันถึงได้ผลนั้นผิด

สูตรในเครื่องของผู้โจมตี:

1. ส่งออกโทเค็นการเข้าถึงที่ถูกขโมยและเรียกใช้คำสั่งหนึ่งครั้ง:

export ANTHROPIC_API_KEY=<access-token>
claude

2. ออกไป จากนั้น unset ANTHROPIC_API_KEY.

3. นำของที่ขโมยมาทั้งหมดไปใส่ไว้ในพวงกุญแจของคุณเอง:

security add-generic-password -U -s "Claude Code-credentials" -a "$USER" -T /usr/bin/security -w 'PASTE_THE_JSON_HERE'

4.วิ่ง claude อีกครั้ง คุณได้เข้าสู่ระบบในฐานะผู้เสียหายแล้ว

ส่วนนี้อาจดูขัดกับสามัญสำนึก ตัวแปรสภาพแวดล้อมไม่ใช่สิ่งที่ใช้ในการล็อกอิน แต่เป็นสิ่งที่ถูกขโมยมา sk-ant-oat… ค่าที่ใส่ใน ANTHROPIC_API_KEY จะถูกส่งออกไปเป็นส่วนหัว X-Api-Key ตามเอกสารลำดับความสำคัญของการตรวจสอบสิทธิ์ CLI ของ Claude Code ซึ่งเป็นส่วนหัวที่ไม่ถูกต้อง และยังเป็นโทเค็นประเภทที่ไม่ถูกต้องด้วย เพราะโทเค็นการเข้าถึง OAuth ไม่ใช่คีย์ API ของคอนโซล มันไม่สามารถตรวจสอบสิทธิ์การเรียกใช้โมเดลได้เลย

แล้วการส่งออกนั้นมีไว้เพื่ออะไร? ลำดับการดำเนินการเป็นประเด็นสำคัญ การดำเนินการครั้งแรก โดยการส่งออกโทเค็นการเข้าถึงที่ถูกขโมยไปนั้น เป็นขั้นตอนที่จะเขียนข้อมูลประจำตัวบัญชีของเหยื่อลงใน ~/.claude.json ทำให้ผู้โจมตีไม่ต้องคัดลอกไฟล์นั้นอีกต่อไป จากนั้น คุณก็ยกเลิกการตั้งค่าตัวแปรและบันทึกชุดข้อมูลทั้งหมด รวมถึงโทเค็นรีเฟรช ลงใน Keychain เอกสารอธิบายไว้แล้ว unset ANTHROPIC_API_KEY โดยใช้เป็นวิธีการ "ย้อนกลับไปใช้การสมัครสมาชิกของคุณ" และการทำงานครั้งสุดท้ายก็ทำเช่นนั้นจริงๆ คือ ตรวจสอบสิทธิ์ด้วยชุด Keychain เป็นข้อมูลประจำตัวการสมัครสมาชิก ซึ่งโทเค็นรีเฟรชที่มีอายุการใช้งานยาวนานจะสร้างโทเค็นการเข้าถึงใหม่ๆ อย่างต่อเนื่อง ข้อมูลประจำตัวนั้นเป็นรายการที่มีลำดับความสำคัญต่ำที่สุดในรายการและมีความทนทานที่สุดด้วย

ทำไมผู้ป้องกันจึงควรใส่ใจ? เพราะจุดประสงค์หลักของวิธีการนี้คือการใช้ทรัพยากรน้อยที่สุด การอ่าน Keychain เพียงครั้งเดียวแบบเงียบๆ สามารถทดแทนการดึงไฟล์หลายไฟล์ได้ และจำนวนไฟล์ที่คัดลอกไปยังเครื่องต้นทางน้อยลง หมายความว่าจะมีตัวบ่งชี้สำหรับการตรวจจับการดึงข้อมูลน้อยลง บน macOS คุณไม่สามารถรอเหตุการณ์ไฟล์ได้ด้วยซ้ำ เพราะไม่มีไฟล์อยู่จริง การอ่านเกิดขึ้นภายในกระบวนการ ดังนั้นคุณต้องเฝ้าดูกระบวนการนั้น

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

keychain-attack-flow-redesign-hires_logo-01
ภาพรวมทั้งกระบวนการในภาพเดียว สีส้มแสดงถึงสองขั้นตอนสำคัญ คือ การอ่านข้อมูลจากพวงกุญแจแบบเงียบๆ และการเข้าควบคุมระบบ กล่องสีดำคือพัสดุที่ถูกขโมยไป เครื่องของเหยื่อทำทุกอย่างเพียงแค่การอ่านและส่งเท่านั้น

นี่คือขั้นตอนการทำงานเดียวกันในรูปแบบการพิสูจน์แนวคิด โดยแสดงการทำงานตั้งแต่ต้นจนจบ:

เกตเวย์แอป Claude จะแก้ไขปัญหานี้ได้ไม่ใช่เหรอ?

คำตอบสั้นๆ คือ ไม่ เราติดตั้งเกตเวย์แล้ว ใช้โค้ด Claude ของเราเองตรวจสอบ และทำการโจรกรรมแบบเดียวกันเป๊ะๆ มันก็ยังใช้งานได้อยู่

การระบุให้ชัดเจนว่าเกตเวย์คืออะไรนั้นสำคัญมาก เพราะความหมายของมันแคบกว่าชื่อที่บอก เกตเวย์ไม่ใช่เลเยอร์ความปลอดภัยที่ห่อหุ้มการตั้งค่า Claude ปกติของคุณ แต่มันเป็นเครื่องมือการกำหนดเส้นทาง วิธีการชี้ Claude Code ไปยังปลายทางโมเดลเฉพาะที่องค์กรใช้งานหรือเลือกใช้ ซึ่งไม่ใช่เส้นทางเริ่มต้นของ Anthropic เช่น บนเซิร์ฟเวอร์ภายในองค์กร Microsoft Foundry Amazon Bedrock Google Cloud หรือปลายทาง Anthropic ของตนเอง เหตุผลที่เราพบเห็นนั้นเป็นเหตุผลที่คุ้นเคยกันดี ได้แก่ การจัดเก็บข้อมูลและกฎการปฏิบัติตามข้อกำหนด ผู้ให้บริการคลาวด์ที่ต้องการ หรือการติดตั้งใช้งานในพื้นที่ หากองค์กรของคุณไม่ใช่แบบนั้น เกตเวย์ก็ไม่เคยเป็นส่วนหนึ่งของการตั้งค่าของคุณ และรายการ Keychain จะถูกเปิดเผยตามที่อธิบายไว้ในส่วนที่เหลือของโพสต์นี้

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

“ไม่มีความลับใด ๆ ที่คงอยู่ยาวนานบนเครื่องคอมพิวเตอร์ของนักพัฒนา”

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

ดังนั้นเราจึงตั้งค่าเกตเวย์ เชื่อมต่อ Claude เข้ากับเกตเวย์ และทำการโจมตีซ้ำจากส่วนที่แล้ว การอ่าน Keychain ไม่เปลี่ยนแปลง สคริปต์ Python บรรทัดเดียวเดิมดึงข้อมูลประจำตัวออกมาได้โดยไม่ต้องมีการแจ้งเตือน และเราคัดลอกข้อมูลนั้นไปยังเครื่องที่สอง

คราวนี้เราไม่จำเป็นต้องใช้ขั้นตอนการเริ่มต้นระบบเพิ่มเติมจากส่วนก่อนหน้า และเราก็ไม่ต้องการไฟล์ที่สองจากเหยื่อด้วย ที่อยู่ของเกตเวย์นั้นอยู่ในข้อมูลประจำตัวที่เราขโมยมาแล้ว ค่าที่เก็บไว้ในรายการ Keychain ของ Claude Code-credentials ไม่ได้มีเพียงแค่โทเค็นเท่านั้น มันยังบันทึกเกตเวย์ที่เหยื่อลงชื่อเข้าใช้ด้วย ดังนั้นการอ่านข้อมูลแบบเงียบๆ เพียงครั้งเดียวก็ทำให้เราได้ทั้งกุญแจและที่อยู่ของประตูที่พวกเขาเปิดออก

นั่นหมายความว่าไม่มีข้อมูลเพิ่มเติมใดๆ ที่จะดึงออกจากดิสก์ของเหยื่อ เราสร้างไฟล์คอนฟิกบนเครื่องของผู้โจมตีเองที่:
/Library/Application Support/ClaudeCode/managed-settings.json
และชี้ไปยัง URL เกตเวย์ที่เราเพิ่งอ่านออกมาจากข้อมูลประจำตัวที่ถูกขโมยมา:

{
"forceLoginMethod": "gateway",
"forceLoginGatewayUrl": "https://claude-gateway.internal.example.com"
}

การเขียนไฟล์นั้นไม่ใช่ปัญหาแต่อย่างใด Anthropic เองเรียกการตั้งค่าที่จัดการไว้ว่า “การควบคุมฝั่งไคลเอ็นต์ ไม่ใช่ขอบเขตด้านความปลอดภัย” ดังนั้นผู้โจมตีจึงมีอิสระที่จะสร้างการตั้งค่าของตนเองขึ้นมา จากนั้นเราก็โหลดข้อมูลประจำตัวที่ถูกขโมยมาและเริ่มใช้งาน Claude Code โดยไม่มีขั้นตอนแยกต่างหากในการสร้างตัวตนของเหยื่อขึ้นมาใหม่ ข้อมูลประจำตัวนั้นมีโทเค็น โทเค็นนั้นใช้ในการตรวจสอบสิทธิ์กับเกตเวย์ และเกตเวย์จะเรียกใช้เซสชันในฐานะเหยื่อ โดยมีสิทธิ์การเข้าถึงของเหยื่อ

เกตเวย์นี้มีอุปสรรคอยู่ข้อหนึ่งที่ผู้โจมตีจากระยะไกลอย่างเดียวไม่สามารถเอาชนะได้ Claude Code จะไม่สามารถสื่อสารกับเกตเวย์ที่ใช้ที่อยู่สาธารณะได้:

“ที่ /login นั้น Claude Code ต้องการให้ชื่อโฮสต์หรือที่อยู่ IP ของเกตเวย์สามารถแปลงเป็นที่อยู่ส่วนตัวได้เท่านั้น ได้แก่ RFC 1918, link-local, CGNAT 100.64.0.0/10, IPv6 ULA fc00::/7 หรือ loopback สำหรับการพัฒนาในพื้นที่ สำหรับเกตเวย์ที่คุณเป็นผู้ดูแลเอง ที่อยู่สาธารณะใดๆ จะถูกปฏิเสธ”

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

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

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

กองหลังควรทำอะไรทันที

  • macOS: จนกว่า ACL ของรายการจะถูกผูกเข้ากับลายเซ็น Claude จุดตรวจจับของคุณคือกระบวนการ ไม่ใช่ไฟล์ สัญญาณคือการเรียกใช้ /usr/bin/security find-generic-password ซึ่งมีสตริงบริการเป็น Claude Code-credentials และมีตัวเลือก -w เพื่อพิมพ์รหัสลับ แจ้งเตือนผ่านการทำงานของกระบวนการหรือการส่งข้อมูลทางไกลของ Endpoint Security และใช้ลำดับการทำงานของกระบวนการเพื่อลดการแจ้งเตือนที่ผิดพลาด: การอ่านที่ถูกต้องจะสืบย้อนกลับไปยังไบนารีของ Claude ดังนั้นให้ตรวจสอบสิ่งเหล่านั้นก่อน ในขณะที่สิ่งน่าสงสัยมาจากคำสั่งบรรทัดเดียวในเชลล์ โปรแกรมแก้ไขข้อความ หรือโฮสต์ส่วนขยาย หรือสคริปต์การติดตั้งส่วนประกอบ ตรวจสอบ add-generic-password สำหรับบริการเดียวกันด้วย เพราะนั่นคือวิธีที่ชุดโปรแกรมที่ถูกขโมยถูกฝังลงในเครื่องที่สอง ถือว่าการแจ้งเตือนเหล่านี้เป็นการควบคุมชดเชย
  • ลินุกซ์และ Windows: การตรวจสอบความสมบูรณ์ของไฟล์และ DLP บนไฟล์ .credentials.json, การแจ้งเตือนการเปลี่ยนแปลงสิทธิ์การเข้าถึง และลายเซ็นเนื้อหาบนคำนำหน้า sk-ant-oat และ sk-ant-ort
  • ทุกที่: เชื่อมโยงการอ่านข้อมูลจากที่เก็บข้อมูลประจำตัวกับการรับส่งข้อมูลขาออกที่ไม่คาดคิด และเฝ้าดูส่วนการยืนยันตัวตนเพื่อดูว่ามีการใช้โทเค็นเดียวกันซ้ำในโฮสต์ต่างๆ หรือไม่ หมุนเวียนโทเค็นเมื่อมีข้อสงสัย การอ่านเพียงครั้งเดียวจะส่งมอบโทเค็นรีเฟรชที่มีอายุการใช้งานยาวนาน ดังนั้นเหตุการณ์การอ่านที่น่าเชื่อถือจึงต้องมีการออกจากระบบและเข้าสู่ระบบใหม่ รวมถึงการหมุนเวียนคีย์คอนโซล ไม่ใช่แค่การล้างข้อมูลปลายทางเท่านั้น
  • วิธีแก้ปัญหาที่แท้จริงเป็นของ Anthropic และมีความเสี่ยงต่ำ: สร้างรายการ Keychain ของ CLI ผ่าน API ดั้งเดิม โดยผูกกับลายเซ็นโค้ดของไบนารี Claude เอง ซึ่งเป็นรูปแบบที่มีอยู่แล้วใน Claude Desktop

ข่าวดีก็คือ ส่วนที่ยากที่สุดนั้นได้รับการแก้ไขไปแล้วภายในโค้ดของ Anthropic เอง CLI ไม่จำเป็นต้องใช้โมเดลความปลอดภัยใหม่ มันใช้โมเดลที่มีอยู่แล้วในระบบข้างเคียงก็เพียงพอแล้ว

ไทม์ไลน์การเปิดเผยข้อมูล

25 มิถุนายน เวลา 3:46 น. ตามเวลา UTC นักวิจัยส่งรายงานพร้อมขั้นตอนการจำลองปัญหา ผลกระทบ และภาพหน้าจอสามภาพ

25 มิถุนายน เวลา 4:05 น. ตามเวลา UTC Anthropic ปิดเคสนี้โดยระบุว่าเป็นข้อมูลเบื้องต้นเพียง 19 นาทีต่อมา โดยตัดออกจากการพิจารณาภายใต้หัวข้อ “การจัดเก็บข้อมูลประจำตัว การกำหนดค่า และบันทึกของ Claude Code ในเครื่อง” และระบุว่ากระบวนการของผู้ใช้คนเดียวกันนั้นได้รับความไว้วางใจอย่างเต็มที่ ดังนั้น ACL ของ Keychain ต่อกระบวนการจึงไม่สร้างขอบเขตที่มีความหมายใดๆ

วันที่ 2 กรกฎาคม เวลา 11:12 น. ตามเวลา UTC นักวิจัยขอให้มีการประเมินใหม่โดยมนุษย์ โต้แย้งว่าการปิดถูกแมปไปยังการยกเว้นที่ไม่ถูกต้อง (นี่คือการตั้งค่า ACL ของ Keychain ผิดพลาด ไม่ใช่พื้นที่จัดเก็บข้อมูลในเครื่อง และ Desktop ทำได้ถูกต้องบนระบบปฏิบัติการเดียวกัน) แนบวิดีโอ POC และแจ้งให้ทราบเกี่ยวกับการเขียนรายงานแก้ต่างพร้อมข้อเสนอที่จะประสานงานการเปิดเผยข้อมูล

วันที่ 2 กรกฎาคม เวลา 11:14 น. ตามเวลา UTC บริษัท Anthropic รับทราบคำขอประเมินใหม่และกล่าวว่าจะตรวจสอบภายในองค์กร ยืนยันว่าการอภิปรายสาธารณะเป็นไปได้เนื่องจากรายงานฉบับนี้เสร็จสิ้นแล้ว และขอให้ดูร่างรายงานล่วงหน้า

กรกฎาคม 22 นักวิจัยได้ส่งร่างสุดท้ายของบล็อกให้ Anthropic ตรวจสอบก่อนตีพิมพ์ตามคำขอ และระบุว่าขณะนี้ได้รวมการวิเคราะห์ว่าเกตเวย์แอป Claude ช่วยลดข้อบกพร่องดังกล่าวได้หรือไม่

กรกฎาคม 24 Anthropic เสร็จสิ้นการตรวจสอบแล้ว รายงานว่าไม่มีข้อกังวลด้านข้อเท็จจริงหรือคำขอแก้ไขใดๆ และอนุมัติให้เผยแพร่รายงานได้ การจัดประเภทไม่เปลี่ยนแปลง: โดยเพิ่มเติมว่าขณะนี้กำลังติดตามการเพิ่มความเข้มงวดในการควบคุมการเข้าถึงของรายการ Keychain ในฐานะการปรับปรุงการเสริมความแข็งแกร่งเชิงป้องกันที่คุ้มค่าที่จะดำเนินการ แม้ว่าจะไม่ถือว่าเป็นช่องโหว่ภายใต้แบบจำลองภัยคุกคามของตนก็ตาม

เรากล้าที่จะผลักดันการรักษาความปลอดภัยข้อมูลประจำตัวไปไกลยิ่งขึ้น

ค้นพบสิ่งที่เป็นไปได้

ตั้งค่าการสาธิตเพื่อดู Silverfort แพลตฟอร์มการรักษาความปลอดภัยข้อมูลประจำตัวในการดำเนินการ

new hero (1)

Silverfort เข้าซื้อกิจการ Fabrix Security

มอบการรักษาความปลอดภัยข้อมูลประจำตัวแบบอัตโนมัติในระหว่างการทำงาน

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