SpamChannel: ส่งอีเมลสวมรอยจากมากกว่า 2 ล้านโดเมนและกลายเป็นซาตานโดยพฤตินัย [PDF]
(media.defcon.org)- งานนำเสนอ DEFCON 31 2023 SpamChannel ว่าด้วยปัญหาการสวมรอยอีเมลที่กระทบโดเมนมากกว่า 2 ล้านโดเมน โดยเริ่มจากความพยายามส่งอีเมลผ่าน Cloudflare Worker
- การทดลองหลักเริ่มจากการทำให้การส่งอีเมลเป็นแบบ เขียนโปรแกรมได้ แทนการทำด้วยมือ และเชื่อมเข้ากับขั้นตอนการดีพลอย Worker
- Cloudflare Workers ถูกแนะนำในฐานะสภาพแวดล้อม serverless computing ที่รองรับ JavaScript, TypeScript และ WASM
- ขั้นตอนพื้นฐานคือสร้างโปรเจ็กต์ด้วย
npm create cloudflare@latestและดีพลอยด้วยnpx wrangler deploy - เบาะแสในการส่งอีเมลจาก Workers เชื่อมโยงต่อจากบทความบล็อกของ Cloudflare เรื่อง การเชื่อมต่อ MailChannels
จุดเริ่มต้นของงานนำเสนอ SpamChannel
- SpamChannel คือไฟล์ PDF ที่ Marcello Salvati(@byt3bl33d3r) นำเสนอใน DEFCON 31 2023 ว่าด้วยหัวข้อการส่งอีเมลสวมรอยจากมากกว่า 2 ล้านโดเมน
- เป้าหมายของงานนำเสนอคือการทำให้การส่งอีเมลเกิดขึ้นภายใต้เงื่อนไขต่อไปนี้
- ส่งอีเมลแบบ เขียนโปรแกรมได้
- ส่งผ่าน Cloudflare Worker
- มี ข้อความปฏิเสธความรับผิดชอบ เกี่ยวกับประเด็นทางกฎหมายว่า “อย่าก่ออาชญากรรม”
Cloudflare Workers และเบาะแสการส่งอีเมล
- Cloudflare Workers ถูกอธิบายว่าเป็นสภาพแวดล้อม serverless computing ที่ใช้ JavaScript, TypeScript และ WASM
- ขั้นตอนการใช้งานพื้นฐานมีดังนี้
npm create cloudflare@latest- สร้าง
worker.js npx wrangler deploy- หลังดีพลอยแล้วจะใช้งาน Worker ได้ที่ адресรูปแบบ
https://<YOUR_WORKER>.<YOUR_SUBDOMAIN>.workers.dev
- เอกสารเริ่มต้นเชื่อมไปที่ Cloudflare Workers Get started guide
- เบาะแสการส่งอีเมลสามารถดูได้จากบล็อก Cloudflare เรื่อง Sending email from Workers with MailChannels
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
วิดีโอการนำเสนอ: https://www.youtube.com/watch?v=NwnT15q_PS8
หรือดูได้ที่นี่ด้วย ใน Firefox ของผม รูปแบบวิดีโอใช้ไม่ได้ แต่เล่นได้ด้วย VLC: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...
https://www.youtube.com/watch?v=61PIOBp30vA
https://www.youtube.com/watch?v=eODw4t4WaCw
SPF พังในหลายรูปแบบมากกว่าที่การนำเสนอนี้พูดถึงเสียอีก จากมุมมองของคนที่ทำงานเป็นวิศวกรด้านการเสริมความปลอดภัยอีเมล/ช่วยเรื่องอัตราการส่งถึง คำแนะนำของผมคือให้โฟกัสที่ DKIM + DMARC มากกว่า SPF เสมอ
ด้วยเหตุผลด้านระบบเก่า SPF ยังจำเป็นอยู่ แต่ไม่ควรพึ่งพามันเพื่ออัตราการส่งถึงหรือการป้องกันการปลอมแปลงตัวตน
สไลด์ 54 บอกว่า DKIM + DMARC ไม่ช่วยกับการโจมตีนี้ แต่นั่นไม่ถูกทั้งหมด
คุณจะเปิดนโยบาย DMARC
p=rejectได้อย่างปลอดภัยก็ต่อเมื่อตั้งค่า DKIM ให้ผู้ส่งทั้งหมดที่มอบหมายสิทธิ์ไว้แล้ว และเมื่อถึงระดับนั้น ก็เริ่มตัด SPF ออกจากผู้ส่งบุคคลที่สามได้ โดยใช้ตัวแก้ไขแบบ neutral?ใน SPFเช่น
v=spf1 include:relay.mailchannels.net ~allจะกลายเป็นv=spf1 ?include:relay.mailchannels.net ~allแบบนี้ เมลที่มาจาก MailChannels จะถูกมองว่า SPF เป็น neutral สำหรับผู้รับที่รองรับ DMARC และจะหันไปใช้ DKIM ขณะที่บริการอีเมลเก่า ๆ ก็ยังควรยอมรับผลลัพธ์แบบ neutral ได้
ไม่ใช่วิธีแก้ที่สมบูรณ์แบบ แต่อีเมลก็ไม่มีทางเชื่อถือได้หรือปลอดภัย 100% อยู่แล้ว
ผมตั้งค่า SPF ให้อนุญาตเฉพาะ
$myIPมาโดยตลอด ถ้าจะส่งสแปมด้วยชื่อโดเมนของผม ก็ต้องเจาะ ISP หรือ registrar ก่อน และถ้าทำได้ขนาดนั้นก็คงขอใบรับรอง TLS ของโดเมนผมได้ด้วยแม้แต่ในองค์กรขนาดใหญ่ที่ต้อง allowlist ระบบส่งหลายตัว ผมก็ยังไม่รู้ว่าจะปลอมตัวเป็นหนึ่งในผู้ส่ง SPF ที่ถูกต้องได้อย่างไร ในสถานการณ์ที่ปลอมแปลงระเบียน DKIM ไม่ได้
กรณีที่เอาช่วง IP ที่ใคร ๆ ก็ใช้ได้แบบสาธารณะมาใส่ allowlist อย่างในการนำเสนอที่ถูกส่งมานั้น ก็เป็นแค่การตั้งค่าที่โง่เง่า
ถ้าจะปลอมทั้งการแลกเปลี่ยนเมลทั้งหมด ต้องใช้ทราฟฟิกระดับเทราไบต์เพื่ออีเมลไม่กี่ไบต์ และถ้าบังคับใช้ STARTTLS ก็จะเป็นไปไม่ได้
เราใช้ Cloudflare Workers + MailChannels ในโปรดักชันอยู่ ใจหายเลย
เดิมทีก็กำลังย้ายจาก CF Workers ไปยังเซิร์ฟเวอร์จริงอยู่แล้ว ตอนนี้ดูเหมือนต้องย้ายออกจาก MailChannels ด้วย
ความเสี่ยงด้านความปลอดภัยไม่คุ้มกับความสะดวก
_mailchannelsใน DNS ก็จะส่งอีเมลผ่าน MailChannels จาก Workers ไม่ได้“แสดงแบนเนอร์บนอีเมลทั้งหมดที่มาจากโดเมนที่ใช้ DKIM แต่ไม่มีลายเซ็น DKIM” ถ้าผมเข้าใจถูก เรื่องนี้ส่วนใหญ่ทำไม่ได้ เพราะไม่มีทางรู้แน่ชัดว่าโดเมนไหน ใช้งาน DKIM อยู่
ในทางทฤษฎี เราอาจ query DNS ไปที่
"_domainkey.example.com"เพื่อดูว่าเป็น NXDOMAIN หรือ NOERROR ได้ อย่างหลังมักหมายถึงมีซับโดเมนอยู่ และจึงอาจแปลว่ามีคีย์ DKIM บางส่วนใน DNSแต่เราไม่รู้ชื่อ selector และไม่รู้ด้วยว่าคีย์นั้นใช้งานอยู่จริง หรือแค่จะเปิดใช้ในภายหลัง
โดเมนหนึ่งอาจมีผู้ส่งที่ผ่านการรับรองหลายราย บางรายใช้ลายเซ็น DKIM แต่บางรายอาจไม่ใช้
DNS server ไม่ได้ทำตามมาตรฐานอย่างถูกต้องทั้งหมด ดังนั้นการแยก NXDOMAIN/NOERROR ก็ใช้ได้เพียงโดยประมาณเท่านั้น
ประโยคที่อ้างมาดูเหมือนหมายถึงให้ปฏิเสธเมลจาก MailChannels ที่ไม่มีลายเซ็น DKIM
“ลูกค้าหลักของ MailChannels คือผู้ให้บริการเว็บโฮสติ้งที่ไม่ได้เป็นเจ้าของโดเมนของอีเมลที่ตนส่ง” นี่เป็นข้ออ้างที่แย่ที่สุดข้อหนึ่งที่ได้ยินมาพักใหญ่
ผู้ให้บริการเว็บโฮสติ้งโดยทั่วไปไม่ได้ “เป็นเจ้าของ” โดเมนที่โฮสต์อยู่ก็จริง แต่ย่อมรู้อย่างชัดเจนว่าโฮสต์โดเมนใดบ้าง การ route โดเมนไปยังบัญชี/ไดเรกทอรีของลูกค้าคือหัวใจของเว็บโฮสติ้ง
สิ่งที่ต้องมีก็แค่ integration แบบ cPanel เพื่อรายงานรายชื่อโดเมน และผูกแต่ละโดเมนกับคีย์ที่สุ่มสร้างขึ้น
ทั้งหมดนี้สามารถและควร ทำให้เป็นอัตโนมัติ ได้ โดยไม่รบกวนผู้ใช้ปลายทาง
คงจะดีถ้าสเปก DMARC พัฒนาจนมีวิธีให้ใช้ เฉพาะ DKIM ในการตรวจสอบ ไม่ใช่ SPF น่าเสียดายที่สิ่งอย่างคำเชิญ Google Calendar ยังตรวจ DKIM ไม่ผ่านอยู่
https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
ผมมองว่าเป็นไอเดียที่ดีมาก เพราะเจ้าของโดเมนจะใช้ DMARC พร้อมกับระบุได้ว่า “กลไกที่รับรองทราฟฟิกของโดเมนฉันจริง ๆ ขอให้เป็น DKIM เท่านั้น”
ในวงการมีวิธีมากมายในการเลี่ยงจุดอ่อนของ SPF และ DMARC เช่น มาโคร SPF ที่ปรับการรับรองแบบไดนามิกตามเงื่อนไขที่รู้ได้เฉพาะตอนตีความ SPF
แต่ไม่มีทางเลี่ยงใดดีกว่าการพูดว่า “โดเมนของฉัน ขอให้ใช้ DKIM เท่านั้น”
ช่วงนี้ผมเพิ่งเจอเรื่องการเตรียมอีเมลสำหรับโดเมนของตัวเองโดยตรง และหงุดหงิดแทบคลั่ง โดยเฉพาะกับ ISP ที่กำหนดว่า “ถ้าจะส่งอีเมลจากอุปกรณ์ของตัวเอง ต้องเป็นบัญชีธุรกิจ” เรื่องแบบนี้ทำให้โมโหมากจริง ๆ
ผมพยายามแทบตายที่จะเป็นสมาชิกที่รับผิดชอบของเครือข่าย และขุดคุ้ยจนถึงมาตรฐานล่าสุดในปัจจุบันเพื่อปรับระบบของตัวเองให้ถูกต้อง
แต่คนพวกนั้นไม่เพียงมีอยู่จริง ยังแทบจะเปิดให้ทำงานแบบ โอเพนรีเลย์ อย่างเบามือ และเกือบครึ่งหนึ่งของอินเทอร์เน็ตต้องมาจ่ายราคานั้น ช่างเหลือเชื่อจริง ๆ
สรุปคือ เป็นเรื่องที่พบ โอเพนรีเลย์ ที่รวมอยู่ในระเบียน SPF จำนวนมาก
การนำเสนอที่ DEFCON ไม่ได้พิสูจน์ว่ามีช่องโหว่ขนาดมหึมา แต่แสดงให้เห็นข้อเท็จจริงที่มีมาตั้งแต่ยุคแรก ๆ ของอีเมลอินเทอร์เน็ต
ถ้าไม่ใช้ลายเซ็นข้อความอย่าง S/MIME หรือ DKIM ก็ไม่สามารถรับรองโดเมนผู้ส่งได้อย่างเพียงพอ
ต่อให้มี DKIM ก็ยังสามารถถูกนำไปใช้ในทางที่ผิดได้อย่างกว้างขวางผ่าน การโจมตีแบบส่งต่อ DKIM
ผลกระทบของเฮดเดอร์ ARC ต่อคะแนนสแปมน่าสนใจ ในฐานะคนที่ดูแลเมลเซิร์ฟเวอร์ส่วนตัว แค่เพิ่มชุด เฮดเดอร์ ARC ที่ไม่มีความหมายเข้าไปในอีเมลของผม ก็จะช่วยเพิ่มอัตราการส่งถึงผู้รับได้หรือเปล่า?
สแปมเมอร์ที่เป็นระบบและมีความรู้คงกำลังขุดคุ้ยเรื่องพวกนี้ทั้งหมดอยู่ และแน่นอนว่าคงเอาไปใช้เจาะผ่านอยู่แล้ว
เรื่องนี้ดูเหมือนจะถูกยืนยันแล้วตั้งแต่เดือนพฤษภาคม 2022: https://news.ycombinator.com/item?id=30533032
“เรามีขีดความสามารถในการตรวจจับสแปมและฟิชชิงอย่างกว้างขวาง และสามารถจัดการการใช้งานในทางที่ผิดได้”
อ้อ อย่างนั้นเองสินะ :D