3.0K 224 105

Đã đăng vào thg 11 15, 2022 7:09 SA 12 phút đọc

916

Authentication vulnerability - Lỗ hổng xác thực (phần 3)

IV. Phân tích và khai thác lỗ hổng trong xác thực đa yếu tố (multi-factor authentication)

1. Tổng quan

Qua mục III, các bạn đã thấy được rằng chỉ riêng sử dụng kỹ thuật vét cạn (brute force), chúng ta cũng có rất nhiều cách khai thác đối với phương thức xác thực danh tính người dùng thông qua mật khẩu. Ngay cả khi hệ thống có sử dụng thêm các cơ chế, biện pháp ngăn chặn kỹ thuật tấn công này, thì cũng luôn tồn tại nhiều hình thức bypass (vượt qua). Không phải tất cả các lập trình viên đều dám khẳng định mình có thể tạo ra một sản phẩm "bất khả xâm phạm". Điều đó cũng chứng tỏ việc sử dụng đơn thuần phương thức xác thực danh tính bằng mật khẩu đã không đủ tính bảo mật, nhất là đối với những hệ thống chứa đựng nhiều thông tin, dữ liệu quan trọng. Bởi vậy, các nhà cung cấp cần sử dụng thêm ít nhất một "bức tường" bảo vệ người dùng nữa. Và Two-factor authentication (2FA) chính là một giải pháp được lựa chọn bởi nhiều nhà cung cấp.

2. Two-factor authentication (2FA) là gì? Nên lựa chọn dạng 2FA nào?

Xin được trích dẫn một định nghĩa về Multi-factor authentication (MFA):

Multi-factor authentication (MFA; encompassing authentication, or 2FA, along with similar terms) is an electronic authentication method in which a user is granted access to a website or application only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows), possession (something only the user has), and inherence (something only the user is).

Two-factor authentication (2FA) là một dạng của MFA, chúng ta có thể hiểu đơn giản đây là một quá trình xác thực hai nguyên tố, hoặc xác thực hai bước. Sau khi người dùng hoàn thành bước xác thực thứ nhất (thường là bằng tài khoản), hệ thống sẽ tiếp tục yêu cầu người dùng xác thực thêm một bước nữa để tăng độ bảo mật. Bước xác thực thứ hai dựa trên nguyên lý: tài nguyên sử dụng để xác thực phải là những sự vật, sự việc, yếu tố liên quan trực tiếp tới người dùng (những điều chỉ người dùng đó biết, những đồ vật chỉ người dùng đó sở hữu).

Vậy thì, từ nguyên lý hoạt động này, các bạn có thể dễ dàng nhận thấy hoặc biết tới (qua phim ảnh chẳng hạn) một số hệ thống xác thực bằng khuôn mặt, bằng vân tay - là thứ tồn tại duy nhất, rất khó để bị thay thế hoặc làm giả. Đúng vậy, đây có thể coi là một cơ chế bảo mật rất tốt cho người dùng cũng như doanh nghiệp. Tuy nhiên, thực tế (ít nhất là hiện tại) chưa thể ứng dụng rộng rãi việc sử dụng bảo mật bằng khuôn mặt hoặc sinh trắc học được, một phần là do yêu cầu kỹ thuật chuyên môn cao, một phần còn do kinh phí vận hành chưa thể đáp ứng (Hiện tại chỉ có các doanh nghiệp lớn hoặc các ứng dụng ngân hàng, tổ chức thuộc về chính phủ sử dụng).

Giải pháp xác thực ở bước thứ hai được lựa chọn thường là yêu cầu người dùng nhập một đoạn mã code được gửi về điện thoại, hoặc sử dụng ứng dụng sinh mã ngẫu nhiên gắn với trang web cần xác thực đó (Ví dụ: Google Authenticator), ...

3. Có thể vượt qua xác thực two-factor (2FA) một cách dễ dàng?

Có thể thấy rõ cơ chế xác thực hai bước đã nâng mức độ bảo mật lên nhiều so với xác thực chỉ bằng mật khẩu. Tôi chưa kể đến những trường hợp tấn công "vật lý" như chiếm đoạt điện thoại nhận mã 2FA, hoặc người dùng bất cẩn đánh mất điện thoại, thông thông cá nhân, ... thì cơ chế xác thực 2FA cũng chứa một mức độ rủi ro nhất định.

Trước khi đến với người dùng, thì code 2FA cũng sẽ cần được gửi từ hệ thống tới điện thoại của người dùng, bởi vậy hoàn toàn có thể bị tấn công bởi kỹ thuật tấn công Man in the Middle (Xem thêm tại Tấn công Man-in-the-Middle).

