bpa

IP Steganography

25 posts in this topic

Hello everyone at BinRev. This is my first post ever on the forums. I just wanted to say hello, and that I am going to be doing my undergraduate honors thesis on Steganography in IPv4 and IPv6. I haven't really defined the topic completely yet, because I'm just getting started. I chose the topic, not because I know a lot about it, but because I'm interested in it and I really want to learn more about it. I was inspired by the recent DefCon 15 talk entitled "IPv6 is Bad for your Privacy" by Lindqvist. I hope to explore and maybe expand upon the material in that talk. I encourage (and hope for) any comments from anyone who may also be interested in the subject.

P.S. I didn't meet at the BinRev get-together becasue I'm behind on my podcasts, and I didn't hear the one in which Stank talked about it until after the con. I love the podcast, though and the whole DDP project. Keep it going!

-bpa

Edited by bpa
0

Share this post


Link to post
Share on other sites

Just noticed, I spelled 'Steganography' wrong in the subject. For the record, I know how to spell it, correctly. Please ignore that typo. =P

Edit by StankDawg: Fixed subject! you can edit your own post above where it is also misspelled. :roll:

Thank's StankDawg ^

Edited by bpa
0

Share this post


Link to post
Share on other sites

Isn't this essentially the same idea as a "covert channel"?

0

Share this post


Link to post
Share on other sites
Isn't this essentially the same idea as a "covert channel"?

By strict definition, they're basically the same thing, but you'll see the use of the two terms vary. In typical usage, you'll see "covert channel" used to describe a communications channel implemented by manipulating things in a non-obvious manner. Steganography may a way this channel is implemented, but can also apply to methods of hiding things on storage media for later retrieval by the original hider, or even watermarking data in a way that can track whoever's using it and passing it around.

As an example, imagine if I were communicating commands to a system that I had backdoored by encoding them into the low-order bits of images I posted to a image-sharing website, and my backdoor on that system were retrieving those images, extracting the commands, and executing them. I would call that a covert channel, even though it uses steganography to accomplish the goal. If I were hiding data on my own hard drive encoded in images for myself to decode later, when I needed it, then I would simply call that steganography, rather than a covert channel.

"Covert channel" brings in the implication that you're using it to communicate in a stealthy manner. I haven't seen the Defcon talk and I don't know the original poster's intentions, so this may apply to what he's thinking as well.

0

Share this post


Link to post
Share on other sites
Isn't this essentially the same idea as a "covert channel"?

It's very encouraging to see some quick posts to the topic. To answer your question, yes, my intentions are to use IP packets as a covert channel in some manner. Like I said earlier, I haven't really completely defined the topic as of right now. I am thinking about coming up with and/or using some existing methods of accomplishing this, and then possibly coming up with some way to detect when it is being done. I will get back to you as soon as I have met with my advisor a few more times and we have had time to narrow things down to a clearly defined idea. I'm open to suggestions as well.

0

Share this post


Link to post
Share on other sites

I've written a covert channel that worked over HTTP about 4 years ago, and I have looked at a lot of other implementations. I'd say that the one common theme across all covert channels is that it's an arms race that covert channel implementors have a huge advantage in.

Imagine the information that's being trafficked over a covert channel as having a size and some value to the "attacker". Then imagine the "carrier" (the medium you're encoding the data into... say IP traffic, or images) as having a certain volume or size. You can think of the amount of covert data being encoded into a larger carrier as representing the "density" of the covert channel in the carrier. For higher densities, it's easier to detect the presence of a covert channel (with data hidden in images, the image might become "noisier"). However, as long as the attacker doesn't mind having a very low bandwidth to shuffle data through his covert channel, and if there's enough carrier traffic to spread the covert data into over time, the attacker has the luxury of making this density arbitrarily low. If there is some part of the carrier data which has some degree of randomness already (IP sequence numbers, low-order bits of photographic images), and the attacker can encode the covert data in at a low enough density that it does not decreasing the entropy of the carrier by a detectable amount, then it will be nearly impossible for anyone to detect.

0

Share this post


Link to post
Share on other sites
I've written a covert channel that worked over HTTP about 4 years ago, and I have looked at a lot of other implementations. I'd say that the one common theme across all covert channels is that it's an arms race that covert channel implementors have a huge advantage in.

Imagine the information that's being trafficked over a covert channel as having a size and some value to the "attacker". Then imagine the "carrier" (the medium you're encoding the data into... say IP traffic, or images) as having a certain volume or size. You can think of the amount of covert data being encoded into a larger carrier as representing the "density" of the covert channel in the carrier. For higher densities, it's easier to detect the presence of a covert channel (with data hidden in images, the image might become "noisier"). However, as long as the attacker doesn't mind having a very low bandwidth to shuffle data through his covert channel, and if there's enough carrier traffic to spread the covert data into over time, the attacker has the luxury of making this density arbitrarily low. If there is some part of the carrier data which has some degree of randomness already (IP sequence numbers, low-order bits of photographic images), and the attacker can encode the covert data in at a low enough density that it does not decreasing the entropy of the carrier by a detectable amount, then it will be nearly impossible for anyone to detect.

