start	end	text
20070	29030	Okay, well, good morning, or good evening, or good afternoon, wherever you are right now.
29470	37230	Welcome to Q&A with Gals Aurore. We have a little bit of business to take care of first.
37230	44630	This is Gals' first time speaking and presenting at DEF CON. And not only that, it's also,
44630	54070	his wedding anniversary. And his wedding occurred actually in Las Vegas. So,
54070	60520	unfortunately, as you guys know, we are all stuck at home. So, we're not ones to let
61330	67710	the Rona get in the way of staying fairly well lubricated. So, to everybody playing the home
67710	79770	version of DEF CON. We have shots here. There we go. All right. So, Gal, here's to you.
79770	86510	Congratulations on making a stage. Congratulations to your bride on surviving here with a hacker
86510	92530	who made it through DEF CON. So, here's to you. Cheers. I'll drink to that.
96410	102070	All right. Not a bad way to start. Okay. I'm glad we did that.
102630	111710	Okay. So, welcome to Q&A with Gals Aurore. Gal gave a fantastic presentation on Ruckus wireless
111710	119010	gear and some of the problems that seem to be resonant in that over and over and over again.
119010	125930	All right. So, Gal, why don't you introduce yourself a little bit. Tell us about yourself
125930	130390	in case some folks may be glazed over that part of your presentation. And we'll start
130390	139690	queuing up some of these questions from the audience. Sure. So, I work for Adaf Research,
139690	150670	which is a part of HCL AppScan. And I've been doing reverse engineering for something like 10,
150670	164270	11 years. Especially embedded devices. This is a subject that I was exploring for a while.
164270	171070	And actually, something that I did not say in my talk, I talked about it in the previous talk,
171070	180750	was that the inspiration for this research was because last year I visited DefCon and BlackHat,
180750	187270	and I noticed that BlackHat are using this gear. So, this is what started everything.
187910	195250	Yeah. You saw them in the wild, like, oh, nope, I gotta do that. Right, right. I've heard about
195250	203430	them, but I never really had the opportunity to really do a full research. And yeah, so it turns
203430	214510	out to be two research. One was presented half a year ago in Leipzig, in CCC. And this one,
214510	220970	is the follow-up research that I managed to find additional vulnerabilities and some
222430	228150	fixes that did not fix the vulnerabilities I already found.
230690	234510	Well, very good. So, you found a number of different problems and kind of triggered them
234510	240370	to take some action on their part. Do you know, does Ruckus actually patch any of their gear
240370	244150	automatically, such that, you know, what you found and what they did
244150	249670	fix or try to fix, did that get pushed out to all the gear worldwide?
250010	260030	Right. So, as far as I know, Ruckus avoids automatic update. I understand where it comes
260030	268330	from because, you know, pushing an automatic update through the air on network gear might
268330	277270	sometimes mess configuration and do some things that you don't necessarily want to happen.
277290	286970	So, I get why they don't push their updates. But yeah, so the thing I think is the most
286970	295830	important from my talks is Ruckus users should stay up to date, you know, even now, even after
295830	302270	this, even before my previous research and on this research as well, they need to keep everything
302270	308030	up to date. So, there's a general question out then from Hawkeye Dank about how did Ruckus
308030	312890	respond to your research and what sort of a communication did you get back and forth with them?
313690	321310	Yeah. So, in my research group, I think like most of the research group, we try to
321590	329790	do a full disclosure, which is a 90-day disclosure. And with Ruckus, both the first
329790	337490	research and this follow-up research, we gave them enough time. Eventually, it was a bit more than
337490	345130	90 days. It was around 100 and so days. And we just sent them a report with all the
345130	352650	things we found. We just talked about it a bit and they fixed... well, they tried to fix everything.
354150	358470	So, all in all, the disclosure was pretty standard.
362420	366240	It's one of the interesting things to have the conversation with folks about
366240	371540	how did your disclosure go? How did that conversation go with the developers and
371540	376800	with the people on that team? Because there's a lot that you can learn about a company by
376880	383360	how that relationship evolves. So, it's nice to get that data point.
383380	389780	Right. If I may add something, if we are talking about a disclosure, I think one thing...
389780	397060	this is from my first research and not from this one... I think one thing that took Ruckus by, let's
397060	403540	say, a surprise was the fact that I managed to recover a lot of function names from their
403540	410160	binaries because they left a lot of debug information both in the debug logs and some
411220	418440	assertion in the code itself. So, yes, when I sent them the report, it was with the
418440	424380	right function names and the right architecture. So, I think it was a bit of a shock for them.
424380	435860	Well, it's a lesson that I bet they learned to try to not give free stuff for hackers.
436220	439580	Yeah, no, that's good. Well, that goes pretty well with this question about
439580	444220	how does owning the device help you with the research that you did?
444620	453200	Oh, yeah. So, well, yes, my first research was done on emulation, 100% based on emulation. I just
454520	462860	extracted the firmware from Ruckus, and then I managed to emulate most of the device itself,
462860	468980	which, well, all the vulnerabilities were found on the web interface. So, I managed to get the
468980	476940	web interface up and running, which included different binaries. But I think when I got the
476940	485920	actual device, when I bought it, so I bought it for live demos and stuff. And so, when I got the
485920	497460	device itself, I could debug and see different things that were more related to the configuration
497460	503620	of the device itself, because sometimes the device you get from the firmware, the device you emulate,
503620	511360	not necessarily has all the configuration or the binaries, depends on how the vendor is deploying
511360	519980	the firmware. And, yeah, and when I got the device itself, it really helped me to override the admin
519980	528050	credentials. So, one of the vulnerabilities I demonstrated is admin override. And I just,
528050	534470	by debugging just the binary itself on the device, I could see all the files it tried to,
534470	540170	which actually, it was with a simple asterisk, all the files he was opening and writing to.
540210	545270	And this is how I realized those are the configuration files that are important. And
545270	552550	if I manage to override one of them, well, specifically the sys.xml, I would win. And
552550	557330	thankfully, it happened. Well, so you're definitely not afraid of diving into the
557330	563750	technical stuff here. So, would you talk just a little bit more then about how that was different
563750	569170	doing it, how you were able to find those things easier on the physical device than you were with
569170	575690	the emulated device? I'd like to hear more about that. Right. So, it's really common in embedded
575690	583990	devices that they usually separate the web server and the logic to different binaries. And usually
583990	591510	they find this way to communicate with each other. It's very popular to use Unix domain
591510	600290	socket. And this is exactly the case in Ruckus. So, eventually, the web server just talks with
600290	606570	other services, with other binaries, with domain sockets. And at first, when I was emulating the
607290	613150	device itself, I was emulating only a single socket to the logic itself. And that's about it.
613150	624190	But when I had the physical device, just by running a simple PS on the device, I could see
624190	634170	all the other binaries that I had to trigger and all the domain sockets they had to use to get
634170	641490	everything work together. So, yeah, that really, really helped a lot with the other research.
641490	646770	That's probably a good thing for a lot of folks who are getting into this field to have some
646770	652510	understanding of is you can do a lot from emulation, but there does come a point where
653090	657350	having the physical device is going to be a benefit to you.
657830	665850	Right. I agree. I think that... well, if you put enough effort, I tend to think that you can get
666630	673050	most of the things done by emulation. Depends, user space, of course, but you can even emulate
673050	679350	like the kernel and Ruckus actually gives you the config file for the kernel itself. So,
679350	684570	theoretically, you can just compile yourself the Ruckus kernel, exact kernel, and run drivers and
684570	693630	everything. But, yeah, there's this... when having a physical device really, really speeds things up.
694230	700830	Things that you need to spend some time and understand how to emulate, you just don't need
701410	712050	to do it. So, it really helps. Very cool. Once you found out that Ruckus had tried to fix
712710	717970	one of the vulnerabilities, how did you then figure out that they didn't fix it properly?
718910	730570	Okay. So, well, that was kind of a hunch, because... so, my first research, I found several
730570	742650	bugs. And I... so, when I got the fix, I was going through them. But I realized that the function
742650	748210	they're using to validate the... actually, everything that they are validating, all the
748210	757030	inputs from the user are... well, let's say it's not like airtight. It's not... they got some bad
757030	765130	practices there. And hopefully, I was managed to find these three primitives, which were the
765130	772430	new line, the shabang, and slash. And thankfully, with those primitives, I was able to
773390	781390	understand that this validation function is not doing a good enough job. And that's how I got the
782190	786210	injection again, to get the command injection back to work.
786210	792790	So, from the perspective of a bug hunter doing this work, would you, in the future,
792790	801830	change the way you wrote your bug report and sent that in to help the team come up with more of
802450	809750	these... to fix more of the... to fix more of your avenue in? Or would you do it the same way in the
809750	815510	future? You give them the... this is the area that I hit. And how would you structure that in the
815510	822290	future, knowing what you know now? Right. So, I think that... well, I did not know that they're
822290	827990	using this... so, apparently, this validator function was been there the entire time, even
827990	834790	before my research. It was using this bad validation function, like, since the beginning of
834790	840870	the first research. I would... if I would knew that they're going to use this function, and actually,
840870	846150	I did not knew this function even exists, but if I knew that they're going to use it, I would
846150	856190	definitely tell them to use a different function with a more robust white list or black list,
856190	863850	to be exact. Do you think any of those vulnerabilities, like that function that
863850	868410	you were just talking about, do you think that is present in other similar devices
869510	875670	that are out there? Or do you think that was kind of a custom rolled thing from Ruckus that it's
875670	885290	going to be a one and done kind of deal? Yeah, so, I think by the name of the functions, because
885850	892410	a lot of, as I said before, a lot of information I managed to extract from the debug functions and
892410	900030	debug logs in Ruckus, and because a lot of them are Ruckus related, I think that's only Ruckus
900030	908930	code base. I don't think that other vendors are using this code, but what I did realize,
908930	914790	and I already mentioned it in the research, I did realize that they're using this code base for
915390	921590	for more than one product line. So, for both of the product line, also the Wi-Fi controller, as well
921590	928510	at the access point, they all use the same code base, and that's why they were vulnerable to...
929070	931810	both of them were vulnerable to some of the attacks.
933790	939630	I like this. Hawkeye Dank has the question. Did you find a way to brick the Ruckus?
940430	948830	Brick? No, actually. So, at first, yeah, while doing emulation, it wasn't even in my mind.
948830	953950	But, of course, when I bought an actual device, I bought two, of course, because I already broke
953950	964410	some devices back in the time. So, I don't think, because I was dealing with user space
964410	974330	and nothing that was too deep in the internals of the device, I did not manage to
974330	982290	brick it. Although that, well, it was for another research, but I realized that if you write echo,
982690	992290	any echo, right, the A character to slash dev slash asterisks, usually the device gets
992830	999050	bricked. That happened to me before. I don't even know why I did that, but I just, I think it was
999050	1007070	like a last resort. I was like, okay, nothing works. Let's try to echo to the entire dev,
1007070	1009790	and that worked poorly.
1011290	1013170	That's good to know.
1013770	1022230	Yeah. So, yeah, no rm slash, rm minus rf slash, and no slash dev asterisks.
1023450	1027070	I'll keep that in mind the next time I'm hunting around in these things.
1027070	1034910	So, in the stack overflow, did you have to use any sort of brute force to overcome the ASLR?
1035630	1046950	Yes. So, well, so this stack overflow, I was lucky enough to just base it, so the same
1046950	1054610	payload for my first stack overflow, although they were in different binaries, the library
1054610	1063430	that I was using to create the rope chains were both in libc. So, I only had to fix the addresses,
1063430	1070610	and basically I used the same gadgets. But the thing is, so in my first stack overflow,
1070610	1079610	back in my first research, I was trying to deal with the ASLR in a non-brute force way,
1080810	1087550	yeah, just to not to, you know, to create something a bit more robust. And I just decided
1087550	1093770	after I found the command injection, I just decided to ditch it, because, you know, there's
1093770	1101970	already an easier exploit for it. So, let's just see, like, let's do a POC for the stack overflow.
1104910	1112190	And on, okay, so with this research, I realized that because this is a different binary,
1112190	1121370	this is the web server binary, which is way more bigger than the ZAP binary from my first research.
1121630	1129870	So, I think I can overcome the ASLR not by doing brute force, maybe just, you know,
1129870	1136590	take something from the binary itself and use it. But again, because I already, because I found
1136590	1143130	and command injection as well, so I just decided to stick with the most basic POC, because the
1143130	1148670	command injection, in my opinion, is way more, it's not way more critical, but it's just different.
1148670	1159590	It's easier to exploit. You're talking about the web server. Can you talk more about the
1159590	1171110	web server correlation with the binary? Yeah. So, as I said, as I mentioned before, so the web
1171110	1177790	server is, and it's super common for embedded devices, it just communicates with different
1177790	1185930	processes, with different binaries. And one in particular was this, like, the device logic
1185930	1196030	called EMFD. So, this binary is the one that actually executes the commands and just do,
1196030	1202310	like, network configuration and just about everything. And the interesting part about
1204490	1211770	this binary is that Ruckus, so they, Ruckus were using this embedded JavaScript
1212830	1217990	developed, I think, by EmbedDisk. I'm not sure if this is theirs, but I think, so they work
1217990	1227450	together. EmbedDisk, which is the web server, supports the embedded JavaScript, E-M-E-G-S.
1227910	1237030	And so this back server, or back-end JavaScript, that was the one that, this is the language they
1237030	1246210	use to trigger different functions that would be sent to different binaries. So, I get into it in
1246210	1254210	the first, in my first talk, but also in my second, that, so they added a code to trigger these
1256310	1265810	functions that were using the domain socket that I talked about to just pass commands to different
1265810	1269650	binaries. And some of them were vulnerable.
1272960	1277340	Hawkeye Dank does ask the question here, he's talking about you found cross-site scripting
1277340	1281180	and some other exploits, which looks like he's specifically wondering about
1281180	1284160	Csurf vulnerabilities. Did you find any Csurf in there?
1285440	1295640	No, actually, so the entire Csurf token in, I didn't pay too much attention to it,
1295640	1304180	because, so in one of the pages, or in some of the pages in Ruckus, in the embedded JavaScript
1304180	1314560	language that I mentioned before, some of them were expecting a Csurf token, but the thing is that
1315360	1324380	some of them looks to be like hard-coded there, so probably I can just overcome this token,
1324380	1334800	but I did not pay too much attention for it, I must honestly say. Yeah, and the XSS vulnerability
1334800	1342560	as well, it was just out there. For every request you send, you just get the reflected, you know,
1342560	1348640	reflection for what you sent. So I'm like, okay, there's an XSS here, I gotta tell them.
1349520	1354160	You can't not report that one when it, you didn't, sounds like you didn't really try, it just
1354160	1361600	came back to you. That's true. So, and that's actually an interesting idea of how you are
1361600	1366540	approaching this, so if there are some vulnerabilities that just show up without
1366540	1375440	you having to really hunt for them, when you are reporting that, do you ever leave commentary
1375440	1380820	around, hey, so I found this one, I wasn't really looking for it, I didn't really hunt down in this
1380820	1387840	direction, or is this something that you're leaving open for future research for yourself,
1387840	1394760	or would you tell anybody else in the community, oh hey, there's probably some findings here if you
1394760	1403360	want to aim in this quadrant. Right, that's a good question. So no, I don't leave anything,
1403360	1410620	I try not to leave anything open, I just, you know, try to report everything that I, you know,
1410620	1417660	managed to found, even things that are not necessarily a full exploit, I would still
1417660	1425160	let them know. A good example for it is the information leakage. I also noticed that there's
1425160	1432020	this page, that you just go to this page, upnp.jsp, and you get just everything about the device,
1432020	1438060	and I'm like, okay, this is a bad practice, it can lead to a jailbreak, and you guys should fix it.
1438100	1445480	So no, I'm not, I think that the responsible thing to do is just to tell them, you know,
1445480	1451920	to report everything that you find. But that being said, I must honestly say that the XSS,
1451920	1456800	I only reported on this report, and not on my previous report, because as I said, it was really
1456800	1462540	obvious. But I just, you know, I just, I don't know if I forget, I forgot about it, but I just,
1462540	1470180	on this round, I just said, okay, I have to report it. Very good. Well, we're kind of
1470180	1476220	coming to the end of the Q&A session. And one thing that Falvo and I like to do is kind of
1476220	1481420	give you an opportunity to talk to the community about what's next, right? What's next in this
1481420	1485720	kind of vein of research? Where are you going to be taking this kind of thing next? And where do
1485720	1491680	you think that other people that are interested in the in the same kind of thing, how can they,
1491680	1495080	how can they take what you've done and then run with it in other directions?
1496140	1505680	All right. So, I think so. In our group, there are a lot of going on. We do all different sorts
1505680	1514140	of research projects. And I think I already got another research that I just started. It's not
1514140	1520480	going to be embedded devices, because I just want to experience with something else. Probably
1520480	1532500	going to be around a bit fuzzing. And that's it for now. But except for that, so, in my group,
1532500	1541100	we are also doing a very impressive research on iOS simulation, which is a really, really
1541100	1550740	cool project that I might also take some part of it. Or in general, I think, so, as I already said,
1550740	1560360	emulation in general, I think it's a really good thing to have in your arsenal as a researcher.
1561800	1568520	So, yeah. So, probably some more emulation for sure. And then my next research, I think,
1568520	1574960	is going to be, I hope, is going to be on something else with brand new vulnerabilities.
1577540	1582660	There's a lot of exciting stuff to look forward to, then. Thank you very much. That's cool.
1582940	1590620	Thank you, guys. Yeah. Thanks a lot. And thank you, everybody, for coming out for the Q&A session.
1590900	1596460	And we will see you guys later on. Congratulations again on a great talk.
1596460	1600900	And happy anniversary. Thank you very much, guys.
1601900	1605120	All right. We'll talk to you guys soon. Okay. Bye now.