- Cloudflare ประกาศว่าได้ตรวจพบผู้ก่อภัยคุกคามบน เซิร์ฟเวอร์ Atlassian ที่โฮสต์เองเมื่อวันที่ 23 พฤศจิกายน 2023 แต่ข้อมูลลูกค้า·ระบบลูกค้า·ระบบและการตั้งค่าเครือข่ายทั่วโลกไม่ได้รับผลกระทบ
- เส้นทางการบุกรุกคือ access token 1 รายการและข้อมูลประจำตัวของ service account 3 รายการที่ไม่ได้ถูกหมุนเวียนหลังเหตุ Okta ถูกละเมิด ในเดือนตุลาคม 2023 โดยการเข้าถึงมุ่งไปที่สภาพแวดล้อม Atlassian เช่น Jira, Confluence, Bitbucket
- ผู้ก่อภัยคุกคามทำการลาดตระเวนและเข้าถึงเอกสารภายในระหว่างวันที่ 14–17 พฤศจิกายน จากนั้นในวันที่ 22 พฤศจิกายนติดตั้ง Sliver ผ่าน ScriptRunner for Jira เพื่อคงการเข้าถึงอย่างต่อเนื่อง
- Cloudflare ตอบสนองแบบ “Code Red” โดยหมุนเวียนข้อมูลประจำตัว production มากกว่า 5,000 รายการ คัดกรองและตรวจพิสูจน์ทางนิติวิทยาศาสตร์ 4,893 ระบบ และ reimage·reboot เครื่องทั้งหมดในเครือข่ายทั่วโลกและผลิตภัณฑ์ Atlassian
- การสอบสวนอิสระของ CrowdStrike ไม่พบกิจกรรมที่ตกหล่น และยืนยันหลักฐานกิจกรรมของผู้ก่อภัยคุกคามครั้งสุดท้ายเมื่อวันที่ 24 พฤศจิกายน 2023 เวลา 10:44 UTC
ภาพรวมเหตุการณ์และขอบเขตผลกระทบ
- Cloudflare ตรวจพบผู้ก่อภัยคุกคามบน เซิร์ฟเวอร์ Atlassian ที่โฮสต์เองเมื่อวันที่ 23 พฤศจิกายน 2023
- ทีมความปลอดภัยเริ่มการสอบสวนทันทีและบล็อกการเข้าถึง
- วันที่ 26 พฤศจิกายน ได้เรียกทีม forensic ของ CrowdStrike เข้ามาทำการวิเคราะห์อิสระ
- เหตุการณ์ครั้งนี้ ข้อมูลลูกค้าหรือระบบลูกค้า ไม่ได้รับผลกระทบ
- บริการไม่ได้เกี่ยวข้องกับเหตุการณ์
- ไม่มีการเปลี่ยนแปลงระบบหรือการตั้งค่าเครือข่ายทั่วโลก
- การควบคุมการเข้าถึง กฎ firewall และ hardware security key ที่บังคับใช้ด้วยเครื่องมือ Zero Trust ของตนเองช่วยจำกัดการเคลื่อนย้ายด้านข้าง
- ขอบเขตการเข้าถึงของผู้ก่อภัยคุกคามจำกัดอยู่ที่ Atlassian Confluence ซึ่งเป็นวิกิภายใน, Jira ฐานข้อมูลบั๊ก, Bitbucket ระบบจัดการซอร์สโค้ด และเซิร์ฟเวอร์ที่รัน Atlassian
ข้อมูลประจำตัวที่ใช้ในการบุกรุก
- การบุกรุกเริ่มจาก service token 1 รายการและ service account 3 รายการ ที่รั่วไหลหลังเหตุ Okta ถูกละเมิด ในเดือนตุลาคม 2023 แต่ไม่ได้ถูกหมุนเวียน
- Moveworks service token: ใช้สำหรับเข้าถึงระบบ Atlassian จากระยะไกล
- Smartsheet service account: มีสิทธิ์ผู้ดูแลระบบบนอินสแตนซ์ Atlassian Jira
- Bitbucket service account: ใช้สำหรับเข้าถึงระบบจัดการซอร์สโค้ด
- บัญชีสภาพแวดล้อม AWS: ไม่มีสิทธิ์เข้าถึงเครือข่ายทั่วโลก ข้อมูลลูกค้า หรือข้อมูลอ่อนไหว
- token และบัญชีดังกล่าวถูกประเมินผิดว่าไม่ได้ใช้งาน จึงหลุดจากรายการที่ต้องหมุนเวียน
- Cloudflare ระบุชัดเจนว่านี่ไม่ใช่ความผิดพลาดของ Atlassian, AWS, Moveworks หรือ Smartsheet แต่เป็นผลจากการที่ Cloudflare ไม่สามารถหมุนเวียนข้อมูลประจำตัวได้
ไทม์ไลน์การโจมตี
- ตั้งแต่วันที่ 14 พฤศจิกายน เวลา 09:22:49 ผู้ก่อภัยคุกคามเริ่มสำรวจระบบและลาดตระเวน
- ความพยายามล็อกอินเข้าอินสแตนซ์ Okta ถูกปฏิเสธ
- การเข้าถึง Cloudflare Dashboard ก็ถูกบล็อกเช่นกัน
- เข้าถึงสภาพแวดล้อม AWS ที่ขับเคลื่อน Cloudflare Apps marketplace ได้ แต่สภาพแวดล้อมนี้ถูกแยกออกจากเครือข่ายทั่วโลกและข้อมูลลูกค้า
- วันที่ 15 พฤศจิกายน เวลา 16:28:38 เข้าถึง Atlassian Jira และ Confluence ได้สำเร็จ
- ผ่านเกตเวย์ด้วย Moveworks service token และเข้าถึงชุดผลิตภัณฑ์ Atlassian ด้วย Smartsheet service account
- ค้นหาในวิกิด้วยคำว่า remote access, secret, client-secret, openconnect, cloudflared, token เป็นต้น
- เข้าถึง Jira ticket 36 รายการจากทั้งหมด 2,059,357 รายการ และหน้า wiki 202 หน้าจากทั้งหมด 194,100 หน้า
- Jira ticket ที่เข้าถึงมีรายการเกี่ยวกับการจัดการช่องโหว่ การหมุนเวียน secret การ bypass MFA การเข้าถึงเครือข่าย และการตอบสนองต่อเหตุ Okta
- วันที่ 16 พฤศจิกายน เวลา 14:36:37 ใช้ข้อมูลประจำตัว Smartsheet สร้างบัญชี Atlassian ที่ดูเหมือนผู้ใช้ Cloudflare ทั่วไป และเพิ่มเข้าหลายกลุ่ม
- เป็นมาตรการเพื่อให้ยังเข้าถึงสภาพแวดล้อม Atlassian ต่อไปได้ แม้ Smartsheet service account จะถูกลบออก
- ตั้งแต่วันที่ 17 พฤศจิกายน เวลา 14:33:52 ถึงวันที่ 20 พฤศจิกายน เวลา 09:26:53 การเข้าถึงระบบ Cloudflare หยุดลง ยกเว้นการทดสอบเข้าถึงสั้น ๆ
- วันที่ 22 พฤศจิกายน เวลา 14:18:22 ใช้สิทธิ์ผู้ดูแล Jira ของ Smartsheet service account เพื่อติดตั้ง Sliver Adversary Emulation Framework ผ่านปลั๊กอิน ScriptRunner for Jira
- Sliver เป็นเครื่องมือและเฟรมเวิร์กที่ red team และผู้โจมตีใช้สำหรับ C2, การเชื่อมต่อ และการเข้าถึงอย่างต่อเนื่องแบบลับ ๆ
- สิ่งนี้ทำให้เข้าถึงเซิร์ฟเวอร์ Atlassian ได้อย่างต่อเนื่องและพยายามเคลื่อนย้ายด้านข้าง
- ความพยายามเข้าถึง non-production console server ในดาต้าเซ็นเตอร์ที่ São Paulo, Brazil ซึ่งยังไม่ได้เข้าสู่ production ล้มเหลว
การเข้าถึงซอร์สโค้ดและเอกสาร
- หลังวันที่ 22 พฤศจิกายน ผู้ก่อภัยคุกคามดู code repository 120 รายการ จากทั้งหมด 11,904 รายการภายในหนึ่งวัน
- ในจำนวนนี้ repository 76 รายการถูกดาวน์โหลดไปยังเซิร์ฟเวอร์ Atlassian โดยใช้ฟังก์ชัน git archive ของ Atlassian Bitbucket
- Cloudflare ไม่สามารถยืนยันได้ว่ามีการรั่วไหลออกภายนอกหรือไม่ แต่ตอบสนองโดยถือว่ารั่วไหลแล้ว
- repository 76 รายการส่วนใหญ่เกี่ยวข้องกับด้านต่อไปนี้
- วิธีการทำงานของ backup
- การตั้งค่าและการจัดการเครือข่ายทั่วโลก
- ระบบ identity ของ Cloudflare
- การเข้าถึงระยะไกล
- การใช้งาน Terraform และ Kubernetes
- repository บางรายการมี secret ที่เข้ารหัสอยู่ และ Cloudflare หมุนเวียนทันทีแม้จะถูกเข้ารหัสอย่างแข็งแรงแล้วก็ตาม
- Cloudflare เน้นตรวจสอบ secret ที่ฝังอยู่ ในโค้ด ช่องโหว่ และเส้นทางที่อาจถูกใช้ในการโจมตีภายหลัง มากกว่าตัวซอร์สโค้ดเอง
- Cloudflare อธิบายว่าบริษัทได้เปิดซอร์สโค้ดจำนวนมากเป็นโอเพนซอร์ส และได้กล่าวถึงอัลกอริทึมและเทคนิคที่ใช้ผ่านบล็อกอย่างเปิดเผยมาโดยตลอด
การตรวจจับและการบล็อก
- วันที่ 23 พฤศจิกายน เวลา 16:00 ทีมความปลอดภัยได้รับการแจ้งเตือนเกี่ยวกับการมีอยู่ของผู้ก่อภัยคุกคาม
- 15:58: ผู้ก่อภัยคุกคามเพิ่ม Smartsheet service account เข้าในกลุ่มผู้ดูแลระบบ
- 16:00: การแจ้งเตือนอัตโนมัติเกี่ยวกับการเปลี่ยนแปลงดังกล่าวถูกส่งไปยังทีมความปลอดภัย
- 16:12: Cloudflare SOC เริ่มสอบสวน
- 16:35: ปิดใช้งาน Smartsheet service account
- 17:23: พบบัญชีผู้ใช้ Atlassian ที่ผู้ก่อภัยคุกคามสร้างและปิดใช้งาน
- 17:43: ประกาศ incident ภายใน Cloudflare
- 21:31: ใช้กฎ firewall เพื่อบล็อกที่อยู่ IP ที่ทราบของผู้ก่อภัยคุกคาม
- วันที่ 24 พฤศจิกายน ยืนยันกิจกรรมครั้งสุดท้ายและการลบ Sliver
- 10:44: กิจกรรมผู้ก่อภัยคุกคามที่ทราบครั้งสุดท้าย
- 11:59: ลบ Sliver
- ผู้ก่อภัยคุกคามพยายามเข้าถึงระบบหลากหลาย เช่น metrics ภายใน การตั้งค่าเครือข่าย ระบบ build ระบบแจ้งเตือน ระบบจัดการ release แต่ไม่สำเร็จ
- ไม่พบหลักฐานการเข้าถึงเครือข่ายทั่วโลก ดาต้าเซ็นเตอร์ SSL key ฐานข้อมูลหรือข้อมูลการตั้งค่าของลูกค้า Cloudflare Workers โมเดล AI โครงสร้างพื้นฐานเครือข่าย หรือ data store เช่น Workers KV, R2, Quicksilver
การตอบสนอง “Code Red” และงานเสริมความแข็งแกร่ง
- หลังจากนำผู้ก่อภัยคุกคามออกจากสภาพแวดล้อมเมื่อวันที่ 24 พฤศจิกายน Cloudflare ระดมบุคลากรทั่วบริษัทเพื่อสอบสวนการบุกรุกและยืนยันขอบเขตการเข้าถึง
- ตั้งแต่วันที่ 27 พฤศจิกายน บุคลากรเทคนิคจำนวนมากทั้งในและนอกทีมความปลอดภัยมุ่งเน้นไปที่โปรเจกต์ Code Red
- เสริมความแข็งแกร่ง·ตรวจสอบ·แก้ไขการควบคุมของสภาพแวดล้อมเพื่อรับมือการบุกรุกในอนาคต
- ตรวจสอบว่าผู้ก่อภัยคุกคามไม่สามารถเข้าถึงต่อไปได้
- ตรวจสอบระบบ บัญชี และ log ทั้งหมดเพื่อยืนยันว่ามีการเข้าถึงอย่างต่อเนื่องหรือไม่ และเข้าถึงหรือพยายามเข้าถึงสิ่งใด
- มาตรการหลักมีดังนี้
- หมุนเวียนข้อมูลประจำตัว production มากกว่า 5,000 รายการ
- แยกระบบทดสอบและ staging ทางกายภาพ
- คัดกรองและตรวจพิสูจน์ทางนิติวิทยาศาสตร์ 4,893 ระบบ
- reimage และ reboot เครื่องทั้งหมดในเครือข่ายทั่วโลก
- reimage และ reboot ผลิตภัณฑ์ Atlassian ทั้งหมด เช่น Jira, Confluence, Bitbucket
- อุปกรณ์ในดาต้าเซ็นเตอร์ São Paulo ถูกส่งคืนให้ผู้ผลิต
- ทีม forensic ของผู้ผลิตตรวจสอบว่ามีการเข้าถึงหรือการสร้าง persistence หรือไม่
- ไม่พบสิ่งใด แต่ Cloudflare เปลี่ยนฮาร์ดแวร์ใหม่
- นอกจากนี้ยังตรวจสอบแพ็กเกจซอฟต์แวร์ที่ไม่ได้อัปเดต บัญชีผู้ใช้ที่อาจถูกสร้างขึ้น บัญชีพนักงานที่ยังใช้งานอยู่แต่ไม่ได้ใช้ secret ที่อาจหลงเหลือใน Jira ticket หรือซอร์สโค้ด และไฟล์ HAR ที่อัปโหลดในวิกิ
- ไฟล์ HAR ถูกลบเผื่อกรณีมี token รวมอยู่
- งาน Code Red แบบเร่งด่วนสิ้นสุดเมื่อวันที่ 5 มกราคม 2024 แต่การปรับปรุงการจัดการข้อมูลประจำตัว การเสริมความแข็งแกร่งซอฟต์แวร์ การจัดการช่องโหว่ และการปรับปรุงการแจ้งเตือนเพิ่มเติมยังคงดำเนินต่อไป
การสอบสวนของ CrowdStrike และ IOCs
- CrowdStrike ประเมินขอบเขตกิจกรรมของผู้ก่อภัยคุกคามและหลักฐาน persistence อย่างเป็นอิสระ
- ไม่พบกิจกรรมที่การสอบสวนของ Cloudflare พลาดไป
- สรุปว่าหลักฐานกิจกรรมของผู้ก่อภัยคุกคามครั้งสุดท้ายคือวันที่ 24 พฤศจิกายน 2023 เวลา 10:44 UTC
- จากความร่วมมือกับเพื่อนร่วมอุตสาหกรรมและหน่วยงานรัฐ Cloudflare ประเมินว่าการโจมตีครั้งนี้ดำเนินการโดย ผู้โจมตีที่ได้รับการสนับสนุนจากรัฐ ซึ่งพยายามเข้าถึงเครือข่ายทั่วโลกของ Cloudflare อย่างต่อเนื่องและกว้างขวาง
- Cloudflare เปิดเผย indicators of compromise เพื่อให้องค์กรอื่นที่อาจได้รับผลกระทบจากเหตุ Okta ถูกละเมิดสามารถตรวจสอบ log ได้
193.142.58[.]126: โครงสร้างพื้นฐานหลักของผู้ก่อภัยคุกคาม เป็นของ M247 Europe SRL198.244.174[.]214: เซิร์ฟเวอร์ Sliver C2 เป็นของ OVH SASidowall[.]com: โครงสร้างพื้นฐานสำหรับส่ง Sliver payloadjvm-agent: ชื่อไฟล์ Sliver payload, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เพราะ การวิเคราะห์และการตอบสนองอย่างเปิดเผย แบบนี้ของ Cloudflare ผมเลยมองว่าสามารถฝากข้อมูลและธุรกิจของผมไว้กับเขาได้
แม้จะไม่ได้สมบูรณ์แบบ และมีเรื่องที่ผมไม่เห็นด้วยอยู่บ้าง แต่ด้วย แนวคิดแบบวิศวกรรม ที่ถูกแชร์ทั่วทั้งบริษัท และท่าทีที่จริงจังกับเรื่องแบบนี้ ทำให้รู้สึกว่าเชื่อถือได้
เป็นวิธีเน้นย้ำว่าตัวเองมีความซื่อตรงสูงกว่าคู่แข่ง และแชร์การตรวจสอบด้านปฏิบัติการบางส่วนหลังเหตุการณ์ความปลอดภัยล่าสุด
แต่ Cloudflare ไม่ได้ให้การวิเคราะห์ความเสี่ยง SOC ในฐานะผู้ประมวลผลบัตรชำระเงินตาม PCI/DSS และไม่ได้อธิบายว่าทำไมจึงพลาดบัญชีที่ถูกยกระดับสิทธิ์ หรือบัญชีเหล่านั้นถูกเจาะตั้งแต่แรกได้อย่างไร อธิบายแค่ remediation มากกว่าความรับผิดชอบ
มีการพูดถึงการตรวจสอบโดยบุคคลที่สาม แต่นั่นไม่ใช่เพราะคำนึงถึงผู้ใช้ หากเป็นเพราะ PCI/DSS กำหนดให้องค์กรที่ข้อมูลบัตรชำระเงินถูกละเมิดต้องถูกตรวจสอบหน้างานทุกปี ไม่อย่างนั้นบริษัทบัตรรายใหญ่คงระงับการประมวลผลชำระเงินไปแล้ว
คำพูดที่ว่าไม่ได้สูญเสียอะไรเลยนั้นเชื่อได้ยาก และ Jira/Confluence ส่วนใหญ่ที่ผมเคยเห็นมีข้อมูลลับเต็มไปหมด
จากข้อความที่ว่า “เมื่อวิเคราะห์หน้า wiki, issue ในฐานข้อมูลบั๊ก และคลังซอร์สโค้ดที่ถูกเข้าถึง ดูเหมือนว่ากำลังมองหาข้อมูลเกี่ยวกับสถาปัตยกรรม ความปลอดภัย และการจัดการของเครือข่ายทั่วโลก” วิธีที่ง่ายที่สุดสำหรับผู้ปฏิบัติการระดับรัฐคือการส่งพลเมืองที่ภักดีเข้าไปเป็นพนักงานของบริษัทเป้าหมาย แล้วให้คนนั้นส่งข้อมูลดังกล่าวกลับมา
มีเรื่องเล่าน่าสนใจแต่ไม่แน่ชัดว่าเป็นจริงไหมว่า เมื่อกว่า 10 ปีก่อน ในงานสังสรรค์ของ SRE ที่ Google มีบางคนยอมรับว่ารับเงินเดือนจากหน่วยข่าวกรองของประเทศตัวเอง
ถ้าไม่ใช่ ก็สงสัยว่ามียาแรงแค่ไหนในงานสังสรรค์นั้น ถึงเกิด ความล้มเหลวด้านความปลอดภัยของปฏิบัติการ ที่ร้ายแรงขนาดนั้นได้
ชาวออสเตรเลียได้รับ “โอกาส” ให้เข้าร่วมกิจกรรมสายลับแบบนั้นราวกับเป็นเงื่อนไขพื้นฐานของการเป็นพลเมือง https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
ถ้าจะมีข้อดีก็คือ มันอาจช่วยบังคับแนวปฏิบัติที่ดีในการพัฒนากระบวนการและระบบแบบ zero trust ได้
จากส่วนที่ว่า “เราเป็นเหยื่อของการละเมิดระบบ Okta เป็นครั้งที่สอง” ทำให้สงสัยว่า Cloudflare กำลัง ทบทวนการใช้งาน Okta อยู่หรือเปล่า
Okta ก็ควรถูกวิจารณ์ แต่กรณีนี้ให้ความรู้สึกว่า Cloudflare กำลังโยนความรับผิดลงไปข้างล่างเพื่อกลบความผิดพลาดของตัวเอง
ผมยังใช้ MacBook เก่าที่ได้รับมาตั้งแต่ “ยุคแรก ๆ” อยู่ จึงไม่มีซอฟต์แวร์จัดการเลย ตอนนั้นยังไม่มีฝ่าย IT และผมก็ได้รับแล็ปท็อปใหม่เอี่ยมที่ไม่ได้ถูกแตะต้องมาเฉย ๆ
บริษัทเสนอจะอัปเกรดเป็น M1/M2 Pro ให้ แต่ผมปฏิเสธ เพราะถ้ามีรหัสผ่านหรือคีย์ส่วนตัวแม้แต่อันเดียวบนคอมพิวเตอร์ที่ใช้ทำงาน ผมก็ไม่อยากใช้ระบบล็อกอินของ Okta
ดังนั้นผมคงอัปเกรดไม่ได้จนกว่าจะกระทบงานอย่างหนัก บางทีอาจใช้เหตุการณ์แบบนี้เป็นเหตุผลต่อฝ่าย IT เพื่อสนับสนุนความคิดของผมได้
ข้อความที่ว่า “โทเคนบริการหนึ่งตัวและบัญชีสามบัญชีไม่ได้ถูก rotate เพราะเราเข้าใจผิดว่าไม่ได้ใช้งาน” ฟังดูแปลก ถ้าไม่ได้ใช้แล้ว ทำไมไม่ทิ้งไปเลย?
น่าจะมีอะไรบางอย่างหายไป หรือหล่นหายระหว่างการสื่อสาร แต่ถ้าดูตามประโยคตรง ๆ ก็ไม่ค่อยเข้าใจ
ตัวอย่างเช่น บัญชีบริการนั้นอาจถูกทำเครื่องหมายไว้ที่ไหนสักแห่งในฐานข้อมูลว่าอยู่ในสถานะไม่ใช้งาน เช่น “เลิกใช้แล้ว” หรือ “ล้างแล้ว” แต่เครื่องหมายนั้นผิด ดังนั้นรหัสผ่านของบัญชีที่ใช้งานอยู่ทั้งหมดจึงถูก rotate แต่บัญชีที่ถูกมองว่าไม่ใช้งานถูกข้ามไป
ถ้าพิจารณาเฉพาะบริบทของโครงสร้างพื้นฐานกุญแจสาธารณะและการเพิกถอนใบรับรองที่ผมคุ้นเคยดี การปล่อยให้ใบรับรองหมดอายุ การทำเครื่องหมายว่า “ไม่ใช้งานแล้ว” และการเพิกถอนอย่างสมบูรณ์นั้นต่างกันพอสมควร ในกรณีแรก CA ไม่ต้องทำอะไรเลย กรณีที่สองอาจไม่ทำอะไรหรืออาจเพิกถอนก็ได้ ส่วนกรณีที่สามต้องดูแลและเผยแพร่รายการเพิกถอนอย่างจริงจัง ถ้ามีคนบอกว่า “ผมเผลอเขียนทับ private key ไป ขอใบรับรองสำหรับคีย์ใหม่หน่อย” โดยทั่วไปก็ไม่ได้เอาใบรับรองเก่าไปใส่ในรายการเพิกถอน
การเขียนชัด ๆ ว่า “นี่ไม่ใช่ความผิดของ AWS, Moveworks หรือ Smartsheet แต่อย่างใด เป็นเพียง credentials ที่เราไม่ได้ rotate” เป็นการชี้ประเด็นที่ดี
Cloudflare เชื่อว่าการเข้าถึงของผู้โจมตีมีขอบเขตจำกัด และแม้ภายหลังจะยืนยันได้เช่นนั้นแล้ว ก็ยัง หมุนเวียนข้อมูลรับรองสำหรับโปรดักชันมากกว่า 5,000 รายการ ทั้งหมด แยกระบบทดสอบ·สเตจจิงออกจากกันทางกายภาพ ตรวจสอบเชิงนิติวิทยาศาสตร์ 4,893 ระบบ และรีอิมเมจ·รีบูตเครื่องทุกเครื่องในเครือข่ายทั่วโลก
แม้ความพยายามเข้าถึงคอนโซลเซิร์ฟเวอร์ของดาต้าเซ็นเตอร์ São Paulo ที่ยังไม่ได้ถูกนำเข้าโปรดักชันจะล้มเหลว แต่ก็ส่งอุปกรณ์ของดาต้าเซ็นเตอร์ในบราซิลกลับไปให้ผู้ผลิตทำฟอเรนสิก และแม้ไม่พบอะไรเลยก็ยังเปลี่ยนฮาร์ดแวร์
จริง ๆ อาจไม่จำเป็นต้องทำถึงขนาดนี้ และจะเลือกไม่ทำก็ง่าย แต่การที่ทำจริงก็น่าชื่นชม
การเจาะเข้ามาใน ช่วงเริ่มต้น ของการสร้างดาต้าเซ็นเตอร์ใหม่ แทบจะเป็นเอ็กซ์พลอยต์ขั้นสุดยอด ลองนึกภาพว่าเข้าไปอยู่กลาง Meet-Me room ใหม่(https://en.wikipedia.org/wiki/Meet-me_room) แล้วได้สิทธิ์เข้าถึง core switch อย่างต่อเนื่อง
ดาต้าเซ็นเตอร์ของ Cloudflare มักเป็นฮับของทราฟฟิกข้อมูลปริมาณมหาศาล การที่ผู้โจมตีรู้คุณค่าของดาต้าเซ็นเตอร์ “ก่อนโปรดักชัน” น่าจะหมายความว่า Cloudflare เองก็ตระหนักว่า หากมีจุดยืนเกิดขึ้นที่นั่นก่อนระบบความปลอดภัยปกติจะพร้อม ก็เท่ากับจบเกม 100% หากมีใครปักหลักในดาต้าเซ็นเตอร์ที่กำลังสร้าง·กำลังเปิดใช้งานได้สำเร็จ นั่นอาจเป็นเหตุการณ์ที่ทำให้บริษัทจบได้
ต้องจำไว้ด้วยว่าในช่วงต้นของการสร้างดาต้าเซ็นเตอร์ สวิตช์และอุปกรณ์ทั้งหมดมักใช้ค่าเริ่มต้นหรือรหัสผ่าน root ว่างเปล่า(admin/admin) และเฟิร์มแวร์ก็เก่า มีช่องโหว่มาก หากการโจมตีแบบนี้เกิดขึ้นก่อนที่ระบบอัตโนมัติจะอัปเดตแพตช์เฟิร์มแวร์ทั้งหมด นี่ก็เป็นเหตุการณ์ระดับ “ส่งอุปกรณ์ทั้งหมดคืน แล้วให้ผู้ผลิตส่งของใหม่มา”
หากสมมติว่าผู้โจมตีเข้าถึงได้เฉพาะขอบเขตที่พิสูจน์ได้ ก็เท่ากับเหลือช่องให้ผู้โจมตีรอดอยู่ได้ ถ้าจะบอกว่าไม่จำเป็นต้องทำสิ่งนี้ ควรต้องได้รับอนุมัติจากองค์ประชุมหลายคน
แน่นอนว่านี่เป็นเรื่องของโลกอุดมคติ ผมถือว่าโชคดีที่ทีมของเรายังได้รับเวลาให้ทำฟีเจอร์ที่ไม่ได้ให้ผลประโยชน์ทางการเงินหรือผู้ใช้โดยตรง
การเตรียมพร้อมให้สามารถหมุนเวียนข้อมูลรับรองแบบนี้ได้ต้องอาศัยวินัยและการเตรียมตัว และพูดตามตรง ทีมส่วนใหญ่ไม่ได้ลงทุนตรงนี้ แม้แต่ทีมที่ฉลาดและมีทรัพยากรมากก็เช่นกัน
ถ้าทีมความปลอดภัยของ Cloudflare ตัดสินใจได้ว่าจะหมุนเวียน secret ทั้งหมดและรีอิมเมจเครื่องทุกเครื่อง และเรื่องนั้นเกิดขึ้นจริงภายในเวลาที่สมเหตุสมผล ก็ถือว่าน่าประทับใจทีเดียว
† https://twitter.com/badthingsdaily?lang=en
ส่วนที่น่าประหลาดใจที่สุดตรงนี้คือ Cloudflare ใช้ Bitbucket
เมื่อข้อมูลรั่วออกไปแล้ว ในกรณีนี้ ซอร์สโค้ด ก็เหมือนอยู่นอกบ้านถาวร และคุณควบคุมไม่ได้เลยว่าใครจะเอาไป
หลังเหตุการณ์จะเสริมความแข็งแกร่งเท่าไรก็ทำได้ และจะพูดถึงมันมากแค่ไหนก็ได้ แต่สิ่งที่พยายามป้องกันได้เกิดขึ้นไปแล้ว ไข่ที่ตีแตกไปแล้วเอากลับคืนไม่ได้
ในโค้ดเก่า ๆ ยังอาจพบอีสเตอร์เอ็กอื่น ๆ ได้ด้วย แทบทุกบริษัทมี backdoor ที่ไม่ได้ทำเอกสารไว้
การรั่วไหลของข้อมูลลูกค้านั้นแย่กว่า แต่เรื่องนี้ก็แย่มากเหมือนกัน
ข้อมูลลูกค้าปีหน้าก็ไม่เหมือนข้อมูลลูกค้าปีนี้
ใน Confluence ของ Atlassian แค่ Apache Lucene search engine ในตัวก็อาจทำให้ข้อมูลอ่อนไหวรั่วได้ และการเข้าถึงแบบนี้อาจติดตาม·ระบุได้ยากมาก
หากข้อมูลอ่อนไหวแสดงอยู่บนหน้าผลการค้นหาแล้ว ผู้โจมตีก็ไม่จำเป็นต้องเปิดหน้า Confluence ด้วยซ้ำ
ประโยคที่ว่า “ไม่ได้หมุนเวียน service token หนึ่งรายการและบัญชีสามบัญชี เพราะเข้าใจผิดว่าไม่ได้ใช้งาน” ฟังดูแปลก ข้อมูลรับรองที่ไม่ได้ใช้งาน น่าจะควรถูกลบ ไม่ใช่หมุนเวียน
สถานการณ์ประมาณว่า “บัญชีพวกนี้คืออะไร?” “อ๋อ ไม่ได้ใช้แล้ว ในล็อกก็ไม่มี” “ยังไงก็ต้องหมุนเวียนนะ” “ไม่ล่ะ ปล่อยบัญชีสุ่ม ๆ ที่มีข้อมูลรับรองเก่าซึ่งอาจถูกเจาะไว้เถอะ… เหตุผลก็มีประมาณหนึ่ง” หรือเปล่า?
ถ้าหมุนเวียนข้อมูลรับรองที่รั่วหลังเหตุการณ์ Okta แล้ว ผมว่าควรตั้ง honeypot ไว้บนข้อมูลนั้น แล้วรอดูว่าผู้โจมตีจะทำอะไร
honeypot ยังมีผลทำให้ผู้โจมตีไม่กล้าดำเนินการต่อ เพราะกลัวถูกจับได้