 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 pentester 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. I see 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. That'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 a single pane of glass that agglomerates AirWave data. So, this is a kind of terrible diagram of how they relate to each other in a network and how you might find them configured. Just Aruba stuff. So, first thing is the AP. I put the least amount of time into researching this and mostly focused on post-orthotact 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 Arubos which is a operating system that they ship on it. It uses a Linux kernel. And the newer AP's mostly ARM. And some of the older ones use the MIPS architecture. That Arubos 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 wanna 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 a CPIO 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 wanna get runtime access to the AP's. 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 route. And build route's an awesome set of scripts that you can basically cross compile for all sorts of different architectures. And you can build static binaries so you don't have to worry about libc compatibility or anything like that. It's got a nice little interface. You can just go into it, tick the boxes for things you want and it'll build that for you. 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 multi-arch. And it will actually like pull the binary across the wire using the GDB protocol and all the libraries it has loaded. So, that 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 air wave 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, 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 it 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 somewhat convoluted way where you had a file write into that directory, the EDCH-TDPD custom image directory and you could create a binary that had things like Bactics, so meta characters in the file name and then when you run the show and audit commands 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 on the file name so obviously you can't have a slash because it's a file name but there's also some length restrictions so it was easy enough to do Bactics ID good enough for a proof of concept but I wanna 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 Bactics 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 ArubaOS 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 the dollar home is too long and then I kind of just wildcard through some various directories so that after resolving the variables looks like this and then after you've resolved the wildcards 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 emulate a command injection you can see it's actually running itself. So, the trick there is you wanna look at even if you have like restrictions on characters or things when you're trying to exploit a command injection the environment's quite a good place to look. There's often like things like semi-colons and on some boxes depending on how the environment's configured and I also use that in another command injection vulnerability whereby they didn't let me do backticks or anything and I could do a dollar and a left parentheses which is like a sub-shell but if it was followed by a right parentheses they disallowed it. So, what I did is just actually define that right parentheses as a variable before the dollar and left parentheses and then use afterwards. So, yeah, check out the environment variables. It's a good place to source characters you may need. I'm just gonna 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, or 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. 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 and Linux that you might need to access like password, shadow, pseudo is 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 a encryption password because people would 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 init ramfs. You can pull it out like that. 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's 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 I look at the web XML file and you can see what the servlet mapping does is maps like 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 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 ClearPass, 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. So, the next step is to decompile the Java code and I like using proc.on for doing that because proc.on has a flag SL or stretch lines and what that does is in the output decompiled code it will match the Java files, it generates lines to the line numbers in the line table and like 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 like 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 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 runtime 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 runtime 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 it, do some stuff and then come back and look at your logs and you get things like this which show commands that are being executed via process builder and what the stack trace look 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 activity dump service will be sent to backend 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 could access this without authentication and what it does is posture validation which basically lets you like in-map and arbitrary IP address. This is a snippet of the Aruba code that was there 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 runtime getexec where you could just command inject it, right? No, you can't because runtime get runtime.exec doesn't actually invoke a shell. It tokenizes that and then on the bottom right there you can see the exec ve is not splitting that into the ls and id command. It's just running try to ls that file that doesn't exist so it's not vulnerable to command injection if 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 it 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 want 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 exploited is like this. The bin blue is the directory traversal and in the bin in red you can see at the top in the first request I'm fetching a script from my host and storing it in the temp Z 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 ClearPass 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. Excess is pretty straightforward I'm not gonna 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 load manipulation so a while ago there was a classic struts one vulnerability and that was N2 and that was down to it's using this library Apache bean utils and calling populate on a bean with the 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 ClearPass used to use 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 ClearPass 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 doc base and you can set an alias and what setting an alias lets you do is basically alias is 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 to the file system you can set the alias to that directory and like upload a JSP shell. So, okay we have an R read. On ClearPass 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 and 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 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, just going to go over there. Right, here's the good one. So, Cleopas has like a go binary listening on localhost on port 7007 and you can reach it via Apache and what it does, the go binary does the authentication and it attempts to access an X4 to 4 header and checks if that is exactly localhost or 127.001. If that X4 to 4 header doesn't exist it falls back to the remote address which is always going to be localhost because you're talking to it via Apache. Apache doesn't let us mess with the X4 to 4 localhost 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 X4 to 4 header I send to its own one and then it wouldn't exactly match 127.001. So what we need is like a way of removing headers and turns out you can do that. So there's something called a hot by hot 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. So that is defined in RFC 2616 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 X4 to 4 and then down the bottom, if I add X4 to 4 in the connection header, which is how the hot by hot works, it's actually not forward upstream. 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 there was actually an Apache vulnerability that I'd been accidentally sitting on for several months. So I just reported it like a month ago, I think. Yeah, anyway, it's a patch now. So, but now we can reach the Go APIs binary. What can we do? Well, what it supports is letting you pass in the URL to a clear pass upgrade file and the way clear pass upgrade files work is when you are, 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 contents 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 your writable web root. 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 this sim link and into the web directory so you can get an arbitrary file right anywhere on a disk like that. That's how the requests look to exploit it. Right, next target is AirWave. So AirWave is like a network management system. It can be a virtual appliance or a 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 gonna talk about is an auth bypass when clear pass is, sorry, AirWave is set up to do auth via radius. So imagine you're a Ruba and you're writing some code and you say, 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 reex the output? 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 ePoll test binary which has the same format as WPA's supplicant. There's a bit of a reasonably inscrutable Perl but basically what it's doing is just sending that config file to ePoll test over standard in and then calls the extract ePoll output subroutine which works like this. So what that does is basically just reexes the output of ePoll test and looks for the string entering state authenticated and then some other stuff letting it know what the user's privileged levels are. So what does the output of ePoll 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 reexing 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 and that's all well and good but 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 ePoll test. You can also inject new lines. So what that lets you do is inject a new line and then you can put arbitrary config lines into this config file. And given it has the same format as WPA supplegant I looked through it and found that it supports open SSL engines via the PKCS 11 engine path. That is accepted by most common open SSL commands and the engine is basically like a shared library that is loaded and executed when run. So we can inject a config line that looks like this and set PKCS 11 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, Perl deserialization. So some endpoints in Airwave deserialize Perl objects which is quite interesting and they're signed with like a parent store secret and I hadn't really come across Perl deserialization before but it's using a library called storable and when I looked into it there's only a few 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, if you set eval to one deserialization is done via eval which is dangerous and do not accept storable docs from untrusted sources. This is the Perl 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 things that get automatically run at certain stages in an object's life cycle so that in Perl 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. So and there has to be a code ref though which is like a subroutine in Perl. So this is how you construct and exploit for it. I've just put a, just a basic sleep command in there and freeze it, sign it with a 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 basic 64 objects and you get your sleep. So the deserialize works great. So I sent that to them and 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 and 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 eval-ing it and what you can do is just go and hex edit your frozen pearl object and 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 KOROS and now it's Ubuntu. Has a lot of microservices and some very hefty memory requirements. It wanted 96 gigabytes of RAM which is a bit much for my poor old laptop but I managed to buy 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 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 and that's just 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 was 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 that 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 execs root in a pod but I kinda wanna 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 the sync called CAS, a period CAS, originally it was running 4.14 and there was like a non-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 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. All right, 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 in-map argument injection. Hopefully that font size is readable. So I just kick it off scanning my host which is hosting the n6.nse which is the lower script which I'm gonna get the clear pass to pull in and run. Just takes a second. Should see the in-map coming soon. There we are. So now the n6.nse lower script is sitting on disk on the clear pass. 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, this one is the AirWave username regex issue where if I try to log in with just an invalid user that's not gonna work but if I paste in that entering state authenticated username it logs us in. Then I'm gonna go and exploit the open SSL engine issue so I specifically pick this firmware type because it doesn't validate anything in it and I can just upload that open SSL engine file on disk. That's how you construct it by the way. So now that's uploaded to disk and then I'm gonna go and exploit it with that epel config new line injection and get the shell to come in now. Okay, this is the glass command injection issue. So we're gonna do it backwards and get the systemd pod breakout file and just base 64 it because that'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 end cat listening. Then we're gonna restart systemd so I can see that file and then we're just gonna 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 up. Thank you. Right, one second. Okay, so getting started, where are we? 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? Well, if you don't wanna 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 gonna run it anyway and it asked me for a username 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, we'll just try decoding it anyway. No, not authorized to do that. Okay, gotta bust out the decompiler. So it turns out what it's doing is it's actually using elliptic curve Diffie-Hellman and which gives you key agreements over an untrusted channel. So I initially reversed this support binary with Ghidra and which took me some time because it was a little tricky and then it 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 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 nest 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. How within range? I think good implementation about on my desktop 200 seconds. So if we paste those constants in and break the Aruba support, it's 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 and you do this for us the Polig-Hellman 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. 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 a 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. Any presentation? Thank you.