About-Password cracking is the process of recovering passwords from data that has been stored in or transmitted by a computer system. - A common approach is to repeatedly try guesses for the password. ++ When developers have to build authorisation matrices into complex systems it is easy for them to miss adding the right checks in every place, especially those + which are not directly accessible through a browser, for example API calls. + -Users often choose weak passwords. Examples of insecure choices include single words found in dictionaries, family names, any too short password - (usually thought to be less than 6 or 7 characters), or predictable patterns - (e.g. alternating vowels and consonants, which is known as leetspeak, so "password" becomes "p@55w0rd"). - -Creating a targeted wordlists, which is generated towards the target, often gives the highest success rate. There are public tools out there that will create a dictionary - based on a combination of company websites, personal social networks and other common information (such as birthdays or year of graduation). - - A last resort is to try every possible password, known as a brute force attack. In theory, if there is no limit to the number of attempts, a brute force attack will always - be successful since the rules for acceptable passwords must be publicly known; but as the length of the password increases, so does the number of possible passwords - making the attack time longer. ++ As a tester, you need to be looking at every call a system makes and then testing it using every level of user to ensure that the checks are being carried out correctly. + This can often be a long and boring task, especially with a large matrix with lots of different user types, but it is critical that the testing is carried out as one missed + check could lead to an attacker gaining access to confidential data or functions. + Objective-Your goal is to get the administrator’s password by brute forcing. Bonus points for getting the other four user passwords! +Your goal is to test this user management system at all four security levels to identify any areas where authorisation checks have been missed. +The system is only designed to be accessed by the admin user, so have a look at all the calls made while logged in as the admin, and then try to reproduce them while logged in as different user. +If you need a second user, you can use gordonb / abc123.
Low Level-The developer has completely missed out any protections methods, allowing for anyone to try as many times as they wish, to login to any user without any repercussions. +Non-admin users do not have the 'Authorisation Bypass' menu option. +Spoiler: Try browsing directly to /vulnerabilities/authbypass/. +Medium Level-This stage adds a sleep on the failed login screen. This mean when you login incorrectly, there will be an extra two second wait before the page is visible. - -This will only slow down the amount of requests which can be processed a minute, making it longer to brute force. +The developer has locked down access to the HTML for the page, but have a look how the page is populated when logged in as the admin. +Spoiler: Try browsing directly to /vulnerabilities/authbypass/get_user_data.php to access the API which returns the user data for the page. High Level-There has been an "anti Cross-Site Request Forgery (CSRF) token" used. There is a old myth that this protection will stop brute force attacks. This is not the case. - This level also extends on the medium level, by waiting when there is a failed login but this time it is a random amount of time between two and four seconds. - The idea of this is to try and confuse any timing predictions. - -Using a form could have a similar effect as a CSRF token. +Both the HTML page and the API to retrieve data have been locked down, but what about updating data? You have to make sure you test every call to the site. +Spoiler: GET calls to retrieve data have been locked down but the POST to update the data has been missed, can you figure out how to call it? + +Spoiler: This is one way to do it: + +fetch('change_user_details.php', {
+method: 'POST',
+headers: {
+'Accept': 'application/json',
+'Content-Type': 'application/json'
+},
+body: JSON.stringify({ 'id':1, "first_name": "Harry", "surname": "Hacker" })
+}
+)
+.then((response) => response.json())
+.then((data) => console.log(data));
+
Impossible Level-Brute force (and user enumeration) should not be possible in the impossible level. The developer has added a "lock out" feature, where if there are five bad logins within - the last 15 minutes, the locked out user cannot log in. - -If the locked out user tries to login, even with a valid password, it will say their username or password is incorrect. This will make it impossible to know - if there is a valid account on the system, with that password, and if the account is locked. - -This can cause a "Denial of Service" (DoS), by having someone continually trying to login to someone's account. - This level would need to be extended by blacklisting the attacker (e.g. IP address, country, user-agent). ++ Hopefully on this level all the functions correctly check authorisation before allowing access to the data. + ++ There may however be some non-authorisation related issues on the page, so do not write it off as fully secure. + |
Reference:
+Reference:
+Reference:
+Reference:
++ Welcome to the user manager, please enjoy updating your user\'s details. +
+ '; $page[ 'body' ] .= " @@ -62,7 +66,6 @@ "; $page[ 'body' ] .= ' -Put rest of function here.
' . $html . ' diff --git a/vulnerabilities/authbypass/source/high.php b/vulnerabilities/authbypass/source/high.php index 40bd09f7..2479d697 100644 --- a/vulnerabilities/authbypass/source/high.php +++ b/vulnerabilities/authbypass/source/high.php @@ -1,8 +1,11 @@ diff --git a/vulnerabilities/authbypass/source/medium.php b/vulnerabilities/authbypass/source/medium.php index 0a12413d..9bebd567 100644 --- a/vulnerabilities/authbypass/source/medium.php +++ b/vulnerabilities/authbypass/source/medium.php @@ -1,6 +1,13 @@