Lỗi gõ sai DNS của MasterCard không bị phát hiện suốt gần 5 năm

 (krebsonsecurity.com)
1 điểm bởi GN⁺ 2025-01-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • MasterCard đã cấu hình sai tên máy chủ DNS của Akamai dùng để định tuyến một phần lưu lượng tới mastercard.com, nhập thành akam.ne thay vì akam.net, và lỗi gõ sai này đã tồn tại suốt gần 5 năm, từ ngày 30/6/2020 đến 14/1/2025
  • Nhà nghiên cứu bảo mật Philippe Caturegli nhận thấy akam.ne dưới tên miền cấp cao nhất quốc gia của Niger vẫn chưa được đăng ký, nên đã bỏ ra 300 USD và khoảng 3 tháng để sở hữu tên miền này nhằm ngăn khả năng bị lạm dụng
  • Khi bật máy chủ DNS cho akam.ne, ông nhận được hàng trăm nghìn truy vấn DNS mỗi ngày từ khắp thế giới, và trong số các tổ chức mắc cùng lỗi gõ sai, MasterCard là trường hợp lớn nhất
  • Nếu tên miền này bị lạm dụng, nó có thể dẫn đến việc nhận email bị chuyển nhầm, lấy được chứng chỉ SSL/TLS cho các website bị ảnh hưởng, và nhận thủ công một phần thông tin xác thực Windows
  • MasterCard cho biết “không có rủi ro đối với hệ thống” và đã sửa lỗi gõ sai, nhưng sau đó còn phát sinh tranh cãi về cách công khai khi có yêu cầu xóa bài đăng LinkedIn thông qua Bugcrowd

Lỗi gõ sai DNS bị bỏ sót gần 5 năm

  • MasterCard sử dụng 5 máy chủ DNS dùng chung của Akamai để định tuyến một phần lưu lượng trong mạng mastercard.com
  • Từ ngày 30/6/2020 đến 14/1/2025, một trong số đó đã bị cấu hình với tên sai
    • Tên máy chủ đúng phải kết thúc bằng akam.net
    • Cấu hình lỗi lại trỏ tới akam.ne
  • akam.ne là tên miền thuộc phạm vi quản lý của tên miền cấp cao nhất quốc gia Niger ở Tây Phi

Nhà nghiên cứu đã đăng ký tên miền trước

  • Philippe Caturegli, nhà sáng lập công ty tư vấn bảo mật Seralys, đã phát hiện ra lỗi gõ sai này
  • Caturegli cho rằng akam.ne có thể vẫn chưa được đăng ký và đã sở hữu tên miền này thông qua cơ quan đăng ký của Niger
    • Chi phí là 300 USD
    • Mất gần 3 tháng để hoàn tất đăng ký
  • Khi kích hoạt máy chủ DNS, ông nhận được hàng trăm nghìn truy vấn DNS mỗi ngày từ khắp thế giới
  • MasterCard không phải tổ chức duy nhất mắc lỗi gõ sai này, nhưng xét theo lượng truy vấn nhận được thì đây là tổ chức lớn nhất

Những rủi ro mà tên miền gõ sai có thể gây ra

  • Nếu Caturegli bật máy chủ email trên akam.ne, ông có thể nhận được email bị chuyển nhầm vốn hướng tới mastercard.com hoặc các tên miền bị ảnh hưởng khác
  • Nếu lạm dụng quyền truy cập, cũng có thể có khả năng lấy được chứng chỉ SSL/TLS để tiếp nhận và chuyển tiếp lưu lượng của các website bị ảnh hưởng
  • Cũng có khả năng nhận thủ công thông tin xác thực Microsoft Windows từ máy tính nhân viên
  • Caturegli không thử thực hiện các hành vi này và đã thông báo rằng ông có thể chuyển giao tên miền cho MasterCard
    • Trong thông báo còn đính kèm tác giả của Krebs on Security ở phần tham chiếu