Thank you very much for the extremely informative reply. Thinking in terms of densities and detectable entropy is very helpful. The DefCon talk focused on the idea of there being much more bandwidth for your covert channel when using IPv6. It also talked about how the Stateless Address Autoconfiguration, as the protocol is currently defined, can be used to "cover up" some of this entropy, since it is random anyway in normal use. That's what I understand from it anyway. I plan on reading up on some of the references that author has in the presentation. Maybe I could come up with some sort of way to determine an optimal level of steganography within certain mediums, here IPv4 and IPv6.

0

Share this post


Link to post
Share on other sites
Hello everyone at BinRev. This is my first post ever on the forums. I just wanted to say hello, and that I am going to be doing my undergraduate honors thesis on Steganography in IPv4 and IPv6. I haven't really defined the topic completely yet, because I'm just getting started. I chose the topic, not because I know a lot about it, but because I'm interested in it and I really want to learn more about it. I was inspired by the recent DefCon 15 talk entitled "IPv6 is Bad for your Privacy" by Lindqvist. I hope to explore and maybe expand upon the material in that talk. I encourage (and hope for) any comments from anyone who may also be interested in the subject.

P.S. I didn't meet at the BinRev get-together becasue I'm behind on my podcasts, and I didn't hear the one in which Stank talked about it until after the con. I love the podcast, though and the whole DDP project. Keep it going!

-bpa

While I am mostly interested in listening to this topic for now in a traditional lurking manner, I am curious, what school are you attending?

0

Share this post


Link to post
Share on other sites
While I am mostly interested in listening to this topic for now in a traditional lurking manner, I am curious, what school are you attending?

I'm at the University of Arkansas, in Fayetteville. GO HOGS!

0

Share this post


Link to post
Share on other sites

I'm interested in doing an implementation for use in IPv4 networks. I've got some links posted at http://www.retoros.org/

I would like to create a whole network infrastructure using this. We could develop a kernel module that allows direct access (like eth0, for example). This would enable one to use any application within the covert network (assuming one uses resources only available on the network).

0

Share this post


Link to post
Share on other sites
I'm interested in doing an implementation for use in IPv4 networks. I've got some links posted at http://www.retoros.org/

I would like to create a whole network infrastructure using this. We could develop a kernel module that allows direct access (like eth0, for example). This would enable one to use any application within the covert network (assuming one uses resources only available on the network).

This should be a neat project. You should be able to generate some random data, and then modify or add to it to meet the checksum you want. I've added your blog to my rss reader so I can follow your progress.

0

Share this post


Link to post
Share on other sites

Did you check out |)ruid's talk on real time steno of RDP.... It was fucking great!

The pdf should be on your defcon CD...

0

Share this post


Link to post
Share on other sites
Did you check out |)ruid's talk on real time steno of RDP.... It was fucking great!

The pdf should be on your defcon CD...

I didn't attend that talk, but I do have that particular pdf in my pool of stuff to look over for this project. It did look sweet.

0

Share this post


Link to post
Share on other sites
Videos of Defcon 15 presentations are online now, if you wanted to check that or anything else from DC15 out:

Didn't know that, thanks. I'm glad I didn't spend a ton of money to buy them now.

0

Share this post


Link to post
Share on other sites

I was waiting to start this project because I was working on another project for a friend. For work, I had to install WinXP Pro on my laptop. I backed up all my personal files (including all my code, passwords, etc.). The backup file is corrupt. Looks like I can start on this project sooner, lol.

0

Share this post


Link to post
Share on other sites
I've written a covert channel that worked over HTTP about 4 years ago, and I have looked at a lot of other implementations. I'd say that the one common theme across all covert channels is that it's an arms race that covert channel implementors have a huge advantage in.

Imagine the information that's being trafficked over a covert channel as having a size and some value to the "attacker". Then imagine the "carrier" (the medium you're encoding the data into... say IP traffic, or images) as having a certain volume or size. You can think of the amount of covert data being encoded into a larger carrier as representing the "density" of the covert channel in the carrier. For higher densities, it's easier to detect the presence of a covert channel (with data hidden in images, the image might become "noisier"). However, as long as the attacker doesn't mind having a very low bandwidth to shuffle data through his covert channel, and if there's enough carrier traffic to spread the covert data into over time, the attacker has the luxury of making this density arbitrarily low. If there is some part of the carrier data which has some degree of randomness already (IP sequence numbers, low-order bits of photographic images), and the attacker can encode the covert data in at a low enough density that it does not decreasing the entropy of the carrier by a detectable amount, then it will be nearly impossible for anyone to detect.

