รีวิวการตรวจสอบความปลอดภัย Mullvad VPN
(x41-dsec.de)- X41 ตรวจสอบแอป Mullvad VPN ด้วยการทดสอบเจาะระบบแบบ white-box ที่รวมถึง การเข้าถึงซอร์สโค้ด และจัดทำ threat model แบบเบาร่วมด้วย
- ขอบเขตการตรวจสอบคือโค้ด Android 2024.8-beta1, iOS 2024.8 และ Desktop 2024.6 โดยถือว่าทำงานบน 5 แพลตฟอร์ม ได้แก่ Linux, Windows, macOS, Android, iOS
- การทดสอบพบ ช่องโหว่ 6 รายการ แต่โดยรวมแล้วแอป Mullvad VPN แสดงระดับความปลอดภัยสูงตาม threat model ในรายงาน
- ประเด็นที่ร้ายแรงที่สุดคือความเสียหายของหน่วยความจำจาก race condition ใน signal handler และการละเมิด temporal safety แต่ระดับความรุนแรงลดลงเพราะผู้โจมตีต้องอาศัยข้อบกพร่องอื่นเพื่อกระตุ้นสัญญาณก่อน
- ช่องโหว่บางรายการอาจนำไปสู่การรั่วไหลของข้อมูลระบุตัวผู้ใช้โดยผู้โจมตีในเครือข่ายใกล้เคียง หรือ side-channel attack ภายใต้เงื่อนไขเฉพาะ และ Mullvad VPN AB ได้นำการแก้ไขไปใช้ได้อย่างรวดเร็ว
ขอบเขตการตรวจสอบและลักษณะของเป้าหมาย
- X41 ดำเนินการ ทดสอบเจาะระบบแบบ white-box กับแอปพลิเคชัน VPN ของ Mullvad
- มีการเข้าถึงซอร์สโค้ด และรวมถึงการจัดทำ threat model แบบเบาด้วย
- ซอร์สโค้ดที่ตรวจสอบเป็นเวอร์ชันต่อไปนี้
- แอปเป้าหมายมีขนาดใหญ่และทำงานบน 5 แพลตฟอร์ม ทำให้การตรวจสอบมีความยากสูง
- แพลตฟอร์มที่รองรับคือ Linux, Windows, macOS, Android, iOS
- Mullvad VPN มีการตรวจสอบเป็นประจำมาโดยตลอด และการพบช่องโหว่ใหม่ในโค้ดเดิมแสดงให้เห็นว่า เมื่อพิจารณาจากความซับซ้อนของผลิตภัณฑ์แล้ว ยังจำเป็นต้องมีการทบทวนความปลอดภัยอย่างต่อเนื่อง
- สำหรับเป้าหมายที่มีความ成熟สูง ประเด็นที่พบมักมีแนวโน้มย้ายไปอยู่ในพื้นที่ที่อยู่นอกเหนือการควบคุมโดยตรงหรือจุดโฟกัสของทีมพัฒนาแอปพลิเคชัน
- ลักษณะการทำงานของระบบปฏิบัติการ
- ปฏิสัมพันธ์ระหว่างเลเยอร์เครือข่ายและโปรโตคอลที่แตกต่างกัน
ผลการค้นพบและการประเมินความปลอดภัย
- การทดสอบของ X41 พบ ช่องโหว่รวม 6 รายการ
- แอปพลิเคชัน Mullvad VPN แสดงระดับความปลอดภัยสูงตาม threat model ในรายงาน
- รูปแบบการเขียนโค้ดและการออกแบบที่ปลอดภัย
- การตรวจสอบและการทดสอบเจาะระบบเป็นประจำ
- สภาพแวดล้อมการรันที่ได้รับการ hardening
- ช่องโหว่ที่ร้ายแรงที่สุดคือความเสียหายของหน่วยความจำจาก race condition ในโค้ด signal handler และการละเมิด temporal safety
- เมื่อโค้ด signal handler ถูกทริกเกอร์แล้ว ความเป็นไปได้ในการใช้โจมตีไม่ได้ดูต่ำ
- อย่างไรก็ตาม ผู้โจมตีต้องอาศัยข้อบกพร่องอื่นเพื่อกระตุ้นสัญญาณก่อน ทำให้ความรุนแรงโดยรวมลดลง
- ช่องโหว่อื่นอาจทำให้ผู้โจมตีในเครือข่ายใกล้เคียงรั่วไหลข้อมูลตัวตนของผู้ใช้ หรือทำให้เกิด side-channel attack ที่เปิดเผยเว็บไซต์ที่ไคลเอนต์กำลังเข้าถึงอยู่ภายใต้เงื่อนไขเฉพาะ
- side-channel attack ส่วนใหญ่ได้รับการบรรเทาแล้ว
- ข้อยกเว้นคือการโจมตีระดับโปรโตคอลที่เกิดจากการผสมผสานหลายเทคโนโลยี เช่น NAT และรูปแบบใหม่ของโปรโตคอล HTTP ซึ่งอยู่นอกขอบเขตการควบคุมของ Mullvad VPN AB
- ผู้ใช้ที่ต้องการความปลอดภัยและความเป็นส่วนตัวสูงขึ้นอาจพิจารณาเทคโนโลยี obfuscation และบริการพร็อกซีภายใน VPN ที่ได้รับการป้องกันเป็นทางเลือกได้
- Mullvad VPN AB แก้ไขประเด็นที่พบได้อย่างรวดเร็ว และมีการตรวจสอบแล้วว่าการแก้ไขทำงานได้ตามปกติ
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
หัวข้อของปัญหาที่พบ ได้แก่ การไม่มีสแต็กสำรองสำหรับ signal handler, การใช้ฟังก์ชันที่ไม่ปลอดภัยแบบ async, การรั่วไหลของที่อยู่ IP เสมือนของอุปกรณ์ tunnel, การทำให้ไม่เป็นนิรนามผ่าน NAT, การทำให้ไม่เป็นนิรนามผ่าน MTU, และ sideloading ระหว่างกระบวนการติดตั้ง เป็นต้น
โดยรวมแล้วเนื้อหาค่อนข้างตรงไปตรงมา และพึ่งพา DAITA (การป้องกันการวิเคราะห์ทราฟฟิกด้วย AI) อยู่มาก ซึ่งผมยังไม่เข้าใจทั้งหมด แต่ดูคุ้มค่าที่จะอ่านต่อ: https://mullvad.net/en/vpn/daita
แม้แต่ OpenSSH ก็เคยมีประเด็นที่เกี่ยวข้อง https://blog.qualys.com/vulnerabilities-threat-research/2024... และหากไม่มีกลไก function coloring อย่างชัดเจน ก็ดูยากที่จะสร้าง abstraction ที่ดีได้ในภาษาใด ๆ
ภาษา functional แบบบริสุทธิ์อย่าง Haskell อาจทำได้ก็เป็นได้
การใช้ฟังก์ชันที่ไม่ปลอดภัยแบบ async เป็นปัญหาที่พบได้บ่อย แต่โจมตีจริงได้ยาก และถ้าเป็นนักพัฒนาที่เคยจัดการ signal handler ก็น่าจะเคยพลาดแบบนี้สักครั้ง เพราะเป็นปัญหา timing ที่ทำซ้ำได้ยากมาก
การรั่วไหลของที่อยู่ ARP ไม่ใช่ปัญหาเฉพาะของ Mullvad เองเท่าไร และโจมตีได้เฉพาะในเครือข่ายโลคัล ส่วนการโจมตีเพื่อทำให้ไม่เป็นนิรนามนั้นใช้ได้กับ VPN ทุกเจ้า และแม้จะทำให้เป็นนิรนามมากขึ้นได้ แต่ก็มีต้นทุน
sideloading น่าจะเป็นปัญหาร้ายแรงที่สุด แต่ลำพังตัวมันเองก็ยังใช้โจมตีไม่ได้
อย่างไรก็ตาม การค้นพบ ช่องโหว่ heap corruption ในโปรแกรม Rust ที่ทำให้เกิดขึ้นจริงได้นั้นถือว่าจับประเด็นได้ดี
แต่การให้ช่องโหว่ถัดไปมีความรุนแรงสูงนั้นดูเป็นเชิงทฤษฎี ไม่มี proof of concept และก็ไม่ใช่ memory corruption จึงดูเหมือนเป็น การเฟ้อของระดับความรุนแรง
ส่วน threat model แยกต่างหากเป็นสิ่งที่บริษัท audit จำนวนมากมักข้ามไปในรายงาน
ผมมั่นใจว่า auditor ก่อนหน้านี้อย่าง Cure53, Assured และ Atredis ก็คงกำหนด threat model ที่เหมาะสมร่วมกับ Mullvad ไว้ล่วงหน้าแล้ว แต่ถ้าไม่ได้เขียนให้ผู้อ่านเห็นอย่างชัดเจน ก็มีช่องให้เข้าใจผลลัพธ์ผิดได้
ถ้าเป้าหมายมีสิทธิ์ออกเสียงเรื่องการ audit หรือวิธีโจมตี ผลลัพธ์ก็ยากที่จะไม่เอนเอียงเข้าข้างเป้าหมาย
วิธีที่เอนเอียงน้อยที่สุดน่าจะเป็นการที่เป้าหมายไม่รู้เลยว่า auditor จะทำอะไร
หาก Mullvad มีส่วนเกี่ยวข้องกับวิธีการหรือจำกัดขอบเขตการทดสอบ ผลลัพธ์ก็ไม่มีคุณค่าอยู่ดี
การยุติการรองรับ OpenVPN ก็ไม่ค่อยถูกใจผม เพราะมีบางกรณีใช้งานที่ผมต้องพึ่งมัน เลยคงจะย้ายไปใช้เจ้าอื่น
น่าเสียดาย เพราะใช้ดีมานาน
การเอา port forwarding ออกช่วยลดการใช้งานในทางที่ผิดที่ต้องจัดการลงได้มาก และกระทบแค่ผู้ใช้สายเนิร์ดสุดขั้วจำนวนน้อยมากเท่านั้น
ผมใช้ Mullvad กับทอร์เรนต์มาพักหนึ่งแล้ว และทอร์เรนต์ที่มี seed น้อยบางครั้งก็ใช้เวลานานกว่าจะเริ่ม แต่สุดท้ายก็โหลดได้
สื่อที่เฉพาะกลุ่มกว่านั้น บางทีก็ต้องคิดเผื่อไว้ล่วงหน้าหลายวัน
พูดตรง ๆ ผมคงไม่พิจารณาผู้ให้บริการที่ ไม่รองรับ OpenVPN เลย แล้วแบบนั้นจะมีความหมายอะไร
ไม่รู้ด้วยเหตุผลอะไร มันทำงานเป็น site-to-site VPN บนเราเตอร์ของผมได้ดีกว่าและเสถียรกว่ามาก
man wg)ทำงานได้ดี และยังซื้อรายเดือนได้ด้วย Bitcoin เพื่อความเป็นนิรนาม
ผมเข้าใจอะไรผิดไปหรือเปล่า?
ผมไม่ได้พยายามปิดบังว่าบางครั้งใช้ VPN, ISP เห็น tunnel เว็บไซต์ที่เข้าเห็น IP ของ VPN และใน netflow ก็มีเวลา ระยะเวลา ปริมาณข้อมูลที่ส่ง ฯลฯ เหลืออยู่
การใช้ VPN เองไม่ใช่ความลับ
ผมคิดว่าผู้ใช้ VPN ส่วนใหญ่เป็นคนธรรมดาแบบผม ที่ต้องการความเป็นส่วนตัวจากบริษัทโฆษณาออนไลน์และบริษัทเก็บรวบรวมข้อมูล
ไม่ต้องการหรือคาดหวังความเป็นส่วนตัวจากผู้ให้บริการ VPN อยู่แล้ว
ยังไงก็เชื่อมต่อบริการ VPN ของพวกเขาจาก IP ของ ISP บ้านที่เป็นบัญชีชื่อตัวเอง
ไม่ว่าคุณจะซ่อนการจ่ายเงินค่า VPN อย่างไร พวกเขาก็จะรู้ว่าคุณเป็นใคร
คนสายเทคนิค โดยเฉพาะคนสายความปลอดภัย มักไปไกลเกินไปกับเรื่องแบบนี้จนไม่สมจริง และรู้สึกว่าหลุดออกจาก threat model และกรณีใช้งานในโลกจริง
บทความสั้นของ James Mickens เรื่อง “This World of Ours” พูดถึงหัวข้อนี้ได้ดี: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
ในบรรดาแอป VPN ที่ทดสอบ มันเสถียรที่สุด และใช้ได้สูงสุด 5 อุปกรณ์ ต่อบัญชี
ถ้าพวกเขาไม่เก็บล็อกตามที่อ้าง ต่อให้รู้ข้อมูลอะไรเกี่ยวกับคุณก็ตาม IP ที่ตำรวจถามหาอาจถูกใช้โดยลูกค้าคนใดก็ได้ในหลายพันคน ดังนั้นถึงอยากส่งให้ทางการก็ส่งไม่ได้
ผมพลาดอะไรไปหรือเปล่า?
ดูเหมือนมีเรื่องไร้สาระอยู่ไม่น้อย และยังมีบรรยากาศว่า VPN ที่ “เจ๋ง” ต้องมาจากประเทศสแกนดิเนเวีย แต่ในความเป็นจริงส่วนใหญ่ไม่ได้เป็นแบบนั้น
อย่างดีก็เกี่ยวข้องกับบทความหลักแค่รอบนอก และถ้อยคำก็คลุมเครือจนฟังเหมือนกำลังบอกว่า Mullvad ทำอะไรไม่ดีอยู่
Mullvad ระบุว่าตั้งอยู่ในสวีเดน หรือคุณจะบอกว่าไม่ใช่อย่างนั้น? พวกเขายังเปิดเผยตำแหน่งเซิร์ฟเวอร์และเจ้าของด้วย
พวกเขาให้ข้อมูลค่อนข้างมากว่าทำไมควรหรือไม่ควรใช้ VPN, ไม่บันทึกข้อมูลลูกค้า, ย้ายไปใช้โครงสร้างพื้นฐานแบบ RAM-only และราคาถูกด้วยค่าบริการเหมาจ่ายแบบเดียว
อยากรู้ว่าตรงไหนกันแน่ที่เป็น เรื่องไร้สาระ และอยากให้พวกเขาทำอะไรต่างออกไป
ไม่เข้าใจทั้งว่าทำไมต้องเป็นแบบนั้น และทำไมมันไม่จริง
ถ้าพูดอย่างเป็นธรรม VPN ที่เน้นความเป็นส่วนตัวอย่างแข็งแรงที่ผมรู้จักและไม่ได้มาจากสแกนดิเนเวียก็มีแค่ ProtonVPN ประมาณนั้น
หลายปีก่อนตอนใช้ Nord ผมพบความล้มเหลวแบบเงียบ ๆ ที่มันแสดงว่าเชื่อมต่อแล้ว แต่จริง ๆ ไม่ได้เชื่อมต่อ VPN และเมื่อรายงานไป ก็ได้รับคำตอบว่าเป็นปัญหาที่รู้กันอยู่แล้ว ไม่ต้องกังวล
เท่าที่ผมรู้ พวกเขาไม่ได้ออกประกาศด้านความปลอดภัย
การที่พวกเขาไม่ได้ทุ่มเงินโฆษณามหาศาลบน YouTube หรือเว็บ affiliate กลับทำให้รู้สึกอุ่นใจ
ผมยังชอบที่บริษัทอยู่ในเขตอำนาจศาลที่ไม่ใช่เหมือนแหล่งพักพิงของบริษัทน่าสงสัย
สรุปคือผมชอบเพราะดูมีเรื่องไร้สาระน้อยและดูโอเค
ผมคงไม่รู้สึกว่าเชื่อถือ PIA หรือบริษัททำนองนั้นได้
ผมค่อนข้างมั่นใจว่าการบล็อกอย่างดุเดือดไม่ได้เป็นเพราะการใช้งานในทางที่ผิด แต่เพราะ VPN กลายเป็นปัญหาจริงสำหรับการติดตามและการขุดข้อมูล
บ่อยครั้ง exit server จะใช้ได้กับเว็บหนึ่งในสองเว็บนี้ แต่ใช้ไม่ได้กับทั้งคู่ ทำให้สงสัยว่ามีการประสานการบล็อก IP ระหว่าง YouTube กับ Reddit ในระดับหนึ่ง เพื่อทำให้การใช้ VPN น่ารำคาญและลดแรงจูงใจในการใช้
การขัดจังหวะการ ping-pong ระหว่างโซเชียลมีเดียสำหรับผู้ใช้ VPN ดูเป็นกลยุทธ์ที่มีประสิทธิภาพในการส่งผลต่อพฤติกรรม และทั้งสองก็แทบเป็นการผูกขาดโดยธรรมชาติ จึงแทบไม่มีความเสี่ยงว่าจะเสียผู้ใช้จากการทำแบบนั้น
คล้ายกับที่แบนเนอร์คุกกี้ถูกนำไปใช้ในทางที่ผิดเพื่อเปลี่ยนความรู้สึกของผู้คนต่อกฎระเบียบด้านความเป็นส่วนตัวให้เป็นประโยชน์ต่อการขุดข้อมูล
แม้แต่คนสายเทคนิคจำนวนมากก็ยังเชื่อว่าแบนเนอร์คุกกี้ที่น่ารำคาญเป็นความผิดของ EU แต่ในทางปฏิบัติจริง มักเป็นการปฏิบัติตามแบบมุ่งร้าย หรือไม่จำเป็น หรือผิดกฎหมายอย่างโจ่งแจ้ง
อย่างไรก็ดี มันน่ารำคาญจริง ๆ และรู้สึกเหมือนเป็นอีกแง่มุมหนึ่งของ enshittification ของเว็บโดยรวมและความไม่พอใจที่เพิ่มขึ้นอย่างรวดเร็ว
แทบจะถูกปฏิบัติเหมือนเป็น บุคคลต้องห้าม และ CAPTCHA จำนวนมากก็เป็นแค่การบล็อก แต่ดูเหมือนยังคาดหวังให้ช่วยเทรนฟรี ๆ