Equifax 2017 — เมืองที่ผ่าน audit แต่ยังโดนปล้น#

Equifax ถ้าคุณไม่รู้จักชื่อนี้ลองนึกถึงเครดิตบูโร ในอเมริกามี 3 บริษัทใหญ่ที่เก็บประวัติเครดิตของคนทั้งประเทศ Equifax คือ 1 ใน 3 นั้น แปลว่าในเซิร์ฟเวอร์ของเขามีเลข Social Security Number (SSN คือเลขบัตรประชาชนของอเมริกัน) เลขบัตรเครดิต ประวัติเงินกู้ ของคนอเมริกันแทบทั้งประเทศ ของในเซฟของเมืองนี้คือเอกสารยืนยันตัวตนของคนทั้งชาติ ของชิ้นเดียวที่ขโมยไปแล้วซื้อบ้าน เปิดบัญชี กู้เงินในนามคนอื่นได้

Equifax เพิ่งผ่านการ audit ใหญ่หลายตัวก่อนเกิดเหตุ ทั้ง PCI DSS (Payment Card Industry Data Security Standard มาตรฐานความปลอดภัยของอุตสาหกรรมบัตรเครดิตที่ Visa/Mastercard บังคับ) ผ่าน มาตรฐานอื่นๆ ผ่าน ผู้ตรวจสอบมาดูระบบ ดูเอกสาร ดู policy แล้วเซ็นรับรองว่าโอเค เหมือนเทศบาลมาตรวจป้อมแล้วบอกว่า “กำแพงสูง ปืนใหญ่พร้อม ยามครบ ผ่าน”

แล้วเรื่องเกิดยังไง? มีนาคม 2017 มีคนค้นพบช่องโหว่ใน Apache Struts (ซอฟต์แวร์โอเพนซอร์สที่ใช้ทำเว็บแอป Equifax ใช้เว็บนี้รับเรื่อง dispute เครดิตของลูกค้า) ช่องโหว่นี้ชื่อ CVE-2017-5638 (CVE = Common Vulnerabilities and Exposures คือเลขทะเบียนช่องโหว่กลางของวงการ) ทีม Apache ออก patch ปิดช่องนี้ออกมาในวันเดียวกัน ฝ่าย IT ของ Equifax ก็รู้ ได้รับ email แจ้งเตือนภายในตามขั้นตอน

แต่ — และนี่คือคำว่า “แต่” ที่ทำเรื่องราว 147 ล้าน records — Equifax ใช้ scanner (เครื่องมือสแกนช่องโหว่อัตโนมัติ) เป็นตัวค้นหาว่าเซิร์ฟเวอร์ตัวไหนของบริษัทที่ต้องลง patch scanner ตัวที่ Equifax ใช้รุ่นเก่า + ตั้งค่าผิด ทำให้มันมองไม่เห็นเซิร์ฟเวอร์ตัวที่ดูแลระบบ dispute ทีม IT เลยเข้าใจว่า “ไม่มีเซิร์ฟเวอร์ตัวไหนต้อง patch” ก็ปล่อยไว้

2 เดือนผ่านไป โจรหาเซิร์ฟเวอร์ตัวนี้เจอ ส่ง request พิเศษเข้าไปทาง CVE-2017-5638 ระบบรับ shell command ของโจร แปลว่าโจรเข้ามาอยู่ในเครื่อง Equifax แล้ว จากตรงนั้นโจรเดินเล่นในระบบ 76 วันต่อเนื่อง เกือบ 11 สัปดาห์ ขโมยฐานข้อมูลออกมาช้าๆ ปริมาณน้อยๆ ทีละเล็กทีละน้อย ผ่าน connection ที่ดูเหมือน traffic ปกติ รวมแล้วเอาไปได้ 147 ล้าน records ทั้ง SSN วันเกิด ที่อยู่ และเลขใบขับขี่ของคนอเมริกันเกือบครึ่งประเทศ

ที่หนักกว่าคือ Equifax รู้ตัวเมื่อปลายเดือนกรกฎาคม รอบในบริษัทช่วงระหว่างที่รู้แล้วยังไม่ประกาศนั้น มีผู้บริหารบางคนขายหุ้น Equifax ออกหลายล้านดอลลาร์ก่อนข่าวออก ภายหลังโดนสอบเรื่อง insider trading CEO ลาออก CIO ลาออก CSO ลาออก รวมค่าปรับ + ค่าฟ้องร้อง + เงินชดเชยลูกค้า ทะลุ 700 ล้านดอลลาร์ และความเชื่อมั่นในชื่อ “Equifax” เสียหายชนิดที่ฟื้นไม่ได้

