Request for comment - homophone attacks

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Request for comment - homophone attacks

Kurt Seifried
It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
JA
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

JA
Seems covered as homographs in CWE-451
I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 
What do you think?

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:
It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Kurt Seifried-2
I would say much like the CWE-79 thing it would be nice to break this up a bit, especially with international domain names and easy access to TLS/SSL certs homophone attacks will become a much more prevalent problem for web stuff (and outside of web browsers, do many/any tls/ssl clients that display the hostname to people do it "right"?). 

On Mon, May 8, 2017 at 8:26 AM, Jerome Athias <[hidden email]> wrote:
Seems covered as homographs in CWE-451
I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 
What do you think?

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:
It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



--

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Barry, Jim

Kurt,

 

The CWE and CAPEC teams have been looking into the proposals submitted by Kurt Seifried and would like to update the CWE community on the team's progress.

 

Based off of the original email, the CAPEC team will be creating 3 new CAPEC entries (typosquatting, soundsquatting, and homograph attack), which will be explained more in a subsequent email.

 

In terms of the CWE approach, the team is hoping for some clarification of the original email. When you say "a system doesn't give some indication that a URL/name/whatever is not in my normal character set", do you believe the browser should give the indication or some other 'system' should?

 

The second question is, what is the underlying weakness of the attack you describe? In the original email, the primary concern is a URL which is either fully or partially comprised of a set of characters outside of the default set, which can lead a user to a malicious website. What weakness is being exploited here and how are the developers supposed to safeguard against this attack?

 

Since CWE currently focuses on software weaknesses, the team is trying to determine if there is anything the developers of an application can do differently to mitigate these attacks. Also, because a single weakness can often be addressed by different mitigations, the team typically does not create entries that focus on "failure to use specific mitigation X."  Such missing-mitigation characterizations provide a strong hint that the underlying weakness is not well-understood or has not yet been properly identified.  In this case, it seems that the attacker simply registers a similar looking URL and tricks a user into visiting that malicious URL, which is something that the developer cannot prevent.

 

Any input or additional information allowing the CWE team to better understand the issue would be much appreciated.

 

Thank you,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng
Work (781) 271-3058 | Mobile (617) 406-9278

 

MITRE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, May 8, 2017 11:13 AM
To: Jerome Athias <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

I would say much like the CWE-79 thing it would be nice to break this up a bit, especially with international domain names and easy access to TLS/SSL certs homophone attacks will become a much more prevalent problem for web stuff (and outside of web browsers, do many/any tls/ssl clients that display the hostname to people do it "right"?). 

 

On Mon, May 8, 2017 at 8:26 AM, Jerome Athias <[hidden email]> wrote:

Seems covered as homographs in CWE-451

I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 

What do you think?

 

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:

It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Wheeler, David A

Jim Barry:

> Since CWE currently focuses on software weaknesses, the team is trying to determine if there is anything the developers of an application can do differently to mitigate these attacks. Also, because a single weakness can often be addressed by different mitigations, the team typically does not create entries that focus on "failure to use specific mitigation X."  Such missing-mitigation characterizations provide a strong hint that the underlying weakness is not well-understood or has not yet been properly identified.  In this case, it seems that the attacker simply registers a similar looking URL and tricks a user into visiting that malicious URL, which is something that the developer cannot prevent.

 

There are many different ways to mitigate attacks, so I agree that “failure to use specific mitigation X” is often not helpful.

 

However, I think the weakness in these cases would be something like, “failure to provide an adequate mitigation for <whatever>”.  Sure, the devil’s in the details of “adequate”, but it’s not really acceptable to provide *NO* mitigation for a real-world vulnerability.  It’s okay that there would be multiple mitigations for different circumstances; listing the most reasonable options, with pros & cons, would be a useful service.

 

Let’s talk about DNS specifically.  You could argue that in the case of DNS, the vulnerability is in the DNS registrar system that allows identical-appearance DNS names.  But when “Let’s Encrypt” permits them all – and they are generally a *good* actor and are certainly widely depended upon – then it you can’t really depend on the DNS registration system preventing malicious names.  That means that user software must provide some mechanism to help the users navigate these shark-infested waters.  Dumping the user in front of the shark is *not* acceptable J.

 

--- David A. Wheeler

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Kurt Seifried
In reply to this post by Barry, Jim


On Mon, Jun 19, 2017 at 8:00 AM, Barry, Jim <[hidden email]> wrote:

Kurt,

 

The CWE and CAPEC teams have been looking into the proposals submitted by Kurt Seifried and would like to update the CWE community on the team's progress.

 

Based off of the original email, the CAPEC team will be creating 3 new CAPEC entries (typosquatting, soundsquatting, and homograph attack), which will be explained more in a subsequent email.

 

In terms of the CWE approach, the team is hoping for some clarification of the original email. When you say "a system doesn't give some indication that a URL/name/whatever is not in my normal character set", do you believe the browser should give the indication or some other 'system' should?

So up until recently domain names were restricted character set wise to a subset of ASCII. So it was always safe to assume that whatever was in the address bar was ASCII. Now with unicode my address bar is usually (probably most alway) ASCII, but it might also be unicode, with characters that look a lot like "seifried.org" for example but are in fact a Cyrillic character or something else. It would be nice for my address bar to give an indication, am I looking at ASCII? unicode? The fonts themselves in theory could do this (e.g. have very different type settings for non ascii chars) but I think it's better to leave this up to the UI to indicate what character set is present. 

 

