Newsfeed
Nachrichtenbote
The following is a true story. The names have been changed because the identity of those involved is none of your business.
Bob uses Linux. Alice uses Mac. Bob gave Alice a file via FAT32 formatted USB drive. Alice inserted the USB drive into her Mac, copied the file, and then gave the USB drive back to Bob. Later, Bob inserted the USB drive into his Linux computer and saw Mac files. Lots and lots of Mac files. And that's typical.
Anybody who has exchanged files with a Mac user knows that Mac OS X copies various "hidden" files to USB drives.
Here's the interesting part…
Bob was curious about the function of the files. (And why so many, what do they do?) Being a reverse engineer, Bob naturally examined the files with a hex editor. And that's when he discovered that a file called ".store.db" contained e-mail addresses, subject lines, and in a few cases, the opening sentence of Alice's messages.
Alarmed that such data/metadata was copied to his USB drive, Bob investigated further and found that the information couldn't be seen using a forensic tool designed specifically for viewing such .db files. From a conventional view, ".store.db" appeared to be identical to "store.db". Only a hex editor view revealed the leaked info embedded within .store.db — so it isn't at all obvious with standard forensic tools.
We have examined Bob's USB drive and can confirm that there is data in the .store.db file that really shouldn't be there. We have been unsuccessful in reproducing the issue with our own Mac computers. We don't have access to Alice or her computer, so we can only speculate. The data may have leaked due to an unknown configuration, it may have leaked due to third-party software, or it may have leaked due to malware.
Here's the concern…
Imagine you're a reporter. Do you want data about the e-mail to your sources leaking to somebody else's USB drive? Definitely not! In some countries, an OPSEC failure such as this could easily land people in jail.
We don't normally write about unknowns. But we do so in this particular case in the hope that somebody will be able to identify the source of the issue. And if somebody does — we'll update this post.
On 13/10/14 At 01:21 PM
Weiterlesen...
Bob uses Linux. Alice uses Mac. Bob gave Alice a file via FAT32 formatted USB drive. Alice inserted the USB drive into her Mac, copied the file, and then gave the USB drive back to Bob. Later, Bob inserted the USB drive into his Linux computer and saw Mac files. Lots and lots of Mac files. And that's typical.
Anybody who has exchanged files with a Mac user knows that Mac OS X copies various "hidden" files to USB drives.
Here's the interesting part…
Bob was curious about the function of the files. (And why so many, what do they do?) Being a reverse engineer, Bob naturally examined the files with a hex editor. And that's when he discovered that a file called ".store.db" contained e-mail addresses, subject lines, and in a few cases, the opening sentence of Alice's messages.
Alarmed that such data/metadata was copied to his USB drive, Bob investigated further and found that the information couldn't be seen using a forensic tool designed specifically for viewing such .db files. From a conventional view, ".store.db" appeared to be identical to "store.db". Only a hex editor view revealed the leaked info embedded within .store.db — so it isn't at all obvious with standard forensic tools.
We have examined Bob's USB drive and can confirm that there is data in the .store.db file that really shouldn't be there. We have been unsuccessful in reproducing the issue with our own Mac computers. We don't have access to Alice or her computer, so we can only speculate. The data may have leaked due to an unknown configuration, it may have leaked due to third-party software, or it may have leaked due to malware.
Here's the concern…
Imagine you're a reporter. Do you want data about the e-mail to your sources leaking to somebody else's USB drive? Definitely not! In some countries, an OPSEC failure such as this could easily land people in jail.
We don't normally write about unknowns. But we do so in this particular case in the hope that somebody will be able to identify the source of the issue. And if somebody does — we'll update this post.
On 13/10/14 At 01:21 PM
Weiterlesen...