SpamChannel: Gửi email giả mạo từ hơn 2 triệu tên miền và gần như trở thành Satan [PDF]

 (media.defcon.org)
1 điểm bởi GN⁺ 2023-09-24 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bài thuyết trình SpamChannel tại DEFCON 31 2023 đề cập đến vấn đề giả mạo khi cố gắng gửi email bằng Cloudflare Worker tới hơn 2 triệu tên miền
  • Thí nghiệm cốt lõi bắt đầu từ việc xử lý việc gửi email theo cách lập trình thay vì thủ công, và nối nó vào luồng triển khai Worker
  • Cloudflare Workers được giới thiệu là môi trường điện toán serverless dựa trên JavaScript, TypeScript và WASM
  • Quy trình cơ bản là tạo dự án bằng npm create cloudflare@latest và triển khai bằng npx wrangler deploy
  • Manh mối để gửi email từ Workers được nối tiếp từ bài viết trên blog Cloudflare về tích hợp MailChannels

Điểm khởi đầu của bài thuyết trình SpamChannel

  • SpamChannel là bản PDF do Marcello Salvati(@byt3bl33d3r) trình bày tại DEFCON 31 2023, bàn về chủ đề gửi email giả mạo từ hơn 2 triệu tên miền
  • Mục tiêu của bài thuyết trình là triển khai việc gửi email trong các điều kiện sau
    • Gửi email theo cách lập trình
    • Gửi thông qua Cloudflare Worker
  • Có kèm theo tuyên bố miễn trừ trách nhiệm liên quan đến trách nhiệm pháp lý với nội dung “đừng phạm tội”

