You've been with the Packet Hacking Village and the Speaker Workshop before.
As I said, this is the fifth anniversary of the Speaker Workshop at the Packet Hacking Village.
And I think you've spoken at all five.
I think you've spoken at all five.
I know you were out missing once.
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 a 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 hiding,
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 Defensive 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,
I've been focusing on Stego as well for quite some time,
I think about 17 or 18 years.
I 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 got out of a talk that we did in track four
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 DEF CON 12,
released a tool called StegSpy,
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 Steganography?
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,
data rather than looking for the hidden data itself. So we can go ahead and jump into it.
I think Chet has the first part. Thanks, Mike. So back in 1997 when we were starting to really
get into looking at steganography 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 5th, 1997.
So Cinco de Mayo, 1997. Can't forget that date. There's a link here in the brief that you can
go get the actual article that Craig wrote. 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. Really interesting guy. So anyway, the concept was, it really intrigued me
because we were looking at steganography from the perspective of hiding information in 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 corporate communication actually is. It's any
communication channel that can be exploited by a process to transfer information in a manner that
violates the system 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 steganography, encryption is
all about keeping information private so that only those that contain the key, hold the keys, can
actually decipher the information unless you have a lot of time in big computers, right? The
purpose behind steganography is to hide the mere existence of the message, right? So very
different concept of what we're trying to do in steganography. It's a very different concept than the
steganography 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, most
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 that's a
way that I can 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 acknowledgment 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 a little bit more on the TCPIP packet header and the
same thing that 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, right? 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, you leak information and then you send it to the TCPIP header. So
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's the identification field. So the identification field in the IP
header is basically used to provide information to the packet. 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. So 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 really
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 Mike could have a constant that we're going to divide by. So I
can basically put a number, divide it 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.
Okay? Real simple. You've got to do a lot of these in order to be able to pass a message, or you
could have some kind of code book for this. If we want to do this with a twist, I could use a
code book, right? 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 used in
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 in the 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 acknowledgment 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.
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 could encode anything we want into that initial sequence
number. So if I take that to the next level and I extract the
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
figure 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 code book so he knows what it's going to be. In this case,
it will 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 it 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 we're going to talk about today. The third
method is the method 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. Okay? 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 SYN 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, 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 the IP address of the sender and the
response as 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 SYN
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. Okay? Just as I kind of
talked about. Included.
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's going to
know where that request came from and where the response is.
Where it went to. Right? 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 every time. Right? I could pick 1,000 servers out on
the internet and send each one a single SYN packet and have the
response go to the client. So now I've got these 1,000 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 1,000 different
servers if I want to send a message that's of the
local server. So now I can hide or mask the identity of the
link 1,000 bytes. I've just got to pick 1,000 different
servers to do this. And I did this with Google and Amazon at a
bunch of places last week just to see if they would actually
recognize the fact that I bounced this SYN packet off it
and received it on this other client. 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. And we're going to talk about
some of the things that Craig had defined 20 years ago. And we're
no 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.
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
Chet came up with this idea, I was like, well, I'm going to do
this. And I was like, well, I think it's a good 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
complementary to what you're going to, what he's 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 and lack of fundamental security across IOT, both within
the devices as well as how they communicate and how it's
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 or
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, you know, UPMP has been
around for a long time as well, right? Microsoft has been around
for numerous years. Yet again, we're probably not any better
off with UPMP than we were when Microsoft first released it,
right? And now it's been adopted as part of IOT. And in
addition to that, it also has been adopted as part of the
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. MSerch, for
example, is a very popular service. It's a very popular
service. For example, is a discovery packet. It 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 a notification packet? Well, the
features and characteristics of these packets. 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 MSerch messages. The interesting thing is
that supported not only an 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, there are 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 you know in playing around with
all these different fields this was almost like a free form
field. You could put a different URL in here that might
point to command and control. First of all you could put a
different URL in here. 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 cyphered 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, no issues whatsoever. And
certainly could be a method by 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 you know if you're communicating this
covertly and it does harbor a URL that could point to
something benign like a WordPress site or even a link on
social media where an image might reside with hidden content
as well. And this just gives you a little bit more of 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. You can put any kind of content you want in this field
to whatever extent you want. I don't know the size limitations
of that yet. I'm just as sure about the dimensions of what it
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 router 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 and to an intended
recipient. And in addition, a lot of these fields could be
exploited in there.
So in the diagram here, if you had 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 secure
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
two packets. So in terms of wireless, there's a variety of
beacon packets, probe response, probe request, a variety of
different types of packets that are available online. Perhaps,
packets that are used within that. One of those within the beacon packet is something
called an information element field or information element field, kind of used in exchangeably,
but this field sometimes is leveraged by the vendor. So in a beacon packet, you've got
a number of fields here, right, including the SSID and the BSSID, but you additionally
have this information element field, and that information element field sometimes is used
by the vendor. In there, they may say, hey, you know, 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, you know, mentioned earlier,
if you send multiple packets,
which I did with this with my DDWRT, you can actually have a very extensive message or content
that's split across these beacon packets such that they can 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, you know, by the protocol. It was transmitted.
I sent it from my DDWRT.
I sent it to the IE 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. 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 while although people in the neighboring
airspace would just see a whole bunch of access points all sending 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 or someone on, you know, 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 smart phone, they would detect when you came into the store because they
would be looking for probe requests, for example, from your device, right, 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, you 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. Yep. And there's others too. Yeah. And 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.
All right. 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
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? 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 and do this effectively without, you know, I wanted to do this on my own. So I
thought I'd just say that this is a lot more simply than what people were 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
NoteTella, we've 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 the reason that this is a
problem is obviously these streaming protocols are not as easy to use as they are to communicate. 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, much of the streaming traffic goes unchecked. Again, due to some of the other
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 e-mail and web traffic and those kinds of things. It doesn't focus on, you know,
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 the 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
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. Right? If I
actually encode other information within those, the payload portion, it's going to potentially have
some impact on what you hear. Okay? Does that make sense? So we actually don't really want to do
that. So basically the way this works, you know, in normal situations, it's going to be, you know,
going to be letting Bob and Alice communicate with each other. So we'll have to have a little bit of
time to do it more often. So the way the world has been organized 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 Roland was talking about within this environment?
So let's take a look at this in a little bit different way and assuming I have control of both ends
of this interface. I can say this clearly, I don't have control over this interface. I've just got to
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 unreliable link technology in
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. Give me one second. 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 put, use that entire
payload for whatever content that I want to transfer over
that, over that medium. So now what I do is I do a
different thing. 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,
all 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. Right? 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 the
system 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 a 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 there saying that
we couldn't use this kind of protocol, this streaming
protocol, 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 is it's a little bit more complex
to pull off. Right? So we had to write some significant Python
scripts on both ends 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. We haven't solved that problem. 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? Yeah. Okay.
Cool. So a few other things I was going to mention. You know,
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. 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 and it would be
streaming, really, for anybody, just like in posting an image to
social media or, as Chet mentioned, you know, 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, wait for that
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 it 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, you
know, 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.
Well, Mike and I presented this morning at, 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 and 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-hiding element, whether it's a data
structure for a particular file format. For example, one of the
things on the multimedia side that we discovered was the
ability to hide information within an MP4 file using a
program called TCStack. 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? 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 IBHR is a
company that's been working on the ID3 header for a long time.
And the ID3 header has images associated with it. Whoever built
this structure for the ID3 were certainly audiophiles 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 were put together and 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 ID3
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?
Yeah. Feel free. Question and answer. Assuming that I'm not a Russian
spy, what are some of the consequences?
Yeah, I mean, yeah, see if I can paraphrase it correctly. Yeah,
yeah. Like other than a Russian spy, what would be the, you know,
what, like a practical use case for this, either offensively or
defensively. Yeah. Yeah. So there's a variety of use cases,
right? And we actually covered this, we just announced this
hour ago we did a presentation. You were there, right, 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, and 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 or an IP
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 is
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, there's
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
furthermore in the talk we just did, hey, I've got an MP3, I'm
going to post that to social media, you know, 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, right? Or append data to the end of the file
beyond the end of file marker. So there's a plethora of
different like use cases. Are other groups, agencies, good or
bad, using this for covert communications? You know, I guess
a lot of that's left to you to decide. I think that's a good
way to get off to spy movies, but, you know, there's certainly a
variety of use cases. I don't know, did I miss anything, Chet,
you wanted to add? Okay. All right. Cool. Thanks.
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 Sky Talks 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 and forward packets, you can basically jam those channels
by basically overwriting the data. If information is leaking
out as part of MP3s, 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've 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 the other things that we can do. One 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. 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? I don't know if you want to add to
that. Yeah, the only thing I would add, and I think Chet kind of
hit on this, is in modeling out the network and knowing what's
normal, leveraging that to determine what's anomalistic
that's going on. But that's very difficult to do, but attainable in
today's world, right? So we've spent a lot of time talking about
how this has been an inherent 20-year, probably 30-year problem.
We've been doing it a long time.
We're old. 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, I think there's a number of
different views. One was that the most common view in track
four here at DEF CON was leveraging social media for
covert 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're running around
trying to find ways in which we can detect this stuff, with the
technology we have today, could we simulate that in a way that's
more user-friendly? And I think that's what we're trying to
do. We're trying to simulate 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.
Yeah, the other thing I wanted to say is that, you know, we've
been trying to try to send data to a large number of organizations
Well, the thing that we're trying to do is 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 has just released a bunch of information about the
concern for steganography, which we've been talking to them about
for 10 years. And now they're seeing this as a real problem.
So once the standards bodies realize that the protocols they're
defining the data structures that are coming out
that 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, you know, Mike
and I both being authors, I mean,
it's like DRM doesn't exist.
It's just worthless.
It's not about writing back code anymore.
Right. Right.
We can't blame the vendors
for writing back code.
Because they have a highway
that promotes illicit behavior.
Yeah, and they're
abiding by standards that have
these fundamental flaws in them
so they can hide behind that.
Because they're writing into the standard.
Yep, exactly.
That was rhetorical, yeah.
Any other questions?
Yes.
Yes.
I have a question about your
safe-looking attack.
What is the Bible or
rather just checks that you cannot
use any address
but you can use
all of it.
It might quite be a back address.
Can you use these cards to
communication?
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 and that kind of stuff.
But at the time that the SYN comes in, right,
that is just going to be a lot of trouble.
We responded to and acknowledged unless
that particular IP address has been blocked.
And if you're not abusive, right,
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 this packet
off of in Craig's original,
this is not my design, this was Craig's
original article.
This 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 I've 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
to...
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.
After you've done that.
Exactly right.
But the ISPs typically don't do that, right?
So the question is, I want to find out whether
you're talking about a guy who is in a company
in the Internet trying to steal
as extroverted data from companies.
But then in that case,
the spoof of technology wouldn't work.
Correct.
You would do that.
Right.
But then you mentioned method one, method two,
where you can use IP, IP ID,
or TCP initial signal number.
But some of the firewalls will overwrite them,
will rewrite them.
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.
Right.
They're not always.
Yep.
And so that's a wrap for Chet and Mike.
Chet and Mike, welcome back.
Always a pleasure.
Always a pleasure.