[00:20.070 --> 00:29.030]  Okay, well, good morning, or good evening, or good afternoon, wherever you are right now.
[00:29.470 --> 00:37.230]  Welcome to Q&A with Gals Aurore. We have a little bit of business to take care of first.
[00:37.230 --> 00:44.630]  This is Gals' first time speaking and presenting at DEF CON. And not only that, it's also,
[00:44.630 --> 00:54.070]  his wedding anniversary. And his wedding occurred actually in Las Vegas. So,
[00:54.070 --> 01:00.520]  unfortunately, as you guys know, we are all stuck at home. So, we're not ones to let
[01:01.330 --> 01:07.710]  the Rona get in the way of staying fairly well lubricated. So, to everybody playing the home
[01:07.710 --> 01:19.770]  version of DEF CON. We have shots here. There we go. All right. So, Gal, here's to you.
[01:19.770 --> 01:26.510]  Congratulations on making a stage. Congratulations to your bride on surviving here with a hacker
[01:26.510 --> 01:32.530]  who made it through DEF CON. So, here's to you. Cheers. I'll drink to that.
[01:36.410 --> 01:42.070]  All right. Not a bad way to start. Okay. I'm glad we did that.
[01:42.630 --> 01:51.710]  Okay. So, welcome to Q&A with Gals Aurore. Gal gave a fantastic presentation on Ruckus wireless
[01:51.710 --> 01:59.010]  gear and some of the problems that seem to be resonant in that over and over and over again.
[01:59.010 --> 02:05.930]  All right. So, Gal, why don't you introduce yourself a little bit. Tell us about yourself
[02:05.930 --> 02:10.390]  in case some folks may be glazed over that part of your presentation. And we'll start
[02:10.390 --> 02:19.690]  queuing up some of these questions from the audience. Sure. So, I work for Adaf Research,
[02:19.690 --> 02:30.670]  which is a part of HCL AppScan. And I've been doing reverse engineering for something like 10,
[02:30.670 --> 02:44.270]  11 years. Especially embedded devices. This is a subject that I was exploring for a while.
[02:44.270 --> 02:51.070]  And actually, something that I did not say in my talk, I talked about it in the previous talk,
[02:51.070 --> 03:00.750]  was that the inspiration for this research was because last year I visited DefCon and BlackHat,
[03:00.750 --> 03:07.270]  and I noticed that BlackHat are using this gear. So, this is what started everything.
[03:07.910 --> 03:15.250]  Yeah. You saw them in the wild, like, oh, nope, I gotta do that. Right, right. I've heard about
[03:15.250 --> 03:23.430]  them, but I never really had the opportunity to really do a full research. And yeah, so it turns
[03:23.430 --> 03:34.510]  out to be two research. One was presented half a year ago in Leipzig, in CCC. And this one,
[03:34.510 --> 03:40.970]  is the follow-up research that I managed to find additional vulnerabilities and some
[03:42.430 --> 03:48.150]  fixes that did not fix the vulnerabilities I already found.
[03:50.690 --> 03:54.510]  Well, very good. So, you found a number of different problems and kind of triggered them
[03:54.510 --> 04:00.370]  to take some action on their part. Do you know, does Ruckus actually patch any of their gear
[04:00.370 --> 04:04.150]  automatically, such that, you know, what you found and what they did
[04:04.150 --> 04:09.670]  fix or try to fix, did that get pushed out to all the gear worldwide?
[04:10.010 --> 04:20.030]  Right. So, as far as I know, Ruckus avoids automatic update. I understand where it comes
[04:20.030 --> 04:28.330]  from because, you know, pushing an automatic update through the air on network gear might
[04:28.330 --> 04:37.270]  sometimes mess configuration and do some things that you don't necessarily want to happen.
[04:37.290 --> 04:46.970]  So, I get why they don't push their updates. But yeah, so the thing I think is the most
[04:46.970 --> 04:55.830]  important from my talks is Ruckus users should stay up to date, you know, even now, even after
[04:55.830 --> 05:02.270]  this, even before my previous research and on this research as well, they need to keep everything
[05:02.270 --> 05:08.030]  up to date. So, there's a general question out then from Hawkeye Dank about how did Ruckus
[05:08.030 --> 05:12.890]  respond to your research and what sort of a communication did you get back and forth with them?
[05:13.690 --> 05:21.310]  Yeah. So, in my research group, I think like most of the research group, we try to
[05:21.590 --> 05:29.790]  do a full disclosure, which is a 90-day disclosure. And with Ruckus, both the first
[05:29.790 --> 05:37.490]  research and this follow-up research, we gave them enough time. Eventually, it was a bit more than
[05:37.490 --> 05:45.130]  90 days. It was around 100 and so days. And we just sent them a report with all the
[05:45.130 --> 05:52.650]  things we found. We just talked about it a bit and they fixed... well, they tried to fix everything.
[05:54.150 --> 05:58.470]  So, all in all, the disclosure was pretty standard.
[06:02.420 --> 06:06.240]  It's one of the interesting things to have the conversation with folks about
[06:06.240 --> 06:11.540]  how did your disclosure go? How did that conversation go with the developers and
[06:11.540 --> 06:16.800]  with the people on that team? Because there's a lot that you can learn about a company by
[06:16.880 --> 06:23.360]  how that relationship evolves. So, it's nice to get that data point.
[06:23.380 --> 06:29.780]  Right. If I may add something, if we are talking about a disclosure, I think one thing...
[06:29.780 --> 06:37.060]  this is from my first research and not from this one... I think one thing that took Ruckus by, let's
[06:37.060 --> 06:43.540]  say, a surprise was the fact that I managed to recover a lot of function names from their
[06:43.540 --> 06:50.160]  binaries because they left a lot of debug information both in the debug logs and some
[06:51.220 --> 06:58.440]  assertion in the code itself. So, yes, when I sent them the report, it was with the
[06:58.440 --> 07:04.380]  right function names and the right architecture. So, I think it was a bit of a shock for them.
[07:04.380 --> 07:15.860]  Well, it's a lesson that I bet they learned to try to not give free stuff for hackers.
[07:16.220 --> 07:19.580]  Yeah, no, that's good. Well, that goes pretty well with this question about
[07:19.580 --> 07:24.220]  how does owning the device help you with the research that you did?
[07:24.620 --> 07:33.200]  Oh, yeah. So, well, yes, my first research was done on emulation, 100% based on emulation. I just
[07:34.520 --> 07:42.860]  extracted the firmware from Ruckus, and then I managed to emulate most of the device itself,
[07:42.860 --> 07:48.980]  which, well, all the vulnerabilities were found on the web interface. So, I managed to get the
[07:48.980 --> 07:56.940]  web interface up and running, which included different binaries. But I think when I got the
[07:56.940 --> 08:05.920]  actual device, when I bought it, so I bought it for live demos and stuff. And so, when I got the
[08:05.920 --> 08:17.460]  device itself, I could debug and see different things that were more related to the configuration
[08:17.460 --> 08:23.620]  of the device itself, because sometimes the device you get from the firmware, the device you emulate,
[08:23.620 --> 08:31.360]  not necessarily has all the configuration or the binaries, depends on how the vendor is deploying
[08:31.360 --> 08:39.980]  the firmware. And, yeah, and when I got the device itself, it really helped me to override the admin
[08:39.980 --> 08:48.050]  credentials. So, one of the vulnerabilities I demonstrated is admin override. And I just,
[08:48.050 --> 08:54.470]  by debugging just the binary itself on the device, I could see all the files it tried to,
[08:54.470 --> 09:00.170]  which actually, it was with a simple asterisk, all the files he was opening and writing to.
[09:00.210 --> 09:05.270]  And this is how I realized those are the configuration files that are important. And
[09:05.270 --> 09:12.550]  if I manage to override one of them, well, specifically the sys.xml, I would win. And
[09:12.550 --> 09:17.330]  thankfully, it happened. Well, so you're definitely not afraid of diving into the
[09:17.330 --> 09:23.750]  technical stuff here. So, would you talk just a little bit more then about how that was different
[09:23.750 --> 09:29.170]  doing it, how you were able to find those things easier on the physical device than you were with
[09:29.170 --> 09:35.690]  the emulated device? I'd like to hear more about that. Right. So, it's really common in embedded
[09:35.690 --> 09:43.990]  devices that they usually separate the web server and the logic to different binaries. And usually
[09:43.990 --> 09:51.510]  they find this way to communicate with each other. It's very popular to use Unix domain
[09:51.510 --> 10:00.290]  socket. And this is exactly the case in Ruckus. So, eventually, the web server just talks with
[10:00.290 --> 10:06.570]  other services, with other binaries, with domain sockets. And at first, when I was emulating the
[10:07.290 --> 10:13.150]  device itself, I was emulating only a single socket to the logic itself. And that's about it.
[10:13.150 --> 10:24.190]  But when I had the physical device, just by running a simple PS on the device, I could see
[10:24.190 --> 10:34.170]  all the other binaries that I had to trigger and all the domain sockets they had to use to get
[10:34.170 --> 10:41.490]  everything work together. So, yeah, that really, really helped a lot with the other research.
[10:41.490 --> 10:46.770]  That's probably a good thing for a lot of folks who are getting into this field to have some
[10:46.770 --> 10:52.510]  understanding of is you can do a lot from emulation, but there does come a point where
[10:53.090 --> 10:57.350]  having the physical device is going to be a benefit to you.
[10:57.830 --> 11:05.850]  Right. I agree. I think that... well, if you put enough effort, I tend to think that you can get
[11:06.630 --> 11:13.050]  most of the things done by emulation. Depends, user space, of course, but you can even emulate
[11:13.050 --> 11:19.350]  like the kernel and Ruckus actually gives you the config file for the kernel itself. So,
[11:19.350 --> 11:24.570]  theoretically, you can just compile yourself the Ruckus kernel, exact kernel, and run drivers and
[11:24.570 --> 11:33.630]  everything. But, yeah, there's this... when having a physical device really, really speeds things up.
[11:34.230 --> 11:40.830]  Things that you need to spend some time and understand how to emulate, you just don't need
[11:41.410 --> 11:52.050]  to do it. So, it really helps. Very cool. Once you found out that Ruckus had tried to fix
[11:52.710 --> 11:57.970]  one of the vulnerabilities, how did you then figure out that they didn't fix it properly?
[11:58.910 --> 12:10.570]  Okay. So, well, that was kind of a hunch, because... so, my first research, I found several
[12:10.570 --> 12:22.650]  bugs. And I... so, when I got the fix, I was going through them. But I realized that the function
[12:22.650 --> 12:28.210]  they're using to validate the... actually, everything that they are validating, all the
[12:28.210 --> 12:37.030]  inputs from the user are... well, let's say it's not like airtight. It's not... they got some bad
[12:37.030 --> 12:45.130]  practices there. And hopefully, I was managed to find these three primitives, which were the
[12:45.130 --> 12:52.430]  new line, the shabang, and slash. And thankfully, with those primitives, I was able to
[12:53.390 --> 13:01.390]  understand that this validation function is not doing a good enough job. And that's how I got the
[13:02.190 --> 13:06.210]  injection again, to get the command injection back to work.
[13:06.210 --> 13:12.790]  So, from the perspective of a bug hunter doing this work, would you, in the future,
[13:12.790 --> 13:21.830]  change the way you wrote your bug report and sent that in to help the team come up with more of
[13:22.450 --> 13:29.750]  these... to fix more of the... to fix more of your avenue in? Or would you do it the same way in the
[13:29.750 --> 13:35.510]  future? You give them the... this is the area that I hit. And how would you structure that in the
[13:35.510 --> 13:42.290]  future, knowing what you know now? Right. So, I think that... well, I did not know that they're
[13:42.290 --> 13:47.990]  using this... so, apparently, this validator function was been there the entire time, even
[13:47.990 --> 13:54.790]  before my research. It was using this bad validation function, like, since the beginning of
[13:54.790 --> 14:00.870]  the first research. I would... if I would knew that they're going to use this function, and actually,
[14:00.870 --> 14:06.150]  I did not knew this function even exists, but if I knew that they're going to use it, I would
[14:06.150 --> 14:16.190]  definitely tell them to use a different function with a more robust white list or black list,
[14:16.190 --> 14:23.850]  to be exact. Do you think any of those vulnerabilities, like that function that
[14:23.850 --> 14:28.410]  you were just talking about, do you think that is present in other similar devices
[14:29.510 --> 14:35.670]  that are out there? Or do you think that was kind of a custom rolled thing from Ruckus that it's
[14:35.670 --> 14:45.290]  going to be a one and done kind of deal? Yeah, so, I think by the name of the functions, because
[14:45.850 --> 14:52.410]  a lot of, as I said before, a lot of information I managed to extract from the debug functions and
[14:52.410 --> 15:00.030]  debug logs in Ruckus, and because a lot of them are Ruckus related, I think that's only Ruckus
[15:00.030 --> 15:08.930]  code base. I don't think that other vendors are using this code, but what I did realize,
[15:08.930 --> 15:14.790]  and I already mentioned it in the research, I did realize that they're using this code base for
[15:15.390 --> 15:21.590]  for more than one product line. So, for both of the product line, also the Wi-Fi controller, as well
[15:21.590 --> 15:28.510]  at the access point, they all use the same code base, and that's why they were vulnerable to...
[15:29.070 --> 15:31.810]  both of them were vulnerable to some of the attacks.
[15:33.790 --> 15:39.630]  I like this. Hawkeye Dank has the question. Did you find a way to brick the Ruckus?
[15:40.430 --> 15:48.830]  Brick? No, actually. So, at first, yeah, while doing emulation, it wasn't even in my mind.
[15:48.830 --> 15:53.950]  But, of course, when I bought an actual device, I bought two, of course, because I already broke
[15:53.950 --> 16:04.410]  some devices back in the time. So, I don't think, because I was dealing with user space
[16:04.410 --> 16:14.330]  and nothing that was too deep in the internals of the device, I did not manage to
[16:14.330 --> 16:22.290]  brick it. Although that, well, it was for another research, but I realized that if you write echo,
[16:22.690 --> 16:32.290]  any echo, right, the A character to slash dev slash asterisks, usually the device gets
[16:32.830 --> 16:39.050]  bricked. That happened to me before. I don't even know why I did that, but I just, I think it was
[16:39.050 --> 16:47.070]  like a last resort. I was like, okay, nothing works. Let's try to echo to the entire dev,
[16:47.070 --> 16:49.790]  and that worked poorly.
[16:51.290 --> 16:53.170]  That's good to know.
[16:53.770 --> 17:02.230]  Yeah. So, yeah, no rm slash, rm minus rf slash, and no slash dev asterisks.
[17:03.450 --> 17:07.070]  I'll keep that in mind the next time I'm hunting around in these things.
[17:07.070 --> 17:14.910]  So, in the stack overflow, did you have to use any sort of brute force to overcome the ASLR?
[17:15.630 --> 17:26.950]  Yes. So, well, so this stack overflow, I was lucky enough to just base it, so the same
[17:26.950 --> 17:34.610]  payload for my first stack overflow, although they were in different binaries, the library
[17:34.610 --> 17:43.430]  that I was using to create the rope chains were both in libc. So, I only had to fix the addresses,
[17:43.430 --> 17:50.610]  and basically I used the same gadgets. But the thing is, so in my first stack overflow,
[17:50.610 --> 17:59.610]  back in my first research, I was trying to deal with the ASLR in a non-brute force way,
[18:00.810 --> 18:07.550]  yeah, just to not to, you know, to create something a bit more robust. And I just decided
[18:07.550 --> 18:13.770]  after I found the command injection, I just decided to ditch it, because, you know, there's
[18:13.770 --> 18:21.970]  already an easier exploit for it. So, let's just see, like, let's do a POC for the stack overflow.
[18:24.910 --> 18:32.190]  And on, okay, so with this research, I realized that because this is a different binary,
[18:32.190 --> 18:41.370]  this is the web server binary, which is way more bigger than the ZAP binary from my first research.
[18:41.630 --> 18:49.870]  So, I think I can overcome the ASLR not by doing brute force, maybe just, you know,
[18:49.870 --> 18:56.590]  take something from the binary itself and use it. But again, because I already, because I found
[18:56.590 --> 19:03.130]  and command injection as well, so I just decided to stick with the most basic POC, because the
[19:03.130 --> 19:08.670]  command injection, in my opinion, is way more, it's not way more critical, but it's just different.
[19:08.670 --> 19:19.590]  It's easier to exploit. You're talking about the web server. Can you talk more about the
[19:19.590 --> 19:31.110]  web server correlation with the binary? Yeah. So, as I said, as I mentioned before, so the web
[19:31.110 --> 19:37.790]  server is, and it's super common for embedded devices, it just communicates with different
[19:37.790 --> 19:45.930]  processes, with different binaries. And one in particular was this, like, the device logic
[19:45.930 --> 19:56.030]  called EMFD. So, this binary is the one that actually executes the commands and just do,
[19:56.030 --> 20:02.310]  like, network configuration and just about everything. And the interesting part about
[20:04.490 --> 20:11.770]  this binary is that Ruckus, so they, Ruckus were using this embedded JavaScript
[20:12.830 --> 20:17.990]  developed, I think, by EmbedDisk. I'm not sure if this is theirs, but I think, so they work
[20:17.990 --> 20:27.450]  together. EmbedDisk, which is the web server, supports the embedded JavaScript, E-M-E-G-S.
[20:27.910 --> 20:37.030]  And so this back server, or back-end JavaScript, that was the one that, this is the language they
[20:37.030 --> 20:46.210]  use to trigger different functions that would be sent to different binaries. So, I get into it in
[20:46.210 --> 20:54.210]  the first, in my first talk, but also in my second, that, so they added a code to trigger these
[20:56.310 --> 21:05.810]  functions that were using the domain socket that I talked about to just pass commands to different
[21:05.810 --> 21:09.650]  binaries. And some of them were vulnerable.
[21:12.960 --> 21:17.340]  Hawkeye Dank does ask the question here, he's talking about you found cross-site scripting
[21:17.340 --> 21:21.180]  and some other exploits, which looks like he's specifically wondering about
[21:21.180 --> 21:24.160]  Csurf vulnerabilities. Did you find any Csurf in there?
[21:25.440 --> 21:35.640]  No, actually, so the entire Csurf token in, I didn't pay too much attention to it,
[21:35.640 --> 21:44.180]  because, so in one of the pages, or in some of the pages in Ruckus, in the embedded JavaScript
[21:44.180 --> 21:54.560]  language that I mentioned before, some of them were expecting a Csurf token, but the thing is that
[21:55.360 --> 22:04.380]  some of them looks to be like hard-coded there, so probably I can just overcome this token,
[22:04.380 --> 22:14.800]  but I did not pay too much attention for it, I must honestly say. Yeah, and the XSS vulnerability
[22:14.800 --> 22:22.560]  as well, it was just out there. For every request you send, you just get the reflected, you know,
[22:22.560 --> 22:28.640]  reflection for what you sent. So I'm like, okay, there's an XSS here, I gotta tell them.
[22:29.520 --> 22:34.160]  You can't not report that one when it, you didn't, sounds like you didn't really try, it just
[22:34.160 --> 22:41.600]  came back to you. That's true. So, and that's actually an interesting idea of how you are
[22:41.600 --> 22:46.540]  approaching this, so if there are some vulnerabilities that just show up without
[22:46.540 --> 22:55.440]  you having to really hunt for them, when you are reporting that, do you ever leave commentary
[22:55.440 --> 23:00.820]  around, hey, so I found this one, I wasn't really looking for it, I didn't really hunt down in this
[23:00.820 --> 23:07.840]  direction, or is this something that you're leaving open for future research for yourself,
[23:07.840 --> 23:14.760]  or would you tell anybody else in the community, oh hey, there's probably some findings here if you
[23:14.760 --> 23:23.360]  want to aim in this quadrant. Right, that's a good question. So no, I don't leave anything,
[23:23.360 --> 23:30.620]  I try not to leave anything open, I just, you know, try to report everything that I, you know,
[23:30.620 --> 23:37.660]  managed to found, even things that are not necessarily a full exploit, I would still
[23:37.660 --> 23:45.160]  let them know. A good example for it is the information leakage. I also noticed that there's
[23:45.160 --> 23:52.020]  this page, that you just go to this page, upnp.jsp, and you get just everything about the device,
[23:52.020 --> 23:58.060]  and I'm like, okay, this is a bad practice, it can lead to a jailbreak, and you guys should fix it.
[23:58.100 --> 24:05.480]  So no, I'm not, I think that the responsible thing to do is just to tell them, you know,
[24:05.480 --> 24:11.920]  to report everything that you find. But that being said, I must honestly say that the XSS,
[24:11.920 --> 24:16.800]  I only reported on this report, and not on my previous report, because as I said, it was really
[24:16.800 --> 24:22.540]  obvious. But I just, you know, I just, I don't know if I forget, I forgot about it, but I just,
[24:22.540 --> 24:30.180]  on this round, I just said, okay, I have to report it. Very good. Well, we're kind of
[24:30.180 --> 24:36.220]  coming to the end of the Q&A session. And one thing that Falvo and I like to do is kind of
[24:36.220 --> 24:41.420]  give you an opportunity to talk to the community about what's next, right? What's next in this
[24:41.420 --> 24:45.720]  kind of vein of research? Where are you going to be taking this kind of thing next? And where do
[24:45.720 --> 24:51.680]  you think that other people that are interested in the in the same kind of thing, how can they,
[24:51.680 --> 24:55.080]  how can they take what you've done and then run with it in other directions?
[24:56.140 --> 25:05.680]  All right. So, I think so. In our group, there are a lot of going on. We do all different sorts
[25:05.680 --> 25:14.140]  of research projects. And I think I already got another research that I just started. It's not
[25:14.140 --> 25:20.480]  going to be embedded devices, because I just want to experience with something else. Probably
[25:20.480 --> 25:32.500]  going to be around a bit fuzzing. And that's it for now. But except for that, so, in my group,
[25:32.500 --> 25:41.100]  we are also doing a very impressive research on iOS simulation, which is a really, really
[25:41.100 --> 25:50.740]  cool project that I might also take some part of it. Or in general, I think, so, as I already said,
[25:50.740 --> 26:00.360]  emulation in general, I think it's a really good thing to have in your arsenal as a researcher.
[26:01.800 --> 26:08.520]  So, yeah. So, probably some more emulation for sure. And then my next research, I think,
[26:08.520 --> 26:14.960]  is going to be, I hope, is going to be on something else with brand new vulnerabilities.
[26:17.540 --> 26:22.660]  There's a lot of exciting stuff to look forward to, then. Thank you very much. That's cool.
[26:22.940 --> 26:30.620]  Thank you, guys. Yeah. Thanks a lot. And thank you, everybody, for coming out for the Q&A session.
[26:30.900 --> 26:36.460]  And we will see you guys later on. Congratulations again on a great talk.
[26:36.460 --> 26:40.900]  And happy anniversary. Thank you very much, guys.
[26:41.900 --> 26:45.120]  All right. We'll talk to you guys soon. Okay. Bye now.