Security Unlocked 7.21.21
Ep 37 | 7.21.21

Discovering Router Vulnerabilities with Anomaly Detection

Transcript

Nic Fillingham: Hello and welcome to Security Unlocked, a new podcast from Microsoft, where we unlock insights from the latest in news and research from across Microsoft security engineering and operations teams. I'm Nic Fillingham.

Natalia Godyla: And I'm Natalia Godyla. In each episode, we'll discuss the latest stories from Microsoft security, deep dive into the newest threat intel, research, and data science.

Nic Fillingham: And profile some of the fascinating people working on artificial intelligence in Microsoft security.

Natalia Godyla: And now, let's unlock the pod.

Nic Fillingham: Hello listeners. Hello, Natalia. Welcome to episode 37 of Security Unlocked. On today's podcast, we are joined by Jonathan Bar Or who is the author of a blog from June 30th, 2021, in which Jonathan talks about discovering some firmware vulnerabilities in networking hardware and how he went about, first of all, discovering those vulnerabilities and then working with the vendor to get them resolved.

Nic Fillingham: It is a fascinating conversation because it really starts in one place, which is Jonathan, basically helping test the, the efficacy and accuracy of a machine learning model. And it ends in Jonathan sort of working hand in hand with this network manufacturing company to get some, uh, pretty gnarly vulnerabilities addressed.

Natalia Godyla: Many of us have seen the recent stats on the rising number of firmware attacks or attacks via internet-facing systems. And as we all continue to live this hybrid remote work life, we recognize that our weakest link can be the home network infrastructure that companies now have to secure since the infrastructure extends well beyond the office now.

Natalia Godyla: Jonathan is super great at describing this really technical investigation and he uses a ton of acronyms that I think would be worthwhile to cover off here before we dive into the substance of the episode.

Nic Fillingham: Yeah, Jonathan talks about TLS encryption. I think our audience is, is pretty familiar with, with that transport layer security, which is the successor to, to SSL. The other one that was used quite a bit was NVRAM. And that's short for non-volatile random access memory, which is memory that saves it stored data, regardless of whether the, the power is on or off. Any other acronyms you got on your list there.

Natalia Godyla: He does also reference QEMU, which is a open-source tool that performs hardware virtualization. And he uses that in the course of in his investigation. So you'll get to hear a real-life use case for that solution. I do have to pause and just give serious kudos to Jonathan because in the episode, as he's describing these vulnerabilities and how they occurred, he defined side-channel attacks to us. And he does this by setting up a riddle and describing the analogy that supports that riddle using a classroom with 40 children trying to ace an exam.

Nic Fillingham: Yep. We'll leave it there. That's the teas. It's a fantastic analogy. I think you'll enjoy this episode. On with the pod.

Natalia Godyla: On with the pod.

Nic Fillingham: Welcome to the Security Unlocked podcast, Jonathan Bar or. Jonathan, thank you so much for your time.

Jonathan Bar Or: Thank you for having me.

Nic Fillingham: Jonathan, if you could give us a, a quick introduction to yourself, what do you do at Microsoft? What's your job description, but what's your, your day-to-day look like?

Jonathan Bar Or: So, I'm a security researcher in Microsoft. I've been in Microsoft for the last five years, give or take. And I've been focusing on, on, um, mix between a red teaming and blue teaming also known as purple teaming, mostly on, on, um, the Microsoft defender world. So, both antivirus and post-breach solutions. Currently, I'm, I'm doing the research architecture for the cross-platform solution for, uh, Microsoft Defender for Endpoint.

Nic Fillingham: Good. So on today's episode, uh, we're gonna talk about a, ah, blog post that you authored on June the 30th, around some, uh, vulnerabilities that were found in some, uh, the network hardware. Before we jump into that blog post, though, I'd love to sort of understand a little bit about your background. We're gonna talk about firmware, we're gonna talk about sort of unpacking firmware. We're gonna talk about sort of low-level decryption. Can you tell us about your, your path to Microsoft in your role and, and as it pertains to what we're gonna talk about in this blog post?

Jonathan Bar Or: So, as I said, you know, that's the five years I've been Microsoft and I was a part of a team that looked at all the security techniques that were available, both for pre-breach and post-breach, and was tasked with both simulating them, finding new techniques and detecting these, or even preventing these. So, if you look for instance, at what, uh, MITRE attack metrics, how it looks today, then we kind of created that even before the MITRE attack metrics was existed, it was created internally.

