Multifaceted Tests : Modifying Host Headers & Brute-Force Guessing Usernames and Passwords

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

1. Modifying Host Headers

1.1. Problem

Application servers frequently listen on multiple ports for different purposes. For example, JBoss listens on one port for regular requests and exposes the JMX console on a separate port for administration purposes. Even if the administration port is blocked by a firewall, an external user could still gain access to it by modifying the Host header in a HTTP request. If your application server is not configured correctly, an attacker can use this technique to gain access to the application server’s administrative functionality.

1.2. Solution

WebScarab can be used to modify HTTP headers in requests. Turn on WebScarab and set it to intercept requests. Then, initiate a connection to the target by entering a URL such as in your web browser’s address bar.

When WebScarab intercepts the request, modify the port in the Host header to the target application server’s administration port and submit the request (i.e., modify the Host header to something like Some common application servers and their default administration port numbers are listed in Table 1.

Table 1. Default administration ports in common application servers
Application serverAdministration port
Adobe JRun8000
Apache Geronimo8080
BEA WebLogic7001
IBM WebSphere 6.0.x9060, 9043
IBM WebSphere 5.19090, 9043
IBM WebSphere 4.0.x9090
Oracle OC4J23791
RedHat JBoss8080

If, as a result, your browser displays the application server’s administration page, the deployed application fails this test. If you get an error page stating that the request was invalid or if you get the same response as when you do not modify the host header, then the application passes this test.

1.3. Discussion

This attack works because the application server is not aware of the network-layer port used to submit any particular request. Once it receives a request, it uses the supplied Host header to determine how to service the request.

Of course, this can expose sensitive functionality to attackers. The JBoss JMX console, for example, allows the user to display the JNDI tree, generate a thread dump, display memory pool usage, manage the deployment scanner, redeploy an application, and shut down JBoss. By default, this functionality is wide open; however, it can be secured such that the user needs to authenticate before the application server will allow her to access the functionality.

Note that even if authentication is required to access the administration console, it may not be secure. In many application servers, there are documented default usernames and passwords for administration that should be tried when performing these tests.


This test should be executed in your operational environment or on staging servers that replicate the production environment’s configuration. This is a configuration issue that needs to be addressed during deployment, and so testing servers in the development or QA environments will not provide accurate results for the production environment.

2. Brute-Force Guessing Usernames and Passwords

2.1. Problem

Unless an application contains account lockout functionality, an attacker can attempt to log in by brute-force guessing common usernames and passwords. This typically involves brute-force guessing to find a list of valid usernames and then attempting to brute-force passwords.

2.2. Solution

The goal is to test whether an attacker can obtain some valid usernames in the application and whether he can continually guess passwords until he gets one right. Attempt the following to determine whether the application intentionally or unintentionally reveals usernames:

  • Attempt to log in with a username that does not exist. Then, attempt to log in with a username that does exist, but enter an incorrect password. If the application’s response in the two cases is different, then the attacker can enumerate usernames in the system.

  • If the application implements password reset functionality for users that forget their passwords, determine how the password reset functionality works. Does it require the user to enter a username? If so, determine whether the application responds differently depending on whether a valid or invalid username is entered.

  • Some applications contain functionality to allow users to sign up for accounts themselves. Since usernames need to be unique, the application will indicate to the end user whether the username that she is trying to sign up for already exists. This functionality could be exploited by an attacker to enumerate usernames. Determine whether the application contains such functionality.

If in any of these tests the application allows the attacker to determine valid usernames, the application fails this part of the test. This may or may not be of interest in your particular application. However, if the next test fails, then the failure will definitely be of interest.

The next step is determining whether the application allows brute-forcing passwords. Even if the attacker cannot conclusively get a valid list of usernames, he could still attempt to brute-force passwords for common usernames that may or may not be valid in the application (e.g., jsmith). Attempt one of the following depending on your circumstances:

  • If there is a requirement concerning account lockout functionality, test it by entering an incorrect password for a valid username several times (as dictated by the requirement) and determine whether the account is locked out by entering the same username with the corresponding valid password. Also, if the account is locked out, determine whether the application provides the same response regardless of whether the entered password is correct. If after account lockout it provides different responses depending on whether the password is correct or not, the attacker can still brute-force the password. However, he will not be able to actually log in until the account is unlocked.

  • If there is no requirement concerning account lockout functionality, determine whether account lockouts are enforced by entering an incorrect password for a valid user account a number of times (10 to 15 times should be sufficient). Then, enter the valid password and see if the account is locked out. As in the previous test, even if the account is locked out, determine whether the application’s response is different depending on whether the entered password is correct or not.

The application fails this test if it either does not enforce account lockout functionality, or locks out accounts and then provides different responses depending on whether the entered password is correct or not.

2.3. Discussion

Usernames and passwords are frequently brute-forceable even in the presence of account lockout functionality or other mitigating measures. Applications often try to be helpful and provide different error messages to users depending on whether the supplied username is incorrect or the supplied password is incorrect. This is often true even after an account gets locked out. The authors have seen an application that displayed error messages similar to the following. If the username was incorrect, the application stated that “The username or password is incorrect”; if the password was incorrect, the user would get the message “The user could not be authenticated”; if the account was locked out and the password was correct, the user would get a message stating “Your account has been locked out.” This provides an easy way to brute-force usernames and passwords.

In the earlier example, an attacker could enumerate usernames by entering different values and recording whether the application stated that “The username or password is incorrect” or “The user could not be authenticated.” The attacker could then brute-force the password by waiting to either get logged in or get the message “Your account has been locked out.” Even if the attacker locks out an account while brute-forcing, he will just need to wait until the account is unlocked before accessing it. Many applications unlock accounts automatically after a predetermined amount of time.

Note that it is typically easy for attackers to guess at least a small number of usernames and passwords in most systems. This is because usernames tend to be predictable, and many users tend to choose very weak passwords.

Guessing Usernames and Passwords

There are several ways in which an attacker could get valid usernames depending on the application. Many systems contain usernames that are essentially public or that can be easily obtained (e.g., performing a Google search for “” reveals a large number of valid Google user accounts). In other cases, the application may leak information during log in, password reset, or account signup.

An attacker can guess usernames by getting a list of common names and then generating usernames from them. In the United States, the Census Bureau publishes lists of the most common first and last names. According to the results from the 1990 Census, jsmith and msmith are probably the most common usernames since Smith was the most popular last name, James and John were the most popular first names for males, and Mary was the most popular first name for females.[9]

Additionally, studies have shown that a significant number of users choose common weak passwords such as “123,” “password,” “qwerty,” “letmein,” “monkey,” and their own first names.

  •  Multifaceted Tests : Bypassing Field Length Restrictions & Attempting Cross-Site Tracing Interactively
  •  Multifaceted Tests : Making HTTP Requests Using XSS & Attempting DOM-Based XSS Interactively
  •  Multifaceted Tests : Stealing Cookies Using XSS & Creating Overlays Using XSS
  •  IIS 7.0 : Securing Configuration - Controlling Configuration Delegation
  •  IIS 7.0 : Securing Configuration - Securing Sensitive Configuration
  •  IIS 7.0 : Securing Configuration - Restricting Access to Configuration
  •  Web Security Testing : Changing Sessions to Evade Restrictions & Impersonating Another User
  •  Web Security Testing : Manipulating Sessions - Analyzing Session Randomness with WebScarab
  •  Web Security Testing : Manipulating Sessions - Analyzing Session Identifiers with Burp
  •  Programming .NET Security : Extending the .NET Framework (part 2) - Defining the Key Exchange Deformatter
    Top 10
    Free Mobile And Desktop Apps For Accessing Restricted Websites
    MASERATI QUATTROPORTE; DIESEL : Lure of Italian limos
    TOYOTA CAMRY 2; 2.5 : Camry now more comely
    KIA SORENTO 2.2CRDi : Fuel-sipping slugger
    How To Setup, Password Protect & Encrypt Wireless Internet Connection
    Emulate And Run iPad Apps On Windows, Mac OS X & Linux With iPadian
    Backup & Restore Game Progress From Any Game With SaveGameProgress
    Generate A Facebook Timeline Cover Using A Free App
    New App for Women ‘Remix’ Offers Fashion Advice & Style Tips
    SG50 Ferrari F12berlinetta : Prancing Horse for Lion City's 50th
    - Messages forwarded by Outlook rule go nowhere
    - Create and Deploy Windows 7 Image
    - How do I check to see if my exchange 2003 is an open relay? (not using a open relay tester tool online, but on the console)
    - Creating and using an unencrypted cookie in ASP.NET
    - Directories
    - Poor Performance on Sharepoint 2010 Server
    - SBS 2008 ~ The e-mail alias already exists...
    - Public to Private IP - DNS Changes
    - Send Email from Winform application
    - How to create a .mdb file from ms sql server database.......
    programming4us programming4us