The second question is, what is the underlying weakness of the attack you describe? In the original email, the primary concern is a URL which is either fully or partially comprised of a set of characters outside of the default set, which can lead a user to a malicious website. What weakness is being exploited here and how are the developers supposed to safeguard against this attack?

Ultimately it's people as always. Part of this is the fonts, some glyphs look an awful lot like each other but are totally different things, and in the case of DNS of course example.org and ėxample.org and exampłe.org (btw on my screen that ł looks like I have a bit of dust or some odd graphical glitch/artifact) are totally different things.

Since CWE currently focuses on software weaknesses, the team is trying to determine if there is anything the developers of an application can do differently to mitigate these attacks. Also, because a single weakness can often be addressed by different mitigations, the team typically does not create entries that focus on "failure to use specific mitigation X."  Such missing-mitigation characterizations provide a strong hint that the underlying weakness is not well-understood or has not yet been properly identified.  In this case, it seems that the attacker simply registers a similar looking URL and tricks a user into visiting that malicious URL, which is something that the developer cannot prevent.

Having an indication of what charset (e.g. set a "Default" like ascii, if it's ascii get a soothing blue background on the url, if it';s unicode give me an angry red) would be one way to go.
 

 

Any input or additional information allowing the CWE team to better understand the issue would be much appreciated.

 

Thank you,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng
Work <a href="tel:(781)%20271-3058" value="+17812713058" target="_blank">(781) 271-3058 | Mobile <a href="tel:(617)%20406-9278" value="+16174069278" target="_blank">(617) 406-9278

 

MITRE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, May 8, 2017 11:13 AM
To: Jerome Athias <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

I would say much like the CWE-79 thing it would be nice to break this up a bit, especially with international domain names and easy access to TLS/SSL certs homophone attacks will become a much more prevalent problem for web stuff (and outside of web browsers, do many/any tls/ssl clients that display the hostname to people do it "right"?). 

 

On Mon, May 8, 2017 at 8:26 AM, Jerome Athias <[hidden email]> wrote:

Seems covered as homographs in CWE-451

I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 

What do you think?

 

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:

It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].




--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Kurt Seifried


On Mon, Jun 19, 2017 at 10:11 AM, Shawn Hernan <[hidden email]> wrote:

I would be very reluctant to create a system that suggests that non-ASCII characters are somehow de facto suspicious.

I didn't meаn to sаy globаlly suspicious, but for exаmple if а user sаys  "Chinese chаrset аnd english аre ok, everything else is suspicious to me" their UI should help them with these choices. Or it should аt leаst signаl to me "hey this text field here thаt is аlmost аlwаys ASCII, well, todаy it's unicode." Or else I'm going to hаve to... cut аnd pаste the аddress bаr into а text editor every single link to confirm whаt it аctuаlly is, vs whаt I think my browser is showing me. 

BTW I replaced all the "a" with "а" in the above paragraph. Did anyone notice? I bet not (unless they're reading email in a terminal with no unicode support =). 





 

 

Thanks,

Shawn

 

Shawn Hernan, Principal Software Security Engineering Manager

Microsoft Azure Security Assurance

[hidden email]; <a href="tel:(425)%20703-7569" value="+14257037569" target="_blank">425-703-7569; @shawnhernan

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, June 19, 2017 8:26 AM
To: Barry, Jim <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>


Subject: Re: Request for comment - homophone attacks

 

 

 

On Mon, Jun 19, 2017 at 8:00 AM, Barry, Jim <[hidden email]> wrote:

Kurt,

 

The CWE and CAPEC teams have been looking into the proposals submitted by Kurt Seifried and would like to update the CWE community on the team's progress.

 

Based off of the original email, the CAPEC team will be creating 3 new CAPEC entries (typosquatting, soundsquatting, and homograph attack), which will be explained more in a subsequent email.

 

In terms of the CWE approach, the team is hoping for some clarification of the original email. When you say "a system doesn't give some indication that a URL/name/whatever is not in my normal character set", do you believe the browser should give the indication or some other 'system' should?

So up until recently domain names were restricted character set wise to a subset of ASCII. So it was always safe to assume that whatever was in the address bar was ASCII. Now with unicode my address bar is usually (probably most alway) ASCII, but it might also be unicode, with characters that look a lot like "seifried.org" for example but are in fact a Cyrillic character or something else. It would be nice for my address bar to give an indication, am I looking at ASCII? unicode? The fonts themselves in theory could do this (e.g. have very different type settings for non ascii chars) but I think it's better to leave this up to the UI to indicate what character set is present. 

 

 

The second question is, what is the underlying weakness of the attack you describe? In the original email, the primary concern is a URL which is either fully or partially comprised of a set of characters outside of the default set, which can lead a user to a malicious website. What weakness is being exploited here and how are the developers supposed to safeguard against this attack?

Ultimately it's people as always. Part of this is the fonts, some glyphs look an awful lot like each other but are totally different things, and in the case of DNS of course example.org and ėxample.org and exampłe.org (btw on my screen that ł looks like I have a bit of dust or some odd graphical glitch/artifact) are totally different things.

 

Since CWE currently focuses on software weaknesses, the team is trying to determine if there is anything the developers of an application can do differently to mitigate these attacks. Also, because a single weakness can often be addressed by different mitigations, the team typically does not create entries that focus on "failure to use specific mitigation X."  Such missing-mitigation characterizations provide a strong hint that the underlying weakness is not well-understood or has not yet been properly identified.  In this case, it seems that the attacker simply registers a similar looking URL and tricks a user into visiting that malicious URL, which is something that the developer cannot prevent.

Having an indication of what charset (e.g. set a "Default" like ascii, if it's ascii get a soothing blue background on the url, if it';s unicode give me an angry red) would be one way to go.

 

 

Any input or additional information allowing the CWE team to better understand the issue would be much appreciated.

 

Thank you,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng
Work <a href="tel:(781)%20271-3058" target="_blank">(781) 271-3058 | Mobile <a href="tel:(617)%20406-9278" target="_blank"> (617) 406-9278

 

MITRE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, May 8, 2017 11:13 AM
To: Jerome Athias <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

I would say much like the CWE-79 thing it would be nice to break this up a bit, especially with international domain names and easy access to TLS/SSL certs homophone attacks will become a much more prevalent problem for web stuff (and outside of web browsers, do many/any tls/ssl clients that display the hostname to people do it "right"?). 

 

On Mon, May 8, 2017 at 8:26 AM, Jerome Athias <[hidden email]> wrote:

Seems covered as homographs in CWE-451

I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 

What do you think?

 

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:

It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].




