แฮกเกอร์ขโมย access token จากทีมซัพพอร์ตของ Okta

 (krebsonsecurity.com)
1 คะแนน โดย GN⁺ 2023-10-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การ เจาะระบบฝ่ายบริการลูกค้าของ Okta ทำให้ไฟล์บางส่วนที่ลูกค้าอัปโหลดไว้ในเคสซัพพอร์ตถูกเปิดเผย และคาดว่าผู้โจมตีเข้าถึงแพลตฟอร์มซัพพอร์ตได้อย่างน้อย 2 สัปดาห์ก่อนถูกสกัดกั้น
  • ผู้โจมตีใช้ข้อมูลรับรองที่ถูกขโมยเพื่อเข้าสู่ ระบบจัดการเคสซัพพอร์ต และสามารถดูไฟล์ HAR ที่ลูกค้าส่งมาเพื่อช่วยแก้ปัญหาได้
  • ไฟล์ HAR อาจมี คุกกี้และเซสชันโทเค็น อยู่ภายใน ดังนั้นหากถูกขโมย ผู้โจมตีอาจนำเซสชันกลับมาใช้ซ้ำได้เสมือนเป็นผู้ใช้ที่ยังล็อกอินอยู่จริง
  • BeyondTrust ตรวจพบความพยายามสร้างบัญชีผู้ดูแลระบบในสภาพแวดล้อม Okta ของบริษัทเมื่อวันที่ 2 ตุลาคม และก่อนหน้านั้น 30 นาทีได้แชร์ไฟล์ HAR ที่มี Okta session token ที่ยังใช้งานได้ให้ Okta
  • Okta แจ้งลูกค้าประมาณ 170 ราย หรือราว 1% จากลูกค้ามากกว่า 18,000 ราย และ 1Password กับ Cloudflare ก็เปิดเผยเช่นกันว่าแพลตฟอร์มยืนยันตัวตน Okta ของตนถูกกระทบ แต่ระบุว่าไม่มีผลต่อข้อมูลลูกค้าหรือระบบ

ไฟล์ลูกค้าที่ถูกเปิดเผยจากระบบจัดการเคสซัพพอร์ต

  • Okta เป็นบริษัทที่ให้บริการ เครื่องมือด้านตัวตน (ID tools) รวมถึงการยืนยันตัวตนหลายปัจจัยและ single sign-on แก่องค์กรหลายพันแห่ง และเหตุการณ์ครั้งนี้เริ่มต้นจากการเจาะฝ่ายบริการลูกค้า
  • ในประกาศที่ส่งถึงลูกค้าบางส่วนเมื่อวันที่ 19 ตุลาคม บริษัทแจ้งว่ามีการใช้ข้อมูลรับรองที่ถูกขโมยเพื่อเข้าถึง ระบบจัดการเคสซัพพอร์ต
  • ผู้โจมตีสามารถดูไฟล์ที่ลูกค้า Okta บางรายอัปโหลดไว้ในเคสซัพพอร์ตล่าสุดได้
  • ขอบเขตผลกระทบในตอนแรกถูกอธิบายว่าเป็น “จำนวนน้อยมาก” และต่อมามีการยืนยันว่าได้แจ้งลูกค้าประมาณ 170 ราย คิดเป็นราว 1% ของฐานลูกค้า

เหตุใดไฟล์ HAR จึงกลายเป็นความเสี่ยง

  • บางครั้ง Okta ขอไฟล์ HTTP Archive (HAR) ซึ่งเป็นบันทึกเซสชันของเว็บเบราว์เซอร์ เพื่อใช้แก้ปัญหาให้ลูกค้า
  • ไฟล์ HAR มีความอ่อนไหว เพราะอาจมีคุกกี้และ เซสชันโทเค็น ของลูกค้าอยู่ภายใน
  • ผู้โจมตีสามารถใช้คุกกี้หรือโทเค็นในไฟล์เพื่อปลอมตัวเป็นผู้ใช้ที่ยังมีเซสชันถูกต้องได้
  • Okta ระบุว่ากำลังสืบสวนร่วมกับลูกค้าที่ได้รับผลกระทบ และได้ใช้มาตรการป้องกัน เช่น การเพิกถอนเซสชันโทเค็นที่ฝังอยู่ในไฟล์
  • ก่อนแชร์ไฟล์ HAR ควรลบข้อมูลรับรอง คุกกี้ และเซสชันโทเค็นทั้งหมดออกก่อน

