GT - Seek out new protocols, and boldly go where no one has gone before

all right thank you I'm excited to be speaking at my first uh bsid Las Vegas it's great to get a chance to to talk to you all today I'm going to talk about something called proprietary protocols it's something I think we leverage not enough in the industry both from an offensive and defensive perspective so I'm going to go through uh both of those things first off uh I like to say who's the crazy guy talking in front of you uh I've been in the industry for about 15 years almost which is scary to say out loud mostly on the offensive side of the house doing a lot of uh hacking I'm also the author and Lead instructor for sand

security 568 which is a product security pen testing class uh and during a day I'm the executive director for uh threat research at sonic wall so spend a lot of time in security threat intelligence and networking stuff which is what's important for today's talk you can look me up on almost any social media platform at Fullmetal packets happy to discuss anything cyber security related if you are interested so to set the stage a little bit uh I'm a little guilty right being a s instructor I always end up defining everything before uh before I get started so we need to start by talking about what do I mean when I say proprietary protocols so an open

protocol are things that you're very well familiar with from a networking perspective these are things like HTTP FTP these are protocols that have what's called an RFC so these protocols you if you want to know how they work you can go somewhere you can look up that RFC it'll put you to sleep but that's okay it'll still tell you EX exactly how the protocol functions on the other side we have proprietary protocols and these are the opposite these are protocols that have been created by vendors typically for a very specific purpose now I did some Googling online looking at like what do people think about proprietary protocols and I found this graphic posted online and I I love this because

it illustrates the point that the internet always knows everything that it's talking about right so here it's the vendor is marketing that proprietary protocols what's so good about them is they are safer because they are unknown now i' I've only been in the industry a short time but security through obscurity I don't think is the Mantra that typically pays out from a security perspective so this is not accurate right it's actually we want to take the time to understand these protocols because they're beneficial whether or not you're on the red side of the house or the blue side of the house so I've put together what I call an eight-step process for dissecting and understanding proprietary protocols I

cover this in security 568 in about a day and a half which I do not have time obviously for here today so we're going to talk about four of the eight steps and I'm doing this because I believe if you want to walk out of here today and apply this immediately these four steps will get you started on the road to immediately apply these principles and start helping you uh within within the workplace so to Jump Right In I'm going to talk about the first concept here referred to as simplifying scope so what do I mean mean by simplifying scope to put it simply it's the concept of reducing data down to a reasonable size

so taking a large quantity in this case of packets sometimes we have thousands hundreds of thousands of packets and how do we get less data that's the goal of simplifying scope because I don't know about you but I do not have a time to look at a th000 packets 10,000 packets or 100,000 packets in my daily workflow so how do we do it now the key to this is we can't just randomly select what packets we look at in selecting less data we have to do it in a statistical significant Manner and what that means is we want to select a representation of the entire data set keyword there being representation we don't want to select the entire data set

and it has to be statistically relevant so simplifying scope is selecting that data set in a statistically relevant way and the way I start thinking about this is starting through what I call grouping packets and we're going to group packets to find out what type of types or likeness we have between packets the goal here is to be able to pick a packet from each type or likeness to have a representation of that group so one way to get started here these are five different methods to start grouping your packets by no means is it an exhaustive list I'm sure you can find other ways to do this as well but starting with the first one protocols himself or higher

level protocols almost every proprietary protocol rides on top of another protocol and it's not uncommon to see multiple higher or actually I'm saying that in Reverse lower level protocols multiple lower level protocols being used within a proprietary protocol so you might have TCP and UDP being leveraged by a proprietary protocol simply splitting them out into two different types or groups of packets starts to get you two different representations of those protocols another way to do this is by conversations or flows many of you are probably familiar with in wire shark you can uh right click and do you show me the TCP flow or UDP flow at times what we see is that a flow of traffic is one

format or one type of protocol again what we're trying to do is to group these so that we have likeness between our groups so we can analyze one or a couple of packets in that group and have an understanding of that larger group another way to do this is by port numbers often times especially destination port numbers will ingest or parse a different type or format of packet think about this from an operating system perspective what is a thread right port numbers are often tied to threads they're they're independent sections of code well that code is different often times between threads they're parsing different different types of packets we can also use payload length this often surpris surprises a lot of

