Server-side vulnerabilities - Authentication

Bài viết gốc 

Authentication vulnerabilities

Về mặt khái niệm, lỗ hổng xác thực rất dễ hiểu. Tuy nhiên, chúng thường rất quan trọng vì mối quan hệ rõ ràng giữa xác thực và bảo mật.

Các lỗ hổng xác thực có thể cho phép kẻ tấn công truy cập vào dữ liệu và chức năng nhạy cảm. Chúng cũng tiết lộ thêm bề mặt tấn công cho các cuộc tấn công tiếp theo. Vì lý do này, việc học cách xác định và khai thác các lỗ hổng xác thực, và cách bỏ qua các biện pháp bảo vệ thông thường là rất quan trọng.

Trong phần này, chúng tôi giải thích:

• Các cơ chế xác thực phổ biến nhất được sử dụng bởi các trang web.
• Các lỗ hổng tiềm ẩn trong các cơ chế này.
• Lỗ hổng cố hữu trong các cơ chế xác thực khác nhau.
• Các lỗ hổng điển hình xuất hiện do việc triển khai không đúng cách.
• Cách bạn có thể tạo cơ chế xác thực của riêng mình mạnh mẽ nhất có thể.

What is authentication?

Xác thực là quá trình xác minh danh tính của người dùng hoặc khách hàng. Các trang web có khả năng bị lộ cho bất kỳ ai kết nối với Internet. Điều này làm cho cơ chế xác thực mạnh mẽ trở thành một phần không thể thiếu để bảo mật web hiệu quả.

Có ba loại xác thực chính:

• Thông tin nào đó bạn biết, chẳng hạn như mật khẩu hoặc câu trả lời cho câu hỏi bảo mật. Đôi khi chúng được gọi là "yếu tố kiến ​​thức".
• Thông tin nào đó bạn có, Đây là một đối tượng vật lý như điện thoại di động hoặc mã thông báo bảo mật. Đôi khi chúng được gọi là "yếu tố sở hữu".
• Điều gì đó mà bạn là hoặc làm. Ví dụ: sinh trắc học hoặc mô hình hành vi của bạn. Đôi khi chúng được gọi là "yếu tố vốn có".

Cơ chế xác thực dựa trên một loạt công nghệ để xác minh một hoặc nhiều yếu tố này.

What is the difference between authentication and authorization?

Xác thực là quá trình xác minh rằng người dùng là ai. Ủy quyền liên quan đến việc xác minh liệu người dùng có được phép làm điều gì hay không.

Ví dụ: xác thực xác định xem ai đó đang cố truy cập trang web bằng tên người dùng Carlos123 có thực sự chính là người đã tạo tài khoản hay không.

Sau khi Carlos123 được xác thực, quyền của họ sẽ xác định những gì họ được phép làm. Ví dụ: họ có thể được ủy quyền truy cập thông tin cá nhân của người dùng khác hoặc thực hiện các hành động như xóa tài khoản của người dùng khác.

How do authentication vulnerabilities arise?

Hầu hết các lỗ hổng trong cơ chế xác thực xảy ra theo một trong hai cách:

• Các cơ chế xác thực yếu vì chúng không thể bảo vệ đầy đủ trước các cuộc tấn công brute-force attacks.
• Lỗi logic hoặc mã hóa kém trong quá trình triển khai cho phép kẻ tấn công bỏ qua hoàn toàn các cơ chế xác thực. Điều này đôi khi được gọi là "xác thực bị hỏng". "broken authentication".

Trong nhiều lĩnh vực phát triển web, lỗi logic khiến trang web hoạt động không mong muốn, điều này có thể có hoặc không phải là vấn đề bảo mật. Tuy nhiên, vì xác thực rất quan trọng đối với bảo mật nên rất có thể logic xác thực bị thiếu sót sẽ khiến trang web gặp phải các vấn đề bảo mật.

What is the impact of vulnerable authentication?

Tác động của lỗ hổng xác thực có thể nghiêm trọng. Nếu kẻ tấn công bỏ qua xác thực hoặc đột nhập vào tài khoản của người dùng khác, chúng có quyền truy cập vào tất cả dữ liệu và chức năng mà tài khoản bị xâm nhập có. Nếu họ có thể xâm phạm tài khoản có đặc quyền cao, chẳng hạn như quản trị viên hệ thống, họ có thể có toàn quyền kiểm soát toàn bộ ứng dụng và có khả năng giành được quyền truy cập vào cơ sở hạ tầng nội bộ.

Ngay cả việc xâm phạm tài khoản có đặc quyền thấp vẫn có thể cấp cho kẻ tấn công quyền truy cập vào dữ liệu mà lẽ ra chúng không nên có, chẳng hạn như thông tin doanh nghiệp nhạy cảm về mặt thương mại. Ngay cả khi tài khoản không có quyền truy cập vào bất kỳ dữ liệu nhạy cảm nào, nó vẫn có thể cho phép kẻ tấn công truy cập các trang bổ sung, cung cấp thêm bề mặt tấn công. Thông thường, các cuộc tấn công có mức độ nghiêm trọng cao không thể thực hiện được từ các trang có thể truy cập công khai nhưng chúng có thể xảy ra từ một trang nội bộ.

Vulnerabilities in authentication mechanisms

Hệ thống xác thực của trang web thường bao gồm một số cơ chế riêng biệt có thể xảy ra lỗ hổng. Một số lỗ hổng có thể áp dụng được trên tất cả các bối cảnh này. Những người khác cụ thể hơn về chức năng được cung cấp.

Một số phòng thí nghiệm yêu cầu bạn liệt kê tên người dùng và mật khẩu mạnh mẽ. Để giúp bạn thực hiện quy trình này, chúng tôi cung cấp danh sách rút gọn gồm tên người dùng và mật khẩu thích hợp mà bạn nên sử dụng để giải các bài thí nghiệm.

Vulnerabilities in password-based login

Trong phần này, chúng ta sẽ xem xét kỹ hơn một số lỗ hổng phổ biến nhất xảy ra trong cơ chế đăng nhập dựa trên mật khẩu. Chúng tôi cũng sẽ đề xuất những cách mà chúng có thể bị khai thác. Thậm chí còn có một số phòng thí nghiệm tương tác để bạn có thể tự mình thử và khai thác những lỗ hổng này.

Đối với các trang web áp dụng quy trình đăng nhập dựa trên mật khẩu, người dùng có thể tự đăng ký tài khoản hoặc được quản trị viên chỉ định một tài khoản. Tài khoản này được liên kết với một tên người dùng duy nhất và một mật khẩu bí mật mà người dùng nhập vào biểu mẫu đăng nhập để xác thực chính họ.

Trong trường hợp này, việc họ biết mật khẩu bí mật được coi là bằng chứng đầy đủ về danh tính của người dùng. Do đó, tính bảo mật của trang web sẽ bị xâm phạm nếu kẻ tấn công có thể lấy hoặc đoán thông tin đăng nhập của người dùng khác.

Điều này có thể đạt được bằng nhiều cách khác nhau, như chúng ta sẽ khám phá bên dưới.

Brute-force attacks

Tấn công brute-force là khi kẻ tấn công sử dụng hệ thống thử và sai để đoán thông tin đăng nhập hợp lệ của người dùng. Các cuộc tấn công này thường được tự động hóa bằng cách sử dụng danh sách từ gồm tên người dùng và mật khẩu. Việc tự động hóa quá trình này, đặc biệt là sử dụng các công cụ chuyên dụng, có khả năng cho phép kẻ tấn công thực hiện số lượng lớn các lần thử đăng nhập ở tốc độ cao.

Brute-forcing không phải lúc nào cũng chỉ là trường hợp đoán tên người dùng và mật khẩu hoàn toàn ngẫu nhiên. Bằng cách sử dụng logic cơ bản hoặc kiến ​​thức có sẵn công khai, những kẻ tấn công có thể tinh chỉnh các cuộc tấn công brute-force để đưa ra những phỏng đoán có cơ sở hơn nhiều. Điều này làm tăng đáng kể hiệu quả của các cuộc tấn công như vậy. Các trang web dựa vào đăng nhập dựa trên mật khẩu làm phương pháp xác thực người dùng duy nhất có thể rất dễ bị tấn công nếu không triển khai biện pháp bảo vệ bạo lực đầy đủ.

Brute-forcing usernames

