Chuyến đi vào chiếc két sắt số và cuộc tấn công vào password vault

Hãy tưởng tượng bạn đang đứng trước một thành phố mà mỗi căn nhà đều có một chiếc két sắt riêng.

Trong két có chìa khóa ngân hàng, tài khoản email, tài liệu công việc, tài khoản mạng xã hội và hàng chục bí mật khác. Người quản lý thành phố không giữ những chiếc chìa khóa ấy trực tiếp. Thay vào đó, họ xây dựng một hệ thống để mỗi người có thể mở két của mình bằng một mật khẩu chủ.

Đó là cách có thể hình dung về password manager.

Và rồi một ngày, kẻ tấn công không cố phá chiếc két.

Hắn tìm cách thuyết phục hệ thống rằng mình là chủ nhân hợp pháp của một chiếc chìa khóa mới.

Đó chính là điều khiến vụ tấn công nhằm vào người dùng Dashlane trở nên đáng chú ý.

Theo thông tin được công bố, một nhóm tấn công đã thực hiện chiến dịch tự động hóa trên quy mô lớn nhằm vào cơ chế đăng ký thiết bị mới. Mục tiêu không phải ngay lập tức giải mã kho mật khẩu. Mục tiêu đầu tiên đơn giản hơn: tìm cách khiến hệ thống cấp quyền tải xuống những bản sao của password vault được mã hóa.

Cuộc tấn công cuối cùng bị chặn lại.

Ít hơn 20 vault cá nhân đã bị tải xuống trước khi chiến dịch bị vô hiệu hóa.

Nhưng câu chuyện quan trọng không nằm ở con số đó.

Nó nằm ở cách kẻ tấn công suy nghĩ.

Và bài học nằm ở chỗ: một hệ thống có mã hóa rất mạnh vẫn có thể bị đặt vào tình huống nguy hiểm nếu lớp xác thực phía trước bị khai thác theo cách đủ thông minh.

Cánh cửa không nằm ở chiếc két

Password manager hiện đại thường được thiết kế theo một nguyên tắc khá đơn giản.

Bạn có một tài khoản.

Bạn cài ứng dụng trên điện thoại hoặc máy tính mới.

Hệ thống cần xác nhận rằng thiết bị mới thực sự thuộc về bạn.

Trong trường hợp này, quy trình đăng ký thiết bị của Dashlane sử dụng một mã xác thực một lần gồm sáu chữ số được gửi đến email đã đăng ký. Với người dùng bật xác thực hai yếu tố, hệ thống có thể yêu cầu mã sáu chữ số được tạo bởi ứng dụng xác thực.

Người dùng nhập mã vào thiết bị mới.

Nếu mã đúng, thiết bị được đăng ký.

Sau đó, bản sao của vault được mã hóa có thể được gửi xuống thiết bị.

Đây là thiết kế hợp lý.

Nhưng nó tạo ra một điểm mà kẻ tấn công có thể nhắm tới.

Họ không cần phá mã hóa vault ngay từ đầu.

Họ chỉ cần tìm cách vượt qua lớp xác thực để lấy được bản sao của vault.

Đây là một khác biệt rất quan trọng trong an ninh mạng.

Tấn công hệ thống không nhất thiết có nghĩa là phá lớp bảo mật mạnh nhất.

Đôi khi con đường hiệu quả hơn là tìm một cánh cửa bên cạnh.

Một triệu khả năng và một bài toán xác suất

Một mã sáu chữ số có 1 triệu khả năng.

Nếu kẻ tấn công chỉ nhắm vào một tài khoản, việc thử lần lượt tất cả các mã là một chiến thuật cực kỳ kém hiệu quả.

Mã xác thực chỉ tồn tại trong một khoảng thời gian giới hạn, khoảng ba giờ trong mô tả của hệ thống. Hơn nữa, các cơ chế rate limiting và tự động khóa tài khoản khiến việc gửi liên tục hàng trăm nghìn hoặc hàng triệu yêu cầu vào cùng một tài khoản trở nên rất khó.

