Thư Kobold: Mối nguy của email HTML

 (lutrasecurity.com)
2 điểm bởi GN⁺ 2024-04-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kobold letters là một kỹ thuật tấn công khiến email HTML ban đầu trông vô hại nhưng sau khi được chuyển tiếp lại biến thành nội dung lừa đảo đối với người nhận khác
  • Cốt lõi của kỹ thuật này là tận dụng CSS mà ứng dụng email cho phép, cùng với vị trí DOM thay đổi trong quá trình chuyển tiếp để ẩn hoặc hiện lại những câu chữ nhất định
  • Thunderbird và Outlook on the web có thể làm lộ các câu chữ bị ẩn sau khi chuyển tiếp do cấu trúc DOM và cách viết lại CSS, còn Gmail có thể để lộ nội dung theo cách đơn giản hơn vì xóa style khi chuyển tiếp
  • Vấn đề đã được báo cho Mozilla, Microsoft và Google vào ngày 5/3/2024; Microsoft đóng báo cáo vào ngày 26/3 mà không có biện pháp ngay lập tức, còn Google xác nhận đang sửa lỗi vào ngày 9/4
  • Người dùng có thể tắt email HTML hoặc xem ở chế độ hạn chế, nhưng việc chặn `` có thể phá vỡ nhiều trường hợp sử dụng trong hệ sinh thái email hiện tại nên rất khó giảm thiểu triệt để ở cấp ứng dụng khách

Kịch bản tấn công và ý tưởng cốt lõi

  • Một email do quản trị viên chuyển tiếp lúc đầu có thể trông như thư hỏi đáp vô hại, nhưng sau khi được chuyển tiếp thì lại biến thành yêu cầu lừa đảo đối với người nhận mới
  • Người nhận thấy người gửi là người quen, trong một số trường hợp còn có cả chữ ký mật mã, và ngay cả khi xác nhận qua điện thoại việc chuyển tiếp, họ vẫn có thể bị lừa
  • Quản trị viên là người nhận ban đầu không nhìn thấy câu chữ lừa đảo trong email mà mình đã chuyển tiếp, nên ngay cả khi xác nhận việc chuyển tiếp cũng khó nhận ra đây là một cuộc tấn công

Cách Kobold letters hoạt động

  • Phần lớn ứng dụng email cho phép định kiểu CSS trong email HTML
  • Khi email được chuyển tiếp, vị trí DOM của email gốc thường thay đổi, và kẻ tấn công áp dụng bộ chọn CSS dựa trên sự thay đổi đó
  • Kẻ tấn công có thể chèn vào email các phần tử xuất hiện hoặc biến mất tùy theo ngữ cảnh
    • Bình thường thì ẩn bằng display: none;
    • Sau khi chuyển tiếp, khi cấu trúc DOM thay đổi thì hiển thị bằng các quy tắc như display: block !important;
  • Những phần tử này thường không nhìn thấy, chỉ xuất hiện trong những tình huống nhất định và có thể bị lạm dụng cho phishing, nên được gọi là kobold letters
  • Nhìn chung, các ứng dụng email và webmail hỗ trợ email HTML đều có thể bị ảnh hưởng

Cách hoạt động trên Thunderbird

  • Vấn đề liên quan đến Thunderbird đã được báo cho Mozilla vào ngày 5/3/2024, và bản nháp cùng ngày công bố dự kiến 20/3/2024 đã được gửi đi
  • Các biện pháp giảm thiểu khả dĩ đã được thảo luận, nhưng việc triển khai dự kiến sẽ được để lại sau
  • Thunderbird bọc email bằng `

` và ngoài ra gần như không thay đổi gì

  • Khi chuyển tiếp email, email gốc được trích dẫn lại sẽ tiếp tục nằm trong `

`, khiến nó di chuyển xuống một cấp trong DOM

  • CSS ví dụ sẽ ẩn .kobold-letter theo mặc định và chỉ hiển thị trong điều kiện .moz-text-html>div>.kobold-letter
  • Với người xem email gốc, chỉ đoạn văn luôn hiển thị mới xuất hiện, nhưng với người nhận email đã được chuyển tiếp thì đoạn văn từng bị ẩn lại đột ngột hiện ra
  • Kẻ tấn công biết vị trí tương đối trong DOM và có thể điều khiển CSS để ẩn hoặc hiện một phần email, từ đó thay đổi toàn bộ nội dung
  • Nếu định kiểu kobold letter như một lớp phủ, kẻ tấn công thậm chí có thể thay thế cả bình luận mà người chuyển tiếp thêm vào email gốc, tạo thêm cơ hội phishing