people but generally speaking and again this is not all the time right not 100% of the time but generally speaking packets of the same length often have the same format or the same function and so using length as a tool can be very useful and lastly let's not forget about basic computer science tools for things like Integrity if the md5 is the same between two packets they're the same payload right the same packet and we can leverage that to our advantage so using these five methods the best way to communicate this is to do this in real time so I'm going to walk through leveraging this concept of simplifying scope using a real proprietary protocol

here in this presentation so here on the screen is a proprietary protocol wire shark clearly knows not not what to do with it this is obviously just a screenshop of a much larger peap and we want to start reducing this scope of this pcap so to give you the larger context in this AP there's about 516 packets captured in about 188 seconds or about 3 minutes that's a lot of packets right no no not really that's kind of a trick question that's actually like nothing three minutes of a network capture can be like 200,000 packets right so I say that to illustrate that we're going to do this for just 500 packets uh but you're likely going to be

working with a lot more but the point the principles will hold so one of the things we can can leverage they talked about ground truth being potentially a data sciencey track is this concept of Eda Eda is exploratory data analysis we can actually use code to make it so we have to what uh my co-author for 568 ishill likes to say is not we don't have to read The Matrix he accuses me of reading the matrix by just looking at packets we can leverage code so here is a panda or here's I'm sorry here's python code which is leveraging scapy to put packets into a panda data frame by putting packets into a panda data frame

we can start doing statistical analysis on these packets and we can use the grouping methan mechanisms that I talked about on the previous slide encode a lot faster and we don't have to actually be able to recognize this visually so here in four lines of code I argue it's really two lines of code because two of the lines of code are print statements we can ingest a pcap and display the different protocols known protocols in that packet so here we've got UDP and TCP now if we do this for the example peap that I provided you or provided on the screen for the grouping principle here are four of the different grouping techniques I talk about the first one

was I said you can Group by a lower level protocol unfortunately here that becomes useless right the entire peap is UDP so we're going to have to try again so we're going to look at another method I said destination ports could be something that is useful for grouping if we you leverage our Panda's data frame to graph out destination ports we instantly get four distinct groups of packets okay now we're on to something there's a chance that these are all of similar format or different formats if you will what if we' use length if we use length we also get four distinct different groups which begs the question is there an overlap between length and

destination ports we always when we're simplifying scope the stronger case we can make is the more data points we can use and it just so happens that if we tell python to group these together we actually get a perfect marrying of length and destination port and this is very simple to do leveraging Eda and leveraging pandas you don't have to always visually see this you can totally do this what I would call the hard way and I've done it that way many times but this is Will speed up your process so now we have this concept of okay if we take the length and the destination port number this could help reduce our data set but we've looked at one pcap is that

statistically relevant no right one pcap of data of one capture that's great but this could just be a random Trend that we found and that's very important in dissecting proprietary protocols you need multiple captures multiple instance of the same behavior and that's also very key so let's go ahead and look at this again for a second take of the same behavior of the protocol we're looking at and what happens is we actually get a very similar representation there's a few minor differences here but the important thing to point out is that our length by destination port number pairing still holds true and we can test this a couple more times but the concept is this is

likely a good place to start to reduce our scope down to four packet types so here we had 516 packets in 188 seconds and in just a few minutes we selected four that require analysis not 516 and I can't stress enough that out all of the eight steps in the process I have put together for reversing proprietary protocols this sets you up for either success or failure this is probably the most important step so now moving on to some of the other steps the other thing that I will note uh here quickly is the first step has to be first you have to do simplify scope the rest of this is kind of in an order that I felt was

useful to me and to my workflow and can definitely be rearrange to your workflow once you've done simplified scope you can rearrange these to whatever you feel is the most useful so I'm going to talk about a concept called embedded networking as the next scope it's it's actually uh very common in proprietary protocols to see embedded networking within the payload of the protocol that matches the networking D data in the other lower layers so what do I mean by that things like IP addresses Mac addresses port numbers are often duplicated in the application layer or payload layer of the packet the number one question I get when I talk about this information is why to be