--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Joe Jarzombek
In reply to this post by Kurt Seifried
A mix of fonts (ASCII and non-ASCII) in a URL should warrant a 'suspicious' warning flag.

If nothing else that would be a poor practice.

Regards,

Joe Jarzombek


Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-----Original Message-----
From: Shawn Hernan [[hidden email]]
Received: Monday, 19 Jun 2017, 11:56AM
To: Kurt Seifried [[hidden email]]; Barry, Jim [[hidden email]]
CC: cwe-research-list CWE Research Discussion [[hidden email]]
Subject: RE: Request for comment - homophone attacks

I would be very reluctant to create a system that suggests that non-ASCII characters are somehow de facto suspicious.

 

Thanks,

Shawn

 

Shawn Hernan, Principal Software Security Engineering Manager

Microsoft Azure Security Assurance

[hidden email]; 425-703-7569; @shawnhernan

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, June 19, 2017 8:26 AM
To: Barry, Jim <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

 

 

On Mon, Jun 19, 2017 at 8:00 AM, Barry, Jim <[hidden email]> wrote:

Kurt,

 

The CWE and CAPEC teams have been looking into the proposals submitted by Kurt Seifried and would like to update the CWE community on the team's progress.

 

Based off of the original email, the CAPEC team will be creating 3 new CAPEC entries (typosquatting, soundsquatting, and homograph attack), which will be explained more in a subsequent email.

 

In terms of the CWE approach, the team is hoping for some clarification of the original email. When you say "a system doesn't give some indication that a URL/name/whatever is not in my normal character set", do you believe the browser should give the indication or some other 'system' should?

So up until recently domain names were restricted character set wise to a subset of ASCII. So it was always safe to assume that whatever was in the address bar was ASCII. Now with unicode my address bar is usually (probably most alway) ASCII, but it might also be unicode, with characters that look a lot like "seifried.org" for example but are in fact a Cyrillic character or something else. It would be nice for my address bar to give an indication, am I looking at ASCII? unicode? The fonts themselves in theory could do this (e.g. have very different type settings for non ascii chars) but I think it's better to leave this up to the UI to indicate what character set is present. 

 

 

The second question is, what is the underlying weakness of the attack you describe? In the original email, the primary concern is a URL which is either fully or partially comprised of a set of characters outside of the default set, which can lead a user to a malicious website. What weakness is being exploited here and how are the developers supposed to safeguard against this attack?

Ultimately it's people as always. Part of this is the fonts, some glyphs look an awful lot like each other but are totally different things, and in the case of DNS of course example.org and ėxample.org and exampłe.org (btw on my screen that ł looks like I have a bit of dust or some odd graphical glitch/artifact) are totally different things.

 

Since CWE currently focuses on software weaknesses, the team is trying to determine if there is anything the developers of an application can do differently to mitigate these attacks. Also, because a single weakness can often be addressed by different mitigations, the team typically does not create entries that focus on "failure to use specific mitigation X."  Such missing-mitigation characterizations provide a strong hint that the underlying weakness is not well-understood or has not yet been properly identified.  In this case, it seems that the attacker simply registers a similar looking URL and tricks a user into visiting that malicious URL, which is something that the developer cannot prevent.

Having an indication of what charset (e.g. set a "Default" like ascii, if it's ascii get a soothing blue background on the url, if it';s unicode give me an angry red) would be one way to go.

 

 

Any input or additional information allowing the CWE team to better understand the issue would be much appreciated.

 

Thank you,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng
Work <a href="tel:(781)%20271-3058" target="_blank">(781) 271-3058 | Mobile <a href="tel:(617)%20406-9278" target="_blank"> (617) 406-9278

 