ลองคิดเปรียบเทียบกับป้อมปราการดู ผู้ตรวจสอบของเทศบาลเดินรอบป้อม ดูกำแพง — โอเค ดูปืนใหญ่ — โอเค ดูเอกสารยาม — โอเค ออกใบรับรอง “ป้อมนี้ผ่านมาตรฐาน” ปัญหาคือผู้ตรวจสอบมาดูในวันที่ X คืนวันที่ X+45 ฝนตกหนัก ท่อระบายน้ำที่ไม่ได้อยู่ในรายการตรวจดันแตก โจรปีนเข้าทางนั้น กระดาษรับรองจากเทศบาลที่ติดผนังป้อมไม่ได้ช่วยอะไรเลย เพราะมันคือ snapshot ภาพถ่ายของระบบในวันใดวันหนึ่ง ส่วนความปลอดภัยจริงๆ เป็น continuous เกิดขึ้นต่อเนื่องทุกวินาที

นี่คือ lesson ที่วงการเรียกว่า Compliance ≠ Security ครับ ผ่าน checklist ของผู้ตรวจ ไม่ได้แปลว่าโจรปล้นไม่ได้ หรือถ้าจะเปรียบกับชีวิตประจำวันให้เห็นชัด ผ่านแบบประเมินสุขภาพประจำปี ≠ ไม่ได้เป็นมะเร็ง แบบประเมินดูสิ่งที่อยู่ใน checklist เท่านั้น มะเร็งบางชนิดเริ่มหลัง check-up รอบที่แล้วและจะเจอตอน check-up รอบหน้า ระหว่างนั้นคุณเดินรอบเมืองอย่างมั่นใจว่าสุขภาพดี เพราะมีใบรับรอง

มุมผู้บริหาร: ถ้าวันนี้ผู้บริหารถามทีม IT ว่า “เราปลอดภัยไหม” แล้วได้คำตอบว่า “ปลอดภัยครับ เราเพิ่งผ่าน audit” นั่นคือสัญญาณเตือน ไม่ใช่คำตอบที่ปลอดภัย คำถามที่ดีกว่าคือ

• “patch ล่าสุดที่เรายังไม่ลงคือตัวไหน เพราะอะไร?”
• “scanner เราหาเซิร์ฟเวอร์เจอครบไหม รู้ได้ยังไง?”
• “เคยมี server ตัวไหนที่ทีมลืม inventory ไหม?”

สามคำถามนี้เปิดบาดแผลได้เร็วกว่ารายงาน audit หนาเป็นนิ้ว

Target 2013 — โจรเข้าทางช่างซ่อมแอร์#

เคสที่สอง Target ห้างใหญ่ของอเมริกาที่ทุกบ้านในชานเมืองไปซื้อของวันเสาร์ ปลายปี 2013 ช่วงเทศกาล Thanksgiving (ช่วงที่คนอเมริกันออกไปจับจ่ายใช้สอยเตรียมคริสต์มาส) Target โดนปล้นข้อมูลบัตรเครดิตลูกค้า 40 ล้านใบ บวกกับข้อมูลส่วนตัว (ชื่อ ที่อยู่ เบอร์ อีเมล) อีก 70 ล้าน รวมแล้วใกล้ 1 ใน 3 ของผู้ใหญ่ทั้งประเทศอเมริกาโดน

ที่น่าสนใจคือ Target ลงทุนเรื่อง security ดีมากในสายตาคนวงในตอนนั้น มี SOC (Security Operations Center คือห้องควบคุมความปลอดภัยที่มีคนนั่งดูจอ 24 ชั่วโมง) มี firewall ระดับ enterprise มีระบบเตือนภัยตัวใหม่ที่เพิ่งติดตั้งราคาหลายล้านดอลลาร์ (FireEye) แล้วโจรเข้ามาทางไหน?

โจรไม่ได้เข้ามาทางประตูหน้าของ Target โจรเข้ามาทาง Fazio Mechanical บริษัทรับติดตั้ง + ดูแลระบบทำความเย็นและเครื่องปรับอากาศ (HVAC = Heating, Ventilation, Air Conditioning) ที่ Target จ้างให้ดูแลห้างหลายร้อยสาขา Fazio เป็นบริษัทกลางๆ มีพนักงานไม่กี่สิบคน ไม่ได้มีระบบ security เทียบเท่า Target

ลำดับเหตุการณ์เป็นแบบนี้ มีนาคม 2013 Fazio Mechanical ได้รับอีเมล phishing คืออีเมลปลอมที่หลอกให้ดาวน์โหลดไฟล์อะไรสักอย่าง พนักงานคนหนึ่งของ Fazio กดเปิดไฟล์ มัลแวร์ชื่อ Citadel (ตัวที่ขโมย password จาก browser) เข้าไปอยู่ในเครื่อง มัลแวร์นั้นค่อยๆ ขโมย credential ที่ Fazio เก็บไว้ในเครื่อง รวมถึง password ที่ Fazio ใช้ login เข้าระบบ vendor portal ของ Target (Target มี portal ให้คู่ค้าใช้ส่งใบเรียกเก็บเงิน ดู work order ฯลฯ)

