10 Yrs Hunting Zero Days in Weapons Systems

immigration

my glasses

okay okay

check check I hear myself yeah all right

um

quality over 25 years

okay so we are getting over to our next session today we have with us Mr Brandon Ward and he is going to oh yes we got some claps that's what I'm talking about let's give it up we've been drinking uh the balls guarana I see got a lot of energy Mr Ward is a cyber security engineer with Raytheon codex specializing in reverse engineering vulnerability research Hard Target emulation and advanced program analysis for the past seven years Mr ward has served as chief engineer of codex's cyber vulnerability assessment programs applying the tools and techniques of the offensive cyber expert to the securing critical systems Mr Ward also serves as the site lead of codex Tampa St Petersburg office and has

served as a principal investigator of several DARPA cyber efforts and with that being said without further Ado Mr Ward sure

thanks everybody mic check anybody hear me hit me in the back excellent all right um welcome to this talk um thank you guys all so much for showing up um I know there's a lot of things you could have done today besides this go watch baseball which I'm gonna do a little bit um but you know they thank me for being a speaker when I got here but I want to thank all you guys you know basically thank all the people who contribute to sort of the Tampa info stack community um you know I think it's growing and it gets better every year and so that's all for you guys thanks um let's get started here

um I'm gonna talk real briefly about where I come from um there's a company called Raytheon codex we're like a business group within the large thing that is Raytheon um we used to be a company called SI govs we used to be called CSI um and our code codex um the big offices over in Melbourne Florida there's 300 Engineers over there we've got a small site here in Tampa St Pete um you know we do a lot of this work you know a lot of vulnerability research reverse engineering a lot of emulation work you know a lot of this really just grew over the tech base that we've built over the past 15 years supporting the VR task right finding

bugs the tools you need to automatically find them to help VR Engineers do the job faster program analysis how to expand to ever stranger Target sets um to figure out how to do the work um people just told you we don't need to go over that um so cyber vulnerability assessment is probably the most unfortunately named thing I don't know why we came up with this because I think the dod has like the same name for something that they do and like there's four other people that do the same thing um and it's basically to try and do the same job right which is um secure you know what we call Blue four systems secure

um you know us technology uh weapon systems supporting technology um in one way or another uh and the way that we do this is we take the existing Tech base uh existing knowledge base that we have that we spend a lot of time and years uh pointing at Targets to find bugs and we point those things at our customer sets um you know their targets to basically emulate the same thing um find bugs help them patch it um secure the systems um what else uh the big thing here is is the Cooperative piece of this um if someone comes and you know there's a piece of equipment that falls off the back of the truck and you ask me to

spend x amount of time analyzing it finding bugs in it there's this massive upfront reverse engineering effort um you throw like a series of binaries at me and give me you know tell me to look at them you know you're going to spend the majority of your effort for the first x amount of months trying to figure out what is this thing what Target is it what architecture is it what does it do um and the real thought is we shouldn't have to do that with our own systems right bring in the system stakeholders bring in the development teams that are that are doing that work have them work sort of hand in hand with us to do that

rapid information dump to say okay this is what the system does here's where the major components are is how they talk to each other this is where the important processes live here's the artifacts that they consume and you know even further like here's the test sets that we use to test the system now here's all the test data we use you know from functional tests through unit tests Etc you guys should adapt this to do cyber testing analyze the system you know really rapidly you know find vulnerabilities and enable the customers to fix them um and the other big thing about this is you talk about actionable vulnerability reports um we only really report out things that

we've proven um you know if I have a fuzzer that has a crash um that's something that'll turn into a report someone to fix um but if I you know let's say they're like you have some sort of uh you know you run some static analysis tool it says oh there's a potential vulnerability at this line of code whatever um we'll go look at that run that code exercise that code to see if it's real um so really taking that sort of false positive level that you get from a lot of sort of tooling and just take it all the way to the ground if I if I pass over some um only 30 report to whatever customers

that's the thing that we have done uh on on the system on the code that giveness um and then you know what we want to do ideally is be able to pass information you know actionably into the software development chain so that they can fix things they can write sort of sort of tickets um I I always say I do not want to be like sort of sort of like Uber consultant right who comes back like three years later to tell you the same problems that I found like last time I was here you know I want you to be able to fix this stuff and the next time I come over you can we can look at

