Cách bẻ khóa khóa DKIM 512 bit với chi phí đám mây dưới 8 USD

 (dmarcchecker.app)
3 điểm bởi GN⁺ 2025-01-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khảo sát 1 triệu website hàng đầu phát hiện hơn 1.700 khóa công khai DKIM dưới 1.024 bit, và thí nghiệm kiểm tra liệu khóa RSA DKIM 512 bit của redfin.com có thực sự có thể bị khai thác hay không
  • Giải mã thẻ p của bản ghi DKIM để lấy mô-đun RSA n và số mũ công khai e=65537, sau đó phân tích thừa số mô-đun bằng CADO-NFS
  • Trên máy chủ Hetzner với 8 vCPU dedicated, 32GB RAM, mất khoảng 86 giờ để tách n thành hai số nguyên tố p, q, rồi từ đó tái tạo khóa riêng RSA
  • Khi dùng khóa riêng đã tái tạo để ký email gửi từ security@redfin.com, Gmail và Outlook từ chối nhưng Yahoo Mail, Mailfence, Tuta trả về dkim=pass
  • Với chính sách DMARC p=reject; pct=100 của redfin.com, DKIM vượt qua sẽ dẫn tới DMARC vượt qua, nên các nhà cung cấp email cần từ chối chữ ký DKIM RSA dưới 1.024 bit

Vấn đề các khóa DKIM 512 bit vẫn còn tồn tại

  • Trong khảo sát bản ghi SPF, DKIM, DMARC trên 1 triệu website hàng đầu, đã phát hiện hơn 1.700 khóa DKIM công khai có độ dài dưới 1.024 bit
  • Khóa RSA dưới 1.024 bit được xem là không an toàn, và với DKIM thì từ RFC 8301 năm 2018 đã bị khuyến nghị loại bỏ
  • Đối tượng thí nghiệm là khóa công khai RSA 512 bit được tìm thấy tại key1._domainkey.redfin.com
  • Mục tiêu là xác minh liệu chỉ với khóa công khai có thể khôi phục khóa riêng và ký email như thể được gửi từ miền gốc hay không
  • Đồng thời cũng kiểm tra xem các nhà cung cấp email lớn như Gmail, Outlook.com, Yahoo Mail có cho phép chữ ký DKIM tạo bằng khóa ngắn vượt qua hay không

Trích xuất thành phần RSA từ khóa công khai DKIM

  • Trong thẻ p của bản ghi DKIM, khóa công khai được mã hóa theo định dạng ASN.1 DER rồi tiếp tục được mã hóa Base64
  • Dùng Crypto.PublicKey.RSA.import_key của Python để đọc khóa công khai và trích xuất các thành phần RSA
    • Mô-đun n: 10709580243955269690347257968368575486652256021267387585731784527165077094358215924099792804326677548390607229176966588251215467367272433485332943072098119
    • Số mũ công khai e: 65537

Phân tích thừa số mô-đun bằng CADO-NFS

  • Để tạo khóa riêng RSA, cần phân rã mô-đun n thành tích của hai số nguyên tố p và q
  • Việc phân tích thừa số được thực hiện bằng CADO-NFS
    • CADO-NFS là một triển khai thuật toán Number Field Sieve (NFS) dùng để phân tích thừa số các số nguyên lớn
  • Để tránh chiếm dụng máy tính cá nhân trong nhiều ngày, tác giả thuê máy chủ đám mây của Hetzner
    • Cấu hình máy chủ là 8 vCPU dedicated, AMD EPYC dòng 7003, 32GB RAM
    • Hệ điều hành là Ubuntu
    • Đã bổ sung 32GB swap để đảm bảo đủ bộ nhớ cho tác vụ
  • Đưa mô-đun n vào cado-nfs.py để chạy phân tích thừa số
  • Toàn bộ quá trình mất khoảng 86 giờ trên máy chủ 8 vCPU, và n được phân rã thành hai số nguyên tố sau
    • p = 97850895333751392558280999318309697780438485965134147739065017624372104720767
    • q = 109447953515671602102748820944693252789237215829169932130613751100276125683257
  • Có thể rút ngắn thời gian nếu dùng máy chủ mạnh hơn hoặc chạy phân tán trên nhiều hệ thống, và CADO-NFS giúp đơn giản hóa việc chạy phân tán