Jonathan Bar Or: And then initially, I was responsible for the lateral movement aspect of the attack, moved towards, uh, looking at kernel exploits, everything that's related to exploitation really moved towards temporary protection. Because one of the things that we really wanna have is, is a product that can't be easily tampered with, right? Especially because attackers nowadays, at least in Windows, heavily rely on running as administrator. So, i- it's quite a challenge.

Jonathan Bar Or: Later, I wa- I, I joined a team that does kind of a mix between attacks on the endpoint and attacks on, on the cloud itself. So if you look at attacks today, you'll see, let's say tools like Ruler, right? Which is an attack tool in which if, if someone, uh, compromised your Outlook account online, they can basically breach your, uh, endpoint. Right? So everything, everything now is, is, is basically a mishmash of, of attacks. And you have to kind of, uh, coordinate how the endpoint and the cloud work together.

Jonathan Bar Or: As a part of that effort, I was also tasked with kind of leading technically at least the network detection and response e- effort that became basically the network device discovery solution that is, uh, basically described in the blog post. As a part of that effort, I also looked at some firmware vulnerabilities because  

we know our customers are sometimes are not only they're vulnerable, but also they don't know that they're vulnerable. They don't know what's on their network.

Jonathan Bar Or: So, that, that was kind of a huge effort. And I would say that 99% of my work there was really describing kind of the attacks themselves and how to fingerprint devices correctly. The 1% that is basically, you know, resulted in the blog post is basically looking more deeper into, uh, what attackers could do with network equipment.

Nic Fillingham: Thank you, John. That's a great setup. So, the blog post we're gonna talk about today, or the work we're gonna talk about today is from this June 30th blog posts. So, you basically, uh, I'll paraphrase and I'll have you sort of correct my oversimplification, but you notice some, ah, anomalies coming from a very specific router made by a- another company and basically went through the process of decrypting or extracting the firmware, looking into the firmware and finding, up- I think it was three vulnerabilities. And then you sort of went through a, a disclosure process with the company and ultimately got that fixed.

Nic Fillingham: I think in, in today's conversation, I- I'd love sort of a, sort of a chronological walkthrough of how this happened. How was my summary? Did I get that right? What- what's, what's the sort of TLDR for this blog post?

Jonathan Bar Or: You are absolutely correct. I don't need to correct you. Uh, that was 100% correct. So basically, basically what happened is, is we, with time, right, we started, uh, getting our, our data from our customers and we started realizing that we have an issue, right? Because there are known network equipment vulnerabilities that are very... sometimes might seem even, even very reliable for attackers. Right?

Jonathan Bar Or: And we see, we, we actually see that attackers are moving away from modern operating systems because they're so hard in these days. In the past, you could have just exploited, you know, found... find like, uh, you could have found basically like a m- memory corruption vulnerability, and you'd get code execution. And these days you have so many technologies, the known ones are of course a non-execution, the NX bit or, or DEP. That's how it's called on Windows. And also ASLR that randomizes how mo- modules are laid out in memory.

Jonathan Bar Or: Of course, that's not bulletproof, but these days you have so many other technologies. CFG is one of them. There are, you know, sandboxes inside Windows and other operating systems as well. New, uh, hardware vendors are implementing pointer authentication. So all these things make life really, really difficult for attackers to attack o- modern operating systems, not just Windows, everything, right? Linux, Mac are, are really hardened well.

Jonathan Bar Or: And again, because, because of that, attackers tend to move away from those things where network equipment and all of these things 'cause, 'cause they're easier to target then continue from there. So basically, the problem is that a lot of the, um, network traffic between these network equipment and the modern operating system or endpoints is encrypted. In this case, it was TLS encrypted.

Jonathan Bar Or: So, one of the things that I started doing with our machine learning folks is basically to train a model that  

would say, "This network connection is an anomaly even though we can't really tell what's inside because we can't decrypt it." Right. "Both technically and, and also legally."

Jonathan Bar Or: And basically, the idea was, okay, so let's say, I don't know, I'll, I'll give you a scenario. I'm not an, an IT person, I'm just working at some company, you know. At a certain point in time, let's say at, at midnight, we see that my machine tries to log on into a router's management support, right?

Jonathan Bar Or: That's not something that should normally happen, right? I'm not an IT person, we're not supposed to do that. And then our solution is supposed to basically flag that and say, "Oh, this is an anomalous connection." So just based on time, the type of machine that I have and, and so on. And so ba- basically we started, uh, training these models and they work pretty well. We simulated some attacks, known attacks on, on various webcams and routers and whatnot.