some new Target set all right bad news up front um I swear I have done this and I've looked at many systems and found many bugs um me and my team um we are not going to talk about any specific targets any specific findings um there are pretty obvious reasons for this um you know even you know outside of this space um people are super leery about you know even if they found stuff right you don't want they don't want you know you know you assessors to be sharing that you know what kinds of bugs are you finding um we're going to talk a little bit about the end a sort of high level what kinds

of things we see but um if you want me to say oh you know in system X we found this vulnerability uh that's not gonna happen um what else oh okay so I just want to take a quick suret here just to kind of gauge the room um how many people here like software Developers pretty pretty decent amount how many people here have put their hands on like ghidra or something like that at some point in life okay good good amount okay who here knows what like a fuzzer is all right cool I think we're going to be in good you know we won't have to sort of walk through a lot of that stuff

um all right so this is our sort of ov1 view of this um there's two major Pro uh steps to this process right uh when we engage with uh new customers uh we we sort of say okay what we're gonna do initially is this sort of software architecture security assessment this is pretty similar to kind of lots of other sort of secure systems engineering exercises you're going to see as far as uh identifying where data comes into the system understanding how data is passed within a system how data is trusted within a system um what are the sort of impacts I can have I could have you know if I could gain access to a system and do effects

everything from you know dossing a system to full code execution you know what kind of uh you know ability do I have to you know Elevate privileges paper through the system steal data Etc um really to end up with uh this sort of prioritized list of like here's where we want to look at this system um and I just give it sort of like to for some scale here right um let's say you came to me and you said hey I want you to look at like a submarine I would say that's like way too big like there's 400 computers in that thing uh let's spend some time thinking about initially what we want to

look at for his engagement and that for that like subsystem let then we can sort of apply this process and say um what does this thing do where are the critical components um what are the ways that you know attacker can touch this thing um and sort of you know end up with this sort of prioritized list here um there's one thing that makes sort of the sort of sassa process different which is uh the whole time we're doing this I'm really trying to drill down with a customer to find out where the binaries are what they're running on how they're compiled how they talk to each other what libraries they link to um what kind of os protections

uh config files data formats you know what the ideal here is like at the end of this Sasa process I have like a package that I can hand over to like a VR engineer and they can like go go open this again I see where the binaries are I see where all the link libraries I could run this thing in emulation today if I wanted to um I can open these things up in ghidra start looking you know at the code although to an extent do we really need to spend a lot of time in ghidra like we have source code most of the time right so you know we get the benefit of not needing to look at

deidra's um you know decopulation necessarily uh because we have the code I will tell you that we still use gedra like a whole lot because it's like the best way to sort of move around and code and sort of follow connections and understand dependencies and stuff like that um but that's a part of this sort of Cooperative process where we're like you know you got super good code Auditors um give us your code we'll spend time looking at run tools on it Etc um and then this second piece here which is like vulnerability research um and I always kind of the way I kind of describe it right um let's talk about the standard vulnerability research job without sort

of this Cooperative you know effect um you know there's a lot of reverse engineering here right and then we sort of enter this process which is like a dual static analysis and dynamic analysis at the same time we've got people tearing apart code we've got people running static tools on these things and then a lot of times we're trying to get things running either on you know you know in containers in virtualized environments um in emulation in order to do what to basically you know normally we basically want to like Point buzzers at these things send them all kinds of crazy data get crashes Etc um I'm going to talk a little bit about fuzzing in a couple slides because I

think it's interesting it's useful to understand sort of the state of play as far as usefulness of actually fuzzing targets today um so and dynamic analysis together the bugs fall out if you file your vulnerability reports any questions to try and stop every now and then like ask questions I don't understand like a data job if anybody has a question just like bridging oh so just to hammer home this whole like Cooperative nature of this um you know we really encourage our customers to like you know really cooperate with this as much as possible um this is what happens when you don't I actually got a message yesterday in signal from one of my engineers and it

says in other news a guy at XXX client is stonewalling slow walking providing a software for an audit of a dice so we got one off of eBay and are in the process of dumping a fair player so we're going to get there anyway so you may as well help us um so I can't talk about specific systems but we can have like an idea exercise or we can talk about this sweet baby here right probably the most wicked weapon system you've ever seen it's the tank and a sub and a helicopter um It's You Know believe me when I say when we talk a little bit about how this thing would be put together it's pretty

