4 · เมื่อโครงสร้างเป็นซอฟต์แวร์
ภาคนี้เปลี่ยนวัสดุ และสิ่งที่เปลี่ยนไปพร้อมกับวัสดุคือการทำสำเนา สะพานที่ออกแบบผิดหนึ่งแห่งถล่มหนึ่งแห่ง ส่วนโค้ดที่เขียนผิดหนึ่งบรรทัดเดินทางไปถึงทุกเครื่องที่ติดตั้งมัน เพราะข้อบกพร่องในซอฟต์แวร์คัดลอกได้โดยไม่มีต้นทุน จุดอ่อนจุดเดียวจึงถูกส่งออกไปพร้อมกันเป็นพันล้านสำเนา และคนที่หาเจอคนแรกได้ทั้งพันล้านนั้นไปในคราวเดียว
ตัวเลขที่ภาคนี้ตามมีตัวเดียว — ข้อบกพร่องมีอยู่นานเท่าไรก่อนมีคนใช้มัน ในสิบสี่กรณีข้างล่าง คำตอบวัดเป็นปีเกือบทุกครั้ง ไม่ใช่วันหรือสัปดาห์ และช่องว่างนั้นเองคือเรื่องของภาคนี้
ก่อนเริ่ม มีข้อตกลงเรื่องตัวเลขหนึ่งข้อ ตัวเลขเงินในวงการนี้เป็นตัวเลขที่เชื่อถือได้น้อยที่สุดบนหน้ากระดาษ จำนวนบันทึกที่รั่วใกล้เคียงการตรวจสอบ ระยะเวลาที่ผู้โจมตีอยู่ในระบบมาจากไทม์ไลน์นิติวิทยาศาสตร์และใช้ได้ แต่ตัวเลขดอลลาร์เกือบทั้งหมดคือแถลงข่าว คำฟ้อง หรือการเดาของนักวิเคราะห์ที่ถูกเล่าซ้ำจนแข็ง เล่มนี้พิมพ์ทั้งตัวเลขที่บริษัทเปิดเผยเองและตัวเลขพาดหัว และบอกว่าอันไหนเป็นอันไหน ตัวเลขดังหลายตัวที่เล่ากันติดปากจะไม่อยู่ในหน้าถัดไป และทุกครั้งจะมีหนึ่งบรรทัดบอกว่าทำไมมันหายไป
Multics · 1974
ในปี 1974 ถ้าถามว่าระบบปฏิบัติการที่มั่นคงที่สุดในตลาดคือตัวไหน คำตอบที่วงการให้ตรงกันมีชื่อเดียวคือ Multics และคำถามที่ศูนย์ข้อมูลของกองทัพอากาศในชั้นใต้ดินเพนตากอนอยากได้คำตอบก็ตรงไปตรงมา — Multics บนเครื่อง Honeywell HIS 645 และ HIS 6180 รับงาน Secret กับ Top Secret บนเครื่องเดียวกันได้หรือไม่
เดือนมิถุนายน 1974 กองทัพอากาศสหรัฐตีพิมพ์คำตอบในรายงาน ESD-TR-74-193 เล่มที่สอง ผู้เขียนคือ Paul Karger และ Roger Schell และคำตัดสินคือรับรองให้ใช้กับงานสองระดับชั้นความลับไม่ได้
ทีมพบข้อบกพร่องสามชั้น ฮาร์ดแวร์ ซอฟต์แวร์ และขั้นตอนปฏิบัติ ในชั้นซอฟต์แวร์มีโมดูลที่ออกแบบให้ทำงานในระดับผู้ใช้ แต่กลับทำงานด้วยสิทธิ์ระดับระบบ นี่คือรายงานเจาะระบบปฏิบัติการเชิงพาณิชย์ฉบับแรกที่ตีพิมพ์โดยละเอียด ไม่ใช่การเจาะระบบครั้งแรก ทีมแบบนี้มีมาตั้งแต่ปลายทศวรรษ 1960 สิ่งที่ใหม่คือมีคนพิมพ์วิธีการออกมาให้คนนอกอ่าน
แต่รายการข้อบกพร่องไม่ใช่ส่วนที่สำคัญที่สุด และผู้เขียนทั้งสองเขียนไว้เองในบทย้อนหลังปี 2002 ว่ามันเป็นครึ่งเล็กของผลลัพธ์ ครึ่งใหญ่คือการสาธิตว่ากลไกป้องกันถูกล้มได้ด้วยซอฟต์แวร์ที่ตั้งใจหลอกมัน — trap door และ Trojan horse ความต่างนี้สำคัญเพราะมันเปลี่ยนว่าอะไรคือทางแก้ แพตช์ปิดข้อบกพร่องที่หาเจอแล้ว มันไม่ได้ปิดช่องทางที่ยังไม่มีใครไปหา ข้อสรุปของรายงานจึงไม่ใช่รายการแพตช์ แต่คือคำว่าต้องรื้อโครงสร้างใหม่รอบแกนความมั่นคงที่พิสูจน์ได้ ก่อนใช้ระบบใดในสภาพแวดล้อมเปิดที่มีมืออาชีพเป็นศัตรู
วิธีที่ทีมใช้พิสูจน์ข้อนั้นคือสิ่งที่ทำให้กรณีนี้ยังมีค่าอยู่จนวันนี้ พวกเขาไม่ได้แค่หาข้อบกพร่อง พวกเขาปลูกมันด้วย trap door ตัวหนึ่งถูกฝังในเครื่อง 645 และไม่เคยถูกแจกจ่าย เพราะเครื่องรุ่นนั้นกำลังถูกปลด ตัวที่สองถูกฝังในระบบพัฒนาของเครื่อง 6180 ที่ MIT จากจุดนั้นมันไม่ต้องทำอะไรเลย มันแค่เดินทางไปตามเส้นทางปกติที่ซอฟต์แวร์ทุกตัวเดิน ฝ่ายควบคุมคุณภาพของ Honeywell ตรวจไม่พบ และ Honeywell ส่งมันไปกับซอฟต์แวร์ถึงเครื่องของกองทัพอากาศเอง
ตัวเลขของกรณีนี้อยู่ตรงนี้ trap door ตัวที่สองอยู่รอดราวหนึ่งปีหลังรายงานตีพิมพ์ ทั้งที่รายงานพิมพ์คำใบ้ตำแหน่งของมันไว้ในมาตรา 3.4.6 มันถูกพบระหว่างการตรวจสอบเข้มที่ศูนย์ Multics ของ General Motors เมื่อรุ่นที่ถูกถอดเขี้ยวแล้วคืนค่าข้อผิดพลาดแปลกออกมา ห่างจากการทำงานจริงหนึ่งคำสั่ง อ่านลำดับนั้นอีกรอบแล้วจะเห็นว่าอะไรล้มเหลว คำเตือนถูกพิมพ์ไว้แล้ว พร้อมที่อยู่ของสิ่งที่ต้องไปดู และยังไม่พอให้ใครไปหา
มาตรา 3.2.4 ของรายงานฉบับเดียวกันทำนาย trap door ไว้สามแบบ ในสายแจกจ่ายซอฟต์แวร์ ในขั้นติดตั้ง และใน compiler ที่ฝัง trap door ลงในทุกอย่างที่มันแปล ปี 1974 ทั้งสามข้อยังเป็นคำทำนาย ไม่ใช่รายงานเหตุการณ์
สิ่งที่กรณีนี้สอน: ทดสอบกลไกป้องกันด้วยการปลูกของปลอมลงไปเองแล้วนับวัน จนกว่าฝ่ายควบคุมคุณภาพจะเจอ — ตัวเลขที่ได้คือส่วนเผื่อจริง ไม่ใช่ใบรับรอง
Trusting Trust · 1984
ข้อที่ Ken Thompson ขึ้นไปพังบนเวทีรับรางวัล Turing คือข้อที่ฟังดูไม่มีอะไรให้เถียง ถ้าอยากรู้ว่าโปรแกรมตัวหนึ่งทำอะไร ก็เปิด source ออกมาอ่าน เดือนสิงหาคม 1984 Communications of the ACM ฉบับที่ 27(8) พิมพ์ปาฐกถานั้นยาวสามหน้า หน้า 761 ถึง 763 และจำนวนเครื่องที่เสียหายจากมันคือศูนย์
กรณีนี้อยู่ในภาคเพราะมันไม่มีผู้เสียหาย ข้ออ้างของ Thompson ไม่ใช่ว่า compiler มีบั๊กได้ ทุกคนรู้อยู่แล้วว่ามีได้ มันคือโครงสร้างสามขั้นที่ทำให้การอ่านไร้ความหมาย ขั้นแรก สอน binary ของ compiler ให้จำโปรแกรม login ได้ และใส่ทางลับลงไปเมื่อแปลมัน ขั้นสอง สอนมันให้จำตัวเองได้ และใส่พฤติกรรมทั้งสองกลับเข้าไปใน compiler ทุกตัวที่มันแปล ขั้นสาม ลบ source ส่วนที่เป็นพิษทิ้ง
จากจุดนั้นทุกอย่างที่ตรวจได้ก็สะอาดหมด source ของ compiler สะอาด source ของ login สะอาด compiler ทุกตัวที่สร้างจาก source สะอาดถือข้อบกพร่องต่อไป และการอ่าน source กี่รอบก็ไม่เจอ เพราะสิ่งที่ต้องอ่านไม่ได้อยู่ในสิ่งที่อ่านได้ ประโยคสรุปของเขา: คุณไว้ใจโค้ดที่คุณไม่ได้สร้างเองทั้งหมดไม่ได้ อ่าน source ไม่เท่ากับไว้ใจโปรแกรม เพราะโปรแกรมมาจากเครื่องมือ และเครื่องมือสร้างตัวเองซ้ำ
ที่มาของความคิดมักถูกเล่าผิด และคนที่เล่าถูกที่สุดคือ Thompson เอง เขาเขียนว่าได้แนวคิดจากเอกสารกองทัพอากาศที่ไม่ทราบชื่อ และขอให้ใครก็ได้ช่วยหาที่อ้างอิงที่ดีกว่า Karger และ Schell บันทึกว่าเอกสารนั้นคือรายงาน Multics ของพวกเขาเองปี 1974 พวกเขาส่งสำเนาให้เขาหลังปาฐกถาตีพิมพ์ และ Thompson แก้ที่อ้างอิงในฉบับพิมพ์ซ้ำใน Unix Review เดือนพฤศจิกายน 1989 ความคิดเป็นของปี 1974 การสาธิตและชื่อเสียงเป็นของปี 1984 ส่วนที่ว่า compiler ตัวนั้นเคยถูกใช้นอก Bell Labs หรือไม่ มีคนยืนยันทั้งสองทาง และเล่มนี้ยืนยันไม่ได้
คำถามประจำภาค — ข้อบกพร่องมีอยู่นานเท่าไรก่อนถูกใช้ — ตอบแบบเดิมไม่ได้ในกรณีนี้ เพราะสิ่งที่ Thompson ชี้ไม่ใช่ข้อบกพร่องที่ถูกเพิ่มเข้าไปวันหนึ่ง เงื่อนไขที่เขาอธิบายคือการไว้ใจ binary ของเครื่องมือ และมันมีมาตั้งแต่ compiler เริ่มแปลตัวเอง การอ่านตรวจแก้มันไม่ได้ วิธีรับมือมาถึงยี่สิบเอ็ดปีให้หลัง David A. Wheeler เสนอ Diverse Double-Compiling ตรวจ binary ของ compiler เทียบกับ binary ที่สร้างจาก source เดียวกันด้วย compiler อิสระอีกตัว ปี 2023 Russ Cox สร้างการโจมตีต้นฉบับของ Thompson ขึ้นใหม่และรันมันได้ สี่สิบปีจากคำเตือนถึงการยืนยันว่ามันทำงานจริง
ในแง่สันของเล่ม นี่คือกรณีที่ศัตรูไม่ได้อ่านแบบก่อสร้าง เขาอ่านเครื่องมือที่ใช้อ่านแบบ
สิ่งที่กรณีนี้สอน: เมื่อตรวจ source ให้ถามต่อว่าใครตรวจ compiler ที่แปลมัน และตรวจด้วย compiler ตัวไหน
หนอน Morris · 2 พฤศจิกายน 1988
อินเทอร์เน็ตปี 1988 มีเครื่องต่ออยู่ราว 60,000 เครื่อง และทุกเครื่องใช้ข้อสมมติเดียวกันข้อหนึ่งโดยไม่มีใครเขียนมันลงไปที่ไหน ว่าเครื่องอีกฝั่งของสายไม่ใช่ศัตรู ข้อสมมตินั้นไม่ได้อยู่ในเอกสาร มันอยู่ในบริการเครือข่ายที่ทุกผู้ขายส่งมาพร้อมระบบ
ค่ำวันที่ 2 พฤศจิกายน 1988 โปรแกรมตัวเดียวทำให้เครื่องราว 6,000 จากราว 60,000 เครื่องนั้น — ราวสิบเปอร์เซ็นต์ — หยุดทำงานภายในยี่สิบสี่ชั่วโมง ผู้ปล่อยคือ Robert Tappan Morris นักศึกษาปริญญาโทของ Cornell จากเครื่องที่ MIT
มันไม่ใช่การขโมยข้อมูล มันคือ denial of service โดยไม่ตั้งใจ เครื่องที่ถูกติดเชื้อซ้ำหลายรอบรับภาระจนหยุดเดิน ทางเข้ามีสองทางและทั้งสองทางเคยถูกเรียกว่าคุณสมบัติ ฟังก์ชัน debug ที่ถูกเปิดทิ้งไว้ในระบบจริง กับรูทีนรับข้อมูลที่ไม่จำกัดความยาว แยกกันมันคือความสะดวกสองอย่าง รวมกันมันคือการสั่งรันโค้ดจากระยะไกลบนอินเทอร์เน็ตเกือบทั้งหมด
ตัวเลขความเสียหายมีสองแบบ และแบบที่ตรงกว่าคือแบบที่ดูเหมือนตอบไม่ได้ GAO ประเมินค่าฟื้นฟูไว้ระหว่าง 100,000 ถึง 10,000,000 ดอลลาร์ ช่วงกว้างร้อยเท่า และช่วงนั้นเองคือผลการวัดที่ตรงที่สุด เพราะไม่มีใครวัดได้ ส่วนตัวเลข 100 ล้านดอลลาร์ที่เล่าต่อกันมาจนติดปาก ไม่มีแหล่งต้นทาง มันดูเหมือนเพดานของ GAO ที่ถูกเติมศูนย์อีกสองตัว เล่มนี้จึงไม่พิมพ์มันเป็นข้อเท็จจริง
สิ่งที่ตามมาหลังคืนนั้นมีสองอย่างที่อยู่คนละระนาบกัน อย่างแรกคือกฎหมาย Morris เป็นคนแรกที่ถูกตัดสินว่าผิดตาม Computer Fraud and Abuse Act ปี 1986 วันที่ 4 พฤษภาคม 1990 ผู้พิพากษา Howard G. Munson ให้รอลงอาญาสามปี บริการชุมชน 400 ชั่วโมง ปรับ 10,050 ดอลลาร์ ไม่มีโทษจำคุก ศาลอุทธรณ์ยืนคำตัดสินในปี 1991
อย่างที่สองคือสถาบัน และมันเกิดขึ้นภายในไม่กี่สัปดาห์ CERT/CC ที่ Software Engineering Institute ของ Carnegie Mellon ด้วยทุนจาก DARPA มันเป็นจุดประสานงานกลางแห่งแรกสำหรับเหตุฉุกเฉินบนเครือข่าย เหตุผลที่ต้องมีเรียบง่ายกว่าที่ควรจะเป็น คืนนั้นไม่มีใครมีเบอร์โทรให้โทรหา
ข้อบกพร่องสองข้ออยู่ในโค้ดที่ส่งมอบแล้วมาหลายปี ผู้ปฏิบัติงานรู้จักมันในฐานะความสะดวก ไม่ใช่ช่องโหว่ ตัวเลขปีที่แน่นอนของแต่ละข้อ การค้นคว้าครั้งนี้ยืนยันไม่ได้ ในแง่สันของเล่ม ข้อสมมติว่าปลายสายเป็นมิตรคือส่วนเผื่อที่ไม่เคยถูกวัดกับใครเลย จนกระทั่งมีคนวัด
สิ่งที่กรณีนี้สอน: ไล่รายการความสะดวกที่ยังเปิดอยู่ในระบบจริง — โหมด debug บัญชีทดสอบ ช่องรับข้อมูลที่ไม่จำกัดขนาด — แล้วถามทีละข้อว่าถ้าปลายสายเป็นศัตรู มันคืออะไร
Phrack 49 · 1996
ก่อนเดือนพฤศจิกายน 1996 โปรแกรมที่พังเพราะรับข้อมูลยาวเกินเป็นเรื่องน่ารำคาญ ไม่ใช่เรื่องความมั่นคง การเขียนเลย stack เป็นเรื่องเล่าในวงเล็กๆ และเป็นบั๊กความไม่เสถียรสำหรับคนที่เหลือ คนเขียนโปรแกรมส่วนใหญ่รู้ว่ามันทำให้โปรแกรมพัง และหยุดคิดตรงนั้น
วันที่ 8 พฤศจิกายน 1996 Phrack ฉบับที่ 49 ไฟล์ที่ 14 จาก 16 พิมพ์บทความของ Aleph One (Elias Levy) และจำนวนผู้เสียหายจากบทความนั้นคือศูนย์ มันเป็นเอกสาร
สิ่งที่บทความตั้งชื่อคือประเภทของข้อบกพร่อง และการตั้งชื่อคือทั้งหมดของเรื่อง โปรแกรมที่เขียนเลยขอบของ buffer ทำลายบันทึกที่บอกว่าจะกลับไปทำงานต่อที่ไหนได้ ถ้าบันทึกนั้นถูกทำลายได้ มันก็ถูกเลือกค่าให้ได้ ประเภทของข้อบกพร่องจึงไม่ใช่โปรแกรมพัง แต่คือผู้โจมตีเลือกได้ว่าอะไรจะรันต่อ เล่มนี้บันทึกแค่นั้น ไม่มีเทคนิค ไม่มีโค้ด โดยตั้งใจ
หลังบทความ มันเป็นประเภทที่มีชื่อ สอนได้ ทำซ้ำได้ มีคำศัพท์มาตรฐาน สอนผู้โจมตีได้ และที่ส่งผลมากกว่า สอนผู้ป้องกันได้ แนวป้องกันที่ตามมาเป็นเส้นตรง StackGuard canary ปี 1998 ASLR ของ PaX ปี 2001 Windows /GS ปี 2003 บิต NX / DEP ในฮาร์ดแวร์ปี 2004 สังเกตว่าทุกชิ้นตอบบทความ ไม่ได้ตอบเหตุการณ์ ไม่มีภัยพิบัติไหนอยู่ระหว่างปี 1996 กับ StackGuard มีแต่คนอ่านหนังสือ
ระยะเวลาที่ข้อบกพร่องมีอยู่ก่อนถูกใช้ กลับด้านในกรณีนี้ ประเภทนี้ถูกใช้จริงแปดปีก่อนบทความ — ทางเข้าทางหนึ่งของหนอน Morris ปี 1988 คือมัน ความเชื่อว่าบทความนี้สร้าง buffer overflow ขึ้นมา จึงตายในการค้นคว้า ปี 1996 ไม่ได้ทำให้มันมีอยู่ มันทำให้ทุกคนได้อ่าน และข้ออ้างนั้นใหญ่กว่าคำว่าประดิษฐ์
มีข้อเทียบที่ไม่สบายใจอยู่ข้อหนึ่ง Karger และ Schell บันทึกในบทย้อนหลังปี 2002 ว่า Multics ต้านข้อบกพร่องประเภทนี้ทั้งประเภทได้ตั้งแต่ปี 1974 เพราะบิตสิทธิ์ execute ในฮาร์ดแวร์ทำให้หน้าข้อมูลถูกรันเป็นคำสั่งไม่ได้ การป้องกันมาก่อนการแพร่กระจายยี่สิบสองปี แล้วหายไปจากระบบที่ต้องการมัน เหตุผลไม่ใช่ว่าใครลืม แต่เพราะระบบเหล่านั้นเลือกสถาปัตยกรรมฮาร์ดแวร์ที่พูดเรื่องนี้ไม่ได้ ของที่จะกลับมาได้ต้องรอฮาร์ดแวร์รุ่นที่พูดได้ และมันมาถึงปี 2004
ในแง่สันของเล่ม บทความคือวันที่ผู้โจมตีทุกคนได้อ่านแบบก่อสร้างชุดเดียวกัน ส่วนเผื่อที่เคยเป็นความไม่รู้ หมดอายุในวันนั้น
สิ่งที่กรณีนี้สอน: เมื่อบั๊กประเภทหนึ่งได้ชื่อและมีบทความสอน ให้นับวันนั้นเป็นวันแรกที่ระบบของคุณถูกอ่าน แล้วไล่ดูว่าการป้องกันที่ตามมาแต่ละชิ้นเปิดอยู่บนเครื่องของคุณหรือไม่
SQL injection และ Heartland · 1998 และ 2008
หน้าเว็บที่รับข้อความจากผู้ใช้แล้วส่งต่อให้ฐานข้อมูล เป็นของธรรมดามาตั้งแต่เว็บเริ่มทำอะไรได้มากกว่าแสดงเอกสาร และคนที่เขียนมันคิดว่าข้อความที่ผู้ใช้พิมพ์คือค่าหนึ่งค่าในคำสั่ง วันที่ 25 ธันวาคม 1998 Phrack ฉบับที่ 54 ไฟล์ที่ 8 พิมพ์บทความของ rain.forest.puppy (Jeff Forristal) ที่อธิบายว่ามันไม่ใช่ ข้อความจากผู้ใช้ที่ไปถึงฐานข้อมูลโดยไม่ถูกกรอง เปลี่ยนโครงสร้างของคำสั่งได้ ไม่ใช่แค่ค่าในคำสั่ง เก้าปีต่อมา ข้อบกพร่องประเภทเดียวกันเปิดทางให้บันทึกบัตร 130 ล้านรายการถูกเข้าถึง
Forristal ไม่ได้ใช้คำว่า SQL injection ชื่อนั้นมาทีหลัง สิ่งที่เขาบรรยายคือหน้าเว็บบน ASP ที่ต่อกับ SQL Server 6.5 และรับข้อความจากผู้ใช้ไปต่อเข้าคำสั่งฐานข้อมูลตรงๆ ตั้งแต่วันคริสต์มาสนั้น ประเภทของข้อบกพร่องนี้เป็นสาธารณะ ใครก็อ่านได้ ทั้งคนที่ต้องปิดมันและคนที่ต้องการใช้มัน
Heartland Payment Systems เป็นผู้ประมวลผลการชำระเงินใหญ่อันดับห้าของสหรัฐ ตามคำฟ้องของกระทรวงยุติธรรม การบุกรุกเครือข่ายเริ่มอย่างช้าที่สุดวันที่ 26 ธันวาคม 2007 Visa แจ้งเตือน Heartland เรื่องความเคลื่อนไหวผิดปกติของบัตรปลายเดือนตุลาคม 2008 บริษัทประกาศต่อสาธารณะวันที่ 20 มกราคม 2009 ราวสิบสามเดือนโดยไม่มีใครเห็น และคนที่เห็นก่อนบริษัทคือ Visa
ทางเข้าคือ SQL injection สู่เครือข่ายสำนักงาน การเก็บเกี่ยวทำด้วยตัวดักฟังที่วางไว้บนเครือข่ายประมวลผล และมันทำงานอยู่หลายเดือน ระหว่างสองขั้นนั้นมีข้อสมมติหนึ่งข้อที่ไม่มีใครตรวจ ต้นเหตุในหนึ่งประโยค แอปพลิเคชันหน้าเว็บต่อข้อความที่ไม่น่าไว้ใจเข้าคำสั่งฐานข้อมูล และเครือข่ายสำนักงานที่มันอยู่ไม่ได้แยกจากเครือข่ายที่ถือข้อมูลบัตรจริง วันที่ SQL injection สำเร็จครั้งแรก แยกจากวันเข้าเครือข่ายในคำฟ้อง การค้นคว้าครั้งนี้หาไม่พบ
ตัวเลข 130 ล้านคือจำนวนบันทึกบัตรที่ถูกเข้าถึงตามคำฟ้อง ไม่ใช่จำนวนบัตรที่ถูกใช้ทุจริต รายงานร่วมสมัยบางฉบับใช้ "ถึง 100 ล้าน" ตัวเลขแข็งอยู่ในรายงานต่อ ก.ล.ต. ของบริษัทเอง เพราะบริษัทโกหกตัวเลขในรายงานนั้นไม่ได้ Heartland บันทึกค่าใช้จ่าย 146.4 ล้านดอลลาร์ระหว่างมกราคม 2009 ถึงมีนาคม 2011 ได้คืนจากประกัน 31.2 ล้าน ราว 114.7 ล้านเป็นเงินยอมความ Visa 58.6 ล้าน จ่ายวันที่ 18 กุมภาพันธ์ 2010 MasterCard 34.4 ล้าน เดือนกันยายน 2010 American Express ราว 3.5 ล้าน Albert Gonzalez ถูกฟ้องเดือนสิงหาคม 2009 และรับโทษจำคุกยี่สิบปี
เก้าปี ธันวาคม 1998 ถึงธันวาคม 2007 ระหว่างการตีพิมพ์ประเภทของข้อบกพร่องกับการรั่วของบัตรครั้งใหญ่ที่สุดที่เคยบันทึกในเวลานั้น ผู้โจมตีอ่านบทความฉบับเดียวกับผู้ป้องกัน ต่างกันที่ฝ่ายหนึ่งลงมือ
สิ่งที่กรณีนี้สอน: เขียนปีที่ข้อบกพร่องประเภทนั้นถูกตีพิมพ์ครั้งแรกไว้ข้างช่องโหว่ทุกช่องที่กำลังปิด — ตัวเลขนั้นคือจำนวนปีที่ผู้โจมตีมีมากกว่าคุณ
Stuxnet · 2010
ในช่วงพฤศจิกายน 2009 ถึงปลายมกราคม 2010 เครื่องหมุนเหวี่ยง IR-1 ถึงราวหนึ่งพันเครื่องที่โรงงานเสริมสมรรถนะ Natanz ถูกเปลี่ยนออก ตลอดช่วงเวลานั้น จอของผู้ควบคุมอ่านค่าปกติ และมันอ่านค่าปกติเพราะมีคนตั้งใจให้มันอ่านอย่างนั้น
สิ่งที่ในที่สุดทำให้เรื่องนี้ถูกพบไม่ใช่หน่วยข่าวกรองไหน วันที่ 17 มิถุนายน 2010 บริษัทแอนติไวรัสเล็กๆ ในมินสค์ชื่อ VirusBlokAda พบมัลแวร์ตัวหนึ่งจากคำร้องเรียนของลูกค้าเรื่องเครื่องรีบูตเองโดยไม่มีสาเหตุ นักวิเคราะห์ที่พบคือ Sergey Ulasen ปฏิบัติการเดินมาอย่างน้อยตั้งแต่ปี 2009
ตัวเลขหนึ่งพันมาจากสถาบัน ISIS เดือนธันวาคม 2010 คำที่สถาบันใช้คือเสียหายและถูกเปลี่ยน ราวสิบเปอร์เซ็นต์ของเครื่องที่เดินอยู่ คำว่าถูกทำลายเป็นคำที่นิยมเล่า และอาจเกินแหล่งต้นทาง รายงานของ Symantec สืบต้นทางการติดเชื้อไปถึงห้าองค์กร ทุกแห่งเกี่ยวข้องกับโครงการนิวเคลียร์ของอิหร่าน
มันใช้ zero-day ของ Windows สี่ตัว ช่องโหว่ในไฟล์ shortcut ในระบบพิมพ์ และช่องยกระดับสิทธิ์อีกสอง ตัวเลขห้าที่เล่าต่อกันมาผิด และความผิดของมันไม่ใช่เรื่องเลขคลาดเคลื่อนหนึ่งหน่วย ช่องที่ห้าคือ MS08-067 ที่มีแพตช์มาตั้งแต่ปี 2008 และถูกเลือกเพราะมันเก่า ด้วยเหตุผลว่าเครือข่ายควบคุมอุตสาหกรรมแพตช์ช้า บันทึกน้อย และป้องกันเบา พูดอีกอย่างคือผู้เขียนมัลแวร์งบประมาณช่องโหว่ที่รู้กันแล้วไว้ใส่จุดอ่อนของสถาบันที่รู้กันแล้ว นั่นคือข้อเท็จจริงที่น่าสนใจที่สุดของปฏิบัติการ และคำว่าห้า zero-day ทำให้มันหาย
เครือข่ายเป้าหมายไม่มีเส้นทางจากอินเทอร์เน็ต หนอนจึงเดินทางบนสื่อพกพา ผ่านเครื่องของวิศวกร และผ่านไฟล์โครงการที่เครื่องเหล่านั้นถือเข้าไปข้างใน มันขี่การจราจรซ่อมบำรุงธรรมดาที่ air gap ต้องมี เพื่อให้ air gap ดูแลรักษาได้ ช่องว่างไม่ได้ถูกเอาชนะ มันถูกใช้ ขั้นตอนปฏิบัติของ air gap เองคือพาหนะ ต้นเหตุในหนึ่งประโยค: การแยกระบบที่อนุญาตให้ข้ามได้ทางเดียวคือคนถือสื่อเข้าไป คือการแยกระบบที่มีช่องทางผ่านซึ่งเขียนเป็นเอกสาร มีตารางเวลา และไม่ตรวจตัวตน
สิ่งที่ไม่เคยมีมาก่อนคือสองอย่างพร้อมกัน มันเป็นมัลแวร์ตัวแรกที่เขียนเพื่อทำลายอุปกรณ์อุตสาหกรรมทางกายภาพ ไม่ใช่เพื่อขโมย ปิดกั้น หรือขีดเขียน และมันเล็ง PLC ตระกูล Siemens S7 เปลี่ยนกระบวนการ แล้วเล่นค่าปกติที่บันทึกไว้ก่อนหน้ากลับไปที่จอของผู้ควบคุม สองอย่างนี้ต้องมาด้วยกัน เพราะการทำลายเครื่องจักรช้าๆ ต้องการเวลา และเวลาจะมีได้ก็ต่อเมื่อคนที่เฝ้าอยู่ไม่รู้ตัว เครื่องวัดอ่านว่าปกติ ขณะที่เครื่องจักรพังตัวเอง ในเล่มที่ถามว่าเผื่อพอหรือไม่ นี่คือกรณีที่เครื่องวัดส่วนเผื่อถูกยึดก่อน
สิ่งที่กรณีนี้สอน: เขียนรายการทางข้ามทุกทางของ air gap — แผ่นสื่อ เครื่องของช่าง ไฟล์โครงการ — แล้วถามว่าทางไหนตรวจสิ่งที่ข้ามมา และเครื่องวัดที่คุณเชื่อ อ่านค่าจากคอมพิวเตอร์ตัวเดียวกับที่ถูกโจมตีหรือไม่
Heartbleed · เมษายน 2014
การเข้ารหัสของอินเทอร์เน็ตส่วนใหญ่วิ่งผ่านไลบรารีตัวเดียวชื่อ OpenSSL และไลบรารีตัวนั้นดูแลด้วยเงินบริจาคราว 2,000 ดอลลาร์ต่อปี ตัวเลขสองตัวนี้อยู่ในโลกเดียวกันมาหลายปีโดยไม่มีใครต้องอธิบายมัน จนกระทั่งวันที่ 7 เมษายน 2014
วันนั้น OpenSSL ออกประกาศช่องโหว่ CVE-2014-0160 และในเดือนเดียวกัน Netcraft นับได้ว่าเว็บไซต์ SSL 17.5% เปิดส่วนขยายที่มีช่องโหว่นี้อยู่ — ใบรับรองราวครึ่งล้านใบจากผู้ออกที่เบราว์เซอร์เชื่อถือ ผู้พบคือ Neel Mehta จาก Google Security และบริษัท Codenomicon แยกกันพบ แก้ใน OpenSSL 1.0.1g
กลไกในระดับแนวคิดเรียบง่ายจนน่าหงุดหงิด ส่วนขยาย heartbeat ของ TLS ตาม RFC 6520 ให้ฝ่ายหนึ่งส่งข้อมูลก้อนเล็กพร้อมระบุความยาว แล้วขอให้อีกฝ่ายส่งกลับ OpenSSL ใช้ความยาวที่ถูกบอก แทนที่จะวัดก้อนที่ได้รับจริง เมื่อความยาวที่บอกเกินของจริง คำตอบถูกเติมให้ครบขนาดด้วยสิ่งที่อยู่ถัดไปในหน่วยความจำของโปรเซส ได้ครั้งละถึง 64 KB ทำซ้ำได้ ไม่ต้องมีรหัสผ่าน ไม่ต้องเปิดเซสชันให้เสร็จ และไม่ทิ้งอะไรไว้ในบันทึก ส่วนสิ่งที่อยู่ถัดไปบนเซิร์ฟเวอร์ TLS รวมถึงข้อมูลเซสชันและกุญแจส่วนตัว
ระยะเวลาของกรณีนี้ชัดที่สุดในภาค และมันน่าสนใจตรงที่ใครเป็นคนเขียน โค้ดที่ผิดถูกเพิ่มวันที่ 31 ธันวาคม 2011 โดย Robin Seggelmann ผู้เขียนร่วมคนแรกของ RFC ฉบับนั้นเอง ส่งถึงโลกใน OpenSSL 1.0.1 วันที่ 14 มีนาคม 2012 เปิดเผยวันที่ 7 เมษายน 2014 สองปีกับสามสัปดาห์ในโค้ดที่ปล่อยใช้แล้ว ระหว่างสองปีนั้น Apache กับ nginx สองเซิร์ฟเวอร์ที่พึ่ง OpenSSL มากที่สุด มีส่วนแบ่งเว็บไซต์ที่ใช้งานอยู่รวมกันเกิน 66% ในสำรวจของ Netcraft เดือนเดียวกัน ต้นเหตุในหนึ่งประโยค: ค่าความยาวที่ฝ่ายไกลส่งมาถูกเชื่อแทนที่จะถูกตรวจ ในไลบรารีความมั่นคงที่ถูกติดตั้งกว้างที่สุดที่มีอยู่
ส่วนเผื่อถูกเติมหลังจากมันหมดไปแล้ว วันที่ 24 เมษายน 2014 สิบเจ็ดวันหลังเปิดเผย Linux Foundation ประกาศ Core Infrastructure Initiative โดยมีบริษัทเทคโนโลยีใหญ่หลายแห่งหนุน OpenSSL เป็นโครงการชุดแรกที่ได้ทุน และเงินนั้นจ่ายเป็นเงินเดือนนักพัฒนาแกนหลักเต็มเวลาสองคน สองคน หลังจากสองปีสามสัปดาห์
ในแง่สันของเล่ม ธรรมชาติไม่ส่งค่าความยาวปลอม ผู้โจมตีส่ง และส่งซ้ำได้ไม่จำกัด ค่าที่ไม่ถูกตรวจในโค้ดหนึ่งบรรทัดจึงไม่ใช่บั๊กหนึ่งตัว มันคือประตูที่เปิดอยู่บนเซิร์ฟเวอร์ครึ่งล้านเครื่องพร้อมกัน
สิ่งที่กรณีนี้สอน: หาไลบรารีที่ทุกอย่างของคุณพึ่งอยู่ แล้วถามว่ามีคนกี่คนได้เงินเดือนดูแลมัน — ถ้าคำตอบคือศูนย์ นั่นคือส่วนเผื่อที่ไม่มี
Mirai · ตุลาคม 2016
เจ้าของเราเตอร์ตามบ้าน กล้อง IP และเครื่องบันทึกวิดีโอ ไม่รู้ว่าของพวกนั้นเป็นคอมพิวเตอร์ พวกเขาซื้อมันมาเพื่อทำงานอย่างเดียว เสียบไฟ แล้วลืม ผู้ผลิตเผารหัสผ่านตายตัวลงในเฟิร์มแวร์ก่อนส่งออกจากโรงงาน และหลายกรณีเจ้าของเปลี่ยนมันไม่ได้ต่อให้อยากเปลี่ยน
วันที่ 21 ตุลาคม 2016 ผู้ให้บริการ DNS ชื่อ Dyn ถูกโจมตีจากปลายทางถึงราวหนึ่งแสนจุดตามการวิเคราะห์ของ Dyn เอง และ Twitter, Netflix, Reddit, GitHub กับ Spotify หายไปจากผู้ใช้ในพื้นที่ส่วนใหญ่ของสหรัฐ
ลำดับเหตุการณ์ก่อนหน้านั้นสั้น วันที่ 20 กันยายน เว็บไซต์ Krebs on Security ถูกโจมตี วันที่ 30 กันยายน ผู้ใช้ชื่อ Anna-senpai ปล่อย source code ของมัลแวร์สู่สาธารณะ วันที่ 21 ตุลาคม Dyn ล้ม สามสัปดาห์ระหว่างการแจกเครื่องมือกับการใช้มันในระดับนั้น ตัวสแกนของ Mirai ถือพจนานุกรมชื่อผู้ใช้กับรหัสผ่าน 62 คู่ ไม่ซ้ำกัน 61 คู่ มีหนึ่งคู่ซ้ำ นั่นคือเหตุผลที่วรรณกรรมพิมพ์ทั้งสองตัวเลข และหกสิบสองคู่คือทั้งหมดที่มันต้องใช้ มันไม่ใช่เครื่องมือถอดรหัส มันเป็นแค่รายชื่อของที่ผู้ผลิตพิมพ์ไว้ในคู่มือ
งานศึกษาใน USENIX Security 2017 โดย Antonakakis และคณะ ติดตามเจ็ดเดือน วัดจุดสูงสุดของการติดเชื้อพร้อมกันได้ 600,000 เครื่อง ส่วนใหญ่เป็นเราเตอร์ตามบ้าน กล้อง IP และเครื่องบันทึกวิดีโอ ส่วนตัวเลขสะสมสองถึงสามล้านเครื่องที่แพร่อยู่ การค้นคว้าครั้งนี้ไม่ได้ตรวจ
ตัวเลข 1.2 Tbps ที่ถูกพิมพ์เป็นข้อเท็จจริงมาสิบปี ตายในการค้นคว้า และคนที่ฆ่ามันคือ Dyn เอง บริษัทเขียนว่ามีรายงานขนาดในช่วงนั้น และในเวลานั้นบริษัทยืนยันข้ออ้างนี้ไม่ได้ Dyn ยังบอกด้วยว่าตัวเลขของตนไม่รวมการจราจรที่ถูกกรองต้นทาง ตัวเลขจริงจึงไม่รู้ว่ามากหรือน้อยกว่า มันแค่ไม่รู้ และการที่ตัวเลขนี้หายไปไม่ได้ทำให้เรื่องเล็กลง เพราะสิ่งที่รู้คือคานงัดไม่ใช่แบนด์วิดท์ การแปลงชื่อเป็นที่อยู่คือจุดล้มจุดเดียวของทุกอย่างที่อยู่เหนือมัน ล้ม Dyn ได้ก็ล้มทุกชื่อที่ Dyn ถืออยู่
ต้นเหตุในหนึ่งประโยค: อุปกรณ์ถูกส่งออกจากโรงงานพร้อมรหัสผ่านตายตัวที่ตีพิมพ์แล้ว บนบริการที่เข้าถึงได้จากอินเทอร์เน็ตเปิด ไม่มีกลไกอัปเดต และเจ้าของไม่รู้ว่าสิ่งนั้นเป็นคอมพิวเตอร์
คำถามประจำภาค — ข้อบกพร่องมีอยู่นานเท่าไรก่อนถูกใช้ — ไม่มีคำตอบในกรณีนี้ และเหตุผลที่ไม่มีคือเหตุผลที่แย่ที่สุด มันไม่ใช่ข้อบกพร่องที่เกิดในวันหนึ่งและแก้ด้วยแพตช์ มันคือการตัดสินใจในการผลิต อยู่ในฮาร์ดแวร์ที่มีอายุใช้งานหลายปีและไม่มีทางส่งการแก้ไขไปถึง ข้อบกพร่องคือตัวสินค้า
สิ่งที่กรณีนี้สอน: ก่อนต่ออุปกรณ์ใดเข้าเครือข่าย ถามสองข้อ — เปลี่ยนรหัสผ่านจากโรงงานได้ไหม และผู้ผลิตส่งแพตช์มาทางไหน — ถ้าตอบไม่ได้ทั้งคู่ ให้ถือว่ามันติดเชื้อแล้วตั้งแต่วันซื้อ
Equifax · 2017
วันที่ 7 มีนาคม 2017 Apache ประกาศช่องโหว่ CVE-2017-5638 ใน Struts พร้อมแพตช์ในวันเดียวกัน แบบก่อสร้างของการโจมตีจึงวางอยู่ในที่สาธารณะพร้อมคำเตือนและทางแก้ตั้งแต่นาทีแรก และ 67 วันต่อมา ผู้โจมตีเดินเข้าพอร์ทัลรับเรื่องร้องเรียนของ Equifax ผ่านช่องโหว่นั้นที่ยังไม่ได้แพตช์
เรื่องจริงของกรณีนี้ไม่ได้อยู่ที่แพตช์ที่พลาด มันอยู่ที่ทำไมไม่มีใครเห็นอะไรเลยตลอดสองเดือนครึ่งหลังจากนั้น อุปกรณ์ที่ตรวจการจราจรเข้ารหัสในเครือข่ายของ Equifax หยุดทำงานมา 19 เดือน เพราะใบรับรองของมันหมดอายุ วันที่ 29 กรกฎาคม พนักงานคนหนึ่งต่ออายุใบรับรอง เครื่องมือเริ่มแจ้งเตือนการจราจรผิดปกติทันที ความสามารถนี้ถูกซื้อ ถูกติดตั้ง และตาบอด และไม่มีอะไรในองค์กรสังเกตว่ากลไกควบคุมชิ้นหนึ่งหยุดส่งผลลัพธ์มาปีครึ่ง
วันที่เรียงตามลำดับที่สำคัญ เข้าระบบ 13 พฤษภาคม ระหว่างพฤษภาคมถึงปลายกรกฎาคม ผู้โจมตีค้นฐานข้อมูลของ Equifax แยกกัน 51 ฐาน ตรวจพบ 29 กรกฎาคม ซึ่งเป็นวันเดียวกับที่ใบรับรองถูกต่ออายุ เปิดเผยต่อสาธารณะ 7 กันยายน ระยะเวลาที่ผู้โจมตีอยู่ในระบบ ตัวเลขที่ใช้กันทั่วไปคือ 76 วัน นับตามปฏิทินจาก 13 พฤษภาคมถึง 29 กรกฎาคมได้ 77 วัน เล่มนี้พิมพ์ทั้งสอง
ขนาด 147 ล้านคน ตามตัวเลขของ Equifax และ FTC ราวครึ่งหนึ่งของประชากรสหรัฐ รวมผู้อยู่อาศัยในสหราชอาณาจักรและแคนาดา ตัวเลขของ GAO คืออย่างน้อย 145.5 ล้านคน นับเฉพาะผู้บริโภคในสหรัฐ ทั้งสองตัวเลขถูกต้อง มันนับคนละประชากร ต้นเหตุในหนึ่งประโยค: ช่องโหว่ที่มีแพตช์สาธารณะถูกปล่อยให้เดินอยู่ 67 วันบนแอปพลิเคชันที่หันหน้าหาอินเทอร์เน็ต ในเครือข่ายที่ไม่แบ่งส่วน ภายใต้ระบบเฝ้าระวังที่ถูกปิดด้วยใบรับรองหมดอายุและไม่มีใครคิดถึง
ค่ายอมความราว 700 ล้านดอลลาร์ กับ FTC, CFPB และ 50 รัฐ เดือนกรกฎาคม 2019 แบ่งเป็น 575 ล้านทันที และเพิ่มได้อีกถึง 125 ล้าน รายงานชันสูตรของ GAO หมายเลข GAO-18-559 เดือนสิงหาคม 2018 ระบุความบกพร่องเชิงระบบสี่ด้าน การระบุ การตรวจจับ การแบ่งส่วน และการกำกับข้อมูล สี่ความล้มเหลว ไม่ใช่แพตช์ที่พลาดหนึ่งตัว
ในแง่สันของเล่ม 67 วันคือระยะที่แบบก่อสร้างพร้อมคำเตือนวางอยู่ในที่สาธารณะ และผู้โจมตีอ่านมันก่อนเจ้าของ
สิ่งที่กรณีนี้สอน: ให้เครื่องมือตรวจจับทุกตัวรายงานจำนวนสิ่งที่มันเห็นต่อวัน แล้วตั้งสัญญาณเตือนเมื่อตัวเลขนั้นเป็นศูนย์ — ความเงียบของเครื่องมือไม่ใช่ความสงบของระบบ
NotPetya · มิถุนายน 2017
ใครทำธุรกิจในยูเครนปี 2017 แทบต้องใช้ซอฟต์แวร์บัญชีภาษีชื่อ M.E.Doc ยื่นภาษี ฐานผู้ติดตั้งจึงคือบริษัทที่ทำธุรกิจในยูเครน รวมถึงสำนักงานท้องถิ่นของบริษัทข้ามชาติ และทุกเครื่องที่ติดตั้งมันถูกตั้งค่าให้รับอัปเดตจากเซิร์ฟเวอร์ของ M.E.Doc เองโดยอัตโนมัติ เพราะนั่นคือสิ่งที่ซอฟต์แวร์ที่ดูแลดีควรทำ
วันที่ 27 มิถุนายน 2017 หนึ่งวันก่อนวันรัฐธรรมนูญของยูเครน Maersk บริษัทเดินเรือคอนเทนเนอร์ใหญ่ที่สุดในโลกสูญเสีย domain controller ทุกตัวในเครือข่ายทั่วโลก และต้องติดตั้ง PC ราว 45,000 เครื่องกับเซิร์ฟเวอร์ 4,000 เครื่องใหม่ทั้งหมด
ทางที่มันเข้าไปถึงที่นั่นคือเซิร์ฟเวอร์อัปเดต ผู้โจมตียึดเซิร์ฟเวอร์อัปเดตของ M.E.Doc เปลี่ยนเส้นทางคำขออัปเดตจากเครื่องลูกค้าไปยังเซิร์ฟเวอร์ของตน และสั่งให้ดาวน์โหลดและรัน ทุกเหยื่อรับมันผ่านช่องทางที่ตนตั้งใจตั้งค่าให้ไว้ใจและรันอัตโนมัติ ต้นเหตุในหนึ่งประโยค: ช่องทางอัปเดตตรวจตัวตนของเซิร์ฟเวอร์ ไม่ได้ตรวจตัวสิ่งที่ส่งมา ยึดเซิร์ฟเวอร์ได้จึงเท่ากับยึดทุกเครื่องปลายทาง
มันไม่ใช่ ransomware มันแสดงข้อความเรียกค่าไถ่ แต่กุญแจติดตั้งที่แสดงเป็นค่าสุ่ม จ่ายแล้วถอดรหัสไม่ได้ มันคือตัวลบข้อมูลที่สวมเสื้อ ransomware ข้อนี้เปลี่ยนความหมายของทุกเรื่องเล่าที่ตามมา เรื่องเล่าการฟื้นตัวทุกเรื่องจึงเป็นการสร้างใหม่ ไม่ใช่การถอดรหัส
domain controller ทุกตัวของ Maersk ถูกทำลาย และเครือข่าย Windows ที่ไม่มี Active Directory สร้างใหม่ไม่ได้ เพราะไม่เหลืออะไรบอกว่าใครเป็นใคร เหลืออยู่ตัวเดียว เครื่องในสำนักงานห่างไกลที่กานา ไฟดับในพื้นที่ทำให้มันหลุดจากเครือข่ายก่อน NotPetya ไปถึง การฟื้นตัวทั้งหมดของบริษัทเดินเรือใหญ่ที่สุดในโลกขึ้นอยู่กับอุบัติเหตุในสำนักงานที่มีทรัพยากรน้อยที่สุด
ตัวเลขความเสียหายมีสองชั้น และเล่มนี้พิมพ์ทั้งสองชั้นเพราะทั้งสองชั้นบอกคนละเรื่อง ทำเนียบขาววันที่ 15 กุมภาพันธ์ 2018 ระบุว่าเป็นฝีมือกองทัพรัสเซีย เรียกมันว่าการโจมตีไซเบอร์ที่ทำลายล้างและแพงที่สุดในประวัติศาสตร์ และให้ตัวเลขเกินหนึ่งหมื่นล้านดอลลาร์ ตัวเลขนั้นไม่มีฐานการตรวจสอบและไม่มีวิธีคำนวณตีพิมพ์ มันจึงอยู่ในเล่มนี้ในฐานะคำแถลงของทำเนียบขาว ไม่ใช่ในฐานะจำนวนเงิน ส่วนตัวเลขที่บริษัทเปิดเผยเองตรวจได้ Merck ราว 870 ล้าน FedEx/TNT Express 300 ล้านในไตรมาสเดียวและเกิน 400 ล้านรวม Maersk 250 ถึง 300 ล้าน รวมแล้วต่ำกว่าสองพันล้านที่ระบุที่มาได้ ส่วนหางยาวที่เหลือไม่รู้จริง
คำถามประจำภาคตอบได้สองชั้นเช่นกัน ส่วนที่ใช้แพร่ในเครือข่ายอาศัยช่องโหว่ SMB ที่ MS17-010 แพตช์ไว้วันที่ 14 มีนาคม 2017 สามเดือนครึ่งก่อนหน้า แต่ทางเข้าหลักคือช่องทางอัปเดตเอง และนั่นไม่ใช่ข้อบกพร่องที่มีอายุ มันคือแบบที่ออกไว้
สิ่งที่กรณีนี้สอน: หาช่องทางทุกช่องที่เครื่องของคุณรับโค้ดมารันโดยอัตโนมัติ แล้วถามว่ามันตรวจลายเซ็นของสิ่งที่ส่งมา หรือแค่ตรวจว่าเซิร์ฟเวอร์ถูกตัว
SolarWinds · ธันวาคม 2020
องค์กรราว 300,000 แห่งเป็นลูกค้าของ SolarWinds และงานประจำที่ไม่มีใครต้องคิดมากคือติดตั้งอัปเดตของซอฟต์แวร์ Orion ที่บริษัทลงลายเซ็นส่งมา ลายเซ็นคือสิ่งที่ทำให้ไม่ต้องคิด มันตอบคำถามว่าของนี้มาจากใคร
วันที่ 13 ธันวาคม 2020 FireEye เปิดเผยว่าอัปเดตที่ SolarWinds ลงลายเซ็นและแจกจ่ายระหว่างเดือนมีนาคมถึงมิถุนายนปีนั้น มี backdoor อยู่ข้างใน และลูกค้าถึง 18,000 รายติดตั้งมันไปแล้ว FireEye พบมันขณะสอบสวนการถูกเจาะของตัวเอง
สิ่งที่อยู่ในระบบ build ของ SolarWinds คือมัลแวร์อีกตัวชื่อ SUNSPOT และจังหวะที่มันเลือกคือทั้งหมดของเรื่อง มันเฝ้าดูโปรเซสที่แปลโค้ดของ Orion และสลับไฟล์ source หนึ่งไฟล์ในจังหวะ build เพื่อฝัง backdoor ชื่อ SUNBURST หลังนักพัฒนาตรวจโค้ดเสร็จ ก่อนลงลายเซ็น ผลคือคลัง source สะอาด และ binary ที่ลงลายเซ็นแล้วไม่สะอาด การตรวจทุกชั้นปลายทาง ลายเซ็นถูกต้อง ผู้เผยแพร่ตัวจริง ค่า hash ตรงกับที่ SolarWinds ประกาศ ตอบว่าผ่านทั้งหมด ไม่มีชั้นไหนตอบผิด ทุกชั้นตอบคำถามที่ตัวเองถูกสร้างมาให้ถาม นี่คือข้อโต้แย้งของ Thompson ปี 1984 และคำทำนายในมาตรา 3.2.4 ของรายงาน Multics ปี 1974 ทำงานจริงในระดับอุตสาหกรรม ต้นเหตุในหนึ่งประโยค: ระบบ build ถูกไว้ใจและไม่ถูกเฝ้า กุญแจลงลายเซ็นจึงรับรอง binary ที่ไม่มีมนุษย์คนไหนเคยอ่าน
ตัวเลขที่ถูกรายงานผิดบ่อยที่สุดคือ 18,000 นั่นคือจำนวนลูกค้าที่ติดตั้งอัปเดตปนเปื้อน จากลูกค้าราว 300,000 ราย SolarWinds ระบุจำนวนที่ถูกใช้ประโยชน์จริงไว้ต่ำกว่า 100 ทำเนียบขาวโดย Anne Neuberger วันที่ 17 กุมภาพันธ์ 2021 ระบุหน่วยงานรัฐบาลกลางเก้าแห่งและบริษัทเอกชนราว 100 แห่ง ติดตั้งไม่เท่ากับถูกเจาะ
ช่องว่างระหว่าง 18,000 กับราวหนึ่งร้อยคือตัวเลขที่น่าสนใจกว่าทั้งสองตัว ผู้โจมตีสร้างกลไกส่งของที่ไปถึงหนึ่งหมื่นแปดพันองค์กร แล้วใช้มันกับเศษเสี้ยวของหนึ่งเปอร์เซ็นต์ เพราะเปิดใช้ทั้งหมดจะเผามันทิ้ง ความยับยั้งชั่งใจตรงนั้นไม่ใช่ความเมตตา มันคือการถนอมทรัพย์สิน
ระยะเวลา: เข้าถึงระบบของ SolarWinds เองราวเดือนกันยายน 2019 ทดลองฝังเดือนตุลาคม 2019 backdoor ตัวจริงออกไปกับ build ระหว่างมีนาคมถึงมิถุนายน 2020 ถูกพบเดือนธันวาคม 2020 ราวสิบสี่ถึงสิบห้าเดือนจากเข้าครั้งแรกถึงเปิดเผย และมีความพยายามลบร่องรอยจำนวนมากที่ใช้ไปเพื่อยืดตัวเลขนี้โดยเฉพาะ
ในแง่สันของเล่ม ผู้โจมตีไม่ได้เจาะแบบก่อสร้าง เขาเจาะโรงงานที่หล่อชิ้นส่วน แล้วปล่อยให้ระบบตรวจรับของทุกลูกค้าประทับตราให้
สิ่งที่กรณีนี้สอน: สร้าง binary จาก source เดียวกันบนเครื่องที่สอง แล้วเทียบไบต์ต่อไบต์กับสิ่งที่ออกจากระบบ build — ลายเซ็นบอกว่าใครส่ง ไม่ได้บอกว่าข้างในคืออะไร
Log4Shell · ธันวาคม 2021
งานที่น่าเบื่อที่สุดที่ซอฟต์แวร์ทำ คือการจดว่าเกิดอะไรขึ้น และไลบรารีที่รับงานนั้นในโลก Java ชื่อ Log4j มันอยู่แทบทุกที่ที่ Java ทำงาน เพราะแทบทุกโปรแกรมต้องจดอะไรสักอย่าง ปัญหาอยู่ตรงที่มันไม่ได้แค่จด ต้นเหตุในหนึ่งประโยค: ไลบรารีบันทึก log ปฏิบัติต่อข้อความที่ถูกขอให้จด ในฐานะสิ่งที่ต้องประเมิน แทนที่จะเป็นสิ่งที่ต้องเก็บ
วันที่ 24 พฤศจิกายน 2021 Chen Zhaojun จาก Alibaba Cloud Security Team รายงานช่องโหว่ CVE-2021-44228 ใน Log4j ต่อ Apache และเมื่อมันเป็นสาธารณะวันที่ 9–10 ธันวาคม คะแนน CVSS ของมันคือ 10.0 จาก 10
สิบเต็มแปลว่าสั่งรันโค้ดจากระยะไกลได้โดยไม่ต้องยืนยันตัวตน จุดชนวนง่าย และไลบรารีอยู่แทบทุกที่ที่ Java ทำงาน การแก้ไล่มาสามรุ่น 2.15.0 แล้ว 2.16.0 ที่ปิด JNDI เป็นค่าตั้งต้นและถอดการค้นหาในข้อความออกทั้งหมด แล้ว 2.17.0 สามรุ่นในไม่กี่สัปดาห์คือภาพของคนที่กำลังไล่แก้ของที่ไม่รู้ว่าตัวเองมีกี่ทาง
ระยะเวลา: ปลั๊กอินค้นหา JNDI ออกมากับ Log4j 2.0-beta9 วันที่ 18 กรกฎาคม 2013 รุ่นที่ได้รับผลกระทบไล่จาก 2.0-beta9 ถึง 2.14.1 ราวแปดปีในโค้ดที่ปล่อยใช้แล้ว ก่อนมีใครรายงาน
ความกว้างวัดได้ และเหตุผลที่มันกว้างขนาดนั้นคือส่วนที่ทำให้แก้ยาก Google วิเคราะห์วันที่ 17 ธันวาคม 2021 พบแพ็กเกจ Java ที่ได้รับผลกระทบเกิน 35,000 แพ็กเกจ เกิน 8% ของ Maven Central ดัชนีแพ็กเกจ Java หลัก ส่วนใหญ่ได้รับผลกระทบโดยอ้อม ไลบรารีมาถึงลึกกว่าหนึ่งชั้นของ dependency ทีมที่อ่านรายการ dependency ของตัวเองจึงไม่เห็น Log4j อยู่ในนั้นเลย ทั้งที่มันอยู่ Cyber Safety Review Board ในรายงานฉบับแรกวันที่ 11 กรกฎาคม 2022 เรียกมันว่าช่องโหว่ระดับ endemic คาดว่าจะถูกใช้ต่อไปถึงทศวรรษ 2030 ด้วยเหตุผลตรงตัวว่าไม่มีวิธีกลางที่จะหาสำเนาทุกชุด และจึงไม่มีวิธีกลางที่จะแก้
แล้วใครเป็นคนแก้ ผู้ดูแล Apache Logging Services โครงการเบื้องหลังไลบรารีที่ฝังอยู่ในสัดส่วนที่วัดได้ของซอฟต์แวร์ Java ทั้งโลก เป็นอาสาสมัครไม่ได้รับเงิน รายงานร่วมสมัยให้จำนวน 16 คน ตัวเลขนี้ไม่ได้ตรวจกับแหล่งต้นทางของ Apache ส่วนตัวเลขสามคนที่เล่าต่อกันมา หาแหล่งไม่พบ และมันไม่สำคัญเท่าที่คนเล่าคิด ครึ่งที่รับน้ำหนักคือคำว่าไม่ได้รับเงิน ไม่ใช่จำนวนหัว การแก้ไขต้องถูกผลิตโดยอาสาสมัครเหล่านั้น ด้วยความเร็ว ในสุดสัปดาห์เดียว ไม่มีค่าตอบแทน ขณะที่ผู้ขายความมั่นคงทุกรายบนโลกเขียนถึงพวกเขา
ในแง่สันของเล่ม ช่องโหว่หนึ่งช่องคัดลอกไปพร้อมไลบรารีสามหมื่นห้าพันครั้ง โดยที่คนถือสำเนาไม่รู้ว่าถืออยู่ ผู้โจมตีไม่ต้องหาว่าใครใช้ Log4j เขายิงทุกอย่างที่รับข้อความ
สิ่งที่กรณีนี้สอน: สร้างรายการ dependency ที่ลึกกว่าหนึ่งชั้น แล้วค้นชื่อไลบรารีที่คุณไม่เคยตัดสินใจใช้ — ที่นั่นคือที่ช่องโหว่ระดับ endemic อาศัยอยู่
Colonial Pipeline · พฤษภาคม 2021
วันที่ 7 พฤษภาคม 2021 Colonial Pipeline ปิดท่อส่งน้ำมันยาวกว่า 5,500 ไมล์ที่ส่งน้ำมันราว 2.5 ล้านบาร์เรลต่อวัน — ราว 45% ของเชื้อเพลิงฝั่งตะวันออกของสหรัฐ — ด้วยมือของบริษัทเอง ระบบที่ผู้โจมตีทำให้ล่มไม่ใช่ท่อ มันคือระบบออกบิล
ส่วนที่เล่มนี้ต้องการอยู่ตรงนั้น ระบบปฏิบัติการของท่อไม่ได้รับการยืนยันว่าถูกเจาะ Colonial ปิดท่อเองเพื่อความปลอดภัย เพราะระบบออกบิลล่ม และบริษัทบันทึกไม่ได้ว่ากำลังส่งอะไรให้ใคร ความล้มเหลวทางกายภาพจึงเป็นผลของระบบธุรกิจล้ม บวกกับไม่มีวิธีเดินเครื่องแบบลดระดับ ส่วนเผื่อที่ขาดไม่ใช่มาตรการความมั่นคง มันคือแผนสำรองด้วยมือ
ลำดับเหตุการณ์กินเวลาไม่ถึงสัปดาห์ การขโมยข้อมูลเดินอยู่แล้วตั้งแต่วันที่ 6 พฤษภาคม ransomware ถูกปล่อยและท่อถูกปิดวันที่ 7 จ่ายค่าไถ่วันที่ 8 กลับมาส่งเต็มระบบวันที่ 12 ราวห้าวัน ห้าวันนั้นพอให้คิวเติมน้ำมันยาวจากเวอร์จิเนียถึงจอร์เจีย และสายการบินเปลี่ยนเส้นทางไปเติมเชื้อเพลิงที่อื่น
ทางเข้าคือรหัสผ่านของบัญชี VPN เก่าที่เลิกใช้แล้วและไม่มี multi-factor authentication ปัจจัยเดียว บัญชีเดียว ไม่มีใครมีหน้าที่ปลดมัน บัญชีนั้นมีอยู่นานเท่าไรก่อนถูกใช้ ไม่ทราบ และนั่นคือคำตอบของคำถามประจำภาคในกรณีนี้ องค์กรตอบไม่ได้เพราะไม่มีใครนับ ต้นเหตุในหนึ่งประโยค: บัญชีเข้าถึงระยะไกลที่หลับอยู่ มีปัจจัยยืนยันเดียวที่ใช้ซ้ำได้ ไม่เคยถูกปลด และไม่มีอะไรในองค์กรรับผิดชอบว่าต้องรู้ว่ามันยังอยู่
ค่าไถ่ราว 75 BTC ราว 4.4 ล้านดอลลาร์ จ่ายให้กลุ่ม DarkSide วันที่ 8 พฤษภาคม วันที่ 7 มิถุนายน กระทรวงยุติธรรมประกาศยึดได้ 63.7 BTC มูลค่าราว 2.3 ล้านดอลลาร์ 85% ของเหรียญ แต่ราวครึ่งเดียวของเงิน เพราะราคา bitcoin ตกระหว่างเดือนที่จ่ายกับเดือนที่ยึด ประโยคว่าค่าไถ่ถูกกู้คืนจึงจริงสำหรับเหรียญและเท็จสำหรับเงิน และหน่วยที่คุณเลือกนับคือสิ่งที่ตัดสินว่าเรื่องนี้จบดีหรือไม่
ในแง่สันของเล่ม ผู้โจมตีไม่ได้แตะท่อ เขาแตะบัญชีที่ไม่มีใครจำได้ว่ามี และท่อหยุดเพราะไม่มีใครเคยซ้อมเดินมันโดยไม่มีคอมพิวเตอร์
สิ่งที่กรณีนี้สอน: ถามว่าถ้าระบบออกบิลล่มพรุ่งนี้ เครื่องจักรจริงเดินต่อด้วยกระดาษได้กี่วัน — คำตอบนั้นคือส่วนเผื่อจริงของท่อ ไม่ใช่ firewall
XZ Utils · มีนาคม 2024
xz เป็น dependency ของ Linux แทบทุกดิสทริบิวชัน และคนที่ดูแลมันมีอยู่คนเดียวชื่อ Lasse Collin ไม่ได้รับเงิน ตรวจแพตช์ไม่ทัน และเหนื่อย ปลายปี 2021 มีคนเริ่มสนใจข้อเท็จจริงข้อนั้น ตัวตนชื่อ Jia Tan เริ่มส่งแพตช์เล็กๆ ให้ xz-devel
ปฏิบัติการทั้งหมดใช้เวลาสองปีครึ่ง และเกือบทั้งหมดของมันเป็นเรื่องของคน ไม่ใช่โค้ด เมษายน 2022 ตัวตนที่สองชื่อ Jigar Kumar ปรากฏขึ้นมากดดันให้รับแพตช์ของ Jia Tan มิถุนายน 2022 Jigar Kumar โพสต์สาธารณะกดดัน Collin ผู้ดูแลเพียงคนเดียว เรื่องตรวจช้าและเรียกร้องให้เพิ่มผู้ดูแล Collin ตอบว่าทรัพยากรของเขามีจำกัดเกินไป และ Jia Tan อาจรับบทบาทใหญ่ขึ้น วันที่ 10 มิถุนายน 2022 สามวันหลังอีเมลกดดัน Collin รวม commit แรกที่ Jia Tan เป็นผู้เขียน Jigar Kumar ไม่ปรากฏตัวอีกเลย งานของเขาเสร็จแล้ว กุมภาพันธ์ 2024 backdoor ออกไปกับรุ่น 5.6.0 วันที่แน่นอนของรุ่นนี้ การค้นคว้าครั้งนี้ยืนยันไม่ได้
พื้นผิวที่ถูกโจมตีไม่ใช่โค้ด มันคือผู้ดูแลที่หมดแรงหนึ่งคน ผลิตคำร้องเรียน ผลิตอาสาสมัคร แล้วปล่อยให้ความเหนื่อยทำที่เหลือ ส่วนตัว backdoor เองก็ไม่ได้อยู่ในที่ที่คนตรวจมอง มันไม่ได้อยู่ในคลัง git มันอยู่ใน tarball ของรุ่นที่ปล่อย ซ่อนในไฟล์ทดสอบ และถูกประกอบขึ้นโดยสคริปต์ build ใครอ่าน source สาธารณะเห็นแต่ความว่างเปล่า รูปร่างเดียวกับ SUNSPOT ของ SolarWinds กับ compiler ของ Thompson และกับมาตรา 3.2.4 ของรายงานปี 1974 ห้าสิบปี บทเรียนเดียว ยังไม่ได้เรียน
วันที่ 28 มีนาคม 2024 Andres Freund นักพัฒนา PostgreSQL ที่ Microsoft รายงานต่อรายชื่ออีเมล oss-security ว่า xz/liblzma รุ่น 5.6.0 และ 5.6.1 มี backdoor และสิ่งที่พาเขาไปเจอคือ SSH login ที่ใช้เวลาราว 500 มิลลิวินาทีแทนที่จะเป็นราว 100 เขากำลังวัดประสิทธิภาพบน Debian sid เขาไม่ได้ทำงานความมั่นคง เขารำคาญตัวเลขที่ถอยหลัง ไล่ดู เห็น Valgrind ชี้ข้อผิดพลาดเข้าไปใน liblzma และตามไปถึง tarball ของ xz ปฏิบัติการระดับรัฐที่ผ่านการตรวจโค้ด ผ่านการตรวจรับของดิสทริบิวชัน และผ่านสแกนเนอร์อัตโนมัติทุกตัว ถูกจับด้วยความหน่วง 400 มิลลิวินาทีที่คนหนึ่งคนสังเกตขณะวัดอย่างอื่น
CVSS 10.0 ขนาดความเสียหายแทบเป็นศูนย์ และเป็นศูนย์เพราะวิธีที่มันถูกจับได้เท่านั้น มันไปถึง Fedora Rawhide และ Fedora 41, Debian สาย testing/unstable, openSUSE Tumbleweed และ Kali สำหรับเครื่องที่อัปเดตระหว่าง 26–29 มีนาคม 2024 มันไม่ถึง Debian stable, RHEL, Ubuntu รุ่นออกจริง หรือ SUSE Linux Enterprise ถ้ามันไปถึงรุ่น stable รัศมีคือเซิร์ฟเวอร์ Linux ส่วนใหญ่บนโลก พร้อมช่องรันโค้ดจากระยะไกลก่อนยืนยันตัวตน สำหรับใครก็ตามที่ถือกุญแจส่วนตัวที่ตรงกัน ราวห้าสัปดาห์ในโลกจริง เทียบกับสองปีครึ่งของการเตรียม ส่วนที่แพงของการโจมตี supply chain คือความไว้ใจ ไม่ใช่โค้ด
สิ่งที่กรณีนี้สอน: เมื่อตัวเลขประสิทธิภาพเปลี่ยนโดยไม่มีคำอธิบาย ให้ไล่จนเจอสาเหตุ ไม่ใช่จนมันหายไป — ส่วนเผื่อชิ้นสุดท้ายของระบบนิเวศคือคนที่ทนตัวเลขแปลกไม่ได้
ท่าที่เอาไปใช้ได้: สำหรับทุกระบบที่คุณดูแล เขียนวันที่สองวันไว้ข้างกัน — วันที่ช่องโหว่ประเภทนั้นถูกตีพิมพ์ครั้งแรก กับวันที่ระบบของคุณปิดมัน ช่องว่างระหว่างสองวันคือเวลาที่ผู้โจมตีมีมากกว่าคุณ และในภาคนี้มันวัดเป็นปี
จะพลิกคำตัดสินของภาคนี้ได้เมื่อ: มีชุดข้อมูลที่ตรวจสอบได้ว่าช่องโหว่ในซอฟต์แวร์ที่ใช้กันกว้าง ส่วนใหญ่ถูกใช้ภายในไม่กี่วันหลังเกิด ไม่ใช่หลายปี หรือมีวิธีคำนวณและตัวเลขที่ audit ได้ปรากฏสำหรับหนึ่งหมื่นล้านดอลลาร์ของ NotPetya, 1.2 Tbps ของ Dyn หรือ 100 ล้านดอลลาร์ของหนอน Morris
แหล่งของภาคนี้:
- Karger และ Schell, Multics Security Evaluation: Vulnerability Analysis, ESD-TR-74-193 Vol. II, มิถุนายน 1974 — https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/karg74.pdf
- Karger และ Schell, Thirty Years Later: Lessons from the Multics Security Evaluation, ACSAC 2002 — https://www.acsac.org/2002/papers/classic-multics.pdf
- Thompson, Reflections on Trusting Trust, CACM 27(8), สิงหาคม 1984 — https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
- Wheeler, Fully Countering Trusting Trust through Diverse Double-Compiling — https://arxiv.org/pdf/1004.5534
- Cox, Running the "Reflections on Trusting Trust" Compiler, 2023 — https://research.swtch.com/nih
- FBI, The Morris Worm: 30 Years Since First Major Attack on the Internet — https://www.fbi.gov/news/stories/morris-worm-30-years-since-first-major-attack-on-internet-110218
- United States v. Morris, 928 F.2d 504 (2d Cir. 1991) — https://law.justia.com/cases/federal/appellate-courts/F2/928/504/452673/
- Washington Post, No Jail Time Imposed in Hacker Case, 5 พฤษภาคม 1990 — https://www.washingtonpost.com/archive/politics/1990/05/05/no-jail-time-imposed-in-hacker-case/3f8fbd6c-e9e3-4249-8c51-bf72c43e2055/
- Aleph One, Smashing the Stack for Fun and Profit, Phrack 49, 8 พฤศจิกายน 1996 — https://phrack.org/issues/49/14
- rain.forest.puppy, NT Web Technology Vulnerabilities, Phrack 54, 25 ธันวาคม 1998 — https://phrack.org/issues/54/8
- กระทรวงยุติธรรมสหรัฐ, คำฟ้อง Albert Gonzalez, สิงหาคม 2009 — https://www.justice.gov/archives/opa/pr/alleged-international-hacker-indicted-massive-attack-us-retail-and-banking-networks
- Heartland Payment Systems, รายงาน 10-Q ไตรมาสสิ้นสุด 31 มีนาคม 2011 — https://www.sec.gov/Archives/edgar/data/0001144354/000114435411000011/hpy0331201110q.htm
- ISIS, Stuxnet Malware and Natanz, 22 ธันวาคม 2010 — https://isis-online.org/isis-reports/stuxnet-malware-and-natanz-update-of-isis-december-22-2010-reportsupa-href1
- CISA, ICS Advisory ICSA-10-238-01B — https://www.cisa.gov/news-events/ics-advisories/icsa-10-238-01b
- Kaspersky, The Man Who Found Stuxnet: Sergey Ulasen, 2 พฤศจิกายน 2011 — https://eugene.kaspersky.com/2011/11/02/the-man-who-found-stuxnet-sergey-ulasen-in-the-spotlight/
- Netcraft, Half a Million Widely Trusted Websites Vulnerable to Heartbleed Bug, เมษายน 2014 — https://www.netcraft.com/blog/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug
- CISA, OpenSSL Heartbleed Vulnerability CVE-2014-0160, 8 เมษายน 2014 — https://www.cisa.gov/news-events/alerts/2014/04/08/openssl-heartbleed-vulnerability-cve-2014-0160
- The Register, Linux Foundation Core Infrastructure Initiative, 24 เมษายน 2014 — https://www.theregister.com/2014/04/24/linux_foundation_core_infrastructure
- The Register, Robin Seggelmann และ Heartbleed, 11 เมษายน 2014 — https://www.theregister.com/2014/04/11/openssl_heartbleed_robin_seggelmann/
- Antonakakis และคณะ, Understanding the Mirai Botnet, USENIX Security 2017 — https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
- CISA, Heightened DDoS Threat Posed by Mirai and Other Botnets, 14 ตุลาคม 2016 — https://www.cisa.gov/news-events/alerts/2016/10/14/heightened-ddos-threat-posed-mirai-and-other-botnets
- การโจมตี Dyn รวมถึงคำแถลงของ Dyn เรื่อง 1.2 Tbps — https://en.wikipedia.org/wiki/DDoS_attacks_on_Dyn
- GAO-18-559, Data Protection: Actions Taken by Equifax and Federal Agencies, สิงหาคม 2018 — https://www.gao.gov/assets/gao-18-559.pdf
- Equifax, Cybersecurity Incident, 7 กันยายน 2017 — https://investor.equifax.com/news-events/press-releases/detail/237/equifax-releases-details-on-cybersecurity-incident
- Apache Software Foundation, แถลงเรื่อง Struts และ Equifax — https://news.apache.org/foundation/entry/media-alert-the-apache-software
- House Oversight Committee, The Equifax Data Breach, ธันวาคม 2018 — https://oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf
- CISA, Petya Ransomware, 1 กรกฎาคม 2017 — https://www.cisa.gov/news-events/alerts/2017/07/01/petya-ransomware
- Axios, White House confirms NotPetya attribution, 15 กุมภาพันธ์ 2018 — https://www.axios.com/2018/02/15/white-house-confirms-notpetya-1518728781
- The Register, FedEx NotPetya damages, 20 กันยายน 2017 — https://www.theregister.com/2017/09/20/fedex_notpetya_damages/
- CyberScoop, NotPetya cost Merck — https://cyberscoop.com/notpetya-ransomware-cost-merck-310-million/
- Control Engineering, How NotPetya took down Maersk — https://www.controleng.com/throwback-attack-how-notpetya-accidentally-took-down-global-shipping-giant-maersk/
- CrowdStrike, SUNSPOT Malware Technical Analysis — https://www.crowdstrike.com/en-us/blog/sunspot-malware-technical-analysis/
- SolarWinds Security Advisory FAQ — https://www.solarwinds.com/sa-overview/securityadvisory/faq
- The Record, SolarWinds says fewer than 100 customers were impacted — https://therecord.media/solarwinds-says-fewer-than-100-customers-were-impacted-by-supply-chain-attack
- CyberScoop, Neuberger on SolarWinds, 17 กุมภาพันธ์ 2021 — https://cyberscoop.com/solarwinds-cyber-espionage-russia-neuberger/
- Cyber Safety Review Board, Review of the December 2021 Log4j Event, 11 กรกฎาคม 2022 — https://www.cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf
- CERT/CC, VU#930724 Log4j — https://www.kb.cert.org/vuls/id/930724
- InfoWorld, How developers scrambled to secure the Log4j vulnerability — https://www.infoworld.com/article/2271392/how-developers-scrambled-to-secure-the-log4j-vulnerability.html
- CISA, Alert AA21-356A — https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-356a
- CISA, The Attack on Colonial Pipeline: What We've Learned — https://www.cisa.gov/news-events/news/attack-colonial-pipeline-what-weve-learned-what-weve-done-over-past-two-years
- กระทรวงพลังงานสหรัฐ, Colonial Pipeline Cyber Incident — https://www.energy.gov/ceser/colonial-pipeline-cyber-incident
- Morrison Foerster, DOJ Retrieves Millions in Colonial Pipeline Ransom, 9 มิถุนายน 2021 — https://www.mofo.com/resources/insights/210609-doj-retrieves-millions
- Cox, Timeline of the xz open source attack — https://research.swtch.com/xz-timeline
- Boehs, Everything I know about the xz backdoor — https://boehs.org/node/everything-i-know-about-the-xz-backdoor
- Help Net Security, xz backdoored: affected distros, 31 มีนาคม 2024 — https://www.helpnetsecurity.com/2024/03/31/xz-backdoored-linux-affected-distros/
- Red Hat warns of backdoor in xz tools — https://www.bleepingcomputer.com/news/security/red-hat-warns-of-backdoor-in-xz-tools-used-by-most-linux-distros/