ลำดับการโจมตีที่ BeyondTrust จับได้

  • บริษัทความปลอดภัย BeyondTrust เป็นหนึ่งในลูกค้าที่ได้รับการแจ้งเตือนจาก Okta เมื่อวันที่ 19 ตุลาคม
  • Marc Maiffret CTO ของ BeyondTrust กล่าวว่า การแจ้งเตือนดังกล่าวมาถึงหลังจากที่ BeyondTrust แจ้ง Okta เกี่ยวกับปัญหาที่อาจเกิดขึ้นไปแล้วมากกว่า 2 สัปดาห์
  • ทีมความปลอดภัยของ BeyondTrust ตรวจพบเมื่อวันที่ 2 ตุลาคมว่ามีผู้พยายามสร้างบัญชีผู้ดูแลระบบสิทธิ์สูงในสภาพแวดล้อม Okta ของบริษัท โดยใช้บัญชี Okta ที่ผูกกับวิศวกรของบริษัท
  • เมื่อตรวจสอบกิจกรรมของบัญชีพนักงานดังกล่าว พบว่า 30 นาทีก่อนกิจกรรมที่ไม่ได้รับอนุญาต วิศวกรซัพพอร์ตได้แชร์ไฟล์ HAR ที่มี Okta session token ที่ยังใช้งานได้ให้ Okta ตามคำขอของ Okta
  • ผู้โจมตีพยายามใช้คุกกี้ในบันทึกเบราว์เซอร์เพื่อทำ session hijacking และดำเนินการแทนผู้ใช้คนนั้น
  • BeyondTrust แจ้ง Okta เมื่อวันที่ 3 ตุลาคมว่ามีความเป็นไปได้สูงที่ Okta จะถูกเจาะ และได้ย้ำข้อสรุปเดิมในการสนทนาเมื่อวันที่ 11 และ 13 ตุลาคม
  • BeyondTrust ระบุว่าตรวจพบการโจมตีได้ระหว่างที่กำลังเกิดขึ้น และลูกค้าของบริษัทไม่ได้รับผลกระทบ

การตอบสนองของ Okta และคำถามที่ยังค้างอยู่

  • Charlotte Wylie รอง CISO ของ Okta กล่าวว่า ตอนแรกบริษัทไม่ได้มองว่าการแจ้งเตือนจาก BeyondTrust เมื่อวันที่ 2 ตุลาคมเป็นผลจากการเจาะระบบของตน
  • ภายในวันที่ 17 ตุลาคม Okta ระบุและสกัดกั้นเหตุการณ์ได้แล้ว พร้อมปิดใช้งานบัญชีจัดการเคสลูกค้าที่ถูกเจาะ และทำให้ Okta access token ที่เกี่ยวข้องเป็นโมฆะ
  • Wylie ไม่ได้เปิดเผยจำนวนลูกค้าที่ได้รับการแจ้งเตือนเรื่องปัญหาความปลอดภัยที่อาจเกิดขึ้นอย่างชัดเจน แต่ระบุว่าเป็น “ส่วนน้อยมาก ๆ” จากลูกค้ามากกว่า 18,000 ราย
  • ยังไม่มีการเปิดเผยว่าผู้บุกรุกเข้าถึงบัญชีจัดการเคสของบริษัทได้นานเท่าใด และใครอยู่เบื้องหลังการโจมตี
  • Wylie ระบุว่าผู้โจมตีครั้งนี้เป็น ผู้ไม่หวังดีที่รู้จักกันอยู่แล้ว ซึ่งเคยมุ่งเป้าไปที่ Okta และลูกค้าบางรายของ Okta มาก่อน