similar to how any other sort of large weapon systems put together there's pretty standard sort of bus usages across a lot of Frameworks there's a lot of standard usage of um the same sort of computing components operating systems message sets um you know it's not unusual for me to walk in and say okay I got it you got a heterogeneous environment with like arm and mips and they're talking across some 1553 bus and maybe there's some like space wire over here or whatever you have ethernet running in here also cool um they're sensors there's a radio there's crypto cool um so how will we sort of walk through this I'm gonna go through this sort of

like Sasa process quickly and again if you guys have any questions please call out I'm really just going to try and drill down to how we would tear this thing apart again this is way bigger than we ever generally look at for an engagement but I think it's going to be useful and maybe you guys can all go home and see if you can purchase your own Olympus off the internet later um so you know in the end you're gonna have stuff like this right uh this thing's gonna have to do built-in tests so there's probably some master computer to try and run all that crap um there's a bunch of com systems that probably going to this thing I mean heck

this guy's gonna need to have like boosted comps probably for example water these need to have like sat comp or it's flying around it's gonna have to have like internal comms on the thing so probably those things are going to come in to the system through their various sensors they're going to get wired into their you know their sort of localized message set you know handlers and they're going to parse you know pump all that to something that's like a comms manager right um and people who need to get that information that's going to sort of be sort of dispersed across the uh um loader verifier you know you're going to see a lot of these right there's

generally I don't know you know so a lot of times these things have sort of single software load uh architectures where when this thing sort of boots up it's going to push all these software loads to a whole bunch of different systems and then it's going to say hey run crcs or Shaws on these do crypto verification make sure that that is the uh the software that we intended to load onto their mission computer this thing's doing a mission it's going to have a mission computer which is probably integrating a lot of this stuff into it between the comms you know it's got uh you know when this thing is flying it's gonna have you know avionics

in order to figure out how to how to move the vehicle along um oh does anyone see like what the what the the worst part of the system is it's that main laptop um and and and and I you know you're lucky if there's one right um you know often there's like five you know contractor X has a specific part of the system that they work on and they show up on site and then they connect and they upload software and then they walk away and then somebody goes who was that guy oh I don't know he's the guy from Lockheed who uploads software on this thing sometimes like okay cool um a lot of times in our engagements we

just sort of assume presence on that thing um as far as trust levels and security levels um it's a juicy attack Vector um that things not only is it in transit um you know it is the piece of equipment which is most easily easy to abuse um it's the easiest thing that someone's going to plug into the internet at some point and it's going to end up as a foothold for this system um so going forward what we do here um so as we go forward this is kind of how the systems you know perhaps going to look like um it's got some sort of uh division of Duties on these three different uh 1553

buses that it's using to share data um and there's some unfortunate things that you're going to see in all these things right which is some of the some of the worst like components get like the most access to like everything like your maintenance laptop who you want to like sort of push software updates and configs you often see that thing sitting on like all the buses so it kind of can just look at anything same thing with something like a bit processor right that thing's trying to harvest all the bit results and it wants to give you some coherent status of how this thing booted and how it's working so that's going to have a tremendous

sort of visibility across the system you know and and as we look for you know things to attack you know all things give it being equal um we're going to look at things that have the most ability to sort of talk to other things uh what else so this is sort of how I was talking about how we want to keep sort of pushing down the stack on this stuff um we're working with the customer we're talking about things we're finding we're evolving our understanding the system with them based on documentation they're going to give us uh you know source code they're giving us conversations with developers Etc and in the back of my mind I'm always

trying to build this picture here right and uh this is normally an interesting exercise to try and get to common language on these things you know what's your architecture oh it's a I don't know it's it's a whatever it's a navigation I'm like I don't care about what it does what show me where the computers are like what do you mean I'm like literally where is a microprocessor and what's running on it what kind of computer is that it's like it's you know I will say it's amazing but but I think it's just you know different sort of you know people have different ways to do in business right and it's you know there's always an activity to sort of normalize

on language and get people talking um there's often this discussion we have with like sort of the network security person um and I understand Nick those you know they have a job right and we are not there to like mess with that but if you tell me um hey we do all this this all this work with like vlaning stuff to make sure things can't talk to each other okay and we have all these firewalls in place and stuff like that that's cool too um and we normally get this position where I'm like I will assert that all those things work perfectly like you don't have to worry about like I'm not worried about your firewall configs uh

