Penetration Testing Step 3 – Công phá hệ thống Multi-factor authentication

Như đã hứa hẹn khi kết thúc nội dung Penetration Testing Step 3 – Những con đường đâm thọc hệ thống brute-force protection, kỳ này tôi sẽ bàn đến việc đâm thọc hệ thống có triển khai multi-factor authentication (cụ thể ở đây sẽ là 2 Factors Authentication – 2FA).

Lưu ý:

• Nếu chưa rõ multi-factor authentication là gì thì bạn có thể xem lại nội dung Penetration Testing Step 3 – Tấn công vào Authentication mechanisms liệu có khả thi?;
• Như mọi khi, tôi cũng sẽ tận dụng các bài Lab dựng sẵn của ông PortSwigger để tiết kiệm thời gian dàn cảnh.;
• Thông tin liên quan đến Burp Suite bạn có thể xem nội dung Penetration Testing Step 3 – 6 điều bạn nên biết trước khi xài tool khủng Burp Suite;
• Chi tiết việc sử dụng Burp Suite Repeater bạn có thể xem trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater;
• Chi tiết việc sử dụng Burp Suite Intruder bạn có thể xem trong nội dung Penetration Testing Step 3 – Chuẩn bị đổ mưa bom, bão đạn lên mục tiêu với Burp Suite Intruder;

#1. Two Factors Authentication – 2FA an toàn đến đâu?

Với 2FA, hình thức triển khai phổ biến nhất hiện nay mà bạn có thể gặp là sử dụng:

• Something you know: Ví dụ password;
• Something you have: Ví dụ cái điện thoại với app xác thực như Google Authenticator hoặc securtiy token như RSA token để tạo verification code;

Ngoài ra, bạn cũng có thể gặp các tình huống như sau:

• Xác thực với verification code gửi qua email: Nhìn chung, giải pháp này sẽ tốt hơn chỉ sử dụng mỗi password nhưng thật sự không đúng chuẩn 2FA với 2 factor khác nhóm nhau (vì ở đây thực chất password đăng nhập vào mục tiêu và credential để đăng nhập vào email thuộc cùng nhóm factor something you know);
• Sử dụng điện thoại để nhận verification code qua SMS: Phương án này sẽ tốt hơn dùng email ở trên nhưng vẫn tiềm ẩn rủi ro như SIM swapping để chiếm SIM của nạn nhân hoặc lừa đảo để chuyển tiếp tin nhắn.

Ngoài những điểm yếu kỹ thuật của giải pháp, đôi khi bạn cũng có thể ăn may nếu như việc triển khai 2FA bị lỗi dẫn đến mất sạch tác dụng ví dụ như:

• Hệ thống không kiểm tra xem bước xác thực thứ hai đã hoàn thành hay chưa trước khi xác lập trạng thái đã log in cho người dùng;
• Hệ thống không kiểm soát chặt quá trình chuyển tiếp giữa 2 bước xác thực, từ đó cho phép attacker sử dụng kết quả xác thực ở bước 1 cho account ban đầu (với một số hiệu chỉnh) để triển khai xác thực bước 2 cho một account khác rồi truy cập vào hệ thống dưới danh nghĩa account này.

Nội dung chém gió lý thuyết dông dài quá rồi, tôi bắt tay vô demo một số tình huống cụ thể cho rõ ràng ngay đây.

#2. Khai thác lỗi logic khi chuyển tiếp giữa 2 bước xác thực của 2FA

Tình huống demo ở đây là tôi đã có credential để đăng ký vào hệ thống) thông qua quá trình đăng ký thông thường. Nhưng với lòng tham không đáy, tôi vẫn muốn chiếm đoạt tài khoản của người khác (nạn nhân “carlos” trong trường hợp này) để coi nạn nhân có hàng họ gì ngon hơn tôi không.

Để đơn giản hóa, cái verification code ở bước thứ 2 sẽ được gửi qua email. Tuy nhiên phần demo này sẽ không sử dụng cách tấn công chiếm credential để đăng nhập vào email như đề cập ở Mục 1 mà tận dụng lỗi logic trong quản lý quá trình chuyển tiếp của 2 bước xác thực.

1, 2, 3, …Bắt đầu!

#2.1 Nhen nhóm mưu đồ tấn công

Sau khi bật Burp Suite, tôi thử login vào hệ thống bằng credential chính chủ (“wiener:peter”) để kiểm tra quá trình xác thực 2 yếu tố. Cụ thể, với cái POST /login2 request sau, tôi có thể thấy verify parameter (đang thiết lập cho “wiener”) dùng để xác định user đang truy cập. Thông tin này cho tôi ý tưởng về việc thay đổi verify parameter sang nạn nhân (“carlos”) để chiếm đoạt tài khoản.

Nghĩ là làm. Tôi logout tài khoản của mình và quay lại chỗ Proxy History để tìm và đẩy cái GET /login2 request sang Burp Repeater. Sau đó tôi đổi verify parameter thành nạn nhân (“carlos”) và send request nhằm kích hoạt việc tạo cái 2FA verification code cho nạn nhân.