Nếu chỉ có một cánh cửa, hàng triệu lần thử sẽ nhanh chóng bị phát hiện.

Nhưng kẻ tấn công không đi qua một cánh cửa.

Họ thử rất nhiều cánh cửa cùng lúc.

Đây là điểm tinh vi của chiến dịch.

Thay vì liên tục thử mã với một người dùng, hệ thống tấn công gửi yêu cầu đăng ký thiết bị đến một lượng lớn tài khoản.

Sau đó, các mã được thử song song trên nhiều tài khoản.

Về mặt xác suất, điều này thay đổi hoàn toàn bài toán.

Nếu chỉ tấn công một tài khoản, một lần thử có xác suất đúng là 1 trên 1.000.000.

Nếu cùng một lượt thử được phân bổ trên hai tài khoản, cơ hội để một trong hai tài khoản trúng mã tăng lên.

Với 1.000 tài khoản, bài toán trở nên khác hẳn.

Xác suất lý thuyết để một lượt thử trúng một mã trong tập tài khoản đó có thể tăng lên khoảng 1 trên 1.000.

Kẻ tấn công không còn cố thắng bằng tốc độ.

Họ thắng bằng quy mô.

Đây chính là tư duy phía sau password spraying.

Tại sao rate limiting không còn đủ?

Rate limiting là một trong những công cụ quan trọng để chống brute force.

Hệ thống có thể nói:

“Bạn chỉ được thử một số lần nhất định.”

Nếu kẻ tấn công tập trung vào một tài khoản, biện pháp này rất hiệu quả.

Nhưng nếu họ chia hàng nghìn lần thử cho hàng nghìn tài khoản, mỗi tài khoản chỉ nhận một lượng yêu cầu tương đối nhỏ.

Hệ thống khó nhìn thấy một cuộc tấn công lớn nếu chỉ quan sát từng tài khoản riêng lẻ.

Đây là một bài toán kiến trúc.

Một hệ thống phòng thủ tốt không thể chỉ hỏi:

“Tài khoản này đang bị tấn công bao nhiêu lần?”

Nó phải hỏi thêm:

“Toàn bộ hệ thống đang nhận một mẫu hành vi bất thường nào?”

Đó là sự khác biệt giữa bảo mật ở cấp tài khoản và bảo mật ở cấp hệ thống.

Dashlane cho biết các hệ thống bảo mật tự động đã hoạt động như thiết kế và kích hoạt khóa tài khoản đối với các tài khoản bị nhắm mục tiêu.

Nhưng trước khi chiến dịch được kiểm soát hoàn toàn, kẻ tấn công vẫn tạo được token hợp lệ cho ít hơn 20 tài khoản cá nhân và sử dụng quyền đó để đăng ký thiết bị mới, sau đó tải bản sao vault được mã hóa.

Nói cách khác, lớp phòng thủ đã làm giảm đáng kể thiệt hại.

Nhưng không có lớp phòng thủ nào nên được xem là duy nhất.

Lấy được vault không đồng nghĩa lấy được mật khẩu

Đây là phần quan trọng nhất của câu chuyện.

Kẻ tấn công có thể tải xuống một vault.

Nhưng vault đó vẫn được mã hóa.

Nội dung bên trong chưa tự động trở thành văn bản có thể đọc.

Muốn giải mã, kẻ tấn công vẫn cần master password.

Và đây là nơi kiến trúc mật mã của password manager trở thành tuyến phòng thủ cuối cùng.

Dashlane sử dụng Argon2 để làm cho quá trình biến master password thành cryptographic hash trở nên tốn thời gian và tài nguyên tính toán hơn.

Điều này rất quan trọng.

Một hệ thống password manager không chỉ cần mã hóa dữ liệu.

Nó cần khiến việc thử hàng triệu hoặc hàng tỷ mật khẩu giả trở nên đắt đỏ về mặt tính toán.

GPU mạnh có thể giúp kẻ tấn công tăng tốc nhiều loại tác vụ.

