เจาะลึกเหตุการณ์ด้านความปลอดภัยในเดือนพฤษภาคม 2019: ความคิดเห็นเกี่ยวกับบล็อกโพสต์

Question

เราเพิ่งโพสต์การอัปเดตเหตุการณ์ด้านความปลอดภัยที่เกิดขึ้นในเดือนพฤษภาคม 2019 พร้อมรายละเอียดทางเทคนิคว่าเกิดอะไรขึ้นมันเกิดขึ้นได้อย่างไรและการแก้ไขที่เราใช้เพื่อป้องกันไม่ให้เหตุการณ์เช่นนี้เกิดขึ้นอีก ต่อไปนี้เป็นข้อความที่ตัดตอนมาจากโพสต์ - อันดับแรกจากบทนำ:

ในวันที่ 12 พฤษภาคม 2019 เวลาประมาณ 00:00 UTC เราได้รับการแจ้งเตือนเกี่ยวกับการเพิ่มสิทธิ์ที่ไม่คาดคิดสำหรับบัญชีผู้ใช้ใหม่โดยสมาชิกหลายคนในชุมชน ผู้ใช้ที่ไม่มีใครรู้จักได้รับการเข้าถึงระดับโมเดอเรเตอร์และผู้พัฒนาในทุกไซต์ในเครือข่าย Stack Exchange การตอบสนองทันทีของเราคือการเพิกถอนสิทธิ์และการระงับบัญชีนี้จากนั้นจึงกำหนดกระบวนการเพื่อระบุและตรวจสอบการกระทำที่นำไปสู่เหตุการณ์

หลังจากการค้นพบครั้งแรกเราพบว่าการเพิ่มสิทธิ์เป็นเพียงส่วนเล็ก ๆ ของภูเขาน้ำแข็งและการโจมตีดังกล่าวส่งผลให้มีการขุดซอร์สโค้ดของเราและการเปิดเผย PII (อีเมลชื่อจริงที่อยู่ IP) โดยไม่ได้ตั้งใจ ของ Stack Exchange Network (ทุกคนได้รับแจ้ง) โชคดีที่ไม่มีฐานข้อมูลใดเลย - ไม่เป็นสาธารณะ (อ่าน: เนื้อหา Stack Exchange) หรือส่วนตัว (Teams, Talent หรือ Enterprise) - ถูก exfilted นอกจากนี้ยังไม่มีหลักฐานใด ๆ เกี่ยวกับการเข้าถึงโครงสร้างพื้นฐานเครือข่ายภายในของเราโดยตรงและในเวลาไม่นานผู้โจมตีก็ไม่เคยเข้าถึงข้อมูลในผลิตภัณฑ์ Teams, Talent หรือ Enterprise

และจากย่อหน้าสุดท้าย:

เหตุการณ์นี้เตือนเราเกี่ยวกับแนวทางปฏิบัติด้านความปลอดภัยขั้นพื้นฐานที่ทุกคนควรปฏิบัติตาม:

1. บันทึกการจราจรขาเข้าทั้งหมดของคุณ เราเก็บบันทึกการเชื่อมต่อที่อยู่ในขอบเขตทั้งหมด สิ่งนี้เปิดใช้งานการตรวจสอบทั้งหมดของเรา คุณไม่สามารถตรวจสอบสิ่งที่คุณไม่ได้บันทึก
2. ใช้ 2FA ระบบที่เหลืออยู่ซึ่งยังคงใช้การพิสูจน์ตัวตนแบบเดิมอาจเป็นช่องโหว่ที่ใหญ่ที่สุดของคุณ
3. ป้องกันความลับได้ดีขึ้น TeamCity มีวิธีปกป้องความลับ แต่เราพบว่าเราไม่ได้ใช้มันอย่างสม่ำเสมอ ให้ความรู้แก่วิศวกรว่า "ความลับจะไม่เพียงแค่รหัสผ่าน”. คีย์ SSH ป้องกันและฐานข้อมูลการเชื่อมต่อสายเกินไป. เมื่อสงสัยปกป้องมัน. ถ้าคุณต้องเก็บความลับใน repo Git ปกป้องพวกเขาด้วยGit-ฝังศพใต้ถุนโบสถ์หรือBlackbox
4. ตรวจสอบคำขอของลูกค้า คำขอจากลูกค้าที่ผิดปกติยิ่งมีความสำคัญมากขึ้นในการตรวจสอบว่าคำขอนั้นถูกต้องตามกฎหมายหรือไม่
5. รายงานความปลอดภัยอย่างจริงจัง เรารู้สึกขอบคุณที่ชุมชนของเรารายงานกิจกรรมที่น่าสงสัยอย่างรวดเร็ว ขอบคุณ!

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

