Tôi phát hiện ra một lỗ hổng. Họ đi tìm luật sư

• Tác giả, một huấn luyện viên lặn đồng thời là kỹ sư nền tảng, đã phát hiện lỗ hổng bảo mật nghiêm trọng trong cổng thành viên của một công ty bảo hiểm lặn
• Cổng này sử dụng ID người dùng tuần tự và cùng một mật khẩu mặc định, khiến bất kỳ ai cũng có thể truy cập thông tin cá nhân của thành viên khác chỉ bằng một tổ hợp đơn giản
• Tác giả đã đồng thời báo cáo cho CSIRT Malta và tổ chức liên quan, nhưng thay vì cảm ơn, tổ chức này lại cảnh báo khả năng truy cứu trách nhiệm hình sự thông qua đại diện pháp lý
• Tác giả từ chối yêu cầu ký cam kết bảo mật (NDA) và đề xuất một tuyên bố sửa đổi chỉ xác nhận việc xóa dữ liệu, nhưng tổ chức tiếp tục đe dọa với lý do có thể bị kiện phỉ báng
• Vụ việc cho thấy tầm quan trọng của quy trình công bố lỗ hổng có trách nhiệm và thực tế rằng các đe dọa pháp lý đang làm suy yếu sự bảo vệ dành cho các nhà nghiên cứu

---

Phát hiện lỗ hổng

• Trong chuyến lặn tới đảo Cocos, Costa Rica, tác giả đã phát hiện lỗi cấu trúc trong cổng thành viên của công ty bảo hiểm lặn
  • Khi huấn luyện viên đăng ký học viên, hệ thống tạo một ID số tuần tự và mật khẩu mặc định không bị thay đổi
  • Nhiều người dùng không đổi mật khẩu nên có thể truy cập toàn bộ thông tin cá nhân của thành viên khác (tên, địa chỉ, ngày sinh, thông tin liên hệ, v.v.)
• Hoàn toàn không có các biện pháp bảo mật cơ bản như buộc đổi mật khẩu, giới hạn đăng nhập, MFA
• Một số tài khoản còn chứa thông tin của trẻ vị thành niên (14 tuổi)
• Tác giả chỉ xác minh vấn đề với mức truy cập tối thiểu rồi dừng ngay, và xóa vĩnh viễn toàn bộ dữ liệu đã thu thập

Xác minh và chứng minh

• Đã thử với Python requests, nhưng do cấu trúc phiên phức tạp nên tác giả chuyển sang tự động hóa trình duyệt bằng Selenium để xác minh
  • Chỉ cần nhập ID người dùng và mật khẩu mặc định là có thể đăng nhập
  • Script tự động hóa được công bố dưới dạng mã ví dụ không hoạt động, và mọi định danh thực tế đều đã bị xóa
• Ví dụ đầu ra bao gồm toàn bộ dữ liệu hồ sơ như tên, email, địa chỉ, ngày sinh
• Quá trình này cũng xác nhận rằng nhiều tài khoản của trẻ vị thành niên bị lộ theo cùng một cách

Quy trình công bố lỗ hổng

• Vào ngày 28 tháng 4 năm 2025, tác giả đã báo cáo chính thức lỗ hổng và đặt thời hạn gia hạn 30 ngày để khắc phục
• Tác giả gửi email đồng thời cho CSIRT Malta và tổ chức liên quan
  • Báo cáo gồm tóm tắt vấn đề, khả năng vi phạm GDPR, ảnh chụp màn hình và liên kết PoC đã mã hóa
  • Yêu cầu xác nhận đã tiếp nhận trong vòng 7 ngày, và khắc phục trong vòng 30 ngày
• Đây là quy trình tiêu chuẩn phù hợp với chính sách công bố lỗ hổng quốc gia (NCVDP)

Phản ứng của tổ chức

