“Do Not Push To Production” And Other Insecure Code, Demonstrated By An Ethical Hacker

In November, our own Mackenzie Jackson hosted a webinar called “Crack the Code: A Beginner’s Guide to Ethical Hacking” with special guest, Snyk’s Sonya Moisset. Viewers got to see some interesting vulnerabilities and coding practices that made her demo app pretty open to exploits.

I will warn you right now, if you watch the ethical hacking webinar, be careful about what you’re drinking, where you’re facing, and the size of your sips. I learned this the hard way when I almost sprayed my monitor with Coke Zero Sugar as she got to a specific point I’ll note when we get there.

What is “Ethical Hacking?”

To quote Sonya, ethical hacking is “identifying and exploiting vulnerabilities in computer systems or networks in a responsible and lawful manner.” It’s been around for quite a while. A friend of mine published a book about it over 25 years ago, called The Happy Hacker.

Basically, there are four main tenets that ethical hackers are supposed to follow:

Only hack with permission. If you’re hacking without permission, no matter what your motives, you could get arrested.
Follow relevant laws and regulations. Again, you can get arrested, even if your motives are altruistic.
Don’t be destructive/disruptive. Don’t try to nuke your target, crash it, or delete production data to prove your hack. Don’t use tools you know could do damage. Remember, if you’re hacking ethically, you’re a guest in the systems you breach, so be respectful.
Document your findings and provide a comprehensive report to the system owner.

Ethical hackers are very useful. They’re often the source of reports that lead to security patches for your browser, your OS, etc. For example, the Sakura Samurai ethical hacking group exposed (and helped fix) a security hole that provided access to sensitive United Nations data.

The heist!

Sonya’s demo went through hacking an app called Patch, which is a deliberately vulnerable demo application, written in Node.js. Thank goodness, she was running it locally, but had she put a tunneling service like ngrok in front of it, the app could have been available to the broader internet.

One of the first steps in hacking is reconnaissance. As part of her recon, Sonia tried some common and simple tests. She found that assets were being served from the public folder. She was able to take the URL to an asset, remove the file name and get access to the full directory listing of the folder.

This is pretty old and has multiple ways to solve it. Apache lets you turn off showing the directory listing in the server configuration. I simply include an index.html file in those directories. It has one line of text: “These are not the droids you’re looking for. Move along.”

But then she got a little fancier and tried a directory traversal exploit to see if she could get out of the public directory and into directories she shouldn’t be able to access. And she could.

She found her way to the top level of the app directory, giving her the ability to view and exfiltrate the entire source code. As she’d show later, directory traversal could go even farther, giving an attacker access to the ~/.ssh directory where secure keys are stored or the files where hashed system passwords are stored.

First thing she did, though, was browse through the package.json file, which provided a list of all the third-party NPM packages it was using. Using the Snyk plugin for VSCode, she was able to scan the app for vulnerabilities and find that the directory traversal weakness came from the app being pegged to the 0.2.5 version of a package that’s currently at version 3.0.0.

It may seem simple to fix that just by updating the version, but realize that there are likely to be breaking changes between those two versions because they’re so far removed. Extensive testing would be necessary. But it’s not her job to fix it. It’s her job to report it, so she recorded it with as much detail as possible, and moved on.

Remember though, she got access to all the code, not just that file. She started digging into the main code file, index.js, and scrolling through it. She saw all the packages being imported, then she was able to see all the routes for all the endpoints, including an endpoint for a chat feature she wasn’t aware of.

She scrolled further down to find the code associated with the chat endpoint and that’s when I almost…

// DO NOT PUSH TO PRODUCTION

For those of you who aren’t programmers, that’s a comment in the code. It’s a reminder to anyone who reads the code, but has absolutely zero impact on whether the code will actually get pushed to production. It’s not functional, simply informational, and might as well be a post-it note with “TO DO: Don’t!” on it for all the security it offers. This is why I almost covered my monitor in Coke Zero Sugar, because it’s the coding equivalent of a slapstick gag.

She checked that the endpoint actually worked, then started to probe it with API calls using CURL. She was able to add messages to the chat with information she found in the code. Then she tried to delete one and was blocked. But she went back through the code, found something interesting, traced it to another outdated package with a Prototype Pollution vulnerability, and was able to use it to inject code that gave her the ability to delete chat messages.

Note, she only deleted her own messages. Remember the tenet of not being destructive.

Wrapping Up…

When I did a demonstration of how to code a simple WebSockets chat at a developer meetup over 10 years ago, my app was so simple that it didn’t sanitize the messages. People were injecting HTML and CSS into their messages and the stuff they got up to was crazy. One of the better known XKCD comics is about a boy with a SQL injection exploit in his name.

It’s easier than you think to write vulnerable code and ethical hacking can help you find it when you have. But remember the four tenets: get permission, avoid illegal stuff, avoid destructive stuff, and most importantly document and report your findings to the system owner and give them time to fix things before you tell anyone else. If you ignore any of those, your hacking is not ethical and you could get in trouble.

If you want to learn more about ethical hacking, our friends at Snyk have a great set of ethical hacking resources for you to explore. And remember, an important bit of hacker recon is to go through public repositories, looking for plaintext secrets in your public code. To help you remedy that, try GitGuardian.