Usernames đặc biệt dễ đoán nếu chúng tuân theo một mẫu có thể nhận dạng được, chẳng hạn như địa chỉ email. Ví dụ: thông tin đăng nhập doanh nghiệp ở định dạng firstname.lastname@somecompany.comlà điều rất phổ biến. Tuy nhiên, ngay cả khi không có quy luật rõ ràng, đôi khi ngay cả những tài khoản có đặc quyền cao cũng được tạo bằng tên người dùng có thể dự đoán được, chẳng hạn như admin hay administrator.

Trong quá trình kiểm tra, hãy kiểm tra xem trang web có tiết lộ công khai tên người dùng tiềm năng hay không. Ví dụ: bạn có thể truy cập hồ sơ người dùng mà không cần đăng nhập không? Ngay cả khi nội dung thực tế của hồ sơ bị ẩn, tên được sử dụng trong hồ sơ đôi khi giống với tên người dùng đăng nhập. Bạn cũng nên kiểm tra phản hồi HTTP để xem có địa chỉ email nào bị tiết lộ hay không. Đôi khi, phản hồi chứa địa chỉ email của người dùng có đặc quyền cao, chẳng hạn như quản trị viên hoặc bộ phận hỗ trợ CNTT.

Brute-forcing passwords

Tương tự, mật khẩu có thể bị brute-force, với độ khó thay đổi tùy theo độ mạnh của mật khẩu. Nhiều trang web áp dụng một số hình thức chính sách mật khẩu, buộc người dùng phải tạo mật khẩu có độ khó cao, ít nhất về mặt lý thuyết, khó bị bẻ khóa hơn chỉ bằng cách sử dụng brute-force. Điều này thường liên quan đến việc tạo mật khẩu với:

• Số lượng ký tự tối thiểu
• Sự kết hợp giữa chữ thường và chữ hoa
• Ít nhất một ký tự đặc biệt

Tuy nhiên, mặc dù chỉ riêng máy tính thôi cũng khó có thể bẻ khóa mật khẩu có độ khó cao, nhưng chúng ta có thể sử dụng kiến ​​thức cơ bản về hành vi của con người để khai thác các lỗ hổng mà người dùng vô tình đưa vào hệ thống này. Thay vì tạo một mật khẩu mạnh với sự kết hợp ngẫu nhiên của các ký tự, người dùng thường lấy một mật khẩu mà họ có thể nhớ và cố gắng đặt nó sao cho phù hợp với chính sách mật khẩu. Ví dụ, nếu mypassword không được phép, người dùng có thể thử cái gì đó như Mypassword1! hoặc Myp4$$w0rd.

Trong trường hợp chính sách yêu cầu người dùng thay đổi mật khẩu thường xuyên, thông thường người dùng chỉ thực hiện những thay đổi nhỏ, có thể dự đoán được đối với mật khẩu ưa thích của họ. Ví dụ, Mypassword1! thành Mypassword1? hoặc Mypassword2!.

Kiến thức về thông tin xác thực có thể có và các mẫu có thể dự đoán được có nghĩa là các cuộc tấn công brute-force thường có thể phức tạp hơn nhiều và do đó hiệu quả hơn là chỉ lặp lại qua mọi tổ hợp ký tự có thể có.

Username enumeration

Liệt kê tên người dùng là khi kẻ tấn công có thể quan sát các thay đổi trong hành vi của trang web để xác định xem tên người dùng nhất định có hợp lệ hay không.

Việc liệt kê tên người dùng thường xảy ra trên trang đăng nhập, ví dụ: khi bạn nhập tên người dùng hợp lệ nhưng mật khẩu không chính xác hoặc trên biểu mẫu đăng ký khi bạn nhập tên người dùng đã được sử dụng. Điều này giúp giảm đáng kể thời gian và công sức cần thiết để brute-force đăng nhập vì kẻ tấn công có thể nhanh chóng tạo ra một danh sách rút gọn các tên người dùng hợp lệ.

Trong khi cố gắng để brute-force trang đăng nhập, bạn nên chú ý đến bất kỳ sự khác biệt nào về:

• Status codes: Trong một cuộc tấn công brute-force, mã trạng thái HTTP được trả về có thể giống nhau đối với phần lớn các dự đoán vì hầu hết chúng đều sai. Nếu dự đoán trả về một mã trạng thái khác thì đây là dấu hiệu rõ ràng rằng tên người dùng đã đúng. Cách tốt nhất là các trang web luôn trả về cùng một mã trạng thái bất kể kết quả ra sao, nhưng cách làm này không phải lúc nào cũng được tuân theo.
• Error messages: Đôi khi thông báo lỗi trả về sẽ khác nhau tùy thuộc vào việc cả tên người dùng VÀ mật khẩu đều sai hay chỉ sai mật khẩu. Cách tốt nhất là các trang web nên sử dụng thông báo chung, giống hệt nhau trong cả hai trường hợp, nhưng đôi khi có những lỗi đánh máy nhỏ. Chỉ cần một ký tự sai vị trí cũng khiến hai thông báo trở nên khác biệt, ngay cả trong trường hợp ký tự đó không hiển thị trên trang được hiển thị.
• Response times: Nếu hầu hết các yêu cầu được xử lý với thời gian phản hồi tương tự nhau, thì bất kỳ yêu cầu nào khác với điều này đều cho thấy rằng có điều gì đó khác biệt đang xảy ra đằng sau hậu trường. Đây là một dấu hiệu khác cho thấy tên người dùng được đoán có thể đúng. Ví dụ: một trang web chỉ có thể kiểm tra xem mật khẩu có đúng hay không nếu tên người dùng hợp lệ. Bước bổ sung này có thể làm tăng nhẹ thời gian phản hồi. Điều này có thể tinh vi, nhưng kẻ tấn công có thể làm cho sự chậm trễ này trở nên rõ ràng hơn bằng cách nhập mật khẩu quá dài khiến trang web mất nhiều thời gian hơn để xử lý.

Lab: Username enumeration via different responses

TPhòng thí nghiệm này dễ bị tấn công bằng cách liệt kê tên người dùng và tấn công brute-force mật khẩu. Nó có một tài khoản với tên người dùng và mật khẩu dễ đoán, có thể tìm thấy trong các danh sách từ sau:

• Candidate usernames
• Candidate passwords

Để giải quyết bài lab, hãy liệt kê tên người dùng hợp lệ, brute-force mật khẩu của người dùng này, sau đó truy cập trang tài khoản của họ.

ACCESS THE LAB

 Solution

Đầu tiên là đăng nhập thử để lấy api đăng nhập, sau đó sử dụng Intruder để brute-force tài khoản. Ta sẽ nhìn thấy kết quả trả về tuy tất cả status code đều là 200 nhưng Length có 1 sự thay đổi nhẹ nên biết được với username là info .

Giờ thay username là info và tiếp tục brute-force mật khẩu, sẽ nhanh chóng nhận ra mật khẩu ở đây là ginger , đăng nhập với tài khoản và mật khẩu tìm được là hoàn thành

Lab: Username enumeration via subtly different responses

Bài thực hành này có lỗ hổng nhẹ về liệt kê tên người dùng và tấn công dò mật khẩu. Nó có một tài khoản với tên người dùng và mật khẩu dễ đoán, có thể được tìm thấy trong các danh sách từ sau:

• Candidate usernames
• Candidate passwords

Để giải quyết bài lab, hãy liệt kê tên người dùng hợp lệ, brute-force mật khẩu của người dùng này, sau đó truy cập trang tài khoản của họ.

ACCESS THE LAB

 Solution

Tính dùng lại chiêu cũ thử thì có vẻ không ổn lắm vì cả status code đều giống nhau và Length thì không cố định như phần trước nữa

Do đó phải kiểm tra xem kết quả trả về có thay đổi gì không bằng cách vào cài đặt và tại mục Grep - Extract và ấn add, bôi đen đoạn text như sau:

Attack lại một lần nữa và kiểm tra, tại đây có một khác biệt cực kỳ nhỏ là một lỗi đánh máy thiếu một dấu chấm

Qua đó thì ta cũng đã xác định được username là ads rồi, cuối cùng brute-force password nữa là được.

Lab: Username enumeration via response timing

Phòng thí nghiệm này dễ bị tấn công để xác định tên người dùng thông qua thời gian phản hồi. Để giải quyết phòng thí nghiệm, hãy xác định một tên người dùng hợp lệ, tấn công mật khẩu của người dùng này, sau đó truy cập vào trang tài khoản của họ.

• Thông tin tài khoản của bạn: wiener:peter
• Candidate usernames
• Candidate passwords

ACCESS THE LAB

 Solution

