Penetration Testing Step 3 – Bypass hệ thống xác thực với chức năng reset password

Kết thúc nội dung Penetration Testing Step 3 – Password cracking attack có dễ ăn không?, kỳ này tôi sẽ lại quay trở về với vấn đề Authentication – xác thực.

Ở nội dung Penetration Testing Step 3 – Bypass hệ thống xác thực với “Stay logged in” cookie, tôi đã giới thiệu phương án đường vòng né “trạm thu phí – login” thông qua việc khai thác cookie. Và trong nội dung kỳ này, tôi sẽ giới thiệu một phương án bypass hệ thống xác thực khác – đó là khai thác các lỗ hổng trong cơ chế reset password.

Thực tế, việc user mất/quên password đăng nhập là chuyện không hiếm gặp, do vậy, đa số các hệ thống đều chuẩn bị sẵn phương án cho phép user reset password. Và một số cách thường hay gặp:

• Hệ thống khởi tạo ra một password tạm thời có thời gian sử dụng ngắn và user bắt buộc phải thay đổi password ngay khi đăng nhập lại vào hệ thống;
• Hệ thống gửi link reset password đến email đã đăng ký của user để hoàn tất quá trình thiết lập password mới.

Trong khi phương án thứ nhất dễ bị ăn hành bởi man-in-the-middle attack thì phương án thứ hai cũng tiềm ẩn các vấn đề như khi link reset password có cấu trúc dễ đoán, attacker có thể dò tìm ra đáp án trong khoảng thời gian chấp nhật được. Để giải quyết vấn đề này, hệ thống có thể tăng độ ngẫu nhiên cho link bằng cách sử dụng token khó đoán (tốt nhất là dựa trên password của user).

Ý tưởng thiết kế nói trên có vẻ khá ổn nhưng thực tế triển khai sẽ vẫn có thể tiềm ẩn các vấn đề để tôi chấm mút:

• Hệ thống “quên” kiểm tra token khi thực hiện reset password hoặc để token trôi nổi được phép sử không hạn định kể cả khi user đã reset password;
• User hớ hênh để token rơi vào tay attacker;
• Hệ thống không ngăn chặn việc attacker tấn công dò tìm password.

Lưu ý:

• 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. Khai thác lỗi “quên” kiểm tra token trong quá trình reset password

#1.1 Thăm dò mục tiêu

Rồi, tôi vào việc với tình huống đầu tiên khi hệ thống, vì lí do gì đó, quên bén không kiểm tra token trước khi triển khai quá trình reset password.

Để bắt đầu, rôi bật Burp Suite Intercept lên sẵn và truy cập vào vị trí login của mục tiêu. Sau đó, tôi kiểm tra thử chức năng Forgot password?

Và sau đó điền username chính chủ (wiener như mọi khi) vào thử.

Với quá trình reset password thông thường, tôi sẽ phải nắm quyền truy cập vào email đã đăng ký với hệ thống để tiếp tục quá trình reset. Ở đây, để đánh nhanh thắng nhanh, tôi có thể dùng Email Client dựng sẵn chung với bài Lab. Tiếp tục, tôi chọn vào Email Client button để kiểm tra reset email sau đó chọt vào đường link để reset lại password như mong muốn.

Ở đây, nếu quan sát kỹ tôi sẽ thấy reset token được kẹp trong cái URL query parameter như bên dưới.

Tôi cũng dò lại Burp Suite History để tìm cái POST /forgot-password?temp-forgot-password-token request (tương ứng với việc nhập và gửi password mới ở trên) và đẩy sang Burp Suite Repeater.

Câu chuyện bắt đầu thú vị ở vị trí này. Kể cả khi tôi thử xóa giá trị của temp-forgot-password-token parameter (ở URL trong phần đầu của request và phần request body bên dưới) thì chức năng password reset vẫn hoạt động ầm ầm. Điều này cho thấy cái token chỉ để trang trí chứ chả bố con thằng nào thèm kiểm tra gì sất.

#1.2 Tấn công triệt hạ

Nhận thấy thời cơ đã đến, tôi truy cập mục tiêu bằng browser và chạy lại chức năng reset password. Sau đó túm cái POST /forgot-password?temp-forgot-password-token request mới đẩy sang Burp Suite Repeater một lần nữa.

Lần này, tôi thử chuyển username sang thành nạn nhân carlos và đặt lại password mới rồi gửi request.

Kết quả respone trả về mượt mà báo hiệu một vụ mùa bội thu nên tôi mạnh dạn xông vào vị trí login và thử lại với username carlos và password vừa mới thiết lập lại.

Và bùm chíu, account của carlos đã nằm trong bàn tay nhám nhúa của tôi.

#2 Hạ độc mục tiêu thông qua password reset link

#2.1 Thăm dò mục tiêu

Không mắc sai lầm thô thiển về mặt logic như trường hợp ở trên, ở phần này tôi chuyển sang kịch bản khi mà nạn nhân thuộc dạng “điếc không sợ súng”, bất kể ai gửi cho link gì qua email cũng click vô tội vạ.

Tương tự như mục trên, tôi cũng bật Burp Suite Intercept lên sẵn và truy cập vào vị trí login của mục tiêu. Tôi cũng kiểm tra thử chức năng reset password thông qua cái Forgot password? và sau đó điền username vào như sau.

Kế đến, tôi truy cập vào Exploit Server (được thiết lập kèm bài Lab để hỗ trợ quá trình thử nghiệm), sau đó di chuyển xuống để tìm và truy cập vào Email Client. Tại đây, tôi có thể thấy link reset password có chứa cái reset token liên quan.