Cách hoạt động trên Outlook on the web

  • Vấn đề trên Outlook on the web đã được báo cho Microsoft vào ngày 5/3/2024, và bản nháp cùng ngày công bố dự kiến 20/3/2024 đã được gửi đi
  • Microsoft đã đóng báo cáo vào ngày 26/3/2024 và quyết định không có biện pháp xử lý ngay lập tức
  • Vì OWA là webmail nên tình huống phức tạp hơn; email được đặt trong các container như `

`, nhưng tên class chính xác sẽ thay đổi

  • Outlook thêm tiền tố x_ vào id và class, đồng thời điều chỉnh CSS tương ứng để CSS của email không ảnh hưởng đến style giao diện webmail
  • Trong ví dụ, CSS của email gốc khi hiển thị trên OWA được biến đổi như sau
    • .rps_78fa .x_kobold-letter {display:none}
    • .rps_78fa > div > div > .x_kobold-letter {display:block!important}
  • Sau khi chuyển tiếp, class lại đổi tiếp thành dạng như x_x_kobold-letter và CSS cũng lại được cập nhật
  • Ở quy tắc thứ hai, dấu > giữa .rps_78fa và div biến mất, nên khi tạo các selector phức tạp cần tính đến điều này
  • Các điều chỉnh của OWA không ngăn được bản thân cuộc tấn công, nhưng lại tạo ra những ràng buộc phiền toái khi muốn tạo kobold letter hoạt động đồng thời trên nhiều ứng dụng

Cách hoạt động trên Gmail

  • Vấn đề trên Gmail đã được báo cho Google vào ngày 5/3/2024, và bản nháp cùng ngày công bố dự kiến 20/3/2024 đã được gửi đi
  • Google xác nhận vào ngày 9/4/2024 rằng họ đang thực hiện sửa lỗi
  • Gmail xóa toàn bộ style khi chuyển tiếp email, nên về mặt kỹ thuật nó không dễ bị tổn thương trước định nghĩa hẹp của kobold letters, tức kiểu tấn công dùng selector CSS để thay đổi việc hiển thị theo ngữ cảnh
  • Tuy vậy, vẫn có thể thực hiện một cuộc tấn công đơn giản hơn
    • Ẩn kobold letter trong email gốc bằng CSS
    • Khi chuyển tiếp, style bị xóa nên phần tử bị ẩn sẽ tự động hiện ra
  • Cách này có giới hạn; không thể làm điều ngược lại là nội dung xuất hiện trong bản gốc nhưng biến mất sau khi chuyển tiếp
  • Do Gmail chưa xóa CSS ở bước trình soạn thảo trước khi gửi, nên trong lúc người chuyển tiếp đang viết bình luận, đoạn văn bị ẩn vẫn không xuất hiện
  • Trong email kết quả, style bị xóa nên đoạn văn thứ hai sẽ hiện ra
  • Nếu Gmail xóa CSS ngay ở giai đoạn trình soạn thảo, người chuyển tiếp có thể phát hiện cuộc tấn công trước khi gửi và vấn đề có thể được giảm nhẹ

Các trường hợp tương tự trước đây và điểm khác biệt