Đăng nhập thử vào tài khoản cung cấp để kiểm tra đồng thời lấy api đăng nhập và gửi vào Intruder

Vẫn thử brute-force username như bình thường và chợt nhận ra có thêm 1 cơ chế bảo mật khác để ngăn chặn bute-force.

Sau một thời gian nghiên cứu thì mình phát hiện ra là có thể bypass được nếu mình giả mạo IP address thông qua header X-Forwarded-For. Không phải là tất cả các server đều thế, tuỳ vào cách code thôi.

Bây giờ ta sẽ thêm header vào request và attack lại lần nữa với cấu hình như sau

Chuyển sang tấn công kiểu PitchFork, vì có 100 mật khẩu nên ta sẽ sử dụng fake 100 IP từ 1 đến 100

để không bị chặn, mật khẩu sẽ đặt rấtttttt là dài, sau đó ấn Attack và xem kết quả

Thời gian phản hồi cao đáng ngờ thế này thì rất có thể tài khoản là auth rồi.

giờ sẽ brute-force mật khẩu với tài khoản auth.

Vậy là tìm được mật khẩu là monitor

Flawed brute-force protection

Rất có khả năng một cuộc tấn công brute-force sẽ liên quan đến nhiều lần đoán sai trước khi kẻ tấn công xâm phạm tài khoản thành công. Về mặt logic, bảo vệ brute-force xoay quanh việc cố gắng làm cho việc tự động hóa quy trình trở nên phức tạp nhất có thể và làm chậm tốc độ mà kẻ tấn công có thể thử đăng nhập. Hai cách phổ biến nhất để ngăn chặn các cuộc tấn công brute-force là:

• Khóa tài khoản mà người dùng từ xa đang cố truy cập nếu họ đăng nhập thất bại quá nhiều lần
• Chặn địa chỉ IP của người dùng từ xa nếu họ thực hiện quá nhiều lần đăng nhập liên tiếp

Cả hai phương pháp đều cung cấp các mức độ bảo vệ khác nhau, nhưng không có phương pháp nào là không thể bị xâm nhập, đặc biệt là nếu được triển khai mà sai sót về logic.

Ví dụ, bạn có thể đôi khi phát hiện rằng IP của bạn bị chặn nếu bạn không đăng nhập thành công quá nhiều lần. Trong một số cách triển khai, bộ đếm cho số lần thất bại sẽ được đặt lại nếu chủ sở hữu IP đăng nhập thành công. Điều này có nghĩa là kẻ tấn công chỉ cần đăng nhập vào tài khoản của họ sau mỗi vài lần thử để ngăn không cho giới hạn này bao giờ được đạt đến.

Trong trường hợp này, chỉ cần bao gồm thông tin đăng nhập của bạn ở các khoảng thời gian đều đặn trong danh sách từ là đủ để làm cho biện pháp phòng thủ này gần như vô ích.

Lab: Broken brute-force protection, IP block

Phòng thí nghiệm này có lỗ hổng do lỗi logic trong việc bảo vệ chống tấn công dò mật khẩu. Để giải quyết phòng thí nghiệm, hãy dùng phương pháp tấn công dò mật khẩu của nạn nhân, sau đó đăng nhập và truy cập vào trang tài khoản của họ.

• Your credentials: wiener:peter
• Victim's username: carlos
• Candidate passwords

ACCESS THE LAB

 Solution

Tìm hiểu trước về lab thì nếu đăng nhập sai quá 3 lần liên tiếp thì sẽ bị khóa chức năng đăng nhập trong 1 phút, sai 2 lần và một lần đăng nhập đúng thì bộ đếm khóa đăng nhập sẽ bị reset.

Dựa vào đó thì ta sẽ brute-force chèn tài khoản đăng nhập wiener vào trong danh sách đăng nhập ví dụ như sau:

carlos - 123456

carlos - abcxyz

wiener - peter

carlos - 123456

carlos - abcxyz

wiener - peter

Tiến hành tạo file bằng code, vì mình quen code Nodejs nên mình sẽ tạo file như sau.

Sau đó, sử dụng Intruder mode Pitchfork và tiến hành brute-force thôi.

Cấu hình thêm Maximum concurrent requests để về 1 cho chạy tuần tự

Filter username carlos và không lấy status code 2xx. ta sẽ thấy password là buster

Account locking

Một cách mà các trang web cố gắng ngăn chặn hành vi ép buộc là khóa tài khoản nếu đáp ứng một số tiêu chí đáng ngờ nhất định, thường là một số lần đăng nhập không thành công. Cũng giống như các lỗi đăng nhập thông thường, phản hồi từ máy chủ cho biết tài khoản đã bị khóa cũng có thể giúp kẻ tấn công liệt kê tên người dùng.

Lab: Username enumeration via account lock

Phòng thí nghiệm này dễ bị tấn công để lấy thông tin về tên người dùng. Nó sử dụng chức năng khóa tài khoản, nhưng chức năng này có một lỗi logic. Để giải quyết bài lab, hãy liệt kê một tên người dùng hợp lệ, tấn công mật khẩu của người dùng này bằng brute-force sau đó truy cập vào trang tài khoản của họ

• Candidate usernames
• Candidate passwords

ACCESS THE LAB

 Solution

Lab này cũng gần giống với lab trước, chỉ có điều là ta sẽ không biết user nào đúng.

Đăng nhập với username và password bất kỳ để lấy api login, sau đó gửi sang intruder.

Payload 1 để danh sách username, payload 2 để null payload và generate 5 payload, có nghĩa là gửi 5 request.

Kết quả thấy username là asia báo đăng nhập sai nhiều lần và phải đợi 1 phút để tiếp tục, dựa vào đây là ta biết được username là asia

Sử dụng mode Sniper để brute-force password với username là asia.

Lẽ ra tất cả các response đều phải thông báo đăng nhập sai nhiều lần nhưng mà tự nnhiên với mật khẩu princess lại không có thông báo đó. 

Đăng nhập tài khoản với asia/princess để kiểm tra và kết quả thành công.

Việc khóa một tài khoản cung cấp một mức độ bảo vệ nhất định chống lại việc tấn công brute-force một cách tập trung vào một tài khoản cụ thể. Tuy nhiên, phương pháp này không ngăn chặn đủ mạnh những cuộc tấn công brute-force trong đó kẻ tấn công chỉ cố gắng truy cập vào bất kỳ tài khoản ngẫu nhiên nào họ có thể.

Ví dụ: phương pháp sau đây có thể được sử dụng để giải quyết loại bảo vệ này:

1. Thiết lập danh sách tên người dùng ứng viên có khả năng hợp lệ. Điều này có thể thông qua việc liệt kê tên người dùng hoặc đơn giản dựa trên danh sách tên người dùng phổ biến.
2. Quyết định một danh sách mật khẩu rút gọn rất nhỏ mà bạn nghĩ rằng ít nhất một người dùng có thể có. Điều quan trọng là số lượng mật khẩu bạn chọn không được vượt quá số lần đăng nhập được phép. Ví dụ: nếu bạn đã tính ra giới hạn đó là 3 lần thử, bạn cần chọn tối đa 3 lần đoán mật khẩu.
3. Sử dụng một công cụ như Burp Intruder, thử từng mật khẩu đã chọn với từng tên người dùng dự kiến. Bằng cách này, bạn có thể cố gắng brute-force mọi tài khoản mà không kích hoạt khóa tài khoản. Bạn chỉ cần một người dùng sử dụng một trong ba mật khẩu để xâm phạm tài khoản.

Việc khóa tài khoản cũng không bảo vệ được chống lại các cuộc tấn công dùng danh sách lớn các cặp username:password , được tạo từ các thông tin đăng nhập thực sự đã bị đánh cắp trong các vụ vi phạm dữ liệu. Tấn công dùng danh sách này dựa vào việc nhiều người sử dụng cùng một tên người dùng và mật khẩu trên nhiều trang web khác nhau và do đó, có khả năng một số thông tin đăng nhập bị xâm phạm trong danh sách cũng hợp lệ trên trang web mục tiêu. Việc khóa tài khoản không bảo vệ được chống lại tấn công dùng danh sách vì mỗi tên người dùng chỉ bị thử một lần. Tấn công dùng danh sách đặc biệt nguy hiểm vì nó có thể dẫn đến việc kẻ tấn công xâm nhập thành công vào nhiều tài khoản khác nhau chỉ với một cuộc tấn công tự động duy nhất.

User rate limiting

