# Offensive security wrap-up ## CS 3710: Intro to Cybersecurity === ## Midterm --- ## Midterm <div class="fragment semi-fade-out" data-fragment-index=0> The midterm will be a take-home exam, and will run from Wednesday, Oct. 5th - Saturday, Oct. 8th. </div> <div class="fragment" data-fragment-index=0> You will have Wednesday's (10/5) class to work on problems and ask me questions. We will still have lecture on Friday 10/7 (current plan is to start discussing cryptography then). </div> --- ## Midterm policy As with any exam, the midterm is an individual exam, i.e. no discussing problems with other classmates. Discussion on Discord will be locked; you can still DM me if you have a question. --- ## Midterm format The midterm will be structured like a miniature version of Labs 2 and 3. You will be given a server where you will have to perform some initial reconnaissance and then use information you gather to identify and exploit vulnerabilities. --- ## Midterm topics <div class="fragment semi-fade-out" data-fragment-index=0> The following topics will *definitely* be on the midterm: - Scanning and reconnaissance (ffuf, Nmap) - XSS and CSRF - SQLi - Metasploit and remote code execution </div> <div class="fragment" data-fragment-index=0> The following topics *may* be on the exam: - Using the browser developer tools - `msfvenom` payload generation </div> --- ## Review We will be doing a review on Friday (9/30) before Lightning Talks. In addition, I will be keeping the Lab 3 environment open, which you can use to practice everything that might be on the midterm (except CSRF). === ## Changelog <div class="fragment semi-fade-out" data-fragment-index=0> Lab #6 (deep in the future) originally due Nov. 4th, now Nov. 11th - May also have some slight topic changes to labs 6 and 7 in the next couple of weeks. </div> <div class="fragment fade-in-then-semi-out" data-fragment-index=0> Lab #2 grades have been released </div> <div class="fragment" data-fragment-index=1> PA #1 is released and due next Sunday </div> === ## Offensive security in practice: ethical disclosure --- ## Zero-day vulnerabilities <div class="fragment semi-fade-out" data-fragment-index=0> A _**zero-day vulnerability**_ is a vulnerability that is (or was) previously unknown to software vendors and defenders. </div> <div class="fragment" data-fragment-index=0> It's called a "zero-day" because defenders have had zero days to respond to and mitigate it. </div> --- ## What happens after you discover a 0-day? If you discover a security vulnerability, you have a few different options: <div class="fragment semi-fade-out" data-fragment-index=0> - Sit on it / do nothing </div> <div class="fragment fade-in-then-semi-out" data-fragment-index=0> - Try to sell it, if you're okay with living in the extremely morally ambiguous world of exploit acquisition :( </div> <div class="fragment fade-in-then-semi-out" data-fragment-index=1> - Submit it to a bug bounty program! </div> <div class="fragment" data-fragment-index=2> - Report it to the software vendor </div> --- ## Bug bounty programs <div class="container"> <div class="col"> Many companies have established _**bug bounty programs**_ as part of their security program. These programs incentivize security researchers to submit reports for security vulnerabilities with monetary compensation. </div> <div class="col" style="display: flex; align-items: center;"> <figure> <img src="../../img/misc/hackerone.svg"style="width: 100%;"> <figcaption> *Source: [HackerOne](https://www.hackerone.com/)* </figcaption> </figure> </div> </div> notes: HackerOne "Hacktivity" page reporting various recent bounties: https://hackerone.com/hacktivity Recent Apache Airflow report: https://hackerone.com/reports/1671140 Google's bug bounty program: - https://bughunters.google.com/about/rules/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules --- ## Ethical disclosure <div class="fragment semi-fade-out" data-fragment-index=0> What if a vendor refuses to patch the bug or acknowledge it as a security vulnerability? </div> <div class="fragment fade-in-then-semi-out" data-fragment-index=0> - Users of software should be made of aware of security vulnerabilities so that they can mitigate them and apply patches. - Vendors should be held accountable and prioritize customers' safety. </div> <div class="fragment" data-fragment-index=1> _**Ethical disclosure:**_ how do you publicly disclose a security bug while ensuring that vendors and users have the time to patch and mitigate the bug? </div> --- ## Ethical disclosure Over time, the *90-day* disclosure deadline has become the industry standard for vulnerability disclosure. <figure> <img src="../../img/misc/google_vulnerability_policy.webp"style="max-height: 30vh;"> <figcaption> *Source: [Google](https://about.google/appsecurity/)* </figcaption> </figure> --- ## Ethical disclosure <div class="fragment semi-fade-out" data-fragment-index=0> **90-day policy:** vendors are given 90 days to respond to a security vulnerability. After that time, details about the vulnerability are shared with the security community (or sooner if the bug is patched before the deadline). </div> <div class="fragment" data-fragment-index=0> If a bug is being actively exploited "in the wild", this timeline is often moved up considerably so that defenders can mitigate even if a patch is not available. </div> --- ## CVEs <div class="fragment semi-fade-out" data-fragment-index=0> The _**Common Vulnerabilities and Exposures (CVE)**_ program is a database of vulnerabilities that have been identified for common software. </div> <div class="fragment" data-fragment-index=0> Vulnerabilities can be reported to a _**CVE Numbering Authority (CNA)**_ to be assessed and assigned a CVE ID. This makes it easier to patch and distribute information about the vulnerability. </div> --- ## CVEs _**Example:**_ this is the CVE list (as of late September 2022) for Apache HTTP Server. <figure> <img src="../../img/misc/httpd_cves.webp"style="max-height: 30vh;"> <figcaption> *Source: [MITRE](https://www.cve.org)* </figcaption> </figure> === ## Offensive security: closing remarks --- ## Offensive security: closing remarks <div class="container"> <div class="col"> <div class="fragment semi-fade-out" data-fragment-index=0> We've spent the last few weeks (loosely) following the cyber kill chain and exploring the different components of an attack. </div> <div class="fragment" data-fragment-index=0> Now we can step back and start asking how to *mitigate* and *respond to* these attacks. </div> </div> <div class="col"> <div class="image-background"> <figure> <img src="../../img/intro/cyber_kill_chain.drawio.png"style="max-height: 50vh;"> <figcaption> </figcaption> </figure> </div> </div> </div> --- ## Offensive security: closing remarks <div class="r-stack"> <div class="fragment fade-out" data-fragment-index=0> For example, think back to our discussion on Drovorub. What are some measures that a defender could have taken against it? </div> <div class="fragment fade-in-then-out" data-fragment-index=0> _**Drovorub-kernel:**_ we saw how dangerous kernel modules were when we talked about rootkits and persistence! It shouldn't be possible to load kernel modules that don't come from a trusted provider. _**Mitigation:**_ cryptographic signatures </div> <div class="fragment" data-fragment-index=1> _**Drovorub-client:**_ the implant runs in userspace and has some unique communication mechanisms (e.g. WebSockets-based communications). How can we detect it? _**Mitigation:**_ YARA rules (file-level), Snort rules (network-level) </div> </div> <figure> <img src="../../img/malware/drovorub_components.webp"style="max-height: 30vh;"> <figcaption> </figcaption> </figure> --- ## Offensive security: closing remarks As we discuss the defense, we will look for _**actionable**_ defenses that we can implement and that are appropriate for the defender's _**threat model**_.