5 ms·

A rogue npm package is my nightmare scenario, those packages are like the only (or I wish..) untrusted code my OS is running. That's why I came up with a small

A rogue npm package is my nightmare scenario, those packages are like the only (or I wish..) untrusted code my OS is running. That's why I came up with a small script/service waiting for an "inotify" event on a honey-pot SSH key (and some other files like ~/passwords.doc) which will immediately shutdown the computer on any kind of access of those files. #!/bin/sh inotifywait -e open --fromfile ~/.config/killer/killer.cfg --outfile ~/.config/killer/killer.log if [ $? -eq 0 ]; then poweroff fi

btgeekboy 8y ago
This is a neat idea. Though in my case an accidental grep through my homedir would be incredibly annoying.
- pas 8y ago
  Run untrusted stuff in a VM/container.
  - gcb0 8y ago
    mac "containers" run in virtual box with exposed paths, which is vulnerable to symlinks attacks and others
  - petee 8y ago
    How does that solve an accidental grep that touches a file being monitored? Grep and your key are both trusted, and there are numerous ways someone can try to read the key despite only running specific things in a vm (and forgetting that VMs aren't bulletproof)
chrisper 8y ago
And how can you tell if that was the source of your power off?
- jakobdabo 8y ago
  By examining the timestamp on the log file (defined by the --outfile parameter).
  - lima 8y ago
    Powering off will destroy valuable evidence, though, most payloads live in-memory nowadays. Maybe just disable the NIC? It's not going to do much against a determined adversary, anyway. If he's prepared to turn the NIC back on, he would just kill your inotifywatch first.
    - jakobdabo 8y ago
      Honestly, I didn't give it any serious thought, I came up with the idea and quickly executed it as a PoC in a couple of minutes after that compromised npm package incident a while ago. Disabling the NIC is a nice idea too, it should also be much quicker than shutting the machine down, so, please, feel free to make the script better. The only "clever" thing I did was making sure the honey-pot key comes first in the ~/.ssh directory and that it's big (to gain time to poweroff while it's being transmitted to somewhere). Clearly, this is not a protection against a determined adversary.
lima 8y ago
You don't have to run untrusted npm packages for development. I do all of my development on development servers and just sync over node_modules for IDE autocompletion.
- jakobdabo 8y ago
  Agreed, I don't have to, old habits die hard. I guess I will just set up a development VM (as @pas suggested) instead of remote development though, so thank you to both of you.
jwilk 8y ago
I fear this might be too slow to stop an automated attack. Passing -f to poweroff, so that shutdown(8) is not called, might help a bit.
- brazzledazzle 8y ago
  You could also just down your network interfaces.
  - thisistomsacct 8y ago
    Don't forget about ransomware. Imagine the rogue package encrypted your files and demanded payment to get the decryption key. With public key encryption or a symmetric key that is securely deleted, there is no need for network access for the attack to succeed. A fast shutdown could protect most of your files. https://en.m.wikipedia.org/wiki/CryptoLocker https://en.m.wikipedia.org/wiki/CryptoLocker Although I think the best way to deal with ransomware is a strong backup policy, not a tripwire shutdown trick.
    - jwilk 8y ago
      Non-mobile link: https://en.wikipedia.org/wiki/CryptoLocker https://en.wikipedia.org/wiki/CryptoLocker
    - brazzledazzle 8y ago
      Good point. I haven’t thought about it much since I’m on macOS and Linux but it’s not like they’re immune. The idea of a node module encrypting my home directory (even with backups) makes me a tad nervous.
- geekamongus 8y ago
  "Are you sure you want to quit? iTerm2 is still open."
bogomipz 8y ago
I am not familiar with Node or npm. Is there something specific to Node's package system that requires running untrusted code?
- lvh 8y ago
  Not really. Most dependencies get RCE one way or another, just not necessarily at installation.
  - bogomipz 8y ago
    Sorry what is RCE?
    - lvh 8y ago
      My bad: remote code execution.
- inapis 8y ago
  Not really. A lot of other package managers are vulnerable to the same kind of attacks seen on node/npm. It's just that a lot of npm packages can have an excessively long dependency chain which make it harder to audit. And the npm ecosystem is massive.

btgeekboy 8y ago

This is a neat idea. Though in my case an accidental grep through my homedir would be incredibly annoying.

pas 8y ago
Run untrusted stuff in a VM/container.
- gcb0 8y ago
  mac "containers" run in virtual box with exposed paths, which is vulnerable to symlinks attacks and others
- petee 8y ago
  How does that solve an accidental grep that touches a file being monitored? Grep and your key are both trusted, and there are numerous ways someone can try to read the key despite only running specific things in a vm (and forgetting that VMs aren't bulletproof)

chrisper 8y ago

And how can you tell if that was the source of your power off?

jakobdabo 8y ago
By examining the timestamp on the log file (defined by the --outfile parameter).
- lima 8y ago
  Powering off will destroy valuable evidence, though, most payloads live in-memory nowadays. Maybe just disable the NIC? It's not going to do much against a determined adversary, anyway. If he's prepared to turn the NIC back on, he would just kill your inotifywatch first.
  - jakobdabo 8y ago
    Honestly, I didn't give it any serious thought, I came up with the idea and quickly executed it as a PoC in a couple of minutes after that compromised npm package incident a while ago. Disabling the NIC is a nice idea too, it should also be much quicker than shutting the machine down, so, please, feel free to make the script better. The only "clever" thing I did was making sure the honey-pot key comes first in the ~/.ssh directory and that it's big (to gain time to poweroff while it's being transmitted to somewhere). Clearly, this is not a protection against a determined adversary.

lima 8y ago

You don't have to run untrusted npm packages for development. I do all of my development on development servers and just sync over node_modules for IDE autocompletion.

jakobdabo 8y ago
Agreed, I don't have to, old habits die hard. I guess I will just set up a development VM (as @pas suggested) instead of remote development though, so thank you to both of you.

jwilk 8y ago

I fear this might be too slow to stop an automated attack. Passing -f to poweroff, so that shutdown(8) is not called, might help a bit.

brazzledazzle 8y ago
You could also just down your network interfaces.
- thisistomsacct 8y ago
  Don't forget about ransomware. Imagine the rogue package encrypted your files and demanded payment to get the decryption key. With public key encryption or a symmetric key that is securely deleted, there is no need for network access for the attack to succeed. A fast shutdown could protect most of your files. https://en.m.wikipedia.org/wiki/CryptoLocker https://en.m.wikipedia.org/wiki/CryptoLocker Although I think the best way to deal with ransomware is a strong backup policy, not a tripwire shutdown trick.
  - jwilk 8y ago
    Non-mobile link: https://en.wikipedia.org/wiki/CryptoLocker https://en.wikipedia.org/wiki/CryptoLocker
  - brazzledazzle 8y ago
    Good point. I haven’t thought about it much since I’m on macOS and Linux but it’s not like they’re immune. The idea of a node module encrypting my home directory (even with backups) makes me a tad nervous.
geekamongus 8y ago
"Are you sure you want to quit? iTerm2 is still open."

bogomipz 8y ago

I am not familiar with Node or npm. Is there something specific to Node's package system that requires running untrusted code?

lvh 8y ago
Not really. Most dependencies get RCE one way or another, just not necessarily at installation.
- bogomipz 8y ago
  Sorry what is RCE?
  - lvh 8y ago
    My bad: remote code execution.
inapis 8y ago
Not really. A lot of other package managers are vulnerable to the same kind of attacks seen on node/npm. It's just that a lot of npm packages can have an excessively long dependency chain which make it harder to audit. And the npm ecosystem is massive.