Một cách khác mà các trang web cố gắng ngăn chặn các cuộc tấn công brute-force là thông qua việc giới hạn tốc độ người dùng. Trong trường hợp này, việc thực hiện quá nhiều yêu cầu đăng nhập trong một khoảng thời gian ngắn sẽ khiến địa chỉ IP của bạn bị chặn. Thông thường, IP chỉ có thể được mở chặn theo một trong những cách sau:

• Tự động sau một khoảng thời gian nhất định trôi qua
• Thủ công bởi quản trị viên
• Người dùng thực hiện thủ công sau khi hoàn tất CAPTCHA thành công

Việc giới hạn tốc độ người dùng đôi khi được ưa chuộng hơn việc khóa tài khoản do ít dễ bị liệt kê tên người dùng và tấn công từ chối dịch vụ. Tuy nhiên, nó vẫn chưa hoàn toàn an toàn. Như chúng ta đã thấy một ví dụ trong một phòng thí nghiệm trước đó, có nhiều cách mà kẻ tấn công có thể thao tác IP hiển thị của họ để vượt qua việc chặn.

Vì giới hạn dựa trên tốc độ của các yêu cầu HTTP được gửi từ địa chỉ IP của người dùng, đôi khi cũng có thể vượt qua biện pháp phòng thủ này nếu bạn có thể tìm ra cách đoán nhiều mật khẩu với một yêu cầu duy nhất.

Lab: Broken brute-force protection, multiple credentials per request

Phòng thí nghiệm này có lỗ hổng do một lỗi logic trong việc bảo vệ chống brute-force. Để giải quyết phòng thí nghiệm, hãy sử dụng brute-force để tìm mật khẩu của Carlos, sau đó truy cập vào trang tài khoản của anh ấy.

• Victim's username: carlos
• Candidate passwords

ACCESS THE LAB

 Solution

Dựa vào tên lab thì mình cũng giải quyết một cách khôn lỏi xíu thôi. Để gửi nhiều thông tin xác thực cho một request thì thường chỉ có dùng mảng.

Mình dùng code chuyển đống mật khẩu có sẵn sang dạng mảng

[

    "123456",   "password",   "12345678",   "qwerty",     "123456789",

    "12345",    "1234",       "111111",     "1234567",    "dragon",    

    "123123",   "baseball",   "abc123",     "football",   "monkey",    

    "letmein",  "shadow",     "master",     "666666",     "qwertyuiop",

    "123321",   "mustang",    "1234567890", "michael",    "654321",    

    "superman", "1qaz2wsx",   "7777777",    "121212",     "000000",    

    "qazwsx",   "123qwe",     "killer",     "trustno1",   "jordan",    

    "jennifer", "zxcvbnm",    "asdfgh",     "hunter",     "buster",    

    "soccer",   "harley",     "batman",     "andrew",     "tigger",    

    "sunshine", "iloveyou",   "2000",       "charlie",    "robert",    

    "thomas",   "hockey",     "ranger",     "daniel",     "starwars",  

    "klaster",  "112233",     "george",     "computer",   "michelle",  

    "jessica",  "pepper",     "1111",       "zxcvbn",     "555555",    

    "11111111", "131313",     "freedom",    "777777",     "pass",      

    "maggie",   "159753",     "aaaaaa",     "ginger",     "princess",  

    "joshua",   "cheese",     "amanda",     "summer",     "love",      

    "ashley",   "nicole",     "chelsea",    "biteme",     "matthew",  

    "access",   "yankees",    "987654321",  "dallas",     "austin",    

    "thunder",  "taylor",     "matrix",     "mobilemail", "mom",      

    "monitor",  "monitoring", "montana",    "moon",       "moscow"    

  ]

sau đó đăng nhập với tài khoản carlos và mật khẩu bất kỳ để lấy api đăng nhập và sau đó chuyển sang Repeater và sửa mật khẩu thành mảng vừa rồi.

Vậy là đăng nhập được, Chọn Show in browser copy url và dán vào trình duyệt để truy cập vào tài khoản carlos là hoàn thành.

Lỗi này giờ chắc chả còn nữa đâu vì mình đi làm thấy mật khẩu toàn băm hash xong mới so sánh. nên cái lab này chỉ tham khảo cho vui thôi

HTTP basic authentication

Mặc dù khá cũ, nhưng do sự đơn giản tương đối và dễ dàng triển khai nên bạn có thể thấy phương thức xác thực HTTP cơ bản được sử dụng đôi khi. Trong xác thực HTTP cơ bản, máy khách nhận được một token xác thực từ máy chủ, được xây dựng bằng cách nối tên người dùng và mật khẩu, và mã hóa nó theo Base64. Token này được lưu trữ và quản lý bởi trình duyệt, tự động được thêm vào header Authorization trong các yêu cầu tiếp theo dạng như sau:

Authorization: Basic base64(username:password)

Vì một số lý do, phương thức này nói chung không được coi là một phương thức xác thực an toàn. Đầu tiên, nó liên quan đến việc gửi đi lặp đi lặp lại thông tin đăng nhập của người dùng với mỗi yêu cầu. Trừ khi trang web cũng triển khai HSTS, thông tin đăng nhập của người dùng có thể bị bắt giữ trong một cuộc tấn công man-in-the-middle.

Ngoài ra, các cách triển khai xác thực HTTP cơ bản thường không hỗ trợ bảo vệ chống brute-force. Vì token chỉ bao gồm các giá trị tĩnh, điều này có thể khiến nó dễ bị tấn công bằng brute-force.

Xác thực HTTP cơ bản cũng đặc biệt dễ bị tấn công liên quan đến phiên làm việc, đáng chú ý là CSRF, mà nó không thể tự bảo vệ mình.

Trong một số trường hợp, việc khai thác xác thực cơ bản HTTP dễ bị tấn công chỉ có thể cấp cho kẻ tấn công quyền truy cập vào một trang có vẻ không thú vị. Tuy nhiên, ngoài việc cung cấp thêm bề mặt tấn công, thông tin xác thực bị lộ theo cách này có thể được sử dụng lại trong các bối cảnh khác, bí mật hơn.

Vulnerabilities in multi-factor authentication

Trong phần này, chúng ta sẽ xem xét một số lỗ hổng có thể xảy ra trong các cơ chế xác thực đa yếu tố. Chúng tôi cũng đã cung cấp một số phòng thí nghiệm tương tác để minh họa cách bạn có thể khai thác những lỗ hổng này trong xác thực đa yếu tố.

Nhiều trang web chỉ dựa vào xác thực một yếu tố bằng mật khẩu để xác thực người dùng. Tuy nhiên, một số trang web yêu cầu người dùng chứng minh danh tính của họ bằng nhiều yếu tố xác thực.

Việc xác minh các yếu tố sinh trắc học không thực tế đối với hầu hết các trang web. Tuy nhiên, việc sử dụng xác thực hai yếu tố (2FA) dựa trên điều bạn biết và điều bạn có ngày càng phổ biến, cả dạng bắt buộc lẫn tùy chọn. Điều này thường yêu cầu người dùng nhập cả mật khẩu truyền thống và mã xác minh tạm thời từ một thiết bị vật lý ngoại băng mà họ đang sở hữu.

Mặc dù đôi khi có thể cho một kẻ tấn công lấy được một yếu tố dựa trên kiến thức, chẳng hạn như mật khẩu, nhưng khả năng đồng thời lấy được yếu tố khác từ một nguồn ngoại băng là ít xảy ra hơn rất nhiều. Vì lý do này, xác thực hai yếu tố được chứng minh là an toàn hơn rất nhiều so với xác thực một yếu tố. Tuy nhiên, như với bất kỳ biện pháp bảo mật nào, nó chỉ an toàn đến mức cài đặt của nó. Xác thực hai yếu tố được triển khai kém có thể bị đánh bại, hoặc thậm chí bị bỏ qua hoàn toàn, giống như xác thực một yếu tố.

Cũng đáng lưu ý rằng, lợi ích đầy đủ của xác thực nhiều yếu tố chỉ được đạt được khi xác minh nhiều yếu tố khác nhau. Việc xác minh cùng một yếu tố theo hai cách khác nhau không phải là xác thực hai yếu tố thực sự. Xác thực 2FA dựa trên email là một ví dụ như vậy. Mặc dù người dùng phải cung cấp mật khẩu và mã xác minh, việc truy cập mã chỉ dựa vào việc họ biết thông tin đăng nhập cho tài khoản email của họ. Do đó, yếu tố xác thực dựa trên kiến thức chỉ đơn giản được xác minh hai lần.