Phản ứng của MasterCard và Bugcrowd

  • Vài giờ sau, MasterCard thừa nhận sai sót nhưng nói rằng không có rủi ro thực tế nào đối với an ninh vận hành
    • “Không có rủi ro đối với hệ thống”
    • “Lỗi gõ sai này đã được sửa”
  • Sau đó Caturegli nhận được tin nhắn qua Bugcrowd
    • Nội dung cho rằng việc Caturegli công khai trên LinkedIn sau khi sở hữu akam.ne là không phù hợp với thông lệ bảo mật có đạo đức
    • Tin nhắn cũng nói rằng MasterCard đã yêu cầu xóa bài đăng đó
  • Caturegli trả lời rằng ông chưa từng gửi báo cáo thông qua chương trình Bugcrowd và đã báo trực tiếp vấn đề cho MasterCard
  • Ông cho biết trước khi công khai, ông đã đăng ký các tên miền bị ảnh hưởng để ngăn chặn việc lạm dụng, và tự mình chi trả khoản phí đó

Tác động có thể bị khuếch đại bởi bộ nhớ đệm DNS

  • Thông thường các tổ chức có ít nhất 2 máy chủ DNS có thẩm quyền, nhưng những tổ chức có lượng truy vấn lớn sẽ dùng nhiều tên miền máy chủ DNS hơn để cân bằng tải
  • Vì MasterCard dùng 5 máy chủ DNS, có thể tưởng rằng nếu kẻ tấn công chỉ kiểm soát một máy chủ thì chỉ thấy khoảng 1/5 tổng số truy vấn DNS
  • Nhưng trên thực tế, người dùng Internet phụ thuộc vào các DNS resolver công khai như Cloudflare hoặc Google, nên tác động có thể lớn hơn
    • Chỉ cần một resolver truy vấn nhầm máy chủ tên sai và lưu kết quả vào bộ nhớ đệm
    • Nếu bản ghi DNS đặt TTL dài, chỉ dẫn sai có thể lan rộng thông qua các nhà cung cấp đám mây lớn
  • Caturegli cho rằng với TTL dài, phạm vi tái định tuyến lưu lượng có thể lớn hơn nhiều so với chỉ 1/5

