Exploiting URL Parser in Programming Languages (2017) [pdf]

https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf

by tosh • 8 years ago

125 30 8 years ago

blackhat.com

treve2• 8 years ago

Am I correct to understand that the main exploit here is:

A) A server that makes HTTP requests. B) It does so based on a white or blacklist C) These white or blacklists are circumvented due to bad parsing D) This can be used to call unintended services (and sometimes protocols).

I had an idea to build a generic Webhook service. My thought was that the actual machine that does the requests should be 100% isolated from our VPS and only have public network access. Would that largely stop this attack? Perhaps it should also have a rate limiter to prevent DDOS attacks.

Waiting for every url parser to be fixed seems impracticable. This to me is a great example of why the WHATWG url specification is so terrible. It's so much harder to implement than RFC 3986.

Things that aren't browsers should just implement RFC3986 and reject anything invalid.

simcop2387• 8 years ago

I had an idea to build a generic Webhook service. My thought was that the actual machine that does the requests should be 100% isolated from our VPS and only have public network access. Would that largely stop this attack? Perhaps it should also have a rate limiter to prevent DDOS attacks.

This would at least prevent it from attacking your own internal services but wouldn't prevent it from being made to make requests to other outside services. Effectively leaving you up as a potential proxy for other attacks. I.e. the SMTP TLS stuff, making you able to send spam on someone else's behalf. A bit nuts.

jsjohnst3• 8 years ago

but wouldn't prevent it from being made to make requests to other outside services.

But could be done via host firewall rules to some extent.

gohbgl• 8 years ago

C) These white or blacklists are circumvented due to bad parsing

The main problem is that the parsing is inconsistent between different subsystems, i.e. the parse function interprets the URL one way and the fetch function interprets the URL in another way. This is why I think the most practical solution is to add another layer of validation that checks that a given URL belongs to a very small subset of all valid URLs that is interpreted consistently across all your functions.

jkarneges2• 8 years ago

Some discussion about handling webhooks with evil URLs: http://blog.fanout.io/2014/01/27/how-to-safely-invoke-webhoo...

nicolaslem• 8 years ago

The IP blacklisting section seems fragile to me. What about IPv6 or multiple A records?

I would rather let the OS connect the way it prefers and once it is connected, check that the remote is a legit IP address before sending anything.

nothrabannosir• 8 years ago

Check out the TLS SNI exploit. The attack allows embedding CRLF in a TLS payload. The entire handshake leading up to it is ignored by an SMTP server, and the next command is valid SMTP. Meaning that if you ask something to e.g. load an image from, or send a callback to "https://smtp.targetcorp.com<space><CR><LF>...smtp instructions to send mail here...:25/" it'll actually work. As far as I understand this is the TLS handshake so even before any HTTP is done; post, get, whatever. All works.

Good moment to lock down outgoing requests, I guess. At least to port 25 :)

jrochkind1• 8 years ago

Wait, how does "targetcorp.com<space>etc" even DNS resolve? Trying to wrap my head around this one.

userbinator2• 8 years ago

I've not communicated with SMTP servers manually all that much, but I remember my ISP's SMTP server would just close the connection if you sent it something it didn't understand.

treve2• 8 years ago

That sounds like a good second mitigation then. Only allow known HTTP ports.

userbinator2• 8 years ago

This to me is a great example of why the WHATWG url specification is so terrible. It's so much harder to implement than RFC 3986.

You're not the only one who thinks that:

https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/

(Be sure to read the link to the WHATWG's GitHub issue.)

bzbarsky• 8 years ago

The problem is that in practice things that implement RFC3986 do random things with stuff that is invalid instead of rejecting it, in an attempt to comply with Postel's law.

So, again in practice, the security consequence of implementing RFC3986 is typically much worse than that of implementing the WHATWG URL spec. At least the latter actually defines handling for all inputs, instead of leaving implementations to make things up as they go.

enedil• 8 years ago

It was posted before [1] and thus I know the paper isn't from 2018. Should it be added to title?

[1] https://news.ycombinator.com/item?id=14879488

dang2• 8 years ago

Added now. Thanks!

billpg• 8 years ago

It was only a year ago. Would it be substantially different if written today?

nebulous1• 8 years ago

This doesn't seem designed to be read without the accompanying speech

subcosmos• 8 years ago

Saw this talk at Defcon last year. Left the room .... pretty nervous ....

This isn't it, but same title and content https://www.youtube.com/watch?v=D1S-G8rJrEk

charlysl• 8 years ago

Yet another one:

https://www.youtube.com/watch?v=2MslLrPinm0

LolNoGenerics• 8 years ago

Wow this is brutal! I wonder how safe apache and nginx are?

Go0the0gophers2• 8 years ago

Just fuzz every parser you write. And the problem is solved.

whyever• 8 years ago

I agree with the idea, but I don't think it is enough: A fuzzer does not necessarily find all problems.

Go0the0gophers2• 8 years ago

I wrote several parsers that I fuzzed with tools like AFL or gofuzz. And I promise you that fix lot ugly corner cases.

gsnedders• 8 years ago

The problem fundamentally is different parsers parsing the same string into different component values. Fuzzing won't solve that.

Exploiting URL Parser in Programming Languages (2017) [pdf]

Related Stories