Nhưng nếu thuật toán được thiết kế để cố tình tiêu tốn nhiều tài nguyên cho mỗi lần kiểm tra mật khẩu, việc brute force vẫn trở nên khó khăn hơn đáng kể.

Vì vậy, có hai cuộc chiến diễn ra liên tiếp.

Cuộc chiến thứ nhất là:

Kẻ tấn công có lấy được vault hay không?

Cuộc chiến thứ hai là:

Nếu lấy được vault, họ có giải mã được nó hay không?

Hai câu hỏi này không giống nhau.

Master password vẫn là điểm cuối của chuỗi

Một vault được mã hóa mạnh không có nghĩa mọi master password đều mạnh.

Đây là nơi con người bước vào kiến trúc bảo mật.

Một master password dài, ngẫu nhiên và có entropy cao sẽ khiến việc đoán trở nên khó hơn rất nhiều.

Ngược lại, nếu master password xuất hiện trong những danh sách mật khẩu phổ biến mà giới bẻ khóa thường sử dụng, xác suất bị đoán sẽ cao hơn.

Mật mã có thể bảo vệ dữ liệu.

Nhưng mật mã không thể biến một mật khẩu yếu thành mật khẩu mạnh.

Đây là lý do password manager thường được xem như một công cụ vừa mang tính công nghệ vừa mang tính hành vi.

Nó giúp người dùng tạo và lưu mật khẩu mạnh cho từng dịch vụ.

Nhưng master password vẫn cần được bảo vệ đặc biệt.

Bài học từ LastPass

Vụ việc này cũng gợi nhớ đến một sự cố nổi tiếng trước đó trong ngành password manager.

Năm 2022, LastPass từng bị tấn công và kẻ tấn công thu được các vault được mã hóa.

Điểm đáng chú ý là việc có được vault không đồng nghĩa dữ liệu bên trong lập tức bị đọc.

Nhưng một số yếu tố đã khiến tình hình phức tạp hơn.

Một số trường dữ liệu, chẳng hạn URL website, từng không được mã hóa hoàn toàn trong vault, khiến kẻ tấn công có thể nhìn thấy thông tin đó mà không cần master password.

Ngoài ra, một số vault sử dụng các thuật toán hoặc cấu hình cũ khiến quá trình thử master password không khó như khi dùng những phương pháp bảo vệ mạnh hơn.

So sánh này cho thấy một nguyên tắc quan trọng:

Bảo mật không phải một tính năng. Nó là một chuỗi.

Mã hóa dữ liệu là một mắt xích.

Xác thực là một mắt xích.

Quản lý thiết bị là một mắt xích.

Rate limiting là một mắt xích.

Thuật toán băm mật khẩu là một mắt xích.

Và cách người dùng đặt master password cũng là một mắt xích.

Chỉ cần một mắt xích yếu hơn đáng kể, toàn bộ chuỗi có thể trở nên dễ tấn công hơn.

Điều đáng chú ý trong kiến trúc của Dashlane

Một điểm có lợi cho Dashlane là theo thông tin được công bố, các trường dữ liệu trong vault được mã hóa thay vì để một số thông tin quan trọng ở dạng không mã hóa.

Ngoài ra, khi thuật toán mật mã cần được tăng cường theo sự tiến bộ của công nghệ bẻ khóa, quá trình cập nhật có thể được thực hiện tự động mà không yêu cầu người dùng phải thao tác thủ công.

Đây là một chi tiết kiến trúc rất đáng giá.

Bảo mật không thể đứng yên.

Một thuật toán đủ mạnh hôm nay có thể không còn đủ mạnh trong nhiều năm tới.

Phần cứng thay đổi.

GPU mạnh hơn.

Kỹ thuật tấn công tốt hơn.

Danh sách mật khẩu lớn hơn.

Các công cụ tự động hóa ngày càng phổ biến.

Một password manager hiện đại vì vậy phải có khả năng tiến hóa.

Không chỉ mã hóa hôm nay.

Mà còn có khả năng tăng cường bảo vệ khi môi trường tấn công thay đổi.

