thoughts and a possible solution on homograph attacks

[Paul Smith, Fri, Mar 11, 2005 at 10:42:47AM +0000]
> My proposal would be:
>
> 1) IDNs only allowed on ccTLDs (not gTLDs). After all , the whole point of
> IDNs is to have a domain name in the locally readable script to target
> people within your own region/nation/etc. gTLDs are to have domains to
> target people globally. I see no purpose (other than vanity) to having an
> IDN in a gTLD .
>
> 2) IDNs should only be allowed to consist of a single character set - be
> that Latin, Western European, Japanese, Cyrillic etc.
>
> 3) A ccTLD should only allow IDNs in their local character set(s). So, you
> couldn't have a cyrillic IDN on a .us domain, and you couldn't have a greek
> IDN on a .ru domain.
>
> (4) A domain registry's DRS system should take into account
> homograph/pseudograph attacks.
>
> (5) Possibly any domains containing only characters which are graphically
> equivalent to latin characters should not be allowed, but I'm not sure of
> this one.
>

I would rather suggest that the string comparison function used in IDN
takes "homograph caracters"[1] into account: just like the current DNS
considers 'a' == 'A', the IDN DNS should consider "LATIN SMALL LETTER
a" == "CYRILLIC SMALL LETTER a" == "CYRILLIC CAPITAL LETTER A" ==
"GREEK CAPITAL LETTER A"[2], and similarly for the other homograph chars.

A true fix in this way cannot be implemented browser-side, but rather
in the IDN implementation; still, one can make the browser put the IDN
names in a *canonical form* using this equivalence relation: that is,
"CYRILLIC SMALL LETTER a" in a hostname is always sent on the wire as
a "LATIN SMALL LETTER a".

Riccardo


[1] or whatever the correct term for these is...

[2] so, the transitive closure of the (uppercase == lowercase) and the
homograph equivalence relation implies for instance "LATIN CAPITAL
LETTER A" == "GREEK SMAL LETTER \alpha", which are not homograph, but
I see less harm in this than in the current IDN.

--
Riccardo Murri
EGRID Project
The Abdus Salam ICTP

Strada Costiera, 11
34016 Trieste
Italy

email: riccardo.murri@ictp.it
phone: +39 040-2240-542
fax: +39 040-224531

On Tue, 15 Mar 2005, Riccardo Murri wrote:

> I would rather suggest that the string comparison function used in IDN
> takes "homograph caracters"[1] into account: just like the current DNS
> considers 'a' == 'A', the IDN DNS should consider "LATIN SMALL LETTER
> a" == "CYRILLIC SMALL LETTER a" == "CYRILLIC CAPITAL LETTER A" ==
> "GREEK CAPITAL LETTER A"[2], and similarly for the other homograph chars.

But that breaks case insensitivity for Greek, for instance (other
languages, too, I am sure).

Consider Greek letters eta and nu.

A upper case eta looks like an upper case Latin "H", but a lower
case eta looks like a lower case Latin "n".

Similarly, an uppercase nu looks like a upper case Latin "N", but a lower
case nu looks like a lower case Latin "v".

If such a system as you suggest is in place, and someone in Greece wants
the site (Greek nu).gr, they would have to have control of both N.gr and
v.gr, otherwise people who type in the wrong case would go to the wrong
site. Now let's say a competitor comes along, and wants (Greek eta).gr.
They can get H.gr, but n.gr is already take, since N=n.

I suppose we could get around that by making H=n=N=v(=V=H), but that would
get cohfusivg.

[khockenb, Tue, Mar 15, 2005 at 07:10:16PM -0500]
> On Tue, 15 Mar 2005, Riccardo Murri wrote:
>
> > I would rather suggest that the string comparison function used in IDN
> > takes "homograph caracters"[1] into account: just like the current DNS
> > considers 'a' == 'A', the IDN DNS should consider "LATIN SMALL LETTER
> > a" == "CYRILLIC SMALL LETTER a" == "CYRILLIC CAPITAL LETTER A" ==
> > "GREEK CAPITAL LETTER A"[2], and similarly for the other homograph chars.
>
> But that breaks case insensitivity for Greek, for instance (other
> languages, too, I am sure).
>
> Consider Greek letters eta and nu.
>
> A upper case eta looks like an upper case Latin "H", but a lower
> case eta looks like a lower case Latin "n".
>
> Similarly, an uppercase nu looks like a upper case Latin "N", but a lower
> case nu looks like a lower case Latin "v".
>
> If such a system as you suggest is in place, and someone in Greece wants
> the site (Greek nu).gr, they would have to have control of both N.gr and
> v.gr, otherwise people who type in the wrong case would go to the wrong
> site. Now let's say a competitor comes along, and wants (Greek eta).gr.
> They can get H.gr, but n.gr is already take, since N=n.
>
> I suppose we could get around that by making H=n=N=v(=V=H), but that would
> get cohfusivg.
>

You're perfectly right - this equivalence relation would backfire on
ASCII-only domains too.

Riccardo

--
Riccardo Murri
EGRID Project
The Abdus Salam ICTP

Strada Costiera, 11
34016 Trieste
Italy

email: riccardo.murri@ictp.it
phone: +39 040-2240-542
fax: +39 040-224531

Homograph attacks might be a closed subject but nobody has mentioned this, so
maybe I should. Surely it is possible for a web browser to apply some similar
character mapping rules and react only if it finds something.

Thus if the IDN looks like www.ebay.com on the screen the web browser will
notice www.ebay.com exists, pop up a warning and deny access if you just click
OK. An option safe from those who just click OK without reading anything could
allow access to those websites.