Two-factor authentication tokens

Mã xác minh thường được người dùng đọc từ một loại thiết bị vật lý nào đó. Nhiều trang web có mức độ bảo mật cao hiện cung cấp cho người dùng một thiết bị chuyên dụng cho mục đích này, chẳng hạn như mã thông báo RSA hoặc thiết bị bàn phím mà bạn có thể sử dụng để truy cập ngân hàng trực tuyến hoặc máy tính xách tay làm việc của mình. Ngoài mục đích được xây dựng nhằm mục đích bảo mật, các thiết bị chuyên dụng này còn có ưu điểm là tạo mã xác minh trực tiếp. Các trang web cũng thường sử dụng ứng dụng dành riêng cho thiết bị di động, chẳng hạn như Google Authenticator, vì lý do tương tự.

Mặt khác, một số trang web gửi mã xác minh đến điện thoại di động của người dùng dưới dạng tin nhắn văn bản. Mặc dù kỹ thuật này vẫn đang xác minh yếu tố “điều bạn có”, nhưng nó có thể bị lợi dụng. Đầu tiên, mã được truyền qua SMS thay vì được tạo bởi chính thiết bị. Điều này tạo ra khả năng mã có thể bị chặn. Cũng có rủi ro về việc đổi SIM, nơi mà kẻ tấn công lừa đảo để có được một thẻ SIM với số điện thoại của nạn nhân. Kẻ tấn công sau đó sẽ nhận được tất cả các tin nhắn SMS gửi đến nạn nhân, bao gồm cả tin nhắn chứa mã xác minh của họ.

Bypassing two-factor authentication

Đôi khi, việc triển khai xác thực hai yếu tố bị lỗi đến mức nó có thể bị bỏ qua hoàn toàn.

Nếu người dùng đầu tiên được yêu cầu nhập mật khẩu, sau đó được yêu cầu nhập mã xác minh trên một trang riêng biệt, thì người dùng thực sự đang ở trong trạng thái “đã đăng nhập” trước khi họ nhập mã xác minh. Trong trường hợp này, đáng để kiểm tra xem bạn có thể trực tiếp bỏ qua đến các trang “chỉ dành cho người đã đăng nhập” sau khi hoàn thành bước xác thực đầu tiên hay không. Đôi khi, bạn sẽ thấy rằng một trang web thực sự không kiểm tra xem bạn có hoàn thành bước thứ hai trước khi tải trang hay không.

Lab: 2FA simple bypass

Xác thực hai yếu tố của lab này có thể bị vượt qua. Bạn đã có tên người dùng và mật khẩu hợp lệ, nhưng không có quyền truy cập vào mã xác minh 2FA của người dùng. Để giải quyết lab, hãy truy cập vào trang tài khoản của Carlos.

• Your credentials: wiener:peter
• Victim's credentials carlos:montoya

ACCESS THE LAB

 Solution

Truy cập kiểm tra cách hoạt động, đầu tiên là nhập tài khoản và mật khẩu xong sẽ dẫn đến trang /login2 để nhập otp, nếu nhập đúng thì sẽ dẫn đến /my-account?id=wiener như hình dưới  đây

Nhưng mà do thiếu sót logic mà đã quên mất việc người dùng hoàn toàn có thể chuyển đến trang tài khoản mà không cần xác thức otp khi nhập địa chỉ trên thanh địa chỉ trình duyệt

Đăng nhập tài khoản carlos, tại bước xác thực otp thì sửa lại địa chỉ thành /my-account?id=carlos là có thể bỏ qua bước xác thực otp.

Flawed two-factor verification logic

Đôi khi, logic không hoàn hảo trong xác thực hai yếu tố có nghĩa là sau khi người dùng đã hoàn tất bước đăng nhập ban đầu, trang web không xác minh đầy đủ rằng cùng một người dùng đang hoàn thành bước thứ hai.

Ví dụ, người dùng đăng nhập bằng thông tin đăng nhập thông thường trong bước đầu tiên như sau:

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

Họ sau đó được gán một cookie liên quan đến tài khoản của họ, trước khi được chuyển đến bước thứ hai của quá trình đăng nhập:

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

Khi gửi mã xác minh, yêu cầu sử dụng cookie này để xác định tài khoản mà người dùng đang cố gắng truy cập:

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

Trong trường hợp này, một kẻ tấn công có thể đăng nhập bằng thông tin xác thực của họ nhưng sau đó thay đổi giá trị của cookie tài khoản thành bất kỳ tên người dùng nào khi gửi mã xác minh.

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

Điều này cực kỳ nguy hiểm nếu kẻ tấn công sau đó có thể dùng phương pháp tấn công brute-force để tìm ra mã xác minh, vì nó sẽ cho phép họ đăng nhập vào tài khoản của bất kỳ người dùng nào chỉ dựa trên tên người dùng. Họ thậm chí không cần biết mật khẩu của người dùng.

Lab: 2FA broken logic

“Phương thức xác thực hai yếu tố của phòng thí nghiệm này có lỗ hổng do logic. Để giải quyết bài lab, hãy truy cập vào trang tài khoản của Carlos.

• Your credentials: wiener:peter
• Victim's username: carlos

Bạn cũng có quyền truy cập vào máy chủ email để nhận mã xác minh 2FA của mình.

ACCESS THE LAB

 Solution

Tại tab proxy, bật cái Intercept is on lên sau đó đăng nhập vào tài khoản wiener đã được cung cấp để theo dõi toàn bộ quá trình hoạt động lúc đăng nhập 

Sau khi gửi thông tin đăng nhập lên máy chủ thì sẽ nhận được chuyển hướng sang trang /login2 kèm theo cookie verify=username

Nhập otp vào và  sẽ gửi lên server kèm cookie.

Giờ làm lại và thử sửa request trước khi gửi otp lên thay cookie verify=carlos thay vì username wiener.

Không có hiện tượng gì xảy ra cả, ta cũng không nhận được cả otp, vậy là ngay sau khi đăng nhập ta sẽ được set cookie verify=username là để gửi yêu cầu tạo otp lên server cho đúng username đó. Giờ ở bước thứ 2 ta vẫn sẽ sửa verify=carlos để tạo otp cho tài khoản carlos, đến bước nhập otp nhập bừa otp vào để lấy api đăng nhập. Sau đó sẽ gửi sang tab Intruder để brute-force otp

Tiến hành thôi. Cấu hình như sau

Vậy là brute-force thành công otp là 1660. 

Giờ chọn chuột phải vào request đó và chọn Show response in browser là được.

Trong lab này lỗ hổng được thiết kế như vậy, trong thực tế cứ thử xem biết đâu lại thành công vì mình thấy dự án công ty mình cũng code vớ vẩn bỏ xừ :D

Brute-forcing 2FA verification codes

Giống như mật khẩu, các trang web cần phải thực hiện các bước để ngăn chặn việc tấn công bằng phương brute-forcing mã xác minh 2FA. Điều này đặc biệt quan trọng bởi vì mã thường chỉ là một số đơn giản gồm 4 hoặc 6 chữ số. Nếu không có sự bảo vệ chống tấn công brute-forcing, việc phá mã như vậy trở nên đơn giản.

Một số trang web cố gắng ngăn chặn điều này bằng cách tự động đăng xuất người dùng nếu họ nhập một số lượng nhất định các mã xác minh không chính xác. Điều này không hiệu quả trong thực tế vì một kẻ tấn công tiên tiến thậm chí có thể tự động hóa quy trình nhiều bước này bằng cách tạo macros cho Burp Intruder. Extension Turbo Intruder cũng có thể được sử dụng cho mục đích này.

Lab: 2FA bypass using a brute-force attack

Xác thực hai yếu tố của phòng thí nghiệm này có thể bị brute-force. Bạn đã có tên người dùng và mật khẩu hợp lệ, nhưng không có quyền truy cập vào mã xác minh 2FA của người dùng. Để giải quyết phòng thí nghiệm, hãy brute-force mã 2FA và truy cập vào trang tài khoản của Carlos.

Thông tin xác thực của nạn nhân: carlos:montoya

ACCESS THE LAB

 Solution

Đăng nhập vào tài khoản được cung cấp và nhập thử mã otp, sau khi sai 2 lần thì sẽ bị quay về trang đăng nhập, và sau đó dù ta cố dùng Repeater để gửi thêm request lần thứ 3 thì

Lần này có có thêm cả cơ chế bảo vệ brute-force bằng csrf, nhưng khi ta đăng nhập lại và thực hiện lại thì mọi thứ lại hoạt động bình thường vì khi đó đã được cung cấp csrf mới hợp lệ.

