NỘI DUNG
Tiếp theo nội dung Penetration Testing Step 3 – Tấn công vào Authentication mechanisms liệu có khả thi?, kỳ này tôi sẽ bắt tay vô phần múa lửa minh họa để làm rõ các ý tưởng đã giới thiệu trước đó. Cụ thể, nội dung hôm nay sẽ tập trung vào phần tấn công vào các lỗ hổng thuộc kiểu Password-based login của cơ chế xác thực.
Lưu ý:
- Tương tự như nội dung với SQL Injection attack, 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. Và trong nội dung demo hôm nay, các wordlists chứa username và password cũng sẽ được cung cấp kèm theo bài Lab để đơn giản hóa quá trình tấn công;
- 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. Brute-force attacks liệu có dễ ăn?
Để tấn công vào Password-based login trong cơ chế xác thực, phương án dễ hình dung nhất là Brute-force attack. Cụ thể, với phương án này, nhiệm vụ của bạn “đơn giản” chỉ là thử nghiệm đoán mò user credentials cho đến khi xì rùa vớ bẫm được một cái credential chính chủ để đăng nhập vào hệ thống.
Với ý tưởng này, bạn sẽ cần chuẩn bị sẵn trong tay wordlists – danh sách các từ là ứng cử viên cho username và password để thử nghiệm. Ngoài ra, kể cả khi không có cơ chế bảo vệ (ví dụ khóa đăng nhập khi nhập credential sai quá nhiều lần), quá trình Brute-force cũng sẽ tiêu tốn rất nhiều thời gian nên bạn đừng nghĩ tới chuyện nhập thủ công từng cặp username/password vào vị trí đăng nhập. Thay vào đó, bạn có thể xem xét sử dụng các công cụ hỗ trợ để tự động hóa quá trình này (ví dụ như Burp Suite Intruder).
Hiển nhiên, công cụ cũng chỉ có tác dụng trợ giúp. Nếu cái wordlists của bạn có chất lượng như sh*t thì có khi đến đời cháu chắt của bạn cũng chưa đâm thủng được hệ thống phòng thủ. Để tăng mức độ sát thương, thực tế bạn sẽ cần đầu tư khá nhiều thời gian để do thám và phân tích mục tiêu nhằm tăng chất lượng cho các từ được đưa vào wordlist.
#1.1 Brute-force usernames
Với username, tình hình thường dễ ăn hơn so với password. Bạn có thể dễ dàng húp được cái email address của nạn nhân và xem xét các phương án định dạng của username để thử nghiệm (hoặc cắn thử mấy cái username có máu mặt như admin/admistrator).
Ngoài ra, bạn cũng có thể kiểm tra các nguồn tin công khai liên quan để xem có vô tình thu lượm được thông tin của các user hớ hênh hay không trước khi bò vào la liếm ở vùng truy cập không cần đăng nhập của mục tiêu nhằm kiếm chác thêm.
#1.2 Brute-force passwords
Đến thằng password, công việc sẽ phức tạp hơn khá nhiều, đặc biệt là đối với các mục tiêu có yêu cầu cao về độ mạnh của password ví dụ như quy định số ký tự tối thiểu, phối trộn của chữ hoa, chữ thường và ký tự đặc biệt.
Khi gặp các mục tiêu khó nhằn kiểu này, công tác thăm dò, thu thập thông tin và quá trình phân tích đánh giá kết hợp với các tool hỗ trợ sẽ giúp bạn để giảm thiểu khối lượng công việc khổng lồ.
#2. Thử nghiệm thăm dò username và tấn công password dựa vào nguyên lý brute-force
Việc thăm dò username sẽ khả thi nếu mục tiêu có các phản hồi khác nhau khi bạn đút vào username hàng chuẩn và khi đút vào hàng fake. Quá trình này thường dựa vào các yếu tố như:
- Status code: Dựa vào HTTP status code của response trả về để xác định credentials đưa vào là real/fake;
- Error messages: Khi hệ thống xử lý tốt hơn, bạn sẽ khó lòng nhận được câu trả lời rõ ràng thông qua status code. Lúc này sự sai khác của Error message với tính đúng đắn của credentials đưa vào sẽ giúp bạn có câu trả lời cần thiết;
- Response time: Với trường hợp Error message được xử lý chuẩn (tức là không cho bạn biết cụ thể là sai username hay password) thì bạn sẽ có thể dựa vào thông tin thời gian phản hồi của ứng dụng để xác định kết quả thử nghiệm.
#2.1 Tấn công mục tiêu dựa vào các response khác nhau
Sau khi bật Burp Suite, việc đầu tiên tôi làm hiển nhiên là quất thử một phát credentials với vẩn vào vị trí đăng nhập.