โจรได้ password นั้นมาก็ login เข้า portal ของ Target เลย ในมุมระบบ Target นี่คือ “Fazio login เข้ามาทำงานปกติ” จากตรงนั้น โจรหาทางขยาย access จาก vendor portal → ข้ามไปยังเครือข่ายของพนักงาน Target → ข้ามไปยังเครือข่าย POS (Point of Sale คือเครื่องคิดเงินจุดชำระ) ที่ POS นี่แหละโจรติดตั้ง BlackPOS malware (มัลแวร์ที่ดักจับข้อมูลบัตรเครดิตตอนรูดผ่านเครื่อง เพราะตอนนั้นบัตรในอเมริกายังเป็นแบบแถบแม่เหล็ก ข้อมูลอ่านออกมาเป็นตัวเลขดิบในเครื่องชั่วขณะหนึ่ง)

โจรอยู่ในระบบ POS ของ Target ราว 2 สัปดาห์ ตรงช่วง Black Friday พอดี ดักข้อมูลบัตรลูกค้าที่จ่ายเงินวันละหลายล้านใบ ส่งออกไปเก็บใน server กลางใน Target เอง แล้วทยอยส่งออกนอกบริษัทผ่าน Russia ที่น่าเศร้าคือระบบ FireEye ที่ Target เพิ่งซื้อมา มันเห็นและส่ง alert จริง แต่ทีม security ที่นั่งดูจอ ignore เพราะคิดว่าเป็น false alarm

สรุปความเสียหาย CEO + CIO ของ Target ลาออก ค่าใช้จ่ายรวมทุกอย่าง ทั้งค่าเปลี่ยนบัตรให้ลูกค้า ค่าฟ้องร้องจากธนาคาร ค่าปรับ ค่าทนาย ค่า PR ทะลุ 300 ล้านดอลลาร์ ใกล้ๆ 400 ล้าน ลูกค้าฟ้องร้องเป็น class action หลายปี และคำว่า “Target breach” กลายเป็นกรณีศึกษามาตรฐานในทุกคอร์ส cybersecurity ทั่วโลก

lesson ของเคสนี้คือ Supply chain = ด่านหน้า ความปลอดภัยของคุณ = ความปลอดภัยของ vendor ที่อ่อนแอที่สุดที่คุณเชื่อมต่อด้วย Target ลงทุน security 100 ล้านไม่ช่วย เพราะโจรไม่ได้พยายามฝ่า Target โจรฝ่า Fazio ก่อน บริษัทเล็กที่ไม่มี budget security เลย แล้วใช้ Fazio เป็นกุญแจเข้า Target โจรในยุคนี้ไม่งี่เง่า เขาไม่ปีนกำแพงสูง เขาเดินตามคนที่มีกุญแจ

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

เรื่องนี้เกี่ยวกับธุรกิจไทยยังไง? เกี่ยวมากเลย คนทำบัญชีฟรีแลนซ์ที่คุณส่งไฟล์ลูกค้า + bank statement ให้ทุกเดือน นั่นคือ vendor เอเจนซีโฆษณาที่คุณให้ admin access ของ Facebook page นั่นคือ vendor บริษัทเช่าโกดังที่ใช้ระบบ access card ร่วมกับออฟฟิศคุณ นั่นคือ vendor โปรแกรมเมอร์ outsource ที่คุณให้ access ฐานข้อมูล production นั่นคือ vendor ทุกคนคือประตูเข้าบริษัทคุณ และความสามารถ security ของพวกเขามักจะน้อยกว่าคุณ

มุมผู้บริหาร: ลองนั่งเขียนรายการ “ใครบ้างที่ตอนนี้เข้าถึงข้อมูลหรือระบบของบริษัทผมได้” เขียนทั้งหมดทุกคน ตั้งแต่พนักงานเก่าที่ออกไปแล้วแต่ลืม revoke ฟรีแลนซ์ agency vendor ที่ปรึกษา IT support บริษัทภายนอก บัญชี ทนาย ทีนี้ถามต่อทุกคน:

• “เขาใช้ password ที่ไหนอีกบ้าง?”
• “เขามี 2FA ไหม?”
• “เขาเก็บไฟล์ของเราในเครื่องตัวเอง หรือ in cloud ของใคร?”

ผมการันตีว่า list นี้ของบริษัทไทย 90% มีอย่างน้อย 3 คนที่ “ลืม revoke ตอนเลิกจ้าง” และโจรรู้ดีว่านี่คือประตูที่เปิดทิ้งไว้

