All right. Daniel Jensen is going to be talking to us about some bug hunting in the tropics.
Thank you. Thank you. Okay. This is hunting bugs in the tropics. About me, my name is
Daniel Jensen. I live in Auckland in New Zealand and I work as a pen tester and red teamer
at a company called Cyber CX. This talk is about some bugs I found while I was living
in the tropics. So there's an island called Aruba. It's a country that's a constituent
of the kingdom of the Netherlands. It's just north of Venezuela. There's also an enterprise
networking vendor called Aruba and it was bought by HPE in 2015 and we're going to be
talking about that Aruba. So a bit of background on this talk. These are vulnerabilities I've
submitted to Aruba's bug bounty program. It's a good program. They're good, easy to
work with.
And
, let me talk about these bugs, which is very cool of them. Yep. So I'm going to cover
four products that they make. So there's the AP, which is like a wireless AP. There's
ClearPass, which is a policy manager. There's Airwave, which is like network management
and along those kind of lines. And then there's Glass, which is like a single pane of glass
that agglomerates airwave data.
So this is a kind of a bug bounty program. I'm going to talk a little bit about it.
And then there's the ARUBA, which is kind of a terrible diagram of how they relate to
each other in a network and how you might find them configured just to Aruba stuff.
So first thing is the AP. I put the least amount of time into researching this and mostly
focused on post-auth attack surface. Interestingly, I actually had some bug collisions with other
researchers as well, which they wrote up in that post, the ALIF security. So a bit
of technical details. The AP's run something called a ArubaOS, which is a operating system that they use to run data and user data in an ARUBA network.
ship on it, uses a Linux kernel, and the newer IPs are mostly ARM, and some of the older
ones use the MIPS architecture, that image is signed and it's verified at boot,
so it's actually quite decent compared to some other networking vendors.
In terms of attack surface, they have a Telnet server if you enable it, there's SSH, there's
a web server on the instance, they talk to each other using a protocol PAPI, and also
some of the newer ones talk to Aruba Central, which is like their cloud management-based
thing.
So, if we want to get started on researching this, what do we do?
Well, just get an image and extract files off it, which is easy, thankfully, binwalk
will do it, happily, and it's just two rounds of LZMA and inside of CPIO.
Okay.
Archive.
And you can see there, that's how to do it.
There's also a bit of GPL source code on GitHub, which some enterprising individual has I believe
requested from Aruba and published online, which was nice of them, so you can look at
that as well.
So we also want to get runtime access to the APs, so the way I went about this is first
find an exploit, and then exploit the bug, and then I sort of set up my own research
environment on the AP.
So, pull things across, like I compiled TCP dump, GDB server, and the easiest way to do
that is using something called build root, and build root is an awesome set of scripts
that you can basically cross compile for all sorts of different architectures, and you
can build static libraries, static binaries, so you don't have to worry about libsy compatibility
or anything like that, and it's got a nice little interface, you can just go into it,
tick the boxes for things you want.
And it will build the library.
So you can pull across things like TCP dump, so I can dump, look at what's going on in
the interfaces, and a GDB stub, so you can attach to like running processes on the AP
and see what's going on in them, and that's just stub, so you can connect to the stub
from the comfort of your X64 host using GDB multiarch, and it will actually like pull
the binary across the wire using the GDB protocol and all the libraries it has loaded, so that's
makes it nice and easy.
First bug is the, I found DHCP command injection, so I kind of found this like reading the docs
for the AP, and it said when it sort of boots and it's not configured, it looks for an airwave,
and it does this a few different ways, and one of the ways it does it is by looking for
a, doing a DNS lookup, and that DNS lookup uses the domain name suffix that you provide
it when you hand it a DHCP lease.
So in the DHCP lease.
So in the DHCP lease.
So in the DHCP lease you can set DHCP option 15 and put a command injection in that, and
that ultimately is run and gets you root access to the AP.
So like practically this bug's not that useful, it only really works when it's not otherwise
configured, so it's not something you'd probably use on a job, but it's good for getting research
access.
Second issue I found was a command injection.
So this worked in a.
So this worked in a somewhat convoluted way where you had a file right into that directory,
the EDC, HTTP, custom image directory, and you could create a binary that had things
like back ticks, so meta characters in the file name, and then when you run the show
amp audit command that takes the name of the file you've written into the directory and
inserts it unsafely into a system call, so there's a command injection there, but there's
a few restrictions.
So obviously you can't have a slash because it's a file name, but there's also like some
length restrictions, so it was easy enough to do back tick ID, good enough for a proof
of concept, but, you know, I want to get a shell out of it, so that's what the decompiled
code looks like that's calling system.
So how do you actually get a shell when you have quite a short length restriction?
Well I actually ended up coming up with this monstrosity, which there's a lot going on
in there.
So what's happening here is the back ticks start off the command injection, then you
use the SH, which refers to the shell interpreter, IFS is the field separator, which you can use
as a space, basically.
On Aruba OS, the dollar home environment is slash, so I set the create a new variable
called A, which is slash, which is how I refer to the slash, because dollar home is too long,
and then I kind of just wild card through some various directories.
So that, after resolving that.
Resolving the variables looks like this, and then after you resolve the wild cards,
it looks like the thing at the bottom.
So it's basically referring to itself, and will run itself.
On a Linux host, this is how it looks.
So you can see there's the contents of that file is just the ID command, and then when
you sort of, you know, emulate a command injection, you can see it's actually running itself.
So the trick there is you want to look at even if you have like restrictions
on characters or things when you're trying to exploit a command injection, the environment
is quite a good place to look.
There's often like things like semi-colons on some boxes, depending on how the environment
is configured.
And I also used that in another command injection vulnerability, whereby they didn't let me
do back ticks or anything, and I could do a dollar and a left parenthesis, which is
like a sub shell.
But if it was followed by a right parenthesis, they disallowed it.
So what I did is actually define that right parenthesis as a variable before the dollar
and left parenthesis, and then used afterwards.
So yeah.
Check out the environment variables.
It's a good place to source characters you may need.
I'm just going to grab a drink of water.
Okay.
Target two.
Clear pass policy manager.
So this does like network access control and policy management.
And that sort of thing comes as like a physical hardware or a virtual appliance.
That's what it looks like.
The web interface looks like.
The tech stack looks like this.
So it's running Linux, CentOS 7, and it's got Apache, it's got Tomcat, it's got PHP,
it's got Golang microservices, it's got Python microservices.
There's a lot going on.
And you can also encrypt the disk on it, which is a nice feature when you deploy it.
Okay.
So getting runtime access to this, unfortunately, it restricts us to a sub shell, so we don't
get a proper shell when I SSH to it.
So this is quite common.
And the way I usually deal with this is just boot the appliance with a live CD image.
So I normally use G parted.
And then you can mount the disk and then just add a new user to the files in Linux that
you might need to access like password, shadow, sudo, that sort of thing.
Reboot it and then you can log into it properly.
And that generally works quite well when you're reversing appliances.
ClearPass supports disk encryption.
So this is how you can pull the encryption key for the disk.
Because when you boot it, it doesn't want to be asking you for an encryption password
because people get annoyed by that.
So they have to store the encryption password for the disk.
And the way they do that is they just store it in the RAMFS.
You can pull it out like that.
Here's the demo.
Here's the attack surface.
That little goose there represents the attacker or me.
And there's a few things you can hit directly but most of it is via Apache.
So these are the Apache configs.
There's a lot of them.
There's I think about 20 different config files they use to define all sorts of ways
of routing your HTTP requests to the back end applications.
And on the right there are just some snippets of some of those files.
So.
There's quite a lot of different ways of getting access to the services.
It has two Tomcat instances called back end and front end.
And front end has an application in it called tips.
And that's like the main Java web application.
So I looked at that first.
What I do is look at the web XML file.
And you can see the what the servlet mapping does.
It maps like a U.S. server.
It has a URL pattern to a servlet class.
And so I just go and look at that servlet class.
It also has struts which defines other routes to other areas of the Java code.
It also has something called DWR or direct web remoting.
And that's quite interesting.
I hadn't come across that before.
And what that does is you configure you put like a class name in the DWR XML file.
And it then exposes every method inside that.
That Java class.
To being called remotely.
So there's quite a lot of attack surface there.
And I think some of the vulnerabilities I found were not intended to be reachable.
But because they include the whole class, there's various methods in there that can
be reached.
So because we have root access to the clear pass, what you can do is just go and enable
debug mode for direct web remoting.
Which gives you a nice like HTML interface.
So you can just go.
And click around and see all the various methods and such that you can call.
The next step is to decompile the Java code.
And I like using Procyon for doing that because Procyon has a flag SL or stretch lines.
And what that does is in the output decompiled code, it will match the Java files that generates
lines to the line numbers in the line table.
And insert new lines where they're needed.
And what that buys you is the ability to do line-based debugging.
Which makes it easier when you're debugging an application and want to break on a specific
line.
And you can debug applications from decompiled code.
Which was actually kind of a surprise to me.
But it works well enough.
If you just load that code that you've decompiled into an IDE.
And it works.
I use IntelliJ IDEA.
And then just set up a remote debugger like this.
And then connect to it.
And that gets you all sorts of good things.
Like you can see the stack trace.
You can see the variables at run time.
So if the like static code that you're trying to read is utterly inscrutable, you can connect
to it and see what's going on at run time.
Which is quite helpful.
Another good feature of that is you can set break points on interesting syncs.
So process builder runs a command in Java.
So what I do here is set this break point that dumps the stack trace and prints the
command.
But it doesn't actually break the application.
So you can set this up when you're connected to the application.
And then go to the app and click around this.
Do some stuff.
And then come back and look at your logs.
And you get things like this.
Which will show commands that are being executed via process builder.
And where the ‑‑ what the stack is.
And what the trace looked like at the time.
So first vulnerability is an in‑map argument injection that was reachable via a path traversal.
It worked like this.
That's the relevant Apache config file.
So you can see it's mounting the activity dump service alias via JK mount which mounts
it into like a Tomcat worker.
So any URL that starts with a J.K. mount.
Starts with activity dump service will be sent to back end Tomcat.
But you can do a traversal in there with the dot, dot, semicolon slash trick.
Because Apache sees that URL at the top as starting with activity dump service whereas
Tomcat actually follows that traversal.
And will send it you to network services which is otherwise unreachable.
So I can access this without authentication.
And what it does is posture validation.
Which basically lets you like in map.
In arbitrary IP address.
This is a snippet of the Aruba code that was in there.
And that looks pretty vulnerable, right?
Like it's taking the host IP and just constructing a string out of it and passing it to run time
get exec.
You could just command inject it, right?
No you can't.
Because run time get run time dot exec doesn't actually invoke a shell.
It tokenizes that.
And then on the bottom right there.
You can see the exec.
Exec VE is not splitting that into the LS and ID command.
It's just running trying to LS that file that doesn't exist.
So it's not vulnerable to command injection.
We see when we test it here that the who am I command isn't run.
And it doesn't work.
But it is vulnerable to argument injection.
What's argument injection?
I kind of.
Explain it like command injection lets you execute arbitrary commands.
Whereas argument injection lets you manipulate the arguments to a command.
And that doesn't sound super useful.
But it actually is quite useful.
A lot of binaries have useful flags you can call that do dangerous things.
That GTFO bins is a good resource for it.
And I also see this quite often.
Where I think the devs have fixed.
A command injection issue previously.
But they haven't fixed an argument injection in the same area.
Because fixing command injection depending on how you do it doesn't necessarily prevent
argument injection.
So I think this is a really underrated bug class.
And definitely one to watch out for.
Given how often I've seen it.
Anyway.
We can do argument injection in that Nmap call.
So you can see I'm running the help command.
But there's also.
Sorry the help flag.
But there's also more useful flags.
You can use for exploitation.
So obviously you can just write the Nmap output into various directories.
It also has a script HTTP fetch which is included by default.
That will let you pull in a file from a remote host.
The one you're scanning.
And write it to a directory you specify.
And Nmap scripts are lower.
So you can execute arbitrary commands through them.
Like the bottom there is always execute.
So the way I exploit it is like this.
The blue.
The blue is the directory traversal.
And then the red you can see at the top in the first request I'm fetching a script from
my host.
And storing it in the folder.
Then the second one I actually just specify that as a script.
And that contains my shell.
So I can run code like that through the argument injection.
If we don't have egress you can also get around it.
Because on clear pass it has the guest application which is PHP.
And what you can do is just write into that directory which is the web route and like
write a PHP shell.
XSS is pretty straightforward.
I'm not going to go into that too much detail here.
But basically there's an area that you could reach unauthenticated depending on the config.
You could send it that post request with the XSS payload.
Didn't fire in the main application.
But another area of the application it did fire.
So XSS is really in my mind an output encoding issue.
So even if it's not firing in one area of the application, there are other areas.
Make sure you've checked all the areas to see if that same payload is user data is elsewhere.
Okay.
Class loader manipulation.
So a while ago there was a classic struts one vulnerability.
And that was end two.
And that was end two.
And that was down to it using this library Apache bean utils and calling populate on
a bean with user supplied data.
And what that lets you do is call arbitrary getters and setters.
But at the time they hadn't blocked you from calling get class and get class loader which
lets you set arbitrary values in the class loader which can be quite useful.
So clear pass used to use a vulnerable.
Excuse me.
A vulnerable version of bean utils which was vulnerable to that and it also had an unauthenticated
HTTP endpoint that let you directly pass user data to it.
So when I found this, clear pass was using Tomcat 7 and there's no publicly known proof
of concept for turning class loader manipulation into code exec in Tomcat 7 on Linux.
But you can do other things like overriding the docket.
And you can set an alias and what setting an alias lets you do is basically aliases
like a URL to a path on the file system.
So that gives you an arbitrary read.
Also if you have the ability to upload files to the file system, you can set the alias
to that directory and like upload a JSP shell.
So okay.
We have an read.
On clear pass.
It's often set up in a cluster mode.
And even when it's not, it creates this file here, the cluster password dot properties
and that contains the clear text password for the cluster admin user and that buys
you a lot because the cluster admin user is very highly privileged.
When I went to exploit this, I found in the Apache config that actually prevented any
URL with dot properties in it, no doubt in relation to some other vulnerability but can
be simply bypassed with the semicolon.
So.
What you can do once you've read the cluster admin password is access the tips API.
What I'm doing in the top box there is creating an admin user which lets me log into the web
interface.
Once I can log into the web interface, there's a bunch of different ways of uploading files
to it.
And they go into like a temp directory, which normally is not a problem, but because we
can set an alias, we can just alias that temp directory to a reachable URL.
Okay.
And then access our uploaded web shell, giving us code exec.
Signature check bypass, I'm going to skim over because I realize I talk too fast when
I was timing this talk.
But the details are in this slide deck.
So I'm just going to go over there.
Right.
Here's the good one.
So ClearPass has like a go binary listening on local host on port 7007.
And you can.
You can reach it via Apache.
And what it does, the go binary does the authentication and it attempts to access an exported for
header and checks if that is exactly local host or 127001.
If that exported for header doesn't exist, it falls back to the remote address, which
is always going to be local host because you're talking to it via Apache.
Apache doesn't let us mess with the exported for local host in the request headers.
It's been explicitly blocked.
And also it would just include even if I could set it, Apache would simply add the exported
for header I sent to its own one and then it wouldn't exactly match 127001.
So what we need is like a way of removing headers.
It turns out you can do that.
So there's something called a hop by hop header.
And what that lets you do is kind of like tell the server you're talking to, like,
hey.
This is just between me and you.
Like don't tell it to upstream.
That is defined in RFC2616 and basically lets you remove headers from what it's saying.
So an example request and response looks like this at the top.
You can see it's saying exported for.
And then down the bottom, if I add exported for in the connection header, which is how
the hop by hop works, it's actually not forwarded upstream.
Okay.
As an interesting aside, I found this vulnerability in September 2021.
And when I was reproducing the vulnerability for this talk, I couldn't get it to work.
And I was like, what's going on here?
This is interesting.
So I Googled for it.
And whoops, turns out that was actually an Apache vulnerability that I had been accidentally
sitting on for several months.
So I just reported it like a month ago, I think.
Yeah.
Anyway, it's patched now.
So.
Let's go APIs binary.
What can we do?
Well, what it supports is letting you pass in the URL to a ClearPass upgrade file.
And the way ClearPass upgrade files work is when you they're basically a tar file.
And within that tar file, they have a zip and a signature that sits beside it.
And when you get it to do an upgrade, it pulls that tar file, extracts the content.
And then it didn't ‑‑ if the signature doesn't match, it doesn't delete the contents.
It just deletes the outer tar file.
But those things are still sitting extracted on disk.
So there's a few different ways of exploiting this.
And what I ended up going with is doing it twice.
So first of all, you upload a tar file that just contains a SIM link to the guest directory,
which is, you know, your writable web route.
Then it deletes the tar.
But leaves that SIM link.
And then in the next tar file, you do this.
And create a PHP shell that is in a folder with the same name as the SIM link.
And then when the tar extracts it on the second run, it writes through the SIM link
and into the web directory.
So you can get an arbitrary file right anywhere on disk like that.
That's how the requests look to exploit it.
Right.
Next target is Airwave.
Okay.
So Airwave is like a network management system.
It can be a virtual appliance or physical hardware.
It runs a CentOS 7 again, NGINX, and Apache and the main web apps written in Perl.
Here's our goose-based attack surface of what the airwave looks like.
Yeah.
So the first bug I'm going to talk about is an auth bypass.
When ClearPass is ‑‑ sorry.
Airwave is not.
is set up to do auth via radius.
So, imagine you're a Ruber and you're writing some code
and you say, hm, how do we determine
if the radius authentication attempt
to this airwave web app was successful?
Should we use a reliable Perl library
that supports radius authentication?
No.
Should we just shell out to a binary
used for testing configs and re-ex the output?
Yes.
Yes.
So, this is the code that's doing part of it.
So, it's taking the supplied username and password
and creating a config file for the EPOL test binary,
which has the same format as WPA supplicant.
There's a bit of a reasonably inscrutable Perl,
but basically what it's doing is just sending
that config file to EPOL test over standard in.
And then calls the extract EPOL output subroutine,
which works like this.
So, what that does is basically just re-exes
the output of EPOL test and looks for the string
entering state authenticated and then some other stuff,
letting it know what the user's privilege levels are.
So, what does the output of EPOL test actually look like?
Well, it's a testing binary, so it's quite verbose.
And it looks like this.
And crucially,
the username is output,
regardless of whether the authentication
was successful or not.
So, because it's just re-exing
for entering state authenticated,
what we can do is say,
hello, yes, my username is entering state authenticated.
Set any password and get logged in as that user.
Interestingly, I found some comments
where the devs were very close to finding this bug,
but not quite.
So, that's an auth bypass.
Well and good.
But, you know, we want a shell as well.
This is some interesting code.
Let's go back and look at it again.
So, it does escape the quotes, double quotes,
so you can't escape out of the username.
Or can you?
It turns out that's not the only way of escaping,
of getting out of a config line on EPOL test.
You can also inject new lines.
So, what that lets you do is inject a new line, and, you know,
and then you can put arbitrary config lines
into this config file.
And given it has the same format as WPA supplicant,
I looked through it and found that it supports
OpenSSL engines via the PKCS11 engine path.
That is accepted by most common OpenSSL commands,
and the engine is basically like a shared library
that is loaded and executed when run.
So, you can inject a config line that looks like this,
and set PKCS11 engine path to a file on disk.
The config ends up looking like that
after we've done the new line injection.
And that's how you can use it to get code execution.
So, simply upload your engine file onto disk
after you've exploited the auth bypass,
and then run that command,
and it will load and run your arbitrary code.
Right, pearl to serialization.
So, some endpoints are very similar.
It's an airwave to serialize pearl objects,
which is quite interesting,
and they're signed with like a per install secret.
And I hadn't really come across pearl to serialization
before, but it's using a library called storable.
And when I looked into it,
there's only a few like good resources on it.
So, I read those, and none of them really answered
the question I had of like, how do I exploit this?
Reading the docs, it specifically notes,
deserialization.
Set eval to one, deserialization is done via eval,
which is dangerous.
And do not accept storable docs from untrusted sources.
This is the pearl code that does the deserialization.
So, it checks the signature,
and then it deserializes the object
after first setting storable eval to one.
So, I thought, great, this should be pretty easy to exploit.
I know how deserialization bugs work.
You look for things like,
for example, in PHP, you have magic methods,
and basically they're like things that get automatically run
at certain stages in an object's life cycle.
So, the in-pearl destroy is run
when a runtime object is destroyed.
And I found this file, http.pm.
It basically checks if an array key exists,
and if it exists, it calls it.
And there has to be a code ref, though,
which is like a subroutine in pearl.
So, this is how you construct an exploit for it.
I've just put just a basic sleep command in there,
and freeze it.
Sign it with the salt, which you can get.
You kind of have to exploit another bug to get the salt,
but there's a zero.
And then send it the base64 object, and you get your sleep.
So, the deserialize works great.
So, I sent that to them.
Then they fixed it poorly,
and then I bypassed the fix.
And then they didn't fix it very well again.
And now, I don't know, it might be fixed.
They stopped paying for bugs in this product,
so I stopped looking.
Anyway, later on, I was looking at the docs again,
and it said, like, it's done by eval.
I thought, do I really need to call a destructor?
That doesn't sound like how it works.
So, it turns out, it is actually just evaling it.
And what you can do is just go and hex edit
your, like, frozen pearl object, and put it there.
Put arbitrary code in, and then when you thaw that
with eval on, it just gets run.
So, you don't actually have to go down that destructor path
unless eval's not set.
Okay, last one, glass.
So, glass is like a single pane of glass.
I assume is why it's called glass.
It, like, collates airwave data.
It's Kubernetes, and it used to be Coros,
and now it's Ubuntu.
Has a lot of microservices, and some very hefty memory,
so I wanted 96 gigabytes of RAM,
which is a bit much for my poor old laptop,
but I managed to bargain it down to 24 and get it running.
The web interface just looks like that.
Here's the Goose-based attack surface.
So, there's a lot of, you know,
there's a lot of stuff going on in there,
like Grafana, Elasticsearch.
That's obviously why it needs so much RAM.
There's a lot of pods running on this thing.
So, first thing I did is look at the NGINX config,
and there's quite a few.
It's proxying requests to all these different pods.
So, I thought, okay, I'll try and find exploits
via the web interface.
So, I log into the web interface.
Literally, the first thing I try
has a command injection in it.
So, that's pretty, pretty,
I got a bad sense when I saw that.
Anyway, that's a post-auth issue.
But turns out that, you see the glass
at the start of the URL,
turns out that's actually just, like,
an authentication layer,
and then proxies the request further on to a different pod.
That pod is actually also directly reachable via NGINX.
So, you can simply change the URL
and turn it into a pre-auth bug,
which is good, but,
so we have Code Exec is root in a pod,
but I kind of want to escape the pod.
So, if you have a look at the mounts,
there's a lot of read-write mounts,
and these are running as privileged as well.
So, the one I ended up exploiting
was the EDC systemd mount,
and what you can do there is actually,
because it's maps in the systemd directory
from the node,
just create a systemd service
and start it from inside the pod,
and you get escaped from the container you're in,
and a full cluster compromise from a pre-auth bug.
So, for authentication,
it uses this thing called CAS,
Aperio CAS.
Originally, it was running 4.14,
and there was like a known exploit in that,
which was a deserialization.
So, I exploited that.
At the time, there was no public proof of concepts,
but there is now, which I've linked there.
Since they're public, I'll just skip over that.
Then they updated it, after I submitted it,
to 4.17, so fixed according to the vendor.
And it changes how the deserialized object is encrypted,
and they also removed the Apache Commons jars,
so I couldn't use those for gadget chains anymore.
But looking at the vendor fix,
they specifically highlight,
if you're using the default encryption keys,
which they were, and you have not generated
new keys, you must take action to regenerate the keys.
Do you think they regenerated the keys?
No, they did not.
They kept those keys.
So, what that means is we can just still sign
arbitrary Java objects using this code here,
if you wanna do that yourself.
And are there more deserialization gadgets?
Yes, there are.
So, I played a bit of gadget whack-a-mole,
where I'd submit them a bug, and then they'd fix that,
but not change it.
They'd change the keys, like I suggested,
and then I'd find another gadget,
and eventually, they fixed it,
so that the keys are randomly generated on boot.
Right, let's have a quick demo.
Alt-Tab.
Okay, I have to find it.
Okay.
Yep.
So, what I'm doing here is just gonna exploit
a few of these vulnerabilities I've just talked about,
but it's nice to see them in action.
So, this is the nmap argument injection.
Hopefully, that font size is readable.
So, just kick it off scanning my host,
which is hosting the n6.nse, which is the Lua script,
which I'm gonna get the ClearPass to pull in and run.
Just takes a second.
Yeah.
Hopefully, the nmap come in soon.
There we are.
So, now that n6.nse Lua script is sitting on disk
on the ClearPass.
So, then we execute the second argument injection,
which just runs it as a script,
and that's gonna send us a reverse shell,
which should come in now.
There we go.
That's the first pre-order.
Right, so this one is the airwave username regex issue,
where if I try to log in with, you know, just an invalid user,
that it's not gonna work, but if I paste in that entering
state authenticated username, it logs us in,
and I'm gonna go and exploit the openSSL engine issue,
so I specifically picked this firmware type
because it doesn't have a web address in it,
validate anything in it and I can just upload the OpenSSL engine file on disk.
That's how you construct it, by the way.
So, now that's uploaded to disk.
And then I'm going to go and exploit it with that EPAL config injection and get the shell
to come in now.
Okay.
This is the glass command injection issue.
So we're going to get this ‑‑ we're going to do it backwards and get the system D pod
break out file and just base 64 it because it's an easy way of transferring a file in
a command injection and write that onto on disk inside the pod via the command injection.
And that's run.
Get our NCAT listing.
Then we're going to restart system D so it can see that file.
And then we're just going to start the service.
And the shells come in.
And that's a full route on the glass cluster.
Yeah.
You can see there's a lot of containers running.
Thank you.
Right.
One second.
Okay.
Okay.
So, getting started ‑‑ getting started yourself.
So I showed you how to get research access to the virtual appliances via like just mounting
a live CD.
You know, but how do you get access to the hardware APs?
If you don't want to find an exploit, let's have a look at that.
So.
Arubos has a support command and it specifically says, do not use this command without the
guidance of Aruba customer support.
Yeah, but we're hackers.
So I'm going to run it anyway.
And it asks me for a user name and then it prints out a token and gives me a URL.
So okay.
We'll just go to that URL.
It says this tool is specifically restricted to attack.
So well, just try decoding it anyway.
No.
Not authorized to do that.
Okay.
Got to bust out the decompiler.
So turns out what it's doing is it's actually using elliptic curve Diffie Hellman which gives
you key agreement over an untrusted channel.
So I initially reversed this support binary with GITRA and which took me some time because
it was a little tricky.
And then turns out that source code was just in the GPL release on GitHub.
So I guess the lesson there is like try Googling first.
Before you spend hours in a decompiler.
So the elliptic curve they're using is custom.
They've got their own elliptic curve.
Those are the fields and they have like a fixed public key for Aruba support that's
compiled into the support binary.
So what's actually happening when you run that support command is it generates you a
public private key pair on the hardware AP you're running and then that token is actually
the X coordinate.
Of your public key that it's just generated.
So you give that to the support command and then what it does is calculate the elliptic
curve Diffie Hellman shared secret and then uses that to derive the support password by
doing a bit of like HMAC and that sort of thing.
So that's like that's pretty cool.
There's a lot better than some like hard coded static super user string like I have seen
in some other vendors.
But.
Let's look a little bit closer at that.
The comments say it's a 64 bit elliptic curve.
Elliptic curves are small but they're not that small.
And there's also some comments about skipping NIST validation which certainly piqued my
interest somewhat.
Turns out you can crack that key.
So a 64 bit elliptic curve roughly has 32 bits of security.
It's well within range of a desktop computer.
Power within range.
With a good implementation about on my desktop, 200 seconds.
So if we paste those constants in and break the Aruba support public key, takes about
two minutes.
So that's pretty cool.
It's fast.
But you know, is that fast enough?
Turns out with the discrete logarithm problem, you can solve it much quicker when the order
of the curve can be factored.
Using.
You can do this via the algorithm.
And then it kind of makes the complexity the basically the largest prime factor of the
order of the curve.
So it's quite common for elliptic curves to use prime orders to prevent this.
Did Aruba use a prime order for their curve?
No they did not.
It can be factored.
So the largest factor is only 40 bits.
So then we can break it in six seconds.
There's the private key.
So what that buys you is the ability to implement the response for the challenge response script
and get support access to the device.
Which gives you a full shell on the device.
There's the script for doing it.
It's available on the media server and I'll make it public.
So you can then now get research access to your own Aruba APs and a full root shell.
End of presentation.
Thank you.
.
.