Slashdot Mirror
Hiding and Recovering Data on Linux
neuroticia writes "linuxsecurity.com has an interesting article on data hiding and recovery:
"On a 4GB Linux partition, the block size is typically 4K (chosen automatically when the mke2fs utility is run to create a filesystem). Thus one can reliably hide up to 4KB of data per file if using a small file. The data will be invulnerable to disk usage, invisible from the filesystem, and, which is more exciting for some people, undetectable by file integrity checkers using file checksumming algorithms and MAC times. Ext2 floppy (with a block size of 1KB) allows hiding data as well, albeit in smaller chunks.""
- what are the potential uses for such a thing?
- a hacker could hide some information somewhere, but what to hide?
- Is there any legitimate use for that?
- Does moving the file to another location suffices to prevent any use of such a thing? (after all, if the file is moved, the block is free for reuse).
Just my 0.01 worth questions...
One shall speak only if what one has to say is more beautiful than silence
Take your data with you. Keep it with you at all times or put it somewhere more secure or less obvious than an open server.
Yes, it's not a perfect solution but it works 99 per cent of the time. And, if you're paranoid, you can always encrypt the files on your CDR/floppy/zip/Compact Flash card/USB key chain drive for further security.
Sometimes the simplest solutions are the best.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Regarding slack space, yes, it works as described, you can use slack space to write your data, and hope that it doesn't get overwritten when the file grows.
Using encription and spanning multiple slack zones, namely on binary files, you can, for instance, write a tool that encrypts a file, writes it on a number of slack zones for the files in /usr/bin (since these won't grow much over time, will they?), and then is able to recover the file.
You can even write the tool so that it creates two pipes, one to read, another to write.
But in the end, is this good or bad? Like it is said in the article, it can as easily be used to hide evidence as it can be to plant evidence.
What should we do? Write tools to use this to our advantage, or write tools to automatically wipe clean the slack area and render this inoperant?
Or should we do both?
free the mallocs!
There are several practical problems with this.
First: defragmenting. If you run any utility to defragment your drive, the data will (probably) be lost.
Second: Don't move that file! If you don't know what file space your "secret" data is stored in, then moving, adding, deleting, copying or otherwise altering (editing) any file may destroy some part of your hidden information. Remember that you only have 4k to work with at any given time. This isn't a huge amount of space. You start hiding data all over the place and you quickly start running into this risk.
Third: The govm't and spies aren't stupid. They will have thought of this possibility. In order to implement such file-hiding techniques you would almost certainly need to implement some type of disk partition and format management system on top of the existing one in order to avoid the problems mentioned above. It isn't very hard to search for direct-to-disk calls, and checking the kernel source for partion management against current versions to see if it has been altered is easy too. Unless you hide the source code for your (ext3.01?) filesystem somewhere else or in your hidden system area (pretty hard to do) then the person searching for your data has some pretty clear evidence of where to look for your stuff and how to get at it.
My $0.02 will always be worth more than your â0.02, so
If you are able to store data in the slack space of binary executables, you're presumably root, in which case why not secure your data in a more sensible way.
Unless, of course, you're just "borrowing" root access from the chappie who actually owns the box.
A skilled attacker will hide as many signs of his intrusion as possible. This is one more method he may use, to avoid file integrity checkers like Tripwire, AIDE, and FCheck.
As for what he's hiding? Let's say he puts a trojan sshd in place to grab passwords - those passwords could be conveniently hidden until Bad Guy can come around and collect them.
Sorry, I fail to see how this is news (block sizes and slack space have been well known for years) or a useful technique
Remove yourself from that high equine animal you are saddled upon. Yes, to many of us here, the idea of storing data in unused sections of a drive is old hat, and many of us have even used such a technique before for various purposes such as for copy protection flags, or for hiding information where people wouldn't think to look, etc. (which are examples of where it would be useful) The "news" in this post is not that you can hide data in the unused portions of blocks, but that a new article overviewing this technique was recently posted, so that those who are not familiar with the concept can go read it and learn about it. These are important concepts that system administrators should know about, so that they know when they can and cannot trust what the tools at their disposal (such as ls, for example) tell them about the contents of their system.
By itself, hiding something in a system doesn't provide a very good amount of security, but in combination with other things, it can be the best form of security possible. Never underestimate the value of other people not even knowing there is a secret they need to look for.
This is the essential problem. Crypto needs to be easy enough to use, that people who are lazy and have nothing to hide, will still do it anyway by default.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.