or your VLAN management um what I'm going to say is these things need to talk to each other there is a link between like that uh you know that uh maintenance laptop to the comps processor it has to you've told me that this is the path for for sending data and usually there's like he's like oh okay I get it I get it fair enough but um this is sort of the language that my team wants to talk about it's like where are the computers how are they compiled what are the security settings on those things um what are the key processes and how do they talk to each other and even down to what are sort of the data formats

they're passing around right and where are those handlers uh the more information you can give me in my VR team get faster we can get up and running and the more infectious this process is if you tell me this is the guy who wrote the sort of tactical message handling code and here is the functional test that he wrote or she wrote and here is the dot h file that has all of the the definitions for those messages I'm like yes we are talking the right language now I can write a fuzzer for that in like an afternoon versus if we had to do this blindly it might take five months right um so here's sort of the vulnerability

research process which which I talked we showed in the the ov1 um you know to this day you know you see a lot of of research papers Etc about automating and automation is good um I think from sort of codex's perspective most of the value and automation for us is to point smart people to the places where they can make the evaluations of whether there are bugs here um so sort of human in the loop sort of automation assisted is kind of where we use a lot of tooling um the tool that basically looks at your your binary your source code and says I found the bug and I popped it and I automatically wrote an executable

just don't like work or exist um there is still you know a tremendous amount of sort of crazy thinking that VR Engineers hackers do um and you really need to sort of put them in the position to evaluate uh how things talk to each other how you can misuse them how you can force them to misbehave so we do a decent amount of source code auditing still there is I swear to God a guy in Melbourne Florida and he prints out C code and he walks around the office reading it on printer paper and he's super super smart he finds tons of us like if that's your thing cool um we put a lot of custom binary tools

um you know again we use disassemblers and things like Deidre even though we have the source you know I always make the joke that's like even if you give me all the artifacts of how you built this system I still like have to reverse engineer it like in order to get to like the Zen of how this thing works I need to sort of walk through what you did and there's still effort there it's not nothing um and we we have you know a lar a long tradition you know in the industry doing Dynamic analysis building closers building emulation Frameworks building the ability to run six million fuzz tests a day on a system to find crashes

and easily triage them and rerun them um in context to find you know what caused them um so we still do that a lot and I'm gonna explain why this is still a pretty big part of uh of our workflow um so how do we do this cooperatively um sort of the old-timey VR process was sort of like you know all this reverse engineering Etc but we get cool things like give me access to your Source repo um let me see all your old bug tickets right if you guys found bugs in the past I can go look at code that looks like that we can find books give me all your build environments um you know

you know for a couple reasons right to see if you're building securely but also maybe I just want to roll this thing straight into AFL recompile your code and like run fuzzers on that you know the easier you make it for me the better um so you know normally we're coming from pretty mature uh sort of developments uh when you're talking about sort of modern weapon systems supporting infrastructure so they've got lots of testing they've got lots of virtual machines they've probably used already you know maybe even the written custom emulation of weird architectures that we can we can reuse specialize test script I will put a caveat on the VMS um this is just something we've learned the

past few years and we come into this like customers especially ones that are running you know part of their systems is a more traditional let's say x64 environment um like oh yeah we've got a whole virtualized test system that you can just use and the first thought is like sweet give me the VM and I can just boot it uh and then you find out it's like a four VM sort of setup and they all have to come up together and they these VMS are configured to require like you know 32 gigs of RAM each and they do like we spend more time trying to get other people's virtualization Solutions up and running then half the time just like you

could just just roll about ourselves so just just something to think about um all right assistant fuzz testing I'm going to talk a little bit about this um I will just read this lots of modern communities commodity software already subject to extensive fuzz testing during development um Google Microsoft Etc um if you're if you're building sort of really well put together really you know billion dollar software you've got a secure a team you're buzzing the heck out of this stuff before it goes out the door and you know if you think that I'm gonna walk in the door on like Google Chrome and point some like Dev random fuzzer at that thing and it's going to

fall over it is not there's a reason that those bugs you know you can sell them for a lot of money um but so I'll just bring this up here for all of our developers I've been trying to push this for a while if you're writing your own code especially if you're writing anything in sort of non-memory safe land you really should be fuzzing that stuff yourself um again anybody who writes C code or C plus plus code if you've got header files is you've got unit tests you're already in a perfect position to sort of beat that code up and buying the Bucks before they ship it'll take you like a tenth of the time that'll take like the