Biện pháp giảm thiểu và giới hạn

  • Người dùng có thể tắt hoàn toàn email HTML hoặc xem ở chế độ hạn chế như “plain HTML” của Thunderbird
  • Ứng dụng email có thể giải quyết vấn đề nếu ngăn việc sử dụng ``, nhưng điều đó có thể phá vỡ nhiều trường hợp sử dụng hiện có trong hệ sinh thái email
  • Cách triển khai như Gmail, tức xóa style khi chuyển tiếp, có thể là một giải pháp thỏa hiệp giúp vẫn cho phép bản tin doanh nghiệp có style mà vẫn hạn chế rủi ro của email HTML
  • Trong tương lai gần, khó có thể kỳ vọng các ứng dụng email sẽ triển khai những biện pháp giảm thiểu mạnh mẽ
  • Người dùng cần nhận thức được rủi ro của email HTML và tự áp dụng các biện pháp phòng ngừa cần thiết

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-05
Ý kiến trên Hacker News

  • Đoạn “Tuy vậy vẫn không chắc nên gọi cho quản lý để xác nhận email có thật không. Quản lý nói là đúng, thế là chuyển tiền” có cảm giác như một giả định quá lớn
    Bình thường người ta sẽ không hỏi mơ hồ kiểu “Anh/chị có gửi email này không?” mà sẽ hỏi cụ thể hơn như “Có thật là anh/chị muốn tôi chuyển tiền theo đúng kiểu này không?”, mà nếu vậy thì quản lý đương nhiên sẽ bối rối và khả năng cao cuộc tấn công sẽ bị chặn ngay trong cuộc trao đổi đó
    Đây đúng là một hướng tấn công thú vị, nhưng khả năng thành công ngoài đời thực thì đáng nghi. Bài viết mô tả rằng để cuộc tấn công này xảy ra được thì cần một chuỗi sự kiện khá cụ thể và hẹp, và cá nhân tôi thấy không mấy thuyết phục
    Tôi biết phishing thực sự có hiệu quả. Nhưng những người mắc bẫy phishing thường còn chẳng cần đến mức tấn công tinh vi như thế này, mà ngược lại nếu kẻ tấn công đổ quá nhiều công sức cho một kịch bản cụ thể như vậy thì còn có thể làm thu hẹp xác suất thành công. Chỉ với email phishing thông thường thôi cũng đã có khả năng thành công cao

    • Tôi từng làm ở một công ty có 10.000 nhân viên, một nửa là kỹ sư, và năm nào cũng có vài vụ ai đó mua thẻ quà tặng bằng thẻ công ty cho “CEO” hoặc một lãnh đạo cấp cao khác
      Thông tin về các lãnh đạo đó có thể dễ dàng tìm thấy trên LinkedIn hoặc website công ty, và thậm chí đây còn là đúng ví dụ minh họa trong khóa đào tạo chống phishing, vậy mà vẫn xảy ra nên cũng không lạ
    • Thực ra gần như là ngược lại. Việc những trò lừa đảo lộ liễu và ngớ ngẩn nhất lại hiệu quả nhất là điều đã được ghi nhận rất rõ, vì đó là cách tốt nhất để lọc ra những nạn nhân tiềm năng dễ mắc bẫy nhất
      https://www.microsoft.com/en-us/research/publication/why-do-...
    • Chắc còn tùy người. Có quản lý phải duyệt nhiều khoản thanh toán như vậy vài lần mỗi ngày nên có thể thấy những cuộc gọi kiểu đó rất phiền, và nhân viên cũng có thể muốn tránh các cuộc trao đổi như vậy
      Kẻ tấn công có thể chèn câu như “Tôi đang đi công tác. Nếu vẫn chưa chắc thì hãy gọi vào số di động cá nhân của tôi...” rồi sau đó trả lời bằng giọng nói giả mạo
      Một cách tốt để tiếp cận mục tiêu có thể là “chuyển tiếp hai tầng”. Kẻ gửi giả làm một nhân viên chuyển tiếp email của quản lý đến một người ở gần bộ phận hành chính, rồi người đó lại chuyển tiếp một email bề ngoài vô hại vì lý do như chúc mừng sinh nhật hay thông báo nghỉ ốm, khiến mục tiêu thật khó xác định được nguồn gốc ban đầu của email
      Ngoài ra cũng rất dễ nghĩ ra những cách sáng tạo hơn để lạm dụng “tính năng” này. Ví dụ có thể khiến một người không hề hay biết chuyển tiếp nội dung có vấn đề rồi dùng chuyện đó để tống tiền họ
    • Nếu là tình huống các email kiểu này được gửi tới bộ phận phải trả của một công ty lớn thì cũng không hẳn phi thực tế
      Khi yêu cầu thanh toán đến qua email, nhân viên phụ trách sẽ không gọi cho quản lý trực tiếp mỗi lần, nhất là khi số tiền nhỏ và không cần phê duyệt trước
      Tôi nhớ là Google cũng từng bị lừa trả tiền cho ai đó dù không hề có công việc thực tế nào được thực hiện. Trường hợp đó có hóa đơn giả, nhưng nguyên lý thì giống nhau
    • Về mặt lý thuyết, điều này có thể cho phép các cuộc tấn công tinh vi và nhắm đích hơn, như thay đổi người thụ hưởng của khoản chuyển tiền. Những cuộc tấn công như vậy khó bị phát hiện hơn nhiều

  • Mấy ngày trước tôi xem một email “cập nhật” do designer làm, và vì cái header đồ họa to vô lý ở trên cùng nên nếu không cuộn xuống thì thậm chí còn chẳng thấy được cả phần văn bản nội dung email
    Sau đó tôi chuyển tiếp một phiên bản khác để xin phản hồi, thì người đó bỗng hoảng lên nói có vẻ như font đã nhỏ đi một chút, rồi bảo “À, khi chuyển tiếp thì nó bị chuyển sang bản desktop chứ không phải bản mobile!”
    Tôi chỉ biết nhìn chằm chằm không tin nổi. Đây là email cơ mà, “bản desktop” với “bản mobile” nghĩa là gì? Sao chuyện đó lại tồn tại được? “Bị chuyển đổi” là sao? Chỉ là sao chép thôi mà. Việc nó “vỡ” khi chuyển tiếp tự nó đã cho thấy cách làm này ngu ngốc đến mức nào. Tại sao email của tôi lại phải có CSS?
    Nếu chỉ để thể hiện những thứ như chữ nghiêng thì đáng lẽ người ta nên dùng một cách đơn giản hơn nhiều như Markdown từ lâu rồi mới phải, vậy mà đến giờ vẫn không làm thì thật vô lý. Điều đó cho thấy mức độ thiếu quan tâm đến việc thực sự cải thiện tình hình này. Tất cả chỉ là để đáp ứng những yêu cầu doanh nghiệp kỳ quặc muốn nhét logo và banner vào khắp nơi. Email HTML thực sự quá lố bịch

    • Nếu chỉ đơn giản muốn thể hiện chữ nghiêng các kiểu thì có vẻ bạn đang cần text/enriched [1], ra mắt từ năm 1996. Khả năng cao gần như mọi email client đều có thể hỗ trợ đọc
      [1] https://www.rfc-editor.org/rfc/rfc1896.txt
    • Các framework email responsive như MJML thực sự có tồn tại

  • Tôi đã nói từ lâu rằng văn bản có định dạng trong email nên dùng một dạng gần giống Markdown nhưng bỏ inline HTML, hoặc một kiểu đánh dấu văn bản thuần túy đơn giản tương tự, thay vì HTML
    Như vậy email client có thể dễ dàng quyết định nên hiển thị dưới dạng văn bản có định dạng hay chỉ là văn bản thuần, đồng thời vẫn hỗ trợ hầu hết các định dạng mà người dùng phổ thông cần: in đậm, in nghiêng, trích dẫn, hình ảnh nội tuyến, code block, tiêu đề, v.v.
    Có thể không phù hợp với các email marketing dùng HTML rất nâng cao, nhưng tôi không nghĩ đó là trường hợp sử dụng đáng để bận tâm

    • Có một thứ tương tự là text/enriched được định nghĩa trong RFC 1896. Apple Mail và một số ứng dụng khác cũng hỗ trợ
      https://en.wikipedia.org/wiki/Enriched_text
      https://www.rfc-editor.org/rfc/rfc1896.html
    • Nhiều trình phân tích Markdown cho phép inline HTML. Trong một số ngôn ngữ thì hầu hết đều như vậy, và chỉ có một số parser cho phép tắt nó đi. Thật ngớ ngẩn
    • Cách trình duyệt Lynx hiển thị HTML trong terminal văn bản cũng hoạt động khá tốt, nên tôi không hiểu tại sao lại còn cần một ngôn ngữ markup khác nữa
    • Rất khó đạt được mức độ chấp nhận đủ rộng. Vì chuẩn email rất khó thay đổi
      Đến giờ email thậm chí vẫn chưa có hỗ trợ tạo hyperlink, và gần đây đã có người thử sửa chuyện đó
      https://pastebin.com/kHQs50xm
    • Màu sắc và kích thước là những yếu tố cơ bản và hữu ích của việc viết lách

  • Rủi ro thực sự đối với tổ chức là nhà phát triển được giao tạo email HTML phát điên, cố thủ trong phòng máy chủ rồi vừa hét “tại sao Outlook render khác nhau” vừa đập nát toàn bộ phần cứng
    Dĩ nhiên nói nghiêm túc thì đây là một lỗ hổng rất thú vị

    • Vì thế từ vài năm trước, tôi đã quyết định cứ trả tiền cho dịch vụ code email HTML. Để code được template HTML vượt qua kiểm thử Litmus cần rất nhiều kiến thức chuyên biệt, và tôi không muốn quay lại đó thêm lần nào nữa

  • Liệu có thể khắc phục bằng cách không cho phép stylesheet mà chỉ cho phép thuộc tính style inline trên thẻ không?
    Vì tính khả dụng, ứng dụng email thậm chí có thể thêm một bước tự động “biên dịch” mọi stylesheet thành style inline
    Làm vậy thì có lẽ chỉ làm hỏng các CSS selector nâng cao, ví dụ như hover, nhưng tôi không chắc chúng có thật sự cần thiết không

    • Đồng ý. Có vẻ chỉ cần nung chảy mọi class thành style inline trước khi hiển thị mail là giải quyết được. Dù sao làm vậy cũng hợp lý hơn
      Pseudo-class và media query sẽ không hoạt động, nhưng chúng có thể là rủi ro bảo mật và cũng không được các ứng dụng email lớn hỗ trợ: https://www.caniemail.com/features/css-at-media/
    • Email HTML vốn đã phải inline hóa CSS vì Outlook và Gmail dùng các engine render có tuổi đời hàng chục năm. Outlook theo đúng nghĩa đen dùng MS Word HTML engine từ khoảng năm 2006
      Hơn nữa nếu giết hết mọi thuộc tính style thì tối ưu hóa di động và dark mode cũng chết theo. Vì media query không thể inline hóa được
    • Khi đó cả cách tiếp cận email responsive hiện nay cũng sẽ hỏng
      Thông thường các style mặc định/desktop đã được biên dịch và inline sẵn, còn các selector media query thì đặt trong thẻ style trong head để dễ đọc hơn trên thiết bị di động

  • Thật sự rất thông minh
    Tiền đề là CSS trong email HTML có thể khiến một số văn bản chỉ hiển thị sau khi thông điệp đã được truyền đạt. Đây là mối đe dọa lớn đối với độ tin cậy của email đã được xác thực
    Có các ví dụ với Thunderbird, Outlook, Gmail, và đây là công trình rất xuất sắc
    Tôi đọc toàn bộ mail bằng mutt, nên về mặt chính thức đây là “vấn đề của người khác”
    Nên để than phiền sang chuyện khác thì, ngày báo cáo cho Mozilla được ghi là 05.03.2024. Tôi đồng ý rằng định dạng ngày little-endian hợp lý hơn kiểu middle-endian của Mỹ
    Nhưng nếu là dân kỹ thuật mà không dùng định dạng ngày ISO 8601 là 2024-03-05, có hoặc không có dấu gạch ngang, thì là sai trái :)

    • Không chỉ vậy, bất kỳ ai dùng định dạng ngày middle-endian đều đang làm sai. Đó là cách phi lý nhất để viết một thứ gì đó
      Little-endian ít nhất còn có ưu điểm là đi ngược với cách viết mọi con số khác, còn middle-endian thì đơn giản là kiểu điên rồ. Mà tất nhiên vì thế nên người Mỹ mới dùng nó

  • Có thể thấy một số ứng dụng email được nhắc đến bọc nội dung thư bằng các thẻ HTML bổ sung và thay đổi CSS cùng tên class
    Tôi thắc mắc tại sao các ứng dụng email không dùng iframe sandbox khi render email HTML. Vẫn còn rủi ro bảo mật sao?

    • Phần HTML bổ sung không phát sinh từ ứng dụng đọc email được chuyển tiếp, mà phát sinh khi chuyển tiếp
      Người chuyển tiếp có thể muốn thêm văn bản vào email, nên đó là hành vi có thể đoán trước
    • Hồi trước người ta đã dùng iframe rồi và đã gặp vấn đề. Không phải vấn đề render hay bảo mật, và nếu tôi nhớ không nhầm thì các phần đó hoạt động tốt
      Chỉ là nếu email có liên kết tới website, và iframe sandbox không cho phép JavaScript, thì ngữ cảnh bảo mật đó sẽ tiếp tục áp vào cả trang được mở ra khi bấm liên kết trong iframe, khiến website không thể dùng JS
      Giải pháp là allow-popups-to-escape-sandbox, nên giờ có vẻ không còn lý do gì để nó không hoạt động

  • Đây là kiểu giải pháp điển hình chặt tay chân để chữa vết thương. Vấn đề là sự yếu kém trong chuẩn hóa email đã cho phép những trò hack như vậy thống trị
    Bản thân HTML nói chung cũng dễ bị các lo ngại kiểu này. Dù vậy vẫn có nhiều email dùng HTML mà không gặp vấn đề gì. Bài viết này đọc giống như sự bực bội cá nhân về thứ gì đó gặp ngoài thực tế được gói lại như một vấn đề bảo mật

  • Một vài biện pháp giảm thiểu có thể nghĩ ra là thế này, dù có thể không hiệu quả: cảnh báo nổi bật với phần tử bị ẩn, ngẫu nhiên hóa số lượng div bọc ở cả phía nhận lẫn phía gửi, yêu cầu xác nhận nếu khi chuyển tiếp kết quả hiển thị thực tế được tính ra khác biệt lớn
    Hoặc xử lý theo hướng ngược lại có thể hiệu quả hơn, vì không cần nhờ sự hỗ trợ từ các ứng dụng khác

  • Chỉ cần sửa thành “tại sao email nguy hiểm với tổ chức” là được

    • Đến mức đó thì thành ra chỉ còn là “tại sao giao tiếp với bên ngoài lại nguy hiểm với tổ chức”
      Bài này nêu ra một con đường tấn công đặc thù của email HTML, nhưng phần lớn các cuộc tấn công qua email cũng có thể dễ dàng chuyển sang WhatsApp, Slack, Jira, Zoom hoặc bất kỳ công cụ nào mà con người dùng để giao tiếp với bên ngoài