A memory error is a condition that occurs any time one or more bits being read from memory have changed state from what was previously written.  By even the most conservative of estimates Internet devices experience more than 600,000 memory errors per day.  Cosmic radiation, operating a device outside its recommended environmental conditions, and defects in manufacturing can all cause a "1" in memory to become a "0" or vice-versa.  Most of these bit errors are harmless, but occasionally the bit error occurs inside a domain name or URL, and this can affect where Internet traffic is directed.  The term "bitsquatting", which refers to the practice of registering a domain name one binary digit different than another, is a term coined after a similar term, "cybersquatting" -the practice of registering an unofficial domain which could be confused for a legitimate one.

For example, the fully qualified domain name "www.cisco.com" could by changing only a single binary digit become the bitsquat domain name "wwwncisco.com".  In this example, the dot separating the second and third level domain names has experienced a bit error, and changed to become the letter "n".

Binary representation of a dot versus the character "n"

The layout of the ASCII table dictates how characters can, by the change of a single binary digit, become different printable characters.  Below is a list of the characters commonly used in domain names/URLs along with a list of the alternate characters that might occur by changing only a single binary digit:

Possible 1-Bit Variants

Clearly, sending traffic to the wrong domain name presents problems for security.  An attacker receiving a request at a bitsquat domain can return malicious content to the client, phish for authentication credentials, capture sensitive information, etc.

Up until recently, the available countermeasures that could be deployed against bitsquatting have been few.  One way to cure the problem of single bit memory errors is to use error correcting code memory (ECC).  However, most devices manufactured today do not contain ECC memory, and it is not practical for everyone to upgrade their hardware all at once.  The second way to prevent bitsquatting is to register all the one-bit variants of your domain names.  This can be a costly way to protect your domain, depending on the quantity of domain names to be protected, and the length of each domain.

It is important to recognize that all forms of domain squatting, including bitsquatting, require DNS in order to function, and that is where the problem can be attacked -if you are willing to configure your DNS resolver toliebend the truth.

RPZ to the Rescue!
Many organizations run their own DNS resolvers to provide name translation for their users.  One of the most popular DNS server programs commonly used for this purpose is Berkeley Internet Name Domain (a.k.a. BIND).  Response Policy Zones (RPZs) have been a configuration option since BIND v9.8.1, but patches exist for earlier versions of BIND.  A RPZ is a local zone file which allow the DNS resolver to reply to specific requests by declaring that the domain name doesn't exist (NXDOMAIN), among other possibilities.  This is the power we can harness to defeat bitsquatting.

The first step on the road to eliminating the bitsquatting problem is establishing a list of the hostnames and domain names that are critical for our organization to protect.  For example imagine we have compiled the following list of our most commonly visited domains we wish to protect from bitsquatting:

www.cisco.com
blogs.cisco.com
marketplace.cisco.com
newsroom.cisco.com

Starting with this list, we can then enumerate all the domain names that are one bit different, and add them to a RPZ which is configured to return NXDOMAIN.  Here is a RPZ generated from the list above using Cisco's bitsquat RPZ generator.

We then configure our BIND server to use a response-policy using the zone file we generated.

RPZ configuration example

It's that simple.  Now, whenever someone behind the bitsquat-RPZ-protected DNS resolver tries to look up the name bisco.com because their device experienced a bit error, our DNS resolver will return a response of NXDOMAIN, whether the domain name has been registered by bitsquatters or not.

An example DNS lookup behind our RPZ

So, if it is this easy to defeat bitsquatting attacks, what is the catch?  Actually there are two downsides to this approach.

The first downside is that you can only protect the users behind your DNS resolver.  Requests for registered bitsquat domains may still return a valid IP address if users are connected to an unprotected DNS resolver.

Second is the possibility of false positives.  For example, one of the domains in our bitsquat RPZ example above is "bisco.com".  This happens to be a domain used by a legitimate company named "Bisco" that provides "ADHESIVE AND COMPOSITE TECHNOLOGY".  When deploying an RPZ, careful considerationmustbe paid to the domains that will return NXDOMAIN.

References
http://dinaburg.org/bitsquatting.html
https://deepthought.isc.org/article/AA-00525/110/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
https://alln-extcloud-storage.cisco.com/Cisco_Blogs:ciscoblogs/Schultz-Examining_the_Bitsquatting_Attack_Surface-whitepaper.pdf