Nodemailer cho phép vượt allow-list IDN và chuyển email tới miền do kẻ tấn công kiểm soát

Nodemailer trước 9.1.0 không áp dụng UTS-46 normalization khi mã hóa tên miền quốc tế, khiến domain resolver tính toán một Punycode A-label khác với các parser tuân thủ tiêu chuẩn. Kẻ tấn công có thể tạo địa chỉ người nhận chứa ký tự vô hình hoặc các ánh xạ tương thích, vượt qua kiểm tra domain allow-list nhưng vẫn được chuyển qua SMTP tới các miền do kẻ tấn công kiểm soát.

• nodemailer với semver >= 0 và < 9.1.0 được đánh dấu affected trong bản ghi chuẩn hóa.
• Advisory của nhà phát triển xác định các bản < 9.1.0 bị ảnh hưởng và bản 9.1.0 là bản đã vá.
• Bản ghi cũng chứa default_status: unaffected, nhưng đồng thời nêu rõ phạm vi phiên bản cụ thể ở trên là affected.
• Bằng chứng được cung cấp không xác nhận trạng thái của các nhánh phát hành song song hoặc các bản sau bản vá ngoài phạm vi được nêu trực tiếp.

Nodemailer xử lý miền của địa chỉ người nhận trong _normalizeAddress thuộc lib/mime-node/index.js. Ở các bản bị ảnh hưởng, miền chỉ được chuyển thành chữ thường rồi mã hóa bằng codec Punycode RFC 3492 tích hợp, không áp dụng đầy đủ UTS-46 mapping và normalization trước bước tạo Punycode.

1. Ứng dụng có thể kiểm tra miền người nhận bằng parser tuân thủ UTS-46, chẳng hạn url.domainToASCII, new URL(), parser trên trình duyệt hoặc một IDN library.
2. Kẻ tấn công đưa vào địa chỉ chứa ký tự bị UTS-46 bỏ qua hoặc ánh xạ, như ký tự vô hình hay ký tự tương thích. Parser dùng cho allow-list có thể nhìn thấy miền tin cậy, trong khi Nodemailer tạo ra A-label Punycode khác.
3. Nodemailer dùng miền đã tạo trong SMTP envelope RCPT TO và trong các header địa chỉ, nên quyết định tin cậy và đích gửi thực tế có thể không giống nhau.

Điều kiện khai thác là ứng dụng phải cho phép kẻ tấn công ảnh hưởng tới địa chỉ người nhận, thực hiện quyết định allow-list, block-list hoặc same-domain bằng parser khác, rồi giao việc gửi cho Nodemailer. Bản ghi mô tả khả năng truy cập qua mạng, không yêu cầu quyền và không yêu cầu tương tác người dùng, nhưng độ phức tạp khai thác cao. Việc một A-label cụ thể có thể đăng ký trong TLD mục tiêu và mức độ ảnh hưởng thực tế vẫn phụ thuộc vào luồng ứng dụng và chính sách đăng ký tên miền.

Lỗ hổng có thể bị kích hoạt từ xa qua dữ liệu địa chỉ người nhận nếu ứng dụng nhận đầu vào do kẻ tấn công kiểm soát và áp dụng kiểm tra miền bằng bộ phân tích khác với Nodemailer.

• Không yêu cầu quyền xác thực theo bản ghi chuẩn hóa.
• Không yêu cầu tương tác người dùng theo bản ghi chuẩn hóa.
• Độ phức tạp cao vì cần tạo địa chỉ gây ra khác biệt giữa parser dùng để kiểm tra và parser dùng để gửi, đồng thời cần một luồng gửi email có quyết định tin cậy theo miền.
• Bản ghi đánh dấu public exploit là có; advisory của nhà phát triển kèm một proof of concept cho thấy allow-list có thể chấp nhận một miền nhưng SMTP envelope lại dùng A-label khác.
• Trạng thái khai thác đang hoạt động trong thực tế không được xác lập bởi bằng chứng được cung cấp.

Kết quả kỹ thuật là sự xung đột diễn giải giữa parser dùng để quyết định miền được phép và Nodemailer dùng để tạo địa chỉ SMTP. Một địa chỉ được ứng dụng xem là thuộc miền tin cậy có thể xuất hiện trong SMTP envelope dưới một A-label khác, khiến thư đi tới đích ngoài dự kiến.

