Brute Force Browsing

Contents

Description

Most Web browsers have a standard behavior of listening on port 80 for HTTP traffic and port 443 for HTTPS traffic.
A Web server is only supposed to access files reachable from its own document root directory.
Common Gateway Interface (CGI) is intended to allow ordinary programs to interact using a Web browser interface.
CGI interfaces are present at the core of almost all Web applications
The Web server can restrict access to a CGI to specific users but cannot limit the files that the CGI can access.
These facts lead to a set of vulnerabilities called “forceful browsing” or 'brute-force browsing“ vulnerabilities.
In these vulnerabilities, an attacker can manipulate values in the data they submit to a CGI program by way of the browser and thus force the Web server to return Web pages or other files that the attacker would be unable to access otherwise.

Guess the names of Web pages and enter them in the browser to see if they find a real page and if they can access it.
Because the only security on these pages is that they are not linked to anywhere on the site that can be seen by a regular user.

This type takes place when the attacker knows the URL already. This can be done via saved URLs where the attacker had one instance of legitimate access to the URL and now replays the URL to regain access or replay a prior transaction. If this succeeds. the attacker has carried out a session replay attack.
The root cause of this vulnerability is the lack of state HTTP and CGIs were never intended to he accessed in a stateful fashion.
Sometimes. a session variable is used to associate an authenticated user with a particular session, but these session variables can't he immediately expired by the server because any lag in the communication will cut off the legitimate user from his session.
Session variables are often stored in hidden fields in the HTML Pages of the site, or they are transmitted as art of the URL.

URLs are the most common places from which to perform forceful browsing, but it is not the only place where browsing can be accomplished. Any of the CGI parameters that are present in the fields of the HTML page (both hidden and unhidden) can he tampered with.

An attacker visits a Web site
- for example: http://www.mywebsite.html/default.html.
- When the attacker browses the site. the attacker notices that there is a pattern to the URLs being seen.
- The link titled New Member” leads to the URL http://www.mywebsite.html/newmember.html.
- The link titled “Consultants” leads to the URL http://www.mywebsite.html/consultants.html.
The attacker notices that there is no URL listed that seems to have anything to do with site administration and decides to see if he can find It.
He guesses at a couple of URLs until he happens to guess the correct URL to achieve some level of access: http://www.mywebsite.html/admin.html.

An attacker sits down at a coworker's desk after the coworker has stepped away, and the computer is left unlocked. The coworker had just shown the attacker the new item he bought at a major online retailer.
The attacker navigates to the account management page and changes coworker‘s email address and password to his own, then logs out of the online retailer's site and closes the browser before returning to his own desk.

Kerio Personal Firewall TM is a firewall for workstations. In 2003, a session replay vulnerability was reported. The vulnerability reported involved a law in the authentication when the firewall's remote administration was being used. The traffic during the session is encrypted. but if the entire administration session is captured using a network sniffer and then replayed as a whole, the server recognizes it as a valid session.
The impact of this vulnerability is that an attacker could record a session and replay it at will to cause the same administrative commands to be sent to the firewall.

Start testing for brute-force browsing vulnerabilities by mapping your site. Begin by creating a list of all the URLs that are intended to be safe and accessible to everyone, including those people who aren't logged in.
Log on to your site as an administrator and manually walk through all the pages you can access or find links to.
The next step is to log out of the site completely, and clear your browser cache and cookies. Go back to your site and try all of the URIs both from the safe list and the administrator list. Mark each of the URLs that is reachable.
Now repeat this process while logged in as a normal user. Again, mark each of the accessible pages. If there is any page that is accessible by non admininistrators and it is not on the safe list, then you have a URI–guessing security vulnerability.

Start by seeing if you can detect how your system is storing session information.
Log into the system as a regular user, and navigate to a URL that requires you to be logged into the system to access. Look at the URL that is displayed in your browser's address bar. Does it contain any parameters with names like “session” or any long strings of seemingly random letters and numbers? If either of these are true, the URL probably contains the session variable.
Now save the current page to a local file, and log out of your site. Delete your browser's cache and clear your cookies, then try opening the saved file in your browser, and click on one of the links. If you can still navigate around the site, your system may be vulnerable to a session replay attack.
Try copying the URL to a file, and close your browser. Clear your cache and cookies again. Reopen your browser and paste the URL into the address bar and see if you can access the site without logging in. If you can, you may have a session replay attack.
To verify your findings, try the same process from a different machine with the locally saved file and the URL. If you can still access the site without logging in, you have a confirmed vulnerability.