Thư Kobold: Sự nguy hiểm của email HTML
(lutrasecurity.com)Thư Kobold
- Những người phải xử lý email HTML về mặt kỹ thuật hẳn đã có lúc muốn nghỉ việc hoặc muốn đốt sạch mọi trình khách email vì cách triển khai không nhất quán giữa các client.
- Email HTML không chỉ đơn thuần gây bực bội mà còn có thể trở thành một rủi ro bảo mật nghiêm trọng.
- Hãy tưởng tượng sếp chuyển tiếp một email yêu cầu chuyển một khoản tiền lớn; vì bạn từng nghe về các vụ lừa đảo giả mạo CEO nên bạn sẽ kiểm tra xem email đó có thật sự đến từ sếp hay không.
- Email đúng là từ sếp, và nếu công ty làm như vậy thì thậm chí nó còn có thể được ký mã hóa.
- Nhưng bạn vẫn chưa hoàn toàn chắc chắn, nên gọi điện cho sếp để xác minh tính xác thực của email.
- Khi sếp xác nhận, bạn chuyển tiền.
- Nhưng nếu đây không phải là một vụ lừa đảo thì bài viết này đã kết thúc ở đây rồi.
Thunderbird
- Vấn đề này đã được báo cáo cho Mozilla vào ngày 5 tháng 3 năm 2024, và ngày phát hành dự kiến cùng bản nháp của phần tiếp theo đã được gửi cho Mozilla vào ngày 20 tháng 3 năm 2024.
- Các biện pháp giảm thiểu khả thi đã được thảo luận, nhưng dự kiến chỉ được triển khai sau này.
- Việc khai thác điều này trên Thunderbird rất đơn giản. Thunderbird bọc email trong `
` và ngoài ra không thay đổi gì.
- Khi chuyển tiếp email, email được trích dẫn sẽ được bọc trong một `
` khác và bị đẩy xuống một cấp trong DOM.
- Xét đến điều đó, ta có đoạn proof of concept sau:
.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.
- Email chứa văn bản luôn hiển thị và văn bản bị ẩn bằng
display: none;. - Khi email được chuyển tiếp, đoạn văn bản ẩn đột nhiên chỉ hiện ra với người nhận mới.
Outlook Web
- Vấn đề này đã được báo cáo cho Microsoft vào ngày 5 tháng 3 năm 2024, và ngày phát hành dự kiến cùng bản nháp của phần tiếp theo đã được gửi cho Microsoft vào ngày 20 tháng 3 năm 2024.
- Vào ngày 26 tháng 3 năm 2024, Microsoft quyết định không thực hiện hành động ngay lập tức và đóng báo cáo.
- Trong Outlook Web (OWA), tình hình phức tạp hơn một chút. Email được bọc trong `
`, nhưng tên class chính xác có thể thay đổi.
- Để CSS của email không ảnh hưởng đến style của webmailer, Outlook thêm tiền tố
x_vào mọi id và class trong email rồi điều chỉnh CSS. - Xét đến điều đó, ta có đoạn proof of concept sau:
.kobold-letter {
display: none;
}
body>div>.kobold-letter {
display: block !important;
}
This text is always visible.
This text will only appear after forwarding.
- Khi hiển thị email trong OWA, CSS sẽ trông như sau:
- Sau khi email được chuyển tiếp, thư Kobold lại được bọc trong một `` khác và CSS lại được cập nhật.
Gmail
- Vấn đề này đã được báo cáo cho Google vào ngày 5 tháng 3 năm 2024, và ngày phát hành dự kiến cùng bản nháp của phần tiếp theo đã được gửi cho Google vào ngày 20 tháng 3 năm 2024.
- Về mặt kỹ thuật, Gmail không dễ bị tấn công bởi thư Kobold vì nó loại bỏ toàn bộ style khi email được chuyển tiếp.
- Khi chuyển tiếp email, trước khi CSS bị xóa, thư Kobold bị ẩn bằng CSS sẽ tự động xuất hiện.
Nghiên cứu trước đây
- Khả năng này không phải điều đáng ngạc nhiên hay mới mẻ.
- Các vấn đề tương tự đã từng được báo cáo trong quá khứ.
Triển vọng
- Người dùng có thể giảm thiểu thư Kobold bằng cách tắt hoàn toàn email HTML hoặc xem ở chế độ hạn chế.
- Đối với các trình khách email, việc triển khai biện pháp giảm thiểu là khó khăn. Ngăn việc sử dụng `` có thể giải quyết vấn đề, nhưng cũng có thể phá vỡ nhiều giải pháp đã tồn tại trong hệ sinh thái email.
- Đáng tiếc là không thực tế khi kỳ vọng các trình khách email sẽ triển khai biện pháp giảm thiểu vững chắc trong tương lai gần.
Ý kiến của GN⁺
- Bài viết này cho thấy các lỗ hổng của email HTML, đặc biệt giải thích về cuộc tấn công 'thư Kobold', nơi nội dung có thể thay đổi khi email được chuyển tiếp. Đây là thông tin quan trọng giúp nâng cao nhận thức bảo mật cho người dùng email.
- Bài viết cho thấy lỗ hổng bảo mật có thể phát sinh tùy theo cách các trình khách email xử lý CSS, đồng thời kêu gọi cả người dùng lẫn nhà phát triển chú ý hơn đến bảo mật.
- Kiểu tấn công này đặc biệt nguy hiểm vì nó trông như đến từ một nguồn mà người dùng tin tưởng. Điều này nhấn mạnh sự cần thiết phải luôn cảnh giác trong giao tiếp qua email.
- Ở góc độ kỹ thuật, các nhà phát triển trình khách email cần cải thiện cách xử lý CSS để ngăn chặn các cuộc tấn công như vậy. Tuy nhiên, điều này có thể gây ra vấn đề tương thích với thiết kế email hiện có, nên điều quan trọng là phải tìm được sự cân bằng phù hợp.
- Bài viết này không nói về công nghệ mới hay mã nguồn mở, nhưng đưa ra những điểm cần cân nhắc khi áp dụng các công nghệ liên quan đến bảo mật email. Các nhà phát triển trình khách email cần tìm cách tăng cường bảo mật cho người dùng mà vẫn duy trì được tính khả dụng.
1 bình luận
Ý kiến Hacker News
The other day I was discussing the design for an "update" email that our designer was putting together...
I long argued that we should use markdown (without the inline HTML) or a similar simple text markup...
The real risk to your organisation is that the developer you assign to generate HTML emails will go mad...
Wouldn’t this be fixable by not allowing Stylesheets but only inline style attributes on the tags?
HTML in email shouldn't be as big of a nightmare as it is.
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.
This is really clever!