Subdomain gặp vấn đề và dấu vết đăng ký trước đây

  • Ảnh chụp màn hình do Caturegli công bố cho thấy máy chủ DNS cấu hình sai có liên quan tới subdomain az.mastercard.com của MasterCard
  • Chưa rõ chính xác subdomain này được dùng như thế nào
  • Theo quy ước đặt tên, đây có vẻ là tên miền liên quan đến máy chủ production trên đám mây Microsoft Azure, và Caturegli cho biết các tên miền này phân giải tới địa chỉ Internet của Microsoft
  • akam.ne từng được đăng ký trong quá khứ
    • Tháng 12/2016, một người dùng với email um-i-delo@yandex.ru đã đăng ký tên miền này
    • Yandex hiển thị tài khoản này thuộc về “Ivan I.” ở Moskva
    • Theo lịch sử DNS thủ công của DomainTools.com, từ năm 2016 đến 2018 tên miền này được kết nối tới một máy chủ Internet ở Đức và hết hạn vào năm 2018
  • Một cựu nhân viên Cloudflare đã đăng liên kết tới một báo cáo về trường hợp tương tự trong phần bình luận bài đăng LinkedIn của Caturegli
    • Đây là trường hợp tên miền gõ sai mà một số tổ chức có thể đã nhập nhầm máy chủ DNS AWS awsdns-06.net thành awsdns-06.ne
    • Theo DomainTools, tên miền gõ sai này cũng được đăng ký bởi một người dùng Yandex và được lưu trữ tại cùng ISP Đức là Team Internet

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-23
Các ý kiến trên Hacker News

  • Nameserver có thể đăng ký công khai như trường hợp này chỉ là một phân nhóm tương đối hiếm của vấn đề dangling DNS; phổ biến hơn là trường hợp domain được ánh xạ trực tiếp tới địa chỉ IP của nhà cung cấp cloud mà kẻ tấn công có thể giành được
    Dịch vụ cloud có phạm vi rất rộng và thường thiếu khả năng quan sát toàn cục, nên các doanh nghiệp dùng cloud rất có khả năng có lỗ hổng kiểu này ở đâu đó trong các subdomain
    Các chương trình bug bounty thường loại trừ hàng loạt “subdomain takeover”, nhưng khi phát hiện thì có thể dễ dàng bị khai thác, và cũng đã có dữ liệu nội bộ lẫn công khai chứa thông tin nhạy cảm bị rò rỉ do những lỗi cấu hình như vậy
    Môi trường công bố lỗ hổng hiện nay khiến doanh nghiệp quá dễ né tránh việc thừa nhận lỗ hổng thật sự, còn nhà nghiên cứu thiện chí thì vì ràng buộc đạo đức và pháp lý nên khó đưa ra mức bằng chứng mà nhà cung cấp yêu cầu
    Nguy cơ rằng những lỗ hổng này thực sự có thể dễ dàng dùng để cấp chứng chỉ TLS cũng đang bị đánh giá thấp
    [1] https://dl.acm.org/doi/pdf/10.1145/2976749.2978387
    [2] https://escholarship.org/content/qt9r59r676/qt9r59r676.pdf
    [3] https://pauley.me/post/2022/cloud-squatting/
    [4] https://arxiv.org/pdf/2204.05122

    • Không chỉ IP, còn có một nhóm vấn đề rất lớn là “các bản ghi DNS trỏ tới tài nguyên cloud dùng chung mà tổ chức không còn kiểm soát”, và công ty càng lớn thì vấn đề càng lan rộng
      Ví dụ có CNAME trỏ tới bucket S3 đã được giải phóng, instance Azure Website/WebApp, bản ghi A trỏ tới IP không co giãn, nameserver Route53 không còn thuộc tài khoản AWS của tổ chức, tài khoản Heroku/Shopify/GitHub Pages đã bị xóa hoặc vô hiệu hóa, bản ghi MX trỏ tới domain của nhà cung cấp email giao dịch đã phá sản, v.v.
      Nguyên nhân là hạ tầng được tạo bởi những người không hiểu rõ do IT bị phân tán; khi tháo dỡ thì quên DNS; có nhiều công ty con, thương hiệu và tổ chức theo khu vực khiến việc phát hiện và cưỡng chế chính sách khó khăn; có nhiều website và app theo từng quốc gia; và việc dùng nhà cung cấp bên ngoài mà không báo cho đội bảo mật cứ tích tụ dần
      Tôi làm Field CTO tại một công ty an ninh mạng Israel trong lĩnh vực này; ngay hôm qua tôi đã nói chuyện với một công ty linh kiện máy tính lớn về khoảng 12 trang cờ bạc Indonesia đang “vận hành” bằng domain, PageRank và liên kết của họ, và những cuộc trao đổi như vậy lặp lại hằng tuần
    • Việc bug bounty coi mọi “subdomain takeover” là không hợp lệ là một cách xử lý quá gom chung; cần phân loại theo mức độ dễ dàng giành được domain
      “Nếu bằng cách nào đó chiếm được google.com thì có thể xâm phạm người dùng Google” không phải là một lỗ hổng bảo mật hợp lệ, nhưng nếu việc chiếm domain chưa đăng ký hoặc đã hết hạn như ở đây dẫn tới xâm phạm thì nên được coi là lỗ hổng hợp lệ
    • Việc công bố bug bounty có thể hiệu quả hơn nếu cũng được tự động báo cáo cho cơ quan chính phủ như FCC và email của công ty liên quan được CC
      Nếu công ty muốn bác bỏ báo cáo, họ phải đưa ra bằng chứng rõ ràng; nếu việc khai thác nêu trong báo cáo được chứng minh, hoặc công ty thay đổi khiến các bước tái hiện trong báo cáo không còn hoạt động, thì có thể buộc trả thưởng hoặc bị phạt
    • Ở một sàn giao dịch tiền mã hóa nọ, họ quản lý whitelist các địa chỉ IP có thể truy cập load balancer nhanh hơn mà không có kiểm soát ở tầng ứng dụng
      Người ta đã cấp phát cực nhiều IP cloud và lặp đi lặp lại để tìm các IP cũ, nhờ đó có được dung lượng lớn hơn nhiều so với ban đầu và gửi request với giới hạn tốc độ cao hơn
      Giờ có lẽ cách này không còn dùng được nữa, và hiện nay ai cũng biết rồi

  • Phần về Bugcrowd trong câu chuyện này khá bất ngờ
    Ảnh chụp email trông như đến từ “Platform Behavior Standards Team”; nếu đúng vậy thì hoặc Bugcrowd đã diễn giải tiêu chuẩn nền tảng quá rộng để cố điều chỉnh cả hành vi bên ngoài nền tảng, hoặc Mastercard đã mạo danh nhân viên chính thức của Bugcrowd
    Cả hai khả năng đều khá khó chấp nhận
    [1] https://www.bugcrowd.com/resources/hacker-resources/platform...

    • Có cách hiểu rằng các nền tảng bug bounty tồn tại không phải để khuyến khích responsible disclosure, mà để chiếm giữ và ngăn chặn nó
      Nếu người thường đưa ra lập luận đó thấy việc này, có lẽ họ sẽ giải thích rõ hơn được
    • Cách viết cũng tệ một cách nghiêm trọng
      Nó được viết như thể đã kết luận người nhận đã làm sai, và các lựa chọn chỉ là tuân theo hoặc yêu cầu giải thích thêm vì sao việc đó sai
      Không có cơ hội để giải thích rằng bản thân mình không làm sai
    • Theo kinh nghiệm của tôi, BugCrowd làm mọi thứ để trì hoãn và nhấn chìm việc báo cáo thực sự đến được công ty
      Về phía công ty, điều đó giúp giảm chi phí trả bounty và chi phí rà soát nội bộ, đồng thời cũng có được khả năng phủ nhận hợp lý về mặt pháp lý
    • Chắc ở đây cũng có nhân viên Bugcrowd, nên có lẽ họ có thể giải thích email đó

  • Kiểu phản hồi “không có mối đe dọa thực tế” có thể khiến lần sau các nhà nghiên cứu bảo mật xâm nhập sâu hơn để thu thập thêm bằng chứng về tác động ở công ty này hoặc công ty khác
    Nếu muốn người phát ngôn công ty có thể nói “không có vấn đề gì”, thì dù tác động bị giảm nhẹ, công ty vẫn cần trả thưởng đủ để nhà nghiên cứu chấp nhận
    Dù có vẻ nhà nghiên cứu đã hành xử đúng đắn, việc gây áp lực lên họ để dập tin tức khiến tôi tự hỏi liệu công ty thẻ tín dụng có lý do để làm vậy, hay đó là nhận thức sai lệch về công việc của bộ phận PR, hoặc người chịu trách nhiệm cuối cùng cho sai sót an ninh thông tin đã dùng tài nguyên công ty để tránh bị bẽ mặt trong nhiệm kỳ của mình

    • Có lý do đấy
      Họ muốn khiến các nhà nghiên cứu bảo mật sợ công bố kết quả

  • Vài năm trước ở Ukraine, toàn bộ hoặc phần lớn giao dịch trực tuyến phải được xác minh bằng một dịch vụ tên là masterpass, trông giống kiểu 3DS của Mastercard
    Nhưng như thường thấy trên web doanh nghiệp, chứng chỉ SSL hết hạn, và toàn bộ hoặc phần lớn giao dịch trực tuyến bằng một số loại thẻ MasterCard từ khoảnh khắc đó bị chặn hoàn toàn
    Mastercard đã không gia hạn chứng chỉ trong hơn 1 năm; dù tôi là khách hàng hay bộ phận IT của ngân hàng có liên hệ thế nào cũng vô ích, rồi sau đó họ âm thầm đóng dịch vụ
    Xem xét thì thấy dịch vụ được viết trên nền Microsoft (IIS), chuỗi chứng chỉ dài bất thường với các chứng chỉ trung gian chưa từng nghe tên, và được hosting ở một quốc gia thế giới thứ ba khá xa Ukraine

    • masterpass là phiên bản 3DS của Mastercard, được dùng trên toàn cầu khi giao dịch có vẻ đáng ngờ
      Có vẻ từ góc nhìn của Mastercard, giao dịch của quốc gia đó mặc định bị coi là đáng ngờ dù tất cả đều là giao dịch giữa các chủ thể trong nước
      Ở Mỹ tôi chưa từng thấy nó hết hạn, và tôi không biết họ xử lý lưu lượng theo từng quốc gia thế nào, nhưng nghe như lưu lượng đã bị định tuyến đến một nơi khác chứ không phải Mastercard

  • Điều khiến tôi thấy khó chịu là akam.ne được đăng ký năm 2016 bởi “Ivan I.” ở Moscow dùng email Yandex, được trỏ tới máy chủ ở Đức trong giai đoạn 2016–2018 rồi hết hạn
    Đặc biệt đáng ngờ là một tên miền typo có vẻ nhắm vào các tổ chức nhập sai máy chủ DNS AWS awsdns-06.net thành awsdns-06.ne cũng được đăng ký bằng tài khoản Yandex và được hosting tại cùng ISP ở Đức là Team Internet (AS61969)

    • “Ivan I” rất có thể ám chỉ Ivan Ivanov, một tên giả phổ biến kiểu Nga, tương tự “John Smith” trong tiếng Anh

  • Hai phát biểu “nếu quyền truy cập bị lạm dụng thì có thể đã lấy được chứng chỉ SSL/TLS để nhận và chuyển tiếp lưu lượng của các website bị ảnh hưởng” và “hệ thống của chúng tôi không gặp rủi ro” thì phải có một câu sai
    Cả hai bên đều có động cơ để nói dối hoặc phóng đại

    • Một bên có động cơ nói dối/phóng đại trị giá hàng chục tỷ đô la, còn bên kia dành cả ngày nghĩ về kịch bản xấu nhất của kẻ tấn công tinh vi
      Nếu là máy chủ CS:GO thì đòn tấn công tệ nhất của kẻ tấn công tinh vi có thể là phóng đại, nhưng khi nói về một trong những công ty xử lý thanh toán lớn nhất thế giới thì không phải phóng đại
    • Chỉ cần biết chút ít về cách chứng chỉ được cấp phát thì sẽ hiểu nhà nghiên cứu đúng và MasterCard đang nói nhảm
      Điều tra 10 phút cũng sẽ đi đến cùng kết luận
    • Nếu không có ảnh hưởng, họ chỉ cần cho phép công bố toàn bộ danh sách truy vấn DNS mà anh ta đã thu thập
      Lý do không làm vậy là vì danh sách đó sẽ cung cấp manh mối về hạ tầng cho tác nhân độc hại
      MasterCard hoặc đang nói dối, hoặc vừa thiếu hiểu biết vừa kém năng lực
    • Điểm cốt lõi phụ thuộc rất nhiều vào việc az.mastercard.com thực sự là gì và làm gì
      Nói rằng có thể nhận email gửi tới x@mastercard.com nghe không đúng; đây chỉ là một subdomain chưa rõ mục đích
      TLS có lẽ là khả thi, nhưng mức rủi ro phụ thuộc vào domain đó là gì và có lẽ không ảnh hưởng trực tiếp tới người dùng truy cập mastercard.com
    • Nếu nói về chứng chỉ SSL/TLS thì thứ tôi nghĩ tới đầu tiên là nhà cung cấp chứng chỉ dựa trên ACME
      Chỉ cần có quyền kiểm soát DNS của domain là đủ, và có thể dùng bản ghi TXT hoặc gửi yêu cầu tới máy chủ HTTP do mình kiểm soát

  • Đây rõ ràng là sai sót lớn của Mastercard, nhưng bản thân việc để tồn tại các domain chỉ khác TLD gốc một ký tự cũng có vẻ là một sai lầm
    Ví dụ như .com và .co, .net và .ne; đó là cấu trúc tự chuốc lấy rắc rối
    Nếu không có những domain như vậy thì chúng đã không thể được đăng ký, và các yêu cầu DNS bị nhập sai đơn giản là sẽ không đi đâu cả

    • Không hẳn vậy
      Lỗi gõ có thể xảy ra ở bất kỳ đâu trong tên chứ không chỉ ở TLD, và kể cả không có lỗi gõ, vẫn có thể lấy lưu lượng từ đủ loại lỗi máy tính bằng bitsquatting, tức đăng ký domain chỉ khác 1 bit so với tên website phổ biến
      Có cả bài nghiên cứu kèm ví dụ
      [1] https://en.wikipedia.org/wiki/Bitsquatting
      [2] https://www.securitee.org/files/bitsquatting_www2013.pdf
    • Tôi từng nghĩ các tập đoàn lớn sẽ xử lý vấn đề này bằng Markmonitor
      Về cơ bản là đăng ký kèm càng nhiều domain typo có khoảng cách chỉnh sửa 1 càng tốt
      Theo Wikipedia, Akamai là một trong các khách hàng của Markmonitor, nên khá bất ngờ khi domain này chưa được đăng ký sẵn
    • Vấn đề là định xử lý thế nào với mã ISO 3166-2 của Niger và Colombia
    • Tôi không thấy điều này khác gì việc tồn tại số điện thoại chỉ khác đúng một chữ số so với một số điện thoại nhạy cảm
    • Các TLD ISO 3166-1 alpha-2 rõ ràng hữu ích, nhưng do đặc tính của không gian địa chỉ nên dễ phát sinh nhiều lỗi gõ lệch một ký tự
      Domain không phải mã quốc gia cũng có thể trùng với dạng thiếu một chữ cái của TLD mã quốc gia, nên không khác biệt lớn
      Tuy vậy, một công cụ kiểm tra DNS tốt có thể bắt được các lỗi cấu hình như thế này
      Chúng sẽ lộ ra qua việc một trong các nameserver đã đăng ký không phân giải được, hoặc các nameserver không trả về cùng số sê-ri zone hay cùng phản hồi thực tế
      Với .is, để đăng ký domain phải cung cấp 2 nameserver hoạt động bình thường, nhưng .com giờ không còn khắt khe như vậy

  • Tên miền đó lẽ ra nên được chuyển cho akamai
    Các yêu cầu khác cũng đang được gửi tới cùng địa chỉ, và akamai nên xử lý một cách có trách nhiệm

  • “Chúng tôi tự điều tra chính mình và thấy mình không có lỗi” là phản ứng điển hình
    Mastercard là công ty niêm yết trị giá hàng tỷ đô la, có ít nhất 3,4 tỷ thẻ mang thương hiệu trên toàn thế giới và đã xử lý 44,3 tỷ giao dịch tín dụng, ghi nợ và tiền mặt trên toàn cầu trong quý 3/2024
    Thừa nhận sai lầm có thể gây thiệt hại ngắn hạn trên thị trường, nhưng văn hóa phủ nhận sẽ hủy hoại văn hóa công ty
    Chẳng khác gì ClownStrike, và đã đến lúc các mạng lưới tín dụng/ghi nợ mang tính bóc lột, ký sinh phải đối mặt với hỗn loạn

  • Những câu kiểu “lỗi chính tả đã được sửa và hệ thống không gặp rủi ro” lúc nào cũng giống nhau, và những tuyên bố như vậy thật sự khiến người ta bực mình

    • Tính toán của họ chắc là thế này
      Nếu thừa nhận vấn đề thì giá cổ phiếu có thể bốc hơi hàng triệu đô la, còn nếu phủ nhận thì chỉ có mấy tay lập dị than vãn thêm chút nữa
      Không có bằng chứng bị xâm phạm thì khó ép buộc, còn nếu có bằng chứng bị xâm phạm thì sẽ phải vào tù
    • Ý thực sự gần hơn với “chúng tôi đã nói chuyện với một nhân viên chẳng biết gì ở bộ phận IT, người này có động cơ cá nhân để không tìm ra việc bị lộ, và không nghĩ ra được cách khai thác trong vòng 15 giây”
      Người hiểu biết hiếm khi cảm thấy đủ chắc chắn để khẳng định rằng một thứ gì đó không thể bị khai thác