MITRE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, May 8, 2017 11:13 AM
To: Jerome Athias <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

I would say much like the CWE-79 thing it would be nice to break this up a bit, especially with international domain names and easy access to TLS/SSL certs homophone attacks will become a much more prevalent problem for web stuff (and outside of web browsers, do many/any tls/ssl clients that display the hostname to people do it "right"?). 

 

On Mon, May 8, 2017 at 8:26 AM, Jerome Athias <[hidden email]> wrote:

Seems covered as homographs in CWE-451

I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 

What do you think?

 

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:

It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Kurt Seifried


On Mon, Jun 19, 2017 at 12:37 PM, Joe Jarzombek <[hidden email]> wrote:
A mix of fonts (ASCII and non-ASCII) in a URL should warrant a 'suspicious' warning flag.

If nothing else that would be a poor practice.

Regards,

Joe Jarzombek


On a related note: the address bar in Chrome for example rewrites:

gmаil.com as http://xn--gmil-63d.com/ so that's good, but I don't know if all web browsers do as an example. 


--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Wheeler, David A

On Mon, Jun 19, 2017 at 12:37 PM, Joe Jarzombek <[hidden email]> wrote:

> A mix of fonts (ASCII and non-ASCII) in a URL should warrant a 'suspicious' warning flag.  If nothing else that would be a poor practice.

 

Well, no.

 

The problem is that “it’s complicated”.  First, a nit: these aren’t fonts, they are Unicode characters, and the problem is that different Unicode values can have similar or equal glyphs (don’t get me started on combining characters, that’s fun too).  Also, as far as URLs go, there are two parts: DNS (where punycode lives) and everything else.

 

Anyway, as far as I know there aren’t any universally-accepted solutions.  Even within ASCII some symbols are easily confused, like “1” and “l” (paypal.com vs. paypa1.com).  My understanding is that in many languages you *have* mix character sets.  E.G., most languages use 0-9 for digits.  So “no mixing” is not practical.

 

In addition, detecting “mixing” isn’t enough. Many words can be spelling in solely Cyrillic & solely Latin letters so they look the same (like “epic”), but are different.  I think that “revelation” (which has been known for decades) has been the cause of the recent push, e.g.: https://www.ghacks.net/2017/04/17/punycode-phishing-attack-fools-even-die-hard-internet-veterans/ Many people assumed DNS registrars would be the guardians for DNS names & prevent this problem, but they aren’t actually *doing* that.

 

A “suspicious” warning might be helpful user-side (e.g., on the browser), because the user’s tools at least have access to the user’s primary language.  On non-mobile devices, and Firefox, you can get the complete list of languages the user finds acceptable.  For some reason iPhones and Androids assume users can only know one language, but for many user that’s basically true, and it’s easy to imagine future versions that are more flexible.  That said, it’d difficult to work out the algorithm, since attackers would know the algorithm too.  The bigger problem is that users routinely ignore warnings, so I suspect warnings won’t help very much no matter what.  I like the idea of always displaying punycode to everyone, possibly in addition to the decompressed form, but that has the same problem: Users ignore it.

 

If someone *does* know of a standard, widely-accepted way to counter these problems, I’d like to know about it!

 

If you’re an English-speaking Firefox user, a simple solution is to go to "about:config", and set "network.IDN_show_punycode" to “true”.  I’ve been doing that for a while, and it works well for me.  But I think it should be obvious why everyone isn’t excited about that solution.

 

Some discussions / sources:

https://news.ycombinator.com/item?id=14119713

http://www.unicode.org/Public/security/latest/confusables.txt

https://forums.theregister.co.uk/forum/1/2017/04/18/homograph_attack_again/

https://www.ghacks.net/2017/04/17/punycode-phishing-attack-fools-even-die-hard-internet-veterans/

http://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html

https://www.wired.com/2017/04/sneaky-exploit-allows-phishing-attacks-sites-look-secure/

 

--- David A. Wheeler

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Walter Houser
In reply to this post by Joe Jarzombek
It may not be a weakness but it is an exposure. 

See the Wikipedia discussion of "IDN homograph attack" at https://en.wikipedia.org/wiki/IDN_homograph_attack


Thank you.
Walt Houser
Application Security Engineer
301-351-6975 (cell)

On Mon, Jun 19, 2017 at 2:37 PM, Joe Jarzombek <[hidden email]> wrote:
A mix of fonts (ASCII and non-ASCII) in a URL should warrant a 'suspicious' warning flag.

If nothing else that would be a poor practice.

Regards,

Joe Jarzombek


Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-----Original Message-----
From: Shawn Hernan [[hidden email]]
Received: Monday, 19 Jun 2017, 11:56AM
To: Kurt Seifried [[hidden email]]; Barry, Jim [[hidden email]]
CC: cwe-research-list CWE Research Discussion [[hidden email]]
Subject: RE: Request for comment - homophone attacks

I would be very reluctant to create a system that suggests that non-ASCII characters are somehow de facto suspicious.

 

Thanks,

Shawn

 

Shawn Hernan, Principal Software Security Engineering Manager

Microsoft Azure Security Assurance

[hidden email]; <a href="tel:(425)%20703-7569" value="+14257037569" target="_blank">425-703-7569; @shawnhernan

 

 

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, June 19, 2017 8:26 AM
To: Barry, Jim <[hidden email]>
Cc: cwe-research-list CWE Research Discussion <[hidden email]>


