HOW FRCKN' HARD IS IT TO UNDERSTAND A URL?! - uXSS CVE-2018-6128

URLs are surprisingly hard to read.
Chrome Bug: bugs.chromium.org/p/chromium/...
Orange Tsai: / orange_8361
A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages! - CODE BLUE: • [CB17] A New Era of SS...
Slides: www.blackhat.com/docs/us-17/t...
=[ 🔴 Stuff I use ]=
→ Microphone:* geni.us/ntg3b
→ Graphics tablet:* geni.us/wacom-intuos
→ Camera#1 for streaming:* geni.us/sony-camera
→ Lens for streaming:* geni.us/sony-lense
→ Connect Camera#1 to PC:* geni.us/cam-link
→ Keyboard:* geni.us/mech-keyboard
→ Old Microphone:* geni.us/mic-at2020usb
US Store Front:* www.amazon.com/shop/liveoverflow
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.
#CVE #SecurityResearch

[@daab889]

"You are not browsing it right" - Apple, 2018

[@jonny6702]

daab889 such an underrated comment lol

[@kratosgodofwar777]

#BrowseDifferent

[@HorochovPL]

>discover exploit >suggest fixing it with crash >get money!

[@thechargeblade]

profit ? lol

[@Skyler827]

I mean, it was the best that they could do, especially since the condition would pretty much never occur on regular websites.

[@alimmi9]

@@Skyler827 Well it seems it did, because they deactivated this workaround because of too many false positive crashes.

[@JeppeBeier]

As far as I know many people make their living from discovering and reporting exploits, and possible fixes

[@undead2146]

Weird flex but ok

[@OrangeC7]

9:08 I love this, "QUICK CRASH CHROME THERE'S AN ATTACK"

[@PainSled]

There is only one correct answer to this. (Though, please correct me if I'm wrong) According to section 3.2.2, "In order to disambiguate the syntax, we apply the "first-match-wins" algorithm: If host matches the rule for IPv4address, then it should be considered an IPv4 address literal and not a reg-name." Ignoring "scheme", the logic goes as follows: - "Hier-part" is prefixed with "//", so is defined as "authority path-abempty". - "Userinfo" matches only "1.1.1.1&", as it must come first, cannot contain an "@", and should therefore ignore the second one. - "Host" matches "2.2.2.2" as an IPv4address, and should stop there. - "Host" is not followed by ":", meaning port-number is absent, and the "authority" part has ended. - "Authority" is not directly followed by "/", therefore "path-abempty" is empty, and the "hier-part" has ended. - "Hier-part" is not directly followed by "?", resulting in no hit on the optional "query". But the "#" makes a hit on "fragment". - The entire URI is valid, as it is split up in correctly defined and ordered parts, and all are valid in both syntax and semantics. The only correct interpretation should therefore be as follows: Userinfo: 1.1.1.1& Host: 2.2.2.2 Fragment: @3.3.3.3/ We can follow these relevant ABNF syntax rules by the first-match-wins algorithm, in order to recognize these consequences: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / - / - / - authority = [ userinfo "@" ] host [ ":" port ] userinfo = *( unreserved / pct-encoded / sub-delims / ":" ) host = - / IPv4address / reg-name port = *DIGIT IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet = DIGIT / %x31-39 DIGIT / "1" 2DIGIT / "2" %x30-34 DIGIT / "25" %x30-35 ; 0-255 reg-name = *( unreserved / pct-encoded / sub-delims ) pchar = unreserved / pct-encoded / sub-delims / ":" / "@" fragment = *( pchar / "/" / "?" ) pct-encoded = "%" HEXDIG HEXDIG unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" Parts of rules not relevant to the case has been changed to a single dash(-) to lessen the info-dump. Appendix A of the standard contains the complete list. Note that any scheme may contain additional restrictions, further reducing the amount of valid URI's for that scheme. And according to section 3.1: "When presented with a URI that violates one or more scheme-specific restrictions, the scheme-specific resolution process should flag the reference as an error rather than ignore the unused parts".

[@sajayrrr]

Mate, damn, you are a genius, but I don't feel like you are gonna be appreciated much in this comment section :)

[@allenkay2419]

Let me appreciate him though....just made my work easier

[@brandonstevens6886]

wow this is underrated

[@PainSled]

​@@brandonstevens6886 I have to admit: Coming back and reading through the comments a couple of years later, makes me suspect that it might be rather uncommon to be able to read and properly understand the logical implications of ABNF specifications. *Hey, Google! PM me with a job offer, would'ya?*

[@brandonstevens6886]

@@PainSled Its more that you actually put the effort into a comment on youtube like this.

[@rkan2]

“Award is so high”… 7500$ is not that high for such a critical bug, though it is a lot for a bug found in open source software..

[@simplylinn]

It's pretty high for a bug not even caused by the ones who paid up...

[@Klblaz]

It would be higher if Apple would pay for it, but they wont.

[@GreenyDe]

Well deserved for sure!

[@gavinkemp7920]

my understanding is major vulnerabilities would pay for atleast an other 0. as some have said they paid for something which wasn't their fault and to be fair the number of cases which could exploite this would be fairly rare.

[@rkan2]

Webkit is still probably as much Google's thing nowadays too..

[@matrix8934]

I expected this url to be rick roll

[@LiveOverflow]

Only quality content on this channel!!!1!!1!1!

[@OopsieGoopsie]

exCUSE ME are you saying that rick astley isn't quality content

[@ducpham1478]

ExCUsE mE :D

[@Joevim]

kzbin.info/www/bejne/hnzFqX5of61labs

[@tsuki4737]

@@LiveOverflow how dare u unsubbed even tom scott did it /j

[@MrNateSPF]

Ah, the good old days where the password was right in the url ;-)