Jonathan Bar Or: And then basically, started getting feedback from the field, from our customers. At a certain point, we found, uh, one of these cases and it was really weird. It was kind of almost like these, uh, scenario that I just described, basically a non IT person connecting to a router at, I wouldn- I wouldn't say midnight, but over the weekend at the very interesting hour where no one is supposed to be awake, hopefully.

Jonathan Bar Or: So basically the, the problem now is, is okay, we have an anomaly, but how do we prove that it's actually bad? And this is where I started, uh, my research from, if that makes sense.

Natalia Godyla: Yes, it does. And, and why did you decide to pursue an investigation on this particular anomaly?

Jonathan Bar Or: To be completely, uh, transparent, we wanted to know that our machine learning models work well because up until this point, we just tested them synthetically. As in, we trained them and we ran some attacks, simulated some of them, but we didn't know exactly what would... how they would really work in the field.

Jonathan Bar Or: So, imagine that you, you train your, your machine learning model and you test it and it... they look good. And now you dispatch them to the field, to customers in a non-enforcing mode still because we wanna get feedback from the field before, before releasing it, you know, publicly, and then you get a hit, right? You get, you get an actual anomaly hit. And now you, you basically wanna, ah, as a researcher, you wanna understand what happens there. Right? And, and the only way, because I got, uh, I got the, the network communication recorded, but because it's encrypted, I wasn't able to do anything.

Jonathan Bar Or: At this point, what I decided to do is basically try to prove to myself that it could have been such an attack or at least an attempt, right? It would be very hard for us to be honest, to tell the difference between, you know, an attacker trying to exploit something like what I found and just an attacker trying to scan the network and look for just, you know, even trying to brute force, let's say the management port of the router. So, we still don't know exactly what happened there, but we suspect it might've been one of these cases.

Nic Fillingham: And Jonathan, were you actively hunting, or were you still in sort of model training, model verification mode? I think you mentioned this was, this was customer data. This was... these were network 

equipment actually out in a customer in production running one of the Microsoft Defender for Endpoint services. Is that right?

Jonathan Bar Or: It was a design partner. That's how they are called because it was before, uh, the general a- availability of our product. And yes, I was actively hunting. We have a good machine learning folks that are far, far better than me and more proficient in this, this worlds. So all the credit goes to them. And basically what I tried doing is to prove to our, basically to our leadership and also to ourselves and to our, uh, mach- machine learning, uh, team that their efforts, you know, actually bear some fruit.

Jonathan Bar Or: And then one thing that I would like to mention is the fact that a lot of these design partners, once we ran our solution, we're really shocked to discover how many things there are in the network that they don't, they don't... didn't even know about starting from, you know, Raspberry Pis that employees just brought, you know, ju- just logged into their network, following with vulnerable web cameras that were just there, printers that were just unknown to these folks.

Jonathan Bar Or: And we're also... we also discovered a bunch of network configuration issues. For instance, we discovered some devices that just had open Telnets, which basically means that if someone runs in the network, they can just run arbitrary code on, on, on these machines.

Jonathan Bar Or: So, we started from there, right? And th- that router was also one of these things that were just really weird to see because basically, it's, it's, it's mostly used as a, as a, as a home router as far as I understand, but, uh, nevertheless, we found it on a customer's network.

Natalia Godyla: So you mentioned there were a few surprises. What were the patterns? Were there a particular set of devices that were more commonly identified, like more Raspberry Pis versus routers that were previously unidentified to the customer and like how many new devices on average?

Jonathan Bar Or: I would say that there are case-by-case basis, right?

Natalia Godyla: Mm-hmm (affirmative).

Jonathan Bar Or: It really depends on the customer. For some customers, we found interesting, I think it was around 20 something Raspberry Pis that were just-

Natalia Godyla: (laughs)

Jonathan Bar Or: ... like they didn't know of. The open Telnet issues were found on a different customer. The vulnerable, uh, web cameras were found on a very sensitive kind of, uh, design partner. So it was really alarming to see, but, uh, we didn't draw any, any patterns. We did, however, try to improve our fingerprinting with time. Right.

Jonathan Bar Or: So, if initially, we had our fingerprinting for just the most popular vendors and with time we started getting a lot of, uh, unknown classifications. So we had to improve with time and this thing is, is not, you  

know, it's not a sprint, it's a marathon. So basically, uh, we always get one of these like unknown devices, and then we have to fingerprint them one way or another. But I, I guess it's kind of a different story.

