- กรณีที่ผู้โจมตีใช้ การโจมตีแบบ DKIM Replay เพื่อส่งอีเมลฟิชชิงที่สวมรอยเป็น Google ได้สำเร็จ
- ที่อยู่ผู้ส่งและผลการยืนยันตัวตน ของอีเมลดูเหมือนอีเมลทางการของ Google จริง ทำให้ผู้ใช้หลงเชื่อได้ง่าย
- ผู้โจมตีใช้ Google Sites สร้างเว็บไซต์ให้ดูเหมือนหน้าสนับสนุนอย่างเป็นทางการเพื่อเพิ่มความน่าเชื่อถือ
- แม้ SPF, DMARC และ DKIM จะผ่านการยืนยันทั้งหมด แต่หัวใจสำคัญคือ การส่งต่ออีเมลซ้ำ โดยไม่แก้ไขเนื้อหาหรือส่วนหัวที่ลงลายเซ็นไว้
- มาตรการรับมือที่แนะนำในทางปฏิบัติคือ การหมุนเวียนคีย์ DKIM เป็นประจำ และการเพิ่มการรับรู้ของผู้ใช้
จุดเริ่มต้น: อีเมลฟิชชิงที่ดูเหมือนปกติ
- ช่วงเช้ามีคนรู้จักคนหนึ่งได้รับอีเมลว่า มีคำขอเอกสารทางกฎหมายเกี่ยวกับบัญชี Google
- ผู้ส่งแสดงเป็น ที่อยู่ no-reply อย่างเป็นทางการของ Google ไม่มีคำสะกดผิด ลิงก์น่าสงสัย หรือโดเมนผิดปกติ จัดทำมาอย่างแนบเนียน
- ผู้รับจึงตัดสินความจริงแท้ได้ยากและส่งให้ผู้เชี่ยวชาญตรวจสอบ
การวิเคราะห์รายละเอียดของอีเมล
- ตรวจสอบส่วนหัวอีเมลและพรีวิวลิงก์ใน สภาพแวดล้อมแซนด์บ็อกซ์
- ทั้ง ที่อยู่ผู้ส่ง การสร้างแบรนด์ คุณภาพภาษา และการมีหรือไม่มีไฟล์แนบ ล้วนดูปกติ
- แต่เมื่อเช็กผลการยืนยัน SPF, DKIM และ DMARC กลับพบ สัญญาณผิดปกติ
ข้อควรระวังเกี่ยวกับอีเมลฟิชชิง
- เน้นย้ำว่า ห้ามคลิกลิงก์หรือทำตามคำสั่งในอีเมลที่น่าสงสัย
- หากตอบกลับอีเมลนั้นหรือเปิดไฟล์แนบในสภาพแวดล้อมที่ไม่ใช่แซนด์บ็อกซ์ อาจเสี่ยงต่อ ข้อมูลรั่วไหล การถูกยึดอีเมลองค์กร การถูกขโมยบัญชี และการบุกรุกเครือข่าย
- หากมีข้อสงสัย ควรรายงานให้ทีมวิเคราะห์เฉพาะทางและทีมความปลอดภัยทันที
ลำดับการโจมตี: การใช้ Google Sites
- ลิงก์ในอีเมลโจมตีจะพาไปยัง Google Sites ทันทีหากผู้ใช้ล็อกอินอยู่แล้ว
- แม้ Google Sites จะเป็น ซับโดเมนอย่างเป็นทางการของ google.com ที่ใครก็สร้างได้ฟรี แต่เนื้อหาภายในไม่ใช่หน้าสนับสนุนทางการ
- บริการนี้ถูกใช้ได้หลากหลาย เช่น วิกิภายใน แดชบอร์ดโครงการ เอกสารประกอบ และเว็บไซต์งานอีเวนต์ ซึ่งก็อาจถูกนำไปใช้ในทางที่ผิดแบบกรณีนี้ได้
เมื่อความน่าเชื่อถือของโครงสร้างพื้นฐานกลายเป็นภัยคุกคาม
- Google Sites (เปิดตัวในปี 2008) ทำงานร่วมกับ Google Workspace ช่วยให้สร้างและเผยแพร่ได้ง่าย พร้อม SSL และความน่าเชื่อถือของแบรนด์
- ผู้โจมตีจึงสามารถสร้างเว็บฟิชชิงที่ดูเป็นทางการได้ง่ายและต้นทุนต่ำ โดยไม่ต้องมีโดเมนหรือโฮสติงแยกต่างหาก
รายละเอียดกระบวนการโจมตีแบบ DKIM Replay
ขั้นที่ 1: ได้มาซึ่งอีเมลจริงของ Google
- ผู้โจมตีรับอีเมลปกติจากบัญชี no-reply@accounts.google.com แล้วเก็บเนื้อหาต้นฉบับและส่วนหัวไว้
ขั้นที่ 2: เตรียมส่งต่อข้อความที่มีลายเซ็น
- DKIM จะใส่ลายเซ็นดิจิทัลให้กับบางส่วนของเนื้อหาอีเมลและส่วนหัวบางรายการ
- หากยังคงข้อความต้นฉบับและส่วนหัวลายเซ็นไว้ การส่งต่อซ้ำก็ยังคงผ่านการยืนยันได้
ขั้นที่ 3: ส่งต่อผ่าน Outlook
- ผู้โจมตีส่งอีเมลโจมตีจาก บัญชี Outlook
- แม้ต้นทางและข้อมูลเส้นทางบางส่วนจะเปลี่ยนไป แต่ลายเซ็น DKIM ยังคงใช้ได้
ขั้นที่ 4: ใช้เซิร์ฟเวอร์รีเลย์ SMTP ของ Jellyfish
- มีการเราต์อีเมลผ่าน ระบบ Jellyfish ของ Microsoft (ช่วยเพิ่มระยะห่างจากเซิร์ฟเวอร์ต้นทาง)
ขั้นที่ 5: ส่งผ่าน Namecheap PrivateEmail
- บริการ PrivateEmail ของ Namecheap รับอีเมลและทำหน้าที่เป็นรีเลย์เพิ่มเติม
- ในขั้นตอนนี้จะมีการเพิ่มลายเซ็น DKIM ใหม่ แต่ไม่สอดคล้องตามเกณฑ์ของ DMARC
- อย่างไรก็ตาม ลายเซ็น DKIM ดั้งเดิมของ Google ยังคงตรงกันและใช้ได้ จึงผ่านการตรวจสอบ DMARC
ขั้นที่ 6: ส่งถึง Gmail ปลายทาง
- ท้ายที่สุด ผู้รับจะได้รับอีเมลที่ดูเหมือนเป็น อีเมลทางการของ Google
- ผลลัพธ์คือ SPF, DKIM และ DMARC ผ่านการยืนยันทั้งหมด
เหตุใดอีเมลหมายเรียกปลอมจึงอันตราย
- อีเมลประเภท ‘หมายเรียก’ ทำให้ผู้รับเกิด ความกลัว ความเร่งด่วน และความสับสน
- รูปแบบการออกหรือการส่งหมายเรียกจริงแตกต่างออกไป และหากเป็นของจริงก็มักดำเนินการผ่านการส่งทางกายภาพหรือช่องทางทางการ
- ฟิชชิงลักษณะนี้มีความน่าเชื่อสูงมาก จนแม้แต่ผู้ใช้ที่มีทักษะทางเทคนิคก็อาจถูกหลอกได้ง่าย
บทสรุปและการรับมือ
- ยิ่งเป็น อีเมลด่วนที่มาโดยไม่คาดคิด ยิ่งต้องตรวจสอบความจริงแท้และขอให้ผู้เชี่ยวชาญช่วยดำเนินการ
- ห้ามคลิกลิงก์ ตอบกลับ หรือรันสิ่งใดจากอีเมลนั้นโดยเด็ดขาด
- แนะนำให้ส่งให้ทีมความปลอดภัยหรือผู้เชี่ยวชาญด้านการสืบสวนวิเคราะห์ ตรวจสอบ
เพิ่มเติม: ขั้นตอนการจำลองการโจมตี
- ผู้โจมตีจดทะเบียนโดเมนกับ Namecheap และรับบริการ PrivateEmail ฟรี
- สมัคร Google Workspace (รุ่นทดลองใช้ฟรี) และยืนยันโดเมน จากนั้นสร้าง Google OAuth App ที่เป็นอันตราย
- ในฟิลด์ App Name สามารถตั้งชื่อที่ต้องการได้ (เช่น Google Support)
- การแจ้งเตือนบัญชีที่ Google ส่งจะถูกส่งไปยัง PrivateEmail และสามารถบิดเบือนที่อยู่ผู้ส่งและที่อยู่ตอบกลับได้
- สุดท้ายอีเมลโจมตีก็จะถูกส่งถึงเป้าหมายที่ต้องการ
คำถามที่พบบ่อย
- การโจมตีแบบ DKIM Replay: ผู้โจมตีดักจับอีเมลปกติที่มีลายเซ็น DKIM ถูกต้อง แล้วส่งซ้ำด้วยเนื้อหาและส่วนหัวเดิม
- ข้อจำกัดของการบล็อกด้วย SPF และ DMARC: SPF ตรวจสอบเพียงเซิร์ฟเวอร์/IP ผู้ส่ง และในกรณี Replay หาก DKIM ยังสอดคล้อง DMARC ก็อาจผ่านได้
- เหตุผลที่ตรวจจับได้ยาก: เมื่อไม่มีการแก้ไขเนื้อหาหรือส่วนหัว การตรวจสอบลายเซ็นเพียงอย่างเดียวทำให้แยกแยะได้ยาก
- การอ้อมข้อจำกัดของ Google OAuth ในการโจมตีนี้: ผู้โจมตีสร้าง OAuth App ที่เป็นอันตราย แล้วส่งต่อการแจ้งเตือนทางการจาก Google เพื่อเพิ่มความน่าเชื่อถือ
- มาตรการรับมือ: หมุนเวียนคีย์ DKIM เป็นประจำ (รอบไม่เกิน 30 วัน) และฝึกอบรมผู้ใช้ (ระวังลิงก์น่าสงสัย ตรวจสอบ URL และส่งเสริมวัฒนธรรมการรายงาน) เป็นสิ่งสำคัญ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมกำลังทำวิธีแก้ปัญหานี้อยู่ (ทำร่วมกับผู้ร่วมเขียนที่เคยอยู่ Google และ Yahoo จึงเป็นโปรเจ็กต์ที่น่าเชื่อถือ)
โปรดดูเอกสาร Draft: DKIM2 Motivation
แนวทางนี้ไม่ได้ป้องกันไม่ให้ข้อความที่ผู้ใช้ป้อนถูกส่งออกจาก Google จริง ๆ แต่จะป้องกันไม่ให้ข้อความนั้นถูกส่งต่อซ้ำโดยที่ไม่ใช่เจตนาที่แท้จริงของ Google
เพราะฟิลด์ SMTP FROM/TO จะได้รับการปกป้อง
ร่างเอกสาร motivation ไม่มีรายละเอียดเชิงเทคนิค แต่สามารถดูร่างได้จากเอกสารที่เกี่ยวข้อง
โปรดดูที่ DKIM Working Group Documents
เว็บ Datatracker แสดงเอกสารที่อยู่ในช่วงเสนอไม่ค่อยดี เลยแนบลิงก์ตรงไว้
Draft: dkim2-dns
Draft: dkim2-header
Draft: dkim2-modification-algebra
Draft: dkim2-bounce-processing
Draft: dkim2-message-examples
สงสัยว่าแนวทางนี้จะทำงานกับ mailing list หรือกลุ่มอย่างไร
ตัวอย่างเช่น มักมีการ forward อัตโนมัติอีเมลที่มาจากภายนอกไปยัง accounts-payable@example.com ให้สมาชิกในทีม
ในระบบของผู้รับปลายทาง ต้องตั้งค่าให้เชื่อถือ mailing list forwarder หรือไม่ หรือจำเป็นต้องมีตรรกะภายในที่ติดตามว่าถูกรวมอยู่ในลิสต์ใดบ้าง
ควรต้องสามารถยืนยันได้ว่าผู้รับเดิมคือ accounts-payable เป็นผู้รับที่ถูกต้อง
ผมเคยถูก FBI ยึดข้อมูลทั้งหมดจากบัญชี Google หลังจากถูกตัดสินว่ามีความผิดฐานแฮ็กคอมพิวเตอร์จริง ๆ
ครั้งหนึ่งในปี 2016 และอีกครั้งในปี 2018
ในความเป็นจริงพวกเขาไม่ได้ทำแบบในบทความนี้
จากประสบการณ์ของผม จะมีการส่งอีเมลไปยังแผนกเฉพาะของ Google เพื่อดำเนินการสื่อสารอย่างเป็นทางการ
หน่วยงานสืบสวนจะเคลื่อนไหวอย่างระมัดระวังมากที่สุดเพื่อไม่ให้ผู้ถูกสอบสวนรู้ตัว
คุณจะได้รับอีเมลจาก usernotice@google.com ที่มีเนื้อหาแบบนี้:
ในหมายเรียกของคณะลูกขุนใหญ่ของรัฐบาลกลาง (Federal Grand Jury subpoena) โดยทั่วไปจะมีการขอให้ชะลอการแจ้งเตือน 1-2 ปีเพื่อไม่ให้ผู้ให้บริการ (เช่น Google) แจ้งคุณ
หมายเรียกจะให้เพียงบันทึกทั่วไปเท่านั้น (ข้อมูลการเรียกเก็บเงิน, ประวัติการล็อกอิน ฯลฯ) และไม่รวมเนื้อหา (เช่น อีเมล)
หากเป็นข้อมูลจริงอย่างอีเมล จะต้องมีหมายค้นแยกต่างหาก และโดยปกติ Google จะไม่แจ้งแยกว่ามีการบังคับใช้หมายค้นดังกล่าว
วันนี้วันศุกร์ แต่คอมเมนต์นี้ทำให้ผมตื่นขึ้นมา 10%
อยากรู้เรื่องราวเบื้องหลังแบบละเอียด
น่าสนใจ
สงสัยว่าคำขอแบบนี้จะถูกรวมอยู่ในคำขอแนว GDPR ที่ว่า "ขอข้อมูลทั้งหมดที่เกี่ยวกับบัญชีของฉัน" หรือไม่ และจะมีการบันทึกหรือแปะแท็กไว้ในไฟล์ข้อมูลบัญชีทั้งหมดของผมหรือเปล่า
เดานะ แต่หมายค้นน่าจะออกมาจากข้อหาอย่าง CFAA violation, wire fraud หรือ conspiracy
หวังว่าคุณจะได้ทนายดี ๆ และจัดการเรื่องนี้ได้เรียบร้อย
ช่วงหลังผมก็โดนการโจมตีคล้ายกัน
ผู้โจมตีส่งอีเมลจาก yourgoogleaccount@google.com (ไม่ใช่ gmail.com แบบตรงตัว) จากนั้นก็ forward ข้อความตีกลับ (bounce) ที่ได้รับจากเมลเซิร์ฟเวอร์ของ Google ไปยัง yourgoogleaccount@gmail.com แล้วแทรกข้อความสแปมไว้ท้ายสุด
มันผ่านการตรวจความปลอดภัยทั้งหมด
แปลกมากที่เป็นการผสมกันระหว่าง error ของ postmaster กับแคมเปญฟิชชิง
ถ้าเป็นคนที่ไม่ใช่สายเทคนิคก็น่าจะหลงเชื่อได้ง่าย
ในกรณีของผม เนื้อหาอีเมลฟิชชิงเป็นประมาณว่าผมถูกรางวัลเป็นเครื่องมือช่างก่อสร้าง
ตอนนี้เริ่มรู้สึกว่า Google ยอมแพ้เรื่องเมลไปแล้ว
ตอนอ่านบทความผมสับสนมาก
มันอธิบายละเอียดเหมือนกับว่าผู้โจมตีแก้ไขเนื้อหาอีเมลแล้วแทรกลิงก์ฟิชชิงเข้าไป แต่จริง ๆ ไม่มีหลักฐานหรือการแก้ไขแบบนั้นเลย
ลายเซ็น DKIM มีแฮชของเนื้อหาอยู่ด้วย
ในทางเทคนิคสามารถใช้ฟิลด์ I= เพื่อจำกัดขอบเขตของแฮชได้ แต่ผมยืนยันแล้วว่า Google ไม่ได้ใช้ตัวเลือกนั้นกับอีเมลสั้น ๆ (ตรวจจากอีเมล no-reply@accounts.google.com โดยตรง)
ดังนั้นหากจะให้ผ่านทั้ง DKIM และ DMARC เนื้อหาจะต้องไม่ถูกเปลี่ยน และลิงก์ฟิชชิงก็คงเป็นสิ่งที่ Google ส่งมาแต่เดิมอยู่แล้ว (เพียงแต่ตั้งใจส่งให้ผู้รับอีกคน)
เพราะฉะนั้นประเด็นจริงคือ "กรณีอีเมลน่ากลัวถูก forward ผิดคน" มากกว่า และชื่อเรื่องว่า 'DKIM replay attack' อาจฟังดูร้ายแรงกว่าความเป็นจริงมากสำหรับคนที่ไม่คุ้นกับเรื่องนี้
แก้ไข: ตอนแรกผมเห็น "The Takeaway?" ของบทความแล้วคิดว่าจบแล้ว แต่มีอัปเดตด้านล่างอธิบายว่าลิงก์นั้นจริง ๆ ถูกแทรกในชื่อแอป Google OAuth แล้วถูกรวมอยู่ในเทมเพลตอีเมลของ Google
ตรงนี้ต่างหากคือจุดสำคัญที่สุดของการโจมตีนี้ แต่โครงสร้างบทความแย่มากจนประเด็นนี้ถูก bury ไว้ และทำให้คนเข้าใจผิดเหมือนว่าสามารถส่งเนื้อหาอะไรก็ได้
เพิ่มเติม: อีกคอมเมนต์หนึ่งยังชี้ด้วยว่าสกรีนช็อตอีเมลถูกตัดกลาง ทำให้ไม่เห็นส่วนคงที่ของเทมเพลตอีเมล Google
ตัวการโจมตีเองหละหลวมกว่าที่คิดมาก
บทความนี้ดูเหมือนตั้งใจเขียนให้ชวนเข้าใจผิด
มันทำให้ดูเหมือนว่าส่วนที่จับภาพมาคืออีเมลทั้งหมด ทั้งที่จริงน่าจะมีข้อความต่อจากนั้นซึ่งควรทำให้รู้สึกผิดสังเกต
เท่าที่ผมเข้าใจ DKIM จึงตรวจผ่านเพราะผู้โจมตีกำลัง forward อีเมลที่ได้รับจาก Google จริง ๆ แบบไม่แก้ไข
เวกเตอร์การโจมตีจริงคือ Google ถูกทำให้ส่งอีเมลที่มีข้อความบางส่วนซึ่งผู้โจมตีควบคุมได้
สำหรับผม ช่องโหว่จริงที่นี่คือสามารถใส่ URL ลงในชื่อแอป Google OAuth ได้ และมันถูกเรนเดอร์ลงในอีเมล no-reply จากโดเมนรากของ Google ไปยังที่อยู่ใดก็ได้อย่างไม่เลือกหน้า
แม้ลิงก์จะคลิกไม่ได้ แต่ถ้าข้อความแวดล้อมดูคุกคามพอ เหยื่อก็น่าจะพิมพ์เข้าไปเอง
การที่มีบริการ forward หลายชั้นซ้อนกันได้โดยยังคงความสมบูรณ์ของ DKIM ไว้ได้ เป็นเพียงด้านที่ให้ความรู้เพิ่มเติม
ควรห้ามไม่ให้ใส่ URL ในชื่อแอป OAuth ไปเลย โดยเฉพาะ URL ที่มี google.com
ในที่สุด!
เมื่อหลายเดือนก่อนผมเคยได้รับอีเมลที่แทบจะเหมือนกันเป๊ะ (สำหรับผู้ดูแลระบบ google domains)
ยอมรับว่าผมขนลุกกับอีเมลฉบับนั้นเหมือนกัน
ผมก็ไม่ได้รีบกดลิงก์ และพยายามหาแหล่งอ้างอิงอื่นเกี่ยวกับการหลอกลวงนี้
จุดที่แปลกคืออีเมลทั้งหมดถูกปิดบังไว้ และรูปแบบการมาสก์นั้นไม่ตรงกับอีเมลที่ผมดูแล
ตัวอีเมลเองดู legit และพอลองค้นดูก็พบว่าข้อความในเนื้อหาตรงกัน
ในกรณีของผม มันเป็นอีเมลเกี่ยวกับบัญชีของผู้เสียชีวิต ซึ่งไม่ตรงกับความจริง
แต่ผมเกือบจะเชื่อ 100% ว่ามีใครบางคนพยายามโน้มน้าว Google ว่าผมตายแล้วเพื่อยึดบัญชี Google ทั้งหมดของผม
เป็นประสบการณ์ที่น่ากลัวมาก
Step 3: ผู้โจมตีส่งอีเมลจาก Outlook
เท่าที่ผมรู้ การปลอมเส้นทางใน Received: header เป็นไปไม่ได้
ทุกเซิร์ฟเวอร์จะเพิ่มข้อมูลเส้นทางของตัวเองเข้าไปเรื่อย ๆ
เพราะอย่างนั้นผมจึงตรวจข้อมูลนั้นเสมอเวลาเช็กที่มาของอีเมล
อีเมลจาก Google ไม่น่าจะวิ่งผ่านเซิร์ฟเวอร์ของ Microsoft
header ของเซิร์ฟเวอร์ตัวสุดท้ายที่ 'เชื่อถือได้' ปลอมไม่ได้ แต่เส้นทางส่วนอื่นปลอมได้
สงสัยว่าคุณเปิดดู header ของอีเมลทุกฉบับด้วยมือหรือเปล่า
หรือใช้เครื่องมือที่ช่วยแสดงผลหรือทำภาพให้ดูง่ายขึ้น
เป็นสถานการณ์ที่น่ากลัวจริง ๆ
ลองนึกภาพว่าต้องอธิบายบทเรียนจากบทความนี้ให้ญาติฟัง
แค่ต้องบอกว่าต่อให้อีเมลมาจากโดเมนที่เชื่อถือได้ และผ่าน dkim/dmarc/spf ครบหมด ก็ยังต้องสงสัยไว้ก่อน ก็ทำให้รู้สึกหนักใจแล้ว
แต่อันที่จริงการโจมตีนี้มีข้อจำกัดค่อนข้างมาก
ตัวอย่างเช่น มันไม่สามารถปลอมส่งข้อความจากบัญชี Gmail ของคนอื่นได้
"เมื่อข้อความถูก forward ลายเซ็น DKIM จะยังคงอยู่ตราบใดที่เนื้อหาและ header ที่ถูกเซ็นไม่เปลี่ยน"
สิ่งที่น่าแปลกคือ To: header ไม่ได้ถูกรวมอยู่ในสิ่งที่ DKIM เซ็น
ผมคิดว่าควรเปลี่ยนวิธีตั้งค่าการเซ็น หรือไม่ก็เพิ่มฟีเจอร์ในอีเมลไคลเอนต์ให้เตือนเมื่ออีเมลดูปกติแต่ค่า To ถูกเปลี่ยน
ลองนึกภาพว่าต้องอธิบายบทเรียนของบทความนี้ให้ญาติฟัง — ให้สงสัยทุกอย่างไว้ก่อน
dkim/dmarc/spf นี่แค่จะอธิบายว่าคืออะไรก็ลำบากแล้ว
จริง ๆ เทคโนโลยีพวกนี้เป็นเรื่อง backend ที่ผู้ใช้ไม่จำเป็นต้องรู้ด้วยซ้ำ
การโจมตีนี้ไม่ได้ได้น่ากลัวอย่างที่คิด
บทความนี้มีส่วนเขียนเกินจริงเพื่อขายผลิตภัณฑ์
ประเด็นที่ว่า To: header ไม่ได้อยู่ในลายเซ็นนั้นจริง ๆ ไม่ได้สำคัญนัก
ในทางปฏิบัติ To ของอีเมลไม่ได้จำเป็นต้องเป็นผู้รับปลายทางเสมอไป
ท่าทีที่ว่าต้องสงสัยทุกอย่างในอีเมลนั้นเป็นค่าเริ่มต้นมานานแล้ว
ทางที่ดีที่สุดคืออย่าเชื่อ From field โดยเด็ดขาด
มีคนบอกว่าน่าแปลกที่ To: header ไม่ได้รวมอยู่ใน DKIM signature แต่จริง ๆ มันรวมอยู่
ดังนั้นจึงต้องคงค่า To: เดิมเอาไว้
สกรีนช็อตในส่วน reproduction แสดงค่า To: เดิมนั้นอยู่
ไม่ได้หมายความว่ามันถูกส่งมาที่อยู่นั้นจริง ๆ
โดยพื้นฐานแล้ว อีเมลสามารถถูกส่งไปยังที่อยู่ใดก็ได้ พร้อมค่า To: ใดก็ได้
คำแนะนำพื้นฐานของผมคือ ถ้าอีเมลใดกระตุ้นให้ต้องลงมือทำอะไร ให้เข้าเว็บไซต์นั้นโดยตรงเอง
อย่าคลิกลิงก์ใด ๆ
มันอาจไม่สะดวก แต่สุดท้ายก็ช่วยแก้ปัญหาได้
โดยเฉพาะกับธนาคารหรือระบบสำคัญ ความไม่สะดวกแบบนี้คุ้มค่ามาก
ที่ทำงานของผมรับมือภัยคุกคามแบบนี้ด้วยการทำเป็นนโยบายไปแล้ว
บนอินเทอร์เน็ต การสงสัยทุกอย่างถือเป็นแนวปฏิบัติที่ดี
ธุรกิจขนาดเล็กและฟรีแลนซ์จำนวนมากยังไม่ใช้สิ่งอย่าง MFA และถึงใช้ก็ยังถูกขโมยโทเค็นได้ง่าย
พอบัญชีเหล่านี้โดนเจาะ ก็จะมีอีเมลอันตรายที่ดูเหมือนมาจากผู้ใช้ภายในจริง ๆ ถูกส่งออกมา
จากมุมมองของผู้ใช้ มันดู legit มาก
เพราะฉะนั้นอีเมลต้องถูกปฏิบัติด้วยความระแวงเสมอ
ผู้เขียนบอกว่า
"Here is the URL from that email [...] https://sites.google.com[...]";
ลิงก์นี้แหละคือสัญญาณอันตรายแรก
ผมคิดว่าผู้เขียนควรชี้ประเด็นนี้ตั้งแต่ต้น ไม่ใช่ปล่อยไปอีกสามย่อหน้าค่อยพูด
ไม่ใช่ทุกคนที่จะรู้จักทุกซับโดเมนของ google.com
ปัญหาจริงคือ (นอกเหนือจากปัญหา valid field ของ SSO) Google ให้บริการคอนเทนต์ของผู้ใช้บนซับโดเมนของเมนโดเมนหลัก
บริการอื่นอย่าง Drive ก็อาจเป็นแบบนั้นเช่นกัน
สำหรับคุณมันอาจเป็นสัญญาณอันตราย แต่กับพ่อแม่ของเราอาจไม่ใช่
โดยรวมแล้ว ผมคิดว่านี่เป็นตัวอย่างที่แสดงให้เห็นว่าระบบความปลอดภัยของอีเมลเปราะบางแค่ไหน
ในฟอรัมนี้มีคนฉลาดมากมาย น่าจะช่วยกันคิดทางเลือกที่แก้ปัญหานี้ได้ในคราวเดียว
ผมก็คิดว่า Google ควรให้บริการไซต์พวกนี้บนโดเมนแยก เช่น hostedbygoogle.com ไม่ใช่บนเมนโดเมนหลัก
สงสัยว่าทำไมถึงยังไม่แยกมาจนถึงตอนนี้
ทางเลือกทั้งหมดที่เป็นไปได้จริงในโลกความเป็นจริง สุดท้ายแล้วจะลงเอยเป็นระบบที่มอบอำนาจควบคุมทั้งหมดให้บริษัทเดียว
ซึ่งทำให้คุณค่าหลักที่ยังเหลืออยู่ของอีเมล — การเป็นระบบที่ไม่มีใครควบคุมได้ทั้งหมด — หายไป
ปัญหาทางเทคนิคนั้นแก้ได้ไม่ยากเท่าปัญหาของผู้คนและผลประโยชน์
ผู้ที่มีทรัพยากรมากพอจะแก้ปัญหานี้ ส่วนใหญ่ก็ไม่มีแรงจูงใจจะสร้างแพลตฟอร์มที่เปิดอย่างแท้จริง
ถ้าไม่ได้ทั้งเงินและอำนาจควบคุมทั้งหมด พวกเขาก็ไม่ค่อยมีเหตุผลจะลงทุนลงแรง
ในทางกลับกัน ก็ไม่ใช่ทุกคนที่อยากยกการควบคุมทั้งหมดให้บริษัทเดียว
นี่จึงไม่ใช่ปัญหาทางเทคนิค แต่เป็นปัญหาทางธุรกิจ
(เหตุผลเดียวกันนี้เองที่ทำให้การมี metaverse ที่ทุกบริการแชร์อวตารและไอเท็มร่วมกันแทบเป็นไปไม่ได้
ไม่ใช่เพราะเทคนิคทำไม่ได้ แต่เพราะผู้ถือสิทธิ์ไม่มีทางยอม)
เปิดตัวสตาร์ตอัปใหม่ Shadowfax ที่ Thiel ลงทุนแล้ว!
บริการผูกขาดแบบรวมศูนย์ที่ปลอดภัยของเรามาพร้อมชั้น AI และ blockchain เพื่อแทนที่ระบบอีเมลอันล้าสมัย
เราได้งานจากกระทรวงกลาโหมสหรัฐแล้ว และคาดว่าจะกลายเป็นมาตรฐานของการสื่อสารภาครัฐทั้งภายในและภายนอกทั้งหมดภายในปี 2027