Từ đây mới có cái trò là tạo macro để thực hiện tự động việc này trước khi ta thực hiện việc gửi request xác minh otp.

Vào setting tại mục session ấn add.

 Tại cửa sổ Macro Editor thì ta thêm 3 request theo thứ tự như hình dưới, nó có nghĩa là khi macro được kích hoạt sẽ thực hiện request theo đúng thứ tự như 3 request được tạo ra.

Sau khi ấn Ok thì ấn sang tab Scope ta chọn thêm url là request post /login2, có nghĩa là trước khi api này được gọi thì sẽ kích hoạt macro trước, lấy được csrf token và dùng token đó cho api login2

gửi api /login2 sang Intruder, chọn Resource pool như hình dưới để thực hiện gửi request theo tuần tự, còn payload otp để number giống lab trước thôi.

Đợi phần này rất là lâu luôn.....

Chọn Show response in browser và lab sẽ hoàn thành.

Trong thực tế dự án của công ty mình sẽ cấp otp mới mỗi lần yêu cầu, và đếm số lần thử, nếu quá 5 lần sai liên tục sẽ khoá tài khoản. Dù sao cũng nên thử vì biết đâu không phải dự án nào cũng code cẩn thận, lab này cũng có vẻ khá thực tế.

Vulnerabilities in other authentication mechanisms

Trong phần này, chúng tôi sẽ xem xét một số chức năng bổ sung liên quan đến xác thực và minh họa cách chúng có thể bị yếu kém. Chúng tôi cũng đã tạo ra một số phòng thí nghiệm tương tác mà bạn có thể sử dụng để thực hành những gì bạn đã học.

Ngoài chức năng đăng nhập cơ bản, hầu hết các trang web cung cấp chức năng bổ sung để cho phép người dùng quản lý tài khoản của họ. Ví dụ, người dùng thường có thể thay đổi mật khẩu của họ hoặc đặt lại mật khẩu khi họ quên mật khẩu. Những cơ chế này cũng có thể giới thiệu những lỗ hổng mà kẻ tấn công có thể khai thác.

Các trang web thường chú ý tránh những lỗ hổng nổi tiếng trên trang đăng nhập của họ. Nhưng dễ dàng bỏ qua việc bạn cần thực hiện các bước tương tự để đảm bảo rằng chức năng liên quan cũng mạnh mẽ như vậy. Điều này đặc biệt quan trọng trong các trường hợp mà kẻ tấn công có thể tạo tài khoản của riêng họ và do đó, họ có quyền truy cập dễ dàng để nghiên cứu những trang bổ sung này.

Keeping users logged in

Một tính năng phổ biến là tùy chọn để vẫn đăng nhập ngay cả sau khi đóng phiên trình duyệt. Đây thường là một hộp kiểm đơn giản được gắn nhãn như "Remember me" hoặc "Keep me logged in".

Chức năng này thường được thực hiện bằng cách tạo một loại token "remember me", sau đó được lưu trữ trong một cookie. Vì sở hữu cookie này hiệu quả cho phép bạn bỏ qua quá trình đăng nhập, nên thực tế tốt nhất là cookie này không thể đoán được. Tuy nhiên, một số trang web tạo cookie này dựa trên sự kết hợp dễ đoán của các giá trị tĩnh, chẳng hạn như tên người dùng và dấu thời gian. Một số thậm chí sử dụng mật khẩu là một phần của cookie. Cách tiếp cận này đặc biệt nguy hiểm nếu kẻ tấn công có thể tạo tài khoản của riêng họ vì họ có thể nghiên cứu cookie của riêng họ và có thể suy ra cách nó được tạo ra. Một khi họ tìm ra công thức, họ có thể thử brute-force cookie của người dùng khác để truy cập vào tài khoản của họ.

Một số trang web cho rằng nếu cookie được mã hóa theo một cách nào đó, nó sẽ không thể đoán được ngay cả khi nó sử dụng các giá trị tĩnh. Mặc dù điều này có thể đúng nếu thực hiện đúng cách, nhưng “mã hóa” cookie một cách ngây thơ bằng cách sử dụng một mã hóa hai chiều đơn giản như Base64 không hề bảo vệ. Ngay cả khi sử dụng mã hóa đúng cách với một hàm băm một chiều cũng không hoàn toàn an toàn. Nếu kẻ tấn công có thể dễ dàng xác định thuật toán băm, và không sử dụng biến thể, họ có thể tiếp tục brute-force cookie bằng cách đơn giản là băm danh sách từ của họ. Phương pháp này có thể được sử dụng để vượt qua giới hạn số lần đăng nhập nếu một giới hạn tương tự không được áp dụng cho cookie.

Lab: Brute-forcing a stay-logged-in cookie

Phòng thí nghiệm này cho phép người dùng vẫn đăng nhập ngay cả sau khi họ đóng phiên trình duyệt của mình. Cookie được sử dụng để cung cấp chức năng này dễ bị brute-force.

Để giải quyết phòng thí nghiệm, hãy brute-force cookie của Carlos để truy cập vào trang “Tài khoản của tôi” của anh ấy.

• Your credentials: wiener:peter
• Victim's username: carlos
• Candidate passwords

ACCESS THE LAB

 Solution

Sau khi đăng nhập vào tài khoản và ấn duy trì đăng nhập thì ta sẽ nhận được 1 cookie tên là stay-logged-in

Coppy giá trị sang thử tab Decoder thì ta giải mã thấy như sau

tên tài khoản và 1 chuối phía sau trông khá giống md5, nên mình lên 1 trang web md5 hash online nào đó thử mã hoá peter xem có ra giống thế không.

Dự đoán chính xác luôn. 

Để kiểm chứng suy đoán cách hoạt động của cookie này thì mình đã sử dụng thêm postman để tạo request đến trang /my-account và add thêm cookie của mình vào thì kết quả hiển thị như sau

Vậy là rõ ràng không cần phải đăng nhập thì vẫn có thể truy cập nếu có cookie, giờ ta đã biết cách tạo ra cookie rồi giờ brute-force để truy cập vào tài khoản carlos thôi.

Thêm api get /my-account vào Intruder, cài đặt Payloads như sau

Sẽ dễ nhận ra nếu như tài khoản không chính xác thì sẽ bị chuyển hướng đến trang /login, còn nếu đúng sẽ hiển thị nội dung trang đó ngay.

Chọn Show response in browser và lab sẽ được hoàng thành.

Ngay cả khi kẻ tấn công không thể tạo tài khoản của riêng mình, họ vẫn có thể lợi dụng lỗ hổng này. Sử dụng các kỹ thuật thông thường như XSS, một kẻ tấn công có thể đánh cắp cookie "Remember me" của người dùng khác và suy luận cách cookie được tạo ra từ đó. Nếu trang web được xây dựng bằng một framework mã nguồn mở, thậm chí chi tiết quan trọng về cách tạo cookie có thể được công bố công khai.

Trong một số trường hợp hiếm hoi, có thể có khả năng lấy được mật khẩu thực của người dùng trong dạng văn bản thông thường từ một cookie, ngay cả khi nó được băm. Các phiên bản đã được băm của danh sách mật khẩu nổi tiếng có sẵn trực tuyến, nếu mật khẩu của người dùng xuất hiện trong một trong những danh sách này, việc giải mã hash đôi khi có thể là chuyện đơn giản chỉ bằng cách dán hash vào một công cụ tìm kiếm. Điều này thể hiện sự quan trọng của salt trong việc mã hóa hiệu quả.

Lab: Offline password cracking

Trong bài lab này, mật khẩu của người dùng được lưu trữ dưới dạng hash trong một cookie. Lab cũng chứa một lỗ hổng XSS trong chức năng bình luận. Để giải quyết bài lab, bạn cần lấy cookie stay-logged-in  của Carlos và sử dụng nó để giải mã mật khẩu của anh ấy. Sau đó, đăng nhập với tài khoản của Carlos và xóa tài khoản của anh ấy từ trang "My account".

• Thông tin đăng nhập của bạn: wiener:peter
• Tên người dùng của nạn nhân: carlos

ACCESS THE LAB

 Solution

Đầu tiên mình dạo qua 1 vòng thì chỉ có mỗi đoạn blog có phần comment, để kiểm tra xem có bị XXS không thì mình viết 1 cái script đơn giản để check

Quay lại bài viết đó thì thấy xuất hiện alert thì chứng tỏ là có lỗi xxs