[@ShadowriverUB]

its still a thing in some protocols

[@NicolaiSyvertsen]

@@ShadowriverUB Because assuming an encrypted transport protocol (hello TLS!) that isn't really an issue. Which is why "everyone" switched back to basic authentication instead of digest authentication when switching to HTTPS for login pages.

[@chazy123]

​@@NicolaiSyvertsen Still, I think secrets should be hashed in the client, but I gave up a long time ago, can't do shit about it.

[@user-iq7xy8is3f]

@@ShadowriverUB yea but its Not Safe

[@antonidas159]

@@chazy123 By hashing secrets in client, password hash would work just act like real password, Since server does't know its hashed or copyed, its not really any safer for it

[@fuzzydark1395]

You just overcomplicated my life for no reason at all

[@rGunti]

"What is the correct interpretation of this URL?" My answer: *CRASH* :P

[@CalvinBonner]

As a front-end developer, I must admit that a good amount of this was not something that I am super familiar with. All the same, I feel like I really learned something here and I really appreciate you taking the time to explain things so clearly. In short, great video!

[@retepaskab]

Heh, it must've been fun to write code that _has to crash instead of _mustn't.

[@kmcat]

The only time, when testing it didn't crash.

[@Captain.Mystic]

the art is in making it crash when you want it to.

[@JeppeBeier]

It can be hard to make stuff crash on purpose sometimes.

[@Hati_0x]

Just divide by zero, the universal and ultimate computer operation! It's their kryptonite!

[@SylasTheGreat]

@@Hati_0x Not a quantum computer... They've surpassed us!

[@Ben-ds3cm]

I love your channel so much. Please never stop making videos!!

[@DJTimeLock]

I had barely any idea what you were talking about for the most part (regarding the URL parsing) but I loved it regardless. Shows even small mistakes can have big concequences

[@SuperMarkusparkus]

2.2.2.2 is the hostname. Firefox and Chrome loads 2.2.2.2 and it makes sense. The & before the first @ doesn't have significant meaning, however '?' in the same place would since it would then start the query part of the URL. If # comes before @ it starts the fragment part and then the @ can no longer separate the username:password part from the hostname, everything after is the fragment.

[@SuperMarkusparkus]

One should also note that there is something called protocol-relative URLs: When a url starts with //hostname/ it will link to hostname/ if the URL originates from a web page, but otherwise https if the link is on web page. This can sometimes be used in open redirect vulnerabilities (that can be used to steal tokens and stuff) or just generally bypass filters (like in SSRF). If a website thinks it redirects to a relative URL because it starts with /, add an extra slash so it becomes double slash //hostname so it will take the user to http(s)://evil.com. The naive filter would then check for two slashes in the beginning of the URL to determine that it's a protocol relative / "absolute" URL that should be blocked. Too bad that many browsers will treat or \/hostname.com or /\hostname.com in the same way as //hostname.com or http(s)://hostname.com

[@oisins.6066]

Is the space a valid character?

[@TrancorWD]

I'd figure, while ' ' should become %20, with how cloodgy the network layer seems, it might become %20; in some cases? (I haven't tested anything) The host should be 2.2.2.2, but 3.3.3.3 seems half way logical to me.... I hate to say.

[@ckennedy0323]

@@TrancorWD According to RFC 3986: "In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted....For robustness, software that accepts user-typed URI should attempt to recognize and strip both delimiters and embedded whitespace." As for the symbolism portion, + is a sub-delim while space can be formally inferred as %20. So I'm not sure. Maybe Python knows something I didn't find with my surface level research.

