To see an example of the risks a vulnerable open source component introduces to our running application, we're going to exploit one of those vulnerabilities. The
exploits folder contains exploits for many of the vulnerable dependencies.
Let's execute an exploit against our running application. We'll demonstrate how the Directory Traversal vulnerability in the
st package can lead to sensitive information leakage. Start by navigating to the exploits folder and sourcing the
cd exploits && source st-exploits.sh
This sets up a series of aliases to demonstrate the exploit. They are shown below:
st1="curl $GOOF_HOST/public/about.html"# Directory listing (not necessary)st2="curl $GOOF_HOST/public/"# Failed ../st3="curl $GOOF_HOST/public/../../../"# Exploit startst4="curl $GOOF_HOST/public/%2e%2e/%2e%2e/%2e%2e/"# Exploit fullst5="curl $GOOF_HOST/public/%2e%2e/%2e%2e/%2E%2E/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd"
The good stuff is in
st5, where we see the leaked contents of the
Yikes. And this is just one example. Feel free to play around with the other exploits in this folder, the sample application is very vulnerable (for now!).
In Snyk, this, and other vulnerabilities in our dependencies, are shown under the
package.json file. Snyk accelerates remediation via Pull Requests to upgrade dependencies to non-vulnerable versions.
Click into the
package.json project, and Scroll down to see the list of vulnerabilities present, ordered by our proprietary Priority Score. For each Vulnerability, Snyk displays:
The module that introduced it and, in the case of transitive dependencies, its direct dependency,
Details on the path and proposed Remediation, as well as the specific vulnerable function.
We'll start with the first vulnerability, zip slip, since it's ordered the highest. The exploit for zip-slip is also available in the
exploits folder in case you want to try it out before patching it.
Since a fix is available, Snyk can automatically upgrade the vulnerable dependency to a non-vulnerable version through a Pull Request. Click on "Fix this vulnerability" to do so.
On the next screen, you'll be able to confirm the issue to fix with this PR.
Looks good! Go ahead and open the PR. Once it's ready, you'll be taken to the PR in GitHub, where you can review the changes in the file diff view:
Now, go ahead and merge the PR! Back in Snyk, we can appreciate that our
package.json file has 1 less High Severity Vulnerability.
If you tried the zip-slip exploit,
git pull the code to bring your local copy up to date with GitHub and try the exploit again. You'll notice it no longer works.
Fix Pull Requests are great for fixing individual vulnerabilities, and Snyk can automatically open Pull Requests when new fixes to vulnerabilities are published. You can also fix vulnerabilities manually.
st package exploit demonstrated above. Find the
Directory Traversal vulnerability by looking through the list of issues in Snyk. See that updating
st to version
0.2.5 fixes this issue.
Make this change in your package.json file.
To ensure this isn't exploitable, re-build and re-deploy the container to Kubernetes.
# Build the new imagedocker build $DockerId/goof:dev .# Push to Docker Hubdocker push $DockerId/goof:dev# Scale the deployment down and upkubectl scale deployment goof --replicas=0kubectl scale deployment goof --replicas=1
Now try the exploit again. It should fail spectacularly.
Either with Fix Pull Requests, or using the information in Snyk to modify your package manager manifest, continue fixing vulnerabilities until you've knocked out the High Severity Vulnerabilities that have a fix available. Some additional resources that can help:
Snyk IDE Plugins: If you're using JetBrains IDEs, Eclipse, or VS Code, check out our plugins that show vulnerability and remediation information right within the IDE.
For Node applications, like this one, check out Snyk Wizard!
Once you're ready, continue on to the next section to learn how to fix configuration issues in the Kubernetes manifests that deploy the application!