# Dev Training ### Known Vulnerabilities <!-- .slide: class="title-slide" --> ## Overview ### About * Security vulnerabilities are a part of life * Vulnerabilities are constantly discovered * Protocols * Frameworks * Web servers * Operating systems Notes: Building a completely secure system - be it a network, physical lock or piece of software - is practically impossible. "Everything is vulnerable" is a useful and almost entirely true assumption. Vulnerabilities are constantly found in every layer of our technology stacks. ## How are they found ### Security research * Vendor notified and given time to patch * Patch released and Vulnerability disclosed by researcher * Should be avoidable with good update schedule Notes: Security researchers, for example, are always on the lookout for vulnerabilities. Especially in big, widely-used software and bits of infrastructure. If a researcher finds a vulnerability in your application before anyone else, congratulations! They will (usually) follow responsible disclosure practices and give you a head-start on releasing a patch before they publish a paper or something about it. ### Zero-Day * Vulnerability actively being exploited in the wild * No patch exists * Very hard to mitigate against * Logging is important! Notes: Sometimes, vulnerabilities are referred to by their age in days since the vendor became aware of them. I.e. a 1-day vulnerability is one that was reported earlier today, etc. You will almost exclusively hear about this in reference to zero-day vulnerabilities. Those are vulnerabilities of which the vendor has not yet been made aware, but is being actively exploited. These are often difficult or practically impossible to mitigate before the vendor manages to publish a patch. This is one of many reasons why logging and monitoring are super duper important! ### Common Vulnerabilities and Exposures * Most known vulnerabilities are given CVE IDs * E.g. Log4Shell [`CVE-1337-1234`](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) * Defined and maintained by the US government * Some large companies and institutions have their own systems and standards for vulnerabilities * Mostly vulnerabilities related to their products Notes: Common Vulnerabilities and Exposures (or CVE) is a program started and primarily funded by the U.S. government. It aims to index and classify all known vulnerabilities. This is an invaluable resource for security researchers, IT administrators and hackers alike. There are other standards out there, mostly specific to certain big vendors, but this one is the most widely used. ### Exploits * If serious vulnerabilities are found in popular software, ready-to-use exploits can become available very quickly * [Shellshock](https://en.wikipedia.org/wiki/Shellshock_(software_bug)) exploits were ready hours after disclosure and used to form botnets Notes: If the target software is popular, proof-of-concept exploits are often made public within days or even hours of discovery. The cat-and-mouse game begins as soon as the vulnerability is first exploited. The sooner the vendor becomes aware of it, and the faster they issue a patch and/or mitigation workaround, the better for everyone (except hackers). ## What can I do? ### Update * Monitor vulnerability news feeds * Keep your stack up to date * Operating systems * Web servers * Frameworks * Software Notes: Number 1, update your stuff! This means everything from the operating system and up. If you are still running Windows Server 2008 somewhere, please stop. It's been out of service for over 4 years and has many known vulnerabilities so just please don't do that anymore. Following news about the latest vulnerabilities for your tech stack also helps. ### Audit * Audit dependencies for known vulnerabilities if possible * `npm audit` * go - [Nancy](https://github.com/sonatype-nexus-community/nancy) * GitHub Dependabot * Make this a part of your build pipeline Notes: Audit your dependencies for known vulnerabilities. There are automated tools out there for most languages and frameworks. Most of them can even be integrated into your CI/CD pipeline of choice. Sometimes they are even built-in out of the box. Pretty much everybody should be doing this today. If you do these things, you will avoid a LOT of trouble. ### But... * Beware of supply chain attacks * Dependency hijacking * Dependency confusion * Dependency typosquatting Notes: But of course it gets more complicated. You can get hacked from upstream via dependency hijacking, confusion, typosquatting and other confusing terms. In simple terms, these are all different approaches to trick your software into including malicious code via dependencies on release. This kind of thing can have devestating consequences. See SolarWinds for example. ### For added security * Personally audit all dependencies and pin versions * Prevents dependency hijacking * Separate internal and public dependencies * Mitigate risk of dependency confusion * Type carefully * Reduces odds of falling prey to typosquatting * Also just generally a good idea Notes: To avoid these issues, you can employ various strategies which have different amounts of overhead. Version pinning helps to avoid hijacking, but makes the update process more manually intensive and requires you to keep an eye out for new releases of those dependencies. Separating internal and external dependencies is just a good idea and helps to prevent dependency confusion, where two things can be called the same thing and your packaging solution ends up preferring the evil twin. To avoid typosquatting attacks, you need to stop making typos I guess. Typing carefully is a great idea and we should all do more of that. ## Rules of thumb ### General * Follow news feeds relevant to your technology stack * Update regularly, but be careful Notes: So to sum up this rant, pay attention to vulnerability disclosures relevant to your tech stack and update your stuff. But be deliberate in your updates and pay close attention to any changes. These are almost unattainable ideals for many companies, but if you implement a strategy that brings you closer to them, you are already doing better than most. ## Epilogue ### Further reading * [CVE Data Feeds](https://cve.mitre.org/cve/data_feeds.html) * [CVE Details](https://www.cvedetails.com/version-search.php) * [NIST National Vulnerability Database](https://nvd.nist.gov/vuln/data-feeds) * [Exploit Database](https://www.exploit-db.com/) * [OWASP Using Components with Known Vulnerabilities](https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities) ### Supply chain attacks * [Software Supply Chain Attacks](https://blog.sonatype.com/dependency-hijacking-software-supply-chain-attack-hits-more-than-35-organizations) * [Dependency Confusion](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) * [The npm Package that Broke the Internet](https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/) * [`event-stream` Hack - Malicious npm Package](https://www.trendmicro.com/vinfo/hk-en/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets) ### Hall of fame * [WannaCry ransomware attack](https://en.wikipedia.org/wiki/WannaCry_ransomware_attack) used leaked NSA Zero-days * [Heartbleed](https://heartbleed.com/) compromised servers that used OpenSSL * [Log4Shell](https://infosecwriteups.com/log4j-vulnerability-explanation-in-details-73f7556c5ff1) (log4j vulnerability)