bad guy but guess what like the bad guy is willing to spend a thousand times as much as you are to find those books so you know uh David rumley's been pushing this for years you guys you know track him he works for for all secure he's got lots of articles on this sort of integrating fuzzing into modern development environments um CI CD yeah you should be doing it if you write software um so what are the modern issues with like fuzz testing on Modern software right you know you get these large code spaces um difficult to explore all the code uh even with intelligently generated inputs it is not unusual for you know us to set

up you know spend time learning about your system figuring out sort of the data sets that you use use those as seeds for fuzzers and build you know a moderate size like fuzzing infrastructure that's let's say you got I don't know 20 or 30 cores on it point that at a system six months and never get any crashes you come back and that's like been hitting the same sort of code pathway for six months and then you have to go find a way to sort of undo stuck States Etc um there's also sort of this large upfront setup effort um you know hey I'm going to build this virtualized Farm of computers and I've got to have sort of a test harness to

manage it and I need to find a way to to find in triage crashes um you know if these are like non-x86 computers maybe I need to bring qemu into this or maybe I have to write some sort of custom emulator I mean that is a tremendous amount of work um and a lot of modern VR people uh I think will just tell you that they don't do it anymore Eric do you agree he does I would not use this but why would we use this for like our effort set um we have help um again we can punch through a lot of those problems because we have access to the developers and their data sets

um using existing test data from functional testing unit testing to Target specific code locations so I don't spend as much time in sort of stuck States if there is a key piece of software like a parser that I want to get to I could go to a developer and he says yeah I wrote a functional test for that this thing will get you right into that it will prepare that software state for you and it will then get to that code that is awesome that that's really where I want to be seeding my tests um what else and the other piece is uh you know we spend a decent amount of time getting systems to boot and operate in their

intended modes of the states right if you're working from sort of a black box reworld hey I've got this binary running and it's booting and it's crashing okay you got to go figure out there's some config file that is a specific setting in it that it needs it set in order to turn this light on in order to get the thing to boot or uh oh this thing expects to talk to your bit processor during boot in order to make sure that that handshake's successful and it's going to send some token over the wire to make this thing actually work um that's all work that we basically have to go through but again doing this

cooperatively we go talk to the person who wrote that you can say oh I have a test unit for this it'll just get that's just right to where you need to be super super nice to sort of save that kind of time so this is an art one of the arguments uh why we still incorporate a lot of us testing the CVA process um and here's some other ones um I'll just go back real quick so there is still a lot of C and C plus plus an assembly code deployed on systems out there um that's 30 years more um was developed in environments which we're not thinking a lot about security when they're initially designed

um and because of the nature of these systems um nobody's like pounded on the stuff um we still see pretty trivial kind of uh stack based buffer overflow type of stuff where people are not compiling but secondaries or proper runtime projections um sort of trivial like parser type stuffs where config file parsing you know would we'll knock over the system there's just a lot of code right if you think about let's say the U.S military industrial base there's billions of lines of code that have been deployed on systems that that are still need to be used for decades right and anytime you talk to these developers these owners they talk about the long tail right which is great you found this

bug and we're gonna fix it but we've got 3 600 systems deployed all across the world which basically have to be updated manually using some sort of CD that needs to get shipped um just it's not a great system for for rapidly fixing systems or to sort of maintain uh sort of high security systems um so you know yes goodness well the good thing is right that even outside of the cyber world software updates exist right um you know any any systems that are that's under active development or even a maintenance contract um is going to get software updates so you know a lot of times literally you're talking about dropping CDs into the make

and shipping them across the world to the person who's the sort of uh system owner at that remote location with like you know sending an email on the side so you're going to get a package you need to update these um you can also think about how horrible that is the fact that I could send you know like a CD to say hey you need to install this um but you know there are mechanisms in place that just they weren't they weren't thinking about this and it's tough um now I'm definitely not gonna say that every system in the world is like that right um you know some systems are naturally sort of better equipped for some of this right

you've got like a satellite system right those things are already need to be updated you know remotely so you sort of have some ability there um but sort of other kind of physical systems they still are maintaining these sort of logistics lines which involve physical updates um so it's not super super uh responsive any other questions yes sure um like I used to work on embedded crypto systems back in back in the way back um so we had over the over-the-air software updates to those um so if you've got something like a like a software radio or something like that sure they have the ability to pass that stuff you know encrypted over the wire so that's the thing but it's still

