May 28, 2015 Tags: data, irc, programming, security
This post is at least a year old.
Preword: I didn’t really intend to have two posts on IRC in a row, but I lost several posts in a backup failure. Sorry!
Like so many of my posts, this one begins as an idea in an IRC channel:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
* redacted is now known as NicSkerv
* NicSkerv is now known as NickSerrv
* NickSerrv is now known as redacted
<redacted2> redacted: trying to phish some ns passes?
<redacted> testing the impersonation protection
<redacted> they dont allow NickSer
<redacted> or NickServv
<redacted3> What about nikserv
<redacted3> Or nicserv
<redacted> try it
<redacted> thats not really a likely typo though
<redacted> gotta get the typo ones
<redacted> i guess nikserv is
<yossarian> i would try NixkServ
<yossarian> or NickSerc
[a few messages later...]
<yossarian> actually, i wonder how many nicks you can phish by using common typos
<redacted2> Well, yossarian going by the amount of successful Phishing campaigns
I'd guess quite a lot
<yossarian> redacted2: yeah, i'd think so. this might be my project for the night
<redacted2> Make sure to keep me informed on the results ;)
IRC, like the Domain Name System, relies partially upon the user entering the right information. Your DNS nameserver cannot [1] (or at least shouldn’t) redirect you from “goggle.com” to “google.com”, even if 99% of traffic to “goggle.com” is the result of a simple typo. This is good in the sense that it makes the DNS system impartial [2], and bad in the sense that it allows malicious actors to take advantage of typos and homoglyphs and create a false trust relationship between the user and (fake) site.
This issue is at the heart of the IDN homograph attack and the more common typosquatting, both of which count on the users of a popular service making common errors a certain percentage of the time. That percentage can be low (1%, or even 0.1%) and still produce significant rewards for the squatter, increasing in proportion to the service’s popularity.
It’s easy to see how the typosquatting problem applies to IRC. Unlike the Web, which is slathered in signed SSL certificates and protected by bills like the Anticybersquatting Consumer Protection Act, IRC’s private messaging model is entirely blind.
On many networks, NickServ is the standard way to identify yourself as the owner of a nickname. Because NickServ masquerades as a user, issuing:
1
/MSG NickServ identify super_secret_password
is the preferred approach to nickname authorization.
This presents an obvious problem. /MSG is not secure [3], and it’s trivially
easy to mis-type “NickServ”, in effect sending the (normally) sensitive message
to the typosquatted nickname.
So, how can we use this to our advantage?
We know that /MSG is blind in its attempts to send messages to targets, so all
we have to do is create nicknames that have a high probability of being typed
instead of “NickServ”.
Many networks have realized the problem with having an isolated nick as a point of identification, and have taken some steps to prevent similar types of squatting: neither “NickSer” or “NickServv” is accepted as a valid nickname by some IRCds. However, the network used did not block one-off typos like “NickSerc”, “NickSerf”, “NickSerb”, or “MickServ”. As such, those four were chosen as the sample group.
In order to listen on four nicknames, four bots are needed. I chose Ruby and Cinch, because it makes IRC bot writing insanely easy. Altogether, the individual bot component is only 22 lines, with spacing:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
require 'cinch'
network, nick, channel = ARGV.shift(3)
ignore = ['Global', 'peer', 'py-ctcp'] # ignore these bots/announcers
Cinch::Bot.new do
configure do |c|
c.prefix = // # no prefix required
c.nick = nick
c.realname = nick
c.max_messages = 1
c.server = network
c.channels = [channel]
end
on :private, /(.*)/ do |m, msg|
if msg && m.user && !ignore.include?(m.user.nick)
Channel(channel).send "Received \'#{msg}\' from #{m.user.nick}."
end
end
end.start
The bot’s functionality is dead simple: listen for private (user-to-user)
messages, and report their contents to a specified channel for monitoring.
Messages from a few select hosts, as listed in the ignore array, are not
reported.
After this, all that is needed is a simple bash script to start all four bots:
1
2
3
4
5
6
7
8
network="irc.rizon.net"
channel="#phishbot"
nicks=(NickSerc NickSerf MickServ KickServ)
for nick in "${nicks[@]}"; do
ruby ./phishbot.rb "${network}" "${nick}" "${channel}" 2>/dev/null &
echo "Kill this pid to end ${nick} on ${network}: $!"
done
The product of all of this:
Not very impressive, but let’s leave it for 72 hours and see what we rake in.
Over the course of 72 hours, the four bots phished 8 messages from 7 distinct users.
That isn’t very much data but I wanted to test gnuplot out, so here are some
visual representations:
From the extremely limited dataset it appears as if “NickSerc” is the best nick to typosquat on, with 50% of all messages being directed at it. This would make sense, as the C key’s proximity to the (expected) V key on QWERTY layouts is about as good as it gets with respect to error potential. NickSerf’s 25% share makes sense by similar logic, although I personally make vertical typos less often.
I didn’t really expect “MickServ” or “KickServ” to receive any hits, and was pleasantly surprised when “MickServ” received a 25% share. I can’t really explain this, as I would think that first-letter typos would be the easiest to spot and correct. The fact that “KickServ” received no messages at all is not surprising, however, when you consider that “KickServ” sounds like a legitimate service provided by the network.
The breakdown of commands sent to the squatting bots follows a similarly expected distribution. “IDENTIFY” commands were overwhelmingly common, and only two other distinct command were received: one “HELP” and one “REGIST”, which I assume was meant to be the “REGISTER” command.
Overall, despite the fact that the tested network hosts tens of thousands of users simultaneously, very few were actually ensnared by the four bots that ran over the 72 hour period. This is likely a result of the advancement of IRC clients away from manual authentication and towards automated “IDENTIFY” messages. Although the network in question does not support SASL as an authentication method, this too would likely have drawn targets away into a safer [4] technique.
In short, the consequences of this sort of data gathering are relatively insignificant, but a curiosity and neat demonstration of the potential danger of simple typographical errors. Although NickServ is now a staple of the IRC landscape and is unlikely to disappear anytime soon, the big networks should be aware of the potential for abuse it creates.
In no particular order of efficacy, here are some potential solutions for IRC hosts:
And some potential solutions for IRC users:
/mn to /msg NickServ solves this problem cleanly.To wrap things up, I hope that this post has been interesting and that you’ve taken a few lessons about typosquatting away from it. I know that IRC isn’t the most relevant protocol on the Internet, but it’s great for demonstrating real problems on a smaller scale. Make no mistake: tens of thousands of people do go to “goggle.com” instead of “google.com” on a daily basis. Stopping those people before they download a bunch of malware that steals their credit cards without undermining the infrastructure on which the Internet is built is a massive problem, and hopefully this tiny experiment imparts that upon you.
Happy Hacking!
- William
Notes:
[1] - They actually can, but this is frowned upon and is (thankfully) becoming less common. If you remember the days when mistyping a domain took you to a page controlled by your ISP, you were a victim of this. If your ISP still does this, you should consider switching providers.
[2] - It would also be difficult to call the authorities in control of the root nameservers impartial. However, the fact that all domains with “cola” in them don’t immediately redirect to the Coca-Cola Corporation’s site (yet) is a testament to how relatively unregulated domains still are (in comparison to post boxes and phone numbers).
[3] - A partially moot point, as IRC itself is not (designed to be) secure.
As an example, however, consider how easy it is to accidentally PRIVMSG a user
instead of a channel by simply forgetting the hash:
/MSG secret_channel the british are coming.
[4] - Safe from typosquatting, and not much else. Clients commonly store their connection details in plain text, including passwords. In addition, as mentioned previously, IRC itself is not secure and relies on the underlyng connection, network node(s) and network infrastructure all being trustworthy.
P.S.: I don’t condone going on your IRC network of choice and typosquatting for passwords and other goodies. I got K-Lined for having too many active connections twice while doing this experiment, and I am certain that I would be permanently banned from the entire network had I made my actions more public.