honest I don't have a definitive answer to that question I've never written a proprietary protocol my hypothesis which I think is is based in a decent amount of data is there's a chance there's a large chance that the higher level application that's receiving this information does not have access to the networking layer of information so if they want to make a decision based on let's say an IP address of where something coming from or a port number they embed that in that in the payload so they can access that information I think is typically why we see this but this is seen all over the place so here we have gu shark in the IP layer it's

showing us that the source address is 126 1.1.1 I love this cheat if you highlight it in wire shark it highlights it in the payload and hexadecimal for you it makes it very easy to visually notice that there's another value of the exact same pattern in the payload of the packet and this is the concept of embedded networking if we take this concept and we look at all four of the packets the representation that we took from the larger groups we'll actually notice that three out of the four have a IP address embedded in the payload of the packet so now we're well on our way to understanding how this protocol Works our goal here ultimately is to go from

knowing nothing to knowing something it's sometimes we're able to find out what every bite means sometimes it's not possible or not easy to do but we get one step closer to understanding that protocol the next uh concept or step if you will is something I call enumerating patterns and this is the idea of leveraging patterns across packets across pcaps and within the context of a capture and I'll show you what I mean by that here in a moment and to to determine what bytes in a payload may represent so let's first zoom out and look at the higher level peap again uh just from a wire shark perspective now here we're filtering by length and port

number because that was what we concluded was one group of packet so now we're looking at the group that we've decided and we're saying what are some patterns within this group and it doesn't have to only be within the payload I see that as a common mistake immediately you open up the hex deal View and I want to look at the payload well how about looking at the overall conversation one thing that sticks out as a pattern if you will is this repetitiveness of four packets in a row from the client four packets in a row from the server okay that's interesting and we can also see from a Time perspective these packets are sent almost at the

exact same moment in time well because uh we have this data in a panda data frame it's very easy to check other grouping methods that I talked about in the beginning with just one line of code we can actually check the md5 Hat of these packets are they the same or are we dealing with different packets and what we find out is that four packets is actually the same packet repeated so what we care about or what are the differences between the repeated packet and the packet that is changed understanding how uh cryptography works this could be one bite this could be the entire packet that's different so we want to start tackling this question what is different

and what can we learn about the fact that there's a difference here so if we open up the three three of the packets for the to see the difference across the different payloads and we simply no nothing fancy or trickery here we start looking at one bite at a time after where we have known data so we know the IP address we know where it is in all three of these packets we see that it's the same that's expected because it's coming from the same place what is the next bite Well turns out we start looking bite by bite and the next three bytes are the same where we get a difference is the fourth

bite interesting so three packets in a row the first thing that is different is there's four B three bytes are the same one that is different now in networking it's it's possible to have one bite that indicates something that's why scapy has a bite field for example however it's more common to see two or four bytes or more increments so you're it dissecting packets is a little bit of an art you have to make some assump and then either prove or disprove those assumptions most of the time I'm going to not assume that one bite is different on its own I'm going to assume there's a group of bytes involved and here since I have one bite changing I'm going to look

at these as a four bite group and see if I can determine what these look like now if you can spot it using the hexadecimal here there is a difference of 10 between each one of these I apologize for mixing decimal math and heximal but I think it illustrates the point a little bit more simply on on the slide so here we see it incrementing by 10 so what could that mean that could mean a lot of things one it could in theory be a coincidence even though I don't believe in most coincidences what is causing this to change if we zoom out again and we look at the the the entire peap or filtered

pcap and we look at those four packets we can see that there's something else changing by 10 and it's the value of time so almost exactly to time there is a 10c difference between each one of these packets does that mean that this value represents time no it could but it also could not be I I just randomly started the next four bytes and found a 10 difference so how do we validate this hypothesis well we can take those four bytes and we can convert them using an Epoch inverter why Epoch because that's the most likely thing you're going to see in uh in hexad desmal in a packet and we get a timestamp of Tuesday