Nic Fillingham: I don't wanna di- um, digress into a sort of a, a product pitch here, but, but Jonathan, the, the actual sort of feature or the product that this work, that you... that this machine learning that you talked about and the work that you're supporting, this is a part of Microsoft Defender for Endpoint. So it's the ability for the Microsoft Defender for Endpoint service to run a process, a service that can fingerprint all the devices on a network and then sort of return a view, a sort of a device discovery, sort of a capability inside the product. Is, is that correct?

Jonathan Bar Or: Yeah, that's right. And after the release of, of that feature known as, as the network device discovery feature, we actually acquired two, uh, companies that are very focused on, on network equipment and also IoT. Uh, there's our, our, uh, CyberX and our ReFirm Labs, both of these companies are very proficient at what they're doing. And currently, what we're doing is really to get, get their knowledge absorbed into the product so we can actually do even better. But yes, this is a part of the suites.

Nic Fillingham: Awesome. So, you saw the- the model flagged anomaly, you thought I'm gonna, "I wanna investigate this and, you know, see that the model is actually doing what it should." What was the next step? Did you just physically go and procure one of these network devices or was still unclear what the actual device was? Did you have to do some more investigation to find the, I mean, was the Mac address there? Could you have lookup the Mac address and work out what the, the model number was, et cetera, et cetera?

Jonathan Bar Or: Yeah. So basically, uh, from the Mac address, there is an OUI that you can get, like that's the three first octets of a Mac address, and you can kind of, uh, conclude who the manufacturer is. And then we actually asked... Again, we asked permission from the, uh, design partner to actually, uh, work with them and try to identify the device.

Jonathan Bar Or: Once we identified the device, we still haven't purchased one of these devices 'cause, you know, we had to prove to ourselves that this is really an interesting case before purchasing a bunch of others. But we did. One of the thi- things that I started doing is to try to, with a design partner, try to actively fingerprint the firmware. And I was able to do that with not a lot of difficulties.

Jonathan Bar Or: Um, and then, what I decided to do is just downloading the actual firmware from the vendor's website, which was and still is, available, and basically try to analyze it statically. As in, without running it, without doing anything. And that's where I found, I think the first vulnerability there. And after I found the first vulnerability, I, I basically, uh, pushed for us to acquire one of these devices, actually two, because we were afraid to break one of them and basically try to find more interesting issues there.

Jonathan Bar Or: So we did. We ended up buying that. Before buying that, one of the things that I did was to, uh, emulate the firmware. And you can do that with tools like QEMU that's the, the number one tool probably to do that. But you have to basically simulate some things that are, that are out of your control. In this router's case, it's basically the entire NVRAM, uh, so y- you need to do a bunch of hacky stuff to actually e- emulate it and, and make it, make it happy so it runs, uh, smoothly. So I was able to do it, but not, not for the entire router and sometimes it crashed, and this is why we decided to actually buy one of these things.

Natalia Godyla: So, just stepping back for a minute, can you walk us through what the three vulnerabilities you identified were and TLDR and how you got to identifying that particular vulnerability?

Jonathan Bar Or: Yeah. So, as I mentioned, the anomalous network connection was to the router's management port. So the router keeps a bunch of listening ports open, and one of them is, um, management utility over HTTP, or in this case, it was HTTPS 'cause it was TLS protected.

Nic Fillingham: And Jon- I'm gonna jump in, Jonathan.

Jonathan Bar Or: Yeah.

Nic Fillingham: So, if, if anyone listening to the podcast has had experience either playing with routers or even the one at home, are we talking about the exact same thing where, you know, you set up your router for the first time and you go 192.168.1. something and then a webpage loads. And you enter in like a default username and password. And there are the settings for the router. Is that... When you say management console, is that what you're referring to?

Jonathan Bar Or: Yeah, that's the one.

Nic Fillingham: Go ahead.

Jonathan Bar Or: And then, the three vulnerabilities were basically, uh, an authentication bypass where basically, uh, you can, without knowing the username and password to the router, you can basically log in and do whatever you like. That was, uh, vulnerability number one. Vulnerability number two was, uh, another, I would call it probably not just authentication bypass, but a, a side-channel attack on the username and password verification.

Jonathan Bar Or: So you can basically, uh, with a very low number of, well, relatively low number of, uh, attempts basically conclude what the username and passwords are. And third vulnerability is basically kind of a broken cryptography case where basically the vendor used a baked-in password to encrypt something.