Chuyển qua HTTP history của Proxy, tôi túm các login request ném qua Burp Suite Intruder.

Tại tab Positions, tôi có thể chơi kiểu bắn tỉa Sniper, thiết lập lại payload marker chỗ username (dùng Add §).

Sau đó chuyển qua tab Payload với tùy chọn Simple list, tôi hốt cái wordlist usename tiềm năng đút vào rồi Start attack.

Sau đó, tôi quan sát cột Length trong Result để túm thằng to bự nhất và lưu ý cái thông báo “Incorrect password” (thay vì “Invalid username”) trong response.

Như vậy, tôi đã xác định được một cái username chuẩn cmn mực: “agent”. Công việc kế tiếp là cập nhật lại giá trị username trong tab Position và chuyển payload marker vô vị trí password.

Sau đó chuyển qua tab Payloads để đưa wordlist tiềm năng của password vào rồi Start attack.

Với đợt tấn công này, tôi sẽ tập trung vào cột Status và tìm thằng nào có giá trị 302 thay vì 200.

Với kết quả trên, tôi đọc được password là 111111 và có thể nhảy qua vị trí login thử hàng ngay.

#2.2 Tấn công mục tiêu dựa vào các sai khác nhỏ trong response
Tương tự như ở trên, tôi cũng sẽ thực hiện phần login với credential vớ vẩn rồi đấy cái request đó sang Burp Suite Intruder. Tại tab Positions, tôi cũng sẽ chiến với Attack type Sniper và đánh dấu payload marker vào chỗ username.

Sau đó tôi chuyển sang tab Payloads để đưa wordlist chứa các username tiềm năng vào.

Với trường hợp này, để tiện bề chấm mút, tôi sẽ cần chuyển sang tab Options và thiết lập thêm cho phần Grep – Extract.

Cụ thể, tôi sẽ chọn Add sau đó mò mẫn phần respone để dò tìm và chọn chỗ thông báo “Invalid username or password”. Sau khi chọn, Burp Suite sẽ tự thiết lập điểm bắt đầu và kết thúc liên quan của expression.

Kết quả thiết lập sẽ kiểu tương tự như sau:

Đến đây coi như đã việc bày binh bố trận xong nên tôi có để bắt đầu khai hỏa tấn công với Start attack.
Với thiết lập Grep – Extract ở trên, tôi sẽ có thêm một cột thông tin (warning). Và ở trường hợp này, tôi cần căng mắt ra soi kèo để phát hiện ra có một dòng “Invalid username or password” bất thường khi nó không kết thúc bằng dấu “.” như những thằng khác. Đây là dấu hiệu cho biết cái username tôi đang tìm kiếm khả năng cao sẽ nằm ở đây (là cái username “ai” bên dưới).

Công việc kế tiếp không có gì mới. Tôi sẽ cập nhật lại thông tin username vừa tìm được, đổi cái payload marker qua cho password.

Sau đó cập nhật wordlist cho password rồi lại xả đạn.

Và thu lượm kết quả dựa vào cột Status.

Sau đó đẩy hàng sang vị trí login để test.

#2.3 Tấn công mục tiêu dựa vào response timing – thời gian phản hồi.
Với trường hợp tấn công dựa vào respone timing, tôi cũng sẽ cần thử nghiệm ở vị trí login trước. Ở đây, độ khó sẽ tăng lên thêm một tí vì tôi sẽ bị khóa truy cập 30 phút khi thử credential bẩn bựa quá nhiều lần.

Để xử lý, tôi sẽ cần đẩy cái request thử nghiệm qua Burp Suite Repeater cái đã.

