goldfish: secure, temporary filesystems

[Sitwon]

Recently for work I needed to come up with a volatile storage solution without relying on RAM disks. We needed to ensure that PHI data (protected health information) was irrecoverable if a hard drive was pulled from a running system or the system itself was stolen from a hospital. We couldn't use a RAM disk because there just wasn't enough RAM on theses systems.

The solution I found was to mount a loopfile that had been encrypted with a random key. Since the encryption key is never stored or revealed the data inside the filesystem is irrecoverable once the system loses power.

This approach is not entirely novel, but it seemed like it could be useful more broadly if there was an easy tool. So that's what I did, I wrote an easy to use bash script to generate and destroy secure temporary filesystems.

I've already described one real-world white hat scenario, now here's a black hat scenario: You configure your new WiFi Pineapple Mk 5 to log data about its victims to one of these secure temporary filesystems and then leave it near some target-rich hotspot. You can securely log-in over SSH and retrieve the logs, but if anyone else discovers it and tries to tamper with it the logs (along with evidence against you) is permanently lost.

Obviously this technique is still vulnerable to sophisticated physical attacks (along the lines of the cold-boot attack), however such attacks are extremely rare in practice.

Code is available on GitHub: https://github.com/Sitwon/goldfish

Please respond in the thread if you have questions or comments, but report bugs in GitHub's issue tracker.

[digip]

Out of curiosity, if someone has physical access, can they do a memory dump to access any data while the system is up and running? Also, what of remote access, what controls are in place to stop someone from accessing this system remotely on the same LAN. I imagine this data needs to be retrieved for usage, so there are in my mind also hard copy backups or even file shares for people accessing the data when needed until power loss, or stolen, how do you recover from such a deletion of PHI data, or is this data only used on a temporary basis anyway and constantly destroyed?

I can see the Pineapple usage being very useful, but in a corporate environment where high availability of data and redundancy are the norm, how do you recover from this? What sort of disaster recovery process is there in place to get back the PHI data, or as I mentioned, is it constantly just thrown out and trashed, and only used temporarily. The hospital, or for example, say, any company, bank, government facility, etc, would surely have copies of data, so how is PHI data any different in storage?

When I worked at a bank, all backups were AES encrypted and also mirrored over fiber to a disaster recovery center in the event our data center burnt down, we had off site tape backups, plus replicated data, so I imagine PHI data has some level of redundancy on any system, even if while being used is constantly being looped to encrypt and then be useless once power is lost or drive removed from the hardware, before the data being used is put into the loop and encrypted, how is it stored and retrieved beforehand?

I love topics like this because they make me think about the overall architecture and how it all interconnects and is used. Not that its directly related but in a way, reminds me of my Cisco class in how we setup vlans and segmented routes and such to safeguard against network access from one subnet to another, I like seeing topology in my head and in a way this makes me see threads of where data is coming in and out and how its being accessed, retrieved, destroyed, stored, etc. Think I just got another wrinkle in my brain..lol

[Sitwon]

Regarding the storage of PHI, it's being used in a narrow use case where the data needs to be cached on the device temporarily (while the patient is using the device) but should not persist between patients or across a device reboot. The PHI is stored permanently on a secured server and it can only be retrieved from the server through an encrypted and authenticated session. The hard drives on the servers are encrypted, but not with temporary keys. And we do also keep encrypted backups of the servers.

You're right, someone with physical access to the hardware could freeze the RAM with compressed air and then read the keys out of memory, but that's a relatively sophisticated attack which is not yet commonly used. Or a user on the system with sufficient privileges could read the filesystem while it's mounted or read the keys out of memory on the running system. That's why we need to practice defense in depth and make sure we have layers of security. This isn't a silver bullet.

This strategy of secured temporary storage is useful in fairly narrow context where the device is at a high risk of being stolen or tampered with, and you'd rather destroy the data than have it fall into the adversary's hands.

[digip]

a user on the system with sufficient privileges could read the filesystem while it's mounted or read the keys out of memory on the running system. That's why we need to practice defense in depth and make sure we have layers of security. This isn't a silver bullet.

Thanks for the clarification. I see now more what you are describing. The piece above that I quoted is what I was concerned about, someone pivoting to the device and dumping the raw memory was more what I was after, which I guess even on whole disk encrypted OS's and devices, this is still a threat if someone somehow compromised it while logged in.

I suppose these devices are like what are now used in many hospitals, such as wifi tablets and mobile kiosks that are wheeled around emergency rooms, so I can see how a device like that, once done with the data and sent back and stored on the network from patient to patient, would need to be wiped quickly when done with it since its something probably only used in triage or per patient interaction and then saved, at nursing stations temporarily, and then destroyed before moving to the next patient while stored on the back office servers. Also makes a lot more sense now and I can see why you would want this data not only randomly encrypted but easily destroyed in such a manner. Pretty ingenious too. Not a silver bullet as you mentioned, but I like the concept and can visualize it much clearer now.

[Sitwon]

And of course working on this sent me down the rabbit hole of randomness and entropy generation. I just wrote a SlackBuild for rng-tools so I can seed /dev/random with the TPM in my laptop.

Has Darren ever tried to explain entropy on the show?

[digip]

And of course working on this sent me down the rabbit hole of randomness and entropy generation. I just wrote a SlackBuild for rng-tools so I can seed /dev/random with the TPM in my laptop.

Has Darren ever tried to explain entropy on the show?

I think Darren and int0x80 did something with randomizing data, and if not mistaken, also a reason to use something other than /dev/random and /dev/urandom. Can't remember exactly what it was they used, but it had something to do with entropy I believe and not enough of the data was randomized to protect against cryptographic attacks. int0x80 might be a good one to chime in on this since some of the info I think was on one of Darren's vblogs and might not of been in an actual episode. His talks from Derbycon 1 and 2 though go into some detail on the randomization of data techniques he was using for keeping anyone trying to pull data off his machine next to impossible. Pretty sure thats where the discussion started and then Darren interviewed int0x80 and someone else on ways of securing data using this method after a night of drinking and was a casual talk at dinner as I recall it being at night when they were going over better ways to randomize the data.

[Sitwon]

I'm pretty sure the episode you referring to was about doing poor-mans two-factor authentication.

It also seemed redundant with PAM, but I think they were just too lazy to read the docs for PAM.

http://usbauth.delta-xi.net/doku.php

[digip]

Yeah, it might of been about two factor authentication to the OS itself. Not sure, was a while back. I just recall int0x80 mentioning something about /dev/urandom or something not being strong enough. Would have to find the clip, but you're a programmer, so you know more about that stuff than I do. Over my head when it comes to both programming in general and cryptography stuff as well.