Capital One 2019 — เมืองที่เช่าตึกใหม่แล้วลืมล็อกห้อง#

เคสที่สาม Capital One ธนาคารใหญ่ของอเมริกา ราว top-10 ของประเทศ ปี 2019 ข้อมูลลูกค้า 100 ล้านราย + ใบสมัครบัตรเครดิตอีก 140,000 SSN + 80,000 เลขบัญชี ถูกขโมย ที่ทำให้เคสนี้น่าสนใจไม่ใช่ตัวเลข แต่คือ “วิธีที่โจรเข้ามา” เพราะมันเปิดบทใหม่ของวงการที่เรียกว่า “cloud security”

เริ่มจากบริบทก่อน ปี 2015-2019 บริษัทใหญ่ทั่วโลกเริ่มย้ายระบบจาก data center ตัวเอง → ขึ้น cloud (AWS, Azure, GCP) Capital One เป็น 1 ใน flagship case ของ AWS ธนาคารใหญ่กล้าย้ายระบบ banking ขึ้น cloud เขียน case study ขายของกัน แปลว่าข้อมูลลูกค้า Capital One ไปอยู่ใน AWS S3 buckets (พื้นที่เก็บไฟล์บน AWS เหมือน Google Drive แต่สำหรับองค์กร) จำนวนมาก

โจรชื่อ Paige Thompson เธอเป็นอดีตวิศวกร AWS ที่ลาออกมาแล้ว แปลว่ารู้ระบบของ AWS ดีระดับลึก เธอรู้เรื่องหนึ่งที่คนทั่วไปไม่รู้ AWS มี metadata service (บริการเล็กๆ ที่อยู่ภายในเซิร์ฟเวอร์ AWS ทุกตัว ใช้บอกว่าเซิร์ฟเวอร์ตัวนี้ชื่ออะไร มี role อะไร เข้าถึงอะไรได้บ้าง เป็น API ภายในที่เซิร์ฟเวอร์ใช้คุยกับ AWS เอง) metadata service เวอร์ชันเก่า (IMDSv1) มีจุดอ่อน ถ้ามีคนนอกหลอกให้เซิร์ฟเวอร์ส่ง request ไปยัง metadata service ได้ ก็จะได้ credential ของเซิร์ฟเวอร์ตัวนั้นออกมา

นี่คือเทคนิคที่ชื่อ SSRF (Server-Side Request Forgery — การหลอกให้เซิร์ฟเวอร์ส่งคำขอออกไปยังที่อยู่ที่โจรกำหนด) ตามปกติคุณส่งคำขอเข้าไปที่เซิร์ฟเวอร์เพื่อขอข้อมูลกลับมา SSRF คือพลิกกลับ โจรหาช่องในแอปที่ให้ “เซิร์ฟเวอร์ของเป้า” เป็นคนยิงคำขอออกไป ตามที่โจรสั่ง รวมถึงยิงคำขอไปยังที่อยู่ภายในของระบบเองอย่าง metadata service

Thompson ค้นพบว่า WAF (Web Application Firewall — กำแพงไฟล์ระดับเว็บแอป) ของ Capital One ตั้งค่าผิด ทำให้เธอใช้ SSRF ผ่าน WAF ได้ ขั้นตอนคร่าวๆ คือ:

1. ส่งคำขอที่ออกแบบมาเฉพาะเข้า WAF ของ Capital One — WAF หลงเอาคำขอนี้ส่งไปคุยกับ metadata service ของตัวมันเอง
2. metadata service ตอบกลับด้วย credential ของ role ที่ WAF ใช้
3. ใช้ credential นั้น login เข้า S3 buckets ของ Capital One — เพราะ role ของ WAF ดันมีสิทธิ์อ่าน buckets เยอะเกินไป (least privilege violation)
4. ดาวน์โหลดข้อมูล 100 ล้าน records ออกมา

จุดที่หลายคนงงคือ ทำไม Thompson โดนจับ? คำตอบคือเธอโพสต์อวดบน GitHub + Slack ของกลุ่ม hacker คนคนหนึ่งเห็นโพสต์ แจ้ง Capital One ผ่าน responsible disclosure → Capital One ตรวจสอบเจอ → แจ้ง FBI → จับ Thompson ติดคุก ฝั่ง Capital One โดน OCC ปรับ $80 ล้านดอลลาร์ (2020) บวกกับยอม settle คดี class action ของลูกค้าอีก$190 ล้านดอลลาร์ (2022) และ CISO ในตอนนั้นถูกย้ายตำแหน่งหลังเหตุการณ์

