Lập trình viên Đức vạch trần thông tin xác thực được hardcode trong ứng dụng bị kết tội vì cáo buộc 'hack'

Luật pháp Đức khiến nghiên cứu bảo mật trở thành một công việc nguy hiểm

• Một tòa án Đức đã kết tội một lập trình viên với cáo buộc "hack".
• Lập trình viên này được giao điều tra phần mềm tạo ra quá nhiều thông báo nhật ký và phát hiện phần mềm đó đang thực hiện kết nối MySQL tới máy chủ cơ sở dữ liệu của nhà cung cấp.
• Khi kiểm tra kết nối MySQL, anh phát hiện cơ sở dữ liệu không chỉ chứa dữ liệu của khách hàng đó mà còn chứa dữ liệu của toàn bộ khách hàng của nhà cung cấp. Anh lập tức thông báo cho nhà cung cấp, nhưng phía nhà cung cấp vừa vá lỗ hổng vừa đệ đơn kiện.

Phán quyết của tòa án

• Tòa án đã có nhiều tranh luận đáng kể về việc liệu thông tin xác thực cơ sở dữ liệu được hardcode trong ứng dụng (dường như ở dạng văn bản thuần, thậm chí không cần decompile) có phải là biện pháp bảo vệ đủ để biện minh cho cáo buộc hack hay không.
• Phán quyết của tòa nêu rõ rằng vì có mật khẩu nên một cơ chế bảo vệ đã bị vượt qua, và điều này cấu thành hành vi hack.
• Phán quyết lần này dẫn đến hệ quả rằng, dưới luật pháp Đức, chỉ riêng sự tồn tại của một "biện pháp bảo vệ" dù khiếm khuyết đến đâu cũng có thể biến hoạt động nghiên cứu bảo mật thành hành vi hack mang tính hình sự.

Phản ứng của cộng đồng

• Trong cộng đồng, mọi người đã chia sẻ quan điểm về vụ việc này thông qua nhiều phép so sánh khác nhau.
• Một số người cho rằng việc sử dụng thông tin xác thực được hardcode có thể cấu thành hack, nhưng cũng cần xem xét ý định và thiệt hại đã xảy ra.
• Những người khác chỉ ra rằng phần mềm của nhà cung cấp đã gọi tới hạ tầng bên ngoài không được tài liệu hóa và có khả năng đang chia sẻ dữ liệu nhạy cảm.
• Ngoài ra, họ cũng đề cập đến nhu cầu về các kiểm toán viên độc lập cần được bảo vệ về mặt pháp lý, cũng như vấn đề khi điều đó không khả thi.

Ý kiến của GN⁺

• Vụ việc này cho thấy hành vi phát hiện và báo cáo lỗ hổng của các nhà nghiên cứu bảo mật có thể đi kèm rủi ro pháp lý.
• Phán quyết của tòa nhấn mạnh mối quan hệ căng thẳng giữa nghiên cứu bảo mật và công bố có trách nhiệm, đồng thời khơi ra cuộc thảo luận quan trọng về cách khung pháp lý cần hài hòa với tiến bộ công nghệ.
• Điều này cũng cho thấy những phán quyết như vậy có thể tạo ra hiệu ứng răn đe đối với các nhà nghiên cứu bảo mật, khiến các công ty áp dụng biện pháp bảo mật không phù hợp có thể né tránh vấn đề, và cuối cùng đẩy người dùng vào rủi ro.

[GN⁺]

Ý kiến trên Hacker News

• Tiêu đề gây hiểu lầm và có vẻ gần như câu kéo nhấp chuột

  • Tiêu đề bài báo gây khó hiểu và tiệm cận clickbait. Vấn đề thực tế không phải là làm lộ thông tin xác thực cơ sở dữ liệu, mà là đã dùng chúng để đăng nhập vào máy chủ cơ sở dữ liệu của bên thứ ba. Đây là vấn đề lớn do các điều khoản hình sự StGB 202 ff., vốn trên thực tế khiến việc nghiên cứu bảo mật gần như không thể thực hiện ở Đức.

