4 ms·

Besides reposting the notion that timestamps imply a USB2 file dump, I am seeing only speculation in this article and no "new data on attributing". I would lik

by rilita 12y ago

Besides reposting the notion that timestamps imply a USB2 file dump, I am seeing only speculation in this article and no "new data on attributing". I would like to point out that any skilled unix developer can create a script in about an hour that can make any set of files appear to have been transferred using USB2.

rudolf0 12y ago
Of course. Even more likely is that the timestamps aren't forged, but are merely a result of the attackers copying everything to some sort of local storage a few days before preparing the big dump to release to the public. It's possible that in reality the data was initially copied 3+ months ago. You can't rely on file timestamps as a sole mechanism of when the true "original" version of a file was created or modified. (This is "conclusion 2" from the post.) This isn't really news at all, and I'm kind of surprised Schneier thought it was worthwhile enough to publish it. Look at how incredibly sensationalistic this article is, which Schneier cites as the primary source: http://www.4thmedia.org/2014/12/breaking-we-can-conclusively-confirm-north-korea-was-not-behind-sony-hack/ http://www.4thmedia.org/2014/12/breaking-we-can-conclusively... "BREAKING: We Can Conclusively Confirm North Korea Was NOT BEHIND Sony Hack", seriously? I understand he just wanted to aggregate all the updates and commentary since his last post, but this is practically nothing and is just about bordering on FUD (I'd say "reverse-FUD" but that's not how it works, just like "reverse-racism" doesn't exist). So far, no 3rd party has provided any strong evidence showing that North Korea either was or wasn't involved.
- netman21 12y ago
  Very surprised that Schneier fell for this source. A little research would have provided this on the author, one Charles C. Johnson "The Worst Journalist on the Web" http://gawker.com/what-is-chuck-johnson-and-why-the-web-s-worst-journal-1666834902 http://gawker.com/what-is-chuck-johnson-and-why-the-web-s-wo...
woodman 12y ago
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.
- rilita 12y ago
  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.
  - graylights 12y ago
    "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.
    - rilita 12y ago
      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.
rst 12y ago
Faked timestamps have played a role in at least one high-profile case in the past: the forged evidence presented at the Turkish Ergenekon trials: http://balyozdavasivegercekler.com/2012/10/04/dani-rodrik-did-microsoft-steal-its-fonts-from-the-turkish-army/ http://balyozdavasivegercekler.com/2012/10/04/dani-rodrik-di... These featured files presented as dated 2003 even though internal evidence (including references to software and fonts) showed that they could only have been created much later.
- woodman 12y ago
  Faked timestamps are not uncommon, but I've never heard of somebody faking a transfer speed using fake timestamps. If anybody could point to a prior example, I'd certainly appreciate it. I wonder what other data can be extracted from that as well: like the file copy algorithm used for the transfer (the the files copied alphabetically, shallow, deep, etc)?
graylights 12y ago
The bigger issue is that even if you accept the USB2 transfer, you can't make any real conclusions. Was the USB transfer from victim machine to external storage or from attacker machine to external storage.
- rilita 12y ago
  There will be distinctly different patterns for the dates transferring in different ways. Suppose the source is a shared network drive. From share to external USB thumbdrive will have a different fingerprint than from external USB thumbdrive to single local SATA. Also, you can likely detect what OS was used ( well Linux or Windows ) due to differences in copy order as well as speed. In theory such analysis can be done on the Sony data and tell us something more interesting than is known so far. I don't think there are any existing tools that analyze date stamps and determine anything quite on this level... Purely because it is rare to have such a huge such of files.

by rilita 12y ago

rudolf0 12y ago

Of course. Even more likely is that the timestamps aren't forged, but are merely a result of the attackers copying everything to some sort of local storage a few days before preparing the big dump to release to the public. It's possible that in reality the data was initially copied 3+ months ago. You can't rely on file timestamps as a sole mechanism of when the true "original" version of a file was created or modified. (This is "conclusion 2" from the post.) This isn't really news at all, and I'm kind of surprised Schneier thought it was worthwhile enough to publish it. Look at how incredibly sensationalistic this article is, which Schneier cites as the primary source: http://www.4thmedia.org/2014/12/breaking-we-can-conclusively-confirm-north-korea-was-not-behind-sony-hack/ http://www.4thmedia.org/2014/12/breaking-we-can-conclusively... "BREAKING: We Can Conclusively Confirm North Korea Was NOT BEHIND Sony Hack", seriously? I understand he just wanted to aggregate all the updates and commentary since his last post, but this is practically nothing and is just about bordering on FUD (I'd say "reverse-FUD" but that's not how it works, just like "reverse-racism" doesn't exist). So far, no 3rd party has provided any strong evidence showing that North Korea either was or wasn't involved.

netman21 12y ago
Very surprised that Schneier fell for this source. A little research would have provided this on the author, one Charles C. Johnson "The Worst Journalist on the Web" http://gawker.com/what-is-chuck-johnson-and-why-the-web-s-worst-journal-1666834902 http://gawker.com/what-is-chuck-johnson-and-why-the-web-s-wo...

woodman 12y ago

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.

rilita 12y ago
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.
- graylights 12y ago
  "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.
  - rilita 12y ago
    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.

rst 12y ago

Faked timestamps have played a role in at least one high-profile case in the past: the forged evidence presented at the Turkish Ergenekon trials: http://balyozdavasivegercekler.com/2012/10/04/dani-rodrik-did-microsoft-steal-its-fonts-from-the-turkish-army/ http://balyozdavasivegercekler.com/2012/10/04/dani-rodrik-di... These featured files presented as dated 2003 even though internal evidence (including references to software and fonts) showed that they could only have been created much later.

woodman 12y ago
Faked timestamps are not uncommon, but I've never heard of somebody faking a transfer speed using fake timestamps. If anybody could point to a prior example, I'd certainly appreciate it. I wonder what other data can be extracted from that as well: like the file copy algorithm used for the transfer (the the files copied alphabetically, shallow, deep, etc)?

graylights 12y ago

The bigger issue is that even if you accept the USB2 transfer, you can't make any real conclusions. Was the USB transfer from victim machine to external storage or from attacker machine to external storage.

rilita 12y ago
There will be distinctly different patterns for the dates transferring in different ways. Suppose the source is a shared network drive. From share to external USB thumbdrive will have a different fingerprint than from external USB thumbdrive to single local SATA. Also, you can likely detect what OS was used ( well Linux or Windows ) due to differences in copy order as well as speed. In theory such analysis can be done on the Sony data and tell us something more interesting than is known so far. I don't think there are any existing tools that analyze date stamps and determine anything quite on this level... Purely because it is rare to have such a huge such of files.