Jonathan Bar Or: And then, of course, encryption doesn't mean anything if, if an attacker knows the password and the password again is, is embedded in the binary, which is somewhere buried in the firmware. So, it's, it's more like obfuscation really than, than encryption. So that was the third, uh, third vulnerability, which is, I- I'd like to say less severe than the other two.

Natalia Godyla: And you made a point of distinguishing authentication bypass from a side-channel attack. Can you tell us wh- what's the definition of each of those? What differentiates those two types of vulnerabilities?

Jonathan Bar Or: Well, the authentication bypass is basically when, when in this case, the router, but generically, any system that requires a username and password, then you ju- just somehow bypass and bypass that the requirement b- basically making the system believe that you're authenticated, that's the authentication 

bypass.

Jonathan Bar Or: The side-channel attack relies on, on, in this case, time differences of, uh, the system responding to an attempt, right, to a username and password attempt, which basically allows an attacker to conclude that the username and password. And if you're coming from a cryptography background, this is something that is basically a cryptographic vulnerability.

Nic Fillingham: So, I loved reading your description of how you did the sort of secret retrieval and were able to, you know, ascertain the, the username and password. Is there anything about that technique that... I mean, so I'm not a security researcher, so this, to me, this is all new and very interesting, but the techniques that you went through to do this, was this all, you know, folks listening to the podcast that do this kind of work pretty standard, or did you have to sort of really, really think outside the box and sort of be creative here in, in your approach?

Jonathan Bar Or: I mean, there are certain things, uh, that, that when you look statically at their binary and you start to reverse engineer it, you'd look for a certain patterns and certain function invocations. In this case, actually the... that approach led me to both of these vulnerabilities, right, the authentication bypass and the side-channel attack. Where I, in the authentication bypass, I found that the vendor was using, uh, the notorious C function strstr and in the side-channel attack, the vendor, uh, was using strcmp for a string comparison.

Jonathan Bar Or: So, when, when you get, you know, experienced in, in exploitation, you kind of try to look for, uh, all of these unsafe functions in a binary. And then what I was really looking for is basically a memory corruption issue, right? This is usually the case with these things, but I found basically this... these two issues are logical bugs, right? Specifically, the side-channel attack, if I may actually, uh, try to explain that to my cousin, uh, with, with kind of a riddle.

Jonathan Bar Or: So what I told her is, is that, imagine that you're in high school, right? And your teacher is giving you basically a pop quiz, like to the entire class. It's only a pop quiz with 10 questions. Okay? 10 questions, uh, with multiple choice even. So four options for each question, right? So I have 10 questions with four options each.

Jonathan Bar Or: And the teacher basically announces to the entire class that if someone aces the test, then the entire class passes, otherwise everyone fail. Now, the teacher basically checks every test in front of the students and takes, let's say a second to check each answer. Right. And, of course, the teacher want, just doesn't want to waste their time and doesn't wanna check a paper that's not perfect. So, the teacher basically stops at the first mistake, right?

Jonathan Bar Or: So, let's say that you submitted your test with three, a- and the third answer is, is a mistake. So it'll take the teacher three seconds to basically say, "Oh, you fail." The problem is that we're all very bad students. And no one actually knows the answer to-

Nic Fillingham: (laughs)

Jonathan Bar Or: 

.. any of the questions. Right. So, how can you guys, um, really pass the test given the fact that there are just 40 students? That's the riddle and the answer is basically the, the side-channel attack. So, of course, each answer has four options. So, normally you would need over like a million attempts, right? So you need a million students to actually guess every combination.

Jonathan Bar Or: But what the students can do is to measure the time it takes for the teacher to check each, each submission, right? So, let's say the first student tries question one with the option one checked, right. And then if the teacher, the teacher takes more than one second to say fail, then everyone knows, everyone knows because everyone's present when the teacher checks. Everyone knows that the first answer is answer number one. If the teacher takes a second or less, let's say, then the second student can actually try answer number two for question number one, and so on and so forth. Right?

Jonathan Bar Or: And then if you calculate it, you understand that for each answer, besides the last answer, you need only three attempts to really conclude the right answer, right? So if all three... first three, uh, students fail then, then fourth answer is the one tha- that's right.

Jonathan Bar Or: So, basically, we need 3 times 9 plus 10, which is, uh, 37 attempts. So even have three students extra. And this is how you solve the ridd- the riddle and, and this is exactly how the side-channel works, right? You basically rely on the fact that they run strcmp or a string compare, which is a lazy function just like the teacher. It basically stops whenever there is a mismatch.