lesson ของเคสนี้คือ Shared Responsibility Model โมเดล “ใครรับผิดชอบส่วนไหน” ของ cloud ที่บริษัทไทยส่วนใหญ่ไม่เข้าใจ AWS / Azure / Google Cloud ไม่ใช่ “ที่ที่ปลอดภัยอัตโนมัติ” cloud provider ดูแลความปลอดภัยของ infrastructure (datacenter ทางกายภาพ, hypervisor, network layer ลึก, hardware) แต่ลูกค้า (คุณ) ดูแลความปลอดภัยของ everything that you put on it ทั้ง config ของแอปคุณ สิทธิ์ของ role การตั้งค่า bucket password code ที่มี vulnerability

ลองนึกภาพให้ง่าย เช่าตึกใหม่ในเมือง เจ้าของตึก (cloud provider) ดูแลโครงสร้างตึกไม่พัง ลิฟต์ทำงาน ไฟติด ระบบประปา security guard ที่ล็อบบี้ตึก คุณ (tenant) ดูแลล็อกประตูห้องตัวเอง ไม่เปิดประตูให้คนแปลกหน้า อย่าทิ้งกุญแจในล็อบบี้ ถ้าคุณเช่าห้องในตึกที่ดีที่สุดของเมือง แล้วปล่อยประตูห้องเปิดทั้งคืน คุณโดนปล้น เจ้าของตึกไม่ผิด Capital One คือ tenant ที่ “ลืมล็อกประตูห้องตัวเอง” แม้ AWS จะล็อกประตูตึกให้ดีแค่ไหน

อีก lesson คือ Insider knowledge เป็นอาวุธ Thompson ไม่ใช่ random hacker เธอเคยทำงาน AWS รู้ว่าจุดอ่อนของระบบอยู่ตรงไหน ในธุรกิจคุณก็เหมือนกัน โปรแกรมเมอร์ที่เพิ่งลาออก IT support ที่เคยรู้ระบบ freelancer ที่เคยมี access ไม่ได้แปลว่าเขาทุกคนจะกลายเป็นโจร แต่ความรู้เรื่องระบบของเขาคือ asset ของฝ่ายโจมตีเสมอ เป็น pattern คลาสสิคของวงการที่คู่แข่งบางรายเคยจ้างอดีตพนักงาน IT มาเปิด backdoor ให้ เคสแบบนี้เห็นในข่าวต่างประเทศเป็นระยะ

มุมผู้บริหาร: ถ้าบริษัทคุณใช้ cloud อยู่ (อย่างน้อยใช้ Google Workspace, Microsoft 365, AWS, GCP นี่ก็ cloud หมด) ลองถามคำถามนี้

• “ใครคือคนสุดท้ายที่เช็คว่า bucket / folder ไหนใน cloud ของเราเป็น public บ้าง?”
• “พนักงานคนล่าสุดที่ลาออก เรา revoke access ใน cloud ครบไหม?”
• “role ของ admin คนไหนใน cloud ของเรามีสิทธิ์ ‘อ่าน database production’?”

3 คำถามนี้บริษัทไทย 80% ตอบไม่ได้ทันที แปลว่าตอนนี้คุณอาจจะมี bucket public ที่ลืมไว้แล้ว 2 ปี

SolarWinds 2020 — ผู้สร้างบ้านวางท่อยาพิษในทุกบ้าน#

เคสที่สี่ และเคสที่ทำให้ทุกคนในวงการ “หนาวสะท้าน” คือ SolarWinds 2020

ก่อนเล่าต้องอธิบายว่า SolarWinds คือใคร SolarWinds เป็นบริษัทซอฟต์แวร์อเมริกา ผลิตเครื่องมือชื่อ Orion software ที่ใช้ monitor ระบบ network ขององค์กร (ดูว่า server ตัวไหนช้า ตัวไหนล่ม สวิตช์ไหนหลุด) Orion ไม่ใช่ของฮิตในตลาดผู้บริโภค แต่ในตลาด enterprise มันคือ standard ลูกค้าของ SolarWinds ตอนนั้นมีกว่า 300,000 องค์กร ครอบคลุม Fortune 500 ส่วนใหญ่ + กระทรวงรัฐบาลอเมริกาหลายกระทรวง + บริษัทยักษ์ใหญ่ของวงการ tech รวมถึง Microsoft + FireEye + Cisco

ลูกค้าของ Orion ติดตั้งซอฟต์แวร์นี้ในเครือข่ายลึกที่สุดขององค์กร เพราะ Orion ต้อง “เห็น” ทุกอย่างถึงจะ monitor ได้ แปลว่า Orion มีสิทธิ์เข้าถึงสูงมากในทุกองค์กรที่ติดตั้ง

ตอนนี้มาที่ตัวร้าย APT29 (Advanced Persistent Threat 29 — ชื่อรหัสที่วงการให้กับกลุ่มแฮกเกอร์) หรืออีกชื่อ Cozy Bear เป็นกลุ่มที่ทำงานให้ SVR (Sluzhba Vneshney Razvedki — หน่วยข่าวกรองต่างประเทศของรัสเซีย) ไม่ใช่อาชีพหรือเด็กแว้น เป็น nation-state actor ระดับชาติ มีงบประมาณ มีทีม มีเวลา

