การโจมตีลดทอนความเป็นนิรนามแบบ 0-click ที่มุ่งเป้าแพลตฟอร์มอย่าง Signal และ Discord
(gist.github.com/hackermondev)- เมื่อแคชของ Cloudflare และการแจ้งเตือนแบบพุชทำงานร่วมกัน อาจเกิดการโจมตีลดทอนความเป็นนิรนามแบบ 0-click ที่สามารถ จำกัดตำแหน่งผู้ใช้ให้อยู่ในระยะหลายร้อยไมล์ จากโทรศัพท์ที่ติดตั้งแอปที่มีช่องโหว่ หรือแล็ปท็อปที่มีแอปทำงานอยู่เบื้องหลัง
- ผู้โจมตีทำให้อุปกรณ์เป้าหมายโหลดทรัพยากรที่อยู่หลัง Cloudflare โดยอัตโนมัติ จากนั้นตรวจสอบว่าทรัพยากรถูกแคชไว้ที่ ศูนย์ข้อมูล Cloudflare แห่งใด เพื่อประเมินพื้นที่ที่อยู่ใกล้เป้าหมาย
- Signal อาจดาวน์โหลดภาพแนบได้แม้ผู้ใช้ไม่ได้เปิดห้องสนทนา เนื่องจากแคชไฟล์แนบของ
cdn2.signal.orgและ การแจ้งเตือนแบบพุช บนมือถือ ส่วน Discord สามารถถูกโจมตีแบบเดียวกันผ่าน URL อวาตาร์ในแจ้งเตือนคำขอเป็นเพื่อนได้ - Cloudflare แพตช์บั๊กที่เกี่ยวข้องกับ Cloudflare Teleport ซึ่งใช้ส่งคำขอไปยังศูนย์ข้อมูลเฉพาะแล้ว แต่มีรายงานว่าแม้ใช้เซิร์ฟเวอร์ VPN ก็ยังเข้าถึงศูนย์ข้อมูล Cloudflare ทั้งหมดได้อีกประมาณ 54%
- Signal และ Discord โยนขอบเขตความรับผิดชอบไปที่ Cloudflare หรือฝั่งผู้ใช้ ขณะที่ Cloudflare ระบุว่าการปิดแคชสำหรับทรัพยากรที่ต้องปกป้องเป็นความรับผิดชอบของลูกค้า ทำให้ยังคงมีความเสี่ยงด้านความเป็นส่วนตัวที่พัวพันกับการออกแบบ แอป·CDN·การแจ้งเตือน
หลักการจำกัดตำแหน่งด้วยแคชของ Cloudflare
- การโจมตีนี้ใช้ ข้อมูลสถานะแคช ของ Cloudflare และศูนย์ข้อมูลที่กระจายตามภูมิศาสตร์เพื่อประเมินตำแหน่งโดยคร่าวของผู้ใช้
- Cloudflare ให้ข้อมูลผ่านเฮดเดอร์ตอบกลับสำหรับคำขอทรัพยากรที่แคชได้
cf-cache-statusแสดงHITหรือMISScf-rayมีรหัสสนามบินที่อยู่ใกล้ศูนย์ข้อมูลซึ่งประมวลผลคำขอ
- เมื่ออุปกรณ์เป้าหมายโหลดทรัพยากรของเว็บไซต์ที่อยู่บน Cloudflare ทรัพยากรนั้นอาจถูกแคชไว้ในศูนย์ข้อมูลใกล้เป้าหมาย
- จากนั้น หากตรวจสอบศูนย์ข้อมูล Cloudflare หลายแห่งและพบว่าทรัพยากรถูกแคชไว้ที่ใด ก็สามารถประเมินพื้นที่ที่อยู่ใกล้เป้าหมายได้
- Cloudflare อธิบายว่าบริษัทดำเนินศูนย์ข้อมูลหลายร้อยแห่งในกว่า 120 ประเทศและ 330 เมือง และผู้ที่อาศัยในประเทศพัฒนาแล้วมีแนวโน้มสูงที่ศูนย์ข้อมูลที่ใกล้ที่สุดจะอยู่ภายในระยะ 200 ไมล์
Cloudflare Teleport และการวนตรวจศูนย์ข้อมูล
- โดยทั่วไป ช่วง IP ของ Cloudflare ทำงานแบบ anycast ทำให้ผู้ใช้ไม่สามารถร้องขอการเชื่อมต่อ TCP โดยตรงไปยังศูนย์ข้อมูลเฉพาะได้
- Cloudflare Teleport ถูกสร้างขึ้นจากโพสต์ในฟอรัมชุมชนที่ระบุว่า สามารถใช้ Cloudflare Workers และช่วง IP ภายในของ Cloudflare WARP เพื่อเลี่ยงส่งคำขอ HTTP ไปยังศูนย์ข้อมูลเฉพาะได้
- Cloudflare Teleport เป็นพร็อกซีบน Cloudflare Workers และเป็นเครื่องมือที่ระบุค่า
coloเพื่อส่งคำขอไปยังศูนย์ข้อมูลที่ต้องการได้- ตัวอย่างเช่น ใช้โค้ดอย่าง
SEAซึ่งหมายถึงศูนย์ข้อมูล Seattle - ข้อมูลการจับคู่ระหว่างช่วง IP เฉพาะกับศูนย์ข้อมูลถูกจัดเป็นรูปแบบ
colos.json
- ตัวอย่างเช่น ใช้โค้ดอย่าง
- ภายหลัง Cloudflare แพตช์บั๊กนี้อย่างสมบูรณ์แล้ว และเครื่องมือ Teleport ไม่ทำงานด้วยวิธีดังกล่าวอีกต่อไป
พิสูจน์แนวคิดด้วย favicon ของ Namecheap
- การตรวจสอบครั้งแรกใช้
favicon.icoของ Namecheap - ทรัพยากรดังกล่าวเป็นภาพสแตติกธรรมดาที่เปิดใช้แคชของ Cloudflare และไม่มีการป้องกันบอทที่เข้มงวด จึงถูกเลือกเป็นเป้าทดสอบ
- เครื่องมือ CLI แสดงรายชื่อศูนย์ข้อมูลที่แคชทรัพยากรและอายุของแคชสำหรับ URL ที่ระบุ
- แม้ Namecheap ตั้งอายุแคชไว้ต่ำมากเพียง 5 นาที แต่ก็สามารถตรวจสอบศูนย์ข้อมูลที่แคช favicon ภายใน 5 นาทีล่าสุดได้
- เนื่องจากเบราว์เซอร์ดาวน์โหลด favicon โดยอัตโนมัติเมื่อเปิดเว็บไซต์ ผลลัพธ์นี้จึงเป็นการพิสูจน์แนวคิดที่แสดงว่าผู้ใช้จากหลายพื้นที่เข้าเยี่ยมชม Namecheap.com ภายใน 5 นาทีล่าสุด
การนำไปใช้กับ Signal
- Signal ใช้ CDN สองแห่งสำหรับให้บริการคอนเทนต์
cdn.signal.org: อิง CloudFront ใช้สำหรับอวาตาร์โปรไฟล์cdn2.signal.org: อิง Cloudflare ใช้สำหรับไฟล์แนบในข้อความ
- เส้นทาง
https://cdn2.signal.org/attachments/*มีการตั้งค่าแคชของ Cloudflare ดังนั้นเมื่ออุปกรณ์ที่ได้รับไฟล์แนบดาวน์โหลดไฟล์นั้น ไฟล์อาจถูกแคชไว้ในศูนย์ข้อมูลใกล้อุปกรณ์ได้ -
วิธีแบบ 1-click
- เมื่อผู้ใช้ส่งไฟล์แนบใน Signal ไฟล์จะถูกอัปโหลดไปยัง
cdn2.signal.org - เมื่อผู้รับเปิดบทสนทนา อุปกรณ์จะดาวน์โหลดไฟล์แนบโดยอัตโนมัติ และสามารถจำกัดตำแหน่งผู้รับได้ด้วยวิธีประเมินภูมิศาสตร์จากแคช Cloudflare
- ในการทดสอบ มีการถอด SSL pinning ของแอป Signal เดสก์ท็อป และใช้ Burp ตรวจสอบคำขอและคำตอบ
- หากอุปกรณ์ฝั่งผู้โจมตีดาวน์โหลดไฟล์แนบก่อน แคชอาจเกิดในศูนย์ข้อมูลใกล้ผู้โจมตีและทำให้ผลปนเปื้อน จึงบล็อกคำขอ GET ไปยัง
cdn2.signal.org/attachments/*ในแอป Signal ฝั่งผู้โจมตี - ในการทดสอบจากนิวยอร์กโดยกำหนดเป้าหมายเป็นตัวเอง พบศูนย์ข้อมูล
EWRที่ Newark, NJ ซึ่งอยู่ห่างจากพิกัดจริงประมาณ 150 ไมล์
- เมื่อผู้ใช้ส่งไฟล์แนบใน Signal ไฟล์จะถูกอัปโหลดไปยัง
-
วิธีแบบ 0-click
- แอป Signal บนมือถือโดยค่าเริ่มต้นจะรวมผู้ส่งและข้อความไว้ใน การแจ้งเตือนแบบพุช
- ข้อความที่มีภาพแนบทำให้อุปกรณ์ดาวน์โหลดภาพจาก Signal CDN เพื่อนำไปแสดงทางด้านขวาของการแจ้งเตือน
- แม้เป้าหมายไม่ได้เปิดบทสนทนาใน Signal เมื่อมีการแจ้งเตือนแบบพุช ภาพแนบก็อาจถูกดาวน์โหลด และระหว่างนั้นจะเกิดแคชในศูนย์ข้อมูล Cloudflare ใกล้เป้าหมาย
- วิธีนี้นำไปสู่การโจมตีแบบ 0-click ที่ประเมินตำแหน่งปัจจุบันได้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้
- เนื่องจาก Signal เป็นบริการที่นักข่าว นักเคลื่อนไหว และผู้แจ้งเบาะแสใช้งาน จึงมีความเสี่ยงถูกนำไปใช้ในทางที่ผิด เช่น ติดตามบัญชี เชื่อมโยงตัวตน หรือประเมินตำแหน่งพนักงานที่พบกับนักข่าว
การนำไปใช้กับ Discord
- พบว่า Discord ก็เป็นแอปที่เสี่ยงต่อการโจมตีประเภทเดียวกัน เนื่องจากทรัพยากร CDN ที่ตั้งค่าแคชของ Cloudflare
- ในวิธีแบบ 1-click มีการใช้ อีโมจิแบบกำหนดเอง ที่สมาชิก Nitro ใช้ได้
- อีโมจิแบบกำหนดเองโหลดจาก Discord CDN
- สามารถแสดงได้ในหลายตำแหน่ง เช่น ข้อความ สถานะผู้ใช้ และช่อง
- ผู้โจมตีสามารถแสดงอีโมจิแบบกำหนดเองในสถานะผู้ใช้ แล้วรอให้เป้าหมายเปิดโปรไฟล์
- รายงาน HackerOne ฉบับเต็มที่ส่งให้ Discord เผยแพร่ไว้ใน Gist แยกต่างหาก
-
0-click ด้วยแจ้งเตือนคำขอเป็นเพื่อน
- การแจ้งเตือนแบบพุชบนมือถือของ Discord ถูกส่งในเหตุการณ์หลากหลาย นอกเหนือจากข้อความ
- เมื่อส่งคำขอเป็นเพื่อน จะเกิดการแจ้งเตือนแบบพุชบนอุปกรณ์มือถือของเป้าหมาย
- แม้เป้าหมายกำลังใช้งาน Discord อยู่ แจ้งเตือนคำขอเป็นเพื่อนก็จะถูกส่งไปยังอุปกรณ์มือถือเสมอ
- แจ้งเตือนคำขอเป็นเพื่อนมี URL อวาตาร์ ของผู้ใช้ที่ส่งคำขอ และโทรศัพท์จะดาวน์โหลดอวาตาร์นี้โดยไม่ต้องมีการโต้ตอบจากผู้ใช้เพื่อนำไปแสดงในแจ้งเตือน
- รูปแบบ URL อวาตาร์ของ Discord แตกต่างกันตามสถานการณ์
- แจ้งเตือนแบบพุช:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash} - การแสดงบนเว็บไซต์:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png - URL ทั้งสองชี้ไปยังภาพเดียวกัน แต่มีพาธต่างกันจึงถูกแคชแยกกัน ทำให้แยกแคชที่โหลดจากแจ้งเตือนแบบพุชออกจากแคชที่เกิดจากการแสดงโปรไฟล์ในแอปได้
-
ระบบอัตโนมัติ GeoGuesser
- ขั้นตอนโจมตี Discord แบบ 0-click ถูกทำให้เป็นอัตโนมัติด้วยบอท Discord ส่วนตัวชื่อ GeoGuesser
- บอทรับชื่อผู้ใช้ด้วยคำสั่งเดียว แล้วทำงานต่อไปนี้
- ใช้ข้อมูลยืนยันตัวตนบัญชีผ่าน Discord User API
- เปลี่ยนอวาตาร์ผู้ใช้เป็นภาพสุ่มเพื่อสร้างแฮชอวาตาร์ใหม่
- ส่งคำขอเป็นเพื่อนไปยังผู้ใช้ที่ระบุ
- ดำเนินการโจมตีแจกแจงแคชผ่าน API ส่วนตัวที่อิง Cloudflare Teleport CLI
- แสดงผลใน Discord ภายในเวลาไม่ถึง 30 วินาที
- ในการสาธิตกับ Stanislav Vishnevskiy CTO ของ Discord พบว่าศูนย์ข้อมูล Cloudflare สองแห่งแคชอวาตาร์ไว้
- เหตุผลที่พบศูนย์ข้อมูลสองแห่งอาจเป็นเพราะมีหลายอุปกรณ์ได้รับแจ้งเตือน หรือคำขอจากอุปกรณ์เดียวกันถูกโหลดบาลานซ์ไปยังศูนย์ข้อมูลต่างกัน
- GeoGuesser ใช้ Google Maps API คำนวณจุดกึ่งกลางของศูนย์ข้อมูลทั้งสองแห่งและแสดงวงรัศมี
- ในแผนที่สาธิต สำนักงานใหญ่ของ Discord อยู่ใน San Francisco, CA และรวมอยู่ในวงนอก ส่วนตำแหน่งจริงถูกประเมินว่าอยู่ใกล้ขอบวงในซึ่งมีระยะประมาณ 300 ไมล์
- กระบวนการทั้งหมดเสร็จในเวลาน้อยกว่า 1 นาที และการโจมตีแทบตรวจจับได้ยากมาก
Bug bounty และการตอบสนองของแต่ละองค์กร
- Signal ปฏิเสธรายงานทันที พร้อมระบุว่าไม่เคยพยายามทำซ้ำฟีเจอร์ความเป็นนิรนามระดับเครือข่ายอย่าง WireGuard, Tor หรือซอฟต์แวร์ VPN โอเพนซอร์สอย่างสมบูรณ์
- ข้อโต้แย้งต่อ Signal อิงกับข้อเท็จจริงที่ว่า Signal ทำการตลาดเป็นแพลตฟอร์มสื่อสารที่ให้ความสำคัญกับความเป็นส่วนตัว และผู้ใช้คาดหวังว่าความเสี่ยงด้านความเป็นส่วนตัวนอกเหนือจากการเข้ารหัสแบบ end-to-end จะถูกลดให้น้อยที่สุด
- Telegram ถูกกล่าวถึงเป็นตัวอย่างที่ไม่เสี่ยงต่อการโจมตีนี้
- ใช้โปรโตคอลของตนเองที่ไม่พึ่งพา HTTP
- ไม่พึ่งพาแคชของผู้ให้บริการคลาวด์อย่าง Cloudflare
- ทีมความปลอดภัยของ Discord ตอนแรกระบุว่าจะพิจารณาการเปลี่ยนแปลงเพื่อปกป้องผู้ใช้ แต่ภายหลังเปลี่ยนจุดยืนว่าเป็นปัญหาของ Cloudflare ที่ลูกค้า Cloudflare รายอื่นก็เสี่ยงเช่นกัน
- Cloudflare แพตช์บั๊กที่ Cloudflare Teleport ใช้สำหรับวนตรวจศูนย์ข้อมูล
- บั๊กดังกล่าวเคยถูกรายงานใน HackerOne โดยผู้รายงานรายอื่นเมื่อ 1 ปีก่อน แต่ในตอนนั้นถูกประเมินว่าไม่มีผลกระทบ
- หลังการแชร์งานวิจัยนี้ Cloudflare เปิดรายงานเดิมขึ้นมาใหม่และแก้ไข พร้อมจ่าย bounty รายละ 200 ดอลลาร์ให้ทั้งผู้รายงานเดิมและรายงานครั้งนี้
ปัญหาที่ยังเหลือหลังแพตช์
- สิ่งที่ Cloudflare แพตช์คือบั๊กที่ทำให้วนตรวจศูนย์ข้อมูลจากเครือข่ายภายในได้ แต่เงื่อนไขหลักของการประเมินตำแหน่งจากแคชไม่ได้หายไป
- ระบุว่าหลังแพตช์ การโจมตีที่กล่าวถึงในบทความยังถูกดำเนินการได้ภายใน 24 ชั่วโมงที่ผ่านมา
- Cloudflare Teleport ถูกนำมาทำใหม่ด้วยวิธีที่อิง VPN หลังแพตช์ 24 ชั่วโมง
- ผู้ให้บริการ VPN ที่เลือกมีเซิร์ฟเวอร์มากกว่า 3,000 เครื่องใน 31 ประเทศ
- มีคำอธิบายว่าวิธีนี้ทำให้กลับมาเข้าถึงศูนย์ข้อมูล Cloudflare ทั้งหมดได้ประมาณ 54% และครอบคลุมพื้นที่ส่วนใหญ่ที่มีประชากรหนาแน่น
- จุดยืนสุดท้ายของ Cloudflare คือไม่มองว่าการโจมตีลดทอนความเป็นนิรนามนี้เป็นช่องโหว่ในระบบของตน และการปิดแคชสำหรับทรัพยากรที่ต้องการการปกป้องเป็นความรับผิดชอบของลูกค้า
- ลูกค้าอย่าง Discord มองว่าเป็นความรับผิดชอบของ Cloudflare ขณะที่ Cloudflare เห็นว่าลูกค้าควรปรับการแคชเอง ทำให้เส้นแบ่งความรับผิดชอบแตกต่างกัน
การป้องกันและนัยเชิงปฏิบัติ
- การโจมตีนี้แสดงให้เห็นว่าเมื่อฟีเจอร์ด้านประสิทธิภาพและความสะดวกอย่างแคชและการแจ้งเตือนแบบพุชมารวมกัน อาจถูกนำไปใช้ในทางที่ผิดเป็น เครื่องมือติดตาม ได้
- บั๊ก Cloudflare Teleport ถูกแพตช์แล้ว และแอปบางตัวอย่าง Signal·Discord อาจมีมาตรการบรรเทาหลังจากเผยแพร่ แต่ความเสี่ยงพื้นฐานยังคงอยู่
- แอปที่ให้บริการคอนเทนต์ผ่าน CDN และใช้แคชอาจเสี่ยงต่อการโจมตีประเภทเดียวกัน หากไม่มีความระมัดระวังที่เหมาะสม
- ทรัพยากรที่ต้องปกป้องควรพิจารณาร่วมกันทั้งนโยบายแคชของ CDN ภาพที่โหลดอัตโนมัติในแจ้งเตือนแบบพุช และพฤติกรรมแคชของ URL ที่มีเอกลักษณ์ต่อผู้ใช้แต่ละราย
- นักข่าว นักเคลื่อนไหว แฮกเกอร์ และผู้ใช้ที่อ่อนไหวต่อความเป็นส่วนตัวควรตระหนักว่า การแจ้งเตือนของแอปและการโหลดทรัพยากรภายนอกโดยอัตโนมัติอาจนำไปสู่การเปิดเผยตำแหน่งได้
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
เมื่อส่งรูปภาพให้ผู้ใช้ Signal ระบบจะดึงรูปผ่าน Cloudflare และแคชไว้ที่ศูนย์ข้อมูลใกล้ผู้ใช้นั้น จากนั้นสามารถตรวจสอบ สถานะแคช เพื่อดูได้ว่าใช้ศูนย์ข้อมูลใด
ถ้าผู้ใช้ไม่ได้อยู่ในพื้นที่ห่างไกล การเรียกสิ่งนี้ว่า การเปิดเผยตัวตน ก็ดูจะเกินจริงไปหน่อย แต่ก็ยังเป็นบทความที่น่าสนใจ
ถึงอย่างนั้น Cloudflare ก็คงไม่ไปแตะแคชที่ Seattle, Manchester หรือ Tokyo ดังนั้นแค่การจำกัดตำแหน่งของผู้ใช้ Signal ที่ไม่รู้จักให้เหลือเพียงตำแหน่งทางภูมิศาสตร์คร่าว ๆ ก็กลายเป็น เมทาดาทา สำคัญที่สามารถนำไปรวมกับข้อมูลอื่นเพื่อเปิดเผยตัวบุคคลได้ เป็นการโจมตีที่เจ๋งมาก
Cloudflare สามารถเห็นเมทาดาทาปริมาณมหาศาลจากแชตส่วนตัวและแชตกลุ่ม และติดตามได้ว่าใครเป็นคนส่งสื่อต้นทาง ใครอ่าน อ่านเมื่อไร ใครส่งต่อ และส่งต่อให้ใคร โดยดูจากขนาดไฟล์ แม้จะดูรูปหรือวิดีโอโดยตรงไม่ได้ แต่ถ้ารู้ขนาดล่วงหน้า หรือมารู้ภายหลังผ่านคำขอจากหน่วยงานบังคับใช้กฎหมาย เป็นต้น ก็เพียงพอแล้ว
แม้ข้อมูลเพียงเท่านั้นจะยังไม่พอ แต่ถ้ามีผู้ต้องสงสัยเฉพาะเจาะจง ก็ช่วยยืนยันได้ หากสามารถเข้าถึงบุคคลต้องสงสัยได้โดยตรง และยังเป็นเพื่อนกับโปรไฟล์ “สะอาด” ของเขาได้ ก็อาจใช้เทคนิคเดียวกันจับคู่โปรไฟล์ตำแหน่งทั้งสองได้ การเปิดเผยตัวตนไม่ใช่ข้อมูลชิ้นเดียว แต่เป็นกระบวนการที่ข้อมูลทุกชิ้นถูกเติมเข้าไปในโปรไฟล์เพื่อคัดกรองผู้ต้องสงสัยหรือยืนยันข้อสงสัย
ในที่นี้ “ผู้สืบค้น” หมายถึงคนทั่วไป ไม่ใช่เอเจนต์ AI หรือหน่วยงานบังคับใช้กฎหมาย หากเป็นหน่วยงานบังคับใช้กฎหมาย ก็น่าจะขอข้อมูลจาก Cloudflare ได้โดยตรงมากกว่านี้
ส่วนการเปิดเผยตัวตนในระดับและรูปแบบเฉพาะนี้จะเป็นปัญหากับกรณีใช้งานของตนเองหรือไม่ เป็นอีกคำถามหนึ่ง โดยส่วนตัวแล้ว ผมไม่ค่อยสนใจนักหากผู้ติดต่อที่คุยกันเห็นที่อยู่ IP ของผมโดยตรง แต่ผู้ใช้ทุกคนไม่ได้เป็นแบบนั้น
ในการสืบสวน Silk Road ข้อมูลระดับนั้นก็มีความสำคัญจริง ๆ Ulbricht เคยพลาดเผยโซนเวลาในช่วงแรก ๆ และนั่นช่วยให้ทางการสหรัฐฯ จำกัดวงได้ว่าเขาเป็นคนที่อยู่ในสหรัฐฯ หากไม่มีข้อมูลนั้น เขาอาจอยู่ที่ไหนก็ได้ในโลก
เป็นบทความที่ดี มีเทคนิคและแนวทางที่น่าสนใจ
อย่างไรก็ตาม คำว่า “เปิดเผยตัวตน” หรือ “ได้ตำแหน่งผู้ใช้” ดูจะเกินจริงไปบ้าง มันห่างไกลจากตำแหน่งที่แม่นยำ และ 150 ไมล์คือระยะทางบนทางหลวงประมาณ 2 ชั่วโมงจาก Atlanta, GA ไป Augusta, GA ภายในรัศมีนั้นน่าจะมีคนมากกว่า 700,000 คน
ฟีเจอร์ ดึงไฟล์แนบอัตโนมัติ ของ Signal น่ากังวลอยู่เล็กน้อย สำหรับเมสเซนเจอร์ส่วนตัว ผมคาดว่าจะมีตัวเลือกปิดใช้งานเหมือนการปิด JavaScript บน Tor แต่แม้อาจเป็นเพราะผมหาไม่ลึกพอ ผมก็ไม่เห็นฟีเจอร์แบบนั้น
ดูเหมือน Signal จะเลือกแนวทาง “ใช้งานได้ดีเป็นค่าเริ่มต้น” ที่สร้างสมดุลระหว่างความเป็นส่วนตัวกับความใช้งานง่าย เพื่อให้มีการใช้งานในวงกว้าง ผู้ใช้ที่กังวลจริง ๆ ก็น่าจะ harden Signal ตามคู่มืออย่าง https://www.privacyguides.org/articles/2022/07/07/signal-con... อยู่แล้ว สำหรับสถานการณ์ความเสี่ยงสูง ก็มีการแนะนำ VPN/พร็อกซีและการปรับการตั้งค่าเสมอมา
แคชก็จะไม่หายไป และ CloudFlare ก็จะไม่หายไปเช่นกัน ภัย DDoS ในล็อบบี้มัลติเพลเยอร์แบบ P2P ยุคก่อนที่ IP ถูกเปิดเผยดูจะใหญ่กว่านี้ และในบรรดาบุคคลที่สาม CloudFlare ดูจะตอบสนองได้ดีที่สุด หลักการคือไม่ควรแคชข้อมูลอ่อนไหว และเป็นความรับผิดชอบของแอปพลิเคชันที่สื่อสารกันที่จะบอก CDN หรือบริการตัวกลางว่าไม่ให้แคชรายการใดรายการหนึ่ง
เจ๋งมาก ต่างจากบางกรณี อันนี้ถือได้ชัดเจนว่าเป็นการ เปิดเผยตัวตนจากผู้ไม่ระบุตัวตน หรืออย่างน้อยก็ใกล้เคียงพอ ถ้ารู้ตำแหน่งของ Satoshi ได้ในรัศมี 250 ไมล์ ตอนนี้เขาจะยังคงไม่เปิดเผยตัวตนได้แค่ไหนกัน?
ถ้านำการโจมตีนี้ไปใช้ซ้ำ ๆ โดยซ่อนไว้ไม่ทางใดก็ทางหนึ่ง ก็สามารถติดตามการเคลื่อนที่ตามเวลาได้ โดยทั่วไปแค่มีตำแหน่งขนาดประมาณรหัสไปรษณีย์ 4–5 แห่ง ก็สามารถระบุตัวบุคคลได้แบบไม่ซ้ำใครแล้ว
วิธีที่ Apple และ Cloudflare ใช้ในซอฟต์แวร์ด้านความเป็นส่วนตัวของตนเองก็อิงแนวคิดว่าภูมิภาคไม่ใช่ข้อมูลที่เปิดเผยตัวตน เช่น iCloud Private Relay ของ Apple หรือ WARP ของ Cloudflare และเมื่อเปิด Apple Private Relay IP ต้นทางจะถูกซ่อนไว้ แต่ IP ที่ทราฟฟิกถูก route ผ่านยังอยู่ในประเทศเดียวกัน
https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
การโจมตีนี้น่าสนใจและใหม่ในเชิงวิชาการ แต่ไม่ใช่ “การเปิดเผยตัวตนจากผู้ไม่ระบุตัวตน”
แน่นอนว่าอาจไม่ใช่เขา และอาจเป็นผู้ใช้ยุคแรกแบบสุ่มคนหนึ่งก็ได้ ถึงอย่างนั้นผมก็มองว่ามีความเป็นไปได้ระดับหนึ่งว่าเป็นเขา
รายละเอียดเพิ่มเติม: https://news.ycombinator.com/item?id=29728339
ไม่สนับสนุนความพยายามที่จะค้นหาและเปิดเผยชื่อกับที่อยู่ของเขา เพราะอาจทำให้ชีวิตเขาลำบากได้ แต่ในแง่นามธรรมแล้ว มันน่าสนใจมากในฐานะปริศนาที่ยังคลี่คลายไม่ได้ แม้จะมีสายตาจำนวนมากจับจ้องมาหลายปี
ไม่เข้าใจว่าทำไมคอมเมนต์อันดับต้น ๆ จำนวนมากถึงมองความร้ายแรงต่ำขนาดนี้ นี่คือการโจมตีแบบที่ทำให้หน่วยงานบังคับใช้กฎหมายหรือผู้ไม่ประสงค์ดีสามารถสร้าง หลักฐานตำแหน่งที่อยู่ ได้พอดี
การพิสูจน์ตำแหน่งที่อยู่ไม่ใช่การเปิดเผยตัวตน โดยเฉพาะเมื่อ “ตำแหน่ง” นั้นกว้างขนาดนี้
ลองเมินไปก่อน แล้วดูว่าตอนเช้ายังเป็นปัญหาอยู่ไหม ระหว่างนั้นก็หวังว่าจะมีใครสักคนหาว่าทำไมมันถึงไม่ใช่ปัญหาให้ได้
ทำไม Signal ถึงเปิด แคช ไว้กับ URL พวกนั้น? กรณีที่พบบ่อยที่สุดน่าจะเป็นไฟล์แนบที่ถูกดาวน์โหลดครั้งเดียวแล้วจบ
ผมนึกว่าควรจะทำตรงกันข้าม คือไม่ให้ดาวน์โหลดได้มากกว่าหนึ่งครั้ง และลบทันทีหลังดาวน์โหลดสำเร็จครั้งแรก แน่นอนว่าไคลเอนต์อาจล้มเหลวกลางคัน จึงอาจมีช่วงผ่อนผันสำหรับดาวน์โหลดซ้ำได้ ถึงอย่างนั้นก็ดูไม่น่าใช่กรณีทั่วไป และหวังว่าการปิด CDN caching จะช่วยแก้ปัญหานี้ได้โดยไม่ทำให้ต้นทุนเพิ่มขึ้นมาก
อย่างไรก็ตาม คำว่า “เปิดเผยตัวตนจากผู้ไม่ระบุตัวตน” ตรงนี้ออกจะเป็น clickbait เล็กน้อย การจำกัดตำแหน่งของใครบางคนให้แคบลงเหลือประมาณ 250 ไมล์ไม่ใช่เรื่องดี แต่ก็ไม่ได้เปิดเผยตัวตนของคนคนนั้น
แก้ไข: ไม่ได้นึกถึงกรณีที่ไฟล์แนบถูกส่งในแชตกลุ่มแล้วมีหลายคนดาวน์โหลด แต่แม้ในกรณีนั้น ไฟล์แนบไม่ได้ถูกเข้ารหัสแยกให้แต่ละคนในกลุ่มหรือ? แน่นอนว่าผมก็ไม่รู้จริง ๆ ว่ามันทำงานอย่างไร
สิ่งที่พูดถึงนั้น คนที่ต้องการความเป็นส่วนตัว·ความปลอดภัยในระดับบ้าคลั่งแบบนั้นแทบจะตั้งค่าได้อยู่แล้ว สามารถตั้งให้ข้อความลบอัตโนมัติหลังดูแล้ว 30 วินาที ตั้งให้ route ทราฟฟิกทั้งหมดผ่านพร็อกซีได้ และยังปรับแต่งอื่น ๆ ได้อีกมากตามรสนิยมของผู้ใช้
เหตุผลที่แคชน่าจะเป็นเพราะ ค่าใช้จ่ายในการส่งข้อมูล ไฟล์แนบ ข้อความเสียง วิดีโอ ฯลฯ พอรวมกันแล้วก็ใหญ่
คนนี้คือ เด็กอายุ 15 ปี คนเดียวกับที่เจอช่องโหว่ยึด Zendesk Slack เมื่อไม่กี่เดือนก่อน [1]
[1]: https://news.ycombinator.com/item?id=41818459
รายงานบั๊กที่ส่งให้ Adobe นั้นก็แปลว่าเขาเขียนตอนอายุห้าขวบ: https://hackerone.com/daniel?type=user
แน่นอนว่านี่เป็น “การโจมตี” แต่ไม่ใช่ประเภทที่คนทั่วไปนึกถึงเมื่อพูดว่า zero-click ไม่มีการรันโค้ด แต่เป็นวิธีใช้ทริกบางอย่างเพื่อดูว่าศูนย์ข้อมูล Cloudflare แห่งใดแคชรูปภาพไว้ แล้วนำไปอนุมานพื้นที่คร่าว ๆ ของผู้ใช้
ถึงอย่างนั้นก็น่าประทับใจและให้มุมมองที่ลึกดี
คนกลุ่มนั้นสามารถร่วมมือกับทรัพยากรในพื้นที่เพื่อสืบสวนต่อได้ แค่รู้ว่าควรระดมทรัพยากรใดในพื้นที่ไหน ก็ช่วยประหยัดค่าใช้จ่ายได้มากแล้ว
อย่างที่บอก น่าประทับใจและให้มุมมองที่ลึกดี เอกสารดูเหมือนได้ความช่วยเหลือจาก ChatGPT อยู่บ้าง แต่มีหลายประโยคที่ชัดเจนและเจาะจงมาก สำหรับการใช้งานแบบนี้ถือเป็นกรณีใช้งานที่ยอดเยี่ยม จึงไม่ได้ตำหนิอะไร เป็นบทความที่ดี
ถ้าผมไม่ได้พลาดอะไรไป นี่ดูเหมือนเป็นวิธีที่อ้อมค้อมมากในการตรวจหา ตำแหน่ง IP ของผู้ใช้
เช่น เมื่อเชื่อมต่อ VPN แล้วตรวจ https://cloudflare.com/cdn-cgi/trace จะได้
colo:CPH(Copenhagen) ซึ่งอยู่ไกลจากศูนย์ข้อมูล CF ที่ใกล้ผมที่สุดในเชิงภูมิศาสตร์ และใกล้กับ Oslo ซึ่งเป็นตำแหน่ง IP ของผู้ให้บริการ VPN มากกว่า แต่ก็ยังไม่ได้ใกล้ขนาดนั้นถ้าไม่ใช้ VPN ก็ไม่ได้แสดงเมืองหลวงของประเทศที่ผมอยู่ตอนนี้ แต่แสดงศูนย์ข้อมูลที่อยู่ทางเหนือประมาณ 250 ไมล์ ดังนั้นผมจึงยากจะเห็นด้วยกับคำกล่าวที่ว่า Cloudflare จะคืนค่า “ศูนย์ข้อมูลที่พร้อมใช้งานที่ใกล้ที่สุด” เสมอ
ตัวบทความเองยอดเยี่ยมและน่าสนใจแน่นอน แต่ยังไม่มั่นใจเรื่องการใช้งานจริง
การใช้งานจริงและความเสี่ยงที่อาจเกิดขึ้นจะเกิดเมื่อข้อมูลนี้ถูกนำไปรวมกับข้อมูลอื่น เทคนิค de-anonymization โดยใช้ชุดข้อมูลแบบกระจัดกระจายเป็นสาขาวิจัยที่คึกคักมาอย่างน้อย 15 ปีแล้ว และผู้คนก็มักประหลาดใจว่าข้อมูลเพียงไม่กี่ชิ้นที่ดูไม่เกี่ยวข้องกันสามารถเปิดเผยอะไรได้มากแค่ไหน
มีเหตุผลที่แอปพลิเคชันต่าง ๆ ทุ่มความพยายามอย่างมากในการพร็อกซีคำขอทรัพยากรอย่างรูปภาพ และนั่นไม่ใช่ของฟรี
ประโยชน์ของการ แคชภาพไว้ใน CDN บน Signal คืออะไร?
ถ้าสมมติว่ามีการแคชในไคลเอนต์โลคัล จำนวนคำขอรวมต่อทรัพยากรนั้นควรน้อยมาก และส่วนใหญ่คงมีแค่ครั้งเดียว
แยกจากนั้น CloudFront น่าจะแก้ปัญหานี้ได้ง่ายมากหากไม่ส่งคืนเฮดเดอร์
cf-rayหรือมีตัวเลือกให้ลูกค้าลบออกได้ แต่ข้อมูลด้าน timing ก็อาจยังใช้อนุมานได้อยู่ดี“ความใกล้” ในที่นี้เป็น heuristic แบบประมาณ และเป็นคุณสมบัติของตาราง routing แบบ anycast ของเราเตอร์ BGP ที่คำขอวิ่งผ่าน ในทางปฏิบัติจึงใกล้กับ “เส้นทางที่เหมาะที่สุด” มากกว่า
cf-rayออก ก็แค่ดู เวลาในการตอบสนอง ได้อยู่ดี ถ้าต้องดึงทรัพยากรจากอีกทวีปหนึ่ง ก็น่าจะวัดได้อย่างเสถียรเว็บไซต์ที่พยายามซ่อนว่ามีผู้ใช้อยู่หรือไม่ก็คล้ายกัน หากส่งคำขอล็อกอินด้วยชื่อผู้ใช้ที่มีอยู่ ระบบจะทำ password hashing ซึ่งปกติทำให้เวลาตอบสนองเพิ่มขึ้นอย่างน้อย 50ms ส่วนชื่อผู้ใช้ที่ไม่มีอยู่จะจบก่อน วิธีแก้คือรันโค้ดชุดเดียวกันเสมอและทำ hashing เสมอ แต่มีเว็บไซต์น้อยมากที่ทำแบบนั้น หรือถ้าเข้ากับ threat model ก็อาจแจ้งทันทีว่าชื่อผู้ใช้ไม่มีอยู่ก็ได้
กลับมาที่กรณี Cloudflare หากไม่หน่วงการตอบสนอง ก็ไม่ช่วยอะไร แต่การหน่วงการตอบสนองเป็นสิ่งตรงข้ามกับสิ่งที่ Cloudflare ควรทำ
“การโจมตี” ในที่นี้คือผู้ใช้คนใดก็ได้สามารถส่งข้อความที่มี ลิงก์ไปยังทรัพยากรที่ถูกแคชไว้ใน CDN ให้ผู้ใช้อีกคนได้ ไม่ใช่หรือ? ผมอาจเข้าใจผิดก็ได้
ไม่ค่อยเข้าใจเท่าไร เคยมีใครมองว่า Signal เป็นบริการที่ ไม่ระบุตัวตน ด้วยหรือ? Discord ก็เหมือนกัน ถ้าอย่างนั้นก็มีข่าวร้าย ทั้งคู่ไม่ใช่บริการนิรนามเลย ไม่ใช่แม้แต่น้อย
พวกเขาไม่เคยอ้างแบบนั้นด้วยซ้ำ Signal อ้างแค่ว่าอ่านข้อความไม่ได้ ส่วน Discord ผมไม่ค่อยแน่ใจและก็สงสัยอยู่ แม้แต่คำอ้างนั้นก็ยังมีช่องโหว่ ต่อให้วิทยาการเข้ารหัสแข็งแกร่ง คุณได้ตรวจสอบเวอร์ชันที่ใช้อยู่ตอนนี้อย่างละเอียดและคอมไพล์เองหรือเปล่า?
อย่างมากก็เป็นแค่ การใช้นามแฝง แบบอ่อน ๆ เท่านั้น แอปพลิเคชันที่ยอมเสียสละความปลอดภัยบางส่วนเพื่อความสะดวกของผู้ใช้ การโหลดสื่อโดยค่าเริ่มต้นเป็นเรื่องที่พบเห็นได้เสมอ และใน threat model ทั่วไปก็เป็นทางเลือกที่โอเค การใส่สื่อในข้อความก็เป็นไม้ตายประจำของการโจมตีเพื่อเปิดเผยตัวตนมาโดยตลอด
สุดท้ายก็แค่แสดงให้เห็นว่า tracking pixel ยังเป็นเทคนิคที่ใช้ได้ผลอยู่ในปัจจุบัน ซึ่งก็ดี แต่ไม่น่าแปลกใจ
ถ้าอยากคงความเป็นนิรนาม ก็ไม่ควรใช้ Discord หรือ Signal และไม่แนะนำให้โพสต์บน HN ด้วย บางทีถ้าใช้บัญชีใช้แล้วทิ้งผ่าน Whonix, ไม่ใช้ JavaScript, ให้ LLM ภายในเครื่องเขียนข้อความใหม่ แล้วตั้งให้อัตโนมัติ paste ในเวลาสุ่ม ก็อาจพอมีโอกาสอยู่บ้าง แต่ถึงอย่างนั้นก็ไม่ควรรับประกัน
ความเป็นนิรนามไม่มีอยู่อีกต่อไปแล้ว