First off, sorry for the delay with writing this – been distracted with lots of IRL stuff and it took me over a month to actually get around to posting this (even though it was pretty much written a month ago). I’ll be updating this blog a lot more regularly from here onwards.
My last three posts have been the results of my findings testing against sites in the wild, this post will differ in the sense that it is more of a short tutorial.
NOTE: this is supposed to be a basic tutorial for beginners who may not already know of these methods, so apologies if you were expecting to learn something new.
In my previous post I demonstrated the steps required to setup a spear phishing attack using WebHTTrack – in this post I am going to discuss some of the more obscure and sophisticated methods of phishing which are less well known to those new to the infosec community.
I won’t bother going into methods such as spear phishing or typosquatting too much, and the main methods that I will be covering are bitsquatting, LAN-based phishing and IDN Homograph attacks.
While methods such as typosquatting rely upon human error (for example a user hitting the wrong key while entering their URL of choice), bitsquatting instead relies upon machine error.
To fully understand the concept of bitsquatting, you must first understand the concept of bit errors – when bits are transmitted across a data stream, there is a slim chance that the content of the devices memory can be altered (by a single bit), the factors that cause this to happen can vary, but they include interference, bit synchronization errors, faults within memory modules, distortions, etc.
Let me use an example to demonstrate this:
take the following domain example.com
here is the binary representation of example.com:
01100101 00100000 01111000 00100000 01100001 00100000 01101101 00100000 01110000 00100000 01101100 00100000 01100101 00100000 00101110 00100000 01100011 00100000 01101111 00100000 01101101
lets assume that a bit error takes place, and the last bit of the 9th byte is flipped:
01100101 00100000 01111000 00100000 01100001 00100000 01101101 00100000 01110001 00100000 01101100 00100000 01100101 00100000 00101110 00100000 01100011 00100000 01101111 00100000 01101101
while the user entered example.com into their address bar on their browser, the bit error taking place would instead cause examqle.com to be loaded, through no fault of the user.
While bit errors are uncommon, you should bear in mind that there are several stages while loading a web site in which there is a risk of bit errors (your OS when performs DNS resolution, your browser when it parses HTML, makes the initial HTTP request, etc)
In order to be successful at exploiting this, an attacker would have to bear in mind that the chances of bit errors taking place are relatively slim, therefore the attack would have to be performed on domain names that recieve a lot of traffic or are frequently resolved – the best choice of domain would be something like an ad server or a content delivery network for a large site (also root nameservers ftw??) – another factor to bear in mind is that the success of the bitsquatting attack is largely dependent on where the bit errors are taking place – for example, a bit error taking place in something like a popular proxy server or DNS resolver would affect a much larger number of people than a bit error taking place locally on a single person’s machine.
although bitsquatting isn’t a commonly used attack vector, domains that are frequently resolved are at the most risk – it should also be noted that many government sites (including US Court systems for almost every state!) use publicly available TLD’s (rather than .gov) which puts them at risk to this kind of attack (due to the fact that .us is publicly available) – these sites could contain potentially sensitive info (I see some of them having forms in which users can be prompted to enter their social security numbers, among other things) and this risk could be easily mitigated by switching to .tld’s which aren’t publicly avaialable. Here are some example’s of government sites that are registered under public TLD’s:
It should also be noted that this threat can potentially be mitigated by utilizing some of the new gTLD’s when choosing a domain name – another point to make is that obviously it doesn’t have to be only alphanumeric characters that are susceptible to bitsquatting, take the following domain for example:
At first one might assume they were limited if they wanted to perform a bitsquatting attack on this site, due to the fact that co.us is already registered therefore it’d be impossible to make a subdomain that took advantage of bit errors in order to launch an attack, but this is not the case, someone could register statenco.us and take advantage of bit errors which cause the binary representation of n to be flipped, which would result in it being replaced with . (dot) meaning the domain would be resolved to state.co.us as intended.
IDN Homograph attacks:
This is a fairly interesting attack vector which takes advantage of similar looking characters in ASCII/Unicode domain names
For example, a domain name such as google.com could have the o’s in the domain made up of either the greek letter Ο, the latin letter O or the cyrillic letter О – as you can see, these all look practically identical to eachother, yet they have entirely different unicode representations.
Here is a live example using paypal (it should be noted that paypal and its users have been the successful victims of an IDN homograph attack in the recent past):
the domain above will take you to paypal.com, whereas the domain below will fail to resolve (due to the fact that it is not actually paypal.com)
If you were to copy the link URL of the above domain, you would see that it is actually http://www.xn--pypal-4ve.com/ while at first glance it appears to look like paypal.com
The main defence against IDN Homograph attacks is punycode – this is what you see when you hover over a URL, and it will display the domain name in its true form, to see what i’m referring to just hover your mouse over both of the ‘paypal’ URL’s above and look at the bottom corner of your browsers to see their representation in punycode.
The vast majority of modern browsers have IDNA support disabled by default, meaning that when the URL is actually loaded the user will see the phony URL in their address bar – in order to make the attack more convincing, an attacker could setup a redirect so that xn--pypal-4ve.com redirects to a more authentic looking domain (at least at first glance), some examples would be as follows:
- http://example.com/www.paypal.com/ (as directory name)
- http://www.paypal.com-example.info (paypal as a subdomain and main domain starting with com-)
and so on…
If the site being targeted has an open redirect vulnerability, then it could be chained together with the fraudulent domain so that when the link is hovered over, a more legitimate looking domain is displayed via the punycode.
These methods chained together with some more conventional methods can make for a pretty effective phishing campaign. Here is an example attack scenario:
- Attacker obtains a list of victims
- Attacker finds and utilizes an open redirect in the site targeted within the phishing campaign
- Attacker registers a domain that allows an IDN homograph attack to take place
- Attacker sets up DNS redirect to have the domain redirected to a domain that looks similar to the site targeted in the phishing campaign
- Attacker then chains the open redirect with the link to the site used for the IDN homograph attack
- Attacker crafts spoofed emails containing the link and sends mass mail to the list of victims
- Victim opens the email, assumes its from the target site (due to the email address being valid + the URL actually being part of the site (w/ punycode bypassed due to the fact a redirect is being used)
- Victim is redirected from the site used for the IDN homograph attack to a phishing page registered on a domain that looks similar to the target site
- Victim logs in
- Attacker steals credentials
This is similar to spear phishing, but rather than requiring an XSS vulnerability in the site you want to phish, it instead requires that you have access to the victim’s LAN (which would either entail you cracking their WEP/WPA2 or using some method to remotely gain access i.e. via a remote access tool) – the fact that this requires LAN access means that entering their data to a phishing site is probably the least of the victims worries. That being said, it’s probably still worth covering.
Although I used httrack in the last posts to get a mirror of the site, the most simple way to phish over LAN would be to use SEToolkit (aka SET) – to use SET, install it via whatever your distro requires (apt-get/yum/pacman etc..), then cd to the directory for the install and type ./set to run it. Have a play around with the ‘clone site’ feature.
There are many issues with the method above, and you can perform a way more effective DNS-based phishing campaign (i.e. one that doesn’t display local IP’s in the browser) with some basic tools. In this example I will explain how to achieve it using aircrack-ng and MSF’S (metasploit’s) ‘fakeDNS’ aux module.
First off, you’d need to connect to the LAN in question (whether its a public hotspot or whether its someone’s home connection and you’re in close proximity to their house), after this you’re going to need to set your wireless card to monitor (promiscuous) mode, to do this you can use the tool airmon-ng (found within the aircrack-ng suite)
run the following command to create a new monitor interface:
Airmon-ng start wlan0
to start monitoring on the interface, airodump-ng should be used, run the following command to begin monitoring:
after this, you will need to find a hotspot with clients connected to it, the plan is to create a rogue access point that mimics this hotspot, to get the clients to connect to you instead of the hotspot itself, but first, you need to configure your DHCP server like so:
In the config file, you’re going to be looking for the following option:
option domain-name-servers 18.104.22.168;
Open nano/vim/whatever the fuck you want, then change this line so that the IP address is replaced with your own IP (or at least the IP you’re going to be running the FakeDNS module off of)
to create the rogue access point, we’re first going to be using airbase-ng to make a soft access point using the following command:
airbase-ng -e freenet mon0
next you’re going to want to install the FakeDNS aux module for metasploit and ensure that the options are correct (simply google for a correct setup, there’s a bunch of documentation) and then ensure its running and assign an IP to the tap interface for the soft access point created via airbase-ng, to do so you’ll need to use the following commands:
ifconfig at0 up 10.0.0.1 netmask 255.255.255.0
dhcpd3 -cf /etc/dhcp3/dhcpd.conf at0
After this, the final step is to deauth-flood the victim which will cause them to disconnect from the legitimate access point and be reconnected to your rogue access point, aireplay-ng can be used to achieve this via the following command:
aireplay-ng –deauth 100 -a MAC:FOR:ACCESS:POINT mon0 -c MAC:FOR:CLIENT:VICTIM
after running this command, you should be able to check airbase-ng output to see the victim connecting to your rogue access point (identifiable via MAC address)
once the victim tries to navigate to the site you’re using w/ FakeDNS, they will be redirected to your phishing page and their credentials are logged. And that’s all there is to it.
My next blog post (besides maybe a few little tutorials coming first) will be covering a critical zero-day vulnerability that I have identified, with over 40,000 affected sites including UK Ministry of Defence, US Navy, NASA, Namecheap, ICANN, Time Warner Cable, Toshiba, FedEx and more 🙂
thanks for reading