Subject: Re: Request for comment - homophone attacks

 

 

 

On Mon, Jun 19, 2017 at 8:00 AM, Barry, Jim <[hidden email]> wrote:

Kurt,

 

The CWE and CAPEC teams have been looking into the proposals submitted by Kurt Seifried and would like to update the CWE community on the team's progress.

 

Based off of the original email, the CAPEC team will be creating 3 new CAPEC entries (typosquatting, soundsquatting, and homograph attack), which will be explained more in a subsequent email.

 

In terms of the CWE approach, the team is hoping for some clarification of the original email. When you say "a system doesn't give some indication that a URL/name/whatever is not in my normal character set", do you believe the browser should give the indication or some other 'system' should?

So up until recently domain names were restricted character set wise to a subset of ASCII. So it was always safe to assume that whatever was in the address bar was ASCII. Now with unicode my address bar is usually (probably most alway) ASCII, but it might also be unicode, with characters that look a lot like "seifried.org" for example but are in fact a Cyrillic character or something else. It would be nice for my address bar to give an indication, am I looking at ASCII? unicode? The fonts themselves in theory could do this (e.g. have very different type settings for non ascii chars) but I think it's better to leave this up to the UI to indicate what character set is present. 

 

 

The second question is, what is the underlying weakness of the attack you describe? In the original email, the primary concern is a URL which is either fully or partially comprised of a set of characters outside of the default set, which can lead a user to a malicious website. What weakness is being exploited here and how are the developers supposed to safeguard against this attack?

Ultimately it's people as always. Part of this is the fonts, some glyphs look an awful lot like each other but are totally different things, and in the case of DNS of course example.org and ėxample.org and exampłe.org (btw on my screen that ł looks like I have a bit of dust or some odd graphical glitch/artifact) are totally different things.

 

Since CWE currently focuses on software weaknesses, the team is trying to determine if there is anything the developers of an application can do differently to mitigate these attacks. Also, because a single weakness can often be addressed by different mitigations, the team typically does not create entries that focus on "failure to use specific mitigation X."  Such missing-mitigation characterizations provide a strong hint that the underlying weakness is not well-understood or has not yet been properly identified.  In this case, it seems that the attacker simply registers a similar looking URL and tricks a user into visiting that malicious URL, which is something that the developer cannot prevent.

Having an indication of what charset (e.g. set a "Default" like ascii, if it's ascii get a soothing blue background on the url, if it';s unicode give me an angry red) would be one way to go.

 

 

Any input or additional information allowing the CWE team to better understand the issue would be much appreciated.

 

Thank you,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng
Work <a href="tel:(781)%20271-3058" target="_blank">(781) 271-3058 | Mobile <a href="tel:(617)%20406-9278" target="_blank"> (617) 406-9278

 

MITRE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, May 8, 2017 11:13 AM
To: Jerome Athias <[hidden email]>
Cc: Kurt Seifried <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

I would say much like the CWE-79 thing it would be nice to break this up a bit, especially with international domain names and easy access to TLS/SSL certs homophone attacks will become a much more prevalent problem for web stuff (and outside of web browsers, do many/any tls/ssl clients that display the hostname to people do it "right"?). 

 

On Mon, May 8, 2017 at 8:26 AM, Jerome Athias <[hidden email]> wrote:

Seems covered as homographs in CWE-451

I see it as interesting, i.e. for "URL spoofing" (since it still happens CVE-2016-3276) 

What do you think?

 

On Sun, 7 May 2017 at 19:55, Kurt Seifried <[hidden email]> wrote:

It seems to me like a system that doesn't give some indication that a URL/name/whatever is not in my normal character set or let me easily check basically makes it much easier for such attacks to succeed (much like browsers that don't give good warnings for mangled SSL/TLS certs). Do we need to come up with some generic CWE for "displays different charset than expected with no hints making homophone attacks nearly sure to succeed"?

 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--


Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: 
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].



 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Jeffrey Walton
