Request for comment - homophone attacks

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Jerome Athias-2
Punycode is, as of now, managed differently by the browsers, natively/via config/via plugin.



-------- Original Message --------
Subject: RE: Request for comment - homophone attacks
Local Time: June 27, 2017 12:05 AM
UTC Time: June 26, 2017 9:05 PM
To: Shawn Hernan <[hidden email]>, "Wheeler, David A" <[hidden email]>, Joe Jarzombek <[hidden email]>, "Barry, Jim" <[hidden email]>, cwe-research-list CWE Research Discussion <[hidden email]>

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-
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Barry, Jim
In reply to this post by Christey, Steven M.

Good Morning All,

 

Thank you for the continued discussion regarding this topic. After reviewing the feedback we have received, the CWE team has decided to add a new CWE entry to address the issue of an application not sufficiently notifying a user of the use of homoglyphs. The CWE team has begun drafting the new CWE, which we plan on making a child of CWE-451: User Interface (UI) Misrepresentation of Critical Information. Below are the summary and extended descriptions for this CWE, which should give a sense of the weakness we wish to discuss:

 

CWE-XXX: Insufficient Visual Distinction of Homoglyphs Presented to User

 

Summary: The software displays information or identifiers to a user, but the display mechanism does not make it easy for the user to distinguish between visually similar glyphs (homoglyphs), which may cause the user to misinterpret a glyph and perform an unintended, insecure action.

 

Extended Description: Some glyphs, pictures, or icons can be semantically distinct to a program, while appearing very similar to a human user.  These are referred to as homoglyphs.  For example, in some fonts, the lowercase "l" (ell) and uppercase "I" (eye) have different character codes that allows a program to recognize that they are different, but these characters can be displayed in exactly the same way to a user.  Attackers can exploit this visual similarity for attacks such as phishing, e.g. by providing a link to an attacker-controlled host name that looks like a hostname that the victim trusts.  In a different use of homoglyphs, an attacker may create a back door username that is visually similar to the username of a regular user, which then makes it more difficult for a system administrator to detect the malicious username while reviewing logs.

 

While the additional CWE sections are being worked on, the CWE team would like feedback from the community regarding the above sections. We would also appreciate any suggestions or examples for the mitigations section, as this was one of the major topics of discussion on the mailing list thread. Any additional comments and suggestions are also welcomed and appreciated.

 

Thank you all again for the continuous discussion and feedback,

Jim

 

Jim Barry

Cyber Security Engineer

J83K | Systems Analysis & Reverse Eng

Work (781) 271-3058 | Mobile (617) 406-9278

 

MITRE

 

-----Original Message-----
From: Christey, Steven M.
Sent: Monday, June 26, 2017 5:06 PM
To: Shawn Hernan <[hidden email]>; 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

 

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%2Fbest

> pra

> >

> 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

 

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Kurt Seifried-2
On 07/10/2017 08:20 AM, Barry, Jim wrote:

> Good Morning All,
>
>  
>
> Thank you for the continued discussion regarding this topic. After
> reviewing the feedback we have received, the CWE team has decided to add
> a new CWE entry to address the issue of an application not sufficiently
> notifying a user of the use of homoglyphs. The CWE team has begun
> drafting the new CWE, which we plan on making a child of CWE-451: User
> Interface (UI) Misrepresentation of Critical Information. Below are the
> summary and extended descriptions for this CWE, which should give a
> sense of the weakness we wish to discuss:
>
>  
>
> *CWE-XXX: Insufficient Visual Distinction of Homoglyphs Presented to User*
>
>  
>
> *Summary:* The software displays information or identifiers to a user,
> but the display mechanism does not make it easy for the user to
> distinguish between visually similar glyphs (homoglyphs), which may
> cause the user to misinterpret a glyph and perform an unintended,
> insecure action.

Maybe make a mention that it's also about the fact that ascii vs.
unicode is being presented, e.g. most apps only handled ascii until
recently and most users are not expecting unicode yet.

