1Password ตรวจพบ “กิจกรรมน่าสงสัย” ในบัญชี Okta ภายใน

 (arstechnica.com)
1 คะแนน โดย GN⁺ 2023-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • 1Password ตรวจพบกิจกรรมน่าสงสัยเมื่อวันที่ 29 กันยายนใน อินสแตนซ์ Okta ภายใน ที่ใช้จัดการการเข้าถึงแอปสำหรับพนักงาน และไม่พบว่าข้อมูลผู้ใช้หรือระบบที่มีความอ่อนไหวถูกละเมิด
  • การเข้าถึงครั้งนี้เชื่อมโยงกับ การละเมิดระบบจัดการฝ่ายสนับสนุนลูกค้า ของ Okta โดยผู้โจมตีอาจได้คุกกี้รับรองความถูกต้องและโทเค็นเซสชันจากไฟล์ HAR ที่ลูกค้าอัปโหลด
  • รายงาน Notion ภายในของ 1Password ระบุว่าผู้โจมตีได้ ไฟล์ HAR ที่พนักงาน IT สร้างขึ้นระหว่างทำงานกับฝ่ายสนับสนุนของ Okta ซึ่งมีทราฟฟิก Okta และคุกกี้เซสชันอยู่ภายใน
  • ผู้โจมตีร้องขอรายงานผู้ใช้ผู้ดูแลระบบใน Okta tenant ของ 1Password และอัปเดตพร้อมเปิดใช้งาน IDP สำหรับการยืนยันตัวตนในสภาพแวดล้อมโปรดักชันของ Google แต่ความพยายามนำกลับมาใช้ภายหลังล้มเหลวเพราะ IDP ถูกลบไปแล้ว
  • การละเมิด Okta กลายเป็นกรณีของ การโจมตีต่อเนื่อง ที่การบุกรุกซัพพลายเออร์นำไปสู่การโจมตีลูกค้า และ 1Password เป็นลูกค้า Okta รายที่สองที่ทราบว่าตกเป็นเป้าหมาย

1Password ตรวจพบการเข้าถึง Okta ภายใน

  • 1Password เป็นโปรแกรมจัดการรหัสผ่านที่มีผู้ใช้หลายล้านคนและองค์กรกว่า 100,000 แห่งใช้งาน
  • บริษัทตรวจพบกิจกรรมน่าสงสัยเมื่อวันที่ 29 กันยายนใน อินสแตนซ์ Okta ที่ใช้จัดการแอปสำหรับพนักงาน
  • CTO Pedro Canahuati ระบุว่ากิจกรรมดังกล่าวถูกยุติทันทีและมีการสอบสวน โดยไม่พบว่าข้อมูลผู้ใช้หรือระบบสำคัญสำหรับพนักงานและผู้ใช้ถูกละเมิด
  • หลังจากนั้น 1Password ได้ร่วมกับ Okta สืบสวนเส้นทางที่ผู้โจมตีไม่ทราบตัวตนใช้เข้าถึงบัญชี

การละเมิดระบบสนับสนุนของ Okta และความเสี่ยงจากไฟล์ HAR

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

เป้าหมายรายที่สองที่ทราบ ต่อจาก BeyondTrust

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

ลำดับเหตุการณ์ในรายงาน Notion ภายใน

  • รายงานที่จัดทำเมื่อวันที่ 18 ตุลาคมและแชร์ในเวิร์กสเปซ Notion ภายในของ 1Password ระบุว่าผู้โจมตีได้ ไฟล์ HAR ที่พนักงาน IT ของบริษัทสร้างขึ้น
    • พนักงานรายดังกล่าวเพิ่งสร้างไฟล์นี้ขณะทำงานร่วมกับฝ่ายสนับสนุนของ Okta
    • ไฟล์มีบันทึกทราฟฟิกทั้งหมดระหว่างเบราว์เซอร์ของพนักงาน 1Password กับเซิร์ฟเวอร์ Okta รวมถึงคุกกี้เซสชัน
  • 1Password ไม่ได้ตอบกลับคำขอให้ยืนยันความถูกต้องของเอกสารที่พนักงานไม่เปิดเผยชื่อให้มาในรูปแบบข้อความและภาพหน้าจอ
  • ตามรายงาน ผู้โจมตียังเข้าถึง Okta tenant ของ 1Password ด้วย
    • Okta tenant ใช้จัดการสิทธิ์เข้าถึงระบบและระดับสิทธิ์ที่กำหนดให้พนักงาน พาร์ตเนอร์ และลูกค้า
    • ผู้โจมตีดูการกำหนดกลุ่มและดำเนินการอื่น ๆ ด้วย แต่บางการกระทำไม่ได้ถูกบันทึกใน event log
    • มีการอัปเดต IDP (identity provider) ที่ใช้สำหรับการยืนยันตัวตนในสภาพแวดล้อมโปรดักชันซึ่ง Google จัดเตรียมระหว่างการเข้าสู่ระบบ