This is the first I've heard of IP Stenography, but Steno usually refers to, as you (McGrew) have mentioned, the insertion of bits of data into the "white space" in imagery. It's most notorious claim to fame was when the CIA claimed that terror cells were using child porn newsgroups to spread information, more specifically, that they were using the boards, posting mages with encoded information under the impression that if any arrests were made, they wouldn't discover the actual purpose of the ring anyway. The validity of this claim is widely disputed.

If you're looking to integrate stegonography into IP addresses, you have only a small amount of space to work with. You might consider packet fragmentation. A single permutation per address, all sent, you could get a sentence out in about 10 characters, with 10 addresses, all in the same subnet, same originator. The data would be parsed when all the packets had reached the destination. This is a total stab in the dark, but it's an interesting idea.

The original reason for this post though was to clarily that steganography is the art of hiding in media, this would be obfuscation. You do have the potential to piggy back on data, which I suppose could be seen as evolved stego. I should watch the talk and see what I think.

0

Share this post


Link to post
Share on other sites

the coding of this is over my head, but i think stenography is fascinating. i just wish i had something stealthy worth talking about. if you missed it at defcon druid did a talk on stenography over voip trafic the program he wrote as a proof of concept is called steganrtp (awesome title) you can get it here http://sourceforge.net/projects/steganrtp/ if i remember correctly he found bits in RTP packets specified by the protocol that arent really used for anything, then used them for the covert channel. in any case good luck, and ill be a beta tester if you need one.

0

Share this post


Link to post
Share on other sites
This is the first I've heard of IP Stenography, but Steno usually refers to, as you (McGrew) have mentioned, the insertion of bits of data into the "white space" in imagery. It's most notorious claim to fame was when the CIA claimed that terror cells were using child porn newsgroups to spread information, more specifically, that they were using the boards, posting mages with encoded information under the impression that if any arrests were made, they wouldn't discover the actual purpose of the ring anyway. The validity of this claim is widely disputed.

If you're looking to integrate stegonography into IP addresses, you have only a small amount of space to work with. You might consider packet fragmentation. A single permutation per address, all sent, you could get a sentence out in about 10 characters, with 10 addresses, all in the same subnet, same originator. The data would be parsed when all the packets had reached the destination. This is a total stab in the dark, but it's an interesting idea.

The original reason for this post though was to clarily that steganography is the art of hiding in media, this would be obfuscation. You do have the potential to piggy back on data, which I suppose could be seen as evolved stego. I should watch the talk and see what I think.

Thank you for the suggestions. I'm loving all the input from everyone. Keep it coming. I have decided that I am actually going to be using IPv6 as my covert channel, so the hope is that I will have a considerably larger bandwidth for the channel than IPv4 would allow for. Fragmenting packets shouldn't be neccessary. In fact, data inserted using fragmented packets can be destroyed if those packets are ever reassembled somewhere in transit, so this isn't an effective channel for the entire internet. Although the term steganography may have been popularized in reference to using white space in imagery dealing with the CIA-child porn newsgroup fiasco, the term just has to do with the hiding of data within other data. This data can be anything at all. Steganos(Greek) = Covered or hidden, Graphein(not sure =P) writing; from Merriam-Webster's site and Druid's Defcon talk.

Edited by bpa
0

Share this post


Link to post
Share on other sites

I just wanted to fill everyone in on where I am at this point. I still haven't done any real work. I am in the process of reading a ton of background research on the topic as far as means of implementing and detecting steganography in IPv4 and IPv6. Most of the research for IPv6 has been theoretical. Lots of this stuff is really interesting, and when I get a chance, I'll post the names of all the articles and research papers I've read through. Most of them can be found easily by google-ing the title. I am trying to write a proposal for my topic to get some research grant funding as well. Once I get my $$, I plan on starting up pretty quickly.

0

Share this post


Link to post
Share on other sites

I've started work on modifying glibc and doing an LD_PRELOAD shared object. Once I get those down, I can start working on doing the IP stego stuff.

You can track the process on http://retoros.org/

Edited by kingospam
0

Share this post


Link to post
Share on other sites

All,

This is long overdue, but if anyone is interested, I have release the Perl code for my project on Sourceforge. This code has been sitting around for about a year now, and I am just now getting around to doing this. I have been busy with with work, but that's really no excuse. Here is a little blurb on my blog about the release. The link to the project at Sourceforge is here. The command-line tool currently can encode and decode messages to and from IPv6 source addresses in two modes. It also supports encrypting the message before embedding it.

0

Share this post