การเจาะระบบที่เกี่ยวข้องและการเปิดเผยเพิ่มเติม

  • การเปิดเผยของ Okta เกิดขึ้นเพียงไม่กี่สัปดาห์หลังเหตุแฮ็ก Caesar’s Entertainment และ MGM Resorts
  • ในเหตุของสองบริษัทคาสิโนนี้ ผู้โจมตีใช้ social engineering หลอกพนักงานให้รีเซ็ตข้อกำหนดการล็อกอินแบบหลายปัจจัยของบัญชีผู้ดูแลระบบ Okta
  • ในเดือนมีนาคม 2022 Okta เปิดเผยเหตุเจาะระบบที่เกี่ยวข้องกับกลุ่มแฮ็ก LAPSUS$ ซึ่งเชี่ยวชาญการโจมตีแบบ social engineering
  • ตามรายงานหลังเหตุการณ์ของ Okta กลุ่ม LAPSUS$ ใช้ social engineering เพื่อเข้าถึงเวิร์กสเตชันของวิศวกรซัพพอร์ตจาก Sitel ซึ่งเป็นผู้รับจ้างภายนอกที่มีสิทธิ์เข้าถึงทรัพยากรของ Okta
  • หลังจากนั้น Okta ได้เผยแพร่บล็อกโพสต์เกี่ยวกับเหตุการณ์ พร้อมตัวบ่งชี้การถูกเจาะที่ลูกค้าสามารถใช้ตรวจสอบผลกระทบได้
    • บริษัทระบุว่าได้แจ้งลูกค้าที่ได้รับผลกระทบทั้งหมดแล้ว
    • และย้ำว่าสภาพแวดล้อมหรือทิกเก็ตซัพพอร์ตของลูกค้า Okta ที่ไม่ได้รับการติดต่อแยกต่างหากนั้นไม่ได้รับผลกระทบ
  • BeyondTrust ก็เผยแพร่ผลการสอบสวนของตนเองเช่นกัน
  • ในอัปเดตวันที่ 24 ตุลาคม 1Password และ Cloudflare เปิดเผยว่าแพลตฟอร์มยืนยันตัวตน Okta ของตนถูกกระทบจากเหตุเจาะระบบ Okta
    • ทั้งสองบริษัทระบุว่าจากการสอบสวน ไม่พบว่าข้อมูลลูกค้าหรือระบบได้รับผลกระทบ
    • โฆษกของ Okta บอกกับ TechCrunch ว่าบริษัทได้แจ้งลูกค้าประมาณ 170 ราย หรือราว 1% ของฐานลูกค้า

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

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

 
GN⁺ 2023-10-22
ความคิดเห็นจาก Hacker News

  • ส่วนที่น่าขำของบทความนี้คือ Okta ได้รับแจ้งจากบุคคลที่สามเกี่ยวกับกิจกรรมผู้เช่าที่น่าสงสัย ตอนแรกกลับไม่พบหลักฐานการถูกเจาะระบบ และเพิ่งกลับไปตรวจสอบใหม่จนยืนยันการเจาะระบบได้หลังจาก BeyondTrust กดดันต่อเนื่อง
    Okta โพสต์บล็อกนี้ไว้ที่นี่: https://sec.okta.com/harfiles
    ประโยคเปิดคือ “Okta Security has identified adversarial activity” แต่ไม่มีการพูดถึงการ แจ้งเตือนจากบุคคลที่สาม เลย โปร่งใสดีจริงๆ

    • ตอนนี้ผมยังไม่เข้าใจเลยว่าทำไมยังมีใครใช้ Okta อยู่ การยืนยันตัวตน คือส่วนที่สำคัญที่สุดของ IT ทั้งหมด แต่ Okta ก็พิสูจน์ซ้ำแล้วซ้ำเล่าว่าเป็นฝ่ายที่ไม่น่าเชื่อถือและขาดความน่าไว้วางใจด้านความถูกต้อง ดูเหมือนระเบิดเวลาที่ใกล้จะระเบิด
    • หัวข้อของ Okta น่าจะเป็นหัวข้อประกาศเหตุละเมิดความปลอดภัยที่หมดแรงที่สุดในประวัติศาสตร์: “Tracking Unauthorized Access to Okta's Support System”
      หัวข้อนี้แย่มาก และทั้งไม่โปร่งใสไม่ตรงไปตรงมา ที่ Okta ไม่แม้แต่จะพูดถึงความจริงที่ว่า BeyondTrust แจ้งพวกเขาภายใน 30 นาทีหลังอัปโหลดไฟล์ HAR ไปยัง Okta Support เมื่อวันที่ 2 ตุลาคม นี่แย่มากจริงๆ

  • “Charlotte Wylie รอง CISO ของ Okta กล่าวว่า ในตอนแรก Okta เห็นว่าการแจ้งเตือนจาก BeyondTrust เมื่อวันที่ 2 ตุลาคมไม่ได้เป็นผลจากการเจาะระบบของตนเอง แต่ภายในวันที่ 17 ตุลาคม บริษัทก็ได้ระบุและสกัดกั้นเหตุการณ์นี้แล้ว”
    หมายความว่าบริษัทที่อ้างตัวว่าเป็นผู้เชี่ยวชาญด้านไซเบอร์ซีเคียวริตี้และการยืนยันตัวตน ได้รับการแจ้งภายใน 30 นาทีว่าตัวเองถูกแฮ็ก แต่กลับบอกว่าอีกฝ่ายเข้าใจผิด และปล่อยให้ผู้โจมตีเพ่นพ่านอยู่ 15 วันก่อนจะยอมรับ
    Wylie ต้องทำให้ดีกว่านี้

  • ไปดูโพสต์บล็อกที่ลิงก์ในบทความต้นฉบับก็ได้ บริษัทความปลอดภัยแห่งหนึ่งซึ่งเป็นลูกค้าของ Okta ตรวจพบกิจกรรมต้องสงสัยในเครือข่ายของตัวเองทันทีหลังแชร์ ไฟล์ HAR กับ Okta และแจ้ง Okta ว่ามีการเจาะระบบ
    https://www.beyondtrust.com/blog/entry/okta-support-unit-bre...

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

  • อาจเป็นความเห็นที่ไม่เป็นที่นิยม แต่ผมสงสัยว่า จุดผ่านหลักของ SSO ที่ใช้ OAuth, SAML และ 2FA ควรจะรันแบบ on-premises มากกว่ากดปุ่ม “ง่ายๆ” ของ SaaS หรือเปล่า
    ไม่ได้หมายถึงแค่ Okta แต่รวมถึง Auth0 (ที่ Okta ซื้อกิจการ), Authy และ Duo ด้วย

    • น่าเสียดายที่การรันแบบ on-premises ไม่ได้ป้องกันการถูกเจาะระบบเสมอไป และอาจแย่กว่าการฝากการยืนยันตัวตนไว้กับผู้ให้บริการคลาวด์มากด้วยซ้ำ
      ซอฟต์แวร์ทุกตัวมีบั๊กด้านความปลอดภัย และซอฟต์แวร์ on-premises ก็ไม่ใช่ข้อยกเว้น หลายองค์กร IT ไม่มีความเชี่ยวชาญพอจะดูแลและปกป้อง directory ของตัวเอง นี่ไม่ใช่แค่ติดตั้งซอฟต์แวร์ สร้างบัญชีไม่กี่บัญชี แล้วปล่อยทิ้งไว้ที่มุมห้อง แต่เป็นงานที่ยากมากซึ่งรวมถึงการกู้คืนหลังภัยพิบัติ การทดสอบแบ็กอัป และการวินิจฉัยว่ามีการถูกเจาะหรือไม่
      ยังไม่มีใครพิสูจน์ได้ว่าความปลอดภัย IT แบบ on-premises ดีกว่าความปลอดภัยของผู้ให้บริการคลาวด์จริงๆ แผนก IT แบบ on-premises บางแห่งที่ผมเคยเห็นด้วยตาตัวเองมีความปลอดภัยแย่มาก เช่น ที่หนึ่งยังรัน VPN ที่ใช้ใบรับรอง MD5 อยู่ในช่วงปี 2010~2020 ที่หนึ่งปล่อยเว็บเซอร์วิสที่ผู้ใช้ซึ่งไม่ต้องยืนยันตัวตนก็เข้าถึงข้อมูลส่วนบุคคลอย่างเลขประจำตัวประชาชน/เลขผู้เสียภาษี ที่อยู่ ชื่อ และเบอร์โทรได้ ที่หนึ่งให้พยาบาลใช้โปรแกรมแก้ไขข้อความที่มีโฆษณาเพื่อเขียนบันทึกผู้ป่วย และอีกที่ไม่ยอมอัปเดต Redcap เวอร์ชันหมดระยะซัพพอร์ตทั้งที่มีบั๊กความปลอดภัยที่รู้กันอยู่แล้ว
      เท่าที่ผมเข้าใจ Redcap เป็นซอฟต์แวร์ที่เก็บข้อมูลสำหรับงานวิจัยทางการแพทย์และการคำนวณสถิติด้านสาธารณสุข ซึ่งมีข้อมูลอ่อนไหวอยู่มาก
      ประเด็นสำคัญคือ การย้ายจากคลาวด์กลับไป on-premises อาจทำให้ความปลอดภัยดีขึ้น หรืออาจไม่ก็ได้ มันขึ้นอยู่กับความสามารถของแต่ละองค์กร IT และหลายองค์กรก็ไม่มีศักยภาพจะรัน บริการจัดการตัวตน อย่าง Okta ได้ อีกทั้งผู้ให้บริการคลาวด์มักมีงบประมาณมากกว่ามาก และสามารถเฉลี่ยต้นทุนกับลูกค้าจำนวนมากได้ จึงลงทุนกับผู้เชี่ยวชาญด้านความปลอดภัย การปกป้องระบบ และการตรวจจับการบุกรุกได้มากกว่า
    • เห็นด้วย แต่ทุกวันนี้ต้นทุน on-premises มักถูกคิดอย่างเข้มงวดมาก ขณะที่ฝั่งคลาวด์ใครก็พูดว่า “เราแปลง capex เป็น opex และนำโซลูชัน cloud-native แบบ auto-scaling ระดับท็อปมาใช้แล้ว” ก็ถูกมองเป็นอัจฉริยะ
      ผู้จัดการและผู้บริหารแบบนั้นไม่เคยโดนตั้งคำถามอะไรเลย
    • ขอเสริมอีกความเห็นที่อาจไม่เป็นที่นิยม: ถ้าไม่จำเป็นต้องต่อเข้ากับเครือข่าย ก็อย่าต่อ
      คุณสามารถเขียนและทดสอบซอฟต์แวร์บนระบบที่ไม่เคยเชื่อมต่อเลยได้จริงๆ ฟังดูน่าประหลาด แต่เป็นเรื่องจริง
    • อย่าลืม Azure AD ด้วย ที่นั่นเคยโดนขโมย root key
    • Duo มีเวอร์ชัน on-premises ไหม? หรือถ้าผมอยากได้ฟังก์ชันส่วนใหญ่ประมาณนั้นบนโดเมนของตัวเอง ผมต้องติดตั้งและเชี่ยวชาญโซลูชันตั้งห้าตัว?

  • ผู้ให้บริการยืนยันตัวตน, ผู้จัดการรหัสผ่าน, และบริษัท VPN เป็นประเภทที่ไม่ควรถูกแฮ็กเด็ดขาด พวกเขาหาเงินจากการเป็นบริษัทด้านความปลอดภัย และผมคงไม่ใช้บริการที่เคยถูกเจาะ น่าจะมีปัญหาที่ลึกกว่านั้นอีก

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

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

    1. https://www.malwarebytes.com/blog/news/2023/01/okta-breached...
    2. https://www.theverge.com/2022/4/20/23034360/okta-lapsus-hack...
    3. https://techmonitor.ai/technology/cybersecurity/okta-cyberat...

  • ปีศาจซ่อนอยู่ในรายละเอียด น่าจะรันระบบแบบ Zero Trust อยู่ด้วยซ้ำ
    ในแง่หนึ่ง มันไม่ใช่การเจาะผลิตภัณฑ์หลักโดยตรง แต่อีกแง่หนึ่ง การเจาะผลิตภัณฑ์หลักทุกครั้งก็มักมีการเจาะทางอ้อมในส่วนที่ไม่ใช่แกนหลักนำมาก่อน

  • ช่างน่ายินดีจริงๆ ที่ได้รับอนุญาตให้ซื้อกิจการคู่แข่งอย่าง Auth0

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

  • มีข้อความนี้อยู่ท้ายอีเมล
    “ข้อมูลนี้เป็นข้อมูลลับของ Okta และห้ามแชร์ออกไปนอกองค์กรของคุณ”
    พูดตรงๆ ว่าค่อนข้างขำ

    • ถ้าพวกเขาขอไฟล์ HAR เป็นขั้นตอนซัพพอร์ตมาตรฐาน ทำไมตอนอัปโหลดถึงไม่ทำ การลบข้อมูลอ่อนไหว แบบอัตโนมัติล่ะ?