ระหว่างปี 2019 ปลายปี APT29 แทรกซึมเข้าระบบของ SolarWinds เอง เข้าถึง build pipeline (สายการผลิตซอฟต์แวร์ คือระบบที่นักพัฒนาเขียน code → compile → test → เซ็น digital signature → ปล่อยเป็น update ให้ลูกค้าโหลด) โจรไม่ได้เข้าไปขโมยอะไร โจรเข้าไป ใส่ของลงไป ฝัง malware ชื่อ Sunburst เข้าไปในซอร์สโค้ดของ Orion ในจังหวะที่ build ตัว update ใหม่

ผลคือ มีนาคม 2020 SolarWinds ปล่อย Orion update เวอร์ชันใหม่ออกมาตามรอบปกติ update ตัวนี้ ผ่าน QA ของ SolarWinds ปกติ ถูกเซ็นด้วย digital signature ที่ถูกต้องของ SolarWinds เอง ทุกอย่างดู legitimate 100% ลูกค้าทั่วโลก ~18,000 รายติดตั้ง update นี้ รวมถึงกระทรวง Treasury, กระทรวง Commerce, กระทรวง State Department, กระทรวง Homeland Security ของสหรัฐ + Microsoft + FireEye + บริษัทอื่นอีกเป็นพันราย

ตรงนี้น่าสนใจ โจรไม่ได้ใช้ทุก 18,000 ราย Sunburst ใน Orion update คือ “backdoor ที่หลับอยู่” มันใช้เวลาประมาณ 2 สัปดาห์หลังติดตั้งก่อนจะเริ่มทำงาน เพื่อหลีกเลี่ยงการตรวจจับช่วงทดสอบ แล้วมันคุยกับ command-and-control server ของโจรด้วย DNS ที่ดูเหมือนชื่อเซิร์ฟเวอร์ปกติของ SolarWinds กลมกลืนสุดๆ APT29 ดูรายชื่อเหยื่อทั้ง 18,000 รายแล้ว เลือกเฉพาะที่อยากเจาะลึก น่าจะประมาณ 100 องค์กรเท่านั้น ที่เหลือปล่อยทิ้งเฉยๆ เพื่อไม่ให้สะดุดตา คุณเข้าใจไหมครับ ในมือของกลุ่มนี้ การได้ access 18,000 องค์กรทั่วโลก = “เลือกได้สบายๆ ว่าใครจะโดน”

แล้วโลกรู้เรื่องนี้ได้ยังไง? บังเอิญครับ ธันวาคม 2020 FireEye (บริษัท cybersecurity ระดับโลก ใหญ่มาก ลูกค้าเป็นรัฐบาล) ตรวจพบว่ามีคนพยายามขโมย Red Team tools ของตัวเอง ทีม FireEye สืบกลับ → เจอว่าโจรเข้ามาผ่าน Orion → แจ้ง SolarWinds → แจ้ง CISA (Cybersecurity and Infrastructure Security Agency หน่วยความปลอดภัยไซเบอร์ของรัฐบาลอเมริกา) → CISA ออกคำสั่งฉุกเฉินภายใน 24 ชั่วโมง ให้ทุกหน่วยงานรัฐบาลกลางอเมริกา disconnect Orion ทันที เป็นคำสั่งระดับ “ปลดสาย LAN เดี๋ยวนี้” ระดับฉุกเฉินที่ไม่ค่อยเกิด

ตอนรู้ตัวคือเดือนธันวาคม 2020 update ที่ฝัง Sunburst ออกตั้งแต่มีนาคม แปลว่าโจรอยู่ในระบบของกระทรวงต่างๆ อเมริกาเกือบ 9 เดือนเต็มก่อนรู้ตัว ตัวเลขนี้ในวงการเรียกว่า dwell time (เวลาที่โจรอยู่ในระบบโดยที่เจ้าของยังไม่รู้) dwell time 9 เดือนของระดับกระทรวงคืออะไรในชีวิตจริง? คือโจรอ่านอีเมลภายในของกระทรวงทุกฉบับ ดู doc ทุกชิ้น สำรวจระบบทุกซอกของ infrastructure รัฐบาลอเมริกาได้ 9 เดือนแบบไม่มีใครรู้

ค่าเสียหาย? ประเมินยากมากครับ เพราะหลายส่วนเป็น classified ของรัฐบาล แต่ค่าจัดการเหตุการณ์ (incident response) ทั่วโลก + การ rebuild ระบบที่โดนกระทบ + การสอบสวน น่าจะ เกินพันล้านดอลลาร์ เมื่อรวมทุกองค์กรเข้าด้วยกัน SolarWinds เองโดนฟ้องเป็น class action + โดน SEC สอบเรื่องเปิดเผยข้อมูลล่าช้า CEO ลาออก