Cloudflare Workers và đầu mối về việc gửi email

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-09-24
Ý kiến trên Hacker News

  • Video bài trình bày: https://www.youtube.com/watch?v=NwnT15q_PS8
    Hoặc cũng có ở đây. Trên Firefox của tôi định dạng video không chạy được, nhưng VLC thì phát được: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF hỏng theo nhiều cách hơn rất nhiều so với những gì bài trình bày này đề cập. Từ góc độ một kỹ sư làm về tăng cường bảo mật email/hỗ trợ khả năng gửi đến hộp thư, lời khuyên luôn là tập trung vào DKIM + DMARC hơn là SPF
    Vì lý do hệ thống cũ, SPF vẫn cần thiết, nhưng không nên dựa vào nó để đảm bảo khả năng gửi thư hoặc chống mạo danh
    Slide 54 nói DKIM + DMARC không giúp gì cho cuộc tấn công này, nhưng điều đó không hoàn toàn đúng
    Chỉ khi bạn đã thiết lập DKIM cho mọi bên gửi được ủy quyền thì mới có thể bật chính sách DMARC p=reject một cách an toàn, và khi đạt đến mức đó bạn có thể bắt đầu loại SPF khỏi các bên gửi bên thứ ba bằng cách dùng modifier trung lập ? trong SPF
    Ví dụ v=spf1 include:relay.mailchannels.net ~all sẽ thành v=spf1 ?include:relay.mailchannels.net ~all
    Khi làm vậy, thư đến từ MailChannels sẽ được các bên nhận hỗ trợ DMARC xử lý SPF là trung lập và buộc dùng DKIM, còn các dịch vụ email cũ cũng phải chấp nhận kết quả trung lập
    Đây không phải giải pháp hoàn hảo, nhưng dù sao email cũng không bao giờ có thể đáng tin cậy hoặc an toàn 100%

    • Vậy tôi tò mò vấn đề của SPF là gì. Việc giả mạo IP nguồn trong TCP khá khó, nên tôi luôn thắc mắc DKIM có lợi thế gì so với SPF
      Tôi đã cấu hình SPF chỉ cho phép $myIP. Muốn gửi spam dưới tên miền của tôi thì trước hết phải hack ISP hoặc nhà đăng ký, và đến mức đó thì họ cũng có thể lấy chứng chỉ TLS cho tên miền của tôi
      Ngay cả ở các tổ chức lớn phải đưa nhiều hệ thống gửi vào danh sách cho phép, tôi cũng không rõ làm sao có thể giả làm một trong các bên gửi SPF hợp lệ trong khi không thể giả mạo bản ghi DKIM
      Trường hợp đưa vào danh sách cho phép các dải IP mà bất kỳ ai cũng có thể dùng công khai như trong bài trình bày được gửi lên thì đơn giản là cấu hình ngu ngốc
      Để giả mạo toàn bộ quá trình trao đổi thư, cần lưu lượng cỡ terabyte chỉ cho một email vài byte, và nếu STARTTLS bị bắt buộc thì điều đó trở nên bất khả thi

  • Chúng tôi đang dùng Cloudflare Workers + MailChannels trong production. Thật rợn người
    Chúng tôi vốn đã đang chuyển từ CF Workers sang máy chủ thật, giờ có lẽ cũng phải rời MailChannels
    Rủi ro bảo mật không đáng đổi lấy sự tiện lợi

    • Kể từ tháng 6/2023, nếu không công bố bản ghi _mailchannels trong DNS thì không thể gửi email qua MailChannels từ Workers
    • Nói cho rõ, vấn đề này nằm ở việc MailChannels không xác thực người gửi có phải là chủ sở hữu đã được xác minh của tên miền gửi hay không. CF Workers không phải vấn đề

  • “Hiển thị banner cho mọi email không có chữ ký DKIM nhưng đến từ một tên miền đã triển khai DKIM” theo cách tôi hiểu thì hầu như là không thể. Vì không có cách nào biết chắc một tên miền đã triển khai DKIM hay chưa
    Về lý thuyết có thể truy vấn DNS tới "_domainkey.example.com" để xem là NXDOMAIN hay NOERROR. Trường hợp sau thường có nghĩa là có tên miền con, và do đó có thể hàm ý rằng trong DNS có một số khóa DKIM
    Nhưng bạn không thể biết tên selector, cũng không biết khóa đó đang hoạt động hay chỉ định kích hoạt sau này
    Một tên miền có thể có nhiều bên gửi đã được xác thực, trong đó một số dùng chữ ký DKIM còn một số thì không
    Không phải máy chủ DNS nào cũng tuân thủ chuẩn đúng cách, nên việc phân biệt NXDOMAIN/NOERROR nhìn chung cũng chỉ hoạt động tương đối

    • Nếu là nhà cung cấp quan sát được một tỷ lệ lưu lượng mail có ý nghĩa thống kê, họ có thể thấy tất cả hoặc gần như tất cả DKIM selector
      Câu được trích có vẻ muốn nói là nên từ chối thư đến từ MailChannels mà không có chữ ký DKIM

  • “Khách hàng chính của MailChannels là các nhà cung cấp web hosting không sở hữu tên miền của những email họ gửi” là lời biện minh tệ nhất tôi nghe được trong một thời gian qua
    Nhà cung cấp web hosting thường không “sở hữu” các tên miền họ hosting, nhưng họ chắc chắn biết mình đang hosting những tên miền nào. Định tuyến tên miền tới tài khoản/thư mục của khách hàng chính là cốt lõi của web hosting
    Điều cần làm chỉ là một dạng tích hợp như cPanel để báo cáo danh sách tên miền và gắn mỗi tên miền với một khóa được tạo ngẫu nhiên
    Tất cả những việc này có thể và nên được tự động hóa mà không làm phiền người dùng cuối

    • Thế còn mailing list thì sao? Còn chuyển tiếp mail thì sao?

  • Sẽ tốt nếu đặc tả DMARC phát triển để có cách chỉ dùng DKIM cho việc xác thực, chứ không phải SPF. Đáng tiếc là những thứ như lời mời Google Calendar hiện vẫn thất bại với DKIM

    • Nhiều khả năng bản phát hành DMARC tiếp theo sẽ có tùy chọn loại trừ SPF khỏi quá trình xác thực DMARC. Nhóm Google đang thúc đẩy việc này trên danh sách thư IETF DMARC:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Tôi thấy đây là một ý tưởng rất hay, vì chủ sở hữu tên miền có thể dùng DMARC nhưng vẫn chỉ định rằng “cơ chế thực sự xác thực lưu lượng của tên miền tôi chỉ nên là DKIM”
      Trong ngành có nhiều cách lách qua điểm yếu của SPF và DMARC, như macro SPF cho phép điều chỉnh xác thực một cách động dựa trên các tiêu chí chỉ có thể biết tại thời điểm diễn giải SPF
      Nhưng không cách lách nào tốt hơn việc nói “với tên miền của tôi, xin chỉ dùng DKIM”

  • Gần đây tôi đã tự trải qua việc chuẩn bị email cho tên miền của mình, và đặc biệt là cực kỳ bực bội vì ISP quy định rằng “muốn gửi email từ thiết bị của mình thì phải là tài khoản doanh nghiệp”; những chuyện như thế này thật sự khiến tôi nổi giận
    Tôi đã cố hết sức để trở thành một thành viên có trách nhiệm của mạng lưới, đào sâu và mổ xẻ đến mức cập nhật nhất hiện nay để cấu hình hệ thống của mình cho đúng
    Vậy mà không chỉ có những người như vậy tồn tại, họ còn vận hành hời hợt gần như một open relay, và gần nửa Internet phải trả giá cho điều đó — thật không thể tin nổi

  • Tóm lại, câu chuyện là họ đã phát hiện các open relay được đưa vào nhiều bản ghi SPF

    • Trong số 2 triệu tên miền tự mở mình qua bản ghi SPF, chỉ dưới 1.000 tên miền thiết lập bản ghi DKIM/DMARC; thậm chí có trường hợp cấu hình DKIM rồi bỏ mặc thì Gmail vẫn cho qua như đã được xác thực
    • Còn tệ hơn nữa: bản thân nền tảng thậm chí không cố xác minh quyền sở hữu tên miền, nên có thể gửi dưới tên của bất kỳ ai
    • Nói nghiêm ngặt thì đây không phải là open relay. Nếu MailChannels không kiểm soát spam và phishing một cách quyết liệt, nó đã không thể tồn tại trên Internet
      Bài trình bày DEFCON không chứng minh sự tồn tại của một lỗ hổng khổng lồ, mà cho thấy một sự thật đã tồn tại từ những ngày đầu của email Internet
      Nếu không dùng chữ ký thông điệp như S/MIME hay DKIM, không thể xác thực đầy đủ tên miền người gửi
      Ngay cả khi có DKIM, tấn công phát lại DKIM vẫn có thể bị lạm dụng trên diện rộng

  • Tác động của header ARC lên điểm spam khá thú vị. Với tư cách người vận hành máy chủ mail cá nhân, liệu chỉ cần thêm một bộ header ARC vô nghĩa vào email của mình là có thể tăng tỷ lệ gửi đến nơi không?

    • Tôi muốn nói là không. Vì nếu điều đó là thật, mọi hộp thư đến của tôi rải rác ở nhiều nhà cung cấp hẳn sẽ bị spam tràn ngập
      Những spammer có tổ chức và hiểu biết chắc chắn đang đào bới tất cả những thứ kiểu này, và chắc chắn sẽ dùng chúng để vượt qua bộ lọc
    • Trong ngành email, ARC không được xem là cách hoàn hảo để vượt qua bộ lọc spam của các bên nhận lớn. Diễn giả DEFCON chưa đủ cơ sở để đưa ra kết luận như vậy

  • Có vẻ việc này đã được xác nhận từ tháng 5/2022: https://news.ycombinator.com/item?id=30533032

    • Có vẻ CEO đã nói như sau:
      “Chúng tôi có năng lực phát hiện spam và phishing trên diện rộng, và có thể xử lý lạm dụng”
      À, ra vậy :D