จดหมายโคบอลด์: ความเสี่ยงของอีเมล HTML

 (lutrasecurity.com)
2 คะแนน โดย GN⁺ 2024-04-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

จดหมายโคบอลด์

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

Thunderbird

  • ปัญหานี้ถูกรายงานต่อ Mozilla เมื่อวันที่ 5 มีนาคม 2024 และได้ส่งกำหนดวันเผยแพร่ตามแผนพร้อมร่างของส่วนถัดไปให้ Mozilla เมื่อวันที่ 20 มีนาคม 2024
  • มีการพูดคุยถึงแนวทางบรรเทาผลกระทบที่เป็นไปได้ แต่จะถูกนำไปใช้งานในภายหลัง
  • การใช้ประโยชน์จากสิ่งนี้ใน Thunderbird ทำได้ง่าย Thunderbird จะห่ออีเมลด้วย `

` และนอกเหนือจากนั้นจะไม่แก้ไขอะไร

  • เมื่อมีการส่งต่ออีเมล เนื้อหาที่ถูกอ้างอิงจะถูกห่อด้วย `

` อีกชั้นหนึ่ง ทำให้เลื่อนลงไปหนึ่งระดับใน DOM

  • เมื่อคำนึงถึงสิ่งนี้แล้ว จะได้ตัวอย่าง proof of concept ดังนี้:

      .kobold-letter {
        display: none;
      }
      .moz-text-html>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • ในอีเมลจะมีทั้งข้อความที่มองเห็นได้เสมอ และข้อความที่ถูกซ่อนไว้ด้วย display: none;
  • เมื่อส่งต่ออีเมล ข้อความที่ซ่อนอยู่จะปรากฏขึ้นมาอย่างกะทันหันและมองเห็นได้เฉพาะผู้รับใหม่เท่านั้น

Outlook Web

  • ปัญหานี้ถูกรายงานต่อ Microsoft เมื่อวันที่ 5 มีนาคม 2024 และได้ส่งกำหนดวันเผยแพร่ตามแผนพร้อมร่างของส่วนถัดไปให้ Microsoft เมื่อวันที่ 20 มีนาคม 2024
  • Microsoft ตัดสินใจเมื่อวันที่ 26 มีนาคม 2024 ว่าจะไม่ดำเนินการในทันที และปิดรายงานนี้
  • ใน Outlook Web (OWA) สถานการณ์ซับซ้อนขึ้นเล็กน้อย อีเมลจะถูกห่อด้วย `

` แต่ชื่อคลาสที่แน่นอนอาจเปลี่ยนแปลงได้

  • เพื่อไม่ให้ CSS ของอีเมลไปมีผลกับสไตล์ของเว็บเมล Outlook จะเติม x_ ไว้หน้าทุก id และ class ของอีเมล แล้วปรับ CSS ให้สอดคล้องกัน
  • เมื่อคำนึงถึงสิ่งนี้แล้ว จะได้ตัวอย่าง proof of concept ดังนี้:

      .kobold-letter {
        display: none;
      }
      body>div>.kobold-letter {
        display: block !important;
      }

    This text is always visible.

    This text will only appear after forwarding.
  • เมื่ออีเมลถูกแสดงใน OWA, CSS จะมีลักษณะดังนี้:
  • หลังจากส่งต่ออีเมลแล้ว จดหมายโคบอลด์จะถูกห่อด้วย `` เพิ่มอีกชั้น และ CSS ก็จะถูกอัปเดตอีกครั้ง

Gmail

  • ปัญหานี้ถูกรายงานต่อ Google เมื่อวันที่ 5 มีนาคม 2024 และได้ส่งกำหนดวันเผยแพร่ตามแผนพร้อมร่างของส่วนถัดไปให้ Google เมื่อวันที่ 20 มีนาคม 2024
  • ในทางเทคนิคแล้ว Gmail ไม่ได้มีช่องโหว่ต่อจดหมายโคบอลด์ เพราะมันจะลบสไตล์ทั้งหมดออกเมื่อมีการส่งต่ออีเมล
  • ระหว่างการส่งต่ออีเมล ก่อนที่ CSS จะถูกลบ จดหมายโคบอลด์ที่ถูกซ่อนไว้ด้วย CSS จะปรากฏขึ้นมาโดยอัตโนมัติ