• Hai ngày sau, phản hồi đến không phải từ đội IT mà từ luật sư phụ trách bảo vệ dữ liệu (văn phòng pháp lý DPO)
  • Họ đề cập đến việc đặt lại mật khẩu và áp dụng 2FA, nhưng lại coi việc tác giả thông báo trước cho cơ quan nhà nước là vấn đề
  • Họ cảnh báo rằng hành vi của tác giả có thể cấu thành tội phạm theo luật hình sự Malta, và có thể phải chịu trách nhiệm pháp lý
• Tổ chức yêu cầu tác giả ký tuyên bố bảo mật, nộp bản sao hộ chiếu và ký ngay trong ngày
  • Tuyên bố có điều khoản “giữ bí mật nội dung của tuyên bố này”, về thực chất là một dạng NDA (thỏa thuận không tiết lộ)
• Sau đó là hàng loạt yêu cầu ký lặp đi lặp lại như “nhắc nhở thân thiện”, “thông báo khẩn cấp”

Sự từ chối và phản bác của nhà nghiên cứu

• Tác giả từ chối ký điều khoản bảo mật, và thay vào đó đề xuất một tuyên bố sửa đổi chỉ bao gồm xác nhận xóa dữ liệu
  • Tác giả nêu rõ việc thông báo cho CSIRT Malta là một phần của quy trình chính thức, và việc phân tích sau khi công bố là thông lệ tiêu chuẩn trong ngành bảo mật
• Tổ chức viện dẫn Điều 337E Bộ luật Hình sự (lạm dụng máy tính), cảnh báo rằng ngay cả hành vi diễn ra ở nước ngoài cũng có thể bị coi là tội phạm tại Malta
• Họ cũng thông báo rằng nếu tác giả nhắc đến tên tổ chức trên blog hoặc tại hội nghị thì có thể bị kiện phỉ báng và yêu cầu bồi thường thiệt hại
• Hiện lỗ hổng đã được khắc phục, và việc đặt lại mật khẩu mặc định cùng triển khai 2FA đang được tiến hành
• Tuy nhiên, vẫn chưa xác nhận được liệu các nạn nhân có được thông báo theo Điều 33 và 34 của GDPR hay không

Đổ trách nhiệm và vi phạm GDPR

• Tổ chức lập luận rằng “việc đổi mật khẩu là trách nhiệm của người dùng”
• Tuy nhiên, theo Điều 5(1)(f) và Điều 24(1) của GDPR, bên kiểm soát dữ liệu phải áp dụng các biện pháp kỹ thuật và quản trị phù hợp
• Việc dùng cùng một mật khẩu mặc định và ID tuần tự rõ ràng là biện pháp bảo mật không phù hợp

Mô thức lặp lại

• Hiện tượng “hiệu ứng làm nản lòng” (Chilling Effect), trong đó các nhà nghiên cứu bảo mật bị đe dọa pháp lý khi công bố lỗ hổng một cách có trách nhiệm, vẫn còn tồn tại
• Phản ứng bằng pháp lý chỉ càng làm xấu thêm danh tiếng, và vấn đề không nằm ở bản thân lỗ hổng mà ở cách tổ chức phản ứng

Quy trình ứng phó đúng đắn

• Tiếp nhận báo cáo và khắc phục
• Gửi lời cảm ơn tới nhà nghiên cứu
• Xây dựng chính sách CVD (Coordinated Vulnerability Disclosure)
• Thông báo cho người dùng bị ảnh hưởng, đặc biệt là bảo vệ trẻ vị thành niên
• Không dùng NDA để ép im lặng

Lời khuyên cho tổ chức và nhà nghiên cứu

• Tổ chức nên thiết lập quy trình công bố rõ ràng như security.txt và cảm ơn nhà nghiên cứu
• Nhà nghiên cứu nên tham gia CSIRT quốc gia, lưu giữ mọi hồ sơ, xóa dữ liệu rồi từ chối điều khoản bảo mật
• Chỉ thị NIS2 khuyến khích công bố lỗ hổng có trách nhiệm trong EU
• Ngay cả đến năm 2026, thực tế là một báo cáo lỗ hổng đơn giản vẫn có thể dẫn đến đe dọa pháp lý vẫn còn tồn tại