[@TrancorWD]

@@ckennedy0323 I'm glad there is formality there. %20 being the rule for interpretation. Thanks for the info! I guess I was figuring along the lines of html interpretation,   > < sort of thing

[@Sky_Shaymin]

"I don't understand Python"

[@BoB-Dobbs_leaning-left]

Yeah, that parrot sketch was "Out There".

[@0x19]

OMG AFTER 4y OF BROWSING YT I FOUND YOU, SKY SHAYMIN :D

[@Vogul]

Thank you for making those awesome explanatory videos! Keep it up!

[@astrix8812]

Wow! I have just started to scratch the surface of computer security and this video just blew my mind! Thank you very much for sharing

[@TheSpacecraftX]

Thank you for providing the text subtitle for that guy at the end. I really could not understand him.

[@DrakiniteOfficial]

I appreciate this ranty subject line and introduction, because it got me to watch this video and it was quite interesting.

[@hoola_amigos]

This is some quality quality content.. keep it up @LiveOverflow!

[@Gastell0]

12:53 - He did it all correctly, Google cares about security of Google Chrome browser as it's brand is on it even if the issues is with non-google owned component, they have implemented a quick fix from their side to get this issue mitigated (alas not perfectly), while Apple will be fixing it from their side.

[@Myx0]

I'm credited for CVE-2016-5191, a bug that shares many similar characteristics. I only got $500 for it though. 😪

[@nyaa]

Poor you, complaining about getting money.

[@mamupelu565]

dont even tell them next time

[@RAGHAVENDRASINGH17]

Can you teach me SSRF?

[@billigerfusel]

Report it to the NSA and get more.

[@tmpEngine]

exploit it and earn even more

[@Serverfrog]

Many Things are are defined way back, like URI/URL, XML and so on. Have many "Features" that are defined to be a security issue in some future. Like XXE, which is a XML Parser just working on Spec. I found so many things where an old RFC definition just design a "feature" which is itself a security issue

[@MasterTop100]

This was soooo far above my head, but I enjoyed it, and it was very informative. Thank you.

[@eyokfla]

VERY INFORMATIVE. I was looking for that one for too long! Thanks a lot

[@alexnezhynsky9707]

You totally rock man, keep them security videos coming! Very good job and interesting content 👍

[@kesuskim6072]

How the heck this things can be such analyzed... I admire you :S

[@SayanGHD]

You are an inspiration to watch!

[@Microscraft]

Thanks for this great video !

[@gillesottervanger9106]

Great video, still relevant today!

[@jmalvares88]

This is my new favorite video

[@indiansoftwareengineer4899]

loved your channel, Please upload more&more content.

[@MAHDEO]

THANK YOU, SIR, FOR THIS VERY INFORMATIVE VIDEO. APPRECIATE IT !!!!

[@payloadartist]

Mind blowing insights...

[@rysea9855]

I understood like, 20% of the video at most, but it was somehow still interesting

[@Udok1306]

Are you an anime fan?

[@rysea9855]

@@Udok1306 Yeah, what about it?

[@azamrahman9768]

Incredible. Bravo

[@Almostbakerzero]

great video! there recently was an article about a similar topic on heise, where they pointed out that the way our network stack interprets numbers also can be misleading. for example, who do you expect to reply when executing "ping 2130706433"?

[@limblamb6554]

awesome video, very well done

[@iliankarasimirov9685]

Thank you for pointing out this :)

[@NicholasMaietta]

So glad i found your video. I've been in web security since 1999 and this is one that i always wanted to learn more about. I don't mess around with web browser security much but I guess I just might from here on out. Very nice. Thanks and subbed.

[@RAGHAVENDRASINGH17]

1999 are u serious ? Please teach me too

[@evgenyaleksandrov1206]

Well, this vid is fantastic! Thank you for such an amazing story of a really rediculous bug. LOL

[@romeoaleem5763]

I love your videos ❤️

[@GreenyDe]

Very good video, THANKS!

[@doktoracula7017]

Probably someone mentioned it already, but I want you to know that "Tomasz Bojarski" is pronounced like "Toh-mash Boh-yar-ski". But still really good job. And thanks for the vid, it really shows that even if everything is defined one way it can be interpreted in many ways.

[@bluebaby30]

That workaround seems like something I might make with no time lmao

[@sakyb7]

Great explaination.! Learded a lot :-)

[@Time4Technology]

Just a day before I found this video I was trying to get a Regex to understand a super long URL with weird characters.

[@vypxl]

You forgot that rickrole in the beginning ^^

[@meowwei6181]

