Lỗi đặt lại mật khẩu GitLab khiến hơn 5.300 máy chủ gặp rủi ro

 (scmagazine.com)
1 điểm bởi GN⁺ 2024-01-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • Lỗ hổng CVE-2023-7028 của GitLab vẫn còn tồn tại trên 5.379 máy chủ trên toàn thế giới khoảng 2 tuần sau khi bản vá được công bố, có thể dẫn đến việc chiếm đoạt từ xa tài khoản nhà phát triển
  • Vấn đề nằm ở luồng đặt lại mật khẩu của hệ thống đăng nhập, nơi kẻ tấn công có thể khiến liên kết đặt lại được gửi đến địa chỉ email chưa được xác minh của mình mà không cần tương tác từ nạn nhân
  • GitLab đã công bố lỗ hổng CVSS 10 điểm vào ngày 11/1/2024 và cung cấp bản cập nhật bảo mật cho các phiên bản 16.5.6, 16.6.4, 16.7.2 cùng các bản backport 16.1.6~16.4.5
  • Shadowserver Foundation đã phát hiện 5.379 instance dễ bị tấn công vào ngày 23/1, trong đó Mỹ có 964 và Đức có 730 là nhiều nhất; đến ngày 24/1 con số này giảm còn 4.652
  • Quản trị viên vận hành GitLab Community Edition và Enterprise Edition tự quản lý cần kiểm tra trong log các yêu cầu đặt lại có dạng mảng nhiều email, đồng thời bật 2FA để giảm nguy cơ bị chiếm đoạt tài khoản

Mức độ nguy hiểm của CVE-2023-7028

  • CVE-2023-7028 là lỗ hổng trong hệ thống đăng nhập GitLab, có thể dẫn đến chiếm đoạt tài khoản từ xa trên các máy chủ GitLab chưa được vá
  • GitLab lần đầu công bố và vá lỗ hổng này vào ngày 11/1/2024
  • Điểm CVSS của lỗ hổng là 10, mức nghiêm trọng cao nhất
  • Kẻ tấn công có thể dùng một yêu cầu HTTP được tạo đặc biệt để gửi email đặt lại mật khẩu tới địa chỉ email chưa được xác minh của mình mà không cần tương tác từ nạn nhân
  • Một nhà nghiên cứu thử nghiệm trên GitLab Community Edition 16.6.1 đã đánh giá trên AttackerKB rằng CVE-2023-7028 “rất hiệu quả và dễ khai thác”

Các phiên bản bị ảnh hưởng và bản vá

  • GitLab cung cấp bản cập nhật bảo mật cho các phiên bản sau
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • Bản vá cũng được backport cho các phiên bản sau
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Kết quả phát hiện của Shadowserver

  • Shadowserver Foundation đã phát hiện 5.379 instance GitLab dễ bị tấn công trên toàn thế giới vào ngày 23/1, tức khoảng 2 tuần sau khi bản vá được công bố
  • Theo quốc gia, Mỹ và Đức có nhiều instance dễ bị tấn công nhất
    • Mỹ: 964
    • Đức: 730
  • Đến ngày 24/1, số instance dễ bị tấn công trên dashboard của Shadowserver đã giảm xuống còn 4.652
  • Phía Shadowserver xác nhận rằng dù xu hướng giảm là tín hiệu tích cực, vẫn cần thêm thời gian để xác định đây có phải xu hướng thực sự hay chỉ là biến động tạm thời trong quá trình quét

Cách kiểm tra dấu hiệu bị xâm phạm

  • Khách hàng dùng GitLab Community Edition và GitLab Enterprise Edition tự quản lý cần kiểm tra log để tìm dấu vết khai thác CVE-2023-7028
  • Các log và điều kiện cần kiểm tra như sau
    • gitlab-rails/production_json.log: trong các yêu cầu HTTP vào đường dẫn /users/password, nếu params.value.email là một mảng JSON chứa nhiều địa chỉ email
    • gitlabs-rails/audit_json.log: nếu meta.caller.id là PasswordsController#create và target_Details là một mảng JSON chứa nhiều địa chỉ email