January 23rd 2018 does does that mean it's a time stamp it could just randomly translate into a time we want to validate this by looking at the frame of the packet the frame of the packet also shows January 23rd 2018 the time itself is slightly different but the the probability of the date being exactly the same across those two values is pretty low it's a pretty strong indicator that this is likely a Time Value in the packet so that's just one way that you can leverage one thing you determine by looking at patterns across payloads and across different uh across a pcap I'm going to jump down here for a second to step seven and I'm going to

talk about application reverse engineering this is something that is very useful to you for dissecting proprietary protocols if it is an option and I stress the If part because a lot of times we're dealing with proprietary protocols in iot ic infrastructure and you may not always have access to the application to do the reverse engineering but if you do have the access the if an application is sending and receiving a protocol it understands it if it understands it you have the source code and you have to just be able to read that source code so this is a very strong tool in your tool belt if it's applicable if we go back to our pcap uh this a little bit about this

protocol this is a medical protocol uh it's called the r what protocol and here what we were looking at was the client the client in this case is a medical device not impossible to get the parsing code for sure we could do some Hardware hacking techniques we could pull off firmware uh we could see if it was downloadable but definitely the more difficult approach the server in this instance is a Windows machine much more friendly to work at if we want to do some application reverse engineering so for a moment if we say that we didn't figure out what that time value was and we wanted to investigate if the server side had some clues of what that was we

could dump the server uh in this case dll into something like Ida Pro and right off the bat in Ida Pro this is right in the very beginning of the code uh we get some Clues to what be going what might be going on here now Lucky in this case a lot of debugging symbols were left in function names were left in the majority of this was left here for for me to view uh which is extremely helpful right in determining this I recognize that might not always be the case uh dur during your event but it's something to look out for so here we have a function called broadcast rwood I did not rename that that was provided to

me by the developers thank you very much we know from a little bit of uh osint R what's the name of our protocol broadcast it's going to the broadcast address this makes sense I'm looking in the right place right we go down and we see that there is another function called get R what period it's being saved into a variable I did rename the variable so the variable name is R what period I named that for just for readability on on the slide but I did not name the function and we can see that that variable is being used in a debug statement I love logging in debug statements they provide a lot of useful

information especially for something like this and it says the r period is so many seconds and if we dig into that function just a little bit further we can see that there is a value that's being returned either 10 15 or 20 uh depending on what a configuration is I also named this variable as well so this one was not left in but I renamed it for for readability so this is just an example again of using the tools in your tool belt to help determine what is going on The Wire what's going on on the wire or the ground truth if if you will so I'm going to take a break of go from going into the different processes

of reverse engineering those protocols that gives you kind of a a quick ramp up as I said I do this for a day and a half in in security 568 uh but I'm going to turn to talk a little bit about how you can leverage this from an offensive and a defensive perspective so starting with the offensive side I'm biased I did mostly offensive security so I I generally start there I'm going to go over three principles really quick that you can leverage proprietary protocols for assuming you understand just at least a little bit about them and so I'm going to talk about exfiltration emul uh emulation excuse me and falsification so starting with exfiltration if you remember there was

four packet types we looked at we Group by length and port number this is the longest packet on the screen of the ones uh that we selected a concept that I didn't have a lot of I didn't have time to discuss today is the concept of padding proprietary protocols generally leverage a lot of different padding and they can do this in one common way is to do it in the form of null bites not always it can be any value but often times it's either a null bites or F or what I see the most commonly used here I've highlighted on the screen all the null bytes within the larger packet you can see there's quite a large quantity

of them in fact additionally if we zoom into the top part we can actually see there's even runs of 32 38 bytes of consistent null bytes if you think command and control if you think exfiltration of data and you know that these are going to a broadcast address it's very simple to embed what you might need from an attacker's perspective hidden Within These padding bites to leverage on the network and frankly and the reality of it is most Defenders have no idea what this protocol is it's not being parsed by ids's or other security tools unless they're doing this you likely don't even have to get the format right you can probably strip out the

rest of the payload and and put the whole 600 bytes with whatever you want maybe have a few values in the beginning correct so that way it looks like the other stuff but it's very easy to exfiltrate data with proprietary protocols the next thing I'm going to talk about is emulation often times from an offensive perspective it's useful to make it look like a device is is there that's not there or that you took down and you want it to keep looking like it was doing what it was supposed to do I'm going to use the RW the medical example to to demonstrate this in a a quick little video here don't get caught up on