The best fix would be to stop the registry's granting homograph names to random
people and revoking he existing ones with immediately effect but I do think
this is within the power of bugtraq.


Websites could also help by using cookies valid only for one web request, with
the next working value computable only if you know a secret. Knowing this
secret should require knowing the password, which should never tbe sent
anywhere. This should make it harder to steal cookies and much more difficult
do so without being detected.

If I can implement the above on IE, mozilla and opera using indentical java and
javascript then surely banks can too. There are nasty side effects involving
the back button but these are toleratble and probably fixable. My solution was
only designed to be better than a single fixed value and there are stronger
protocols (for example SRP-6).




--j2JHE1bF010628.1111252443/mail.simpson.demon.co.uk
Content-Type: text/plain

Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."

Duncan Simpson wrote:

> Homograph attacks might be a closed subject but nobody has mentioned thi=
s, so
> maybe I should. Surely it is possible for a web browser to apply some si=
milar
> character mapping rules and react only if it finds something.
>
> Thus if the IDN looks like www.ebay.com on the screen the web browser wi=
ll
> notice www.ebay.com exists, pop up a warning and deny access if you just=
click
> OK. An option safe from those who just click OK without reading anything=
could
> allow access to those websites.
>
> The best fix would be to stop the registry's granting homograph names to=
random
> people and revoking he existing ones with immediately effect but I do th=
ink
> this is within the power of bugtraq.

In fact, it seems that the Unicode folk are thinking about these issues
and similar solutions.

http://unicode.org/reports/tr36/

Draft Unicode Technical Report #36

Security Considerations for the Implementation of Unicode and
Related Technology

Summary

This document describes security considerations that are important
to be aware of when working with Unicode, and provides specific
recommendations for dealing with the issues that arise.

[ToC]

1. Introduction

Unicode represents a very significant advance over all previous
methods of encoding characters. For the first time, all of the
worlds characters could be represented in a uniform manner, for the
first time making it feasible for the vast majority of programs to
be globalized: built to handle any language in the world.

In many ways, the use of Unicode makes programs much more robust and
secure. When systems need to use a hodge-podge of different charsets
for representing characters, it was possible to take advantage of
differences between those charsets, or in the way in which programs
converted to and from them.

However, because Unicode contains such a large number of characters,
and because it incorporates the varied writing systems of the world,
incorrect usage can expose programs or systems to possible security
attacks. This document describes some of the security considerations
that should be taken into account by programmers, system analysts,
standards-developers, and users.

We anticipate that this document will grow over time, adding
additional sections as needed. Initially, there are two areas that
will be discussed: canonical representation and visual spoofing. For
more information, see also the Unicode FAQ on Security Issues.

Each section below presents a background information on the kinds of
problems that can occur, then a list of specific recommendations for
avoiding the problems.

This report discusses most of the issues raised in this thread, and
often from a greater depth of understanding. For example, several
posters disagreed with my suggestion that "homograph" was the wrong
term, but seemed to only be aware of the problems that could arise from
Latin letters that have effective equivalents in non-Latin character
sets, (necessarily) represented by different codepoints in Unicode.
The examples provided in TR36, although still noted by its author as
needing further samples, provide many other cases of clearly non-
equivalent, but visually confusable characters, especially when
displayed at small-ish point/pixel sizes as is common in web browser
address/location/status/etc bars.

3. Visual Spoofing

Visual spoofing is where a similarity in visual appearance fools a
user, and causes him or her to take unsafe actions. This is not new
to Unicode: it was possible to spoof simply with ASCII character:
"inteI.com" for example, uses a capital I instead of an L. The
infamous example here is of course "paypaI.com":

... Not only was "Paypai.com" very convincing, but the scam
artist even goes one step further. He or she is apparently
emailing PayPal customers, saying they have a large payment
waiting for them in their account.

The message then offers up a link, urging the recipient to claim
the funds. But the URL that is displayed for the unwitting victim
uses a capital "i" (I), which looks just like a lowercase "L"
(l), in many computer fonts. ...

=97 Beware the 'PaypaI' scam

And the spoofs nowadays are pretty clever. One is an email that
looks like it comes from a trusted source, like your bank. It even
has an explicit disclaimer to not trust links in email, and directs
you to copy text to your address bar in your browser. The text looks
ok to you, so you won't realize that you are going to a completely
different site, which is then set up to simulate your bank well
enough to get your password.

These spoofs depend on the use of visually confusable strings:

D1. Two different strings of Unicode characters are said to be
visually confusable when their appearance in common fonts in
small sizes at screen resolutions is sufficiently close that
people easily mistake one for the other.

I'll leave the rest of TR36 to those interested in reading it (it deals
extensively with IDN-based spoofing), and recommend it despite that I
still disagree with the term "homograph", which TR36 uses often. All
the definitions of "homograph" I've seen have it meaning "same spelling
but different meaning and/or pronunciation and/or origin". My
suggestion of "pseudograph" much better captures the point of these
things, which is that they are (deliberately) constructed "mis-
spellings" that falsely represent something they are not, or disguise
that they are not what they represent themselves as (think of
"pseudonym" as something of an analog).

Anyway, discussion of the terminology is probably less important than
working out some useful ameliorative actions, so I'm going to drop the
homograph vs. pseudograph issue and suggest anyone interested read TR36
as it makes several suggestions and recommendations, but is a work in
progress and may be amenable to change through your input...


Regards,

Nick FitzGerald