In reply to this post by Kurt Seifried
On Fri, May 5, 2017 at 10:55 PM, Kurt Seifried <[hidden email]> wrote:
> It seems to me like a system that doesn't give some indication that a
> URL/name/whatever is not in my normal character set or let me easily check
> basically makes it much easier for such attacks to succeed (much like
> browsers that don't give good warnings for mangled SSL/TLS certs). Do we
> need to come up with some generic CWE for "displays different charset than
> expected with no hints making homophone attacks nearly sure to succeed"?

Gutmann refers to it as "... the usual endless procession of Unicode
homograph/combining mark/right-to-left mark attacks" in his book
Engineering Security (chapter on Usability, p.472).

Jeff

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Kurt Seifried
So my email with the gmail example got binned by gmail as spam (which actually makes me happy):

Be careful with this message. Someone might be trying to trick you by using similar looking characters in their email address (for example replacing the letter "O" with the number "0").  Learn more

So clearly some people are aware of this and providing nice contextual warnings.

On Mon, Jun 19, 2017 at 3:56 PM, Jeffrey Walton <[hidden email]> wrote:
On Fri, May 5, 2017 at 10:55 PM, Kurt Seifried <[hidden email]> wrote:
> It seems to me like a system that doesn't give some indication that a
> URL/name/whatever is not in my normal character set or let me easily check
> basically makes it much easier for such attacks to succeed (much like
> browsers that don't give good warnings for mangled SSL/TLS certs). Do we
> need to come up with some generic CWE for "displays different charset than
> expected with no hints making homophone attacks nearly sure to succeed"?

Gutmann refers to it as "... the usual endless procession of Unicode
homograph/combining mark/right-to-left mark attacks" in his book
Engineering Security (chapter on Usability, p.472).

Jeff



--
Kurt Seifried
[hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Barry, Jim

All,

 

Thank you all for the feedback. This discussion has proven very useful and has allowed the CWE team to better understand the subject at hand. From this discussion, it sounds like we should add a new weakness about an application (e.g., a broswer) failing to inform

end users of varying character sets within a URL. This will take some time and we may reach back out to the community throughout the process to obtain further suggestions. Thank you all again for the input.

 

Thank you,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng
Work (781) 271-3058 | Mobile (617) 406-9278

 

MITRE

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Kurt Seifried
Sent: Monday, June 19, 2017 10:27 PM
To: [hidden email]
Cc: cwe-research-list CWE Research Discussion <[hidden email]>
Subject: Re: Request for comment - homophone attacks

 

So my email with the gmail example got binned by gmail as spam (which actually makes me happy):

 

Be careful with this message. Someone might be trying to trick you by using similar looking characters in their email address (for example replacing the letter "O" with the number "0").  Learn more

 

So clearly some people are aware of this and providing nice contextual warnings.

 

On Mon, Jun 19, 2017 at 3:56 PM, Jeffrey Walton <[hidden email]> wrote:

On Fri, May 5, 2017 at 10:55 PM, Kurt Seifried <[hidden email]> wrote:
> It seems to me like a system that doesn't give some indication that a
> URL/name/whatever is not in my normal character set or let me easily check
> basically makes it much easier for such attacks to succeed (much like
> browsers that don't give good warnings for mangled SSL/TLS certs). Do we
> need to come up with some generic CWE for "displays different charset than
> expected with no hints making homophone attacks nearly sure to succeed"?

Gutmann refers to it as "... the usual endless procession of Unicode
homograph/combining mark/right-to-left mark attacks" in his book
Engineering Security (chapter on Usability, p.472).

Jeff



 

--

Kurt Seifried
[hidden email]

To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Wheeler, David A

Jim Barry:

 

> Thank you all for the feedback. This discussion has proven very useful and has allowed the CWE team to better understand the subject at hand. From this discussion, it sounds like we should add a new weakness about an application (e.g., a broswer) failing to inform end users of varying character sets within a URL. This will take some time and we may reach back out to the community throughout the process to obtain further suggestions. Thank you all again for the input.

 

NO!!! NO!!! NO!!!  The problem is *NOT* that there are varying character sets within something.  Since that is not the problem, “solving” it will not produce a solution.

 

The problem is that “what the user interprets as what he’s seeing != what is actually there.”  I would call those “homograph” or “homophone” attacks (depending on if it’s visual or audiot).

 

Even within ASCII you can have trouble  E.G., “paypa1.com” and “paypal.com” are in the same script, but are easily confused.  So it’s not “mixing character sets” that’s the problem anyway – all-ASCII is already a problem.

 

But with DNS punycode, every character could be in the *same* character set within a DNS label and *still* be misinterpreted, because many people don’t read multiple scripts.  Cyrillic, Latin, and Greek share a number of glyphs, so a DNS name in all-Cyrillic is different than one in all-Latin, even if they look identical.  E.G., “еуе.com” and “eye.com” look identical, but the first is in all-Cyrillic and the second is in all-Latin.

 

The problem is that (1) punycode allows arbitrary characters, even if they look identical.  Historically the notion was “no problem, registrars will deal with that” - but the explosion of the sites means that at least some registrars have abandoned their historical role as detectors of misleading site names (it’s not clear they could do that job anyway).  So the historical “solution” has failed & we have no plan B.

 

--- David A. Wheeler

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Joe Jarzombek

David –

 

You are correct; yet you would probably agree that using varying character sets within a URL would warrant a ‘suspicious’ flag that could be used to inform end users.  This alone does not solve world hunger; nor address all the issues with using one character set.  However, it does identify part of the problem.  Therefore, I recommend that it should be introduced as a new CWE.

 

Regards,

 

   -Joe -

 

Joe Jarzombek, CSSLP 

Global Manager, Software Supply Chain Solutions

Email: [hidden email]  |  Mobile: 703 627-4644

Synopsys Software Integrity Group  |  www.synopsys.com/software  cid:image002.jpg@01D23376.09F8BF20  cid:image003.jpg@01D23376.09F8BF20  cid:image004.jpg@01D23376.09F8BF20

SynopsysSiliconToSoftware

See my editorial in CrossTalk Sponsor’s Note on Supply Chain Risk in Critical Infrastructure http://bit.ly/2cb6OHU

See my QAI Global Institute webinar on “Cybersecurity Technical Risk Indicators: A Measure of Technical Debt” at https://vimeo.com/206456054 | Download Presentation Slides  

Synopsys Named a Leader in AppSec Testing in Gartner’s 2017 Magic Quadrant – see https://software.synopsys.com/2017-gartner-magic-quadrant.html

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Wheeler, David A
Sent: Friday, June 23, 2017 3:06 PM
To: Barry, Jim <[hidden email]>; cwe-research-list CWE Research Discussion <[hidden email]>
Subject: RE: Request for comment - homophone attacks

 

Jim Barry:

 

> Thank you all for the feedback. This discussion has proven very useful and has allowed the CWE team to better understand the subject at hand. From this discussion, it sounds like we should add a new weakness about an application (e.g., a broswer) failing to inform end users of varying character sets within a URL. This will take some time and we may reach back out to the community throughout the process to obtain further suggestions. Thank you all again for the input.

 

NO!!! NO!!! NO!!!  The problem is *NOT* that there are varying character sets within something.  Since that is not the problem, “solving” it will not produce a solution.

 

The problem is that “what the user interprets as what he’s seeing != what is actually there.”  I would call those “homograph” or “homophone” attacks (depending on if it’s visual or audiot).

 

Even within ASCII you can have trouble  E.G., “paypa1.com” and “paypal.com” are in the same script, but are easily confused.  So it’s not “mixing character sets” that’s the problem anyway – all-ASCII is already a problem.

 

But with DNS punycode, every character could be in the *same* character set within a DNS label and *still* be misinterpreted, because many people don’t read multiple scripts.  Cyrillic, Latin, and Greek share a number of glyphs, so a DNS name in all-Cyrillic is different than one in all-Latin, even if they look identical.  E.G., “еуе.com” and “eye.com” look identical, but the first is in all-Cyrillic and the second is in all-Latin.

 

The problem is that (1) punycode allows arbitrary characters, even if they look identical.  Historically the notion was “no problem, registrars will deal with that” - but the explosion of the sites means that at least some registrars have abandoned their historical role as detectors of misleading site names (it’s not clear they could do that job anyway).  So the historical “solution” has failed & we have no plan B.

 

--- David A. Wheeler

 

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Wheeler, David A
I recommend adding a new CWE, but the CWE needs to be something like "displayed characters confuse user into thinking it's something else".  The CWE must NOT be "mixes character scripts within a range".  The latter is an attempted "solution" for the weakness, not the weakness itself.  I believe that the CWEs should focus on the *problem* not the *solution*.  In addition, for most people in the world "don't mix" is a useless & unacceptable "solution".  That solution works if you only read sites written in English, but not in many other places.

More details below!


Joe Jarzombek:
> You are correct; yet you would probably agree that using varying character sets within a URL would warrant a ‘suspicious’ flag that could be used to inform end users.

No, I wouldn't agree at all.  For many users of languages other than English that would be an absurd & useless flag.  Let's focus just on DNS names.  In many locales admixture is required behavior.  E.G., the digits 0-9 are in the ASCII/Basic Latin set, but these "Arabic" digits are widely used in other locales (e.g., Cyrillic).  Many locales use mixed scripts.  So this rule would invalidate many *legitimate* sites... making it a useless rule.

If you can only read/write English, then *any* other scripts are not just highly suspicious, they're dangerous & probably should be blocked by default.  If you read/write other languages, then blocking those other scripts is absurd.  Which ones?  Well, that depends on the scripts that the user can accept, and that's hard to answer (even with the list of allowed locales it's tricky, though a solution may be workable in that direction).

I'm not a linguist, but I'm just wrapping up internationalizing the CII Best Practices Badge work at <https://bestpractices.coreinfrastructure.org/>.  My experience is that internationalization is *tricky*, and things that English-only speakers think are constants turn out to be variables.

> This alone does not solve world hunger; nor address all the issues with using one character set.  However, it does identify part of the problem.  Therefore, I recommend that it should be introduced as a new CWE.

Solve world hunger? This approach doesn't even provide an individual snack :-).

Someone else recently registered "saic.com" and "raytheon.com" using Cyrillic letters.  The DNS name isn't mixed (it's all Cyrillic before "."), so this "solution" wouldn't even counter this simple example!

In short, a "no mixture" rule fails to identify many problems, while simultaneously forbidding legitimate sites.

I'm not saying this can't be solved, but a solution that can work worldwide among non-English-speakers has to be more sophisticated.  I'd really like to see people working on better solutions to this!

--- David A. Wheeler

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Kurt Seifried-2



On 2017-06-26 2:00 PM, Shawn Hernan wrote:
My experience is that internationalization is *tricky*, and things that English-only speakers think are constants turn out to be variables.
This is very, very true. 

Suggesting that the used of mixed scripts is "bad" is ignoring a large set of perfectly valid international use cases. 
And emoji domains now! (.ws, e.g. i❤️tacos.ws)!

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: [hidden email]
To unsubscribe, send an email message to [hidden email] with SIGNOFF CWE-RESEARCH-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Request for comment - homophone attacks

Christey, Steven M.
In reply to this post by Wheeler, David A
Thank you, everybody, for continuing to dig into and debate this.  No wonder the phishing problem hasn't been solved yet ;-)  In my personal opinion, Shawn appears to be getting closer to a "root cause" for the issue.

We are closely reading all these discussions and considering how (and whether) to frame some kind of technology-oriented CWE entry around it, beyond the current suggestion.

If any readers have implemented any specific mitigations within software to mitigate homograph and related attacks - without overly inconveniencing users - we would love to hear it.

- Steve


> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Shawn Hernan
> Sent: Monday, June 26, 2017 4:01 PM
> To: Wheeler, David A <[hidden email]>; Joe Jarzombek
> <[hidden email]>; Barry, Jim <[hidden email]>; cwe-research-
> list CWE Research Discussion <[hidden email]>
> Subject: RE: Request for comment - homophone attacks
>
> > My experience is that internationalization is *tricky*, and things that English-
> only speakers think are constants turn out to be variables.
>
> This is very, very true.
>
> Suggesting that the used of mixed scripts is "bad" is ignoring a large set of
> perfectly valid international use cases.
>
> At the same time, the suggestion from David of  "displayed characters confuse
> user into thinking it's something else" feels like a statement of an unsolvable
> problem: humans can be tricked.
>
> It seems to me that the "problem" is contextual: user agents present
> inappropriate trust decisions to the user: did a legitimate CA sign this cert?
> Instead, user agents ought to present a much richer data set to the user: have I
> interacted with this site before? Is this name close to (by Hamming distance)
> some other name that I've used before? How long has this site been in
> existence? Is there any reputation data for this site? Did I get here via a link or
> did I type the URL myself?
>
> We're a long way from a plausible UX to present that level of information (or act
> upon it on the user's behalf) of course, but CWE doesn’t necessarily have to
> concern itself with solutions directly.
>
>
> Shawn Hernan, Principal Software Security Engineering Manager
> Microsoft Azure Security Assurance
> [hidden email]; 425-703-7569; @shawnhernan
>
>
>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:owner-cwe-research-
> > [hidden email]] On Behalf Of Wheeler, David A
> > Sent: Monday, June 26, 2017 9:44 AM
> > To: Joe Jarzombek <[hidden email]>; Barry, Jim
> > <[hidden email]>; cwe-research-list CWE Research Discussion <cwe-
> research-
> > [hidden email]>
> > Subject: RE: Request for comment - homophone attacks
> >
> > I recommend adding a new CWE, but the CWE needs to be something like
> > "displayed characters confuse user into thinking it's something else".  The CWE
> > must NOT be "mixes character scripts within a range".  The latter is an
> > attempted "solution" for the weakness, not the weakness itself.  I believe that
> > the CWEs should focus on the *problem* not the *solution*.  In addition, for
> > most people in the world "don't mix" is a useless & unacceptable "solution".
> > That solution works if you only read sites written in English, but not in many
> > other places.
> >
> > More details below!
> >
> >
> > Joe Jarzombek:
> > > You are correct; yet you would probably agree that using varying character
> > sets within a URL would warrant a ‘suspicious’ flag that could be used to
> inform
> > end users.
> >
> > No, I wouldn't agree at all.  For many users of languages other than English
> that
> > would be an absurd & useless flag.  Let's focus just on DNS names.  In many
> > locales admixture is required behavior.  E.G., the digits 0-9 are in the
> ASCII/Basic
> > Latin set, but these "Arabic" digits are widely used in other locales (e.g.,
> Cyrillic).
> > Many locales use mixed scripts.  So this rule would invalidate many
> *legitimate*
> > sites... making it a useless rule.
> >
> > If you can only read/write English, then *any* other scripts are not just highly
> > suspicious, they're dangerous & probably should be blocked by default.  If you
> > read/write other languages, then blocking those other scripts is absurd.  Which
> > ones?  Well, that depends on the scripts that the user can accept, and that's
> > hard to answer (even with the list of allowed locales it's tricky, though a
> solution
> > may be workable in that direction).
> >
> > I'm not a linguist, but I'm just wrapping up internationalizing the CII Best
> > Practices Badge work at
> >
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbestpra
> >
> ctices.coreinfrastructure.org%2F&data=02%7C01%7Cshernan%40MICROSOFT.
> > COM%7Cc05c94ecfbe742e1aeb808d4bcbec33c%7C72f988bf86f141af91ab2d7
> > cd011db47%7C1%7C0%7C636340974911751531&sdata=CWIBPnT3ZOfWoqK
> > XL1zs9YArzXXMjlZrM1CepcaFNy4%3D&reserved=0>.  My experience is that
> > internationalization is *tricky*, and things that English-only speakers think are
> > constants turn out to be variables.
> >
> > > This alone does not solve world hunger; nor address all the issues with using
> > one character set.  However, it does identify part of the problem.  Therefore, I
> > recommend that it should be introduced as a new CWE.
> >
> > Solve world hunger? This approach doesn't even provide an individual snack :-).
> >
> > Someone else recently registered "saic.com" and "raytheon.com" using Cyrillic
> > letters.  The DNS name isn't mixed (it's all Cyrillic before "."), so this "solution"
> > wouldn't even counter this simple example!
> >
> > In short, a "no mixture" rule fails to identify many problems, while
> > simultaneously forbidding legitimate sites.
> >
> > I'm not saying this can't be solved, but a solution that can work worldwide
> > among non-English-speakers has to be more sophisticated.  I'd really like to
> see
> > people working on better solutions to this!
> >
> > --- David A. Wheeler

Loading...