the medical nature of this so this is the server uh and I'm plugging in a Raspberry Pi obviously not a medical device right this is just a Raspberry Pi and the server is going to interpret the data that the Raspberry Pi is sending as valid Medical Data it's actually going to report it as a heartbeat and so as long as this Raspberry Pi is plugged in it's going to keep getting that emulated data from the proprietary protocol now don't get hung up on again the medical example here you could use this in a large number of different use cases or you could uh pretend that something's working at a certain level that it's not and very closely aligned to that is the

idea of maybe I don't want to emulate the entire device but I want to falsify the information that the device is sending so again Leverage this medical example uh here we have the end medical device this is a patient Monitor and it's showing that 80 beats per minute is what's being translated and we're going to bring that up in the uh Central monitoring system here or the server side of the device you're going to see that data communicated across now an attacker that understands how this protocol is supposed to work can manipulate that protocol as it goes over the wire already demonstrated Python's very good at and using scapy uh at bringing in these pack pet and and

utilizing them we can in a simple script here we can send we can intake those packets we can send them back out and we can have them with a completely different value in this case jumping to 180 now again don't get hung up on the medical nature of this example obviously there's implications from a medical perspective but think about this what about an alarm system whether you wanted an alarm to go off or not go off right think about any type of IC System whether you wanted to to make sure that a a valve was open or a valve was closed all of this applies to that as well so that's from the offensive perspective so

now let's talk take a little bit about the defensive perspective of proprietary protocols even though I come from a background that's largely offensive I actually think from a proprietary protocol perspective this is way more important we have to understand the data on our networks in order to be able to defend it properly we have to have that Baseline of information and reversing these protocols helps provide us that Baseline so I'm going to talk about three different uh Concepts again from a defensive perspective I want to talk about threat modeling mitigations and detection and because it's 2024 and I'm speaking at a conference I have to leverage AI or they literally cart me out of the room so I am going to make

sure that I get some of it in this presentation there is a model out there called stride GPT I don't know if anybody's heard this before but it's it's used for threat modeling and it can produce mitigations it's actually a really neat tool like most AI powered functions it is it perfect absolutely not do I think it should replace your threat modeling and mitigation strategy absolutely not but it is a great place to get started to give you some ideas on how to move forward from a defensive perspective one of the things that uh I we talk a lot about threat modeling in uh security 568 and one of the things we talk is a threat modeling Manifesto

which has four questions for threat modeling two of them are what are we working on and what can go wrong and we document them doing something called a DFD or data flow diagram so what you see here on the screen is a data flow diagram of a different protocol this is not the medical one that I was talking about before that is that has been produced by reverse engineering this protocol and understanding how a system works and as a result what could go wrong with it this is created in draw.io which really cool is we can upload this image to stri GPT and stri GPT is able to then understand a little bit about how the system works it

actually populates this description field that you see on the bottom automatically based on that diagram I fill out a few other questions on the right hand side about the application in this case it's an iot application it has basic authentication you hit this generate threat model button at the bottom and you're off with a a generated threat model to start your work with it does different things on top of generating because the threat model it's going to generate I'm sorry is stride based hence the stride GPT stride is not always the most useful methodology to use one of the things that I like to Leverage is something called attack trees and this will actually generate an

attack tree for you and provide it to you in a graph form I find this extremely useful when thinking about things like mitigations and what can go wrong within your network if we look at the nodes all the way at the bottom we can see these are the outcomes or the potential malicious activities or the risk that can occur by using this protocol of course this is based on what the I the AI thinks generated on the in the the input that you gave it but I think it's more actually impactful than the act the outcomes at the end are the fact that you can see what I like to call these choke points within the