Viết script để chuyển hướng đến expolit server của mình để đọc cookie của những ai truy cập vào bài viết đó. 

đương nhiên đây là lab thì nó chỉ có ra cookie của carlos thôi.

Sau khi lấy được cookie stay-login-in thì đem giải mã bên tab Decoder

mình không biết md5 kia là gì nên mình sử dụng trang crackstation để tìm thử, kết quả là onceuponatime.

Sau khi lấy được password rồi thì đăng nhập vào tài khoản của carlos và xóa tài khoản của  họ là lab hoàn thành.

Không biết giờ còn lỗi kiểu này nữa không vì XXS thường đc các framwork frontend xử lý hết rồi hay là cookie toàn là http cookie nên document.cookie không đọc được. Nói chung cũng đáng để thử vì chả biết đâu được lại còn tồn tại. Năm vừa rồi BKAV còn bị hack vì Sql injection cơ mà :))))

Resetting user passwords

Trong thực tế, việc người dùng quên mật khẩu là điều không thể tránh khỏi, nên việc cung cấp một cách để họ đặt lại mật khẩu là phổ biến. Vì xác thực dựa trên mật khẩu thông thường là không thể trong tình huống này, các trang web phải dựa vào các phương pháp thay thế để đảm bảo rằng người dùng thực sự đang đặt lại mật khẩu của họ. Vì lý do này, chức năng đặt lại mật khẩu có tính nguy hiểm và cần được triển khai một cách an toàn.

Có một số cách khác nhau mà tính năng này thường được triển khai, với các mức độ sẵn có của lỗ hổng.

Sending passwords by email

Nên hiểu rằng việc gửi mật khẩu hiện tại cho người dùng không bao giờ nên được thực hiện nếu một trang web đã xử lý mật khẩu một cách an toàn từ đầu. Thay vào đó, một số trang web tạo một mật khẩu mới và gửi nó cho người dùng qua email.

Nói chung, việc gửi mật khẩu cố định qua các kênh không an toàn nên được tránh. Trong trường hợp này, tính an toàn dựa vào mật khẩu được tạo ra sẽ hết hạn sau một khoảng thời gian ngắn, hoặc người dùng sẽ phải thay đổi mật khẩu ngay lập tức. Nếu không, phương pháp này dễ bị tấn công từ giữa đường truyền (man-in-the-middle attacks).

Email cũng thường không được coi là an toàn vì hộp thư đến là cả một không gian lưu trữ không thay đổi và thực sự không được thiết kế để lưu trữ an toàn thông tin mật. Nhiều người dùng cũng tự động đồng bộ hóa hộp thư đến của họ giữa nhiều thiết bị thông qua các kênh không an toàn.

Resetting passwords using a URL

Một phương pháp đặt lại mật khẩu mạnh mẽ hơn là gửi một URL duy nhất đến người dùng đưa họ đến trang đặt lại mật khẩu. Các triển khai ít an toàn của phương pháp này sử dụng một URL với một tham số dễ đoán để xác định tài khoản nào đang được đặt lại, ví dụ:

http://vulnerable-website.com/reset-password?user=victim-user

Trong ví dụ này, một kẻ tấn công có thể thay đổi tham số user để trỏ đến bất kỳ tên người dùng nào mà họ đã xác định. Sau đó, họ có thể đến trực tiếp trang nơi họ có thể đặt lại mật khẩu mới cho người dùng tùy ý này.

Một cách triển khai tốt hơn của quy trình này là tạo ra một mã thông báo có độ ngẫu nhiên và khó đoán, và tạo URL đặt lại dựa trên đó. Trong trường hợp tốt nhất, URL này không nên cung cấp bất kỳ gợi ý nào về việc đặt lại mật khẩu của người dùng nào.

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

Khi người dùng truy cập URL này, hệ thống nên kiểm tra xem mã thông báo này có tồn tại trên back-end và, nếu có, nó nên được sử dụng để đặt lại mật khẩu của người dùng nào. Mã thông báo này nên hết hạn sau một khoảng thời gian ngắn và bị hủy ngay sau khi mật khẩu đã được đặt lại.

Tuy nhiên, một số trang web thất bại khi không kiểm tra lại mã thông báo khi biểu mẫu đặt lại được gửi đi. Trong trường hợp này, kẻ tấn công có thể đơn giản là truy cập biểu mẫu đặt lại từ tài khoản của họ, xóa mã thông báo và tận dụng trang này để đặt lại mật khẩu cho bất kỳ người dùng tùy ý nào.

Lab: Password reset broken logic

Chức năng đặt lại mật khẩu của bài lab này có lỗ hổng. Để giải quyết bài lab, bạn cần đặt lại mật khẩu cho Carlos, sau đó đăng nhập và truy cập trang "My account".

• Your credentials: wiener:peter
• Victim's username: carlos

ACCESS THE LAB

 Solution

Lượn 1 vòng tìm hiểu thì cũng chả có gì mình bắt đầu bấm vào phần quên mật khẩu.

Đổi thử mật khẩu của tài khoản wiener trước xem cách hoạt động nó ra sao
Nhận được 1 cái email chứa link dẫn đến chức năng thay đổi mật khẩu.

Vì mình vẫn để intercept on nên bắt cái request trước khi gửi đi, nào ngờ thấy nó có kèm thêm username và password mới, mình thử đổi nó thành carlos xem sao.

Xong đăng nhập vào tài khoản carlos với pass mình vừa đổi nào ngờ được luôn.

Lab này cũng không thực tế cho lắm, chắc giờ chả còn web nào như vậy nữa rồi.

Nếu URL trong email đặt lại mật khẩu được tạo động, điều này cũng có thể là một lỗ hổng tiềm ẩn đối với password reset. Trong trường hợp này, kẻ tấn công có thể tiềm ẩn khả năng đánh cắp token của người dùng khác và sử dụng nó để thay đổi mật khẩu của họ.

Lab: Password reset poisoning via middleware

Đây là một bài lab có lỗ hổng về password reset poisoning. Người dùng carlos có thể mất cảnh giác và bấm vào bất kỳ liên kết nào trong các email mà anh ta nhận được. Để giải quyết bài lab, đăng nhập vào tài khoản của Carlos. Bạn có thể đăng nhập vào tài khoản của mình bằng thông tin đăng nhập sau: wiener:peter. Mọi email gửi đến tài khoản này có thể được đọc thông qua ứng dụng email trên máy chủ khai thác.

ACCESS THE LAB

 Solution

Lướt qua 1 vòng thì cũng có vẻ khá giống lab trước, nhưng loay hoay mãi không biết phải làm sao nữa thì mình đành phải xem gợi ý, và được hướng dẫn sử dụng header X-Forwarded-Host trong request tạo yêu cầu reset mật khẩu.

Sau đó quay theo như lab nói thì carlos sẽ tự động mở link trong mail và mình sẽ nhận được request ở server sau đó sẽ lấy được token reset mật khẩu của carlos

Tiếp tục tạo một yêu cầu reset mật khẩu của wiener nhưng thay vì sử dụng token của mình nhận được thì sẽ thay thế bằng token của carlos để đổi mật khẩu thì sẽ đổi thành công mật khẩu của carlos thôi.

Cái mình tò mò là cách mà header này hoạt động, vì sao khi thêm header vào thì lại thay được cả đường link trong email,,, mình cảm giác chỗ này cực kì vô lý và khó thuyết phục (hoặc do mình chả biết gì về nó)

Changing user passwords

Thường thì, việc thay đổi mật khẩu đòi hỏi bạn nhập mật khẩu hiện tại và sau đó nhập mật khẩu mới hai lần. Những trang này căn bản dựa vào quy trình kiểm tra tên người dùng và mật khẩu hiện tại có khớp nhau giống như trang đăng nhập thông thường. Do đó, những trang này có thể mắc phải vào những kỹ thuật tấn công tương tự.

Chức năng thay đổi mật khẩu có thể đặc biệt nguy hiểm nếu cho phép kẻ tấn công truy cập trực tiếp mà không cần đăng nhập bằng tư cách là người dùng bị hại. Ví dụ, nếu tên người dùng được cung cấp trong một trường ẩn, kẻ tấn công có thể thay đổi giá trị này trong yêu cầu để nhắm mục tiêu đến người dùng tùy ý. Điều này có thể tiềm ẩn khả năng sử dụng để liệt kê tên người dùng và thực hiện tấn công brute-force mật khẩu.

Lab: Password brute-force via password change