Doanh nghiệp nên nhìn vụ việc này như thế nào?

Sai lầm phổ biến là nhìn vào kết quả:

“Ít hơn 20 vault bị tải xuống, vậy vấn đề không lớn.”

Đó không phải cách một đội bảo mật nên đánh giá.

Điều đáng quan tâm hơn là phương thức tấn công.

Kẻ tấn công đã tìm thấy một API có giá trị.

Họ tự động hóa yêu cầu.

Họ phân phối cuộc tấn công trên nhiều tài khoản.

Họ khai thác xác suất.

Họ tìm cách làm suy yếu hiệu quả của rate limiting.

Đây là tư duy có thể xuất hiện trong rất nhiều hệ thống khác.

Không nhất thiết phải là password manager.

Nó có thể là:

API đăng nhập.

API đặt lại mật khẩu.

API gửi OTP.

API đăng ký thiết bị.

API xác minh email.

API khôi phục tài khoản.

Bất kỳ API nào có cơ chế “chứng minh bạn là người dùng hợp lệ” đều có thể trở thành mục tiêu.

Platform hay product?

Một password manager nhìn bề ngoài là một sản phẩm.

Ứng dụng trên điện thoại.

Ứng dụng desktop.

Extension trình duyệt.

Một vault.

Một giao diện để điền mật khẩu.

Nhưng phía dưới nó là một platform bảo mật.

Nó phải xử lý danh tính, thiết bị, mã hóa, đồng bộ hóa, xác thực, khóa tài khoản và cập nhật thuật toán.

Điều này khiến chất lượng của sản phẩm không thể chỉ đánh giá bằng giao diện.

Một ứng dụng đẹp nhưng thiết kế API xác thực kém vẫn là một sản phẩm nguy hiểm.

Ngược lại, một hệ thống có kiến trúc bảo mật tốt có thể bảo vệ dữ liệu ngay cả khi một lớp khác bị vượt qua.

Đây chính là khái niệm defense in depth.

Không kỳ vọng một bức tường duy nhất chặn mọi cuộc tấn công.

Xây nhiều lớp.

Nếu một lớp thất bại, lớp tiếp theo vẫn phải đứng vững.

Lợi thế cạnh tranh thật sự nằm ở kiến trúc

Thị trường password manager có thể nhìn giống một cuộc cạnh tranh về tính năng.

Đồng bộ đa thiết bị.

Tự động điền.

Chia sẻ mật khẩu.

Xác thực hai yếu tố.

Giao diện.

Nhưng trong dài hạn, lợi thế khó sao chép nhất lại nằm ở kiến trúc bảo mật.

Khả năng phát hiện bất thường.

Khả năng khóa tài khoản.

Cơ chế đăng ký thiết bị.

Quản lý khóa.

Mã hóa toàn bộ vault.

Thuật toán bảo vệ master password.

Khả năng cập nhật thuật toán.

Và khả năng phản ứng khi xảy ra sự cố.

Đây là những thứ người dùng thường không nhìn thấy.

Nhưng chúng quyết định liệu sản phẩm có thể tồn tại sau một cuộc tấn công thực sự hay không.

Việt Nam nên rút ra bài học gì?

Đối với doanh nghiệp Việt Nam đang xây dựng SaaS, ngân hàng số, thương mại điện tử, mạng xã hội hoặc hệ thống quản trị nội bộ, bài học này đặc biệt thực tế.

Đừng chỉ bảo vệ database.

Hãy bảo vệ đường đi đến database.

API authentication phải được thiết kế với góc nhìn chống abuse.

Rate limiting nên được xem xét ở nhiều cấp: IP, tài khoản, thiết bị, email, token và hành vi tổng thể.

Hệ thống cũng cần phát hiện các mẫu như một nguồn gửi yêu cầu đăng ký thiết bị cho hàng nghìn tài khoản trong thời gian ngắn.

Không nên chỉ khóa từng tài khoản.

Phải nhìn thấy chiến dịch.

