Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

eng.getwisdom.io

Post reply on HN
Print view View original

11–20 of 231 posts

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#11

Post by microcolonel »

ljm wrote: post #2

So if I understand this right, what GitHub did was something like: user = get_user_from_valid_email(params[:email]) send_reset_email(params[:email]) # instead of # send_reset_email(user.email) ? I've seen this pattern before and the reason is usually something about using the variable in memory as opposed to the function call. Total non-optimisation.

We use three versions of the email address internally: the exact verified address used at signup or the last valid email change, a normalized version of that (for identity) without + mailboxes, lowercased, de-accented, stripped of dots and other inert punctuation, and normalized in a number of other ways... and then of course the email parameter (only used during registration).

We accomplish this with a slightly more restrictive version of the standard ABNF provided in the RFC.

I guess I should probably document why we go to this trouble, in case somebody gets the brilliant idea to "simplify" it.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#12

Post by anderskaseorg »

notlukesky wrote: post #10
_jg wrote: post #8

Earlier quoted context omitted.

This was a very real and demonstrated vulnerability. Perhaps I've misunderstood your comment.

There are no emails with Turkish characters. The whole attack vector hinges on emails that exist with Turkish characters in the first place.

That’s incorrect. The attack vector hinges on the ability to create email addresses with Turkish characters. There is nothing stopping an attacker from creating addresses with Turkish characters to attack existing addresses without Turkish characters.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#13

Post by glass_of_water »

deathanatos wrote: post #3

This blog sets opacity: 0 (fully invisible) on the entire content, then fails to unset that CSS with JS, b/c the JS crashes if you block cookies. > because the system lowercased the provided email address and compared it to the email address stored in the user database. While sending the email to the attack-provided email, instead of the one in the database, is bad… lowercasing emails is also not valid. The lookup sh…

Nit: did you mean opacity: 0?

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#14

Post by _jg »

microcolonel wrote: post #11
ljm wrote: post #2

So if I understand this right, what GitHub did was something like: user = get_user_from_valid_email(params[:email]) send_reset_email(params[:email]) # instead of # send_reset_email(user.email) ? I've seen this pattern before and the reason is usually something about using the variable in memory as opposed to the function call. Total non-optimisation.

We use three versions of the email address internally: the exact verified address used at signup or the last valid email change, a normalized version of that (for identity) without + mailboxes, lowercased, de-accented, stripped of dots and other inert punctuation, and normalized in a number of other ways... and then of course the email parameter (only used during registration). We accomplish this with a slightly more…

Our team at Wisdom has done the exact same. It's been confusing at times, but much better once we got going.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#15

Post by fartcannon »

This is an organization that not only hosts a great deal of the worlds public/secret code, but is run by one of the largest data-gathering organizations on earth.

I don't believe Microsoft can permit things like this under it's umbrella if it wants to continue to pretend that it's data-collection is benign.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#16

Post by notlukesky »

anderskaseorg wrote: post #12
notlukesky wrote: post #10

Earlier quoted context omitted.

There are no emails with Turkish characters. The whole attack vector hinges on emails that exist with Turkish characters in the first place.

That’s incorrect. The attack vector hinges on the ability to create email addresses with Turkish characters. There is nothing stopping an attacker from creating addresses with Turkish characters to attack existing addresses without Turkish characters.

https://en.wikipedia.org/wiki/Email_address#Internationaliza...

Turkish emails are not supported in the first place.

Internationalization examples[edit] The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these:

Latin alphabet with diacritics: Pelé@example.com

Greek alphabet: δοκιμή@παράδειγμα.δοκιμή

Traditional Chinese characters: 我買@屋企.香港

Japanese characters: 二ノ宮@黒川.日本

Cyrillic characters: медведь@с-балалайкой.рф

Devanagari characters: संपर्क@डाटामेल.भारत

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#17

Post by jcranmer »

deathanatos wrote: post #3

This blog sets opacity: 0 (fully invisible) on the entire content, then fails to unset that CSS with JS, b/c the JS crashes if you block cookies. > because the system lowercased the provided email address and compared it to the email address stored in the user database. While sending the email to the attack-provided email, instead of the one in the database, is bad… lowercasing emails is also not valid. The lookup sh…

Practically speaking, you have to treat email addresses as case-preserving: you match case-insensitive, but you always store the case the user entered in directly.

I usually give my email address as starting with a capital letter for historical reasons, and I once had an issue that wouldn't let me log on with any case whatsoever, probably because it lowercased the email address and tried to match it against the uppercase in the database.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#19

Post by _jal »

microcolonel wrote: post #11
ljm wrote: post #2

So if I understand this right, what GitHub did was something like: user = get_user_from_valid_email(params[:email]) send_reset_email(params[:email]) # instead of # send_reset_email(user.email) ? I've seen this pattern before and the reason is usually something about using the variable in memory as opposed to the function call. Total non-optimisation.

We use three versions of the email address internally: the exact verified address used at signup or the last valid email change, a normalized version of that (for identity) without + mailboxes, lowercased, de-accented, stripped of dots and other inert punctuation, and normalized in a number of other ways... and then of course the email parameter (only used during registration). We accomplish this with a slightly more…

> stripped of dots and other inert punctuation

The period thing is a Gmail feature, not a standard. some.email@mydomain and someemail@mydomain most certainly do not deliver to the same mailbox.

Re: Hacking GitHub's Auth with Unicode's Turkish Dotless 'I'

#20

Post by jcranmer »

notlukesky wrote: post #16
anderskaseorg wrote: post #12

Earlier quoted context omitted.

That’s incorrect. The attack vector hinges on the ability to create email addresses with Turkish characters. There is nothing stopping an attacker from creating addresses with Turkish characters to attack existing addresses without Turkish characters.

https://en.wikipedia.org/wiki/Email_address#Internationaliza... Turkish emails are not supported in the first place. Internationalization examples[edit] The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these: Latin alphabet with diacritics: Pelé@example.com Greek alphabet: δοκιμή@παράδειγμα.δοκιμή Traditional…

EAI email addresses are legal email addresses, even if it's not guaranteed that all servers are capable of delivering to them.
Post reply on HN