3 ms·

When we heard about this this morning at RunKit we immediately started writing a script to identify if any other packages had been possibly affected. We're in a

When we heard about this this morning at RunKit we immediately started writing a script to identify if any other packages had been possibly affected. We're in a pretty unique position since we install every version of every package in a sandbox environment as soon as it is published. The scan is pretty simple (just looking for a few key strings), and designed to catch any pre-discovery propagation. The scan is running as we speak and we've unfortunately found at least one unreported case. Luckily it seems to be a package not in too frequent use, and the way the virus propagated was also pretty bizarre (through `bundledDependencies`). We've created a GitHub repo to track our progress that you can visit here: https://github.com/runkitdev/eslint-scope-scan https://github.com/runkitdev/eslint-scope-scan We will immediately file issues on any packages we find the exploit in. We are also open to suggestions to more sophisticated further approaches after this initial scan. Additionally, we are internally working on adding some sanity checks to the installation pipeline that might one day catch this sooner (such as monitoring network requests and file modifications during our sandbox install). Please let us know if you have any other ideas.

thenewwazoo 8y ago
FYI, I've downloaded all package versions uploaded between 2018-07-12T09:49:24.957Z and 2018-07-12T12:30:00Z (first compromised eslint package upload and key invalidation time), and got no hits for your signature strings in them.
- rpearl 8y ago
  key invalidation time was 2018-07-12 18:42 UTC How did you produce this list btw?
  - thenewwazoo 8y ago
    I'm still not totally clear on that, btw - they claim they invalidated keys created before 2018-07-12T12:30:00Z, but they did it at 2018-07-12 18:42 UTC. I can't decide if that's problematic. I downloaded the contents of the npm couchdb and did an exhaustive search of version timestamps.
    - rpearl 8y ago
      they invalidated keys based on when the attack became non-functional (due to the pastebin getting removed at 12:27 UTC). But the window in which any packages could potentially have been similarly compromised is from the point the attacker had access to tokens through the point they were invalidated.
joneil 8y ago
Amazing work! I'll be following along keenly... and glad to know there's an exhaustive approach being taken to figuring out if anything else was affected
mattbierner 8y ago
A log of network requests made on install would be a valuable start. Even if it doesn’t reveal anything actively hostile, I imagine there’s plenty of telemetry servers getting pinged and probably some http going on (both of which the package may also do at runtime but that’s a whole other problem)

thenewwazoo 8y ago

FYI, I've downloaded all package versions uploaded between 2018-07-12T09:49:24.957Z and 2018-07-12T12:30:00Z (first compromised eslint package upload and key invalidation time), and got no hits for your signature strings in them.

rpearl 8y ago
key invalidation time was 2018-07-12 18:42 UTC How did you produce this list btw?
- thenewwazoo 8y ago
  I'm still not totally clear on that, btw - they claim they invalidated keys created before 2018-07-12T12:30:00Z, but they did it at 2018-07-12 18:42 UTC. I can't decide if that's problematic. I downloaded the contents of the npm couchdb and did an exhaustive search of version timestamps.
  - rpearl 8y ago
    they invalidated keys based on when the attack became non-functional (due to the pastebin getting removed at 12:27 UTC). But the window in which any packages could potentially have been similarly compromised is from the point the attacker had access to tokens through the point they were invalidated.

joneil 8y ago

Amazing work! I'll be following along keenly... and glad to know there's an exhaustive approach being taken to figuring out if anything else was affected

mattbierner 8y ago

A log of network requests made on install would be a valuable start. Even if it doesn’t reveal anything actively hostile, I imagine there’s plenty of telemetry servers getting pinged and probably some http going on (both of which the package may also do at runtime but that’s a whole other problem)