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

เกตเวย์สิ้นสุดอุโมงค์ จึงมองเห็นภายใน

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

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

การเปิดเผยสามอย่างที่ขนาดไม่เท่ากัน

แบ่งคำถามเป็นการรับส่งที่ผ่าน ระบบที่เข้าถึงได้ และความลับที่จัดเก็บไว้ แล้วตอบแต่ละข้อแยกกัน

ExposureWhat the attacker gainsWhat does not follow
Carried trafficPlaintext of whatever the tunnel forwards without its own encryptionKeys for TLS sessions that terminate at the application
Reachable systemsWhatever the backends accept from the gateway's addressControl of every connected client endpoint
Stored secretsThe specific keys, tokens and accounts present on that hostPossession of every client certificate or of a CA key

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

แถวล่างกำหนดว่าเหตุการณ์จะกินเวลานานเท่าใด คีย์เซิร์ฟเวอร์และคีย์ CA มีรัศมีผลกระทบต่างกันโดยสิ้นเชิง เช่นเดียวกับบัญชีผู้ดูแลระบบภายในและโทเคนตรวจสอบแบบอ่านอย่างเดียว

HTTPS ภายในอุโมงค์ยังคงเป็น HTTPS

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

ดังนั้นคำตอบว่าพวกเขาเห็นอะไรจึงมีเงื่อนไข และควรบันทึกเป็นเงื่อนไขแทนการประกาศเป็นคำตัดสิน

อะไรต้องเปลี่ยนก่อนจะไว้วางใจอีกครั้ง

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

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

ss -lntup
getent passwd
crontab -l
ip route show table all

รายการนั้นเป็นวิธีที่เร็วที่สุดในการดูว่าโฮสต์เสนออะไรและเข้าถึงได้ไกลแค่ไหน รักษาหลักฐานไว้ก่อน ตามกระบวนการของเจ้าของการตอบสนอง เพราะการสร้างใหม่ทำลายสิ่งที่การสอบสวนต้องการพอดี NIST SP 800-61 ฉบับปรับปรุง 3 มองว่าการเตรียมพร้อม การตรวจจับ การตอบสนอง และการกู้คืนเป็นส่วนหนึ่งของกระบวนการความเสี่ยงเดียว ไม่ใช่คำแนะนำให้รีสตาร์ต

ขอบเขตที่ทำให้ครั้งต่อไปถูกลง

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

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

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