Username and Password Enumeration

Within /app/models/user.rb:

						def self.authenticate(email, password)
					       	auth = nil
					       	user = find_by_email(email)
					       	# I heard something about hashing, dunno, why bother really. Nobody will get access to my stuff!
					       	if user
					       	  if user.password == password
					       	    auth = user
					       	  else
					       	   raise "Incorrect Password!"
					       	  end 
					       	else
					       	   raise "#{email} doesn't exist!"
					       	end
					       	return auth
					   end
					  

On lines 9 and 12 you'll notice that the application generates two error messages.

Within /app/controllers/sessions_controller.rb:

						  def create

						      begin
						        user = User.authenticate(params[:email], params[:password])
						      rescue Exception => e
						      end

						      if user
						        session[:user_id] = user.user_id if User.where(:user_id => user.user_id).exists?
						        redirect_to home_dashboard_index_path
						      else
						        flash[:error] = e.message
						        render "new"
						      end

						  end
					  

On line 5 you see the exception message object "e" is created. On line 11, the message is displayed.

One of these messages indicates the email address (username) doesn't exist on the system. The other indicates that the password is incorrect. Although the application will render both error messages, either one of the error messages would be harmful by itself. This type of information can be used by an attacker to harvest email addresses or usernames. Once that list is gathered, passwords can be guessed for each account. If the username being enumerated is actually an email address, a phishing campaign could ensue with emails made to look like they are originating from the vulnerable site.

Username and Password Enumeration - SOLUTION

Within /app/controllers/sessions_controller.rb

				  def create

				      begin
				        user = User.authenticate(params[:email], params[:password])
				      rescue Exception => e
				      end

				      if user
				        session[:user_id] = user.user_id if User.where(:user_id => user.user_id).exists?
				        redirect_to home_dashboard_index_path
				      else
				        flash[:error] =  "Either your username and password is incorrect" #e.message
				        render "new"
				      end

				  end
	 		  

Although this fix is neither systemic nor does it address the problematic code at its core (within the user model), it does provide a quick solution. On line 12, we comment out the "e.message code" and instead provide a very generic error message that lacks specificity on what credential was incorrectly entered.

Enter an email address that wouldn't likely exist into the login form. Analyze the result.

Can you leverage this to gain unauthorized access?

Within app/models/User.rb

				validates :password, :presence => true,
			                       :confirmation => true,
			                       :length => {:within => 6..40},
			                       :on => :create
			  

The application validates only the password length and nothing else. Developers can leverage the format option to apply a regular expression that checks the password has sufficient complexity.

Lack of Password Complexity - ATTACK

Leverage a tool such as BurpSuite's intruder to brute-force the passwords of the users. The highest privileged account that you an attacker can compromise is the admin. The password is very simple ("admin1234"), username is ("[email protected]").

Lack of Password Complexity - SOLUTION

This regular expression validates the password has the following requirements:

validates :password, :presence => true,
                      :confirmation => true,
                      :if => :password,
                      :format => {:with => /\A.*(?=.{10,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[\@\#\$\%\^\&\+\=]).*\z/}
  					
			  

I wonder how strong the administrator's password is?

Within app/models/user.rb

			  	    def self.authenticate(email, password)
			  	         auth = nil
			  	          user = find_by_email(email)
			  	          raise "#{email} doesn't exist!" if !(user)
			  	           if user.password == Digest::MD5.hexdigest(password)
			  	             auth = user
			  	           else
			  	            raise "Incorrect Password!"
			  	           end 
			  	         return auth
			  	    end
			  	

Ignore for a moment that the application actually tells you whether or not an email address exists :-). Instead, let's look at what would happen if this error message wasn't so specific. Even if the error message vulnerability was mitigated (because it indicates whether or not a user exists), there will be some variations in the application's response between a user that exists and one that does not (however so slight, considering MD5 is in use).

To understand why, let's follow the flow of this code example. Firstly, the application look for a user by email. If not found, nothing else really happens. No further processing, password comparison, etc. If a user is found, we will perform a password comparison and process as normal.

Lack of Password Complexity - SOLUTION

Within app/models/user.rb:

				 def self.authenticate(email, password)
				       user = find_by_email(email) || User.new(:password => "")
				        if Rack::Utils.secure_compare(user.password, Digest::MD5.hexdigest(password))
				          return user
				        else
				          raise "Incorrect username or password"
				        end 
				   end
			  

To mitigate this attack and shore up our weakness, we do two things. The first is to find a user by email, if they don't exist, create a new user object in memory (not in the database) and assign it a blank password value. This means, regardless of whether or not a user exists, we will have a user to perform some processing on. The next is, we take the input from the user and match it against the user object's password leveraging secure_compare. This is a function (secure_compare) used to ensure that when a comparison happens, it will always take the same amount of time.

In summary, we have ensured that regardless of whether or not a user exists, a password comparison will always occur and it will take the same amount of time to complete.

Timing is everything. Authenticating is important too.