you know it's not the same thing as pushing something an update over the internet right it's a still an order of magnitude more complicated and annoying a process um you're definitely not going to get into something that's like Ci CD world where you're you know you're finding bugs you're patching them you're testing them you're pushing them like eight times a day or something like that you know when I worked in that world you were talking about updates still four times a year so that's sort of yeah

um how does it work I mean I don't think it works any differently than threaded intelligence in the commercial world right like what do you know about the people who are trying to Target your systems uh what do you know about the specific tools and techniques and capabilities and goals of those adversaries um you know perhaps the ways in which you get that information are a bit different but um I think it's still the same sort of you know sort of use case modeling and sort of threat modeling that you would do on even a more open system um the threat intelligence itself um I I guess you'd say that I mean there are people who spend a lot of time

thinking about you know threat modeling for you know us weapon systems and you know there are ways to get that information do no more questions I'm joking um so I'm gonna go we're gonna go through some lessons learned things we've seen um so here's a good thing uh there's a lot of secure design you know with those being done 20 30 40 years ago right um think about um we called like high side systems you know red black linen systems there is a lot of thought putting in put into the requirements um there was a lot of valuation of code back then a lot of serious testing on things that were considered critical and that's helpful

um you know a lot of sort of secure gatekeeping type code um which is kind of stuff that I was writing 25 years ago um when you're talking about like you know what we would call the you should call sort of system high design where there's stuff that's trusted and there's stuff that's not there's stuff that's encrypted and then there's stuff that's not and that sort of gaping between that needs to be super you know well tested and well designed and you've had you know dozens of sets eyes looking at that and that's good that's a you know that's a way to make make good um what's the bad one of the bad things is

um well a lot of times you know sort of people in the binary exploitation world are really looking to get code execution run their code and you sort of pop up notepad um if you're talking about a super critical system in a mission environment that needs to be up all the time um every one of those fuzzer crash tests that I found is basically all the stuff that we would probably throw out um if we were trying to actually get code execution you got to fix all of those problems definitely don't want these systems you know being taken down in the middle of some sort of Engagement or even worse someone having sort of a

deterministic sort of Replay attack where you think it just hit you over and over and every time you sort of reboot you can turn off say.com's computer um so you know a lot of times when we're talking to customers you know I'm like do you want us to go further with this like this is probably exploitable but it's also a crash that can be deterministically thrown so you should fix it what else uh they're good um complicated embedded systems are still hard to understand even with all the source code I had a note in here about like is this hard VR um I think a lot of VR people would probably say in some ways no because

you're still dealing with a lot of sort of you know unsecured CNC plus plus code but the hard part really is how sort of weird these systems end up being with you know three different architectures uh four different programming languages weird non-standard to most people sort of bus you know messaging and stuff like that so there's still an upfront lift in order to get to a state where you can understand um how you can stimulate the system how you can crash it how you can sort of build your threat model and that's good that's sort of a security through obscurity type of type of thing um but it's not nothing um also it's not unusual right where

you've got four different contractors on a system writing different style code uh with different levels of capabilities so it's just this big heterogeneous sort of mess for you know if you're a VR person again it's a little higher lift the bad they said before there's still a lot of Legacy unmanaged CNC plus plus code out there um anytime we look at any embedded system right you know I'm just like where's the C code I have a statement which I'll make which is um any non-trivial c code C program that's more than a thousand lines that's never been sort of banged on is explained it's just the complexity problem alone is hard to manage trying to understand and

you know how this thing's going to work in every corner case it's that's where the bugs are yes

that's what my background yeah so here's how we normally attack that we get this question a lot right um what's the fpga going to do if you're telling me that fpga is implementing like a system on a chip running like an embedded processor I can look at that like a normal processor right like well I wouldn't have it on an fpga if it wasn't like that because there's all these other pieces and filters and and you know computation things in there um we turn that sort of into a simulation problem right where it's like okay uh what I want to do is I want to emulate let's say the microprocessor portion of the soc but then I need to sort of build

this sort of gray box of that I you know where the data comes in and where it goes out and again that is super super hard if you have developers involved if you have all the design I can get easier right do you have a Matlab model that you use to test this thing in the first place give it to me and I will use that as an input into the thing that's trying to get this target into the right state so that you that makes sense yeah yeah but um you people come to us all the time right he's like what about all the bugs in the fpga code that's a super hard problem