Tái tạo khóa riêng RSA

  • Sau khi có p, q, e, tác giả dùng Python và PyCryptodome để dựng lại khóa riêng RSA
  • Các giá trị và quy trình tính toán như sau
    • n = p * q
    • phi = (p-1) * (q-1)
    • d = inverse(e, phi)
    • RSA.construct((n, e, d, p, q))
  • Kết quả là một khóa riêng RSA ở định dạng PEM, được tích hợp vào cấu hình OpenDKIM để ký email thử nghiệm

Kết quả xác thực DKIM theo từng nhà cung cấp email

  • Đưa khóa riêng đã tái tạo vào OpenDKIM và gửi email thử nghiệm với địa chỉ FROM là security@redfin.com tới nhiều dịch vụ lưu trữ email khác nhau
  • Phần lớn nhà cung cấp đánh giá khóa 512 bit là không an toàn và từ chối chữ ký DKIM, nhưng có ba nơi trả về dkim=pass
  • Kết quả theo từng nhà cung cấp như sau
    • Gmail: FAIL
    • Outlook: FAIL
    • Yahoo Mail: PASS
    • Zoho: FAIL
    • Fastmail: FAIL
    • Proton Mail: FAIL
    • Mailfence: PASS
    • Tuta: PASS
    • GMX: FAIL
    • OnMail: FAIL
  • redfin.com có bản ghi DMARC hợp lệ ở dạng v=DMARC1;p=reject;pct=100;...
  • Việc vượt qua xác thực DKIM cho redfin.com cũng dẫn tới vượt qua xác thực DMARC, đồng thời đáp ứng cả yêu cầu của BIMI

