WEBVTT 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:33.950 Welcome to Q&A with Gals Aurore. 00:33.950 --> 00:37.230 We have a little bit of business to take care of first. 00:37.230 --> 00:41.670 This is Gals' first time speaking and presenting at DEF CON. 00:41.870 --> 00:47.290 And not only that, it's also, his wedding anniversary. 00:47.850 --> 00:53.350 And his wedding occurred actually in Las Vegas. 00:53.350 --> 00:56.890 So, unfortunately, as you guys know, we are all stuck at home. 00:57.590 --> 01:05.530 So, we're not ones to let the Rona get in the way of staying fairly well lubricated. 01:05.530 --> 01:10.110 So, to everybody playing the home version of DEF CON. 01:11.170 --> 01:15.670 We have shots here. 01:16.070 --> 01:18.230 There we go. 01:18.230 --> 01:18.810 All right. 01:18.810 --> 01:19.770 So, Gal, here's to you. 01:19.770 --> 01:22.090 Congratulations on making a stage. 01:22.170 --> 01:28.050 Congratulations to your bride on surviving here with a hacker who made it through DEF CON. 01:28.050 --> 01:29.370 So, here's to you. 01:29.710 --> 01:30.910 Cheers. 01:31.170 --> 01:32.530 I'll drink to that. 01:36.410 --> 01:37.750 All right. 01:38.490 --> 01:40.150 Not a bad way to start. 01:40.150 --> 01:40.730 Okay. 01:40.730 --> 01:42.070 I'm glad we did that. 01:42.630 --> 01:43.010 Okay. 01:43.010 --> 01:47.090 So, welcome to Q&A with Gals Aurore. 01:47.090 --> 01:59.010 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. 01:59.010 --> 01:59.610 All right. 02:00.430 --> 02:04.670 So, Gal, why don't you introduce yourself a little bit. 02:04.670 --> 02:09.290 Tell us about yourself in case some folks may be glazed over that part of your presentation. 02:09.410 --> 02:13.050 And we'll start queuing up some of these questions from the audience. 02:13.870 --> 02:14.910 Sure. 02:14.950 --> 02:24.130 So, I work for Adaf Research, which is a part of HCL AppScan. 02:24.130 --> 02:32.470 And I've been doing reverse engineering for something like 10, 11 years. 02:33.290 --> 02:36.590 Especially embedded devices. 02:36.590 --> 02:44.270 This is a subject that I was exploring for a while. 02:44.270 --> 03:05.030 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. 03:05.030 --> 03:07.270 So, this is what started everything. 03:07.910 --> 03:08.950 Yeah. 03:10.210 --> 03:13.750 You saw them in the wild, like, oh, nope, I gotta do that. 03:13.750 --> 03:14.510 Right, right. 03:14.510 --> 03:21.650 I've heard about them, but I never really had the opportunity to really do a full research. 03:21.990 --> 03:26.430 And yeah, so it turns out to be two research. 03:26.430 --> 03:33.070 One was presented half a year ago in Leipzig, in CCC. 03:33.250 --> 03:48.150 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. 03:50.690 --> 03:51.870 Well, very good. 03:51.870 --> 03:56.770 So, you found a number of different problems and kind of triggered them to take some action on their part. 03:56.770 --> 04:09.670 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? 04:10.010 --> 04:10.690 Right. 04:10.690 --> 04:16.830 So, as far as I know, Ruckus avoids automatic update. 04:16.830 --> 04:37.270 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. 04:37.290 --> 04:41.650 So, I get why they don't push their updates. 04:41.650 --> 05:03.250 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. 05:03.510 --> 05:12.890 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? 05:13.690 --> 05:13.950 Yeah. 05:13.950 --> 05:28.070 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. 05:28.070 --> 05:35.330 And with Ruckus, both the first research and this follow-up research, we gave them enough time. 05:35.330 --> 05:38.270 Eventually, it was a bit more than 90 days. 05:38.270 --> 05:41.350 It was around 100 and so days. 05:41.430 --> 05:46.150 And we just sent them a report with all the things we found. 05:46.150 --> 05:52.650 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:08.180 It's one of the interesting things to have the conversation with folks about how did your disclosure go? 06:08.180 --> 06:12.780 How did that conversation go with the developers and with the people on that team? 06:12.780 --> 06:19.660 Because there's a lot that you can learn about a company by how that relationship evolves. 06:19.660 --> 06:23.360 So, it's nice to get that data point. 06:23.380 --> 06:24.000 Right. 06:24.000 --> 06:29.780 If I may add something, if we are talking about a disclosure, I think one thing... 06:29.780 --> 06:53.480 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. 06:54.400 --> 07:01.520 So, yes, when I sent them the report, it was with the right function names and the right architecture. 07:01.520 --> 07:04.380 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:17.380 Yeah, no, that's good. 07:17.380 --> 07:24.220 Well, that goes pretty well with this question about how does owning the device help you with the research that you did? 07:24.620 --> 07:25.400 Oh, yeah. 07:25.400 --> 07:32.840 So, well, yes, my first research was done on emulation, 100% based on emulation. 07:32.840 --> 07:47.020 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. 07:47.020 --> 07:54.200 So, I managed to get the web interface up and running, which included different binaries. 07:54.200 --> 08:04.600 But I think when I got the actual device, when I bought it, so I bought it for live demos and stuff. 08:04.720 --> 08:27.840 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, 08:27.840 --> 08:33.140 depends on how the vendor is deploying the firmware. 08:33.280 --> 08:40.720 And, yeah, and when I got the device itself, it really helped me to override the admin credentials. 08:40.720 --> 08:46.920 So, one of the vulnerabilities I demonstrated is admin override. 08:46.960 --> 09:00.170 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. 09:00.210 --> 09:04.990 And this is how I realized those are the configuration files that are important. 09:04.990 --> 09:12.430 And if I manage to override one of them, well, specifically the sys.xml, I would win. 09:12.430 --> 09:14.170 And thankfully, it happened. 09:14.390 --> 09:18.910 Well, so you're definitely not afraid of diving into the technical stuff here. 09:18.910 --> 09:30.290 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? 09:30.290 --> 09:31.770 I'd like to hear more about that. 09:31.770 --> 09:32.370 Right. 09:32.590 --> 09:43.630 So, it's really common in embedded devices that they usually separate the web server and the logic to different binaries. 09:43.630 --> 09:47.870 And usually they find this way to communicate with each other. 09:47.870 --> 09:52.190 It's very popular to use Unix domain socket. 09:52.190 --> 09:54.870 And this is exactly the case in Ruckus. 09:55.290 --> 10:04.270 So, eventually, the web server just talks with other services, with other binaries, with domain sockets. 10:04.290 --> 10:11.970 And at first, when I was emulating the device itself, I was emulating only a single socket to the logic itself. 10:11.970 --> 10:13.150 And that's about it. 10:13.150 --> 10:36.190 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. 10:36.190 --> 10:41.490 So, yeah, that really, really helped a lot with the other research. 10:41.490 --> 10:57.350 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. 10:57.830 --> 10:58.510 Right. 10:58.510 --> 10:59.530 I agree. 10:59.530 --> 11:09.470 I think that... well, if you put enough effort, I tend to think that you can get most of the things done by emulation. 11:09.470 --> 11:18.770 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. 11:18.770 --> 11:25.590 So, theoretically, you can just compile yourself the Ruckus kernel, exact kernel, and run drivers and everything. 11:26.090 --> 11:33.630 But, yeah, there's this... when having a physical device really, really speeds things up. 11:34.230 --> 11:42.250 Things that you need to spend some time and understand how to emulate, you just don't need to do it. 11:42.250 --> 11:44.810 So, it really helps. 11:45.070 --> 11:46.510 Very cool. 11:46.690 --> 11:57.970 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? 11:58.910 --> 12:00.290 Okay. 12:00.530 --> 12:11.710 So, well, that was kind of a hunch, because... so, my first research, I found several bugs. 12:12.650 --> 12:18.490 And I... so, when I got the fix, I was going through them. 12:19.010 --> 12:34.230 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. 12:34.230 --> 12:38.990 It's not... they got some bad practices there. 12:39.410 --> 12:48.890 And hopefully, I was managed to find these three primitives, which were the new line, the shabang, and slash. 12:48.890 --> 13:00.030 And thankfully, with those primitives, I was able to understand that this validation function is not doing a good enough job. 13:00.030 --> 13:06.210 And that's how I got the injection again, to get the command injection back to work. 13:06.210 --> 13:27.690 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? 13:27.690 --> 13:30.250 Or would you do it the same way in the future? 13:30.250 --> 13:33.370 You give them the... this is the area that I hit. 13:33.370 --> 13:37.370 And how would you structure that in the future, knowing what you know now? 13:37.410 --> 13:37.970 Right. 13:38.130 --> 13:49.330 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. 13:49.330 --> 13:56.090 It was using this bad validation function, like, since the beginning of the first research. 13:56.170 --> 14:16.190 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, 14:16.190 --> 14:17.850 to be exact. 14:19.330 --> 14:31.430 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? 14:31.430 --> 14:37.870 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? 14:39.730 --> 15:00.630 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. 15:00.630 --> 15:17.830 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. 15:17.830 --> 15:28.510 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... 15:29.070 --> 15:31.810 both of them were vulnerable to some of the attacks. 15:33.790 --> 15:34.790 I like this. 15:34.790 --> 15:36.450 Hawkeye Dank has the question. 15:36.450 --> 15:39.630 Did you find a way to brick the Ruckus? 15:40.430 --> 15:41.410 Brick? 15:42.110 --> 15:43.290 No, actually. 15:43.290 --> 15:48.830 So, at first, yeah, while doing emulation, it wasn't even in my mind. 15:48.830 --> 15:58.990 But, of course, when I bought an actual device, I bought two, of course, because I already broke some devices back in the time. 15:59.610 --> 16:15.530 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. 16:15.530 --> 16:33.870 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. 16:34.070 --> 16:35.790 That happened to me before. 16:35.790 --> 16:42.450 I don't even know why I did that, but I just, I think it was like a last resort. 16:42.450 --> 16:44.090 I was like, okay, nothing works. 16:44.090 --> 16:49.790 Let's try to echo to the entire dev, and that worked poorly. 16:51.290 --> 16:53.170 That's good to know. 16:53.770 --> 16:54.490 Yeah. 16:55.070 --> 17:02.230 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:16.410 Yes. 17:16.410 --> 17:40.890 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. 17:40.890 --> 17:46.230 So, I only had to fix the addresses, and basically I used the same gadgets. 17:46.930 --> 18:05.630 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. 18:05.850 --> 18:16.910 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. 18:16.910 --> 18:21.970 So, let's just see, like, let's do a POC for the stack overflow. 18:24.910 --> 18:41.370 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. 18:41.630 --> 18:52.550 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. 18:52.550 --> 19:08.670 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. 19:08.670 --> 19:10.190 It's easier to exploit. 19:16.010 --> 19:17.650 You're talking about the web server. 19:17.650 --> 19:23.910 Can you talk more about the web server correlation with the binary? 19:24.890 --> 19:25.970 Yeah. 19:26.890 --> 19:40.510 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. 19:40.590 --> 19:47.690 And one in particular was this, like, the device logic called EMFD. 19:47.690 --> 19:59.950 So, this binary is the one that actually executes the commands and just do, like, network configuration and just about everything. 19:59.950 --> 20:15.070 And the interesting part about this binary is that Ruckus, so they, Ruckus were using this embedded JavaScript developed, I think, by EmbedDisk. 20:15.070 --> 20:18.470 I'm not sure if this is theirs, but I think, so they work together. 20:18.470 --> 20:27.450 EmbedDisk, which is the web server, supports the embedded JavaScript, E-M-E-G-S. 20:27.910 --> 20:43.910 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. 20:43.910 --> 21:07.090 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. 21:07.090 --> 21:09.650 And some of them were vulnerable. 21:12.960 --> 21:22.640 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. 21:22.640 --> 21:24.160 Did you find any Csurf in there? 21:25.440 --> 21:53.560 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, 21:53.560 --> 22:10.660 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. 22:11.320 --> 22:17.540 Yeah, and the XSS vulnerability as well, it was just out there. 22:17.540 --> 22:23.980 For every request you send, you just get the reflected, you know, reflection for what you sent. 22:23.980 --> 22:28.640 So I'm like, okay, there's an XSS here, I gotta tell them. 22:29.520 --> 22:35.460 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. 22:36.380 --> 22:37.500 That's true. 22:37.560 --> 22:57.800 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, 22:57.800 --> 23:17.120 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. 23:17.400 --> 23:20.520 Right, that's a good question. 23:20.520 --> 23:40.240 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. 23:40.540 --> 23:43.080 A good example for it is the information leakage. 23:43.080 --> 23:58.060 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. 23:58.100 --> 24:07.620 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. 24:07.720 --> 24:17.520 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. 24:17.720 --> 24:27.220 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. 24:28.660 --> 24:29.320 Very good. 24:29.320 --> 24:33.400 Well, we're kind of coming to the end of the Q&A session. 24:33.400 --> 24:40.180 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? 24:40.480 --> 24:42.640 What's next in this kind of vein of research? 24:42.780 --> 24:45.120 Where are you going to be taking this kind of thing next? 24:45.120 --> 24:55.080 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? 24:56.140 --> 24:57.120 All right. 24:57.360 --> 25:00.700 So, I think so. 25:00.700 --> 25:03.400 In our group, there are a lot of going on. 25:03.400 --> 25:08.440 We do all different sorts of research projects. 25:08.660 --> 25:13.220 And I think I already got another research that I just started. 25:13.220 --> 25:19.760 It's not going to be embedded devices, because I just want to experience with something else. 25:19.820 --> 25:23.820 Probably going to be around a bit fuzzing. 25:24.320 --> 25:28.040 And that's it for now. 25:28.400 --> 25:46.200 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. 25:46.200 --> 26:00.360 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. 26:01.800 --> 26:02.540 So, yeah. 26:02.540 --> 26:06.080 So, probably some more emulation for sure. 26:06.080 --> 26:14.960 And then my next research, I think, is going to be, I hope, is going to be on something else with brand new vulnerabilities. 26:17.540 --> 26:20.420 There's a lot of exciting stuff to look forward to, then. 26:20.480 --> 26:21.800 Thank you very much. 26:21.800 --> 26:22.660 That's cool. 26:22.940 --> 26:23.980 Thank you, guys. 26:24.200 --> 26:24.620 Yeah. 26:24.620 --> 26:25.380 Thanks a lot. 26:25.380 --> 26:30.620 And thank you, everybody, for coming out for the Q&A session. 26:30.900 --> 26:33.700 And we will see you guys later on. 26:33.700 --> 26:36.460 Congratulations again on a great talk. 26:36.460 --> 26:38.960 And happy anniversary. 26:39.360 --> 26:40.900 Thank you very much, guys. 26:41.900 --> 26:42.400 All right. 26:42.400 --> 26:43.580 We'll talk to you guys soon. 26:44.120 --> 26:44.720 Okay. 26:44.720 --> 26:45.120 Bye now.