ข้อมูลรั่วไหลของ Snowflake: ยืนยันว่าแฮกเกอร์เข้าถึงผ่านการติดเชื้อ infostealer

 (hudsonrock.com)
1 คะแนน โดย GN⁺ 2024-06-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 31 พฤษภาคม 2024 บริษัทคลาวด์ Snowflake เผชิญเหตุข้อมูลรั่วไหลครั้งใหญ่
  • Hudson Rock ยืนยันว่าแฮกเกอร์เข้าถึงได้ผ่านการติดเชื้อ infostealer
  • แฮกเกอร์นำข้อมูลของหลายบริษัทใหญ่ รวมถึง Ticketmaster และธนาคาร Santander ไปขายในฟอรัมอาชญากรรมไซเบอร์ภาษารัสเซีย

วิธีการแฮ็ก

  • แฮกเกอร์ล็อกอินเข้าสู่บัญชี ServiceNow ของพนักงาน Snowflake โดยใช้ข้อมูลรับรองที่ถูกขโมยมา
  • หลบเลี่ยง OKTA เพื่อสร้าง session token และขโมยข้อมูลออกไปจำนวนมาก
  • แฮกเกอร์อ้างว่ามีบริษัทได้รับผลกระทบราว 400 แห่ง

หลักฐานเพิ่มเติม

  • แฮกเกอร์แชร์ไฟล์ CSV ให้กับนักวิจัยของ Hudson Rock เพื่อแสดงสิทธิ์การเข้าถึงเซิร์ฟเวอร์ของ Snowflake
  • ไฟล์นี้บันทึกข้อมูล customer instance มากกว่า 2,000 รายการที่เกี่ยวข้องกับเซิร์ฟเวอร์ในยุโรปของ Snowflake

เป้าหมายของแฮกเกอร์

  • แฮกเกอร์เรียกร้องเงิน 20 ล้านดอลลาร์จาก Snowflake เพื่อให้ได้ข้อมูลกลับคืน
  • บริษัทไม่ได้ตอบสนองต่อเรื่องนี้

การเพิ่มขึ้นของการติดเชื้อ infostealer

  • การติดเชื้อ infostealer เพิ่มขึ้น 6000% ตั้งแต่ปี 2018 และกลายเป็นช่องทางโจมตีเริ่มต้นที่สำคัญ
  • ถูกใช้เพื่อดำเนินการโจมตีไซเบอร์ เช่น ransomware, การขโมยข้อมูล, การยึดบัญชี และการสอดแนมองค์กร