Chức năng thay đổi mật khẩu của bài lab này có thể bị tấn công brute-force. Để giải quyết bài lab, hãy sử dụng danh sách mật khẩu ứng cử viên để thực hiện tấn công brute-force vào tài khoản của Carlos và truy cập trang "My account".

• Thông tin xác thực của bạn: wiener:peter
• Tên người dùng của nạn nhân: carlos
• Candidate passwords

ACCESS THE LAB

 Solution

Test các trường hợp ở đây thì mình sẽ nhập sai mật khẩu, sai mật khẩu và khớp mật khẩu xác nhận, hoặc là đúng mật khẩu và không khớp xác nhận. nó sẽ trả ra các thông báo khác nhau, dưới đây mình thử không nhập đúng mật khẩu và không khớp xác nhận thì báo current password is incorrect, vậy đó chính là thứ mình cần, giờ cho vào Intruder và brute-force password thôi.

Với password là monkey thì sẽ nhận được thông báo là: New passwords do not match, cũng có nghĩa là đúng mật khẩu của carlos luôn.

Đăng nhập vào và hoàn thành thôi.

How to secure your authentication mechanisms

Trong phần này, chúng ta sẽ thảo luận về cách bạn có thể ngăn chặn một số lỗ hổng mà chúng ta đã thảo luận khỏi xảy ra trong cơ chế xác thực của bạn.

Xác thực là một chủ đề phức tạp và như chúng tôi đã thể hiện, không may mắn rằng các điểm yếu và khuyết điểm có thể xuất hiện dễ dàng. Việc mô tả mọi biện pháp có thể thực hiện để bảo vệ trang web của bạn rõ ràng không khả thi. Tuy nhiên, có một số nguyên tắc chung mà bạn luôn nên tuân thủ.

Take care with user credentials

Ngay cả những cơ chế xác thực mạnh mẽ nhất cũng trở nên vô ích nếu bạn vô tình tiết lộ một bộ thông tin đăng nhập hợp lệ cho kẻ tấn công. Không cần phải nói, bạn không nên gửi bất kỳ dữ liệu đăng nhập nào qua kết nối không được mã hóa. Mặc dù bạn có thể đã triển khai HTTPS cho các yêu cầu đăng nhập của mình, hãy đảm bảo rằng bạn thực hiện điều này bằng cách chuyển hướng bất kỳ yêu cầu HTTP nào đến HTTPS.

Bạn cũng nên kiểm tra trang web của mình để đảm bảo rằng không có tên người dùng hoặc địa chỉ email nào được tiết lộ thông qua các hồ sơ có thể truy cập công khai hoặc được phản ánh trong các phản hồi HTTP.

Don't count on users for security

Các biện pháp xác thực nghiêm ngặt thường đòi hỏi sự nỗ lực bổ sung từ phía người dùng. Tính cách con người khiến cho việc một số người dùng tìm cách tiết kiệm công sức này trở nên không thể tránh khỏi. Do đó, bạn cần áp đặt hành vi an toàn bất cứ khi nào có thể.

Một ví dụ rõ ràng nhất là triển khai một chính sách mật khẩu hiệu quả. Một số chính sách truyền thống thất bại vì người ta thường sử dụng mật khẩu dễ đoán của mình để đáp ứng chính sách. Thay vào đó, có thể hiệu quả hơn khi triển khai một công cụ kiểm tra mật khẩu đơn giản nào đó, cho phép người dùng thử nghiệm với mật khẩu và cung cấp phản hồi về độ mạnh của chúng ngay lập tức. Một ví dụ phổ biến là thư viện JavaScript zxcvbn, được phát triển bởi Dropbox. Bằng cách chỉ cho phép sử dụng mật khẩu được đánh giá cao bởi công cụ kiểm tra mật khẩu, bạn có thể thúc đẩy việc sử dụng mật khẩu an toàn hiệu quả hơn so với chính sách truyền thống.

Prevent username enumeration

Đối với kẻ tấn công, việc phá vỡ các cơ chế xác thực của bạn trở nên đáng kể dễ dàng hơn nếu bạn tiết lộ rằng một người dùng tồn tại trong hệ thống của bạn. Thậm chí còn có những tình huống cụ thể, do tính chất của trang web, thông tin về việc một người cụ thể có tài khoản là một thông tin nhạy cảm theo chính nó.

Cho dù một tên người dùng được thử nghiệm có hợp lệ hay không, việc sử dụng các thông báo lỗi giống nhau và tổng quát là quan trọng, và đảm bảo chúng thực sự giống nhau. Bạn luôn nên trả về cùng một mã trạng thái HTTP với mỗi yêu cầu đăng nhập và cuối cùng, làm cho thời gian phản hồi trong các tình huống khác nhau trở nên khó phân biệt nhau nhất có thể.

Implement robust brute-force protection

Với cách thức đơn giản của việc xây dựng một tấn công brute-force, quan trọng là đảm bảo rằng bạn thực hiện các biện pháp để ngăn chặn, hoặc ít nhất là làm gián đoạn, mọi cố gắng tấn công brute-force đăng nhập.

Một trong những phương pháp hiệu quả hơn là triển khai việc giới hạn tần suất người dùng dựa trên địa chỉ IP một cách nghiêm ngặt. Điều này nên bao gồm các biện pháp để ngăn chặn kẻ tấn công từ việc làm thay đổi địa chỉ IP hiển thị của họ. Lý tưởng nhất, bạn nên yêu cầu người dùng hoàn thành một bài kiểm tra CAPTCHA sau mỗi lần đăng nhập khi đạt đến một số lần giới hạn nhất định.

Hãy nhớ rằng điều này không đảm bảo loại bỏ hoàn toàn nguy cơ từ tấn công brute-force. Tuy nhiên, việc làm quy trình này càng phiền toái và tăng cường yếu tố thủ công làm tăng khả năng rằng bất kỳ kẻ tấn công nào có ý định sẽ từ bỏ và tìm kiếm một mục tiêu dễ dàng hơn

Triple-check your verification logic

Như đã thấy trong các bài lab của chúng tôi, rất dễ để các lỗi logic đơn giản bắt đầu xuất hiện trong mã nguồn, và trong trường hợp xác thực, chúng có thể hoàn toàn đe dọa trang web và người dùng của bạn. Kiểm tra kỹ lưỡng mọi logic xác nhận hoặc xác thực để loại bỏ các lỗ hổng là điều quan trọng tuyệt đối đối với một hệ thống xác thực mạnh mẽ. Một kiểm tra có thể được bỏ qua cuối cùng cũng không khác biệt nhiều so với không có kiểm tra nào cả.

Don't forget supplementary functionality

Hãy chắc chắn rằng bạn không chỉ tập trung vào các trang đăng nhập chính mà bỏ qua các chức năng bổ sung liên quan đến xác thực. Điều này đặc biệt quan trọng trong các trường hợp nơi kẻ tấn công có thể tự do đăng ký một tài khoản của họ và khám phá chức năng này. Hãy nhớ rằng việc đặt lại hoặc thay đổi mật khẩu cũng là một bề mặt tấn công có giá trị không kém gì cơ chế đăng nhập chính và do đó, phải được thực hiện một cách mạnh mẽ tương đương.

Implement proper multi-factor authentication

Mặc dù xác thực đa yếu tố có thể không thực tế đối với mọi trang web, khi triển khai đúng đắn, nó an toàn hơn nhiều so với việc đăng nhập chỉ dựa trên mật khẩu. Hãy nhớ rằng việc xác minh nhiều trường hợp của cùng một yếu tố không phải là xác thực đa yếu tố thực sự. Việc gửi mã xác minh qua email chủ yếu chỉ là một biến thể dài hơn của xác thực đơn yếu tố.

Xác thực hai yếu tố dựa trên SMS kỹ thuật là việc xác minh hai yếu tố (một điều bạn biết và một điều bạn có). Tuy nhiên, khả năng bị lạm dụng thông qua việc đổi SIM, ví dụ như, có nghĩa là hệ thống này có thể không đáng tin cậy.

Lý tưởng nhất, xác thực hai yếu tố nên được triển khai bằng cách sử dụng một thiết bị hoặc ứng dụng chuyên biệt tạo mã xác minh trực tiếp. Vì chúng được xây dựng với mục đích cung cấp bảo mật, chúng thường là lựa chọn an toàn hơn.

Cuối cùng, giống như với logic xác thực chính, hãy đảm bảo rằng logic trong kiểm tra 2FA của bạn là đúng để không thể dễ dàng bị bỏ qua.