สิ่งที่ผู้โจมตีทำและความพยายามซ้ำที่ถูกบล็อก

  • ทีม IT ของ 1Password รับรู้ถึงการเข้าถึงเมื่อวันที่ 29 กันยายน หลังได้รับอีเมลที่ไม่คาดคิดซึ่งบ่งชี้ว่ามีคำขอรายชื่อผู้ใช้ 1Password ที่มีสิทธิ์ผู้ดูแลระบบ
  • สมาชิกทีมสรุปว่าไม่มีพนักงานที่ได้รับอนุญาตเป็นผู้ทำคำขอดังกล่าว จึงแจ้งทีมตอบสนองด้านความปลอดภัยของบริษัท
  • สิ่งที่ผู้โจมตีทำมีดังนี้
    • พยายามเข้าถึงแดชบอร์ด Okta ของพนักงาน IT แต่ถูกบล็อก
    • อัปเดต IDP ที่มีอยู่ซึ่งเชื่อมกับสภาพแวดล้อม Google โปรดักชันของ 1Password
    • เปิดใช้งาน IDP ดังกล่าว
    • ร้องขอรายงานผู้ใช้ผู้ดูแลระบบ
  • วันที่ 2 ตุลาคม ผู้โจมตีเข้าสู่ระบบ Okta tenant ของ 1Password อีกครั้งและพยายามใช้ Google IDP ที่เคยเปิดใช้งานไว้ก่อนหน้า แต่ล้มเหลวเพราะ IDP ถูกลบแล้ว
  • การเข้าถึงทั้งสองครั้งมาจากเซิร์ฟเวอร์ของโฮสต์คลาวด์ LeaseWeb ในสหรัฐฯ และใช้ Chrome เวอร์ชันบนเครื่อง Windows
  • หลังเหตุการณ์ดังกล่าว 1Password เปลี่ยนการตั้งค่า Okta tenant เพื่อปฏิเสธการเข้าสู่ระบบผ่านผู้ให้บริการตัวตนที่ไม่ใช่ Okta