Link to post
Share on other sites
This is the first I've heard of IP Stenography, but Steno usually refers to, as you (McGrew) have mentioned, the insertion of bits of data into the "white space" in imagery. It's most notorious claim to fame was when the CIA claimed that terror cells were using child porn newsgroups to spread information, more specifically, that they were using the boards, posting mages with encoded information under the impression that if any arrests were made, they wouldn't discover the actual purpose of the ring anyway. The validity of this claim is widely disputed.

If you're looking to integrate stegonography into IP addresses, you have only a small amount of space to work with. You might consider packet fragmentation. A single permutation per address, all sent, you could get a sentence out in about 10 characters, with 10 addresses, all in the same subnet, same originator. The data would be parsed when all the packets had reached the destination. This is a total stab in the dark, but it's an interesting idea.

The original reason for this post though was to clarily that steganography is the art of hiding in media, this would be obfuscation. You do have the potential to piggy back on data, which I suppose could be seen as evolved stego. I should watch the talk and see what I think.

Thank you for the suggestions. I'm loving all the input from everyone. Keep it coming. I have decided that I am actually going to be using IPv6 as my covert channel, so the hope is that I will have a considerably larger bandwidth for the channel than IPv4 would allow for. Fragmenting packets shouldn't be neccessary. In fact, data inserted using fragmented packets can be destroyed if those packets are ever reassembled somewhere in transit, so this isn't an effective channel for the entire internet. Although the term steganography may have been popularized in reference to using white space in imagery dealing with the CIA-child porn newsgroup fiasco, the term just has to do with the hiding of data within other data. This data can be anything at all. Steganos(Greek) = Covered or hidden, Graphein(not sure =P) writing; from Merriam-Webster's site and Druid's Defcon talk.

I work on hobbyist and professional medium to high assurance system designs. One of the problems my designs have to deal with is covert channels, which you seem to be interested it. To clarify for others, the key difference between covert channels and steganography is that steganography creates a covert channel within innoculous traffic to disguise it. Covert channels are often direct, may be observed in some form, etc. There already exists covert channels that use TCP, DNS, HTTP and others. So, you want just IP? First thing came to my mind are timing channels. How to disguise it? Well, if you have access to a streaming application (maybe VOIP) that sends packets within a predictable range, your tool could cause random looking delays. If the amount of delay was in one range, then it represents a 0, otherwise it represents a 1. By using a range, it makes it less obvious that its intentional. Error-correcting codes can be used if reliability is an issue. If you use a good content encoding or target each copy to grab a certain kind of data, then you can get more out of it. You can make it private with a simple stream cipher or, if you consider it expendable, a non-secure PRNG like Mersenne or xorshift-128 (2x as fast). You won't be sending much data, so it won't get repetitive before its use is up. This design has very little bandwidth, but is several times faster than ELF that Navy submarines use. Definitely fast enough to send a private key or password file before they notice their VOIP, VPN, whatever is subverted. Hope some of this helps.

0

Share this post


Link to post
Share on other sites

All,

This is long overdue, but if anyone is interested, I have release the Perl code for my project on Sourceforge. This code has been sitting around for about a year now, and I am just now getting around to doing this. I have been busy with with work, but that's really no excuse. Here is a little blurb on my blog about the release. The link to the project at Sourceforge is here. The command-line tool currently can encode and decode messages to and from IPv6 source addresses in two modes. It also supports encrypting the message before embedding it.

I was late to post. I guess I didn't read that far. I know your doing IPv6 but if you are interested in screwing with IPv4, I was just looking at the structural elements that aren't normally used. Now, how routers, gateways, etc. handle unusual values in these fields may affect how useful they are, but I'm sure you could experiment and figure that out. Here's some possible covert storage channels in IP packets besides the obvious ones (i.e. data).

More on IP4. Type of service bits 6-7 I've heard are reserved for future use. That's two bit storage per packet right there, so long as nothing is actually using it. If you control Timetolive, it might be useful too. Figure out minimum it needs to be for the application. Then, if its set higher and odd number then 1 even number 0. That's an extra bit. Who would really pay attention to TTL as a communication channel? So far, we have 3 bits per packet and it only takes 43 packets to covertly share a 128-bit key.

Since I never code raw network operations, I hadn't thought much about the options section. The use of No-Op's in ways like above could add bandwidth and the security field is 16 bits with 8 security values reserved for future use. Eight values translates to 3 bits of usable data that has no defined value for routers. Compartments field 16 bits: uses 0 for non-compartmented value, but DISA has the rest. I don't know what would happen if we just used it to send arbitrary 16 bit values. Handling Restrictions 16 bits: yet another DISA feature. Between the various security fields (excluding No-Ops), we have 35 bits per packet. It's not totally unnoticeable, but I doubt admins are looking for it. The use of any one or group of these features depends most on the behavior of devices the packets move through and the threat model, but it seems worth investigating. Particularly TTL and compartment fields. Just make sure I get credit if it ends up in a paper. ;)

Edited by army_of_one
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now