ความเห็นของ GN⁺

  • ความสำคัญของความมั่นคงปลอดภัยไซเบอร์: เหตุการณ์นี้แสดงให้เห็นว่าบริษัทต่าง ๆ ต้องให้ความสำคัญกับความมั่นคงปลอดภัยไซเบอร์มากขึ้น โดยเฉพาะการจัดการข้อมูลรับรองของพนักงาน
  • ภัยคุกคามจาก infostealer: infostealer กำลังแพร่กระจายอย่างรวดเร็วมาก และองค์กรควรเตรียมมาตรการรับมือไว้
  • กลยุทธ์การตอบสนอง: เมื่อเกิดเหตุแฮ็ก จำเป็นต้องตอบสนองอย่างรวดเร็วและมีกลยุทธ์ลดความเสียหาย โดยกรณีของ Snowflake การตอบสนองที่ล่าช้าทำให้ความเสียหายเพิ่มขึ้น
  • การอบรมด้านความปลอดภัย: การเสริมการอบรมด้านความปลอดภัยให้พนักงานเพื่อเพิ่มความตระหนักเรื่องการจัดการข้อมูลรับรองและการโจมตีแบบฟิชชิงเป็นสิ่งสำคัญ
  • โซลูชันทดแทน: อาจพิจารณาโซลูชันจัดเก็บข้อมูลบนคลาวด์อื่นที่ให้ความสามารถคล้าย Snowflake เช่น AWS S3 หรือ Google Cloud Storage

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

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

 
GN⁺ 2024-06-01
ความคิดเห็นจาก Hacker News

  • ตอนนี้ URL ที่ลิงก์อยู่ถูก 302 redirect ไปที่ / แล้ว @dang ดูเหมือนควรเปลี่ยนเป็นลิงก์ archive ด้านล่างแทน
    https://web.archive.org/web/20240531140540/https://www.hudso...

    • การเรียก @dang ไม่มีผลอะไรหรอก ติดต่อทางอีเมลใน footer น่าจะดีกว่า
      แต่การที่ Hudson Rock ถอดโพสต์บล็อกลงก็เป็นสัญญาณที่น่าสนใจ ดังนั้นจะเปลี่ยนเป็นลิงก์ archive แล้วปล่อยผ่านไปเฉย ๆ ไม่ได้ อะไรเปลี่ยนไปกันแน่?
      เพิ่มเติม: คำตอบอย่างเป็นทางการของ Snowflake ดูเหมือนจะปฏิเสธข้อกล่าวอ้างหลักของบทความต้นฉบับแทบทั้งหมด บางที Hudson Rock อาจถูกแหล่งข่าวที่ไม่ซื่อสัตย์หลอก และเมื่อรู้ว่าพลาดก็เลยถอดบทความลง
      https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

  • ผม Felipe จาก Snowflake จุดยืนล่าสุดของ Snowflake เกี่ยวกับประเด็นนี้อยู่ที่นี่: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    ถ้ามีข่าวเพิ่มเติม ผมจะอัปเดต URL นี้ต่อไป

    • ลิงก์เต็มไปด้วย ภาษาสไตล์องค์กร มากจนอยากขอเช็กให้ชัดเจน บทความของ Hudson Rock อ้างอย่างชัดเจนว่าการเจาะระบบ Ticketmaster และ Santander Bank เกิดขึ้นเพราะ credential ของพนักงาน Snowflake ถูกขโมย
      แต่ประโยคของ Snowflake ที่ว่า “คล้ายกับบัญชีลูกค้าที่ได้รับผลกระทบ เราพบหลักฐานว่าผู้ก่อภัยคุกคามได้ credential ส่วนตัวเพื่อเข้าถึงบัญชีเดโมที่เป็นของอดีตพนักงาน Snowflake ไม่มีข้อมูลอ่อนไหวอยู่ในนั้น” อ่านแล้วเหมือนหมายความว่า Snowflake มองคำอธิบายของ Hudson Rock ว่าเป็นเท็จ เข้าใจแบบนี้ถูกไหม?
    • บทความต้นฉบับของ Hudson Rock อ่านแล้วไม่ได้หมายถึงแค่ว่า credential ของลูกค้ารายหนึ่งรั่ว แต่หมายถึง credential ของพนักงานถูกขโมย และเพราะไม่มี 2FA จึงใช้สิทธิ์ของวิศวกรคนนั้นเข้าไปยังบัญชีลูกค้ารายอื่นได้
      ในทางกลับกัน บทความของ Snowflake ดูเหมือนจะบอกว่า credential ของบัญชีลูกค้ารั่ว และจบแค่นั้น ไม่มีการเข้าถึงบัญชีกลางหรือบัญชีอื่น ๆ ส่วนเรื่องการใช้ข้อมูลบัญชีพนักงานที่ไม่มี 2FA นั้นไม่ได้พูดถึงเลย
      แน่นอนว่า Snowflake ย่อมต้องการให้ credential การเข้าถึงทั้งหมดของพนักงานภายในใช้ 2FA เมื่อก่อนลูกค้าสามารถสร้างแค่ชื่อผู้ใช้/รหัสผ่านเพื่อเข้าสู่ระบบเข้าถึงข้อมูลของตัวเองได้ถ้าต้องการ และเข้าถึงได้แม้ไม่มี 2FA
    • จะมี คอมเมนต์โดยตรง ต่อบทความนี้ออกมาหรือไม่?
    • ขึ้นว่าเซิร์ฟเวอร์ salesforce.com ไม่สามารถตอบสนองคำขอได้ชั่วคราว เห็นแค่ข้อความขออภัยในความไม่สะดวกและให้ลองใหม่ภายหลัง

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

    • เป็นการเดาล้วน ๆ แต่ดูเหมือนว่าเมื่อแฮ็กเกอร์ถูก Snowflake เมิน ก็เลยติดต่อ Hudson Rock และให้ โอกาสประชาสัมพันธ์ ในการปล่อยข่าวนี้ เพื่อแก้แค้น Snowflake ที่ไม่ยอมจ่ายค่าไถ่
      Hudson Rock ดูเหมือนจะเล่นตามนั้น โดยปั้นเรื่องให้ดูเหมือนเป็นการเจาะระบบที่ใหญ่กว่าความจริง ผมยังสงสัยด้วยว่าแฮ็กเกอร์ไปหา Hudson Rock ก่อน หรือ Hudson Rock เป็นบริษัทแรกที่ยอมรับเรื่องนี้กันแน่
    • บทสนทนานั้นประหลาดและเหมือนการ์ตูนมาก ไม่รู้ควรตีความยังไง
      “พวกเขาน่าจะซื้อการป้องกันจาก Hudson Rock แล้วเรื่องนี้ก็คงป้องกันได้”
      “ใช่ มันน่าจะช่วยได้แน่นอน”
    • เป็นถ้อยคำเลี่ยง ๆ ที่พบได้บ่อยใน ransomware หรือการรีดไถค่าคุ้มครอง ข้อความที่ผมชอบในบรรดาข้อความที่กลุ่ม Akira ทิ้งไว้บนเครื่องที่ติดเชื้อ ประมาณนี้
      “ยินดีด้วย บริษัทของคุณผ่านการตรวจประเมินความปลอดภัยสารสนเทศแบบเซอร์ไพรส์ และได้กลายเป็นเหยื่อ ransomware แล้ว”
      [...]
      สิ่งที่ให้: 1) การสนับสนุนการถอดรหัสทั้งหมด 2) หลักฐานการลบข้อมูล 3) รายงานความปลอดภัยเกี่ยวกับช่องโหว่ที่พบ 4) การรับประกันว่าจะไม่เผยแพร่หรือขายข้อมูล 5) การรับประกันว่าจะไม่โจมตีในอนาคต
      สุดท้ายก็เป็นแค่บริษัทที่ปรึกษาด้านความปลอดภัยที่คุณไม่รู้ตัวว่าเอาเข้าบัญชีเงินเดือนแล้วเท่านั้นเอง
      ว่าแต่พอลองดูว่าเขาให้อะไรเป็นหลักฐานการลบข้อมูล กลายเป็นว่าเป็นแค่ stdout ของ rm -vrf data ตามตัวอักษรเท่านั้น ผมเข้าใจว่าการให้หลักฐานของสิ่งที่ไม่มีอยู่เป็นไปไม่ได้ และเหยื่อไม่มีอำนาจต่อรอง แต่ การจัดฉาก แบบนี้ผมค่อนข้างชอบ
    • ดูจากสกรีนช็อตแล้ว อันนี้ไม่ก็ปลอมขึ้นมาทั้งหมด ก็ไม่ก็ทำมาเพื่อ จุดประสงค์ทางการตลาด ล้วน ๆ
      ต่อให้เป็นของจริง ตามสามัญสำนึกก็ควรตัดข้อความของ Hudson Rock ออกไปอยู่ดี ผมใส่บริษัทนี้ไว้ใน blacklist ในหัวแล้ว
    • ฟังดูเหมือนเป็น การรีดไถ แบบนัย ๆ

  • ดูจากคำพูดของผู้ก่อเหตุเพียงอย่างเดียว ดูเหมือนว่า Snowflake จะออกแบบระบบในลักษณะที่ให้สิทธิ์เต็มทั้งหมดกับบัญชีผู้ดูแลระบบเพียงบัญชีเดียว
    การที่ Snowflake กล่าวในประกาศวันที่ 31 พฤษภาคมว่ากำลังสืบสวน “การโจมตีแบบอิงตัวตนที่เกิดขึ้นทั่วทั้งอุตสาหกรรม ซึ่งส่งผลกระทบต่อลูกค้าบางราย” ก็ยิ่งทำให้เรื่องของ Ticketmaster และ Santander ดูน่าเชื่อถือขึ้น
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    หากผู้คุกคามทำได้ถูกจุด นี่อาจกลายเป็นหนึ่งในกรณี ข้อมูลรั่วไหล ที่ใหญ่ที่สุดเท่าที่เคยมีมา

    • บทความสื่อไปในทางนั้นก็จริง แต่ดูเหมือนจะเกินจริง น่าเสียดายที่มีข้อมูลมากพอให้ระบุตัวเจ้าของข้อมูลประจำตัวที่ถูกขโมยได้ และคนคนนั้นเป็น sales engineer
      ข้อมูลน่าจะมาจากบัญชี Snowflake ของบุคคลนั้น ซึ่งใช้ทำเดโมสำหรับลูกค้าหรือว่าที่ลูกค้า เป็นไปได้ว่าลูกค้าบางรายให้สิทธิ์เข้าถึงข้อมูลจริงบางส่วนเพื่อใช้ในเดโม แต่ยังห่างไกลจากการเข้าถึงฐานข้อมูล Snowflake ของลูกค้าแบบไม่จำกัด
      มีความเป็นไปได้สูงเช่นกันว่าแฮกเกอร์ดึงข้อมูลปลอมสำหรับเดโมที่ดูสมจริงออกไป และอาจไม่รู้ความแตกต่างด้วยซ้ำ
    • ปัญหาคือ Hudson Rock ไม่รู้กระบวนการ แต่กลับคาดเดาหรือพยายามวางตัวเหมือนมีอำนาจน่าเชื่อถือ
      sales engineer หนึ่งคนดูแลหลายบัญชี โดยปกติ sales engineer ของ Snowflake ไม่ได้สร้างงานภายในสภาพแวดล้อมของลูกค้า แต่จะตั้งค่า บัญชีเดโมเครดิต 400 ดอลลาร์ ที่ใครก็สร้างได้ บัญชีเดโมจะหมดอายุเมื่อเวลาผ่านไป จึงต้องสร้างใหม่เรื่อย ๆ
      sales engineer จะสร้างงานภายในบัญชีเดโมที่ตนสร้าง แล้วนำไปแสดงให้ลูกค้าดู หลังจาก 30 วัน Snowflake จะล็อกบัญชีหากไม่มีบัตรเครดิต จากนั้นจึงลบอินสแตนซ์เดโมและข้อมูลออก
      เพื่อทำงาน ลูกค้าอาจแชร์ข้อมูลจากอินสแตนซ์ Snowflake ของตนไปยังอินสแตนซ์เดโมที่ sales engineer สร้าง หรือให้สิทธิ์เข้าถึงแก่ sales engineer ของ Snowflake คนนั้นผ่าน SSO
      ไม่ว่ากรณีใด นี่ดูใกล้เคียงกับปัญหาที่องค์กรไม่ได้ตั้งท่าความปลอดภัยให้จำกัดเพียงพอมากกว่า เป็นการโจมตีที่ไม่ได้มีอะไรใหม่ นอกจากพบ sales engineer ที่ทำงานอย่างขยันขันแข็ง กับลูกค้าที่ไม่ได้จำกัดขอบเขตสิทธิ์ของพนักงาน/ผู้รับเหมา/แขกให้เหมาะสม
    • จากประสบการณ์ที่ได้รับการสนับสนุนจาก Snowflake เมื่อประมาณหนึ่งปีก่อน หากทีม Snowflake จะดูหรือทำอะไรบางอย่าง ผู้ดูแลระบบของบัญชีลูกค้าต้องมอบ สิทธิ์เข้าถึงอย่างชัดเจน ให้ Snowflake และเท่าที่จำได้ สิทธิ์นั้นก็มีวันหมดอายุด้วย
    • หากผู้คุกคามเคลื่อนไหวได้ถูกจุด ก็มีโอกาสเป็นเหตุละเมิดข้อมูลครั้งใหญ่ที่สุดในประวัติศาสตร์
    • หมายความว่าทั้งหมดนี้เป็นไปได้ด้วยการโจมตี มัลแวร์แบบบริการ เพียงครั้งเดียวต่อพนักงานที่เหมาะสม สิ่งที่ใช้คือ Lumma
      ที่น่าสนใจคือหน้าแรกยังมีเรื่องใกล้เคียงเกี่ยวกับการใช้ Pegasus กับ NGO ในยุโรปตะวันออกด้วย หลักการให้สิทธิ์น้อยที่สุดสำคัญก็จริง แต่ความปลอดภัยของอุปกรณ์ก็สำคัญเช่นกัน
      https://news.ycombinator.com/item?id=40535912

  • ผมไม่ได้เป็นพนักงาน Snowflake แต่ทำงานร่วมกับ Snowflake และองค์กร sales engineer ของพวกเขามาเป็นเวลานาน
    เวลาทำเดโมกับลูกค้า เหล่า sales engineer จะสร้าง สภาพแวดล้อมสาธิต ด้วยบัญชีเดโม Snowflake มูลค่า 400 ดอลลาร์ที่ใครก็สร้างได้ ในการทำเดโม ลูกค้าจะให้สิทธิ์เข้าถึงแก่ sales engineer คนนั้น และ sales engineer จะนำข้อมูลบางส่วนไปยังสภาพแวดล้อมเดโมเพื่อทำงาน ชื่อสภาพแวดล้อมที่ Hudson Rock เปิดเผยก็สนับสนุนเรื่องนี้
    ในมุมมองของผม นี่เป็นปัญหากระบวนการที่ลูกค้าไม่ได้ทำให้ ID ของคนที่แชร์ข้อมูลด้วยหมดอายุ และผู้คุกคามขโมยข้อมูลประจำตัวไป ไม่ใช่การโจมตีช่องโหว่ จึงไม่มีอะไรใหม่
    และขอแสดงความยินดีกับ Hudson Rock ด้วย ที่เปิดเผยต่อสาธารณะว่าใครคือคนที่ได้รับผลกระทบเพราะมีมัลแวร์อยู่ในเครื่อง เรื่องนี้ไม่ต่างจากกรณีที่ให้ข้อมูลประจำตัวแก่ผู้รับเหมาแล้วถูกขโมยไป เป็นการกระทำที่แย่มาก

    • การที่มันไม่ใช่ “การโจมตีช่องโหว่แบบใหม่” ไม่ได้แปลว่าไม่ใช่เรื่องใหญ่
      Snowflake มีความเสี่ยงที่ข้อมูลประจำตัวของ sales engineer จะถูกขโมยได้ และข้อมูลประจำตัวนั้นสามารถข้าม การยืนยันตัวตนหลายปัจจัย ได้ อีกทั้งตามบทความบอกว่าไม่มีวันหมดอายุด้วย นี่คือสไตรก์ 1, 2, 3
      แนวปฏิบัติด้านความปลอดภัยของ Snowflake สร้างสถานการณ์ที่ลูกค้าถูกกำหนด หรืออย่างน้อยก็ถูกส่งเสริม ให้แชร์สิทธิ์เข้าถึงชุดข้อมูลขนาดกว้างแก่พนักงาน Snowflake นี่คือสไตรก์ 4
      ลูกค้าก็มีส่วนรับผิดชอบที่ให้สิทธิ์เข้าถึงกว้างเกินไป แต่ Snowflake ก็มีส่วนรับผิดชอบที่ไม่ได้สร้างระบบที่ดีกว่านี้เพื่อไม่ให้ต้องมีการเข้าถึงลักษณะนี้ หรืออย่างน้อยไม่ได้กำกับดูแลและควบคุมการเข้าถึงแบบส่งต่อเช่นนี้ให้ดีกว่านี้
      ทันทีที่บัญชีแบบนี้ได้รับสิทธิ์เข้าถึงข้อมูลลูกค้า มันก็ไม่ใช่ “บัญชีเดโม” อีกต่อไป แต่เป็นบัญชีจริง และเป็นบัญชีที่มีข้อมูลจริงซึ่งมีมูลค่าสูงมาก จึงควรถูกปฏิบัติแบบนั้น
      เพิ่มเติม: Snowflake อ้างว่าบัญชีเดโมดังกล่าวไม่ได้เข้าถึงข้อมูลลูกค้าและไม่ใช่แหล่งที่มาของการรั่วไหล ซึ่งขัดแย้งกับคำกล่าวอ้างของผู้โจมตี
    • การเอ่ยถึง ชื่อสำหรับล็อกอิน ของบัญชีที่ถูกเจาะดูไม่เป็นมืออาชีพและไม่จำเป็นจริง ๆ
    • คำอธิบายของ “Bayonet” ซึ่งเป็นหนึ่งในผลิตภัณฑ์หลักของ Hudson Rock ระบุไว้ว่า
      “ลองจินตนาการว่าคุณสามารถเข้าถึงแพลตฟอร์มหาลูกค้าเป้าหมายที่มีบริษัทที่ถูกเจาะหลายแสนแห่งทั่วโลกและมีช่องโหว่ที่ยังใช้งานอยู่ แล้วเปลี่ยนพวกเขาให้เป็นลูกค้าของคุณได้”
      ผมเคยเห็นและเคยรับมือกับบริษัทประเภทนี้มาหลายแห่ง เป็นกลยุทธ์ที่ค่อนข้างต่ำชั้น และในเชิงเทคนิคก็มีระดับทักษะหรือความพยายามต่ำ
    • ผมลองอ่านโพสต์อื่น ๆ ของ Hudson Rock แบบเร็ว ๆ หลายบทความ และหลายอันจบลงในทำนองว่า “คุณน่าจะซื้อการป้องกันจากเรา” มีกลิ่นของ ธุรกิจขายค่าคุ้มครอง
    • บล็อกโพสต์ทั้งชิ้นมีกลิ่นอายการยกยอตัวเองแบบสุดโต่ง และการเปิดเผยตัวเหยื่อก็เป็นพฤติกรรมที่เลวร้ายจริง ๆ โดยรวมแล้วผลงานของ Hudson Rock แย่มาก

  • คำตอบอย่างเป็นทางการของ Snowflake ระบุไว้ดังนี้
    “เราเห็นว่านี่เป็นผลจากการโจมตีแบบอิงตัวตนที่กำลังเกิดขึ้นทั่วทั้งอุตสาหกรรม โดยมีเจตนาเพื่อให้ได้มาซึ่งข้อมูลลูกค้า จากการสอบสวน การโจมตีเหล่านี้ดำเนินการโดยใช้ข้อมูลประจำตัวผู้ใช้ของลูกค้าที่ถูกเปิดเผยผ่านกิจกรรมภัยคุกคามไซเบอร์ที่ไม่เกี่ยวข้องกัน จนถึงขณะนี้ เรายังไม่เห็นว่ากิจกรรมนี้เกิดจากช่องโหว่ การตั้งค่าผิดพลาด หรือกิจกรรมที่เป็นอันตรายภายในผลิตภัณฑ์ของ Snowflake”
    [0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...

  • ดูเหมือนว่าบทความจะถูกตั้งเป็นส่วนตัวไปแล้ว แต่ยังเหลืออยู่ใน Wayback Machine: https://web.archive.org/web/20240531140540/https://www.hudso...

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

  • บทความนี้อ้างว่าการเจาะระบบ Ticketmaster เมื่อไม่กี่วันก่อน ที่จริงแล้วเป็นการแฮ็กที่กว้างกว่ามากซึ่งส่งผลกระทบต่อ บริษัทกว่า 400 แห่ง ผ่านข้อมูลประจำตัวที่ถูกขโมยของพนักงาน Snowflake
    ตอนนี้ดูเหมือนเป็นข่าวใหญ่ที่มีรายงานเฉพาะบน hudsonrock.com เท่านั้น ผมเพิ่งเคยได้ยินชื่อ Hudson Rock เป็นครั้งแรก มีใครรู้ไหมว่าเป็นแหล่งข่าวที่น่าเชื่อถือหรือเปล่า?

    • ผมรู้จัก Hudson Rock ครั้งแรกตอนที่ “CEO” ของพวกเขาเริ่มปล่อยสแปมบล็อกคุณภาพต่ำที่อ้างเรื่องการรั่วไหลจำนวนมากไปทั่ว subreddit ด้านความปลอดภัยเป็นเวลาหลายเดือน
      หลายบัญชีถูกผู้ดำเนินการและผู้ดูแล Reddit แบน ส่วนตัวแล้วผมไม่มองว่าเป็นแหล่งข่าวที่น่าเชื่อถือหรือไว้ใจได้
    • BBC News มีรายงานเกี่ยวกับการแฮ็กครั้งใหญ่ของธนาคาร Santander และมีการเชื่อมโยงกับ Snowflake
      https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
    • พนักงาน Snowflake ต้องซื้อเวลาให้ตัวเองขายหุ้นให้หมด ข่าวนี้จะกระแทก ราคาหุ้น SNOW อย่างหนัก

  • Snowflake ดูเหมือนจะบอกว่าไม่ใช่ความผิดของตัวเอง แต่เป็นความผิดของลูกค้า
    https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
    ถ้า https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... ไม่ใช่เรื่องที่แต่งขึ้นทั้งหมด Snowflake ก็กำลังพูดข้อเท็จจริงแบบไม่ค่อยตรงไปตรงมานัก
    ถ้อยคำว่า “จากการสอบสวน…” คลุมเครือว่าเป็นการสอบสวนของตัวเองหรือเป็นงานวิจัยด้านความปลอดภัยทั่วไป ส่วนประโยคที่ว่า “ไม่ได้เห็นว่าเกิดจากช่องโหว่ การตั้งค่าผิดพลาด หรือกิจกรรมที่เป็นอันตรายภายในผลิตภัณฑ์ของ Snowflake” ก็ไล่ระบุสถานการณ์ที่เป็นไปได้แล้วปฏิเสธ แต่เลี่ยงอย่างชำนาญว่าแท้จริงแล้วมันเกิดขึ้นได้อย่างไร
    ถ้าเชื่อ Hudson Rock ก็เป็นไปได้สูงว่า Snowflake รู้ค่อนข้างดีว่ามันเกิดขึ้นอย่างไร เพราะผู้ไม่หวังดีติดต่อไปหาพวกเขาแล้ว

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

  • บทความดูไม่ค่อยสอดคล้องกับหัวข้อที่ว่า “ลูกค้าหลายร้อยรายถูกเจาะ”
    อย่างแรก รหัสผ่าน lift/okta ดูเหมือนจะให้เข้าถึงได้แค่พอร์ทัล ServiceNow ไม่ใช่เข้าถึงบัญชีลูกค้า ดังนั้นปัญหารีเฟรชโทเคนจึงดูเหมือนจะจำกัดอยู่ที่พอร์ทัล ServiceNow และไม่น่าจะเกี่ยวข้องกับการรั่วไหลของข้อมูลในบัญชี Snowflake จริงของลูกค้า
    อย่างที่สอง ภาพหน้าจอที่บอกว่าบัญชีของ 10 บริษัทถูกเจาะ แสดงข้อมูลประจำตัวของบัญชี Snowflake ที่แตกต่างกัน 4 ชุด และหนึ่งในนั้นดูเหมือนบัญชีเดโมส่วนตัว ดังนั้นจึงอธิบายการถูกเจาะของลูกค้าได้อย่างมากประมาณ 3 ราย แต่ไม่มีรายละเอียดที่แสดงการถูกเจาะของลูกค้ารายอื่น
    ต่อให้สมมติว่าข้อมูลประจำตัวทั้งหมดของลูกค้าทุกรายที่ sales engineer ทำงานด้วยถูกเจาะ จำนวนลูกค้าที่ถูกเจาะก็น่าจะอยู่ในระดับเลขสองหลักต่ำ ๆ เพราะบัญชีของลูกค้าแต่ละรายต้องมอบสิทธิ์เข้าถึงให้ sales engineer เป็นราย ๆ ไป
    การสรุปว่าลูกค้า Snowflake ทั้งหมดถูกเจาะโดยอ้างจาก ปัญหารีเฟรชโทเคน ของพอร์ทัล Okta ภายในนั้นเป็นการกระโดดข้ามเหตุผลไปไกลมาก และปัญหานั้นก็ไม่ได้เชื่อมโยงกับบัญชี Snowflake ของลูกค้ารายใดเลย

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