Answer 1

คุณสามารถแสดงความคิดเห็นเกี่ยวกับความตั้งใจของผู้โจมตีได้หรือไม่?

ปรากฏว่าเป็นไปตามเป้าหมาย / ข้อมูลบางอย่าง (ผู้ใช้) หรือไม่?

หรืออาจจะเป็น "วัยรุ่นขี้สงสัย" มากกว่าที่จะจิ้มด้วยไม้เพื่อดูว่าพวกเขาจะไปได้ไกลแค่ไหน?

---

ปล. ขอบคุณสำหรับการเปิดกว้างเกี่ยวกับเรื่องนี้ขอขอบคุณจริงๆ!

Answer 2

บรรทัดนี้:

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

ทำให้ฟังดูเหมือนตามเวลาจริงในขณะที่การโจมตีเกิดขึ้นคุณสามารถระบุได้ว่าผู้โจมตีจะทำอะไรตามสิ่งที่พวกเขาเยี่ยมชมบน Stack Overflow แทนที่จะเป็นสิ่งที่พวกเขาทำโดยการดูสิ่งที่พวกเขาดู (หลังการโจมตี) ทางนิติเวช คุณหมายถึงอันไหน

Answer 3

คำถามมากมายที่เกี่ยวข้องกับผู้โจมตีเป็นหลัก:

1. เกิดอะไรขึ้นกับผู้โจมตี?
2. คุณระงับบัญชีของพวกเขาหรือไม่?
3. SE ติดต่อผู้โจมตีได้ตลอดเวลาหรือไม่?
4. ทำไมคุณไม่เปิดเผยตัวตนของผู้โจมตี
5. มีใครพยายามใช้วิธีการโจมตีแบบเดียวกันนี้ในภายหลังหรือไม่?

Answer 4

มีวงจรการนอนหลับที่ตรวจพบได้ในตอนท้ายของเหตุการณ์หรือไม่?

แก้ไขเพื่อชี้แจง:

หลังจากรับรู้ถึงผู้โจมตีและเนื่องจากคุณติดตามการกระทำบางอย่างของพวกเขาในขณะที่พวกเขาคลี่คลายคุณสังเกตเห็นอะไรที่คล้ายกับวัฏจักรทางชีววิทยาทั้งแบบวันต่อวันและแบบย้อนหลังหรือไม่? เช่นการรับประทานอาหาร (พัก 1-2 ชั่วโมง) การนอนหลับ (รูปแบบการไม่ใช้งาน 8 ชั่วโมง) "งีบหลับ" (90 นาที) ฯลฯ ... ?

Answer 5

นี่ไม่ใช่ส่วนหนึ่งของเหตุการณ์ที่เกิดขึ้นจริง ๆ แต่เป็นข้อกังวลทั่วไปเกี่ยวกับมาตรการรักษาความปลอดภัยรอบบัญชีพนักงาน มีหลายขั้นตอนในเหตุการณ์นี้ แต่ขั้นตอนสุดท้ายคือการเพิ่มสิทธิ์ของบัญชี SE ฉันสามารถจินตนาการถึงวิธีที่ตรงไปตรงมามากกว่าการเข้าถึงผู้ดูแลระบบไปยังเซิร์ฟเวอร์ CI ผ่านอินสแตนซ์ dev เพื่อดำเนินการ SQL ในการผลิตและฉันสนใจในสิ่งที่การบรรเทาและแนวทางปฏิบัติด้านความปลอดภัยที่ SE นำมาใช้เพื่อป้องกันความพยายามที่ง่ายกว่าในการได้รับ เข้าถึงบัญชีพนักงาน