Chi phí và biện pháp vận hành

  • Nếu như 30 năm trước việc bẻ khóa khóa công khai RSA 512 bit đòi hỏi sức mạnh siêu máy tính, thì hiện nay có thể thực hiện trên máy chủ đám mây với chi phí dưới 8 USD
  • Nếu có máy tính cá nhân mạnh với từ 16 lõi trở lên, thậm chí có thể làm nhanh hơn và rẻ hơn
  • Không có lý do gì để tiếp tục duy trì khóa DKIM 512 bit hay 768 bit, và các nhà cung cấp email nên tự động từ chối chữ ký DKIM được tạo bằng khóa RSA dưới 1.024 bit
  • Kết quả thí nghiệm và khuyến nghị đã được gửi tới Yahoo, Mailfence và Tuta
  • Chủ sở hữu miền cần kiểm tra các bản ghi DKIM cũ trong cấu hình DNS
    • Có thể kiểm tra đơn giản bằng cách đếm số ký tự Base64 trong thẻ p của bản ghi DKIM
    • Khóa công khai RSA 1.024 bit có ít nhất 216 ký tự tính theo Base64

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-09
Ý kiến trên Hacker News

  • Ngay cả 14 năm trước, khóa RSA DKIM 512-bit cũng đã có thể bị bẻ: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b...

    • Trong một thời gian, việc dùng khóa DKIM yếu từng được không chính thức xem như một tính năng
      Lập luận là khóa ngắn khiến chữ ký DKIM không còn giữ được giá trị bằng chứng quá lâu, từ đó khó chứng minh về sau email nào là thật, giúp duy trì khả năng chối bỏ
      Tất nhiên điều đó không có nghĩa là phần lớn công ty dùng khóa ngắn vì lý do ấy, mà là đã từng có một bầu không khí cho rằng khóa ngắn không hoàn toàn là điều xấu
      Cá nhân tôi đã bám theo chủ đề tính chối bỏ của DKIM khá lâu [1], và tuy những khóa ngắn như vậy rõ ràng không phải lời giải, tôi xem chúng là kết quả của lối suy nghĩ rối rắm quanh DKIM và tâm lý cộng đồng không muốn chấp nhận những hệ quả mà mọi cơ chế ký email đều mang theo
      [1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
    • Nhớ lại câu chuyện có người đã bẻ khóa DKIM vì tưởng đó là bài thử thách tuyển dụng của Google
      https://www.wired.com/2012/10/dkim-vulnerability-widespread/
    • Năm 1999, việc phân tích thừa số RSA-155 bằng hàng trăm máy tính đã cho thấy khóa 512-bit có thể bị bẻ theo cách thực tế, và hiện nay có ý kiến cho rằng với phần cứng phổ thông chỉ cần vài tuần
      Tính ra trong khoảng 14 năm, thời gian đã giảm từ vài tuần xuống còn 8 giờ
    • Để tham khảo, tác giả của bình luận cha là CTO của CloudFlare
    • Blog đó cũng đã được nhắc đến trong phần bình luận của http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-...

  • Nếu muốn thử cho vui thì hãy tạo một khóa DKIM 4096-bit
    Các trình kiểm tra DKIM/SPF trực tuyến sẽ nói mọi thứ đều bình thường nếu chỉ nhìn DNS, nhưng email thử nghiệm lại thất bại
    Bạn sẽ thấy một lời giải thích tuyệt vời kiểu STATUS: Fail, DKIM: Pass, SPF: Pass
    Việc dùng khóa lớn hơn 2048-bit trong mục DKIM là được phép và hợp lệ, nhưng trình xác thực không bắt buộc phải xử lý khóa lớn hơn 2048-bit
    Tôi đã phải tự học điều này theo cách khá đau đầu

    • Bổ sung là để thấy việc kiểm tra thất bại, bạn phải đặt chính sách DMARC nghiêm ngặt
      Điều thú vị là các trang vẫn nói cả ba mục đều đúng và hợp lệ, nhưng email thì lại bị đánh trượt
      Có lẽ là vì việc kiểm tra bản ghi DNS và việc xác thực email được xử lý bởi hai phần mềm khác nhau
    • RFC8301 mới hơn có đưa ra yêu cầu
      Trình xác thực phải có khả năng xác minh chữ ký dùng khóa từ 512-bit đến 2048-bit, và có thể xác minh cả khóa lớn hơn
      Một năm trước tôi đã viết luận văn thạc sĩ về chủ đề này, và hiện nay các nhà cung cấp email lớn đều hỗ trợ 4096-bit, một số còn hỗ trợ tới 16384-bit

  • Tôi thắc mắc vì sao trong toàn bộ lĩnh vực mật mã người ta không tăng mạnh kích thước khóa nói chung
    Dù không phải lời giải triệt để, ít nhất nó có vẻ là biện pháp câu giờ
    Hiệu năng tính toán đang tăng nhanh và câu chuyện máy tính lượng tử vẫn liên tục xuất hiện, nhưng cảm giác như mọi người vẫn đứng yên
    Tất nhiên khóa lớn hơn sẽ tốn chi phí tính toán hơn, nhưng vì tài nguyên tính toán của chúng ta cũng tăng lên nên có lẽ không nên chỉ dùng nó cho phía tấn công mà cũng nên dùng cho phòng thủ
    Ngay cả việc đơn giản như ép phía client dùng TLS 1.3 thay vì TLS 1.2 cũng làm hỏng khá nhiều thứ, bao gồm cả trang HN

    • Bài viết cũ nhưng vẫn còn liên quan: https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
      Những con số này không liên quan đến trình độ công nghệ thiết bị mà liên quan đến giới hạn tối đa mà nhiệt động lực học cho phép
      Kết luận là việc brute force AES-256 hay RSA-4096 là bất khả thi về mặt vật lý
    • Thực ra người ta đã làm vậy rồi
      Khóa 1024-bit đã bị loại bỏ khỏi nhiều hệ mật trong hơn 10 năm nay
      Trừ một vài ngoại lệ tụt lại phía sau, mối đe dọa với khóa 2048-bit chỉ đến từ máy tính lượng tử, mà điều đó lại đe dọa chính RSA
      Tiến bộ không diễn ra tuyến tính, nên việc 1024 yếu đi không có nghĩa 2048 cũng sẽ sớm sụp đổ theo kiểu máy móc, và ngay cả 1024 thì các cuộc tấn công thực chiến ngày nay cũng không hề dễ
    • RSA-2048 vẫn chưa bị bẻ, và tiếp theo thì trong hầu hết nơi dùng RSA người ta đã khá phổ biến với RSA-4096 rồi
      DKIM là một trong những ngoại lệ
      Phía DKIM đang chờ Ed25519 được chấp nhận rộng rãi hơn, khi đó nhiều bất tiện sẽ được giải quyết
    • Muốn ép mọi người dùng thì cuối cùng vẫn phải làm hỏng thứ gì đó
      Thường thì nỗi đau đó không đổ lên nhà vận hành dịch vụ mà rơi trực tiếp vào người dùng, rồi người ta hy vọng người dùng sẽ phàn nàn đủ nhiều để nhà vận hành quan tâm
      Nhưng người dùng cũng rất dễ chuyển sang đối thủ cạnh tranh, nơi những chuyện nhỏ như bảo mật không cản trở họ tạo doanh thu
    • Ngay cả 8 năm trước khi làm trong ngành email, DKIM 512-bit cũng đã cực kỳ hiếm
      Về cơ bản đây giống như đang hỏi: “Tại sao các anh không làm điều mà chúng tôi vốn đã làm rồi?”

  • Dùng CADO-NFS thì làm việc này lại dễ hơn tưởng tượng
    Vài tuần trước, vì công việc tôi đã phân tích thừa số một khóa RSA DKIM 512-bit trên máy tính để bàn và chỉ mất 28 giờ
    Cụ thể là AMD Zen 5 9900X
    Đáng tiếc là khóa 1024-bit vẫn còn ngoài tầm với của nỗ lực kiểu sở thích cá nhân, nhưng có thể khả thi với một dự án học thuật quy mô như lần phân tích khóa 768-bit năm 2010: https://eprint.iacr.org/2010/006.pdf

  • Hôm qua tôi nhận được một email từ Bank of America về vấn đề thiết lập tài khoản
    Đúng là tôi có tạo một tài khoản mới, và email cũng biết việc đó cùng tên công ty và các thông tin tương tự
    Không có liên kết nào, chỉ hướng dẫn gọi vào số doanh nghiệp của BofA, và khi tôi kiểm tra số đó trên website của BofA thì đúng là trùng khớp nên tôi đã gọi
    Nhưng không ai có thể cho tôi biết vì sao tôi nhận được email này, hoặc tài khoản có vấn đề gì, và nhân viên hỗ trợ cũng không tìm thấy bản ghi nào về việc email này đã được gửi
    Tôi chắc chắn 100% email này đến từ Bank of America
    Không có dấu hiệu lừa đảo nào, không có liên kết hay số điện thoại độc hại
    SPF, DKIM, DMARC đều vượt qua trong ARC-Authentication-Results của Google, và khóa DKIM cũng là 2048 bit
    Khi tôi yêu cầu Bank of America điều tra, họ trả lời rằng “chắc đó là tin nhắn lừa đảo” và gửi cho tôi một liên kết hướng dẫn cách đề phòng phishing
    Nhiều khả năng đây chỉ là lỗi đơn giản do một hệ thống nào đó đã chạy kiểm tra tính nhất quán quá sớm trong quá trình tạo tài khoản rồi sinh ra email
    Nhưng vì họ nói đó là “phishing”, tôi đã gửi FedEx cho CTO kèm toàn bộ tài liệu
    Chỉ có hai khả năng: hoặc khóa DKIM đã bị lộ và họ cần phát cảnh báo công khai ngay lập tức, hoặc nhân viên thiếu năng lực và hệ thống IT của họ đã bắt tôi chạy lòng vòng, lãng phí một giờ đồng hồ
    Dù là trường hợp nào, tôi cũng muốn có một cuộc điều tra đầy đủ và cách xử lý rõ ràng

  • Một số nhà cung cấp DNS rất tệ, chỉ cho phép thiết lập khóa dài 1024 bit
    Ví dụ wordpress.com là như vậy

    • 1024 bit khó bị bẻ hơn 512 bit đến nhiều bậc độ lớn
      Để tham khảo, số RSA gần đây nhất bị bẻ là RSA-250, tức 829 bit, và vào năm 2020 đã tốn 2700 core-year [1]
      Trong khi đó RSA-155, tức 512 bit, đã bị phân tích thừa số từ năm 1999
      Nó chưa ở mức nguy hiểm
      [1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
    • NIST còn định cấm cả RSA 2048 bit vào năm 2035
      Vì cho rằng nó không còn cung cấp mức an toàn đủ cao
    • Có thể xem RSA-1024 tốt hơn RSA-512 khoảng 8 triệu lần, nên để bẻ nó riêng chi phí tính toán có lẽ vào khoảng 64 triệu USD
      Dù chưa phải mức có thể ngăn cả NSA, nhưng nếu xét DKIM chỉ là một trong nhiều lớp bảo vệ thì có vẻ vẫn đủ để chặn spammer
    • Bản ghi DKIM thực ra chỉ là bản ghi DNS TXT
      Tôi tự hỏi liệu có phải bản thân TXT record bị giới hạn kích thước, hay là họ cố parse các TXT record trông giống DKIM rồi thất bại nên từ chối thêm vào

  • Để có một màn trình diễn thuyết phục, việc bẻ khóa 512 bit vẫn là nghiên cứu bảo mật rất có giá trị dù trước đây đã từng làm
    Việc công bố kiểu “đây là danh sách các nơi vẫn còn dùng 512 bit nên họ cần chuyển đi” cũng là điều chính đáng
    Nhưng trực tiếp bẻ các khóa đang được dùng trong hệ thống thực tế ngoài đời thì cá nhân tôi thấy khá khó chịu vì có cảm giác vượt qua ranh giới đạo đức
    Tôi không phải luật sư, nhưng có vẻ nó cũng có thể là hành vi phạm pháp, và hơi không cần thiết

    • Họ đã thông báo lỗ hổng cho công ty liên quan, khắc phục xong rồi mới công bố bài viết
      Chỉ cần tìm now no longer available trong bài gốc là thấy
      Thông thường khi muốn chứng minh một hệ thống trực tuyến có lỗ hổng, người ta sẽ tái hiện lỗ hổng một cách thiện chí, ghi lại nghiên cứu rồi yêu cầu xem xét
      Dù là bẻ một hệ mật mã, đạt thực thi mã tùy ý trên một máy chơi game bị khóa, chứng minh có thể sửa dữ liệu máy bỏ phiếu, hay cho thấy có thể chỉnh sửa bình luận Q&A trên Google Meet thì quy trình cũng giống nhau
      Nếu chỉ nói hệ thống có lỗ hổng thì họ có thể phớt lờ, nhưng nếu vừa nói vừa chứng minh được thì sẽ khó phớt lờ hơn nhiều
      Thêm vào đó, nếu áp dụng thời hạn công bố theo chuẩn ngành và cố liên hệ trong khoảng 60 ngày trước khi công khai lỗ hổng, thì trên thực tế gần như không còn chỗ để họ làm ngơ nữa
    • Bẻ khóa không phải là tội phạm
      Đó đơn giản chỉ là toán học
      Điều bất hợp pháp là dùng phần toán học đó để gửi email lừa đảo hoặc email vi phạm pháp luật của một khu vực tài phán cụ thể
      Điểm cốt lõi không nằm ở toán học mà ở hành vi và ý định
      Chỉ ra rằng ai đó đang làm điều ngớ ngẩn cũng không phải là bất hợp pháp, nhưng họ vẫn có thể tìm cách khiến cuộc sống của bạn trở nên phiền phức
    • Có thể nói điều tương tự với khá nhiều nghiên cứu bảo mật
      Đại loại như “chứng minh bug có thể bị khai thác thì được, nhưng viết mã proof-of-concept là vượt ranh giới”
      Vấn đề là nếu không cho thấy nó thực sự khả thi thì phần lớn mọi người sẽ không lắng nghe nghiên cứu bảo mật
    • Trong khoảng 1700 domain dùng khóa ngắn hơn 1024 bit, chỉ có đúng một cái tên thực sự bị công khai
      Thay vào đó, sau khi thông báo, họ đã công bố 3 trong 10 nhà cung cấp email lớn không tuân thủ đúng DKIM RFC, tức Yahoo, Tuta, Mailfence
    • Nếu chỉ dùng thông tin công khai và không làm gì với kết quả thu được, thì có vẻ bản thân việc bẻ các khóa đang được sử dụng ngoài thực tế nhiều khả năng không phải là tội phạm

  • Đây là lý do tôi phải ngừng dùng Hover để quản lý DNS
    Họ không hỗ trợ TXT record dài hơn 255 ký tự, và tôi cũng không tìm thấy trường hợp nào cho thấy split record hoạt động trên Hover
    Cuối cùng tôi chuyển sang dùng Digital Ocean
    Nếu vấn đề này còn kéo dài thêm 10 năm nữa thì hy vọng mật mã đường cong elliptic sẽ trở thành chuẩn

  • Ở đoạn “đa số nhà cung cấp đã nhận diện đúng khóa 512 bit là không an toàn và từ chối chữ ký DKIM, nhưng ba nhà cung cấp lớn — Yahoo Mail, Mailfence, Tuta — lại báo dkim=pass”, tôi thắc mắc không biết Google thật sự đánh trượt vì chữ ký DKIM không an toàn hay là vì SPF thất bại

    • Việc xác minh DKIM đã thất bại theo kết quả dkim=policy (weak key) đúng với RFC 8301
      Tức là đúng theo yêu cầu “trình xác minh không được coi chữ ký dùng khóa RSA dưới 1024 bit là chữ ký hợp lệ”

  • Con số 512 bit là lớn hay nhỏ còn tùy đó là mật mã đối xứng hay mật mã bất đối xứng
    Có thể xem mật mã bất đối xứng luôn yếu hơn mật mã đối xứng 8 lần
    DKIM dùng cơ chế bất đối xứng, nên DKIM 512 bit tương đương 64 bit theo chuẩn băm đối xứng và đã ở mức bị bẻ từ rất lâu rồi
    Ngay cả SHA-1 160 bit cũng đã bị xem là bị phá vỡ
    Nếu muốn DKIM có độ mạnh tương tự SHA-3 512 bit thì cần ít nhất 4096 bit, mà như vậy vẫn chưa bao gồm các kỹ thuật giảm thiểu tấn công phát lại của SHA-3

    • DKIM không phải là thuật toán mã hóa
      Đây là tiêu chuẩn chèn chữ ký vào header email và xác minh nó
      Đáng tiếc là DKIM chỉ hỗ trợ chữ ký rsa-sha1 và rsa-sha256: https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3
      Sẽ tốt hơn nếu DKIM được sửa đổi để cho phép Ed25519 hoặc các kiểu chữ ký tương tự
    • Mã hóa RSA yếu hơn mật mã đường cong elliptic 10 lần
      Ví dụ, ECC 224 bit gần tương đương RSA 2048 bit
      Cả hai đều là phương thức bất đối xứng
      Ngược lại, mật mã bất đối xứng dựa trên đường cong elliptic có độ mạnh gần với AES là mật mã đối xứng
      Tất nhiên, chúng vẫn dễ bị tổn thương trước máy tính lượng tử