Liên quan đến vấn đề bị block IP khi đăng nhập sai quá nhiều lần. Tôi có thể thử nghiệm một phương án chữa cháy để thoát khỏi gông cùm của việc khóa IP là sử dụng X-Forwarded-For header trong request kiểu như sau.

Sau khi triệt tiêu được giải pháp block dựa trên IP của mục tiêu, tôi tiếp tục sự nghiệm đâm thọc thử nghiệm. Cụ thể, tôi sẽ thử nghiệm với các username vớ vẩn và một username có thật (“wiener” như trường hợp bên dưới) để quan sát thời gian phản hồi. Lúc này, đám username đểu gần như sẽ có thời gian phản hồi giống nhau. Và với cái username thật, thời gian xử lý sẽ gia tăng theo độ dài của cái password mà tôi đút vào. Điều này cho tôi cơ sở để xác định được đâu là username có tồn tại trong hệ thống, đâu là hàng fake.

Lưu ý:
- Trong bài demo này, tôi chơi cheat code bốc ra cái username wiener dùng ngay luôn cho nhanh gọn. Trên thực tế, cái username này sẽ là kết quả của quá trình thiết lập, thu thập, gạ gẫm hay thậm chí lừa lọc chứ không phải tự nhiên mà có;
- Bạn cũng có thể thắc mắc là đã có username chuẩn ở trên rồi sao không xài luôn đi mà còn bày vẽ dò tìm username thêm làm gì nữa cha? Bạn nghĩ thế không sai. Nhưng cần lưu ý sẽ có tình huống bạn có quyền truy cập vào một hệ thống thông qua bước đăng ký tài khoản đăng nhập. Nhưng bạn vẫn có dã tâm muốn chiếm đoạt tài khoản của các người dùng khác hay thậm chí là của nhân vật quyền lực – administrator.
Quay lại vấn đề chính, sau khi đã xác định được cơ sở dò tìm username, tôi sẽ đẩy hàng qua Burp Suite Intruder và chiến đấu với Attack type là Pitchpork tại tab Positions.
Tại đây, tôi cũng cần xóa thiết lập mặt định và đặt lại payload marker tại vị trí của X-Forwarded-For và username như sau.

Lưu ý :
- Bạn có thể xem thêm thông tin liên quan đến Pitchfork Attack type trong nội dung Penetration Testing Step 3 – Dò tìm password của phpMyAdmin với Pitchfork attack của Burp Suite Intruder;
- Phần password tôi đang để dài đến vô lý nhằm mục tiêu dễ dàng ghi nhận được sự sai khác trong response time.
Chuyển qua tab Payloads, tôi sẽ thiết lập Payload set 1 tương ứng với X-Forwarded-For dạng Numbers kiểu như sau.

Và thiết lập Payload set 2 tương ứng với đám username như đã làm trước đó và sau đó Start attack.

Lần này, để thuận lợi trong việc đọc kết quả, tôi sẽ cần mở Columns menu và chọn thêm 2 thằng Response received và Response completed.

Dựa vào cột thông tin bổ sung này, tôi có thể nhanh chóng xác định kết quả có thời gian xử lý cao bất thường để túm ra cái username cần tìm trong tình huống này là “puppet”.

Công việc còn lại cũng sẽ tương tự. Lần này tôi sẽ thiết lập 2 payload là X-Forwarded-For và password.



Với lần tấn công này tôi sẽ soi kèo dựa vào status và bóc thằng có code 302 để đọc password dò tìm được (“112233”).

Và sau đó tận hưởng hương vị chiến thắng với cái username và password vừa tìm được.

Đọc đến đây tôi nghĩ khả năng cao bạn sẽ phọt ra cái suy nghĩ kiểu như “Cái username wordlist đút với mấy phần demo tấn công ở trên thì có thể gượng ép chấp nhận được. Nhưng còn cái password wordlist có sẵn thì trông ảo ma quá”. Bạn nghĩ thế là đúng đấy. Thực tế xử lý tốt cái password wordlist là cả một trời nghệ thuật chứ không phải chuyện đùa. Tôi sẽ sắp xếp giới thiệu về cái nội dung này ngay trong kỳ tới luôn cho máu lửa.
2 thoughts on “Penetration Testing Step 3 – Password attack bắt đầu từ đâu?”