Ảnh hưởng với GitLab.com, GitLab Dedicated và 2FA

  • GitLab cho biết họ chưa phát hiện trường hợp lỗi này bị khai thác trên các instance GitLab.com hoặc GitLab Dedicated
  • Khách hàng được khuyến nghị bật 2FA
  • 2FA có thể ngăn việc chiếm đoạt tài khoản thông qua CVE-2023-7028, nhưng trên các instance chưa được vá, kẻ tấn công vẫn có thể đặt lại mật khẩu để khóa người dùng khỏi tài khoản của họ

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-29
Các ý kiến trên Hacker News

  • Tôi thấy chức năng liên kết địa chỉ email với tài khoản trong các web app dựa trên tài khoản thật sự đáng sợ
    Tôi không biết lịch sử của lỗi này, nhưng đây là khu vực mà các penetration tester sẽ đụng tới ngay, và là một dạng lỗi cũ có thể truy ngược về tận các lỗ hổng hồi đầu thập niên 2000, khi người ta đánh lừa các triển khai Unix MTA tiêu chuẩn để gửi email đặt lại mật khẩu tới nhiều địa chỉ
    Có vẻ như ở GitLab, các web framework nhiều tính năng đã làm sống lại bề mặt tấn công này; độc giả HN phổ thông nào thấy hứng thú thì nên kiểm tra kỹ chức năng đặt lại mật khẩu, đặc biệt là logic liên kết email
    Theo tôi biết đội bảo mật GitLab khá giỏi, vậy mà vẫn xuất hiện lỗi kiểu này, cho thấy việc tránh dòng lỗi này khó đến mức nào

    • Nhìn vào hành vi được giải thích trong bình luận khác thì lỗi này có vẻ rất dễ tránh
      Nếu dùng ngôn ngữ kiểu tĩnh thì khó mà phát sinh trừ khi cố tình làm như vậy, và khi review code nó cũng sẽ quá lộ đến mức đồng nghiệp có thể nghi ngờ liệu có phải đang cố cài backdoor hay không
    • Khó có thể nói đội bảo mật GitLab là giỏi
      Chức năng liên kết địa chỉ email phụ mới được thêm gần đây chứ không phải chức năng vốn có từ đầu, nên có vẻ họ đã chọn đường tắt mà không kiểm thử lạm dụng đúng mức cho một tính năng mới liên quan đến bảo mật tài khoản
      Hơn nữa hình như còn có một CVE CVSS 9.6 trong đó chức năng tích hợp cho phép chạy lệnh với quyền của người dùng khác
      Nhìn từ bên ngoài thì tốc độ ra mắt tính năng dường như đang vượt quá tốc độ có thể kiểm thử an toàn, có lẽ vì khó kiếm tiền
      Xét từ góc độ kinh doanh thì cũng có phần dễ hiểu, nhưng nếu cốt lõi của một giải pháp Git tự host về thực chất là quản lý tài khoản, thì những vấn đề bảo mật như vậy cũng có thể làm sụp đổ cả doanh nghiệp
    • Góc nhìn kỳ lạ thật
      Nếu không liên kết với email thì phải liên kết với cái gì? Tôi đã vận hành một trang có lượng người dùng lớn hơn 20 năm; ban đầu dùng tên người dùng và đó là thảm họa
      Ai cũng biết tên người dùng của nhau, nên rất dễ brute-force mật khẩu hoặc thử đặt lại mật khẩu
      Vấn đề không nằm ở việc dùng email, mà ở việc làm logic đăng nhập và khôi phục mật khẩu quá phức tạp, lạm dụng trừu tượng hóa, over-engineering, rồi đẩy code vào các vùng nhạy cảm về bảo mật mà không kiểm tra đúng mức
      Cũng nên xem lại lịch sử bảo mật của GitLab. Mỗi năm có nhiều exploit nghiêm trọng khiến các bản triển khai GitLab phải nâng cấp khẩn cấp, và xét về bảo mật thì GitLab là sản phẩm tệ nhất trong số những thứ tôi từng dùng
    • Mỗi lần nhận được email đặt lại mật khẩu lạ, tôi lại lo có ai đó đã âm thầm thêm một địa chỉ email khôi phục nằm ngoài quyền kiểm soát của tôi để chiếm tài khoản của tôi hay không
      Chuyện đó chưa từng xảy ra với tôi, nhưng như trường hợp này cho thấy, đáng tiếc là nó hoàn toàn có thể xảy ra
    • Exploit này hoạt động như thế nào? Nếu có link bài viết tóm tắt thì tôi muốn xem

  • Nếu muốn xem phần trong codebase Rails đã dẫn tới exploit này, commit sửa nằm ở đây
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • Cái này trông giống refactor tiếp theo hơn là bản sửa thực sự
      Có vẻ bản sửa là ở đây: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      Từ recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? đổi thành recoverable.send_reset_password_instructions if recoverable&.persisted?
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail ư, vậy đây là một tính năng à?
      Nhưng ngay cả trong phiên bản đã sửa, tên RecoverableByAnyEmail vẫn được dùng. Mọi người không đọc phần code xung quanh thứ mình đang sửa sao?
    • Với tư cách người không rành Ruby, có thể chỉ ra lỗi nằm ở đâu không?

  • Chúng tôi cũng bị tấn công kiểu này, và còn thấy nó được dùng cùng một “tính năng” thứ hai làm tăng mức độ lộ lọt
    Về cơ bản, để tấn công kiểu này cần biết email của người dùng muốn đặt lại, nhưng có một địa chỉ email ẩn gắn với ID người dùng GitLab. ID này là số tăng dần từ 1
    ID 1 hoặc 2 nhiều khả năng là quản trị viên nên là mục tiêu tốt, và email có dạng như 1-user@mail.noreply..
    Rất tệ và trông có vẻ đã được tự động hóa. Ở đây 2FA đã cứu chúng tôi

  • Đặt lại mật khẩu qua email là cơn ác mộng bảo mật ngay cả khi được triển khai đúng
    Tệ hơn là đa số dịch vụ không cho tắt, và cách né thường chỉ là Enterprise SSO
    Một số dịch vụ cho đặt số điện thoại để nhận token SMS, nhưng tôi chưa thấy kiểu nào yêu cầu cả email lẫn token SMS

    • Tôi tò mò bạn xem nó là cơn ác mộng bảo mật ở điểm nào

  • Tôi nhớ tới lỗi cho phép brute-force tài khoản nếu đưa một mảng mật khẩu vào form đăng nhập
    Trớ trêu là đó là giao diện web thô sơ của một thiết bị spam, và tôi không biết đó là cố ý hay là code do một người mới học PHP viết
    Một người dùng có ký tự đặc biệt trong mật khẩu, vốn hiếm vào thời đó, đã phát hiện ra chuyện đó

    • Ruby on Rails khi nhận một mảng làm tham số cho .where(...) của ORM thì xử lý các giá trị trong mảng bằng điều kiện OR
      Vì vậy nếu code kiểu như User.where(name: name, password: password) thì tôi thấy chuyện như vậy hoàn toàn có thể xảy ra

  • Đây là một lời nhắc tốt rằng các dịch vụ nội bộ như GitLab nên được đặt sau VPN, nơi chỉ người dùng đáng tin cậy mới có thể truy cập

    • Tôi thật sự không hiểu vì sao lại đưa quản lý phiên bản nội bộ và CI/CD lên Internet công khai
      VPN tồn tại chính là để dùng cho những việc như thế này
    • Đúng vậy, chúng tôi cũng đã thoát nhờ vậy, và còn có vài lớp bảo vệ khác
      Tôi làm ở một nhà mạng quốc doanh lớn, và đội phụ trách mạng thật sự rất giỏi. Họ giữ cho đội phụ trách máy chủ không vượt quá giới hạn
      Chúng tôi có để lộ GitLab ở một mức độ nào đó cho một số dự án bên ngoài và consultant, nhưng vẫn không thể truy cập tự do từ Internet
      Người dùng cũng được quản lý trong AD nên bản thân không có kết nối SMTP để đặt lại mật khẩu
      Tuy nhiên cần siết chặt hơn việc bắt buộc 2FA. Hiện tại chúng tôi đang để từng dự án tự đặt quy tắc 2FA của mình

  • Thành thật mà nói, tôi sẽ không đặt bất kỳ máy chủ nội bộ nào trên Internet công khai
    Tốt hơn là chỉ cho truy cập qua VPN để có tuyến phòng thủ thứ hai

    • Đặc biệt những thứ như GitLab có thể hưởng lợi rất nhiều từ các tích hợp bên ngoài cần gọi GitLab API
      Có thể đưa chính xác các request đó vào danh sách cho phép, nhưng việc này có thể khá phiền phức
    • GitLab là lựa chọn tôi thích nhất để vận hành một code forge: git.drk.sc
      Nếu là môi trường bảo mật cao thì tôi đồng ý dùng chiến thuật phòng thủ hơn, nhưng tôi cho rằng phần mềm phải được thiết kế để chịu được cả web công khai
    • Đúng vậy, đặc biệt nếu công ty dùng GitLab tự host thì luôn nên đặt sau VPN của công ty

  • Tự động hóa cập nhật GitLab thật sự rất dễ
    Chỉ xét một cách thôi, nếu dùng GitLab bằng Docker+Compose thì rất ổn định, và có thể dùng công cụ như Watchtower để cập nhật hằng ngày
    Tôi có hai máy chủ GitLab vận hành theo cách này hơn 7 năm rồi mà không gặp vấn đề gì
    Nhìn xung quanh thì thấy quá nhiều GitLab cũ kỹ, không biết các quản trị viên rốt cuộc đang làm gì

  • Mong là chúng ta ngừng giả vờ Ruby/Rails là lựa chọn tốt cho phần mềm cần an toàn
    Tôi hiểu GitLab đã thành ra như vậy rồi thì phải chấp nhận, nhưng từ nay hãy ngừng giả vờ rằng những ngôn ngữ và framework ưu tiên sự “thông minh” cùng luồng điều khiển ẩn tốt hơn các lựa chọn nhàm chán hơn
    Nếu nghe có vẻ tôi đang bực quá mức, đó là vì tôi phải xử lý các codebase Ruby đang chạy thực tế
    Vì có ai đó nghĩ rằng 17 lớp trừu tượng sẽ làm cho mã cực kỳ dễ mở rộng, nên tôi thấy đủ nhiều kịch bản đang chờ bị khai thác bởi các vấn đề tương tự

    • Tôi nghĩ nên tránh các ngôn ngữ hoặc framework cho phép caller chỉ định một tham số là chuỗi hoặc mảng chuỗi
      Chi phí của riêng lỗi này có khả năng lớn hơn toàn bộ giá trị thu được từ việc dùng tính năng đó

  • Đây là một lời nhắc nữa rằng hãy luôn dùng SSO và 2FA