attack tree you can see that there's this one thing that's leading to multiple potential risky outcomes so if I'm able to mitigate this one thing I get the biggest bang for my Buck is protecting against these these type of attacks here obviously in this particular instance the fact that it's an unencrypted TCP protocol is providing the way or Paving the way for four of the outcomes provided the other thing you can do with an attack tree is you can look for things that your organization may be specifically concerned about uh a lot of times in the government World location leakage is an important thing and here the threat model has identified that a location leak can occur well I can work backwards

now so I don't really care about the other potential outcomes but I care about this one I can work backwards up the tree and say what do I have to do to mitigate the risk of location linkage if you're paying attention you can also see on this slide a little bit of the imperfections or not usefulness of something like stri GP stride GPT excuse me in fact having a node that says UDP Network traffic risks is not very helpful right but again this is a a model it's a representation uh as George box used to say all models are wrong some are useful what we're striving for here is something that is useful to help you

mitigate risk in your organization not for something that is 100% correct taking this one step further further uh stride gbt will also provide you a mitigation suggestions based on the attack trees and threat model it provides sometimes these are not super useful they're super overarch ing or industry best practice but again they can jog the thought process on what are things I can try to implement I like this first one here that it produces of course it's going to align these with stride again that's why you see spoofing here and tampering and the screen is cut short uh so it that may or may not fit your methodology but the first one remember we talked about emulation on

the offensive side this first one's actually very well geared to emulation it gives you a scenario and it gives you a potential suggested mitigation the first scenario is an attacker uses a forged IP address to impersonate a legitimate client that sounds like emulation that's what we talked about in the offensive section so what is something we can Implement to help prevent that here it suggest implementing IP whitelisting that's a good suggestion that would definitely help with that emulation problem that we're seeing on from an offensive side so lastly uh I want to talk about uh detection uh which is also something that can be uh extremely important from a defensive perspective I'm to do so uh

in utilizing Zeke I think Zeke is probably one of the most well-known open- Source IDs tools out there so like to use stuff that people are likely familiar with one of the things that I was short in having time to talk about is the this concept of documentation by scapy it's probably the second most important principle in dissecting Pro proprietary protocols and is that you have to document your findings and nobody likes documentation I highly suggest that findings are documented using code so as you learn about your protocol if you write what's called a custom scapy layer that is reusable then for both defensive and offensive purposes offensive things like fuzzing for example defensive we can use it for

detection or logging or baselining so here would be an output from the uh the second protocol I showed you of a scapy layer for that UDP packet and this is just writing es scapy layer for uh what we've learned doing the the reversing now to the best of my knowledge there probably people in the room that are way more familiar with Zeke than myself so uh happy to talk if I'm incorrect about this but I don't believe Zeke understands scapy directly you've got to do something else in order to get it there well one of the things that it does understand is a language called spicy and it's actually very simple to take a scapy protocol and to convert it

to a Skypey uh I'm sorry a spicy syntax I kind of like the way that phrase is uh phrase works out and so here what I've done is I've taken the scapy protocol and I've implemented in uh spicy uh syntax now this is something that you can compile that Zeke understands how to use so we can compile this using the spiky C compiler that comes with Zeke and we can now create a Zeke event this is very very basic I'm just simply showing that you can print out information about the proprietary protocol uh to the screen show you what that might look like you can run the custom Proto or the proprietary protocol through uh through Zeke directly and you

can see that it's parsing out the embedded networking here we have something called a type field and a session ID that's in the protocol but there's that location data this protocol is actually sending you coordinates every time a UDP packet goes out on the location the UDP packet came from here it's repeated five times in this payload and you can see that it's now understood by Zeke what can you do with this you can now detect anomalies right you can now print this to log files that you're ingesting in your other security tool sets to write rules around you can't do that if you don't take the time to understand the proprietary uh protocol so I think there's a lot of value in

this so that's what I've got for you today I thank you for taking the time to to listen to my talk I hope you enjoyed it if we have time left I don't know exactly where we are on the schedule uh happy to happy to take any questions live or afterwards thank you

[Applause] yes sir I think they have a mic they want you to use I'm hello hello great talk than um do you know of or can there exist a scapy to spicy to wire shark dissector pipeline I don't know of a pipeline that exists I I or some variation there yeah I'm not aware of one that currently exists I think it would be a great thing if you want to start open that would be fantastic but I I'm unaware of I'm not aware of one any other questions yes sir uh when you're working with these uh proprietary protocols and you find issues that are um abusable from an offensive security standpoint do you work with the vendors on those like