New RFC is needed to define the unclear case of the URLs I think...

[@dhananjaygarg9868]

Great video thanks

[@De-tp5mq]

After few minutes it all went over my head

[@isaacressler8177]

9:50 “why does Chrome have to crash here instead of WebKit fixing it faster”. Even if Apple/WebKit fixed it the next day that would be a new iOS release, so anyone who didn’t update their phone’s OS would still be vulnerable. By updating Chrome it makes the fix available for everyone who doesn’t (or can’t depending on device).

[@ibrahimabtula3234]

Thanks, that was very interesting video

[@SeanPM]

Great video bro.

[@ArifKamaruzaman]

I feel smart watching this video.

[@ineedtodrive]

i need to learn more of each definition manual!

[@snowpython]

1 should be the request because it carries the https (forgot the proper vernacular) There should be some sanitizer that checks for that prior to any other processing of the request.

[@hazemght4654]

Thanks man ,, keep going ..someone tell me How these people thinking??

[@Acid31337]

They just working with it, and so, they know possible weaknesses.

[@ALurkingGrue]

One theme in security that pops up over and over: PARSING IS HARD!

[@baganatube]

The other day I found Java class java.net.URI from the standard library doesn't meet RFC3986 examples, relative URI resolution to be specific.

[@l-eon]

Great video

[@ShubhamPatil-wk4yv]

Superb!!

[@AzakaSekai]

Orange's network security talks are super interesting. I was at HITCON earlier this summer and his talk also involved URLs parsing inconsistency.

[@Shlonzs]

„I don’t think chrome can do better than crashing“ made my day 🤣🤣😜

[@Webtroter]

I would assume left to right as the correct way to parse. Or we should do a new RFC to specify this.

[@HappyBeezerStudios]

can already see the details: "order of reading depends on the language the url is written in"

[@steve1978ger]

14:13 - My first answer would have been '2.2.2.2', because parsing it top-down, the '#' would delimit a 'fragment', and we get via 'hier-part' into an 'authority' where the '@' delimits a leading 'userinfo'. The spaces throw me off, though. The red rectangles are spaces, right? As far as I can see, these are not legal parts of a URL, so the whole thing should be rejected.

[@DeusGladiorum]

I’m confused as to why this is an XSS attack. XSS requires code injection such that the compromised site will then execute that injected code on behalf of the user, but I see no code injection occurring here. This sounds more like CSRF, where the user can visit a malicious website which will then change the user’s domain to that of the targeted website, thus allowing the malicious site to make valid requests (presumably also sending user cookies) to the targeted site, and now not being blocked by CORS, the request will be processed and authorized by the target server. Can someone explain what I’m missing?

[@rogercruz1547]

The RFC only wants a single @ after user and password, the parsing happens from left to right so I would say the green part. RequestS is right in my eyes.

[@NicolaiSyvertsen]

I can understand a URI fine. I just can't comprehend Backus-Naur Form. Give me a dozen examples over a terse BNF any day.

[@singularity1130]

Only $7500? ON A WORLD WIDE USED BROWSER?! AND APPLE DIDN'T PAY IT?! If that person wasn't a saint they would've gone down in History...

[@vorea]

per the RFC, the green part should be the host since it's immediately followed by a # making the blue part the fragment and the yellow part the username. While the RFC does not specify an error case anywhere, there are considerations for scheme-specific (HTTP in this case) error handling that could return no URI. tools.ietf.org/html/rfc3986#section-3.1 In this case because there is no forward slash between the host and the #, and there's no ? before the & in the first part, the parser should return a malformed http url error. The authority is always the text between the first // and the first @ since it does not specify anything else.

[@misterg3tr3kt11]

The correct action would be throwing an error, since there are two @

[@MagicGonads]

@ is part of the fragment

[@zerobyter]

Hey, looking at the Chrome Rewards page, it says one of the conditions for recognizing the Chrome bug is: "We'd also love to learn about bugs in third-party components that we ship or use (e.g. PDFium, Adobe Flash, Linux kernel). Bugs may be eligible even if they are part of the base operating system and can manifest through Chrome." www.google.com/about/appsecurity/chrome-rewards/ So really there was precedent before this.

[@FennecTECH]

the proper interpitation is ALWAYS the interpitattion that protects the user

[@tekken-pakistan2718]

It seems Thomas used 100% of his brain :D

[@humanbeing2730]

You did Comp Sci at TU Berlin, right? I'm currently doing that too :)

[@sevret313]

The last url is so messy that it should just be regarded as a malformed URL and not lead anywhere.

[@oscarchampion5842]

but it might be valid in some cases, eg ip = 1.1.1.1, user = 2.2.2.2, fragment = 3.3.3.3