คุณไม่สามารถวางไซต์ SE หลักไว้ด้านหลังไฟร์วอลล์ได้อย่างชัดเจนดังนั้นไซต์เหล่านี้จะถูกเปิดเผยเสมอ และวิธีการเข้าสู่ระบบภายใน SE ไม่มีวิธีการ 2FA ซึ่งฉันพบว่าค่อนข้างเกี่ยวข้อง

• บัญชีพนักงาน 2FA ได้รับการปกป้องด้วยวิธีการอื่น (หรือผู้ให้บริการล็อกอินอื่น ๆ ) หรือไม่?
• มีมาตรการใดบ้างเพื่อให้แน่ใจว่าไม่มีที่อยู่อีเมลส่วนตัวหรือผู้ให้บริการเข้าสู่ระบบเชื่อมโยงกับบัญชีพนักงานที่อาจมีความปลอดภัยน้อยกว่าและยังคงใช้เพื่อรับอีเมลกู้คืนเพื่อเข้าถึงบัญชีได้หรือไม่?
• มีการตรวจสอบความพยายามในการเข้าสู่ระบบจากแหล่งข้อมูลใหม่สำหรับบัญชีพนักงานหรือไม่
• มีการป้องกันเพิ่มเติมสำหรับเครื่องมือของพนักงานที่เป็นอันตรายในกรณีที่มีคนสามารถเข้าถึงเซสชันที่ทำงานอยู่ของบัญชีพนักงาน (เช่นต้องใช้รหัสผ่านและ / หรือโทเค็น 2FA อีกครั้งเมื่อเข้าถึงเครื่องมือที่มีความสำคัญด้านความปลอดภัย)

บางอย่างเช่นฟิชชิงหอกอาจยังคงเป็นหนึ่งในวิธีที่เป็นไปได้มากกว่าที่ผู้อื่นจะพยายามเข้าถึงบัญชีพนักงาน

Answer 6

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

เราขอคำอธิบายทั้งหมดได้ไหมว่าทำไมต้องปิดการใช้งาน Twitter oneboxing ในแชทอันเป็นผลมาจากเหตุการณ์ด้านความปลอดภัยนี้ บล็อกโพสต์ตีพิมพ์ในช่วงเวลาที่ระบุไว้ว่า "เวกเตอร์ที่มีศักยภาพอื่น ๆ" ก็ถูกปิดแล้วและข้อความพนักงานกุมภาพันธ์ 2020 ฉันเชื่อมโยงดังกล่าวระบุว่าทวิตเตอร์ oneboxing คุณสมบัติ "ทำให้การใช้หนึ่งในช่องว่างที่เราปิด" สิ่งนั้นคืออะไรและมันสร้างความเสี่ยงด้านความปลอดภัยอะไร?

สุดท้ายมีวิธีใดบ้างที่สามารถนำฟังก์ชันนี้กลับมาใช้งานได้อย่างปลอดภัย? ในเดือนสิงหาคม 2020 ไม่กี่เดือนหลังจากข้อความของเจ้าหน้าที่ด้านบนรายงานข้อบกพร่องที่ยื่นในเวลานั้นถูกทำเครื่องหมายสถานะโดยการออกแบบโดยพนักงานคนอื่น จะมีการพิจารณาคำขอคุณลักษณะเพื่อเปลี่ยนการออกแบบกลับ (ในลักษณะที่ปลอดภัย) หรือเป็นไปไม่ได้ที่จะทำเช่นนั้นโดยไม่เปิดเวกเตอร์การโจมตี

Answer 7

ฉันจะตั้งค่าสถานะว่าประเภทพารามิเตอร์ "รหัสผ่าน" ใน TeamCityไม่ถือว่าปลอดภัยทั้งหมด:

ค่ารหัสผ่านจะถูกเก็บไว้ในไฟล์คอนฟิกูเรชันภายใต้ TeamCity Data Directory ขึ้นอยู่กับการตั้งค่าการเข้ารหัสของเซิร์ฟเวอร์ค่านี้อาจมีสัญญาณรบกวนหรือเข้ารหัสด้วยคีย์ที่กำหนดเอง