lesson ของเคสนี้คือ เชื่อ vendor ไม่ได้ 100% แม้แต่ digital signature Digital signature คือกลไกที่ปกติเรา “เชื่อถือ” ได้ว่า software ตัวนี้มาจาก SolarWinds จริง ไม่ได้ถูกเปลี่ยนกลางทาง เพราะถ้าใครเปลี่ยน byte เดียว signature จะ invalid แต่ในเคสนี้ signature ถูกต้อง 100% เพราะโจรเข้าไปฝัง malware ก่อน ขั้นตอนเซ็น คือ SolarWinds เซ็นรับรอง malware เองโดยไม่รู้ตัว

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

หรือถ้าจะให้ใกล้ตัวกว่านั้น ยาที่หมอสั่ง pharmacy ส่งมาที่บ้าน ปกติเชื่อได้ไหม? เชื่อได้ ตราประทับ pharmacy ปิดผนึกเรียบร้อย ใบเสร็จมี QR ของหมอ แต่ถ้า pharmacy ถูกแฮก ยาในขวดเปลี่ยนได้โดยที่ตราประทับยังเหมือนเดิม ความเชื่อนั้น = ความเชื่อในความปลอดภัยของ pharmacy ไม่ใช่ความเชื่อในยา

นี่คือ supply chain attack ระดับชาติ เคสที่กระตุกให้ทุกองค์กรในโลกตั้งคำถามใหม่ว่า “เราเชื่อ vendor ของเราเพราะอะไร?” ถ้าคำตอบคือ “เพราะ vendor บอกว่าเขาปลอดภัย” คำตอบนี้ใช้ไม่ได้แล้วหลัง 2020

มุมผู้บริหาร: ลอง list software ทั้งหมดที่บริษัทคุณติดตั้ง ไม่ใช่แค่ที่คุณซื้อโดยตรง แต่รวม plugin / extension / library ของนักพัฒนา / SDK ที่ฝังในแอป / โอเพนซอร์สต่างๆ ทุกตัวคือ “ผู้สร้างบ้าน” คนหนึ่ง คำถามที่ต้องถาม “เกิด vendor ตัวไหนของเราถูกแฮก เรารู้ตัวภายในกี่วัน?” ถ้าคำตอบคือ “ไม่รู้” แปลว่าคุณอยู่ในตำแหน่งเดียวกับลูกค้า SolarWinds ตอนเช้าวันที่ FireEye ยังไม่ส่งจดหมายมา คือไม่รู้ว่าโดนแล้วหรือยัง

4 เคส 4 บทเรียน — pattern ที่ซ้ำกัน#

เอาล่ะ 4 เคสจบ ก่อนจะปิด EP นี้ผมอยากให้เราวางทั้ง 4 เคสเรียงกันแล้วถอยมามองภาพรวม เพราะ pattern ที่อยู่ลึกใต้ทั้ง 4 เคสนี่แหละคือสิ่งที่คุณต้องเอาไปใช้

ก่อนอื่น สรุปบทเรียนของแต่ละเคส:

• 1. Equifax — Compliance ≠ Security ผ่าน audit ผ่าน checklist ผ่านมาตรฐานสากล ไม่ได้แปลว่าโจรปล้นไม่ได้ audit เป็น snapshot, security เป็น continuous ตัวจริงที่ทำให้พังคือ patch ที่ลืมลง + scanner ตั้งค่าผิด + ขั้นตอนภายในที่ไม่ครบ ทั้งหมดนี้ checklist ไม่จับ
• 2. Target — Supply chain คือด่านหน้า firewall 100 ล้านไม่ช่วย ถ้าคู่ค้ารายเล็กของคุณโดน phishing ก่อน ความปลอดภัยของคุณ = ความปลอดภัยของ vendor ที่อ่อนแอที่สุดที่คุณเชื่อมต่อด้วย โจรไม่ปีนกำแพง โจรเดินตามคนที่มีกุญแจ
• 3. Capital One — Cloud ตั้งค่าให้ถูก + รู้ว่าคุณรับผิดชอบส่วนไหน cloud provider ดูแลตึก คุณดูแลห้อง ปล่อยประตูห้องเปิด → โดนปล้น เจ้าของตึกไม่ผิด และคนที่รู้ระบบ (insider knowledge) คืออาวุธของอีกฝั่งเสมอ
• 4. SolarWinds — เชื่อ vendor ไม่ได้ 100% แม้ digital signature ของจริงตามเอกสารทุกชิ้น ตราประทับครบ ก็ยังถูกฝัง malware ได้ ถ้าโจรเข้าถึง build server ของ vendor ก่อน ความเชื่อในยี่ห้อใหญ่ + ความเชื่อในเอกสารทางการ ไม่ใช่ control ที่แท้จริง