[@vypxl]

CHECK(false) lol.. reminds me of my if(true) sometimes

[@JochemKuijpers]

assert(false), or in this case, a similar-looking function, is used in situations of code that *should* be unreachable because certain combinations of values are impossible. It's good practice to have a control flow defined for all possible inputs, even if you cannot continue processing and just terminate or throw an error or whatever. Otherwise you will process data under false assumptions, which cause bugs. (Crashes aren't always caused by bugs)

[@darven]

Or "con\con" from the good old 95/98 times.

[@stewartzayat7526]

But crashing generally isn't a good sign. I believe your program should crash only when there's nothing better it can do, so that would include exceptional situations like your memory being corrupted, running out of memory, ...@@JochemKuijpers

[@Triavanicus]

@@stewartzayat7526 yeah, possibly redirecting to a browser specific page like about:newtab, or maybe a new one called about:hacks

[@LuizDahoraavida]

if (true && !false && true != false && false == false && true == !false) { //do stuff }

[@Rowrin]

OMFG IT'S LITTLE BOBBY TABLES!

[@arthusu]

in which software do you edit the brother videos? by the way excellent video

[@jamesflames6987]

I used to exploit these types of url parsing bugs at school to bypass the internet content filter.

[@ygx6]

I understand the basics of URLs, this video taught me more and helped me understand it better! You're a great teacher. (Make a video in German)

[@fuuryuuSKK]

"Tomasz", assuming it's hungarian, is just pronounced like the german equivalent "Thomas", the corresponding graphemes in german and hunggarian are sch - s and s - sz

[@Inseut]

Nah mate. His surname is Polish. "Tomash" is the correct pronunciation in Polish.

[@Inseut]

But yes, if he were Hungarian it would be just like Tomas. :P

[@RAGHAVENDRASINGH17]

Nice explanation 👍

[@David-mf5ef]

sehr gutes Video ;)

[@mskiptr]

Wow, quite decent pronunciation of Polish names : D Most people seeing things like 'Tomasz' get really confused - what the heck is 'sz'? (in fact it's /ʂ/, slightly different, but kinda similar to English /ʃ/) And about 'Bojarski', the only thing you got wrong is 'j'. It's not read as /dʒ/, but rather as /j/ (like in English /jɛs/ - 'yes', not /dʒɛs/ - 'Jess').

[@AliceinEntropy]

Does this kind of attack have anything to do with some attack that happened to some online store? I think it was newegg? Did you ever talk about that or could you? It was a few years back now I think.

[@JayVal90]

This is why you formally verify your semantics.

[@aurelienperrot2323]

Good video, thanks ;)

[@mismis3153]

15:08 Bless you!

[@damascenoalisson]

07:21 Nice drawing bro :)

[@TheFrenchMansControl]

I think the correct response to the URL at the end is to crash the browser :D

[@moth.monster]

Obviously, when the parsers dissagree, access both and hope one is right

[@ZipplyZane]

It sounds like a huge thing with this is not using the same URL parsing code within the same project. Even if they want to spool out the function for efficiency's sake, surely the same code should parse the same input.

[@TheMan83554]

It seems to me that the issue at hand is ordering. The hierarchy part of the specification says "host name, @ symbol, username or password" but different parsers are misplacing where the username/password is and where the host is. Specifying host then username then password (and fixing libraries to match) would solve that part, right?

[@kalleguld]

username is 1.1.1.1& hostname is 2.2.2.2 fragment is @3.3.3.3/

[@MaakaSakuranbo]

Yep!

[@TheAkashicTraveller]

Meanwhile firefox just decides nope not a URL and googles it.

[@sznio]

I think the fragment must come past `/`, so it isn't a URL in the first place.

[@kalleguld]

Dawid: I thought so too, but according to the spec at 1:44 the path-abempty isn't needed. There doesn't need to be a slash between the authority and the fragment

[@Dreamagine1]

Interesting. I had always thought that at least one forward slash was required before any queries or fragments

[@anselmschueler]

I parsed it manually using RFC3986, the correct parse is: uri = "1.1.1.1 &@2.2.2.2# @3.3.3.3/" scheme = "http" hier-part = "//1.1.1.1 &@2.2.2.2" fragment = " @3.3.3.3/" userinfo = "1.1.1.1 &" host = "2.2.2.2"

[@ane150893]

Yep. Thats it. Its official now that i dont understand a thing in this video

[@PanadeEdu]

The sad thing is, I am neither surprised nor shocked. If the world would know what code is out there...

[@silaspaixao2734]

Hey, bro! what programm you use to make your animations?