โครงสร้างที่การละเมิดซัพพลายเออร์นำไปสู่การโจมตีลูกค้า

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

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

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

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

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

    • อะไรทำให้ Okta ดีกว่า “เราเชื่อใจ Bob”? เท่ากับว่าไปเชื่อใจคนที่เราไม่รู้จักเลย แถมยังเคยก่อเหตุการณ์ด้านความปลอดภัยดัง ๆ หลายครั้งแล้วด้วย
    • เห็นด้วยในแง่การสื่อสาร แต่ในแง่ความปลอดภัยจริง ๆ แล้ว Bob ฝั่งผู้ให้บริการควรมองอย่างไร?

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

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

  • จากประโยคที่ว่า “เราได้เปลี่ยนข้อมูลประจำตัวสำหรับทุกระบบของสมาชิกทีม IT และเปลี่ยนให้ MFA ใช้ได้เฉพาะ Yubikey เท่านั้น” ก็หวังว่านี่จะเป็นโอกาสให้พนักงานทุกคนใช้ การยืนยันตัวตนสองขั้นตอนบนพื้นฐาน Yubikey อะไรที่ต่ำกว่า FIDO2 นั้นอ่อนแอจริง ๆ
    ผมสงสัยว่าทำไมคนยังเลือก Okta กันอยู่ ส่วนตัวรู้สึกว่าใช้ GSuite เป็นผู้ให้บริการตัวตนนั้นสะดวกกว่ามาก Okta เคยเจอการละเมิดที่ค่อนข้างร้ายแรง และพูดตรง ๆ ก่อนหน้านั้นก็ไม่เคยได้ยินเรื่องดี ๆ เกี่ยวกับแนวปฏิบัติด้านความปลอดภัยของเขาเลย

    • Yubikey หรือ MFA แบบอื่นที่ใช้ผ่านเบราว์เซอร์ก็คงป้องกันการโจมตีครั้งนี้ไม่ได้ เพราะผู้โจมตีได้ โทเค็นเซสชันผู้ดูแลระบบที่ยังใช้งานได้ หลังจาก MFA เสร็จสิ้นแล้ว
      การบังคับใช้ MFA แบบฮาร์ดแวร์เป็นแนวปฏิบัติที่ดี และอาจช่วยป้องกันการโจมตีอย่าง spear phishing ในอนาคตได้ แต่ไม่เกี่ยวข้องกับเหตุการณ์ครั้งนี้โดยตรง
      คนเลือก Okta ก็คล้าย ๆ กับคำว่า “ไม่มีใครถูกไล่ออกเพราะซื้อ IBM” อีกส่วนหนึ่งคือโครงสร้างการเอาต์ซอร์ส: ถ้าเดิน Keycloak เองแล้วโดนเจาะก็เป็นความรับผิดชอบของฉัน แต่ถ้าเป็น Okta ก็กลายเป็นว่าไม่ใช่ปัญหาของฉัน
    • สิ่งที่ถูกขโมยคือ คุกกี้เซสชัน และการยืนยันตัวตนสองขั้นตอนไม่เกี่ยวกับปัญหานี้
      ผมสงสัยว่าคุณเคยใช้ Google Workspace จริง ๆ ในงานจริงจังหรือเปล่า มันเป็นหนึ่งในผู้ให้บริการตัวตนที่ฟีเจอร์น้อยที่สุด ส่วน Okta อยู่ในกลุ่มที่ฟีเจอร์เยอะที่สุด การเทียบสองอย่างนี้เพียงเพราะทั้งคู่มีล้อสองล้อ ก็เหมือนเทียบจักรยานกับมอเตอร์ไซค์
      ไม่คิดว่าจะได้เห็นการแนะนำ Google Workspace ในฐานะผู้ให้บริการตัวตนบนฟอรัมสายเทคนิค
    • คนส่วนใหญ่ไม่ได้เลือก Okta หรอก ใครสักคนระดับผู้บริหาร เป็นคนเลือก Okta แล้วคนที่เหลือก็ต้องรับผลตามมา
      ถ้าใช้ Yubikey ปัญหาด้านซัพพอร์ตลูกค้าทั้งหมดเกี่ยวกับรหัสผ่านจะตกมาอยู่กับฝ่าย IT ภายใน แทนที่จะเป็นผู้รับเหมาภายนอก
      MFA มีทั้งปัญหาเชิงเทคนิคและปัญหาเชิงสังคม โดยด้านความปลอดภัยเชิงเทคนิคของการใช้งานอย่างกุญแจ โทเค็น โทรศัพท์ หรือ SMS แทบเป็นเรื่องเล็กน้อยมาก เมื่อเทียบกับปัญหาเชิงสังคมอย่างงานซัพพอร์ตลูกค้า รหัสผ่านที่หาย กุญแจที่เข้าเครื่องซักผ้า หรือรับอีเมลไม่ได้ ซึ่งใหญ่กว่ามหาศาล
      ทุกคนอยากเอาบทบาทซัพพอร์ตลูกค้าที่ใหญ่โตและงี่เง่าในเรื่องความปลอดภัยไปเอาต์ซอร์ส แต่พอทำแบบนั้นแล้ว ทุกคนก็มีแรงจูงใจให้ลดต้นทุน ผลลัพธ์ก็คือ Okta
    • การใช้ GSuite เป็นผู้ให้บริการตัวตน นั้นจำกัดมาก มันติ๊กช่อง “เป็นผู้ให้บริการตัวตน” ได้ก็จริง แต่พอไปไกลกว่าแค่ “เชื่อมต่อได้” ก็เริ่มยากหรือเป็นไปไม่ได้
      ตัวอย่างเช่น ถ้าจะให้การเข้าถึงองค์กร AWS สำหรับองค์กรที่พนักงานทุกคนอยู่ใน GSuite วิธีที่แนะนำคือ AWS SSO[1] ตั้งค่าการเชื่อมต่อแล้วก็ล็อกอินได้ แต่มีช่องโหว่หลายอย่าง
      ไม่มีฟังก์ชันในการโปรวิชันหรือเอาผู้ใช้ออกจาก AWS SSO อัตโนมัติตามกลุ่มผู้ใช้ใน GSuite แม้จะเขียนโค้ดเองได้ผ่านการรองรับ SCIM ของ SSO แต่ก็ต้องดูแลรักษาเอง
      ไม่มีวิธีบังคับให้ตรวจสอบ MFA ตอนสร้างเซสชัน SSO ทั้งฝั่ง GSuite และฝั่ง AWS SSO ฝั่ง GSuite ไม่สามารถบังคับให้ตรวจสอบ MFA ก่อนการยืนยันตัวตนแอป SAML ได้ และ AWS SSO เองเมื่อใช้ผู้ให้บริการตัวตนก็ไม่สามารถบังคับตรวจสอบ MFA ได้ ต่างจากตอนใช้ Directory ภายใน
      ผลิตภัณฑ์อย่าง Okta และที่คล้ายกันทำเรื่องเหล่านี้ให้ได้ และว่ากันว่ายังตั้งให้ตรวจสอบ MFA ตามเอนด์พอยต์ที่ใช้อยู่ได้ด้วย ผมไม่ได้ลองเอง อ้างอิงจากเอกสารการตลาดและคำอธิบายของฝ่ายขาย
      สรุปคือ Okta ให้ กาวด้านอัตโนมัติและความปลอดภัย ระหว่างผู้ให้บริการตัวตนกับแอปพลิเคชันที่ใช้งานได้มากกว่ามาก
      [1] ในที่นี้ AWS SSO หมายถึงผลิตภัณฑ์ของ AWS ที่ชื่อ “AWS IAM Identity Center (Successor to AWS Single Sign-On)”
    • มีหลักฐานไหมว่า Okta ดีกว่าหรือแย่กว่าโซลูชันอื่น? การวัดความปลอดภัย นั้นยากมาก
      หลักฐานที่เห็นตอนนี้มีแค่ว่า Okta ถูกละเมิดเมื่อปีที่แล้ว และครั้งนี้ก็ถูกละเมิดอีก โดยการละเมิดครั้งนี้เกิดขึ้นในแผนกหรือระบบซัพพอร์ตลูกค้า อาจมีการเปิดเผยการละเมิดล่าช้า แต่ก็อาจเป็นเพราะมีการแจ้งเหตุเท็จจำนวนมาก จึงเพิ่งพบหลักฐานไม่นานนี้ก็ได้ อาจไม่ได้ให้เครดิตลูกค้ารายแรกที่แจ้งเหตุ และหลังจากได้รับแจ้งแล้วอาจสื่อสารกับลูกค้าได้ไม่ดี
      สิ่งที่เราไม่รู้นั้นมีมากกว่ามาก เช่น ผู้โจมตีมีความชำนาญแค่ไหน ผู้ให้บริการตัวตนแต่ละรายถูกละเมิดกี่ครั้ง ตรวจพบกี่ครั้ง ตรวจพบแล้วปิดบังไว้หรือไม่ แต่ละบริการมีบั๊กด้านความปลอดภัยมากแค่ไหน ร้ายแรงแค่ไหน และหาเจอง่ายแค่ไหน ความสามารถในการตรวจจับการละเมิดเป็นอย่างไร การฝึกอบรมพนักงานดีแค่ไหน และพนักงานจริง ๆ แล้วมีสัดส่วนเท่าไรที่ใส่ใจเรื่องความปลอดภัย
      จะสรุปว่า ผลิตภัณฑ์แย่กว่าเพียงเพราะ Okta รายงานการละเมิดไม่ได้ เราไม่รู้ว่าผลิตภัณฑ์อื่นดีแค่ไหน และก็เป็นไปได้ว่า Okta อาจดีกว่าคู่แข่งบางรายหรือทุกราย แน่นอนว่าก็อาจแย่กว่าด้วย

  • เมื่อก่อนซื้อ 1Password ในราคาเต็ม ซอฟต์แวร์ทำงานแบบออฟไลน์ทั้งหมด และเก็บ vault ที่เข้ารหัสไว้ในเครื่องหรือใน Dropbox เมื่อไม่มีอะไรบนออนไลน์ให้ขโมย ก็ไม่ต้องกังวลเรื่องแฮกเกอร์
    แต่แล้วก็มีใครบางคนหยิบเครื่องคิดเลขมาคำนวณ และตัดสินใจว่าเส้นทางสู่การทำกำไรที่มากขึ้นคือย้ายข้อมูลของทุกคนไปไว้บน คลาวด์ แล้วเก็บ ค่าสมัครสมาชิก ตอนนี้เราก็เลยต้องมานั่งกังวลว่าข้อมูลรั่วหรือไม่

    • ก็จริงที่ความสะดวกเพิ่มขึ้นมากสำหรับคนที่ไม่ชำนาญพอจะจัดการเองโดยตรง
      และเท่าที่รู้ตอนนี้ มันต่างจากการวาง vault ไว้ใน Dropbox แค่ไหน? Dropbox ก็ถูกแฮกได้ และข้อมูลในนั้นก็ขึ้นชื่อว่าไม่ได้เข้ารหัสอยู่แล้ว ยังไม่ใช่ว่าเรารู้ว่ามีกรณีที่ vault ของ 1Password ถูกเจาะจริง ๆ ใช่ไหม?

  • https://blog.1password.com/okta-incident/
    รายงานเหตุการณ์ต้นฉบับ: https://blog.1password.com/files/okta-incident/okta-incident...

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

  • ครั้งนี้ความรับผิดชอบอยู่ที่ Okta อย่างชัดเจน เพราะในการแก้ปัญหากลับขอ session ที่เข้ารหัสใน HAR แบบ plain text แล้วคาดหวังให้ผู้ใช้ปลายทางจัดการล้างข้อมูลให้เรียบร้อยเอง
    ตอนอัปโหลด ก็น่าจะทำความสะอาดข้อมูล HAR ให้เหลือเฉพาะส่วนที่เกี่ยวข้องและปลอดภัยสำหรับช่างซัพพอร์ตที่เข้ามาดูในระบบ ซึ่งค่าจ้างน้อยและคนก็ไม่พอ ไม่ใช่หรือ?
    HAR เป็นข้อมูลแบบมีโครงสร้าง จึงล้างด้วยโปรแกรมได้ง่ายมาก ไม่ใช่วิทยาศาสตร์จรวดอะไรเลย

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

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

  • ประโยคที่ว่า “1Password กลายเป็นลูกค้า Okta รายที่สองที่เป็นที่รู้จักว่าเป็นเป้าหมายของการโจมตีต่อเนื่อง” ฟังดูแปลก Ars ไม่รู้หรือว่า Cloudflare ก็เป็นเหยื่อด้วย?
    https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...

    • ดูเหมือนหมายความว่า BeyondTrust เป็นผู้รายงานปัญหา ส่วน Cloudflare เป็นลูกค้า Okta รายแรกที่เป็นที่รู้จักว่าเป็นเป้าหมาย และ 1Password เป็นรายที่สอง

  • อยากรู้ best practice ในการมอนิเตอร์ พฤติกรรมน่าสงสัย ในแอป รู้พื้นฐานอย่างการดูอัตราคำขอหรืออัตราข้อผิดพลาดในระดับบริการอยู่แล้ว แต่ในทางปฏิบัติมันซับซ้อนได้แค่ไหน?
    สงสัยว่ามีเครื่องมืออัจฉริยะที่แค่ป้อน event stream เข้าไปแล้วช่วยหาพฤติกรรมผิดปกติให้หรือไม่ หรือเราต้องคิดล่วงหน้าเองทั้งหมดว่าจะมอนิเตอร์อะไร แล้วค่อยเพิ่ม rule

    • เป็นแค่คนทั่วไปนั่งอยู่บ้านที่ไม่มีประสบการณ์ด้านนี้ ควรฟังอย่างใช้วิจารณญาณ สิ่งสำคัญอันดับแรกคือ audit trail การกระทำทุกอย่างที่ทำกับบัญชีผู้ใช้หรือข้อมูล และการเปลี่ยนแปลงทุกอย่างในระบบ ควรอยู่ใน audit log พร้อม timestamp ผู้ใช้ ฯลฯ โดยเฉพาะเรื่องอย่างการเปลี่ยนรหัสผ่านหรือรายละเอียดบัญชี
      เมื่อมี event stream แบบนี้แล้ว ก็สามารถรันเครื่องมือวิเคราะห์ข้อมูลได้ ใช้กิจกรรมในช่วงหลายวัน·หลายสัปดาห์·หลายเดือนสร้าง baseline ของความปกติ และให้พฤติกรรมที่โดดออกมา เช่น การเปลี่ยนรหัสผ่านจำนวนมากหรือการเปลี่ยนอีเมล ส่งสัญญาณเตือน
      แต่ทั้งหมดเป็นแค่สมมติฐานจากคนอยู่บ้าน เลยอยากรู้ว่ามีใครที่เคยทำงานกับ audit log และการนำมันไปใช้จริงบ้างไหม
    • เป็นไอเดียสตาร์ทอัพ AI ที่ไม่เลว ทำเป็น Security as a Service โดย proxy ทุก request ผ่านบริการของบุคคลที่สามแล้วให้ตรวจจับความผิดปกติ แต่ถึงตรวจไม่พบ บริการนั้นก็คงไม่รับผิดชอบอยู่ดี
    • https://www.obsidiansecurity.com/

  • ตรวจพบอีกแล้วเหรอ?
    https://news.ycombinator.com/item?id=37991863