Hoặc xét về mặt hệ thống, cơ chế xác thực an toàn đến mức nào thì cũng là do con người tạo ra, do lập trình viên code, nên khó tránh khỏi sự thiếu xót. Chẳng hạn, một số trang web nhập mã 2FA chỉ là "trá hình, vô nghĩa", thực tế hệ thống đã cho phép bạn sử dụng các tính năng sau khi đăng nhập thành công (Điều này xảy ra do lỗi lập trình).

Phân tích lab 2FA simple bypass

Ở tình huống này chúng ta được cung cập một tài khoản hợp lệ (dùng để phân tích cách hoạt động của hệ thống xác thực) và có được username:password của tài khoản victim, chúng ta cần vượt qua cơ chế xác thực 2FA để truy cập vào tài khoản victim. Trang email hỗ trợ việc lấy mã code 2FA cho người dùng wiener.

Thử đăng nhập với tài khoản wiener:peter và quan sát các gói tin.

Sau khi đăng nhập tại trang /login, hệ thống chuyển hướng chúng ta tới một trang mới /login2 để thực hiện xác thực mã code 2FA.

Sau khi điền mã xác thực thành công chúng ta được đưa tới trang cá nhân của wiener. Click một lần nữa vào tùy chọn My account, URL xác định liên kết tới trang cá nhân của wiener:

Từ các dấu hiệu này có thể suy đoán rằng thực chất khi đăng nhập đúng tài khoản tại trang /login, chúng ta đã được xác thực thành công tại trang /login, còn trang /login2 giống như một thao tác phụ để xác thực mã code.

Thật vậy, trước khi điền mã 2FA, thay đổi URL dẫn tới trang cá nhân của wiener và thành công

Như vậy, chúng ta có thể trực tiếp sửa URL thành /my-account?id=carlos sau khi đăng nhập carlos:montoya tại trang /login

4. Vượt qua xác thực two-factor (2FA) với lỗ hổng logic

Đôi lúc, sau khi người dùng xác thực bước một (đăng nhập qua tài khoản) thành công, hệ thống thực hiện gắn một cookie tương ứng (mang tính duy nhất) cho người dùng tại thời điểm đó, và sử dụng chính cookie đó để nhận diện danh tính người dùng sau khi họ hoàn thành xác thực bước hai.

Xét ví dụ sau, đây là request khi người dùng gửi thông tin xác thực bước một tới hệ thống:

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

Yêu cầu trên gửi thông tin username=carlos và password=qwerty bằng phương thức POST tới hệ thống. Sau đó, hệ thống cấp một cookie cho người dùng carlos trước khi đưa họ tới bước xác thực thứ hai:

HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

Giá trị cookie tương ứng đặt cho người dùng carlos là account=carlos: đây là một cookie không an toàn vì nó trực tiếp sử dụng tên đăng nhập làm giá trị cookie mà không qua bước mã hóa nào. Sau đó, khi người dùng hoàn thành xong bước xác thực 2FA, hệ thống sử dụng chính cookie này để xác định danh tính người dùng:

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

Chắc hẳn các bạn cũng đã nhận ra chúng ta có thể làm gì với cookie này rồi chứ! Đúng vậy, kẻ tấn công hoàn toàn có thể thay thế giá trị cookie này thành tên đăng nhập của người dùng khác, biết đâu nó sẽ khiến hệ thống lầm tưởng rằng người dùng xấu số kia đang yêu cầu xác thực 2FA! Tất nhiên, kẻ tấn công sẽ mong muốn victim khi đó đang không hoạt động với tài khoản của họ (đang ngủ chẳng hạn...).

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

Phân tích lab 2FA broken logic

Trước hết, đăng nhập với tài khoản hợp lệ wiener:peter, thực hiện bắt request qua Burp Suite để tìm hiểu cách hoạt động cơ chế xác thực của hệ thống.

Sau khi đăng nhập tại trang /login, hệ thống chuyển hướng chúng ta tới một trang mới /login2 để thực hiện xác thực mã code 2FA. Và hệ thống xác thực danh tính người dùng bằng cookie verify=wiener:

Gửi lại request xác thực mã 2FA nhiều lần, hệ thống không ngăn chặn hành vi tấn công brute force. Hơn nữa mã mfa-code có định dạng là một chuỗi gồm 4 chữ số ngẫu nhiên, nên chúng ta có thể thực hiện một cuộc tấn công brute force sau khi thay đổi giá trị cookie thành verify=carlos.

Lựa chọn chế độ brute force, định dạng 4 kí tự và giới hạn các kí tự sử dụng là các chữ số 0-9:

Chúng ta thu được 1269 là mã 2FA hợp lệ. Click chuột phải chọn Show response in browser, copy và paste lên URL để truy cập vào tài khoản của carlos:

Các tài liệu tham khảo