what's your process there stuff absolutely I've found fact I've got several cves to my name test to to that specific point is issues with that yeah follow responsible disclosure is is typically the way I go about as if a vulnerability discover Discovery process uh there it does get very complex depending on the industry in which the proprietary protocols being used uh in in uh one that I discovered that was in the um building automation industry for example that was a relatively easy fix that fix was in in software on the firmware that was digesting the protocol and they were able to an update to that uh and so that was a very good process and another instance where we found

flaws in the protocol that was in the medical industry right that gets a lot more complicated right they uh they had said that they'd have to go through their accreditations all over again to make that change right and then you have and that's the constant problem you have in ic iot critical infrastructure is it's not as easy as patch it right uh but yes to answer your question directly when I've discovered flaws in the protocol before work directly with the vendor to responsibly disclose them and then you some type of coordinated release uh have you done anything with identifying hashes or signatures in packet streams I'm sorry say again hashes or signatures where hashes or

signatures in the packet stream yeah ABS absolutely there's a lot of times a characteristic I see a lot of is different crc's for example which are not I know they're not a hash but the same same concept that that you're talking about uh those are obviously get a little bit more complex to identify one thing that uh there often times if you're looking at cryptographic tokens of some type A lot of times they're at the end of a packet and my my advice for when you run into that is you don't want to try to look for those first right you want to weed out like the other stuff that I'm showing uh embedded networking

clear text communication uh you're running tool external tools like binwalk and things like that on payloads to help you identify what you're going to end up with is you're going to get all that stuff taken care of and now there's going to be a group of five bytes over here that you have no idea what it is you're going to find two bytes over here that you have no idea what it is right you can start looking at those then with a cryptographic mindset uh to say is this potentially a hash is this potentially some type of CRC uh a lot of times you want to use the I think it's step six in the process is behavior

modification uh and the concept with behavior modification is you want to set up the protocol to work in a normal environment and intercept that traffic make a change and then see how that change affects the client in the server if you're messing with a hash or a CRC you will immediately see something not work the way it's supposed to and that's a very good way to identify that again I talk about that more in depth uh in in the longer program next question does that answer your question sir oh yeah that's great thank you well just a thought I had when you were talking about this especially like for the you know for these medical device things um

you know the first thought in my mind from a defensive standpoint it'd be really helpful if they provided you if they provided like the uh if they were able to provide um these templates for for these proprietary messages and and my argument would be you know you go you you have to go of course they would have to consider this during development but you could convince them that this is a good idea because then this will make it easier for the the people trying to defend the hospital networks against robe any you know against attack um has has there been any thought or has this been like discussed within at least with within industry I I think it's it's a

very wellknown uh problems solution space I I think uh and if you look now especially in the medical industry you're starting to see some of them pull away from proprietary PS or what they're doing is they're doing a better job implementing encryption on top of them okay so it's it's the product is still there but it's sent through an encrypted t the the the challenge that you're faced especially with iotm or medical critical infrastructure is a lot of this is rooted in 20 30 years ago right and so it's not new design it's design that's been here for a long time when security was not the Forefront or we didn't have these concept of the attacks that we

have now or sophistication and changing that is a multi- deade problem no I I I understand completely what you talk about like as an example like people who find vulnerability ities and uh in the baseband firmware and modems you know they they're they're always wondering well why why can't they just fix this and it's like well because if they make any changes then they typically the the the the modem providers typically have to go through recertification with the carriers and the medical industry is very similar you make a change well you got yeah it's not just that but then you have backwards compatibility issues as well you know when I was working on some of the medical devices in order to fix

the flaw that was discovered they would have had to replace all of the devices in the hospital yes well if you go tell a hospital that they need to go replace all of their infusion pumps that's like you know a 10 million $25 million Endeavor and that's not necessarily then you have to start looking at okay is there better ways anyway thank you yes okay I think being told we're at time here so thank you for your time and happy to take any questions outside [Applause]