 Okay, well good morning or good evening or good afternoon wherever you you are right now. Welcome to Q&A with a gals roar. 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 I understand his his wedding anniversary right and and his and his wedding occurred actually in Las Vegas so personally as you guys know we are all stuck at home so we're not we're not ones to let let let the Rona get in the way of staying fairly well lubricated so to everybody playing the the home version of DEF CON tradition we have we have shots here there we go all right congratulations on making the stage with my wife congratulations to your bride I'm so glad to be here with it with a hacker who made it through DEF CON so not a bad way to start okay I'm okay so welcome to Q&A with gals roar gal gave a fantastic presentation on wreckus wireless gear and some of the problems that seem to be resonant in that over and over and over again right so gal why don't you introduce yourself a little bit tell us tell us about yourself in case some folks maybe glaze over that part of your presentation and we'll start Q&A some of these questions from the from the audience sure so I work for other research which is a part of HCL and I've been I've been doing reverse engineering for something like 10 11 years especially in better devices this is the subject that I was you know 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 DEF CON and blackhead and I noticed that blackhead are using this year so this is what started everything yeah you saw I'm in the wild like oh no I got to do that right right I've heard about them but I never really had opportunity to really do a full research and and yeah so it turns out to be two to research one was presented half a year ago in lighting in triple C and this one which is the follow-up research that I managed to find additional vulnerabilities and some some fixes that did not fix the the vulnerabilities I already found 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 it does ruckus actually patch any of their gear automatically such that you know what you found or what they did fix or try to fix did that get pushed out to all that all the gear worldwide right so as far as I know ruckus avoid automatic update I I understand where it comes from because you know pushing and automatic updates through the air on network gear might sometimes mess configuration and and do something that you don't necessarily want to happen so I get I get why they don't push their updates but but yeah so I the thing I I think is the most important from my talks is ruckus users should stay up to date you know even even now even after this I even my 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 him yeah so in my research group we I think like most of the 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 100 and so days and we just send them a report with all the things we found we just talked about it a bit and they fixed well they they they try to fix everything so all in all they did the disclosure was pretty standard that's a 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 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 a you know nice to get that data point right if I may add something if we if we are talking about a disclosure I think one thing if 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 in the code itself so so yeah so when I send them the report it was you know with the right function names and the right architecture so I think it was a bit of a shock for them but well it's a lesson that I I bet they learned to try to not give free 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 of my first research was done on emulation 100% based on emulation I just extracted the firmware from from ruckus and then I managed to emulate most of the of the device itself which well all the vulnerabilities were found on the web interface so I managed to to get the 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 I you know for live demos and stuff and so when I got the device itself I could I could debug and see different 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 there all the configuration or all the binaries depends you know 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 you know by debugging the just the binary itself on the device I could see all the files it tried to let me actually it was with a simple S trace 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 managed to override one of them well specifically the cease dot XML I would win and thankfully it happened well so you're definitely not afraid of diving into the very technical stuff here so would you talk just a little bit more than about how 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 so it eventually the web server is just talks with other services with other binaries with domain sockets and at first when I was emulating the 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 I you know just by running a simple TS on the device I could see all the other binaries that I had to trigger and all the way and all the domain sockets they had to to use to get everything work together so yeah that's 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 even you can even emulate like the kernel and Ruckus actually gives you the config file for the kernels itself so theoretically you can just compile yourself that 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 you can things that you need to spend some time and understand how to emulate you just don't you don't need to do it so it really helps very cool you know kind of once 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 that was kind of hunch because so my first research I found several bugs and 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 the everything that they are validating all the inputs from the user are well let's say it's not like airtight it's not that they got some some bad practices there and and hopefully I was managed to find these three primitives which were the new line the shabang and slash and thankfully with those with those primitive I was able to to understand that this validation function is not doing a good enough job and that's how I get 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 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 you know 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 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 exist but if I if I knew that they're going to use it I would definitely tell them to use a different function with more robust white placed or black placed to be exact do you think any of the any of those vulnerabilities like like that that function 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's going to be about one and done kind of deal. Oh yeah so I think by 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 this code but what I did realize and I already mentioned it in just 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 of the 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 text. 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 a relation 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 a brick some devices in my in my in back in the time so I I don't think because I was dealing with user space and nothing that was too deep in the internals of the of the device I did not manage to break in although that well it was for another research but I realized that if you write echo like any any echo right a character a character to slash dev slash aspects usually the device get get brick that happened to me before I don't even know why I did that but I just I think it was like a last last resort I was like okay nothing works let's try to echo to the entire dev and that worked fully that's good to know yeah so yeah no rm slash rm minus rf slash and no slash dev aspects I'll keep that in mind the next time I'm hunting around in these things yeah so in the stack overflowed did you have to use any sort of brute force to overcome the SLR yes so well so that this stack overflow I was lucky enough to just basic that so the same payload for my first stock over flow although they were in different binaries the the library that I was using to rope guy to create the rope chains were both in lipsy so I only had to fix the addresses and basically I use the same gadgets but the thing is so in my first stock overflow back back in my first research I I was I was trying to deal with the SLR 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 I'm 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 command injection and sorry for the stack overflow and on okay so we 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 the zap binary from my first research so I think I can overcome the SLR 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 with the most basic POC because the command injection in my opinion is way more it's not way more critical but it just different it's easier to exploit you're talking about the web server can you can you talk more about the web server correlation with with the binary yeah so as I said as I mentioned before so the web server is in and it's super common for embedded devices it just communicate 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 net for configuration and just about everything and the interesting part about about this binary is that Ruckus so they Ruckus were using this embedded JavaScript developed I think by embed this I'm not sure this is theirs but I think so that they work together embed this which is the web server supports the embedded JavaScript EME GS and so this this in back server or back end JavaScript that was the one that this is the language they use to trigger different function that would be sent to different binaries so I get into it in the first in my first start but also in my second that so they added a card to trigger these 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 I'm how I date does ask the question here he's talking that you found a cross-site scripting and some other exploits was looks like he's specifically wondering about a C-Surf vulnerabilities did you find any C-Surf in there no actually so the the entire C-Surf 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 records in the in the embedded JavaScript language that I mentioned before some of them were expecting a C-Surf token but the thing is that some of them looks to be like hard-coded there so probably I can just overcome the this token but I did not pay too much attention for it I must honestly say yeah and well and the excess vulnerability as well it just it was just out there it just for every request you send you just get the reflected you know reflection for what you send so I'm like okay there's there's an excess here I gotta I gotta tell them you can't not report that one when it he didn't sounds like he didn't really try it just came back to you so and that 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 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 to found even 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 state 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 excess 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 I have to report it very good well we're we're kind of coming to the end of the Q&A session and one thing that Fowler 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 you're 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 I think so in our group there are a lot of going on with you all different sorts of research project and I think I already got another research that I just started it's not going to be in better devices because I just want to experience with something else probably going to be around a bit a bit pausing and 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 I so as I already said emulation in general I think it's 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 it's 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 thanks thank you everybody for coming out for the Q&A session and we will we will see you guys later on congratulations again on on a great talk and happy anniversary thank you very much guys all right we'll talk to you guys soon okay