Okay, well, good morning, or good evening, or good afternoon, wherever you are right now.
Welcome to Q&A with Gals Aurore. We have a little bit of business to take care of first.
This is Gals' first time speaking and presenting at DEF CON. And not only that, it's also,
his wedding anniversary. And his wedding occurred actually in Las Vegas. So,
unfortunately, as you guys know, we are all stuck at home. So, we're not ones to let
the Rona get in the way of staying fairly well lubricated. So, to everybody playing the home
version of DEF CON. We have shots here. There we go. All right. So, Gal, here's to you.
Congratulations on making a stage. Congratulations to your bride on surviving here with a hacker
who made it through DEF CON. So, here's to you. Cheers. I'll drink to that.
All right. Not a bad way to start. Okay. I'm glad we did that.
Okay. So, welcome to Q&A with Gals Aurore. Gal gave a fantastic presentation on Ruckus wireless
gear and some of the problems that seem to be resonant in that over and over and over again.
All right. So, Gal, why don't you introduce yourself a little bit. Tell us about yourself
in case some folks may be glazed over that part of your presentation. And we'll start
queuing up some of these questions from the audience. Sure. So, I work for Adaf Research,
which is a part of HCL AppScan. And I've been doing reverse engineering for something like 10,
11 years. Especially embedded devices. This is a subject that I was exploring for a while.
And actually, something that I did not say in my talk, I talked about it in the previous talk,
was that the inspiration for this research was because last year I visited DefCon and BlackHat,
and I noticed that BlackHat are using this gear. So, this is what started everything.
Yeah. You saw them in the wild, like, oh, nope, I gotta do that. Right, right. I've heard about
them, but I never really had the opportunity to really do a full research. And yeah, so it turns
out to be two research. One was presented half a year ago in Leipzig, in CCC. And this one,
is the follow-up research that I managed to find additional vulnerabilities and some
fixes that did not fix the vulnerabilities I already found.
Well, very good. So, you found a number of different problems and kind of triggered them
to take some action on their part. Do you know, does Ruckus actually patch any of their gear
automatically, such that, you know, what you found and what they did
fix or try to fix, did that get pushed out to all the gear worldwide?
Right. So, as far as I know, Ruckus avoids automatic update. I understand where it comes
from because, you know, pushing an automatic update through the air on network gear might
sometimes mess configuration and do some things that you don't necessarily want to happen.
So, I get why they don't push their updates. But yeah, so the thing I think is the most
important from my talks is Ruckus users should stay up to date, you know, even now, even after
this, even before my previous research and on this research as well, they need to keep everything
up to date. So, there's a general question out then from Hawkeye Dank about how did Ruckus
respond to your research and what sort of a communication did you get back and forth with them?
Yeah. So, in my research group, I think like most of the research group, we try to
do a full disclosure, which is a 90-day disclosure. And with Ruckus, both the first
research and this follow-up research, we gave them enough time. Eventually, it was a bit more than
90 days. It was around 100 and so days. And we just sent them a report with all the
things we found. We just talked about it a bit and they fixed... well, they tried to fix everything.
So, all in all, the disclosure was pretty standard.
It's one of the interesting things to have the conversation with folks about
how did your disclosure go? How did that conversation go with the developers and
with the people on that team? Because there's a lot that you can learn about a company by
how that relationship evolves. So, it's nice to get that data point.
Right. If I may add something, if we are talking about a disclosure, I think one thing...
this is from my first research and not from this one... I think one thing that took Ruckus by, let's
say, a surprise was the fact that I managed to recover a lot of function names from their
binaries because they left a lot of debug information both in the debug logs and some
assertion in the code itself. So, yes, when I sent them the report, it was with the
right function names and the right architecture. So, I think it was a bit of a shock for them.
Well, it's a lesson that I bet they learned to try to not give free stuff for hackers.
Yeah, no, that's good. Well, that goes pretty well with this question about
how does owning the device help you with the research that you did?
Oh, yeah. So, well, yes, my first research was done on emulation, 100% based on emulation. I just
extracted the firmware from Ruckus, and then I managed to emulate most of the device itself,
which, well, all the vulnerabilities were found on the web interface. So, I managed to get the
web interface up and running, which included different binaries. But I think when I got the
actual device, when I bought it, so I bought it for live demos and stuff. And so, when I got the
device itself, I could debug and see different things that were more related to the configuration
of the device itself, because sometimes the device you get from the firmware, the device you emulate,
not necessarily has all the configuration or the binaries, depends on how the vendor is deploying
the firmware. And, yeah, and when I got the device itself, it really helped me to override the admin
credentials. So, one of the vulnerabilities I demonstrated is admin override. And I just,
by debugging just the binary itself on the device, I could see all the files it tried to,
which actually, it was with a simple asterisk, all the files he was opening and writing to.
And this is how I realized those are the configuration files that are important. And
if I manage to override one of them, well, specifically the sys.xml, I would win. And
thankfully, it happened. Well, so you're definitely not afraid of diving into the
technical stuff here. So, would you talk just a little bit more then about how that was different
doing it, how you were able to find those things easier on the physical device than you were with
the emulated device? I'd like to hear more about that. Right. So, it's really common in embedded
devices that they usually separate the web server and the logic to different binaries. And usually
they find this way to communicate with each other. It's very popular to use Unix domain
socket. And this is exactly the case in Ruckus. So, eventually, the web server just talks with
other services, with other binaries, with domain sockets. And at first, when I was emulating the
device itself, I was emulating only a single socket to the logic itself. And that's about it.
But when I had the physical device, just by running a simple PS on the device, I could see
all the other binaries that I had to trigger and all the domain sockets they had to use to get
everything work together. So, yeah, that really, really helped a lot with the other research.
That's probably a good thing for a lot of folks who are getting into this field to have some
understanding of is you can do a lot from emulation, but there does come a point where
having the physical device is going to be a benefit to you.
Right. I agree. I think that... well, if you put enough effort, I tend to think that you can get
most of the things done by emulation. Depends, user space, of course, but you can even emulate
like the kernel and Ruckus actually gives you the config file for the kernel itself. So,
theoretically, you can just compile yourself the Ruckus kernel, exact kernel, and run drivers and
everything. But, yeah, there's this... when having a physical device really, really speeds things up.
Things that you need to spend some time and understand how to emulate, you just don't need
to do it. So, it really helps. Very cool. Once you found out that Ruckus had tried to fix
one of the vulnerabilities, how did you then figure out that they didn't fix it properly?
Okay. So, well, that was kind of a hunch, because... so, my first research, I found several
bugs. And I... so, when I got the fix, I was going through them. But I realized that the function
they're using to validate the... actually, everything that they are validating, all the
inputs from the user are... well, let's say it's not like airtight. It's not... they got some bad
practices there. And hopefully, I was managed to find these three primitives, which were the
new line, the shabang, and slash. And thankfully, with those primitives, I was able to
understand that this validation function is not doing a good enough job. And that's how I got the
injection again, to get the command injection back to work.
So, from the perspective of a bug hunter doing this work, would you, in the future,
change the way you wrote your bug report and sent that in to help the team come up with more of
these... to fix more of the... to fix more of your avenue in? Or would you do it the same way in the
future? You give them the... this is the area that I hit. And how would you structure that in the
future, knowing what you know now? Right. So, I think that... well, I did not know that they're
using this... so, apparently, this validator function was been there the entire time, even
before my research. It was using this bad validation function, like, since the beginning of
the first research. I would... if I would knew that they're going to use this function, and actually,
I did not knew this function even exists, but if I knew that they're going to use it, I would
definitely tell them to use a different function with a more robust white list or black list,
to be exact. Do you think any of those vulnerabilities, like that function that
you were just talking about, do you think that is present in other similar devices
that are out there? Or do you think that was kind of a custom rolled thing from Ruckus that it's
going to be a one and done kind of deal? Yeah, so, I think by the name of the functions, because
a lot of, as I said before, a lot of information I managed to extract from the debug functions and
debug logs in Ruckus, and because a lot of them are Ruckus related, I think that's only Ruckus
code base. I don't think that other vendors are using this code, but what I did realize,
and I already mentioned it in the research, I did realize that they're using this code base for
for more than one product line. So, for both of the product line, also the Wi-Fi controller, as well
at the access point, they all use the same code base, and that's why they were vulnerable to...
both of them were vulnerable to some of the attacks.
I like this. Hawkeye Dank has the question. Did you find a way to brick the Ruckus?
Brick? No, actually. So, at first, yeah, while doing emulation, it wasn't even in my mind.
But, of course, when I bought an actual device, I bought two, of course, because I already broke
some devices back in the time. So, I don't think, because I was dealing with user space
and nothing that was too deep in the internals of the device, I did not manage to
brick it. Although that, well, it was for another research, but I realized that if you write echo,
any echo, right, the A character to slash dev slash asterisks, usually the device gets
bricked. That happened to me before. I don't even know why I did that, but I just, I think it was
like a last resort. I was like, okay, nothing works. Let's try to echo to the entire dev,
and that worked poorly.
That's good to know.
Yeah. So, yeah, no rm slash, rm minus rf slash, and no slash dev asterisks.
I'll keep that in mind the next time I'm hunting around in these things.
So, in the stack overflow, did you have to use any sort of brute force to overcome the ASLR?
Yes. So, well, so this stack overflow, I was lucky enough to just base it, so the same
payload for my first stack overflow, although they were in different binaries, the library
that I was using to create the rope chains were both in libc. So, I only had to fix the addresses,
and basically I used the same gadgets. But the thing is, so in my first stack overflow,
back in my first research, I was trying to deal with the ASLR in a non-brute force way,
yeah, just to not to, you know, to create something a bit more robust. And I just decided
after I found the command injection, I just decided to ditch it, because, you know, there's
already an easier exploit for it. So, let's just see, like, let's do a POC for the stack overflow.
And on, okay, so with this research, I realized that because this is a different binary,
this is the web server binary, which is way more bigger than the ZAP binary from my first research.
So, I think I can overcome the ASLR not by doing brute force, maybe just, you know,
take something from the binary itself and use it. But again, because I already, because I found
and command injection as well, so I just decided to stick with the most basic POC, because the
command injection, in my opinion, is way more, it's not way more critical, but it's just different.
It's easier to exploit. You're talking about the web server. Can you talk more about the
web server correlation with the binary? Yeah. So, as I said, as I mentioned before, so the web
server is, and it's super common for embedded devices, it just communicates with different
processes, with different binaries. And one in particular was this, like, the device logic
called EMFD. So, this binary is the one that actually executes the commands and just do,
like, network configuration and just about everything. And the interesting part about
this binary is that Ruckus, so they, Ruckus were using this embedded JavaScript
developed, I think, by EmbedDisk. I'm not sure if this is theirs, but I think, so they work
together. EmbedDisk, which is the web server, supports the embedded JavaScript, E-M-E-G-S.
And so this back server, or back-end JavaScript, that was the one that, this is the language they
use to trigger different functions that would be sent to different binaries. So, I get into it in
the first, in my first talk, but also in my second, that, so they added a code to trigger these
functions that were using the domain socket that I talked about to just pass commands to different
binaries. And some of them were vulnerable.
Hawkeye Dank does ask the question here, he's talking about you found cross-site scripting
and some other exploits, which looks like he's specifically wondering about
Csurf vulnerabilities. Did you find any Csurf in there?
No, actually, so the entire Csurf token in, I didn't pay too much attention to it,
because, so in one of the pages, or in some of the pages in Ruckus, in the embedded JavaScript
language that I mentioned before, some of them were expecting a Csurf token, but the thing is that
some of them looks to be like hard-coded there, so probably I can just overcome this token,
but I did not pay too much attention for it, I must honestly say. Yeah, and the XSS vulnerability
as well, it was just out there. For every request you send, you just get the reflected, you know,
reflection for what you sent. So I'm like, okay, there's an XSS here, I gotta tell them.
You can't not report that one when it, you didn't, sounds like you didn't really try, it just
came back to you. That's true. So, and that's actually an interesting idea of how you are
approaching this, so if there are some vulnerabilities that just show up without
you having to really hunt for them, when you are reporting that, do you ever leave commentary
around, hey, so I found this one, I wasn't really looking for it, I didn't really hunt down in this
direction, or is this something that you're leaving open for future research for yourself,
or would you tell anybody else in the community, oh hey, there's probably some findings here if you
want to aim in this quadrant. Right, that's a good question. So no, I don't leave anything,
I try not to leave anything open, I just, you know, try to report everything that I, you know,
managed to found, even things that are not necessarily a full exploit, I would still
let them know. A good example for it is the information leakage. I also noticed that there's
this page, that you just go to this page, upnp.jsp, and you get just everything about the device,
and I'm like, okay, this is a bad practice, it can lead to a jailbreak, and you guys should fix it.
So no, I'm not, I think that the responsible thing to do is just to tell them, you know,
to report everything that you find. But that being said, I must honestly say that the XSS,
I only reported on this report, and not on my previous report, because as I said, it was really
obvious. But I just, you know, I just, I don't know if I forget, I forgot about it, but I just,
on this round, I just said, okay, I have to report it. Very good. Well, we're kind of
coming to the end of the Q&A session. And one thing that Falvo and I like to do is kind of
give you an opportunity to talk to the community about what's next, right? What's next in this
kind of vein of research? Where are you going to be taking this kind of thing next? And where do
you think that other people that are interested in the in the same kind of thing, how can they,
how can they take what you've done and then run with it in other directions?
All right. So, I think so. In our group, there are a lot of going on. We do all different sorts
of research projects. And I think I already got another research that I just started. It's not
going to be embedded devices, because I just want to experience with something else. Probably
going to be around a bit fuzzing. And that's it for now. But except for that, so, in my group,
we are also doing a very impressive research on iOS simulation, which is a really, really
cool project that I might also take some part of it. Or in general, I think, so, as I already said,
emulation in general, I think it's a really good thing to have in your arsenal as a researcher.
So, yeah. So, probably some more emulation for sure. And then my next research, I think,
is going to be, I hope, is going to be on something else with brand new vulnerabilities.
There's a lot of exciting stuff to look forward to, then. Thank you very much. That's cool.
Thank you, guys. Yeah. Thanks a lot. And thank you, everybody, for coming out for the Q&A session.
And we will see you guys later on. Congratulations again on a great talk.
And happy anniversary. Thank you very much, guys.
All right. We'll talk to you guys soon. Okay. Bye now.