• Vấn đề nghiên cứu bảo mật tại Đức

  • Trong khoảng 20 năm qua, ở Đức hầu như không có nhiều kỹ sư trẻ quan tâm đến lĩnh vực bảo mật, và người được đào tạo bài bản cũng rất hiếm. Các tập đoàn lớn đã hút hết nhân sự giỏi, còn những người xuất sắc nhất thì ra nước ngoài. Kết quả là phần lớn các doanh nghiệp vừa và nhỏ ở Đức bị tấn công hằng ngày, và vì không ai kiểm toán nên mọi thứ kết nối vào mạng đều trở thành rủi ro bảo mật.

• Lời khuyên pháp lý

  • Trông đợi vụ việc này sẽ bị bác bỏ ở tòa cấp cao là suy nghĩ rất ngây thơ. Bị cáo sẽ phải lãng phí nhiều năm qua nhiều cấp xét xử và tốn khoảng 100.000 euro tiền luật sư. Tất cả chỉ vì công ty đã không bảo vệ dữ liệu của chính mình đúng cách. Nếu không có chương trình bug bounty rõ ràng, nếu đó không phải công ty của mình, hoặc nếu không được thuê để tìm lỗ hổng, thì lời khuyên là đừng biến vấn đề đó thành chuyện của mình.

• Phản ứng của các chuyên gia bảo mật Đức

  • Một số chuyên gia an ninh thông tin kỳ cựu ở Đức tức giận đến mức từ chối hỗ trợ các cơ quan nhà nước ngay cả khi xảy ra sự cố. Họ mô tả tình cảnh này bằng câu "học qua đau đớn".

• So sánh với luật pháp Anh

  • Không chắc về luật Đức, nhưng ở Anh điều này sẽ rõ ràng bị xem là hành vi lạm dụng máy tính và được xử như một vụ việc đơn giản.

• Sự cần thiết phải sửa đổi luật

  • Có vẻ luật cần được viết lại. Ý định là yếu tố quan trọng, và "hacker" này dường như không có ý gây hại. Công ty đã tự để lộ lỗ hổng của mình rồi lại muốn trừng phạt người phơi bày nó.

• Trường hợp tương tự

  • Điều này tương tự với trường hợp việc giải mã số an sinh xã hội được mã hóa bằng BASE64 bị xem là "hack".

• Trường hợp startup thực phẩm ở Hà Lan

  • Trong lúc hợp tác với PostNL, người ta đã có thể truy cập dữ liệu của các khách hàng khác, nhưng quyết định không sử dụng khả năng đó để tránh trách nhiệm pháp lý. Công ty lẽ ra phải báo cáo việc này theo quy định pháp luật nhưng đã không làm vậy.

• Thái độ chung đối với bảo mật

  • Nhiều vụ "hack" chẳng khác nào việc người ta mở toang cửa trước rồi bỏ mặc. Nếu mở cửa rồi bị trộm thì sẽ không nhận được nhiều cảm thông, nhưng khi công ty lơ là bảo mật thì người ta lại nổi giận với hacker.

• Tình huống đi ngược lại nguyên tắc thiện chí

  • Đây là tình huống mà nếu phát hiện vấn đề thì tốt nhất đừng nói gì và cũng đừng làm gì. Tò mò không biết liệu việc nghi ngờ có vấn đề, dừng lại, rồi bán khống cổ phiếu của công ty có hợp pháp hay không.

• Cách xử lý khi phát hiện vấn đề

  • Ngay cả khi phát hiện ra vấn đề thì tốt hơn là nên bỏ qua. Chỉ riêng việc thông báo rằng có thể nhìn thấy mật khẩu cũng đã là chấp nhận rủi ro. Còn sử dụng mật khẩu đó thì lại càng phải tránh.

• Điều 202a Bộ luật Hình sự

  • Điều này nói về việc "truy cập dữ liệu được bảo vệ khỏi truy cập trái phép bằng các biện pháp đặc biệt", và mật khẩu hardcode trong client cũng thuộc trường hợp đó.