• Tác động chính là mất tính bí mật của nội dung email và làm sai tính toàn vẹn của quyết định định tuyến người nhận.
• Lỗ hổng không được bằng chứng cung cấp mô tả như một đường dẫn thực thi mã hoặc chiếm quyền trực tiếp; rủi ro phụ thuộc vào nội dung mà ứng dụng gửi và quyền kiểm soát đầu vào địa chỉ.
• Phạm vi ảnh hưởng có thể bao gồm các luồng xác nhận miền, đăng ký giới hạn theo miền, notification routing và các cơ chế gửi chỉ tới tenant hoặc miền doanh nghiệp.
• Một số A-label tạo ra từ ký tự đặc biệt có thể không đăng ký được trong TLD mục tiêu, nhưng sự khác biệt giữa miền được chấp thuận và miền được gửi vẫn là rủi ro cần xử lý.

• Email được dự định gửi tới miền tin cậy có thể bị chuyển tới một miền khác do kẻ tấn công kiểm soát, làm lộ nội dung thư, liên kết hoặc thông tin được gửi qua email.
• Các quy trình dựa trên allow-list, block-list hoặc kiểm tra “cùng miền doanh nghiệp” có thể đưa ra quyết định sai về người nhận.
• Luồng hiển thị hoặc ghi log miền đã chuẩn hóa để người dùng xác nhận có thể cho thấy miền tin cậy trong khi SMTP envelope chứa miền khác.
• Các tính năng giới hạn theo miền, như đăng ký dành cho nhân viên, gửi tới tenant hoặc notification routing, có thể bị định tuyến sai nếu nhận đầu vào người dùng.
• Mức độ ảnh hưởng phụ thuộc vào dữ liệu ứng dụng gửi và việc ứng dụng có thực hiện quyết định tin cậy theo miền trước khi dùng Nodemailer hay không.

1. Nâng cấp nodemailer lên chính xác bản 9.1.0, sau đó tái tạo dependency tree và xác nhận bản thực tế được triển khai đã thay đổi.
2. Rà soát mọi ứng dụng sử dụng domain allow-list, same-domain check, tenant routing hoặc xác nhận miền trước khi gọi Nodemailer. Kiểm tra riêng các dependency lockfile và bản đóng gói trong container hoặc artifact triển khai.
3. Nếu chưa thể nâng cấp, áp dụng UTS-46 mapping trước hoặc tại bước mã hóa miền, đồng thời dùng cùng quy tắc chuẩn hóa cho bước validation và bước gửi. Advisory đề xuất dùng bộ chuyển đổi khớp với url.domainToASCII và url.domainToUnicode, nhưng cảnh báo đây là WHATWG host parser chứ không chỉ là IDNA mapper.
4. Không sử dụng url.domainToASCII một cách không kiểm soát cho chuỗi có ký tự cú pháp URL. Các ký tự như /, \\, ?, #, % và control characters phải được xử lý hoặc từ chối trước khi đưa vào mapper để tránh tạo ra một diễn giải mới.
5. Có thể từ chối miền nếu giá trị do codec hiện tại tạo ra khác với giá trị sau UTS-46 mapping. Sau khi thay đổi, kiểm thử các ký tự bị bỏ qua, ký tự tương thích, Unicode normalization và các trường hợp miền không hợp lệ trước khi bật lại luồng gửi.

1. Kiểm kê mọi ứng dụng và lockfile đang sử dụng Nodemailer, sau đó xác định các triển khai nằm trong nhánh phiên bản bị ảnh hưởng.
2. Tìm các luồng kiểm tra allow-list, block-list, same corporate domain, tenant hoặc routing dựa trên miền trước khi gọi Nodemailer. Ưu tiên rà soát nơi dùng new URL(), url.domainToASCII, parser phía trình duyệt hoặc IDN library.
3. Kiểm tra code và dependency tree để xác định việc chuẩn hóa đi qua _normalizeAddress trong lib/mime-node/index.js và việc gửi SMTP sử dụng RCPT TO được tạo từ kết quả Nodemailer.
4. Trong môi trường kiểm thử an toàn, so sánh miền mà bước validation chấp thuận với miền A-label xuất hiện trong SMTP envelope đối với các địa chỉ chứa ký tự vô hình, ký tự tương thích hoặc chuỗi Unicode cần UTS-46 mapping. Không gửi dữ liệu nhạy cảm trong phép thử.
5. Đối chiếu log hoặc telemetry SMTP để phát hiện trường hợp miền được ghi nhận ở bước kiểm tra khác với miền trong RCPT TO. Đây là biện pháp giám sát phòng ngừa, không phải IOC được advisory xác nhận; không thấy bản ghi lệch không chứng minh hệ thống an toàn.