Với các hệ thống có thông tin nhạy cảm, việc mã hóa dữ liệu cũng cần được thiết kế theo nguyên tắc giảm thiểu thiệt hại.

Nếu một database hoặc một vault bị lấy đi, kẻ tấn công không nên ngay lập tức đọc được dữ liệu.

Đó mới là mục tiêu của mã hóa thực sự.

Và bài học quan trọng nhất vẫn là con người

Một hệ thống có thể có API tốt.

Rate limiting tốt.

Mã hóa tốt.

Argon2 tốt.

2FA tốt.

Nhưng nếu người dùng sử dụng master password yếu, tuyến phòng thủ cuối cùng vẫn bị suy giảm.

Vì vậy, bảo mật doanh nghiệp không thể chỉ là câu chuyện của đội security.

Nó phải là sự kết hợp giữa kiến trúc phần mềm, vận hành, chính sách và hành vi người dùng.

Đặc biệt với những hệ thống lưu trữ thông tin xác thực, nguyên tắc nên rất đơn giản:

Giả định rằng một ngày nào đó dữ liệu mã hóa có thể bị đánh cắp.

Nếu điều đó xảy ra, hệ thống phải được thiết kế để dữ liệu vẫn khó bị khai thác.

Đó là một tư duy khác với việc cố xây một hệ thống “không bao giờ bị hack”.

Không có hệ thống nào như vậy.

Điểm đến cuối cùng của cuộc chiến mật khẩu

Vụ việc này không cho thấy mã hóa thất bại.

Ngược lại, nó cho thấy tại sao một kiến trúc bảo mật cần nhiều lớp.

Kẻ tấn công đã tìm cách vượt qua một phần quy trình xác thực bằng cách phân tán brute force trên rất nhiều tài khoản.

Họ đã thành công với một số lượng rất nhỏ tài khoản trước khi hệ thống phòng thủ chặn chiến dịch.

Nhưng ngay cả sau khi lấy được vault, họ vẫn phải đối mặt với lớp mã hóa và master password.

Đó chính là giá trị của defense in depth.

Một lớp bị xuyên thủng không đồng nghĩa toàn bộ thành phố đã mở cửa.

Có thể cánh cổng đầu tiên đã bị phá.

Nhưng phía sau nó vẫn còn tường.

Còn khóa.

Còn hệ thống cảnh báo.

Còn một chiếc két khác.

Và đó là cách nên nhìn password manager hiện đại.

Không phải như một chiếc hộp lưu mật khẩu.

Mà như một hệ thống phòng thủ nhiều tầng được xây dựng quanh một tài sản cực kỳ nhạy cảm.

Trong thế giới số, kẻ tấn công ngày càng ít quan tâm đến việc phá một chiếc khóa theo cách truyền thống.

Họ tìm API.

Tìm quy trình.

Tìm xác suất.

Tìm những điểm mà hệ thống tin rằng hành vi của người dùng là bình thường.

Vì vậy, cuộc chiến bảo mật trong tương lai sẽ không chỉ là cuộc chiến giữa hacker và thuật toán mã hóa.

Nó sẽ là cuộc chiến giữa kiến trúc hệ thống và khả năng thích nghi của kẻ tấn công.

Và với doanh nghiệp, câu hỏi quan trọng nhất không phải là:

“Chúng ta có mã hóa dữ liệu hay không?”

Mà là:

“Nếu ngày mai kẻ tấn công lấy được dữ liệu đã mã hóa, họ còn có thể làm được gì?”

Nếu câu trả lời là “gần như không thể làm gì”, đó mới thực sự là một hệ thống được thiết kế để sống sót.

Từ khóa SEO

Dashlane, password manager, password vault, bảo mật mật khẩu, mã hóa dữ liệu, 2FA, xác thực hai lớp, password spraying, brute force, Argon2, OTP, bảo mật tài khoản, an ninh mạng, mã hóa vault, master password, bảo mật doanh nghiệp, quản lý mật khẩu, tấn công API, bảo vệ dữ liệu