So, I guess, uh, we're a little, we're definitely early, we're definitely on the clock.
Uh, welcome to Speaker Workshops, and now it is the, uh, 210 talk. And, uh,
want to say, just have a little bit to say about, uh, our presenters, Sam Erb. So, Sam Erb, uh,
just real quick, Councilor 9, and I, uh, also, I, uh, I think you're the very first black badge
holder I know personally. Ooh, is, wait, is that a radio, that's radioactive, right? Is that the
radioactive one, or thou shall not speak of it? Are we going to light this thing on fire?
Uh, without much ado, Sam Erb!
Thank you. Um, so, uh, long-time listener, first-time speaker, um, so let's get going.
Uh, so, you're going to connect to the wrong domain name, so, um, for whatever
reason for the past few years, I've been very interested in domain names, and, uh,
this is kind of a look at some of the, um, different ways that you can be tricked,
or your computer can be tricked, uh, or you can be phished to connect to, uh, the wrong domain name.
Um, so, uh, a bit about myself, uh, software engineer, I work at a cool company called Akamai,
uh, we're hiring people like you, I have to say that, uh, and, uh, I have a, uh,
Defcon23 and Defcon24 Uber Black Badge with the Council of Nine.
Um, yeah, that's me at closing ceremonies since last year.
Um, a disclaimer, uh, the opinions expressed here are my own, and no one was phished in
the creation of this presentation, which will become a bit more obvious later on.
Um, yeah, so I'm going to start out from kind of least severe and kind of build up from there.
Um, and so, just to get going, um, we have to start out with typosquatting.
Humans aren't perfect, they're going to connect, they're going to mistype the domain name they
type in, um, and a malicious person could register these and, uh, trick somebody into
entering their bank credentials, for instance.
So this example here is looking at all the one-keyboard-letter-off variants of americanexpress.com.
If you actually look up the registration status of each of these, um, like the example here
is qamericanexpress.com, all but two of them are actually currently registered,
or actively registered, as of April, I believe.
I did all this, most of the research here in April 2017, so that's roughly when all
this data's from.
So the reason why I chose americanexpress here is that it's long enough that no one's
company name is going to be qamericanexpress.com, whereas with a shorter website, you might
get some legitimate websites, whereas I could argue that none of these are actually legitimate.
So, building up from there, we have to look at bit squatting.
This is one where your computer is actually going to get the domain name wrong by flipping
a bit.
The example I gave here is I swapped a bit on Google Analytics, and I end up with Eagle
Analytics.
This is a very low-probability event, but as most phones and personal electronic devices
don't have error-correcting memory, this happens at a non-zero rate across the internet.
So, in order to give a demo for this talk, I actually wanted to register one of these
domains, and so I actually searched for the 1-bit variants of GoogleAnalytics.com.
Part of the reason for looking at GoogleAnalytics.com is you want a website that people are going
to visit a lot, but not mistype.
Google Analytics falls in that, as do most CDNs.
When I searched for domains, this was the only one available.
So, I went ahead and registered it, and I put up a server on it and got a TLS certificate
for it.
And within 24 hours, I saw two what I would call hits.
One HTTP, one HTTPS.
This is one Android browser and one Android application actually connecting to my server.
If you actually go and look at the source website of where this came from,
the source website says GoogleAnalytics.com, but something within their phone caused a
bit to flip in such a way that they went to the wrong website.
Now, one other thing, when I actually...
So, with a very popular website, from what I've seen, this is about what to expect.
You'll get a few random hits per day.
Once I got these hits, I actually took this down.
But when I turned on this website, I immediately was getting spammed by this one very particular
domain name.
So I went to it, and it was actually a Swedish diving company's website had somehow managed
to mess up their Google Analytics tag to point to my website.
So every person that was visiting their website was also connecting to this.
That's a picture of the code at the bottom there.
It's a little bit hard to read from a distance, but it's pointing to EagleAnalytics.com.
Yeah.
So that's just an example of how to do this.
If you're looking for more information on this, there's actually a really great white
paper that Cisco put out.
And I believe it's actually on DefCon.org, if you search for it.
Or sorry, no, that's something later.
I'm getting these confused.
There was a talk at DC19 on this, I believe.
That's what it was.
Yeah.
And so, being familiar with BitSquadian, I wanted to look at some other variants of
BitSquadian.
And one thing that I noticed is that there have been some recent registered top-level
domain names, or TLDs, that actually BitSquad on other TLDs.
So in this case, the registrar requested .got, which BitSquad's .gov.
I reported that one in April of 2016 to the registrar, and they claimed to have implemented
a fix.
It's not actually testable right now, because you can't actually register those domains.
But that's a very tractable problem, because there's a limited number of .gov websites.
However, a recent one, which is .bom, actually BitSquads all of .com, which is a much more
intractable problem, as there are a large number of .com domain names.
A funny thing about .bom is that it was actually objected to by VeriSign, because it looks
too similar to .com, and that objection was overruled, but it also BitSquads on .com,
which is very unfortunate.
I know it didn't report that one, as I'm not sure what value there would be from reporting
that.
This is actually something that was mentioned in the Cisco white paper, but these are more
recent TLDs from that point.
BitSquatting, like I said before, it only really targets random end-users.
You can't really target a specific user with it, but you could target a user base, such
as a bank.
If you could only steal a few credentials per day, that could still be a lot of money.
Or if you're BitSquatting a .gov website, that could get you a few inbound emails to
intelligence agency per day, which could be significant.
Going to the next slide...
I'm getting a bit more serious.
A lot of the reason why I gave this talk, actually, is I wanted to look at IDN homoglyphs.
Homoglyphs are two characters that look the same, but have different meanings.
IDN is an internationalized domain name, which is something that, if you're an English language
speaker, you might not come across very often.
Depending on your browser, you'll either see their source piny code, which is xn dash dash,
or the ASCII equivalent of that.
Piny code is a way to encode a larger character set into a smaller space.
In the format that's used, you have the xn dash dash identifier.
This is all standardized, followed by the English alphabet letters, or standard letters,
followed by a dash, followed by...
There's a standardized algorithm for actually computing what comes after that.
There's an RFC on it and everything.
I'm not going to give a great explanation of that, so I won't.
With that, you can end up with a...
That same machine will determine which letter and what location it will get placed into the
URL that gets rendered.
I gave two examples here.
These are actually both registered domain names.
Google.com, where both the O's are Cyrillic O's.
I believe they're Cyrillic O's.
It might be Latin, sorry.
And Time.com, where every letter is actually from the Cyrillic alphabet.
I'll show you how I found those later.
Those are both actually registered domain names.
I wanted to conduct a survey of existing homoglyphs
and IDN domain names against popular.com domain names.
I wanted to look for people who were impersonating .com domain names.
I chose to focus on .com, as that's where most of the popular English language websites are.
I only speak English, so I'm very limited there.
There's really three options if you want to gather a large number of domain names.
One is you could get the zone files for .com.
That requires filling out a form, which really isn't that fun.
And some of the zone files are actually impossible to acquire,
such as North Korea's, who actually leaked, I believe, last year.
You could go to Certificate of Transparency, which is a log of certificates.
Or you could go to a third party.
And there are third parties where you could pay a few hundred dollars
and get a list of domain names, but that isn't that fun either.
So I chose to go with Certificate of Transparency.
And for this, I pulled down the Google pilot log.
This contains about 100 million certificates.
That's 96.5 million domain names, roughly.
This is also completely searchable if you go to cert.sh.
Certificate of Transparency, if you haven't heard of it before,
is an initiative to log every publicly trusted certificate on the internet.
It's largely a Google initiative.
But there are logs hosted by other companies.
I chose the Google pilot log, simply as it's the largest right now.
There's another reason that I wanted to use Certificate of Transparency.
If a certificate was registered, that means it's far more likely to have been used.
Especially with the bit-squatting and typo-squatting domain names,
a large number of these are registered but never actually utilized,
which I found interesting.
In order to use the CT log, I built a pipeline.
I pulled out the common domain and subject-alternative domain fields from that.
I then filtered out all of the PunyCode domain names.
There's a great Python library called unidecode-package,
where somebody actually went through and said what each Unicode character looks like,
what its ASCII equivalent looks like,
and actually went through character by character and did that,
which is a great amount of work.
It's very impressive.
So that maps ASCII letters to what looks like their English equivalent.
I then cross-referenced that list with the Alexa top 1 million domain names.
At the end of the day, I got 1900 CT certificates that impersonated
the Alexa top 1 million domain names.
I then also went ahead and modified the Chromium unit test
to check whether or not they would actually be rendered as PunyCode
or whether an end user would see xn dash dash.
In Chrome and Firefox right now, that test is actually standardized across all languages,
so this would be applicable to all end users.
In other browsers, I believe Internet Explorer or Microsoft
will take into account your local language to determine whether or not
you actually render the PunyCode variant.
I've actually posted that list online.
There are a few false positives in there, like there are valid websites.
They just simply happen to look like their English equivalent website,
but I chose to include those as I didn't want to actually filter all of these.
What is much more interesting is actually showing the results.
These are all real domain names.
I would encourage you not to visit any of these.
There are some really bad ones in here in that list, unfortunately,
and I spent a decent amount of time actually reporting phishing websites
to the Google phishing page.
These are just some of the worst ones that I saw grouped by what character they used.
There's a Latin small letter K, and the L with a stroke looked pretty bad,
and then the dotless I was one of my personal favorites.
I didn't know that was actually a thing before this.
That's actually part of the reason why I took this approach,
was I'm not an ASCII expert, if there even is such a thing.
I really tried to go about finding the worst abusers
without having to necessarily have a knowledge of ASCII in the first place,
or knowing which letters to look for.
As expected, the most popular websites towards the top of the list
were much more likely to actually be impersonated.
One of the more interesting things that I saw,
which actually bypassed the Chromium check.
The formatting here is the last entry in that field,
whether or not it bypassed the Chromium check.
In this case, they'd actually be rendered as time.com.
They only used Cyrillic characters to represent the English equivalent.
A breakdown of the Unicode blocks that I observed while going through this.
Latin and Cyrillic are kind of as expected, but there was a long tail,
and I really want to call out one at the very end,
which is the Canadian Aboriginal Celbic Unicode block.
That one really struck me as odd, as I wasn't really familiar with what that was.
I went ahead and I looked at that Unicode block,
and the characters that are contained in it.
I went ahead and made a bunch of sample domain names,
and I plugged them into the Firefox and Chrome browser,
and they weren't converted to their Unicode equivalent.
None of these were actually registered.
I simply tested whether or not they bypassed the Firefox and Chromium check,
and then went ahead and reported security bugs.
The end result of this was that Chromium actually will now not allow
the mixture of Canadian Aboriginal Celbic characters and English characters,
which they did before.
And they're actually working on a much more comprehensive anti-phishing fix,
which I believe is still a work in progress.
Within Firefox, this check is a bit more interesting,
because Canadian Aboriginal Celbics actually fell under this thing called
aspirational Unicode blocks, which allowed them to be mixed
as part of the standard Firefox profile with their English language characters.
And in order to resolve this issue, they simply increased the level of that check
to disallow a mixture of English characters and this aspirational character block.
And I believe they actually filed a request with some...
I'm not exactly sure what agency tracks this,
some external request to actually update the rules regarding this aspirational block,
as some of the characters do look like English characters.
So as was news to me and the Firefox and Chromium engineers,
who actually were working on the fixes for these,
you can't actually register any of these domain names.
And this is where, believe it or not, policy comes to the rescue.
When you try to register any of these domains,
you're stopped.
The reason for this is that VeriSign actually has a policy
that you can't mix Canadian original syllabic characters with certain other characters,
which includes English language characters.
And they have this for every Unicode block, which I was completely unfamiliar with.
One of the more interesting things about this
is when I actually tried to register these domain names,
because this is a failure at such a late stage in the registrar process,
most registrars actually took my money.
And in one case, I actually had to fight to get it back.
I wasn't the biggest fan of that.
So I kind of walked through three different examples of different ways that
you or your computer could connect to the wrong domain name.
So now we're just going to look at personal mitigations.
I'm kind of preaching to the choir here.
So the reason to use a password manager is simply because
your computer won't be confused by any of this.
However, if you actually own or are responsible for any popular domain name,
it's probably worth looking into whether or not somebody's impersonating you.
You could actually file an ICANN complaint and issue a takedown request,
especially if your trademark's being violated.
And if you work in IT or are at all curious,
I would be... something that's worth checking is what happens
when you plug these into your email client.
What renders.
Yeah, that's probably going to depend on the email client.
So as I had the super transparency log, I went ahead and just had some fun with it.
I graphed the key types over time.
RSA 2K keys dominate, followed by ECJSA P26 keys, and then RSA 4K keys.
There was also this fun long tail, which proves that
when you give users options, you can always trust them to be consistent.
Some of my favorite ones in there is somebody actually issued an RSA 500 key,
and there's also an RSA 2600 key as well.
And at the very end there, there's a DSA 512 key, which is really unfortunate.
So we actually have an intern this year within my company who's actually looking more into this.
And if you're at all interested in this, I'll publish a link to it on my Twitter feed
with much more details on what's actually contained in the super transparency log
when you look at the log as a whole.
So, yeah, questions.
Questions, anyone? If you have any questions,
feel free to have the stage and feel free to come to the mic.
Feel free.
Oh, we got a question.
I might have missed something in the beginning, but I think you showed examples of
domains that were registered with those mixture of English and non-English characters.
And then later you said that that's not allowed. Is that just something that changed?
So it depends on which block you're looking for.
So the reason why Canadian Aboriginal syllabics actually appeared in this list,
I actually went back later and looked at that domain name,
and it was two Canadian Aboriginal characters, not mixed with any English characters.
But it simply, when it was passed through the Python package,
looked like a, I believe it was like a BB character.
The characters looked like Bs.
And so it looked like bb.com as the English language equivalent.
So that's why it actually appeared on this list, but you can't actually register the mixture.
Thanks.
So regarding the don't click links suggestion,
do you have any recommendations for any other mitigation?
Like, for example, say there's a 40-character hex thingy at the end of a URL.
I don't think most users are going to type in everything,
oh, oops, I mistyped the 23rd letter or something.
They're just going to copy and paste it.
So is there another way?
It's a good question.
It's really a question of trust, I feel like.
Do you trust the recipient?
Can you somehow verify that the link is valid in other ways?
Or just cut and paste the end of it?
And type in the start of it?
It's an intractable problem at the end of the day.
Right.
Okay, thanks.
Once again, Shamrp, everyone!
Shamrp!