[GN⁺]

Ý kiến trên Hacker News

• Đã có những trường hợp khác thử kiểm tra sau khi phát hiện ID người dùng tăng đơn điệu rồi phải vào tù
  Ngay khoảnh khắc kiểm tra theo cách đó, bạn đã đối mặt với nguy cơ vi phạm CFAA
  Nếu đã biết ID tăng đơn điệu và mật khẩu mặc định được đặt sẵn, thì ngay lúc đó lẽ ra phải báo cáo lỗ hổng ngay
  Từ lúc chạy thử kiểm tra, có thể đã bị xem là vi phạm pháp luật
  Việc viết bài này lúc này về cơ bản cũng giống như tự thú, nên bạn cần thuê luật sư và tìm hiểu luật liên quan

• Tôi không có chuyên môn pháp lý, nhưng có ba suy nghĩ

  1. Nếu quy trình công bố hợp pháp quá khó khăn, thì rốt cuộc chỉ có thể biết lỗ hổng thông qua tội phạm
  2. Nếu ở các ngành khác, một kiến trúc sư phát hiện lỗi của tòa nhà mà lại bị kiện thì thật vô lý. Tuy nhiên, an ninh mạng khác ở chỗ chỉ riêng việc biết về lỗi cũng có thể làm tăng rủi ro
  3. Việc một người đi ngang qua ngẫu nhiên lại trở thành người kiểm toán là quá thiếu ổn định. Nếu một website yêu cầu PII (thông tin định danh cá nhân) của tôi, thì tôi phải có quyền yêu cầu thông tin đó được bảo mật
     Những nơi như công ty bảo hiểm nên bắt buộc phải trải qua kiểm toán an ninh mạng theo luật, bảo vệ hacker mũ trắng, và cho phép người dùng khởi kiện tập thể
     Khi đó các lỗ hổng cơ bản sẽ biến mất, và kỹ sư phần mềm sẽ trở nên có giá trị kinh tế hơn luật sư
  • Trong các ngành khác có chế độ kỹ sư chuyên nghiệp phải chịu trách nhiệm pháp lý
    Tôi tự hỏi liệu lĩnh vực CS trong thời đại AI có đi theo hướng này không
    Kỹ sư chuyên nghiệp phụ trách phê duyệt thiết kế và kiểm tra, giữ vai trò cốt lõi trong việc bảo đảm an toàn
    Vì thế họ có quyền hạn và trách nhiệm rất lớn, và thù lao cũng cao
  • Trong các ngành khác, người thiết kế có bảo hiểm và giấy phép hành nghề
    Tôi không muốn ngăn lập trình viên mới tham gia mã nguồn mở, nhưng tôi nghĩ những website xử lý lượng lớn dữ liệu cá nhân hoặc tiền bạc nên phải có kỹ sư phần mềm được chứng nhận ký duyệt
    Như vậy mới có đủ sức để ngăn các yêu cầu quá đáng từ ban lãnh đạo
    Tất nhiên, nhìn vào các trường hợp của Boeing hay Volkswagen thì đây cũng không phải giải pháp hoàn hảo
  • Ở một số quốc gia, ngay cả sự thật cũng có thể bị xem là phỉ báng
    Nghĩa là báo cáo với cơ quan chức năng và công khai với báo chí là hai chuyện hoàn toàn khác nhau
    Đặc biệt ở những nơi như Malta, nơi tội phạm có tổ chức và tham nhũng nghiêm trọng, người công khai những việc này thậm chí có thể gặp một “tai nạn ngoài ý muốn”

