 If you've been with the packet hacking village and the speaker workshop before, as I said, this is the fifth anniversary of a packet hacker of the speaker workshops at the packet hacking village. And I think you've spoken at L5. I know you were out of a lot of missing wands. Like an old friend of ours. And you've given quite a few talks. And so it feels for me, it just feels like for me, not only the annual tradition to come here to DEF CON and the packet hacking village, but also to give an introduction to both Chet Hosmer and Mike Grego. Thanks, Ming. Thanks for having us. I'm going to let Chet kick things off. Great. Thanks, Mike. Hey, welcome, everybody. We're going to talk about covert TCP with the twist today, give you a little history about this, which is really kind of interesting because we've come 20 years from the history that I'm going to talk about, and we're no better off than we were 20 years ago. So hopefully we can work together to correct that problem. Can you guys hear me okay in the back? Everything good? Okay. No? How about that? Yeah, that better? All right, good. So anyway, welcome. Mike and I have done this talk together, similar talks together for quite some time, so hopefully you guys will enjoy this. Just a quick introduction. Mike will do one for him as well. We've been working on the area of secondography and data hiring I have for over 20 years now, before anybody even knew what it was. And was working with the Air Force Research Lab back in the mid-1990s. And there were two groups at the Air Force Research Lab. There was the Offensive Information Warfare Branch and the Defense of Information Warfare Branch. I worked on the defensive side, and we first started looking at secondography and data hiding. My first course of action was to go steal the best guy that was on the offensive side and have him come and work for us on the defensive side. And really start to look at how we're going to actually detect, disrupt this kind of activity that's out there. And since then, Mike and I wrote the book Data Hiding a couple years ago together. Mike kicked it off and brought me into that so we could actually share the book, and it's been really, really popular out there as well. And since then, I've written several, and Mike has written several as well. So I also teach in the cybersecurity graduate program at Utica College, and I teach in the digital forensic graduate program at Champlain College. So if any of those folks, and sometimes there's folks in the audience from my classes, if you are welcome from that perspective. Let me turn it over to Mike to have him introduce himself, and then we'll kick this off. Awesome, thanks, Chet. So my background, while not nearly as many years as Chet, been focusing on Stego as well for quite some time, I think about 17 or 18 years, was really inspired by it kind of organically and soon after had actually met Chet. And we've shared research and ideas ever since then and collaborate quite a bit. Currently work for a company now, 802 Secure, we focus on IoT security. And so a lot of the current testing involves an IoT lab where we do a lot of analysis, reverse engineering, and some of that will be incorporated in what we're covering today. Furthermore, along the Stego front, just out of a talk that we did in Track 4 on deep neural networks for social Stego, so leveraging social media for covert communications, as well as ML for automating that from an offensive ethical standpoint. And then something else, having spoken at DEFCON 12, released a tool called Steg Spy, whereby the idea behind it was to kind of take a little bit of a different approach to Steg Analysis in identifying hidden content by saying, well, with all the really cool things that even Chet and his company were doing at the time, is there a way you can go about fingerprinting the actual applications that are being used to perform this Stegrenography? And having mapped that and fingerprinted that, understanding what kind of fingerprints or remnants that they would leave behind in the image and look more for images that had evidence of a tool being used to hide the data rather than looking for the hidden data itself. All right, so we can go ahead and jump into it. I think Chet has the first part. Great. Thanks, Mike. So back in 1997, when we were starting to really get into looking at Stegrenography and how it was going to affect, I read this article written by Craig Rowland in first Monday, the Hacker publication. It was published on May 5, 1997, so single to my own 1997. I can't forget that date. There's a link here in the brief that you can go get the actual article that Craig wrote and I want to kind of walk you through what he talked about then. Is Craig in the room, by the way? Did he come? No. Too bad. Anyway, I met him once a long time ago, a really interesting guy. So anyway, the concept was it really intrigued me because we were looking at Stegrenography from the perspective of hiding information images, audio files, videos, that kind of thing. And what Craig did was he kind of broke the ground in looking at this from a covert communication perspective and actually being able to hide information in protocol streams. And we're going to talk about that today. So that's kind of just the kickoff of this. So just kind of a quick definition that came out of the 1985 Orange Book from the Department of Defense to define what covert communication actually is. It's any communication channel that can be exploited by a process to transfer information in a manner that violates this security policy. So basically the concept is I want to be able to leak information out of the organization. I want to be able to communicate with people without anybody knowing. So again, just to find the difference between encryption and Stegrenography, encryption is all about keeping information private so that only those that hold the keys can actually decipher the information unless you have a lot of time in big computers, right? The purpose behind Stegrenography is to hide the mere existence of the message, right? So a very different concept of what we're trying to do in Stegrenography versus what we're doing in encryption, right? Kind of much more dangerous from that perspective and you can kind of see the idea behind that. So in Craig's original article, he basically had three different methods that he actually defined on how we could do this using the TCPIP protocol. How could we actually hide information in these protocols? And as I mentioned at the outset of this, most data structures, most protocols, most file structures have this limitation where there is no concept of being able to prevent the data structure or the protocol from carrying illicit information. It's not part of the thought process of those folks that are building that. Last year Mike and I spoke about the MP3 ID3 header and the vast amount of information that I can hide in that and transfer data and we showed how you could actually post music on popular websites and actually have that information included in the download. So I could covertly communicate that way. So this has kind of come a long way but let's talk about the three different methods that Craig had defined. The first couple are fairly simple but kind of interesting and they still stick today. I have a lot of friends that work for defense contractors, big banks and that kind of stuff and I do this to them all the time to see if their defenses can detect any of this and they never can. So the first thing is this is what the TCPIP packet header looks like and by the way, everything I'm going to talk about works with IPv4 and IPv6 so there's no difference. The same vulnerability exists. We didn't fix any of these problems when we went to the later version of IP. So we're going to talk about the identification field within the IP header. We're going to talk about the sequence numbers and the acknowledgement numbers that exist in the TCP packet for structure. Mike's going to talk a lot about wireless and a bunch of other stuff as well but I'm going to focus just on what Craig talked about originally so you can kind of see how we can actually use that same technique today in order to leak information. So the basic concept is pretty simple. We want to be able to use fields within the TCPIP header to convey information and since these are standard protocols that you have to obey, these fields must be there. This information has to be part of the header in order to be able to send this out whether it's in the IP header or whether it's in the TCP header. So basically looking at this information, we're looking for areas within those headers where we could actually hide information within those. So let's take a look at that. The first one we're going to look at is the identification field. So the identification field in the IP header is specifically used so that if, let's say that I'm transmitting a packet, an IP packet, and it has to be broken down, right, it has to actually be fragmented so that packet would have to be fragmented. So the ID field is there so that if the packet becomes fragmented we can put the pieces of the packet back together. The ID field is used to basically provide a number so we know the sequence of the packet as if it was broken down. Today this rarely happens, especially with smaller packets. They're typically not fragmented so we can actually use that field as is to put any information in it that we want. So if I'm the sender of this particular packet, I can replace the identification field with data. For example, I might put a value, it's a 16-bit number so I could put a value in there and then you could have a, Mike could have a constant that we're going to divide by so I can basically put a number divided by a constant and then Mike will get the letter that I'm going to transfer in that particular field. So that's the first example. Really simple, just using the identification field in order to be able to do that. So as an example, this is what it would look like. Basically I'm going to send this identification field that is here, the number you can see is 17-152 is what I put in there. If I have a constant of 256, it gives me the number 67. So converting 67 from ASCII to a letter is the letter C. So by just basically putting that value in the identification field I've transferred the letter C to Mike. He's going to receive the message. Real simple, you've got to do a lot of these in order to be able to pass the message. If we want to do this with a twist, I could use a code book. I could have standard messages that I want to communicate and basically it could just be an index into that standard message. So now I can from within an organization I can basically push out information by just encoding information in that single field that I want to do it. So this is the simplest form that Craig talked about. So let's move to the next one. This is the manipulation of the initial sequence number. This is one that probably has been most talked about. I actually think the third method is really more interesting. But what this is is that whenever we establish a TCP connection we have to basically provide an initial sequence number. This kind of goes back into history with the Robert Morris attack where the initial sequence number wasn't random. So in this case the initiator of the communication which typically is the client is going to define this initial sequence number so that the server can respond with an acknowledgement of that sequence number and now the sequence numbers will increment by one for every packet. But since we get to choose what that sequence number is the same as we could choose whatever we wanted to put in the identification field we can actually use that value in order to be able to convey information in a similar manner that we did. Now remember this is a bigger field so this is a 32-bit number so we could actually transmit a byte, a word, a double word, a quad word of information with every time we establish a connection to a server. So that's how this one works. So basically the way this works if I just take an example packet this is what that TCP header would look like if I extract the information from the header we can see what the initial sequence number looks like down here. Again it's a very large number 32 bits in length that we can encode anything we want into that initial sequence number. So if I take that to the next level and I extract that sequence number and again in this case I've chosen a divisor something that I want to divide that number by to actually convey the information. Now this looks really simple because once you've figured this out you can see what the message is but clearly what we do is change the divisor for every sequence number that we send. So that you don't know what it's going to be Mike has the codebook so he knows what it's going to be in this case it'll convert that to the letter H by dividing those two numbers. So all we have to do ahead of time is exchange the fact that I want to be able to communicate this and all we have to do is have what the divisor or the method is to communicate. So that's pretty cool. Very similar to the identification field we do this. Do we defend against this today? No, nobody looks at the initial sequence number in order to be able to do this. The third method is really interesting because you can actually hide the identity of the sender and of the receiver. So let's talk about the third method which I think is the most interesting one that Craig defined. And I just did an experiment with this last week to see if I could actually do this off popular servers and it works really good. So method three the concept is that I want to expand on method two and actually on method one a little bit and what we're going to do is we're going to have the I want these two clients to be able to communicate with each other. And I want them to be able to do this fairly anonymously so I don't know who the sender or the receiver is of the packets that we're going to exchange. So this is a little bit more difficult to do and we're going to use this method called the bounce method. So what we're going to do is we're going to send a request to a server basically that same packet that we talked about in the previous example. But I'm going to spoof the IP address of the sender and I'm going to have the IP address be of where I really want the response to go. Okay? So I've got these two people that want to communicate. I've got the sender and the receiver and the sender knows the IP address of the receiver. So when it basically sends the packet to the first server it's going to bounce off that server and it's going to go to the second client because I've spoofed that IP address. The second client's not going to respond to that but he has the initial sequence number because it comes as the acknowledgement from the server comes in that packet and since it does he has that piece of data. So now you might say well that's kind of interesting so let's take a look at how this actually works. So basically what happens is client one sends the send packet to let's say a server out there on the internet someplace with the encoded information in the initial sequence number but because it spoofed the IP address of the sender the response or the acknowledgement is actually going to go to client number two just as I kind of talked about including the encoded initial sequence number which again using the method that I talked about earlier you can just divide that and get the actual data out of that. You can use multiple methods in making that happen. So now we've actually sent information from client one to client two using that method. Now we've sort of masked who the sender and the receiver is but you might say well wait a minute the server is going to know where that request came from and where the response went to. Not going to know the sender but it's going to know where the response is supposed to go so it could track that. Well you don't have to use the same server right? I could pick a thousand servers out on the internet and send each one a single send packet and have the response go to the client. So now I've got these thousand servers out there that are going to respond to this and this happens all the time the packet's going to be dropped but now I can bounce this off thousands of servers so that now I can't even identify who the recipient is because the recipient is different for each of the servers that we have. Does that make sense? Everybody kind of understand it? So basically the bounce method really kind of extends this attack to the level where now I can really hide the identity of the sender which I could always do even if it was only to one server but now I can hide or mask the identity of the receiver of the message because it's going to come from a thousand different servers if I want to send a message that's of the link thousand bytes I've just got to pick a thousand different servers to do this. And I did this with Google and Amazon last week just to see if they would actually recognize the fact that I bounced this send packet off and it received it on its other client and it works perfectly, nobody cares. Right, so 20 years and a few months later the methods that Craig had defined really work today. We haven't improved the design of our protocols. We haven't secured either IP or TCP in order to be able to prevent this from happening. And we can communicate small pieces of information or large pieces of information depending on how sophisticated we are. We'll talk about some more sophisticated pieces of this as we go forward in the talk. I'm going to talk about a couple and Mike will talk about some as well. But to just kind of set the stage that we've gone 20 years and this has been a very public information about the methods that Craig had defined 20 years ago and we're better off because we tend to be chasing the shiny object. We don't actually focus on fundamentals of our protocols, of our data structures, of our file structures in order to prevent this kind of leakage of information. We tend to be focused on things that are kind of outside. What is the latest attack that we have? What is the thing that's going on? And we don't go back and look at the fundamentals that we're trying to protect against in order to do this. So just, that's my soapbox for the day. So I'm going to turn this back over to Mike who's going to talk about UDP and IoT and how those didn't get any better either. Even though we were able to create these brand new protocols and brand new techniques in order to communicate with these devices, we actually may be worse off, right? Great, thanks Chet. So as of late I've been doing a lot of testing and modeling in an IoT lab I have at home and when I came up with this idea for this talk I said gee, you know, I think that could be a good launch pad and make a nice addition that would be very complimentary to what you're going to, what he was speaking about in terms of TCP and reveal this from a UDP standpoint. In terms of IoT we've seen numerous articles about the inherent lack of fundamental security across IoT both within the devices as well as how they communicate and to that end a lot of these devices support UPMP or more specifically SSDP and this allows you to have an app that discovers a new device on the network maybe even configure it even allow devices to speak to one another machine to machine if you will and how a lot of this communication is performed is believed to be maintained locally on the network through use of multicast broadcasted packets on the local network so I said UPMP's been around for a long time as well Microsoft been around for numerous years yet again we're probably not any better off with UPMP than we were when Microsoft first released it and now it's been adopted as part of IoT and in addition to that it's been extended into IPv6 with all the backward compatibilities as well but in terms of what I like to call stupid simple discovery protocol or really simple service discovery protocol being a component of UPMP you have a variety of packets that are leveraged in terms of identifying these devices on the network or those devices advertising themselves on the network so everybody can find one another M-search for example is a discovery packet can be sent by an app, can be sent by a device to go out there and discover the IoT devices and then furthermore there's another type of packet called a notify packet typically devices who have employed this SSDP type capability will wake up from time to time and typically on a regular frequency advertise themselves peeling the onion back a little bit further what are the characteristics of these packets well there is what's called a ULA OPT field this is for unique local addresses and site-routable but specifically the OPT value within that carries a URL which is an optional field I believe hence the OPT label within the packets but in addition is used within both notify and M-search messages the second thing is that supported not only in IPv4 but IPv6 for backward compatibility so I said to what extent could this be used for communicating covertly is this a free form field is this a field that is used by the vendor of the IoT device to basically define characteristics about the actual IoT device so we've got the IP address serial numbers other things that are embedded within these types of packets but in addition to that this OPT field usually carries a standard URL that really points back to the schema or more importantly the information about UPNP so in the spec there's kind of limited information about it but I said in playing around with all these different fields this was almost like a free form field you could put a different URL in here and it would point to command and control furthermore it doesn't even have to be a URL so you can go in here and put any kind of text any type of content clear text or ciphered within this field so that's exactly what I did to see to what extent this would be communicated across the network and successfully received by the actual intended recipient or furthermore if it's broadcasted to all the devices on the network and it worked completely successfully whatsoever and certainly could be a method of that which you could communicate covertly using UDP in what would arguably maybe be a different technique but similar to what you're trying to accomplish with TCP so it also makes for a great dead drop so you could just if you're communicating this covertly and it does harbor a URL that could point to something benign like a WordPress site content as well and this just gives you kind of a a zoomed in view of this actual field that comprises this actual packet that's part of SSDP so again designed to incorporate a URL of your choice typically used by the vendor who creates that particular IoT device but as I mentioned doesn't have to be a URL put any kind of content you want in this field to whatever extent you want you don't have these limitations of that yet but nonetheless you can certainly hide a variety of content in here if you wanted to further obfuscate that you could of course go ahead and cipher that as well and well although this is designed for sort of the local network what we've seen in terms of IoT with Mirai and even other variants that predate Mirai and their infections of IoT devices is that this coming in from the internet would potentially target your or your router with your firewall and furthermore would those packets be allowed into the internal network and thus with this type of thing could those packets escape out or have a communication with the actual router itself so theoretically the router itself could actually pass this on to the internet into an intended recipient and in addition a lot of these fields could be exploited in that manner so in the diagram here we've got a two-way communication between two different IoT devices or an individual to an IoT device and vice versa you could send this hidden content in what appears to be normal discovery protocol information leveraging SSDP that's actually harboring hidden content within the actual packet probably undetected by any of the local IDS MPS or other features you may have for your security products on the actual network and then receive this on the other end to actually reveal the hidden message the other area that I did a lot of testing with and this is actually covered in our book has to do with Wi-Fi and layer 2 packets so in terms of wireless there's a variety of beacon packets probe response probe requests a variety of different types of packets that are used within that one of those within the beacon packet is something called an information element field kind of used in exchange but this field sometimes is leveraged by the vendor so in a beacon packet you've got a number of fields here including the SSID and the BSID but you additionally have this information element field and that information element field sometimes is used by the vendor and they may say hey I'm an Aruba, I'm a Motorola, I'm a Cisco but many times this field actually goes unused and it can hold up to 256 bytes of actual data so if I wanted to leverage this to hide information that's a decent amount of information for actually hiding text and as Chet mentioned earlier if you send multiple packets which I did with this with my DDWRT you can actually have a massive message or content that's split across these beacon packets such that they could be put together on the receiving end to reveal the hidden content or the message so I went ahead and did that and hid a message within the IE field it totally was accepted by the protocol, it was transmitted I sent it from my DDWRT device and monitored this and also determined that a laptop I had was receiving these packets and that you could communicate this back and forth I was using Scapi Scapi, yep, automated with Python, yep, so and so what would be the application of this? If I modified a beacon packet and inserted a message into the IE field even if I used something fundamental like Air Replay to replay a PCAP file or I automated it in Scapi I could communicate covert messages over enemy lines for example and although people in the neighboring airspace would just see a whole bunch of access points all send in beacon packets how would you distinguish that out of, you know, 10, 50, 100 access points seen in the local airspace that one of these is communicating covertly and therefore over you know enemy lines or to a different building the other side of the coffee shop for that matter provides a really covert way of doing that versus actually using a wireless ad hoc network for example in which a Russian spy was actually caught using that technique and as I mentioned I prototyped this and configured it within Scapi so that you could run this using Python and essentially I called this Wi-Fi stego stuffing the reason I called it that was back a number of years back Microsoft had done a bunch of research around beacon stuffing I believe the intent behind it was if you walked into a store and you had your Wi-Fi enabled on your smartphone they would detect when you came into the store because they would be looking for probe requests for example from your device to connect to networks that you had previously used but in gathering that information they could actually distinguish that if you had their store app on the device that I see your device you have the app associated to this particular MAC address let's say for your Wi-Fi I know you're in the store I'm going to respond with a beacon packet stuffed with a coupon that's going to flag it in the app and give you a one time use coupon was sort of like what they were looking to do at that time yeah exactly I didn't want to mention any by name but yes exactly and there's others too so it's kind of exploiting that method in a different way but more for covert communications essentially so in terms of beacon stuffing I said I'll call it Wi-Fi stego stuffing instead and with that I'll turn it back over to chat thanks Mike so let's take this to kind of a different level a number of years ago we started to take a look at how we would hide data within streaming protocols and especially things like audio streams VoIP streams that kind of stuff to see if we could actually use that as a method to be able to leak information out and to be absolutely honest it's really a pain in the neck and part of the reason is that those packets that are part of either the VoIP stream or a media stream they're encoded they use different encoding methods there's a very small amount of information in every packet right it's not large it's very brief it can be lost because it's unreliable right and if you lose a couple packets no big deal you can still hear the audio just fine and that kind of thing so it didn't seem at least the folks that we were talking to didn't believe that it was a viable method to be able to use in order to be able to communicate information using those streaming protocols by hiding information by modifying the payload section of those packets okay it sort of makes sense just kind of a complicated thing to actually do well I wasn't done I was certain there was a way to actually do this to do this effectively without you know I wanted to do this a lot more simply than I was talking about so obviously one of the problems with covert communication over these channels is there are just many different protocols we talked about TCP and UDP but then we've got RTP and we've got Notella we got VoIP we've got RTSP and so on and so forth there's all of these different protocols that are available to communicate streaming information so streaming protocols are ubiquitous and most organizations don't prevent people from being able to use these protocols to stream music over their networks and understandably their employees want to be able to listen to Pandora while they're at work right so the sheer volume of the streaming packets flowing in and out of an organization even if it's allowed even if it's VoIP that's being used can be enormous so how do you actually monitor this other than encryption and how does that affect again due to several factors that I've kind of mentioned the complexity of the encoding method the large number of packets the relatively small size of each packet because you want these packets to be really small at least the content portion so if you do lose some information it won't affect the actual experience of the folks that are listening to the streaming data and obviously today from a leakage perspective if you look at data leak protection technology that's out there it almost exclusively focuses on email and web traffic and those kinds of things it doesn't focus on streaming data that's coming from media so let's talk about how Bob and Alice might pull this off and again why it's complicated so when Alice wants to communicate with Bob and they want to basically carry out this streaming protocol we have these packets that are going to go across and the packets have a header as I mentioned that's pretty standardized it is standardized and then they have the payload so again most of the focus up to this point has been on the payload portion of how to encode information in the payload to be able to communicate it over there's a couple of problems besides the fact that it's complicated to include things within this encoding method it's going to mess up the sound of the media if I actually encode other information within those the payload portion it's going to potentially have some impact on what you hear does that make sense I actually don't really want to do that so basically the way this works in normal situations is each of the packets contain a portion of a message that we want to communicate between Bob and Alice so the question is how do we actually pull this off without getting into all the messy stuff that I talked about and kind of extending onto the core concepts behind what Craig Rowland was talking about within this environment so let's take a look at this in a little bit different way and assuming that I have control of both ends of this interface I could extract a packet out and what I want to be able to do is instead of letting all the packets flow I want to pull one out and just delay it so remember on the other end these are going to come in in a sequence and have to be reassembled remember this is fake technology and all of these protocols it's not like TCP so basically they're going to come in potentially out of order there's going to be packets missing so I'm going to intentionally pull out one of the packets and not have it go through and what we're going to do let me pull this all up so I can see it because it's a little bit out of sequence so the concept is if I extract this packet out of the stream and then I reinsert it later what's going to happen when it gets since it's out of sequence and it's quite delayed what's going to happen with the normal music player on the other end it's going to throw the packet away and it's going to throw the packet away because in the stream of things it's already compensated for the fact that the packet is missing so it's not going to have any impact on what we hear but I can put anything I want now in that payload because I know it's not going to actually play music so I can use that entire payload for whatever content that I want to transfer over that medium so now what I do is I take the message that I want and I start to break it up into packets that I'm delaying and actually sending them over in that way so all I do is end up with packets that are delayed so on the other end all Bob has to do is extract the delayed packets so if Bob is watching the network he has to do is basically say wait but this packet is way delayed I'm going to pull that out and I know it has content in it that was meant for me and it's not going to affect wherever that stream was going to because it's going to have thrown that packet away already and not going to use it in order to play the music or communicate the voice so it will have no impact on what the user was so I can be man in the middle here in order to be able to pull these packets out insert what I want and have them be sent across the wire in this fashion so the advantages of this approach again remember there's a lot of naysayers out saying that we couldn't use this kind of protocol this streaming protocol is in order to convey any meaningful information using stego the advantages are the volume of streaming traffic is enormous most of it is not checked some of the disadvantages of this approach it's a little more complex to pull off right so we had to write some significant python scripts on both end in order to be able to do this but it is easy to do once you actually build that so that normal data loss can corrupt or lose the message content however as we talked about before when you look at things that are in the IP header right they're still going to be there so we can use things like the identification field within the IP header in order to be able to re-sync or provide error correction to the packets that may be lost so even if we do lose packets we can actually recover from that by using other fields within the IP header that are not really used that much or are not necessary in order to carry this out so this is an example where taking Craig's original work and looking at first of all we haven't solved that problem either but taking it to the next level with all of the different protocols and formats and data structures that we have we can actually exploit this today to leak information out and we're not checking it unless you're a very sophisticated organization looking at this you're not going to be detecting this within your environment and I'm going to turn it back over to Mike yeah so that was actually the last slide right okay cool so a few other things I was going to mention last year when we presented we had explored mp3s and the id3 headers and the type of content that could be hidden in that how you could identify that from a forensic perspective and one of the interesting things we actually stumbled upon during that testing was in modifying an mp3 and hiding some content in it started to upload it to various music services and one of those was a streaming music service a very popular one a very popular one yes and in doing so had accidentally discovered that if you had say like a musician type of account that you can anybody I believe can actually create you can upload your music to create a band or a channel right that people could bring up on their streaming music player or app for that matter and listen to it playing back and what was kind of interesting was in doing this found that you could upload that music and it would be playing it would be streaming really for anybody just like in a posting an image to social media or as Chet mentioned over the network but only the intended recipient would know it was out there so bottom line if you were the intended recipient you would go to that band you would listen to the streaming music and within Chrome on a PC you can actually download that mp3 and that mp3 would contain that covert message and we actually tested that and actually worked so just something else to think about too so in terms of like additional research I'm doing more research on some of the other protocols aside from SSDP UPMP to see what other fields can be used for hiding content and communicating that and I don't know Chet I know you're doing additional research I don't know if you wanted to comment on anything else Mike and I presented this morning in SkyTalks and we talked briefly about some of the other fields within these protocols that are vulnerable we talked about time to live we talked about some other fields within those protocols but right now what we're doing is looking at a variety of protocols that are available with IOT devices looking at how those could be exploited and those special protocols that are being developed there in order to be able to do that our real reason for presenting this however is for us to really think about how we actually do this better right we tend to take this for granted and we don't consider the data hiding elements of whether it's a protocol which we're talking about today whether it's a data structure for a particular file format for example for things on the multimedia side that we discovered was the ability to hide information within an mp4 file using a program called tcsteg and that actually includes a truecrypt volume right within the movie so now I can actually play the movie it plays perfectly but if I bring that up in truecrypt I can actually extract the hidden content and actually mount it as a volume so all of these data structures have these traditional vulnerabilities built into them because I guess just nobody cares right but so I'm trying to kind of encourage you guys to care so in the graduate programs that I teach in we kind of are looking at ways that we could actually secure these protocols and secure these file structures such that they can't be manipulated as Mike mentioned when we talked about the id3 header of mp3 many of you may know but the id3 header has images associated with it whoever built this structure for the id3 were certainly audio files that were interested in including all kinds of information in the id3 header of an mp3 which is great it's artist information it's information about the publisher it's information about the tracks and how they're put together in images of the band and the singers and all of that kind of information is part of the header but that means that there are images contained within the mp3 right so you've seen this in your car right you play a song within the car and the image of the artist pops up on your dash screen you can put as many of those as you want in the id3 header there's no limit to that so now I can actually put 20 or 30 images in there I can put the lyrics of the song I can synchronize the lyrics in there but I can also hide whatever I want in those images that are there so again the general concept that we're talking about is the fact that these protocols and these data structures have no security in them to prevent the hiding of information so that's kind of what we're trying to encourage you to think about and I guess with that we'd love to hear questions, comments and I guess you should come up to the mic if you're going to do that right? I mean, yeah let's see if I can paraphrase it correctly like other than a Russian spy what would be the what like a practical use case for this either offensively or defensively yeah so there's a variety of use cases we actually covered this just an hour ago we did a presentation you were there on doing this on social media there's a lot of different use cases so aside from a Russian spy whether it be a dead drop or covert communications it could be used for data exfiltration within a corporation or an enterprise or an organization and in addition to that we've seen with things like hammer toss and others where it can be an operation shady rat for that matter where it can be used for pointing to a specific URL where an image resides and within that image is hidden like updated CNC information such as a different URL address to allow the malware to update itself by occasionally going to what appears to be a very benign location like WordPress downloading an image that is just of a cat and again looking very benign but again contained within all of this infrastructure for updating the CNC and leveraging that to further like exfiltrate information the flip side of this also is while we look for areas in which we can hide this information in a lot of metadata fields as Chet alluded to with MP3s and the ID3 headers we explored that last year and there was a plethora of different ways in which you could hide information and then furthermore in the talk we just did hey I've got an MP3 I'm going to post that to social media and leave that as a dead drop for somebody else and rather than actually change anything for the audio or the MP3 itself but rather the JPEG within the MP3 that displays on your MP3 player hide the data there instead or append data to the end of the file a plethora of different use cases are other groups, agencies, good or bad using this for covert communications I guess a lot of that is left to spy movies but there is certainly a variety of use cases I don't know did I miss anything Chet you wanted to add? So currently while there are no security around the abuse of these protocols can an organization use its firewall to monitor the egress of these protocols and drop these packets? Yeah I'll let Chet take that one first Yeah there's two things that you can do one is you can jam the protocols so I talked earlier today at the SkyTalks talking about embedding information in the time to live field the upper bits that are never used so if you're there if you have a way to store in forward packets you can basically jam those channels by basically overwriting the data if information is leaking out as part of MP3's I can re-encode it if it's a JPEG I can re-encode the JPEG I mean obviously this is what Facebook and those do when you post an image to Facebook it eliminates the geotag and the header information of the JPEG but it also actually re-encodes the image so if there was something hidden in it it's supposed to wipe it out now those algorithms are not perfect and we figured out ways around that but nonetheless at least it's an attempt so one of the most effective ways is to jam those protocols if you think that's happening the other thing to do is to be able to monitor those behaviors we talked about the initial sequence numbers we talked about some of those aspects and you can if you're looking for that carefully you can actually have a sensor that would look at that specific information and then be able to detect anomalies within the behavior of those protocols that we would not normally see for example information hidden in the identification field in initial sequence numbers that don't appear to be random so those kinds of things we can detect but the question is is anybody looking from that perspective yeah the only thing I would add and I think Chuck kind of hit on this is you know in modeling out the network and knowing what's normal leveraging that to determine what's anomalistic that's going on right but that's very difficult to do but attainable in today's world right so so we've spent a lot of time talking about how this this has been an inherent 20 year probably 30 year problem we've been doing it a long time we're all so do we fix the problem or do we continue to let it go and if we fix it is it at the vendor level is it at the protocol federal regulation level yeah so I think there's a number of different viewpoints I'll hit on one or two and then I know Chet's very passionate about this one too what we just presented a little while ago in track four here at DEF CON was leveraging social media for COVID communications but further automating that or testing it in an ethical way but from an offensive standpoint and automating it using machine learning the intent behind that was to say while we run around trying to find ways in which we can detect this stuff with the technology we have today we can emulate it from an offensive standpoint and leverage ML and neural nets to actually discover a whole bunch of new ways that humans haven't figured out but the machine can and the result being that here are another 2,000 methods that to our knowledge nobody has used but are ways in which the data could be hidden in what we demonstrated across social media and then leverage that intelligence for better defense the only thing that I would add is that we're trying to inspire encourage the standards bodies to really take a look at this so we keep trying to bring this awareness of this problem and a lot of the big organizations are actually looking at this McAfee actually just released a bunch of information about the concern for secondography which we've been talking to them about for 10 years and now they're actually seeing this as a real problem so once the standards bodies realize that the protocols I mean the data structures that are coming out that our people are using are vulnerable to this hopefully they'll actually start to take steps that will actually redefine those protocols in a way that we can eliminate this I mean part of it starts at even Mike and I both being authors I mean it's like DRM doesn't exist it's just worthless right correct and they're abiding by standards that have these fundamental flaws in them so they can hide behind that right exactly that's okay that was rhetorical yeah any other questions yes yeah no that's a great question and it kind of goes to a talk that we did a couple years ago about actually being able to spoof the MAC address and changing those so obviously it's going to affect the ARP table but at the time that the SIN comes in right it's just going to be responded to and acknowledged unless that particular IP address has been blocked and if you're not abusive if I only use that server one time to basically spoof the IP address it's not going to look like a denial of service attack because I've only sent one packet right to that particular server so the only way to do this is to distribute the effect over thousands or millions of devices that I want to bounce packet off of in Craig's original this is not my design this was Craig's um original article that still stands today I can use that to basically hide the identity of the sender and the receiver by using that method you know judiciously it's like denial of service right one of the things that you want to do with denial of service I want to have millions of IP addresses that have compromised right and have packets sent from all of those IP addresses that I've compromised not from one location right so even if I shut those off I'm still going to have millions that I have to deal with and we obviously deal with that a different way from a denial of service perspective we handle that differently today but nonetheless the issue is exactly what you said it's like nobody's going to basically defend against this because it's a non-issue to that one server getting that one packet from that client that never gets responded to right right right after you've done that exactly right correct correct that's the defense right those firewalls at the egress points will actually rewrite those if they do the same thing with time to live whatever if they see that wrong they'll actually fix it right but they're not implemented very often and so that's our wrap for Chetan Chetan Mike Chetan Mike welcome back always a pleasure