Jonathan Bar Or: So, if we do an attempt and measure the time it takes for the router to respond bad username and password, we can actually conclude whether we... ou- our first character, let's say, was correct or not. And if it was then continuing to the next character and so on. So, this is the... how the side-channel tech works.

Nic Fillingham: Tell me what you were like in high school, Jonathan. Were you-

Natalia Godyla: (laughs)

Nic Fillingham: Well, did you pull together 37... 36 of your friends with stopwatches? And, uh did you-

Jonathan Bar Or: I wish I had 37 friends. (laughs)

Nic Fillingham: (laughs)

Natalia Godyla: (laughs)

Jonathan Bar Or: I'm kidding. I'm kidding.

Nic Fillingham: (laughs)

Jonathan Bar Or: Um, wow, that's some, uh, unintended, uh, uh, sort of therapy happening here in uh-

Nic Fillingham: (laughs)

Jonathan Bar Or: ... in the podcast.

Nic Fillingham: (laughs)

Natalia Godyla: Now that you've gone through this process, you know, what's the takeaway for customers here, um, as we, as we started to talk about earlier in the conversation today, routers, firmware, this is a n- new threat vector or one that is increasingly being considered by threat actors. Do we have guidance to customers on, on what they should use, how they should use our products to help secure themselves?

Jonathan Bar Or: Yeah. Generically, I would say that we see, again, we see a trend of attackers moving away from the endpoint. This connects well to what I said about the cloud and it connects well to what I said, I said about, uh, network equipment. Basically, network equipment, and, you know, IoT and what, what I call devices basically. So IoT is just one branch of them is significantly less secure than modern operating systems sometimes because it has to due to performance, due to size limits. This world is just a very rich and much less secure than modern operating systems.

Jonathan Bar Or: So, I would say that to customers that first of all, be aware of what happens in your network. And one of the ways that you can do that is, is, of course, with a network device discovery solution, such as the one that we're offering. Basically, all the regular IT management is still relevant here. So for example, making sure that all of your solutions are patched, make sure that you get the late- latest firmware from vendors.

Jonathan Bar Or: And it's, it's not a very easy thing to do in, in many cases, especially for all of these devices. A because sometimes our customers are really not aware of what happens in their network and what- what's connected to the network. And secondly because sometimes it means actually manually upgrading firmware. So, so this is not a very easy task, but it has to be done if you wanna be secure. So, unfortunately, it's, it's, again, it's not a very easy thing to do, but it must be done.

Natalia Godyla: And so that's what's next for you? You'll be identifying ahead of time, another investigation to kick off based on what you find?

Jonathan Bar Or: Well, when you say for me, it, it could really be interpr- interpreted as two different things. For that product and the product team, yes. We're... they're going to do that. And as I said, they're working hard now to, to make sure that all of the knowledge from CyberX and ReFirm Labs is being absorbed, if you will, into the product to make us even, even greater.

Jonathan Bar Or: For me personally, as I said, uh, I'm now working on, on the cross-platform for the defender for endpoint, but I'm hoping to achieve a similar fits there if, if, you know, if, if I get lucky.

Natalia Godyla: (laughs)

Jonathan Bar Or: So, if I may add, I'd like to thank not only the, the coordi- vulnerability coordination team, but also, of course, to NETGEAR that we're very responsive and reactive and work closely with us to make sure that all customers are protected.

Nic Fillingham: Fantastic. Well, Jonathan Bar Or, thank you so much for your time. Um, I really enjoyed reading your blog posts. I'd love to learn more about your, uh, let's say exploits, but I think in this context, that's the wrong word. I'd love to learn-

Jonathan Bar Or: (laughs)

Nic Fillingham: ... about your investigations in the future, um, looking for vulnerabilities in, uh, in lots of different pieces of technology. We'd love to have, have you back on the Security Unlocked podcast at some point in future.

Jonathan Bar Or: Sounds good. Waiting to find more things and come back to your-

Nic Fillingham: (laughs)

Jonathan Bar Or: ... podcast.

Natalia Godyla: Well, we had a great time unlocking insights into security from research to artificial intelligence. Keep an eye out for our next episode.

Nic Fillingham: And don't forget to tweet us @msftsecurity or email us at securityunlocked@microsoft.com with topics you'd like to hear on a future episode. Until then, stay safe.

Natalia Godyla: Stay secure.