I have been on an insane tear over the last few years deconstructing network infrastructure, switches, routers, and security controls from pretty much every manufacturer out there.
One of the weakest API, web application, and infrastucture families out there is the HPE / Aruba / 3Com family of products.
I have found so many encoding, processing, and integration flaws in them that I have taken to turning most of them into coding challenges, weird machines, and examples of exactly how NOT to handle input sanitization on network infrastructure.
I’m going to show an encoding trick, how HTTP header splitting works, and finally craft a slick little open redirect payload you can practice with. There’s a *nasty* exploit chain and concept you can extend out of it.
(Hint: Try looking real hard at *why* I’m using specific characters, *why* it works that way, and try a few more yourself.)
POC Provided for:
HPE / Aruba Networks Document – HPE FlexFabric 5700 Switch Series – Specification | HPE Support
Firmware:
2432P06-US
HTTP Response Splitting and Encoding – A Brief Introduction
HTTP Response Splitting | OWASP Foundation
If you’re not familiar with the idea, OWASP has a good writeup on it. The essential idea is that I can encode payloads, reflect them off the webserver, and when they process.. the server decodes the response in my desired output type and things happen.
On a webserver, what I want is to totally control the response, insert the response *I* want, and get the browser picking it up to do what I want.. or go where I want to go. (I’ll go deeper on more problems with implementation of this idea on HPE / Aruba Networks switches in another post. Yikes.)
HTML URL Encoding Reference (w3schools.com)
URL Encoding is straightforward and I’ll leave this link here. Essentially, in this attack, I send URL encoded characters (those % characters you see in URLS / links) to the webserver, it decodes them as text, and includes them in the response.
Using the link above, you’ll see URL encoding that is pretty familiar:
%20 = [space]
%23 = #
%30 – %39 = 0 – 9
HTTP Response Splitting – Controlling how the webserver answers from the URL that is sent!
In an HTTP Response Splitting Attack, I can effectively control content processed by the client browser (victim). By all appearances, it “comes from” or is spoofed by the target server because.. it really came from it. It just takes what I send it, decodes it, and sends it right back.
Here is an example payload:
%43%59%42%49%52%20%6c%6f%6f%6f%6f%6f%6f%76%65%73%20%58%53%53%20%70%61%79%6c%6f%61%64%20%66%75%6e%21 = CYBIR looooooves XSS payload fun!
In BURP SUITE, the DECODER tab lets you play with all kinds of encoding & decoding. Here, you can copy / pasta in the text above and see how this works.
So, now that you know how that works.. let’s get a little fancier. Let’s send Carriage Returns and Line Feeds (CR/LF), control characters that don’t typically get sent by a browser like this:
CYBIR
^there’s a break here!
Now, in URL encoding this becomes a straight encoded payload… no line feed:
%43%59%42%49%52%0a%0a%5e%74%68%65%72%65%27%73%20%61%20%62%72%65%61%6b%20%68%65%72%65%21%0a
The LF is encoded as %0a. Take a look in BURP:
The Incredible Stupidity of Unsanitized, Client-controllable Fields – Crafting the Payloads
HPE and Aruba Networks switches are absolutely terrible at input sanitization and API security controls. I have easily turned up two to three dozen unique exploits against them from every input vector they support. I said at RSA 2022 that I “average at least 1 new 0-day every day I am in the saddle.” I could spend years in here. (Wait, I did.)
Let’s look at something older, widely supported, enterprise class, and easily exploitable:
GET /wnm/ssl/web/frame/login.html?ssl=false&host=
This request is part of the LOGIN process and is designed to redirect the user to the correct page via the HOST field.
This is a client controlled parameter. That means, I can send it a link and it will process what I put there. Let’s try some encoding fun:
GET /wnm/ssl/web/frame/login.html?ssl=false&host=cybir.com
I put in the plaintext of our site, CYBIR.COM.
Simply put, this is an open redirection vulnerability. May have been previously discovered, definitely still out in the wild and active. I see it pretty frequently. I can easily put a spoofed / malicious page there… send the link to my victim… and we’re off to the races. Click that link, as you’ll see, and you’ll be directed to our website.
What about getting fancier? Didn’t I say I could control what the browser does?
GET /wnm/ssl/web/frame/login.html?ssl=false&host=cybir.com%0aPWNEDBYCYBIR:%20POC!%0aNOTGOINGHERE:
What happens if I start injecting those special characters? Will the application decode them and reflect them back?
YOU BET!
So now, instead of injecting an arbitrary website and being redirected, I have actually controlled the HTTP response AFTER my string and injected totally valid, spoofed headers:
&host=cybir.com%0aPWNEDBYCYBIR:%20POC!%0aNOTGOINGHERE:
You can do all sorts of fancy stuff with this and it invariably leads to insane client side exploitation, XSS, session riding…. and total control of this vital piece of network infrastructure.
Final POC / Redirection & Header Injection to CYBIR.COM Site
So… send this URL:
http://(targetip)/wnm/ssl/web/frame/login.html?ssl=false&host=cybir.com%0aPWNEDBYCYBIR:%20POC!%0aNOTGOINGHERE:
To a vulnerable HPE switch and not only do you bounce the request off of it and inject headers, you can jump right into browser exploitation with direct code attacks, seamlessly.