งานวิจัยก่อนหน้า

  • ความเป็นไปได้เช่นนี้ไม่ใช่เรื่องน่าประหลาดใจหรือเรื่องใหม่
  • เคยมีการรายงานปัญหาที่คล้ายกันในอดีตมาแล้ว

แนวโน้ม

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

ความเห็นของ GN⁺

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

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

1 ความคิดเห็น

 
GN⁺ 2024-04-05
ความเห็นบน Hacker News

  • “However, you are still not convinced, so you call your manager to ensure that the email is legit. He confirms, so you transfer the money.”

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

  • The other day I was discussing the design for an "update" email that our designer was putting together...

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

  • I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...

    • ความเห็นนี้โต้แย้งมาโดยตลอดว่า ในอีเมลควรใช้ Markdown (โดยไม่มี inline HTML) หรือมาร์กอัปข้อความแบบง่ายที่คล้ายกันแทน HTML เพราะจะช่วยให้ไคลเอนต์อีเมลตัดสินใจได้ง่ายว่าจะเรนเดอร์เป็น rich text หรือ plain text และยังรองรับการจัดรูปแบบส่วนใหญ่ที่ผู้ใช้ต้องการได้ด้วย ทั้งยังมองว่า HTML ขั้นสูงที่ใช้ในอีเมลการตลาดนั้นไม่สำคัญนัก

  • The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...

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

  • Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?

    • ความเห็นนี้เสนอว่า ปัญหานี้อาจแก้ได้ด้วยการไม่อนุญาตให้ใช้ Stylesheets ในอีเมล และอนุญาตเฉพาะ inline style attributes บนแท็กเท่านั้น โดยให้ไคลเอนต์อีเมลมีขั้นตอนแปลงสไตล์ชีตให้เป็น inline style โดยอัตโนมัติ ซึ่งอาจช่วยให้ใช้งานได้ดีขึ้น

  • HTML in email shouldn't be as big of a nightmare as it is.

    • ความเห็นนี้ระบุว่า HTML ในอีเมลไม่ควรเป็นฝันร้ายขนาดนี้ โดยมองว่าหากไคลเอนต์อีเมลทั้งหมดตรวจสอบว่าข้อความเป็น text หรือ HTML แล้วสลับไปใช้เอนจินเรนเดอร์แบบ WebKit ในกรณีที่เป็น HTML ปัญหาก็น่าจะแก้ได้ง่าย และยังสงสัยด้วยว่าเคยมีการเสนอมาตรฐานสำหรับเรื่องนี้หรือไม่

  • Some possible mitigations from the top of my head (maybe ineffective):

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

  • When efail came out, I wrote a blogpost about the security risks of HTML mail.

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

  • This is really clever!

    • ความเห็นนี้ชื่นชมว่า การใช้ CSS ในอีเมล HTML เพื่อทำให้ข้อความบางส่วนมองเห็นได้เฉพาะหลังจากอีเมลถูกส่งต่อแล้วนั้นชาญฉลาดมาก และมองว่านี่อาจเป็นภัยคุกคามอย่างมากต่อความน่าเชื่อถือของอีเมลที่ผ่านการตรวจสอบแล้ว นอกจากนี้ยังตั้งข้อสงสัยว่าไคลเอนต์อีเมลเพิ่มแท็ก HTML ครอบเนื้อหาอีเมล พร้อมทั้งแก้ไข CSS และชื่อคลาสไปทำไม และสงสัยด้วยว่าเหตุใดไคลเอนต์อีเมลจึงไม่ใช้ sandboxed iframe ในการเรนเดอร์อีเมล HTML