Posts

Defensive Hacking: How to prevent a brute force attack

Your password’s never as safe as you think it is, and understanding how to protect your website will help you from becoming the next iCloud. Today I want to look at the security weaknesses that led to brute force attacks.

Most brute force attacks work by targeting a website, typically the login page, with millions of username and password combinations until a valid combination is found. The same concept can be applied to password resets, secret questions, promotional and discount codes, and/or other “secret” information used to identify a user.

To perform a brute force attack, we need to do a few things:

  • Confirm account lockout/request throttling is disabled or easy to bypass
  • Determine the format of the username
  • Create a list of potential usernames
  • Confirm which usernames are valid
  • Test passwords for each valid username

The first step is to determine if an account lockout exists. This can be done by failing the login for a user. Next we need to figure out the format of the username. These can be significantly from one site to another, but the current trend is to use an email address since it’s easy to remember and can be used for password resets.

Here is the login page on our example site that we are targeting:

The first thing to notice is that the username is an email address. If the login screen didn’t tell us that, we may have been able to figure it out by trying to register or signup for an account. It’s pretty obvious from the signup page that an email address is used for the username:

If it’s a large public site, generally people sign up with gmail, yahoo, or other well-known email domains. Unfortunately, with the rampant hacking on the internet these days, it’s fairly easy to find massive lists of email addresses from compromised databases (https://haveibeenpwned.com/), (users.tar.gz, Adobes hacked list of 135M users). For the iCloud hack, the attackers probably started with the email addresses of the celebrities they wanted to target.

Let’s say we were (HYPOTHETICALLY) targeting James Franco’s use of our site here. First, I enter jamesfranco@gmail.com and a password then click login.

No dice. However, there is an interesting error message — “jamesfranco@gmail.com doesn’t exist!”

Determining Usernames

Now that we have our first clue, the website telling us if the username is registered or not, we need to build a list of usernames. If this was a company site, determining the email format and then creating a custom list is pretty simple. Corporate email addresses generally consist of one of the following formats:

  • firstname.lastname@company.com
  • james.franco@company.com
  • firstinitiallastname@company.com
  • jfranco@company.com
  • lastnamefirstinitial@company.com
  • francoj@company.com
  • firstname@company.com
  • james@company.com

A quick google search (http://www.wordstream.com/blog/ws/2009/09/23/find-anyones-personal-email) for the email domain will generally give you one email address from which you can deduce the format from.

For our example application, we know that the domain is onemonthsimple.com (which we found in the domain and footer), so we can start there.

Guessing Accounts

Let’s guess a few accounts and see if we can find a valid username. Manually testing a few common usernames with the @onemonthsimple.com domain is our first step. Let’s try these users:

  • Joe
  • Kate
  • Brian
  • Eric
  • Kristen
  • Emily
  • Jon
  • Chris

Wow — a few of those worked. When we guess the correct username we get an error message about the password being incorrect. We have a valid username and are on our way to breaking in!

Lets review what we already know:

Usernames are email addresses. The application will tell us if the email address is valid or not. If we find a valid email address with the wrong password, an “Incorrect Password” error message is shown. Since it is a (demo) corporate HR application, we guess correctly that most users have the @onemonthsimple.com as the email. Using this, we can create or use a list of common names and try to find out more users!

Manually guessing these usernames takes awhile. In order to find as many usernames as possible, an attacker would automate the process of trying usernames and matching the error messages to determine which ones are valid.

Automating Attacks

First, we need a larger list of names. In hacker terms, these are called dictionaries or wordlists. Based on what we know about this app, we need a wordlist of first names. Let’s grab the most popular 10,000 baby names from the US census (http://www.ssa.gov/OACT/babynames/limits.html) as a starting place.

Next, we need a way to automate the login process. For this, you can either write a small custom program or use a variety of different brute force hacking tools such as brutus or hydra. For this example, let’s just write our own. All it needs to do is:

  1. Read a file of usernames line by line
  2. Send the username to the website login
  3. Review the error message to see if the user is valid or not

Here’s the code:

require "net/http"
require "uri"
uri = URI.parse("http://localhost/sessions")
http = Net::HTTP.new(uri.host, "3000")
File.open("onemonth2013-users.txt", "r").each_line do |username| # remove the newline
  username = username.chomp
  request = Net::HTTP::Post.new(uri.request_uri)  
  request.set_form_data({"email"=>username,"password"=> "n0taL1k3lyp@ssw0rd","commit"=>
"Login"})

  response = http.request(request) 
  # If response contains incorrect password then the username is valid  
  if response.body.include? "Incorrect"
    puts "Found: #{username}"
  end
end

After this tool is run, we have a list of users for the site. Next, we rerun the script, but slightly modified. For each valid user, we try thousands of different passwords until we stop seeing the “Incorrect Password” error message — then we know we have the right username and password! Game over.

Defending against brute force attacks

Brute force attacks work because developers tip their hand to attackers by revealing critical information in error messages, fail to properly enforce account lockout and password complexity, and do not implement any form of request throttling. Let’s take a look at each one of these areas and see how you can protect your site.

Leaking Information

In our example, the login page revealed if the username was invalid or not. This is how we were able to determine valid usernames. The same thing happens with the password. This problem exists all over the Internet, just try a few favorite sites (https://secure.meetup.com/login/) and use the wrong password, does the site give you any hints you can use to break in?

The best way to prevent these types of attacks is to return a consistent error message for failed logins. Don’t give hints to hackers with verbose error messages!

Also, don’t forget the password reset functionality!

Account Lockout

Now that we have fixed the error message, we still want to strengthen the login further to prevent brute force password guessing attacks. To do this, we will add an account lockout to users when they fail the login after a certain number of times. This will prevent our script from testing millions of passwords for each account. Here is how we add the account lockout in Rails when using devise (http://rubydoc.info/github/plataformatec/devise/master/Devise/Models/Lockable):

First, make sure the devise initializer is properly setup for account lockout:

config/initializers/devise.rb
# Lock account based on failed login attempts
config.lock_strategy = :failed_attempts
# Lock and unlock based on email
config.unlock_keys = [ :email ]
# Email the user the unlock link
config.unlock_strategy = :email
# Lockout the account after 5 failed logins
config.maximum_attempts = 5
# Make sure devise has:lockable set in your model:
devise :database_authenticatable, :registerable, :recoverable, :rememberable, :trackable, :validatable, :lockable

Give it a quick test and make sure accounts are getting locked out and can be reset. If you are adding this to an existing site, you may need to run a migration to add the required devise database fields.

If you are not using devise, then you can manually add a counter in the user model and increment it for each failed login during the authentication process. However, you should use devise!

Password Complexity

Next, we want to make sure the passwords are a little more complex (http://www.sans.org/security-resources/policies/general/pdf/password-protection-policy) so that user’s cannot enter in a weak password, such as “password” or “wizard1”. There are a couple ways to do this, although I personally like the “Devise Security Extension”. This gem provides the ability to configure a number of security controls around passwords, including complexity. Check out the github project for all the details:

https://github.com/phatworx/devise_security_extension

Again, without devise, a decent option is to create a regular expression and make sure that all new passwords meet the requirements. In general, I think it’s best to require at least one number and one special character, with a minimum character length of 10. Passphrases, or passwords that are more than one word are the way to go!

Throttle Requests

Finally, we want to slow down the attackers. One common way developers do this is to implement a security control called a captcha. A captcha is a special image that is intended to be easy for humans to understand, but difficult for automated tools (like our Ruby script). In general, captchas can be annoying and lead to a poor user experience. Also, there are a few tricks hackers use to get past captchas including things like optical character recognition tools, (http://www.zdnet.com/blog/security/inside-indias-captcha-solving-economy/1835), or tricking users into solving captchas.

A better solution is to add in some form of rate limiting based on IP address after a certain amount of failed login attempts. However, be careful as this could be abused by attackers to deny access to legitimate users coming from the same IP range (think your office, coffee shop, or school). Ideally, combining the rate limiting with displaying a captcha is a fairly secure way to go to stop these types of attacks.

The best Ruby gem I’ve seen for throttling requests is rack-attack (https://github.com/kickstarter/rack-attack). Rack-attack was built by Kickstarter to stop brute force attacks. Not only can rack-attack be used to protect login pages, it can be used to protect any page on your site from brute-force attacks.

With our security fixes in place, retest your site and make sure you’ve crushed these types of bugs! If only Apple had enabled these basic login controls, maybe iCloud would be a safe place to store pictures!

What is Web Security?

Key Takeaways

Web security is protecting your website from hackers before it gets broken into.

If you’re a web security expert, you have the following skills:

  • You know how to code.
  • Can review your code for vulnerabilities.
  • You help fix the vulnerabilities you find.

How to Learn Web Security Today

  1. Read about OWASP. It stands for Open Web Application Security Project. They’re an international nonprofit that puts out lots of documentation, events, news, and web security projects. This is in an effort to improve software security across the world. Start here: https://www.owasp.org/index.php/Main_Page (15 minutes).
  2. Read the OWASP Top 10 Vulnerabilities.  Here’s how to succeed in 5 minutes: browse through the list, and read it aloud. Think of it as jumping in over your head! This will plant a seed for getting you on the right path. Start here: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet (5 minutes).
  3. One Month Web Security — By the end of One Month Web Security, you will be able to review your own applications for security issues and ensure the code is properly hardened against malicious attacks. You will also be able to design new applications with security in mind. This will significantly lower the risk and cost associated with deploying new applications.

Dash vs. Monero

Dash and Monero are two cryptocurrencies with an emphasis on privacy and security.

What problem are Dash and Monero solving?

Dash and Monero are best understood in comparison to Bitcoin.

Bitcoin (BTC) is the first popularized decentralized digital currency in the World. The idea of bitcoin is peer to peer transactions without the need for a central authority, third party, or middleman. This truly revolutionizes the way we have ever thought about money.

Dash (DASH) and Monero (XMR) started in 2014 highlighting two privacy issues for Bitcoin:

  1. Bitcoin is traceable Every bitcoin transaction is recorded on a public ledger. You can’t see the sender and recipients names, but you can see their wallet addresses. So bitcoin is not fully anonymous, most people refer to Bitcoin as being pseudonymous, or mostly anonymous.
  2. Bitcoin is not fungible —

What does it mean to be ‘fungible’?

“Fungible: The property of a good or a commodity whose individual units are essentially interchangeable.”

The US dollar is mostly fungible. For example, you and I could exchange 1 US Dollar, and each dollar is equal. 1 dollar = 1 dollar.

Bitcoin is not fungible

Because Bitcoin is traceable, there have been attempts to block, or blacklist bitcoin that comes from addresses where Bitcoin has been stolen, or gained illegally.

What problem is Dash solving?

  • Dash is like bitcoin with added privacy
  • It is like bitcoin with higher security
  • It offers point-of-sale (POS) improvements to bitcoin. Point-of-sale refers to the time and place a transaction occurs.
    • The timeframe for confirmation of transactions (of bitcoin) is far too slow, rendering it an impractical option.

What solution does Dash provide?

Dash’s technology includes three innovative features:

Masternode Network

Bitcoin’s network is maintained by miners only, whereas Dash’s is multi-faceted. Other than miners, Dash also has masternodes, and a budget system. Masternodes allow for PrivateSend and InstandSend to occur.

InstantSend

InstantSend is one service Masternodes provide for the Dash network. Due to this, users have the ability to send and receive instant irreversible transactions. InstantSend is a wonderful use case for point-of-sale (POS) systems.

PrivateSend

PrivateSend is an updated version of CoinJoin. Combined inputs are seen identically from multiple users, while outputs are varying on Dash’s blockchain. This makes it nearly impossible to be tracked and traced by third parties. Fungibility is also increased due to coins being mixed with those of equal value.

What problem is Monero solving?

  • Bitcoin transactions are traceable, Monero transactions are untraceable
  • Bitcoin is not fungible, Monero is fungible
  • It is like Bitcoin with more privacy

Monero is untraceable — Every Monero transaction, by default, obfuscates sending and receiving addresses as well as transacted amounts.

It is fungible — Because it is untraceable, Monero cannot become tainted through use in previous transactions. This means Monero will always be accepted without the risk of censorship.

Monero is private — Monero is often referred to as a “privacy coin” due to it’s untraceable and fungible qualities.

How are Dash and Monero similar?

Both Dash and Monero are working to create a currency like Bitcoin, but more private.

How do they differ?

Dash

  • Dash is a fork of Bitcoin. This essentially means it was created from Bitcoin’s code but altered to enhance privacy.
  • Its privacy is optional with the option to use PrivateSend. However, Dash has a rich list, therefore not private.
  • It is essentially has a hierarchy of nodes with the Masternode Network, rendering them unequal and technically traceable as well.
  • Dash tokens aren’t fungible.
  • Dash also has a strong marketing team and has an ease-of-use approach to appeal to those new to the space.

Monero

  • Monero is not a fork of Bitcoin, or a copy of the Bitcoin source code. Monero is a fork of the CryptoNote protocol, Bytecoin.
  • It is private by default with use of a cryptographically secure system.
  • By taking advantage of a few key technologies, it is untraceable:
  • Nodes on the Monero blockchain are equal, without the ability trace transactions with multiple nodes.
  • It is fungible.
  • It is open source

Comparison Chart: Dash vs. Monero






Dash (DASH)

 Monero (XMR)Monero Logo
URL dash.org getmonero.org
What is it? An instant, private, and secure cryptocurrency An untraceable, fungible, and private cryptocurrency
Creator(s) Evan Duffield Riccardo “fluffypony” Spagni, Francisco “ArticMine” Cabañas and 5 other core team developers
Went live´ January 18, 2014 April 2014
Supply Style Inflationary Inflationary
Supply Cap 18.5 million Once 18.4 million + .3 XMR/min.
Smallest Unit 1 duff =
0.00000001 dash
1 piconero = 0.000000000001 monero
Price View price View price

Where do I buy Dash and Monero?

Both Dash and Monero are readily available on multiple exchanges.

How much does they cost?

Visit coinmarketcap or coingecko for the latest prices.

dash vs. monero: How many tokens are available?

Dash

  • The max supply of dash is 18.9 million.
  • Every 2.5 minutes a new block of dash is generated.

Stay up to date on dash’s block time.

Monero

  • The max supply of monero is 18.4 million.
    Once 18.4 million moneroj (the plural of monero is moneroj)
    is reached the inflation rate will continue at 0.3 XMR per minute,
    which is 0.87% per year.
  • Every 1-2 minutes a new block of Monero is generated.

Stay up to date on monero’s block time.

Dash vs. Monero: What can I do with them?

Dash

Dash can be used to purchase Contraband Organic Coffee, Coin Wars, and a variety of VPN Provides.

Monero

Monero can be used to purchase goods on The Kava Society, Hammock Universe, Kidsweet, a variety of VPN and online services.

Dash vs. Monero: How do I store them?

Dash

Dash can be stored on hardware wallets such as the trezor, ledger, and KeepKey support dash. It can be stored on cold wallets such as coinomi and exodus. Learn more about how to store dash.

Monero

There are no hardware wallets available supporting monero, however Ledger has listed Monero on their roadmap. It is recommended to store you monero on a cold wallet. This is an offline paper wallet which is the most secure.

The safest way to store Monero is with Monero’s full node. When you download the full node you’ll be downloading the entire history of Monero to your computer — so you’ll need at least a few gigabytes worth of disk space. Monero also offers a paper wallet storage, and a web wallet. Read more about Monero storage options on the official Monero website.

Learn more about Dash and Monero:

Dash

Monero

The Newbie Guide to Ethical Hacking

I hack websites. I’ve been doing it for a long time, across various industries, tech stacks, and programming languages. When I tell people what I do, especially those in the tech community, they often ask how I started and how can they learn more. So today, I’m going to give you a quick intro of the tools and tricks to get started with web hacking. The best way to start is to dive into the details and start using some hacking tools.

Here’s how I recommend starting:

  1. Understand the tools of the trade
  2. Understand common attacks and defenses
  3. Practice on test sites

Since we will be focusing on web hacking, a basic understanding and/or refresher may be useful. If so, check out my post on, “Understanding HTTP Basics,” then come back. Don’t worry, its pretty simple but lays the groundwork for later.

Tools of the Trade

I think anyone trying to get involved with web app security needs to know is how to use the most common web hacking tool. Most noteworthy is the proxy. Proxies let you intercept HTTP requests and responses. This allows you to fully understand how a website works and lets you uncover security issues. I wrote a post, “Web hacking Tools: Proxies,” which walks through installing and using the most common web proxy used by security people, Burp.

After you spend some time using a web proxy, it’s pretty eye-opening to see how some of your favorite sites work, under the covers at the HTTP layer. This is also super-useful during normal development to debug and troubleshoot web application problems.

Common Attacks

Next, you need to gain an understanding of the common attacks hackers use to break-in, so you can test your sites and code for these vulnerabilities. You should check out my article on the iCloud attack here. OWASP provides a list of the top 10 attacks. This is a great place to start, although I should warn you that some of them get into the weed fairly quickly. By understanding those you can review sites you build to make sure they are protected.

Practice makes perfect

Armed with your first hacking tool, the web proxy, and an understanding of common attacks, it’s time to put your newfound knowledge to the test with a few hacking challenges. There are great sites out there where you can learn and try out hacking techniques without being worried about breaking the law. These are a few of my favorites:

After you brush up on your skills, you can also take it to the next level with a few public bug bounty programs. These programs are great because they pay for you finding vulnerabilities in public websites, such as Google, Facebook, and Paypal. Make sure you read all the rules before starting:

Also, if you don’t want to deal with these companies directly, you can also join a bug bounty program through a dedicated bug bounty company. These work with various businesses to test security using a pool of freelance hackers, including you! These two are the best:

How Olivia Munn’s Apple iCloud Account Got Hacked

Recently hundreds of celebrity’s private photos (including XXX photos) were leaked on the internet by unknown attackers from Apple’s iCloud. We’re interested in understanding how this happened and how we can help prevent it in the future. What weakness in Apple’s security allowed for this attack to take place?

Here is what we know:

How can we make sure our sites are not susceptible to the same types of attack?

Strong defensive programming techniques and basic web application security knowledge would have prevented this type of attack. Let’s take a deeper look at how these “brute-force” attacks work.

So what is a brute force attack?

Most brute force attacks work by targeting a website, typically the login page, with millions of username and password combinations until a valid combination is found. The same concept can be applied to password reset secret question, promo or discount codes, or other “secret” information used to identify a user.

Let’s look at a real example to understand how this works. Getting past the login screen is often the first step to breaking into most websites. But without a username and password, how can you possibly get in?

Since a python proof of concept attack script was released on github, we can take a look through the code and get a better understanding of how this attack works. The code can be found here: https://github.com/hackappcom/ibrute

First, the code reads passwords and emails from two different files. For the type of targeted attacks that were performed against celebrities such as Olivia Munn, the attacker already knew their valid email address. Emails are loaded into a variable called “apple_ids”. Loading these values can be seen on line 79 and 83:

Next, for each apple_id (email address), the script tries each password and calls the “TryPass” method, shown below on line 98.

Take a minute to read over the following code snippet that actually sends the request:

On line 39, the target URL is constructed by placing the apple_id in the URL. Next, a user-agent header is added and a json object is constructed. Presumably this information was reverse-engineering the researchers sniffing the FindMyiPhone http traffic.

Finally, the email and password value are joined together and base64 encoded into an authorization header on line 64:

It’s interesting to note that the API is using “Basic” authentication, which has a number of known security weaknesses, including the inability to perform account lockouts.

Finally, the request is sent and based on the server response, one can tell if the email and password combination is valid. This is sent for each email address, going through each password, then moving to the next email address and repeating the process. Given a long enough password list, eventually the attacker will discover the right password.

After collecting valid passwords, the attacker was able to download the iCloud backup for the user.

Apple has since closed the security bug.

In my next post, I’ll show you how to find and fix these types of security holes in your own applications.

Have any of your accounts or websites ever been hacked? Let me know what happened in the comments below!