foreign just just leave it there um bad lots of lots of custom build environments lots of custom configs I also say a lot of older build environments it really drives me crazy when you find people that are compiling code without stack protections on without aslr turn on without NX and you ask them why and they'll say one of two things um we never thought about turning that on this file's been like around for 20 years um and just never occurs or we're afraid it'll break the bill and you're like have you tried and you're like nope let's just see if it'll build this way um it's almost impossible in modern development environments to compile that

stuff out um but there's just a lot of you know the embedded world there's a lot of old tools out there where people don't even know they're like if you know version seven of this they implemented like NX I didn't know that um so all you developers out there I don't know that supplies anybody in the room understand you know the tools you're working with the architecture is running on and sort of the security protections they can already provide um so that's how we find sort of exploitable bugs that wouldn't exist in sort of a lot of modern systems um you know because they're just sort of in still in the sort of Legacy mindset

um here's another thing and this is more to sort of generalized VR thing you compile your code and you ensure that it's uh you know you know it's got all the security features turned on everything um and then you link it to like seven libraries and you know bother looking to see if those libraries have like being comparable security protections turned on um you kind of have to think about the whole picture here um same thing with like you know if you're you know a weapon system developer owner right you've got subcontractors and you need to push that kind of stuff down to them it's hey we just learned about this thing called like secure coding we want

you all to signed up to this new model um here's another bad thing we see a lot of sort of custom messaging even rolled over like TCP right um where you know I've got like four bits of start bit and I've got like this field that's you know a time stamp and a sequence number and a message length and then the body data um just hand rolled like C data structure type stuff that's getting passed across the met the the network um that stuff's filthy um I always say so custom message sets equal custom parsers equal bugs um parsers are where the bugs live a lot of the times that's so much like Corner case handling happens through a lot of

like memory allocation occurs trying to like handle this you know you're basically asking the software to have a perfect understanding of System state even though it has this like tiny view of system State and um you know if when we talk to customers the first thing I asked is like okay where are all the parsnips in the system you know I I don't necessarily care about your core processing functionality I I believe that you know how to write like I don't know some sort of DSP style functionality that you chose to implement and see but then you've had some Junior engineer Implement like the config parsing piece that goes there you know that's where the bugs are

um Customs same thing with config files you know this is places where we still find sort of sort of issues you know my recommendation here is like there's existing data formats out there there's existing tools for writing sort of configs that sort of been beat up over time already use them um this is one I I we still see which is crazy is sort of message that get passed over the network to just tell a system to do something like reboot or uh change modes or whatever um you know you you have some sort of let's say mute Mission computer up there that's trying to manage all these assets below it um and which makes sense but you know if I

end up on that same network you've just given me a handle to like just reach out like out the system and like shut it off um we even see places where you'll see like messages like passed as strings over the network which then get passed directly into like command um and executed so like sort of trivial um sort of command escaping and injection over the wire um I I haven't seen as much of this lately but you know it still happens and that's sort of like you know that's that's outside of the CC Plus you know you know memory role right like you see Java code that does this um people that you know are using these

sort of like direct passing of like CIS uh um I'm just gonna go quick here I think I'm a little over time um embedded systems build up State like um if you've got I don't know you've got like a radar system and you've got a that connects into some sort of battle picture management system or whatever these things they're building up State as you go so it's not like like some sort of transaction where it's like you send a message and it either handles it it doesn't it goes back to state zero it's continually building up all this message state which it becomes very unpredictable and very difficult to manage

um this last thing I'll talk about these are just two concepts that I've sort of thought about uh I think this illusion of distance is probably familiar to anybody who's sort of like the penetration testing world people who think because there's lots of systems between the attacker and the target means that they're like far away from each other when in fact it's like no if there's a if you meant for there to be a comms path between those six computers to your computer they're like right next to each other it doesn't matter that all this other stuff's in between you've given me a channel to talk directly another one is sort of Illusion of trust type of stuff

um if you think about like a message coming out of like you know over the air and over-the-air sort of encrypted message like wow that's really hard right nobody's going to attack that you know what are you gonna do if you crack the crypto build your own SDR and send messages over here good luck like okay well that thing connects to like a much larger Network that has 6 000 contractors on there who each of them developed with with different methods each of those systems play different roles in the system like how how trusted is that thing now that sort of blob um you know this is no longer a cryptographically secure Communication channel you basically just like it's

just like a TCP you're trusting every single person on that Network that can touch you to to be a be a good a good actor and that's just to me that's not cool you shouldn't do that um that's about all I got any questions thank you guys so much enjoy the rest of the conference

thanks man appreciate it I appreciate you