>
>  
>
> *Extended Description:* Some glyphs, pictures, or icons can be
> semantically distinct to a program, while appearing very similar to a
> human user.  These are referred to as homoglyphs.  For example, in some
> fonts, the lowercase "l" (ell) and uppercase "I" (eye) have different
> character codes that allows a program to recognize that they are
> different, but these characters can be displayed in exactly the same way
> to a user.  Attackers can exploit this visual similarity for attacks
> such as phishing, e.g. by providing a link to an attacker-controlled
> host name that looks like a hostname that the victim trusts.  In a
> different use of homoglyphs, an attacker may create a back door username
> that is visually similar to the username of a regular user, which then
> makes it more difficult for a system administrator to detect the
> malicious username while reviewing logs.
>
>  
>
> While the additional CWE sections are being worked on, the CWE team
> would like feedback from the community regarding the above sections. We
> would also appreciate any suggestions or examples for the mitigations
> section, as this was one of the major topics of discussion on the
> mailing list thread. Any additional comments and suggestions are also
> welcomed and appreciated.
>
>  
>
> Thank you all again for the continuous discussion and feedback,
>
> Jim
>
>  
>
> Jim Barry
>
> Cyber Security Engineer
>
> J83K | Systems Analysis & Reverse Eng
>
> Work (781) 271-3058 | Mobile (617) 406-9278
>
>  
>
> MITRE
>
>  
>
> -----Original Message-----
> From: Christey, Steven M.
> Sent: Monday, June 26, 2017 5:06 PM
> To: Shawn Hernan <[hidden email]>; 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
>
>  
>
> 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:[hidden email]>
>
>> [mailto:owner-cwe-research- [hidden email]
> <mailto:[hidden email]>] On Behalf Of Shawn
>
>> Hernan
>
>> Sent: Monday, June 26, 2017 4:01 PM
>
>> To: Wheeler, David A <[hidden email] <mailto:[hidden email]>>; Joe
> Jarzombek
>
>> <[hidden email] <mailto:[hidden email]>>;
> Barry, Jim <[hidden email] <mailto:[hidden email]>>;
>
>> cwe-research- list CWE Research Discussion
>
>> <[hidden email]
> <mailto:[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]
> <mailto:[hidden email]>;
>
>> 425-703-7569; @shawnhernan
>
>>
>
>>
>
>>
>
>>
>
>> > -----Original Message-----
>
>> > From: [hidden email]
> <mailto:[hidden email]>
>
>> > [mailto:owner-cwe-research- [hidden email]
> <mailto:[hidden email]>] On Behalf Of
>
>> > Wheeler, David A
>
>> > Sent: Monday, June 26, 2017 9:44 AM
>
>> > To: Joe Jarzombek <[hidden email]
> <mailto:[hidden email]>>; Barry, Jim
>
>> > <[hidden email] <mailto:[hidden email]>>; cwe-research-list CWE
> Research Discussion <cwe-
>
>> research-
>
>> > [hidden email] <mailto:[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%2Fbest
>
>> pra
>
>> >
>
>> 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
>
>  
>

--

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
|

Re: Request for comment - homophone attacks

Wheeler, David A
On 07/10/2017 08:20 AM, Barry, Jim wrote:
> > Thank you for the continued discussion regarding this topic. After
> > reviewing the feedback we have received, the CWE team has decided to
> > add a new CWE entry to address the issue of an application not
> > sufficiently notifying a user of the use of homoglyphs. The CWE team
> > has begun drafting the new CWE, which we plan on making a child of
> > CWE-451: User Interface (UI) Misrepresentation of Critical
> > Information. Below are the summary and extended descriptions for this
> > CWE, which should give a sense of the weakness we wish to discuss:

> > *Summary:* The software displays information or identifiers to a user,
> > but the display mechanism does not make it easy for the user to
> > distinguish between visually similar glyphs (homoglyphs), which may
> > cause the user to misinterpret a glyph and perform an unintended,
> > insecure action.

I would say "visually similar or identical glyphs".  For example, in most fonts Greek and Latin "A" are bit-for-bit identical.



[hidden email] [mailto:[hidden email]] on Monday, July 10, 2017 10:47 AM:
> Maybe make a mention that it's also about the fact that ascii vs.
> unicode is being presented, e.g. most apps only handled ascii until recently
> and most users are not expecting unicode yet.

That has *certainly* increased the incidence of it, but "paypal.com" vs. "paypaI.com" vs. "paypa1.com" (and its many variants) is also an example of this problem, and that's pure ASCII.

> > *Extended Description:* Some glyphs, pictures, or icons can be
> > semantically distinct to a program, while appearing very similar to a

s/similar/similar or identical/

> > human user.  These are referred to as homoglyphs.  For example, in
> > some fonts, the lowercase "l" (ell) and uppercase "I" (eye) have
> > different character codes that allows a program to recognize that they
> > are different, but these characters can be displayed in exactly the
> > same way to a user.

I agree with this example - it's important to show it can happen within the same character code range.

But I would *add* an additional example that demonstrates that it can happen *between* character ranges, because a lot of people don't think about that. E.G., add this:

Another example is uppercase Latin "A" and upper case Greek "A", which programs will typically treat as distinct but will be displayed in exactly the same way to a user.

--- David A. Wheeler

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Wheeler, David A
In reply to this post by Kurt Seifried-2
For completeness, here are some related URLs.

I don't think it's completely current, but this Wikipedia article *does* mention some (attempted) countermeasures for homophone attacks (as well as background material):
  https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_the_attack

There seems to be widespread agreement that the current measures aren’t enough, e.g.:
  http://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html

This is an old well-known attack, and it definitely needs one or more CWE entries.  I don't think you need to wait for a solution to create a CWE entry; it's a common type of vulnerability, so add it, and then start recording solutions.

You might argue that homograph attacks on domain names, or internationalized domain names (IDNs), are an important special cause & thus should be a child of the more general homophone problem.  Domain names are arguably special because they're used by users to determine "what part of the Internet I'm interacting with".  Also, some of the countermeasures might be more unique to IDNs, e.g., showing punycode instead of just the IDN.

--- David A .Wheeler

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Kurt Seifried-2
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.


Do we want to add bit-squatting? http://dinaburg.org/bitsquatting.html
 

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?

Yes, am I looking at ascii, or am I looking at unicode is the main question. Basically everything currently supports ascii, and some of it supports unicode, but almost none give me any indication of what I'm looking at. Thus I might think I'm looking at ascii and it's actually unicode with that cyrillic "a" for example. 
  

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?


The main thing is I can construct a string of text that looks almost identical to another string of text, but is very different. This is super critical with DNS (as I can register that DNS domain and get your web requests/email/etc). For example depending on how auto complete works I could email you from kseifried@redhаt.com, it auto adds to your address book, and in future when you type "kseifried..." it pops up what looks like a legit [hidden email]. Ditto for web browsers.

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.

So you can explicitly do things like:

1) give a hint/display explicitly what encoding is in use (ascii vs unicode), possibly make it a toggle switch, for example "warn on usage of unicode in email addresses" or better yet "Warn on usage of unicode characters known to be similar to ascii characters"
2) ensure that any auto sort/auto complete/etc is explicit (e.g. sort ascii first or unicode first, but don't make me guess)
 

 

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 -- 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
|

Re: Request for comment - homophone attacks

Kurt Seifried
In reply to this post by Wheeler, David A
So it's happened now:


We really need something to classify this and provide some guidance to devs (e.g. display a warning that the name isn't just ascii, etc.). Also something specific for unicode whitespace probably.


On Mon, Jul 17, 2017 at 12:49 PM, Wheeler, David A <[hidden email]> wrote:
For completeness, here are some related URLs.

I don't think it's completely current, but this Wikipedia article *does* mention some (attempted) countermeasures for homophone attacks (as well as background material):
  https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_the_attack

There seems to be widespread agreement that the current measures aren’t enough, e.g.:
  http://thehackernews.com/2017/04/unicode-Punycode-phishing-attack.html

This is an old well-known attack, and it definitely needs one or more CWE entries.  I don't think you need to wait for a solution to create a CWE entry; it's a common type of vulnerability, so add it, and then start recording solutions.

You might argue that homograph attacks on domain names, or internationalized domain names (IDNs), are an important special cause & thus should be a child of the more general homophone problem.  Domain names are arguably special because they're used by users to determine "what part of the Internet I'm interacting with".  Also, some of the countermeasures might be more unique to IDNs, e.g., showing punycode instead of just the IDN.

--- David A .Wheeler




--
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
|

Re: Request for comment - homophone attacks

Andrew Buttner
Administrator
All,

There is a new CWE in the upcoming release specifically for this type of issue. This new weakness was created based on the conversation we have had over this list.

CWE-1007 : Insufficient Visual Distinction of Homoglyphs Presented to User

The release is scheduled for this week. It a major release (the first major CWE release in many years) and includes an improved schema, a new architecture view, a few new individual weaknesses, continued improvement to the developer view, as well as countless content fixes. Unfortunately it has taken us longer than expected to get things staged correctly with the new schema and post everything to the website.  These issues have been resolved and we are going through out final testing.

In addition to the new weakness, there already exists an attack pattern for these types of issues.

CAPEC-63 : Homograph Attack via Homoglyphs

Thanks
Drew



cwe-research-list CWE Research Discussion <[hidden email]>



> -----Original Message-----
> From: [hidden email] [mailto:owner-cwe-research-
> [hidden email]] On Behalf Of Kurt Seifried
> Sent: Sunday, November 5, 2017 11:17 AM
> To: Wheeler, David A <[hidden email]>
> Cc: [hidden email]; Barry, Jim <[hidden email]>; Christey, Steven
> M. <[hidden email]>; Shawn Hernan <[hidden email]>; Joe
> Jarzombek <[hidden email]>; cwe-research-list CWE
> Research Discussion <[hidden email]>
> Subject: Re: Request for comment - homophone attacks
>
> So it's happened now:
>
> https://twitter.com/virqdroid/status/926437790140772362
>
>
> We really need something to classify this and provide some guidance to devs
> (e.g. display a warning that the name isn't just ascii, etc.). Also something
> specific for unicode whitespace probably.
>
>
> On Mon, Jul 17, 2017 at 12:49 PM, Wheeler, David A <[hidden email]
> <mailto:[hidden email]> > wrote:
>
>
> For completeness, here are some related URLs.
>
> I don't think it's completely current, but this Wikipedia article *does*
> mention some (attempted) countermeasures for homophone attacks (as
> well as background material):
>
> https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_t
> he_attack
> <https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against
> _the_attack>
>
> There seems to be widespread agreement that the current
> measures aren’t enough, e.g.:
>  http://thehackernews.com/2017/04/unicode-Punycode-phishing-
> attack.html <http://thehackernews.com/2017/04/unicode-Punycode-
> phishing-attack.html>
>
> This is an old well-known attack, and it definitely needs one or more
> CWE entries.  I don't think you need to wait for a solution to create a CWE
> entry; it's a common type of vulnerability, so add it, and then start recording
> solutions.
>
> You might argue that homograph attacks on domain names, or
> internationalized domain names (IDNs), are an important special cause &
> thus should be a child of the more general homophone problem.  Domain
> names are arguably special because they're used by users to determine
> "what part of the Internet I'm interacting with".  Also, some of the
> countermeasures might be more unique to IDNs, e.g., showing punycode
> instead of just the IDN.
>
> --- David A .Wheeler
>
>
>
>
>
>
> --
>
> Kurt Seifried
> [hidden email] <mailto:[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 CWE-RESEARCH-
> [hidden email].
Reply | Threaded
Open this post in threaded view
|

CQE in CWE?

Joe Jarzombek
Will there be any use or reference to CQE in the release of CWE 3.0?

Joe

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

-----Original Message-----
From: Buttner, Drew [[hidden email]]
Received: Monday, 06 Nov 2017, 5:35AM
To: cwe-research-list CWE Research Discussion [[hidden email]]
Subject: RE: Request for comment - homophone attacks

All,



There is a new CWE in the upcoming release specifically for this type of issue. This new weakness was created based on the conversation we have had over this list.



CWE-1007 : Insufficient Visual Distinction of Homoglyphs Presented to User



The release is scheduled for this week. It a major release (the first major CWE release in many years) and includes an improved schema, a new architecture view, a few new individual weaknesses, continued improvement to the developer view, as well as countless content fixes. Unfortunately it has taken us longer than expected to get things staged correctly with the new schema and post everything to the website.  These issues have been resolved and we are going through out final testing.



In addition to the new weakness, there already exists an attack pattern for these types of issues.



CAPEC-63 : Homograph Attack via Homoglyphs



Thanks

Drew







cwe-research-list CWE Research Discussion <[hidden email]>







> -----Original Message-----

> From: [hidden email] [mailto:owner-cwe-research-

> [hidden email]] On Behalf Of Kurt Seifried

> Sent: Sunday, November 5, 2017 11:17 AM

> To: Wheeler, David A <[hidden email]>

> Cc: [hidden email]; Barry, Jim <[hidden email]>; Christey, Steven

> M. <[hidden email]>; Shawn Hernan <[hidden email]>; Joe

> Jarzombek <[hidden email]>; cwe-research-list CWE

> Research Discussion <[hidden email]>

> Subject: Re: Request for comment - homophone attacks

>

> So it's happened now:

>

> https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_virqdroid_status_926437790140772362&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=dkC8NtFz4MZtYhm-PbXuXtLrPT7e07-ki3QmNcQmy4k&e=

>

>

> We really need something to classify this and provide some guidance to devs

> (e.g. display a warning that the name isn't just ascii, etc.). Also something

> specific for unicode whitespace probably.

>

>

> On Mon, Jul 17, 2017 at 12:49 PM, Wheeler, David A <[hidden email]

> <[hidden email]> > wrote:

>

>

>        For completeness, here are some related URLs.

>

>        I don't think it's completely current, but this Wikipedia article *does*

> mention some (attempted) countermeasures for homophone attacks (as

> well as background material):

>

> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_IDN-5Fhomograph-5Fattack-23Defending-5Fagainst-5Ft&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=GbTj6hflTuiWx4ANo52-4k7o8RIYa4KsU_TzgpU3NPs&e=

> he_attack

> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_IDN-5Fhomograph-5Fattack-23Defending-5Fagainst&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=F2_HCyCa2WoNE7eMTRM1ApT_j3xxo8GkY9zPPsY5aaw&e=

> _the_attack>

>

>        There seems to be widespread agreement that the current

> measures aren’t enough, e.g.:

>          https://urldefense.proofpoint.com/v2/url?u=http-3A__thehackernews.com_2017_04_unicode-2DPunycode-2Dphishing-2D&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=Hb6W-muTNNa19o6E3J7HmuOA7ezJplkxYKsGM9VLu1Y&e=

> attack.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__thehackernews.com_2017_04_unicode-2DPunycode-2D&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=673Bqa3WjaORA79sbiDdbhKiBJoaieyGIJo6cmSvxTk&e=

> phishing-attack.html>

>

>        This is an old well-known attack, and it definitely needs one or more

> CWE entries.  I don't think you need to wait for a solution to create a CWE

> entry; it's a common type of vulnerability, so add it, and then start recording

> solutions.

>

>        You might argue that homograph attacks on domain names, or

> internationalized domain names (IDNs), are an important special cause &

> thus should be a child of the more general homophone problem.  Domain

> names are arguably special because they're used by users to determine

> "what part of the Internet I'm interacting with".  Also, some of the

> countermeasures might be more unique to IDNs, e.g., showing punycode

> instead of just the IDN.

>

>        --- David A .Wheeler

>

>

>

>

>

>

> --

>

> Kurt Seifried

> [hidden email] <[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 CWE-RESEARCH-

> [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
|

Re: CQE in CWE?

Andrew Buttner
Administrator
Unfortunately no, we have not had a chance to look into merging this in. It is on our list for future work though.

Thanks
Drew



> -----Original Message-----
> From: Joe Jarzombek [mailto:[hidden email]]
> Sent: Monday, November 6, 2017 6:47 AM
> To: cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>; Buttner, Drew <[hidden email]>
> Subject: CQE in CWE?
>
> Will there be any use or reference to CQE in the release of CWE 3.0?
>
> Joe
>
> Sent from my Android phone using Symantec TouchDown
> (www.symantec.com)
>
> -----Original Message-----
> From: Buttner, Drew [[hidden email]]
> Received: Monday, 06 Nov 2017, 5:35AM
> To: cwe-research-list CWE Research Discussion [cwe-research-
> [hidden email]]
> Subject: RE: Request for comment - homophone attacks
>
>
> All,
>
>
>
> There is a new CWE in the upcoming release specifically for this type of issue.
> This new weakness was created based on the conversation we have had
> over this list.
>
>
>
> CWE-1007 : Insufficient Visual Distinction of Homoglyphs Presented to User
>
>
>
> The release is scheduled for this week. It a major release (the first major
> CWE release in many years) and includes an improved schema, a new
> architecture view, a few new individual weaknesses, continued
> improvement to the developer view, as well as countless content fixes.
> Unfortunately it has taken us longer than expected to get things staged
> correctly with the new schema and post everything to the website.  These
> issues have been resolved and we are going through out final testing.
>
>
>
> In addition to the new weakness, there already exists an attack pattern for
> these types of issues.
>
>
>
> CAPEC-63 : Homograph Attack via Homoglyphs
>
>
>
> Thanks
>
> Drew
>
>
>
>
>
>
>
> cwe-research-list CWE Research Discussion <cwe-research-
> [hidden email]>
>
>
>
>
>
>
>
> > -----Original Message-----
>
> > From: [hidden email] [mailto:owner-cwe-
> research-
>
> > [hidden email]] On Behalf Of Kurt Seifried
>
> > Sent: Sunday, November 5, 2017 11:17 AM
>
> > To: Wheeler, David A <[hidden email]>
>
> > Cc: [hidden email]; Barry, Jim <[hidden email]>; Christey, Steven
>
> > M. <[hidden email]>; Shawn Hernan <[hidden email]>; Joe
>
> > Jarzombek <[hidden email]>; cwe-research-list CWE
>
> > Research Discussion <[hidden email]>
>
> > Subject: Re: Request for comment - homophone attacks
>
> >
>
> > So it's happened now:
>
> >
>
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__twitter.com_virqdroid_status_926437790140772362&d=DwIGaQ&c=DPL
> 6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJ
> Yz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=dkC8NtFz4
> MZtYhm-PbXuXtLrPT7e07-ki3QmNcQmy4k&e=
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__twitter.com_virqdroid_status_926437790140772362&d=DwIGaQ&c=DPL
> 6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD5bxiMa6Nx1hPouclYdJ
> Yz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJTmHw&s=dkC8NtFz4
> MZtYhm-PbXuXtLrPT7e07-ki3QmNcQmy4k&e=>
>
> >
>
> >
>
> > We really need something to classify this and provide some guidance to
> devs
>
> > (e.g. display a warning that the name isn't just ascii, etc.). Also something
>
> > specific for unicode whitespace probably.
>
> >
>
> >
>
> > On Mon, Jul 17, 2017 at 12:49 PM, Wheeler, David A <[hidden email]
>
> > <mailto:[hidden email]> > wrote:
>
> >
>
> >
>
> >        For completeness, here are some related URLs.
>
> >
>
> >        I don't think it's completely current, but this Wikipedia article *does*
>
> > mention some (attempted) countermeasures for homophone attacks (as
>
> > well as background material):
>
> >
>
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__en.wikipedia.org_wiki_IDN-5Fhomograph-5Fattack-23Defending-
> 5Fagainst-
> 5Ft&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXc
> D5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQa
> kJTmHw&s=GbTj6hflTuiWx4ANo52-4k7o8RIYa4KsU_TzgpU3NPs&e=
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__en.wikipedia.org_wiki_IDN-5Fhomograph-5Fattack-23Defending-
> 5Fagainst-
> 5Ft&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXc
> D5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQa
> kJTmHw&s=GbTj6hflTuiWx4ANo52-4k7o8RIYa4KsU_TzgpU3NPs&e=>
>
> > he_attack
>
> > <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__en.wikipedia.org_wiki_IDN-5Fhomograph-5Fattack-23Defending-
> 5Fagainst&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyea
> kFZXcD5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi
> 2xQakJTmHw&s=F2_HCyCa2WoNE7eMTRM1ApT_j3xxo8GkY9zPPsY5aaw&e
> =
>
> > _the_attack>
>
> >
>
> >        There seems to be widespread agreement that the current
>
> > measures aren't enough, e.g.:
>
> >          https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__thehackernews.com_2017_04_unicode-2DPunycode-2Dphishing-
> 2D&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD
> 5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJ
> TmHw&s=Hb6W-muTNNa19o6E3J7HmuOA7ezJplkxYKsGM9VLu1Y&e=
> <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__thehackernews.com_2017_04_unicode-2DPunycode-2Dphishing-
> 2D&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD
> 5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJ
> TmHw&s=Hb6W-muTNNa19o6E3J7HmuOA7ezJplkxYKsGM9VLu1Y&e=>
>
> > attack.html <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__thehackernews.com_2017_04_unicode-2DPunycode-
> 2D&d=DwIGaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=uxVVCWR8UcUyeakFZXcD
> 5bxiMa6Nx1hPouclYdJYz00&m=InYpcuaiqIv0xO3ORazcSkE1dvdkappGi2xQakJ
> TmHw&s=673Bqa3WjaORA79sbiDdbhKiBJoaieyGIJo6cmSvxTk&e=
>
> > phishing-attack.html>
>
> >
>
> >        This is an old well-known attack, and it definitely needs one or more
>
> > CWE entries.  I don't think you need to wait for a solution to create a CWE
>
> > entry; it's a common type of vulnerability, so add it, and then start
> recording
>
> > solutions.
>
> >
>
> >        You might argue that homograph attacks on domain names, or
>
> > internationalized domain names (IDNs), are an important special cause &
>
> > thus should be a child of the more general homophone problem.  Domain
>
> > names are arguably special because they're used by users to determine
>
> > "what part of the Internet I'm interacting with".  Also, some of the
>
> > countermeasures might be more unique to IDNs, e.g., showing punycode
>
> > instead of just the IDN.
>
> >
>
> >        --- David A .Wheeler
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Kurt Seifried
>
> > [hidden email] <mailto:[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 CWE-
> RESEARCH-
>
> > [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
|

Re: Request for comment - homophone attacks

asummers
Administrator
In reply to this post by Andrew Buttner
Just a correction, the CAPEC number at the bottom of Drew’s message should read CAPEC-632, not 63.

Cheers,
Alec

 
------------------------------------------------
Alec Summers
Trust & Assurance Cyber Tech
W: 781-271-6970 | M: 412-818-3792
 

 

On 11/6/17, 6:36 AM, "[hidden email] on behalf of Buttner, Drew" <[hidden email] on behalf of [hidden email]> wrote:

    All,
   
    There is a new CWE in the upcoming release specifically for this type of issue. This new weakness was created based on the conversation we have had over this list.
   
    CWE-1007 : Insufficient Visual Distinction of Homoglyphs Presented to User
   
    The release is scheduled for this week. It a major release (the first major CWE release in many years) and includes an improved schema, a new architecture view, a few new individual weaknesses, continued improvement to the developer view, as well as countless content fixes. Unfortunately it has taken us longer than expected to get things staged correctly with the new schema and post everything to the website.  These issues have been resolved and we are going through out final testing.
   
    In addition to the new weakness, there already exists an attack pattern for these types of issues.
   
    CAPEC-63 : Homograph Attack via Homoglyphs
   
    Thanks
    Drew
   
   
   
    cwe-research-list CWE Research Discussion <[hidden email]>
   
   
   
    > -----Original Message-----
    > From: [hidden email] [mailto:owner-cwe-research-
    > [hidden email]] On Behalf Of Kurt Seifried
    > Sent: Sunday, November 5, 2017 11:17 AM
    > To: Wheeler, David A <[hidden email]>
    > Cc: [hidden email]; Barry, Jim <[hidden email]>; Christey, Steven
    > M. <[hidden email]>; Shawn Hernan <[hidden email]>; Joe
    > Jarzombek <[hidden email]>; cwe-research-list CWE
    > Research Discussion <[hidden email]>
    > Subject: Re: Request for comment - homophone attacks
    >
    > So it's happened now:
    >
    > https://twitter.com/virqdroid/status/926437790140772362
    >
    >
    > We really need something to classify this and provide some guidance to devs
    > (e.g. display a warning that the name isn't just ascii, etc.). Also something
    > specific for unicode whitespace probably.
    >
    >
    > On Mon, Jul 17, 2017 at 12:49 PM, Wheeler, David A <[hidden email]
    > <mailto:[hidden email]> > wrote:
    >
    >
    > For completeness, here are some related URLs.
    >
    > I don't think it's completely current, but this Wikipedia article *does*
    > mention some (attempted) countermeasures for homophone attacks (as
    > well as background material):
    >
    > https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against_t
    > he_attack
    > <https://en.wikipedia.org/wiki/IDN_homograph_attack#Defending_against
    > _the_attack>
    >
    > There seems to be widespread agreement that the current
    > measures aren’t enough, e.g.:
    >  http://thehackernews.com/2017/04/unicode-Punycode-phishing-
    > attack.html <http://thehackernews.com/2017/04/unicode-Punycode-
    > phishing-attack.html>
    >
    > This is an old well-known attack, and it definitely needs one or more
    > CWE entries.  I don't think you need to wait for a solution to create a CWE
    > entry; it's a common type of vulnerability, so add it, and then start recording
    > solutions.
    >
    > You might argue that homograph attacks on domain names, or
    > internationalized domain names (IDNs), are an important special cause &
    > thus should be a child of the more general homophone problem.  Domain
    > names are arguably special because they're used by users to determine
    > "what part of the Internet I'm interacting with".  Also, some of the
    > countermeasures might be more unique to IDNs, e.g., showing punycode
    > instead of just the IDN.
    >
    > --- David A .Wheeler
    >
    >
    >
    >
    >
    >
    > --
    >
    > Kurt Seifried
    > [hidden email] <mailto:[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 CWE-RESEARCH-
    > [hidden email].
   

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Wheeler, David A
In reply to this post by Kurt Seifried
From: Kurt Seifried [mailto:[hidden email]]
> So it's happened now:
> https://twitter.com/virqdroid/status/926437790140772362
> We really need something to classify this and provide some guidance to devs (e.g. display a warning that the name isn't just ascii, etc.). Also something specific for unicode whitespace probably.

It's not the *first* time malicious names have been used, but the scale is (unfortunately) larger.  Please note that this particular attack has *nothing* to do with DNS and Punycode.  Application names and DNS/punycode are just two of the MANY vectors for the general attack.  It's probably more accurately described as a homograph, not a homophone, but whatever :-).

The key: It's going to get worse.

--- David A. Wheeler

Reply | Threaded
Open this post in threaded view
|

Re: Request for comment - homophone attacks

Jeffrey Walton
On Wed, Nov 8, 2017 at 12:00 PM, Wheeler, David A <[hidden email]> wrote:
> From: Kurt Seifried [mailto:[hidden email]]
>> So it's happened now:
>> https://twitter.com/virqdroid/status/926437790140772362
>> We really need something to classify this and provide some guidance to devs (e.g. display a warning that the name isn't just ascii, etc.). Also something specific for unicode whitespace probably.
>
> It's not the *first* time malicious names have been used, but the scale is (unfortunately) larger.  Please note that this particular attack has *nothing* to do with DNS and Punycode.  Application names and DNS/punycode are just two of the MANY vectors for the general attack.  It's probably more accurately described as a homograph, not a homophone, but whatever :-).
>
> The key: It's going to get worse.

+1.

The homograph attacks are targeted directly at users, and many users
use browsers as their primary user agent. The problem is, the browsers
omit users from their threat models. There's a lot more to overcome
than just developer awareness and training. The users must somehow be
trained too since the browsers mostly wash their hands of it.

Consider, this stupid attack still works in 2017:

<a href="http://www.evil.com" target="_blank" title="http://good.com"
style="color: rgb(0, 102, 204);">Login <strong>HERE</strong></a>

The tooltip happily shows its a link to good.com. The browser vendors
I talked to stated users should not be making security decisions based
on tooltips. Derp...

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].
12