Hacker News Reader

Comment by woodman | Hacker News Reader

So I've been out of security for a while, but I don't think I've ever seen this sort of misdirection applied before - or even disused.

View on HN

I have been faking date/timestamps on files contributed to both github and pause over the past 10 years. To me that information is private and I see no reason to give real dates out for files I put into the open source world.

I messed up once and set the date/times into the future by a bit and got a bug filed against my project when someone tried to merge my software into a mainline linux distro and had problems with the future date/times.

I don't know how many people have used this information for malicious purposes, but I can guarantee that I always think about it in any hacks I've been involved in.

Do note that file creation time in unix requires kernel level access and quite a bit of low level filesystem knowledge to truly forge. The easily changeable date/time is only access and modify times. If you are going to forge this data to remove tracks from real systems you will need to root the machine completely first. It's nontrivial.

Yeah the faked timestamps aren't new to me, it is the potential faking of copy speed that is interesting. To do that you would need to replicate the transfer order of the copy algorithm (cp in linux vs windows 95), and then modify each timestamp based on the prior file size in the ordered list. I've never heard of anybody doing this before.

That is a very good point; in my attempts previously I simply went alphanumerically but windows at the very least does not follow that rule when copying.

I think the easiest method would be to simply generate a bunch of files, do copies, and compare the datetime stamps with the theoretical values they should have. Once you can model the discrepancies generated in real life you can fake them.

You do make a good point that it isn't really mentioned in cybercrime books that I know of, but it seems like an obvious thing. Would be a fun chunk of code to publish on github; I'll look into it.

It really depends on your goals. If your goal is simply to fake the transfer speed in a tarball you leak, the easiest way would be load up a vm of the system you're spoofing - change the clock and somehow rate limit the copy. That wouldn't be nearly as fun though.

It is one of those things that appears obvious after you've been walked through it though. I've never been in a position where I needed to fake transfer speed though, so I'm not sure if I'd have thought about it. If it actually is an attempt to fake an insider attack, it is an impressive trick.

Rate limiting is not effective. Having copied many terabytes of data do/from usb devices, I can tell you that it is not a consistent throughput. The speed of transfer depends on an inverse square of the file size of sorts. ( sensitive to the block size on both devices I'm sure )

Try copying 100gb of 2k-200k files ( all randomly sized ) It's a huge pain in the butt and works terribly on every system I've tried to do this on.

It would be way more awesome to have a utility that can after the fact forge a scenario directly into an existing tarball. Then, you can simply pick a "model to emulate" and click go, and wham you have a forged tarball.

Even if you did use a VM, it would be slower imo than a real transfer due to both the emulated system and the usb passthrough ( which is typically limited to USB 2.0 ) Show me a VM that is capable of USB 3.0 passthrough with reasonable speeds.

Unless you truly forge the dates in a carefully modeled way, it would be possible to tell that it isn't a real transfer.

Speaking of which; who steals data using USB 2.0? That's dumb. Use a modern USB 3.0 external 2.5" SSD. If you must use something small, use a cheapo 256gb USB 3.0 drive. The throughput on those is not bad. If no USB 3.0 ports are available, bring your own PCI Ex USB 3.0 card and open the system and install it. The BIOS may have intrusion detection... so be aware...

It is much more likely than direct system transfer that data is leaked slowly through an un-monitored network channel ( DNS tunneling... email... etc ) Hence the need to make things appear to be local; to distract from looking for the real method of transfer.

When you get to the point where you are emulating the actual hardware in the spoof (seek time, etc), I think you've already fallen below the noise floor. It would be like a side channel attack on string comparison during hash checks, you would need a huge number of trials to tease out the signal. I wouldn't think it would be that difficult to fake a media speed constraint though - just pay attention to the clock and sleep when you're ahead of the target bitrate. You don't care if the speed is under, you just don't want it any higher than the max theoretical limit.

USB 3.0 shouldn't be a problem for VMs, just grant the guest PCI passthrough access to the USB controller. So you'd have to use something like Xen instead of Virtualbox.

My workstation doesn't have USB 3.0, so if I were to steal company data - it would be at USB 2.0 speed. Also, if I were already inside - I'd much rather do that than trying to be clever about getting it out over the network (which would be much slower and more likely to be logged).

"Do note that file creation time in unix requires kernel level access and quite a bit of low level filesystem knowledge to truly forge."

Timestamps are a mess on unix. POSIX doesn't support creation time but instead has ctime (change time). Newer filesystems add crtime but common utilities don't ever display crtime. Also partitions sometimes are mounted to not update atime for performance reasons.

crtime (and ctime) can be modified with root privileges without kernel access with debugfs.

Or you can go the ugly hackish way: date -s $forgedate && touch tmp && date -s $realdate && cat original >> tmp && mv tmp original

Neither are elegant, but certainly not hard.

What's really hard to forensically cover up is the order of inodes on a filesystem. That file with forged timestamps to 2012 will still have an inode that looks much more recent.

It is the inode trail that I am referring to; not the simple forging of the dates ( which you could obviously do by just changing the date and duplicating the file as you've described ). Messing with the inodes is much more difficult.

Reply on news.ycombinator.com