Lưu ý: Ở đây tôi chỉ mới kiểm tra chức năng reset password thông qua việc sử dụng username (wiener) và email chính chủ mà tôi đã đăng ký với hệ thống (giản lược lại thành Email Client). Việc truy cập vào Email Client trên Exploit Server chỉ nhằm hỗ trợ tăng tốc quá trình demo chứ chưa có hành động xấu xa nào diễn ra cả.

Đã xác nhận cơ chế reset password, tôi quay lại cái Burp Suite History, tìm và đẩy con hàng POST /forgot-password (tương ứng cái request tôi nhập vào username và gửi đi để nhận về link reset qua email) sang Burp Suite Repeater.

Với cái request này, tôi sẽ thử nghiệm xem có thể sử dụng X-Fowarded-Host header không. Sau khi xác nhận “ăn” được với X-Fowarded-Host, tôi sẽ có thể thiết lập để trỏ reset link đến domain tùy ý (cụ thể ở đây sẽ là Exploit Server) nhằm dẫn dụ cho nạn nhân click vào rồi tuồn hàng token về.

Để làm được việc này, tôi cần truy cập lại Exploit Server để ghi nhận lại Exploit Server URL (URL: https://exploit-ac751f101fd77565c03e344901d10047.web-security-academy.net/exploit). Và sau đó cập nhật lại giá trị trương ứng cho X-Fowarded-Host header: X-Forwarded-Host: exploit-ac751f101fd77565c03e344901d10047.web-security-academy.net.

#2.2 Tấn công triệt hạ

Đã chuẩn bị xong đủ nguyên liệu, tôi quay lại chỗ Burp Suite Repeater, đổi username thành giá trị tương ứng của nạn nhân (carlos), đút cái X-Fowarded-Host đã chuẩn bị vào và Send.

Lúc này, reset password link (đã bị gài hàng với X-Forwarded-Host) sẽ được gửi đến email của nạn nhân carlos. Một khi nạn nhân vô tư click vào link thì tôi sẽ có thể truy cập Exploit Server và kiểm tra access log để tìm cái GET /forgot-password request (tương ứng với một cái IP khác biệt) chứa cái token của nạn nhân: vJPdtOkXRfzlhzfyETSaq5rMVk0dS5r6.

Quay về Email Client, tôi hốt cái password reset link chuẩn ở phần đầu ra và mông má lại bằng cách thay đổi token sang giá trị hốt được trong access log của Exploit Server:

https://ac041f3e1fcc75c1c09134b600df00a9.web-security-academy.net/forgot-password?temp-forgot-password-token=vJPdtOkXRfzlhzfyETSaq5rMVk0dS5r6

Mở lại đường link này bằng browser, tôi sẽ có thể thiết lập lại password cho account của nạn nhân carlos:

Sau đó truy cập lại trang login để tận hưởng thành quả.

 

#3 Khai thác lỗ hổng để tấn công dò tìm password

#3.1 Thăm dò mục tiêu

Với kịch bản này, tôi sẽ tận dụng lỗ hổng trong cơ chế thay đổi password để dò tìm password. Tương tự như hai phần trước, tôi cũng bật sẵn Burp Suite Intercept lên. Sau đó truy cập đến trang login và thử nghiệm chức năng Change password.

Lúc này, với việc nhập sai Current password, tôi sẽ quan sát thấy 2 tình huống:

• Nếu tôi nhập New password và Confirm new password khớp thì account sẽ bị khóa truy cập;
• Nếu tôi nhập New password và Confirm new password không khớp thì sẽ thấy thông báo lỗi “Current password is incorrect”;

 

Trong một diễn biến khác, nếu tôi nhập đúng Current password và nhập không khớp New password và Confirm new password thì sẽ nhận thông báo lỗi “New passwords do not match”. Do vậy, đây sẽ là cơ sở để tôi nhận diện khi nào mình đoán đúng Current password trong các đợt tấn công tiếp sau đây.

#3.2 Tấn công triệt hạ

Nghĩ là làm, tôi quay lại Proxy history, đẩy con hàng POST /my-account/change-password với tình huống nhập đúng Current password nhưng New password và Confirm new password không khớp sang Burp Suite Intruder.

Tại tab Positions của Burp Suite Intruder, với kiểu tấn công bắn tỉa Sniper, tôi chỉnh lại username sang thành nạn nhân carlos và đặt lại payload marker tại vị trí Current password.

Chuyển sang tab Payloads, tôi có thể sử dụng Payload type Simple list và load password list cung cấp kèm theo bài Lab.

Lưu ý: Cái password list ăn kèm theo bài Lab là để demo cho nhanh. Thực tế bạn sẽ cần bỏ công xây dựng password list như tôi giới thiệu trong nội dung Penetration Testing Step 3 – Kỹ nghệ chế biến wordlist phục vụ Password Attack.

Đồng thời, như đề cập ở trên, tôi cũng sẽ cần mở Grep – Match trong Options tab và đút vào cái error message “New passwords do not match” để dễ nhận biết công cuộc tấn công password đã thành công.

Thiết kế xong xuôi thì tôi bấm Start Attack và chờ hàng về rồi hốt cái password tương ứng (asdfgh như minh họa bên dưới).

Sau đó là thủ tục login và nhận phần thưởng.

Đến đây coi như tôi đã giới thiệu xong các chiêu trò phổ biến để tấn công vào quá trình xác thực của mục tiêu. Dù đây chỉ là những đòn cơ bản nhưng nếu biết cách kết hợp với các thủ thuật khác thì cũng sẽ có thể gây sát thương đáng kể lên mục tiêu. Nếu có thể, tôi sẽ thu xếp để demo giới thiệu chi tiết thêm các nội dung liên quan đến vấn đề này trong tương lai gần.