• Tôi dùng địa chỉ email khác nhau cho từng dịch vụ
  Khoảng 15 năm trước tôi bắt đầu nhận spam qua địa chỉ diversalertnetwork
  Tôi báo cho DAN về việc bị lộ dữ liệu thì chỉ nhận được email hướng dẫn đổi mật khẩu
  Tôi thấy may là mình không bị kiện hình sự

  • Hoặc đó là bị hack, hoặc công ty đã bán dữ liệu cho bên thứ ba
  • Tôi cũng có trải nghiệm tương tự. Tôi bắt đầu nhận spam qua địa chỉ email chỉ dùng cho hãng hàng không Bồ Đào Nha, và công ty không hề phản hồi

• Việc tác giả sợ nêu tên tổ chức cho thấy đe dọa pháp lý đã phát huy tác dụng

  • Hoặc trong cộng đồng lặn, chỉ riêng cách nói “một công ty bảo hiểm cho thợ lặn có trụ sở tại Malta” cũng đã đủ ám chỉ DAN Europe
  • Dựa trên các manh mối trong bài, trong số các công ty bảo hiểm lặn quốc tế đăng ký tại Malta thì gần như chỉ có DAN Europe, nên gần như chắc chắn là vậy
  • Tất nhiên, cũng không thể loại trừ khả năng anh ta đã bán thông tin thu được cho blackhat

• Về yêu cầu “hãy ký xác nhận đã xóa dữ liệu”, tôi thắc mắc tại sao lại ký
  Có vẻ công ty muốn kiểm soát hơn là hợp tác

  • Nhưng nếu buộc phía bên kia đồng ý với điều kiện của mình, thì có thể vô hiệu hóa chiến lược kiểm soát của họ và tạo ra tính ràng buộc pháp lý

• Mô thức các nhà nghiên cứu bảo mật báo cáo lỗ hổng rồi bị đe dọa pháp lý đã lặp lại suốt hàng chục năm
  Chính phủ và doanh nghiệp luôn nói về tầm quan trọng của an ninh mạng, nhưng trên thực tế lại thù địch với nhà nghiên cứu
  Cần có lập pháp để ngăn những phản ứng bất công như vậy
  Có thể xem các trường hợp liên quan tại liên kết này

• Tôi tự hỏi liệu đối tượng trong vụ này có phải là DAN Europe và công ty con của họ là IDA Insurance Limited không

  • Ở bình luận khác đã có người suy luận như vậy

• Ở Đức, việc chạy script kiểu này để truy cập dữ liệu của người khác là bất hợp pháp
  Nó giống như thấy cửa xe người khác mở rồi bước vào và nổ máy vậy
  Có thể tham khảo phân tích pháp lý liên quan trong bài này

  • Vậy thì luật cần phải thay đổi. Mức độ thờ ơ với bảo mật như thế này sẽ không bao giờ được cải thiện nếu không có người báo cáo thiện chí hoặc một vụ rò rỉ lớn
  • Tôi cũng đồng ý. Cần biết phải dừng ở đâu
    Chụp màn hình và báo cáo trong phạm vi sử dụng website bình thường thì không sao, nhưng thu thập dữ liệu bằng script Python là đã vượt ranh giới
    Nó giống như thấy cửa ngân hàng mở mà thay vì gọi cảnh sát lại bước vào trong
  • Chỉ mong tội phạm đừng khai thác lỗ hổng đó

• Năm ngoái tôi phát hiện lỗ hổng trong hệ thống bán vé của một sự kiện lớn
  Link vé gửi qua email là mã hóa base64 của số đơn hàng tuần tự
  Nghĩa là cũng có thể dễ dàng tải vé của người khác xuống
  Tôi đã gửi email cho ban tổ chức và công ty phát triển nhưng không nhận được phản hồi nào, và đến giờ nó vẫn còn mở nguyên như vậy
  Tôi định chờ xem đến kỳ sự kiện năm nay liệu họ có sửa hay không

• Nếu ID người dùng là tuần tự và mật khẩu mặc định giống nhau, thì lỗ hổng thực sự là “giả định rằng có tồn tại người phụ trách bảo mật”
  Ngày nay cái gọi là ‘công bố có trách nhiệm’ rốt cuộc chỉ là cho công ty thêm thời gian để thuê luật sư