Lưu ý: Phần Proxy History bạn có thể xem thêm trong nội dung Penetration Testing Step 3 – Chi tiết về Proxy tab, trái tim của Burp Suite.

#2.2 Brute-force verification code

Kế tiếp, tôi thực hiện lại quá trình login với credential của mình (“wiener:peter”). Nhưng lần này tôi đút vào cái 2FA verification code đểu để hốt cái response báo lỗi “Incorrect security code” như sau.

Từ đây, tôi đẩy cái POST /login2 request này qua Burp Suite Intruder và thiết lập lại verify parameter sang thành nạn nhân (“carlos” như bên dưới). Đồng thời, tôi cũng sẽ sử dụng Attack type Sniper với payload marker đặt vào vị trí mfa-code nhằm chuẩn bị brute-force để dò tìm verfication code.

Chuyển sang phần payload, để brute-force cái mfa-code, tôi có thể sử dụng Brute forcer với các thiết lập như sau.

Sau khi nhả đạn Start Attack, tôi rung đùi chờ kết quả về và soi dòng tương ứng với status code 302 (ứng với payload 0084 bên dưới). Kế đến, tôi chọn Show response in browser để lấy URL đẩy vào brrower tận hưởng thành quả.

#3. Khai thác lỗi của hệ thống anti-brute-force verification code

#3.1 Cơ sở của mưu đồ tấn công

Như phần demo ở Mục 2, bạn có thể thấy lỗ hổng trong khâu quản lý giữa 2 bước xác thực đã cho phép tôi tận dụng kết quả bước 1 rồi tha hồ brute-force cái verification code với Burp Suite Intruder ở bước 2 và đường đường chính chính đăng nhập vào hệ thống với danh nghĩa của nạn nhân.

Để xử lý vấn đề này, ngoài việc kiểm soát bước chuyển tiếp, mục tiêu cũng sẽ cần triển khai các giải pháp để ngăn chặn khả năng brute-force cái verification code (ví dụ như phương án giới hạn thời gian hiệu lực).

Đôi khi, một số hệ thống sử dụng cách “thân thiện” hơn là bắt người dùng thực hiện lại bước một nếu nhập sai verification code một số lần. Và đây là một trong những tình huống mà tôi có thể tận dụng để thò bàn tay nhơ nhuốc của mình vào hệ thống.

#3.2 Triển khai chống anti-brute-force với Burp Suite Macro

Rồi, tôi bắt tay vào phần demo. Trong tình huống này, giả sử sau khi giở đủ chiêu trò, tôi đã có trong tay credential của nạn nhân (“carlos:montoya”) nhưng vẫn còn kẹt ở cái bước xác thực với 2FA verification code.

Việc đầu tiên tôi cần làm cũng là bật Burp Suite và thử nghiệm quá trình xác thực với credential của nạn nhân để xác nhận việc bị sút văng ra ngoài khi nhập verification code sai quá nhiều lần.

Và để xử lý cái giải pháp chống brute-force bằng cách bắt đăng nhập lại ở trên, tôi sẽ cần thiết lập thêm để Burp Suite tự động log in trước khi gửi request. Để làm vụ này, tôi đi vào Project options > Sessions > Sesion Handling Rules.

Sau đó tôi click Add để mở Session handling rule editor và nhảy sang Scope tab chọn Include all URLs bên dưới phần URL Scope.

Sau đó, quay lại Details tab, tôi chọn Add bên dưới phần Rule Actions rồi húp cái Run a macro.

Lưu ý: Nếu không thích phương án sử dụng macros, bạn có thể xem xét sử dụng Burp Suite extension là Turbo Intruder.

Sau đó click Add tiếp để mở Macro Recorder.

Trong cái Macro Recorder, tôi chọn 3 cái request sau:

• GET /login
• POST /login
• GET /login2

Sau đó chọn OK để mở cái Macro Editor và chọn Test macro.

Nếu response trả về yêu cầu nhập securiry code như bên dưới là ngon ăn.

Kế đến thì tôi cứ OK, next…như điên để quay lại giao diện chính của Burp Suite.

#3.3 Brute-force verification code (again)

Sau khi đã thiết lập xong phần macro, tôi quay về chỗ Proxy History tìm và đẩy cái POST /login2 sang Burp Intruder. Tại đây tôi cũng sẽ thiết lập Attack type là Sniper và payload marker vô vị trí mfa-code như bên dưới.

Chuyển sang phần payload, tôi có thể thiết lập kiểu Numbers như sau.

Sau đó chuyển sang Resource pool để thiết lập Maximum concurrent request về 1 để gửi request tuần tự rồi Start attack.

Khi nào hàng về, tôi sẽ lọc theo status code và túm thằng có giá trị 302 rồi chọn Show response in browser để copy URL chuyển qua browser.

Như vậy bạn có thể thấy giải pháp chống brute-force bằng cách sút attacker ra ngoài để đăng nhập lại đã hoàn toàn bị phá sản. Tuy nhiên, tôi thấy cần nhấn mạnh lại tình huống ở trên chỉ để minh họa, thực tế bạn hiếm khi may mắn ăn được con hàng dễ dàng như thế này đâu nhé.