HTTP Plugin Path Normalization

[riramar]

Hi @evilsocket

First, thanks for the amazing tool! :)
I'm trying to use http.enum with a payload that contains "foo/bar/../" and playing against my own server, I noticed the path was normalized to "foo/". This is unintended if a user wants to check against some path traversal.
I tried to apply a patch right here: https://github.com/evilsocket/legba/blob/main/src/plugins/http/mod.rs#L118, but it didn't work. Sorry, I'm totally a noob in Rust.
It seems the Crate url (https://docs.rs/url/latest/url/) does not completely disable path normalization with unwrap(), as you can see here: https://stackoverflow.com/questions/62335488/how-to-obtain-raw-url-path-in-rust. If that's true, a refactor would be required to implement a flag to totally disable path normalization.
Not sure if you have any intention to add such a flag to legba.

Thanks!
Ricardo Iramar

[evilsocket]

good catch! will fix asap

[riramar]

Thank you for replying quickly. :)

[evilsocket]

Hi @riramar, I just verified this behaviour and it seems like the path is only normalized if provided in the -T/--target, and in your case it shouldn't.

For instance, I've tried with a small dictionary like so:

?q=foo/bar/../
foo/bar/../too

And added a log of url here. If the relative path component comes from the payload/wordlist (as it should), it doesn't go trough the Url crate normalization:

So, instead of providing -T www.something.com/foo/../bar, just pass it via the wordlist and it'll work. You can check the dictionary of the LFI recipe for more payload examples.

[riramar]

Thanks for the clarification!

[riramar]

Hey @evilsocket

Sorry to bore you again, but I think the problem is that I'm using a list of targets.
Let me give more details. I'm trying to check a list of targets against CVE-2023-46805.
I'm using the request described here https://twitter.com/assetnote/status/1747421199469351181 which I'm sure it works.

So I created two files (payloads.txt and test.txt).

ricardo@zion:~/Temp/Test$ cat payloads.txt 
api/v1/totp/user-backup-code/../../system/platform?operation=testConnectivity
ricardo@zion:~/Temp/Test$ cat test.txt 
https://{burpcallaboratorid}.oastify.com
https://example.com
ricardo@zion:~/Temp/Test$

I tried the legba command below.

ricardo@zion:~/Temp/Test$ legba http.enum --quiet --http-random-ua --timeout 5000 --retries 2 --concurrency 30 --payloads payloads.txt --target @test.txt --http-success-string "Destination host" --http-method POST --http-payload "" -O legba.txt
legba v0.7.1

[INFO ] targets (2): @test.txt
[INFO ] using -> wordlist payloads.txt
    
[ERROR] [https://{burpcallaboratorid}.oastify.com] attempt 2/2: error sending request for url (https://{burpcallaboratorid}.oastify.com/api/v1/system/platform?operation=testConnectivity): operation timed out
[INFO ] runtime 11.081634407s
ricardo@zion:~/Temp/Test$

Not sure why I'm getting timed out, but when checking the request on my Burp Collaborator instance I see "/api/v1/system/platform?operation=testConnectivity" instead of "/api/v1/totp/user-backup-code/../../system/platform?operation=testConnectivity".

I hope this can help you to reproduce from your side.

Thanks!
Ricardo Iramar

[evilsocket]

thanks for more details, I'll check it

[evilsocket]

This one is very tricky ... as you said, it depends on the url crate path normalization. It happens here when the string is parsed into an Url object by the reqwest crate. And, despite my attempts, I could not avoid this behaviour in any way, even trying to trick the parser.

I've opened an issue on the crate repo, let's see if they can change it.

[riramar]

Thanks! Let's see if they implement the flag.

[evilsocket]

@riramar i've managed to override the Url dependency with one I've customized with our required option. This works as a temporary solution until those folks will close the issue on their side.

It seems like it's working correctly now :D

[riramar]

Thank you! I appreciate your assistance. :)