ทีนี้ ถ้าคุณเรียง 4 เคสนี้แล้วถามว่า “จุดร่วมคืออะไร” ผมอยากให้สังเกต 3 จุด

จุดร่วมที่ 1 — ไม่มีเคสไหนเกิดจาก “โจรเก่งกว่าระบบ” ทั้ง 4 เคสเกิดจาก mindset ที่ผิดของบริษัท ทั้งหมด Equifax คิดว่า audit = ปลอดภัย Target คิดว่า security คือเรื่องของตัวเองคนเดียว Capital One คิดว่าใส่ของขึ้น cloud แล้วปลอดภัยอัตโนมัติ SolarWinds (และ 18,000 ลูกค้า) คิดว่า digital signature = เชื่อได้ โจรไม่ได้เก่งกว่า โจรแค่ใช้ประโยชน์จาก mindset ผิดของอีกฝั่ง

จุดร่วมที่ 2 — dwell time ยาวมากทุกเคส Equifax 76 วัน Target ~3 สัปดาห์ที่ดักข้อมูล (แต่อยู่ในระบบนานกว่านั้น) Capital One หลายเดือน SolarWinds 9 เดือน นี่คือตัวเลขที่ผู้บริหารต้องจำ โจรในเคสจริง ไม่ใช่ “เข้ามาแล้วขโมยรีบหนีในชั่วโมงเดียว” แบบในหนัง โจรอยู่ในระบบเป็นเดือนเป็นปี ค่อยๆ สำรวจ ค่อยๆ ขยาย ค่อยๆ ขโมยเงียบๆ คำถามไม่ใช่ “เราป้องกัน 100% ไหม” คำถามคือ “ถ้าโจรอยู่ในระบบเราตอนนี้ เราจะรู้ตัวภายในกี่วัน?”

จุดร่วมที่ 3 — “ของแพง” ไม่ช่วย ถ้า “พื้นฐาน” ไม่ครบ Equifax มี budget security ใหญ่ แต่ scanner ตั้งค่าผิด + patch ไม่ลง Target มี FireEye ตัวใหม่ราคาหลายล้าน แต่ทีม SOC ignore alert Capital One มี WAF ระดับ enterprise แต่ตั้งค่า role IAM ผิด + bucket S3 เปิดอ่านกว้างเกิน SolarWinds ลูกค้าทั้ง 18,000 ราย มี firewall + EDR + SIEM ครบหมด ไม่ช่วย เพราะ malware มาผ่าน update ที่ “ถูกเชื่อใจ” จาก vendor ของแพงไม่ใช่คำตอบ กระบวนการ + ความเข้าใจพื้นฐาน + การตั้งคำถามที่ถูก = คำตอบ

มุมผู้บริหาร: 4 เคสนี้รวมเป็นคำถามเดียวที่ผู้บริหารต้องถามทีม IT “ถ้า vendor หรือ component ตัวใดตัวหนึ่งของเราถูกแฮกพรุ่งนี้ เราจะรู้ตัวภายในกี่วัน?” ถ้าตอบไม่ได้ทันที ไม่ใช่ความผิดทีม แต่แปลว่าบริษัทยังไม่ได้วาง process ที่จะมีคำตอบ นั่นคือจุดเริ่มต้น

สรุป — 4 เมืองที่ถูกปล้น 4 รูปแบบ#

ถ้าให้สรุป EP นี้เป็นภาพเดียว เมืองในประวัติศาสตร์ cybersecurity ที่ถูกปล้นชื่อดังที่สุด 4 เมือง ไม่ได้พังเพราะกำแพงไม่สูงพอ ไม่ได้พังเพราะปืนใหญ่ไม่แพงพอ พังเพราะ mindset ที่ผิดของเจ้าเมือง — เชื่อใบรับรองมากเกิน เชื่อคู่ค้ามากเกิน เชื่อ cloud มากเกิน เชื่อ vendor มากเกิน — และโจรเข้ามาทางช่องว่างระหว่างความเชื่อเหล่านั้น

Equifax เชื่อว่าผ่าน audit = ปลอดภัย → โจรเข้าทาง patch ที่ลืมลง Target เชื่อว่าระบบของตัวเองแน่น → โจรเข้าทางช่างซ่อมแอร์ที่โดน phishing Capital One เชื่อว่า cloud ปลอดภัยเอง → โจรเข้าทาง role ที่ตั้งค่าผิด SolarWinds (และลูกค้า 18,000 ราย) เชื่อว่า digital signature = เชื่อได้ → โจรเข้าทาง build server ของ vendor ก่อนถึงขั้นตอนเซ็น