ค่าล็อกการสร้างถูกซ่อนไว้ด้วยอัลกอริธึมการค้นหาและแทนที่แบบง่ายดังนั้นหากคุณมีรหัสผ่าน "123" เล็กน้อยการเกิด "123" ทั้งหมดจะถูกแทนที่ซึ่งอาจทำให้รหัสผ่านถูกเปิดเผย การตั้งค่าพารามิเตอร์เป็นชนิดรหัสผ่านไม่ได้รับประกันว่าจะไม่สามารถดึงค่าดิบได้ ผู้ดูแลโครงการทุกคนสามารถเรียกดูได้และนักพัฒนาที่สามารถเปลี่ยนสคริปต์การสร้างอาจเขียนโค้ดที่เป็นอันตรายเพื่อรับรหัสผ่าน

Answer 8

เหตุใดลิงก์วิเศษใน dev จึงสามารถดูได้กับ CM (น่าจะเป็นเพียงแค่ใน dev) ลิงก์มายากลจริง

Answer 9

นี่เป็นรายงานเหตุการณ์ที่ยอดเยี่ยมจริงๆ! หนึ่งในสิ่งที่ดีที่สุดที่ฉันเคยอ่าน

ขอบคุณ Stack ที่เผยแพร่สู่สาธารณะและคณบดีสำหรับการเขียนที่ยอดเยี่ยม!

ฉันแค่อยากรู้บางสิ่ง:

• ทีมเผชิญเหตุมีขนาดเท่าใด
• มีการปฏิบัติตามระเบียบการใด ๆ ในระหว่างการสอบสวนหรือไม่?
• ปัจจัยสำคัญอะไรที่เกี่ยวข้องกับการมีส่วนร่วมกับผู้จำหน่ายความปลอดภัยภายนอก อะไรคือประเด็นที่ได้รับการพิจารณาในการเลือกผู้ขายรายนั้น?
• ได้เรียนรู้บทเรียนอะไรบ้างจากผู้จำหน่ายความปลอดภัยภายนอก กระบวนการตรวจสอบของพวกเขาแตกต่าง (มีประสิทธิภาพ / ไม่มีประสิทธิผล) จากกระบวนการที่ทีมใช้อยู่แล้วหรือไม่?

บทความนี้ให้ภาพรวมที่ดีเกี่ยวกับสถาปัตยกรรมทั้งหมดของ Stack และกระบวนการพัฒนา อ่านรายละเอียดเพิ่มเติมจะหรือลิงค์หากมีบทความเกี่ยวกับเรื่องนี้จะดีมาก

Answer 10

ภายใต้ "คำแนะนำสำหรับผู้อื่น":

บันทึกการจราจรขาเข้าทั้งหมดของคุณ เราเก็บบันทึกการเชื่อมต่อที่อยู่ในขอบเขตทั้งหมด สิ่งนี้เปิดใช้งานการตรวจสอบทั้งหมดของเรา คุณไม่สามารถตรวจสอบสิ่งที่คุณไม่ได้บันทึก

เครือข่ายที่ไม่ว่างอย่าง Stack Exchange จะบันทึกการรับส่งข้อมูลขาเข้าทั้งหมดได้อย่างไร บันทึกเหล่านี้เป็นรายการเว็บเซิร์ฟเวอร์หรือโฟลว์ IP หรือเซสชัน TCP เต็มหรือไม่

ฉันสามารถบันทึกรายการและความพยายามในการเชื่อมต่อส่วนใหญ่บนเครือข่ายขนาดเล็กของฉันได้ แต่ฉันไม่รู้ว่าเครือข่ายขนาดใหญ่ดังกล่าวทำได้อย่างไร

Answer 11

คุณสามารถอธิบายให้ชัดเจนขึ้นได้หรือไม่ว่า"คุณสมบัติที่สามารถเข้าถึงได้โดยสาธารณะ"หมายถึงอะไรในข้อความอ้างอิงด้านล่างนี้

เรามีฐานข้อมูลที่มีบันทึกการเข้าชมทั้งหมดของคุณสมบัติที่เข้าถึงได้โดยสาธารณะของเรา