Skip to content

Latest commit

 

History

History
173 lines (119 loc) · 7.45 KB

Conclusion.md

File metadata and controls

173 lines (119 loc) · 7.45 KB
Raw
layout title permalink nav_order image description author
default
Conclusion
/docs/Conclusion
9
/assets/images/casey-horner-RmoWqDCqN2E-unsplash.jpg
Let CVEs be your north star to start to understand the primary security issues with the component you are researching.
clearbluejar

Conclusion

casey-horner-RmoWqDCqN2E-unsplash Photo by Casey Horner Unsplash

This last section attempts to wrap up the primary ideas and leave some parting thoughts.

Table of Contents

  • toc {:toc}

So far we have covered the 3 primary techniques to help you leverage CVEs as North Stars for vulnerability research:

  • CVE analysis a chance to take a deeper look at a CVE leveraging public sources and information.
  • Patch Diffing a deeper look at the CVE vulnerability and a chance to gain deeper insight. An attempt at binary truth. Observing the actual changes to "fix" a vulnerable binary.
  • Root Cause Analysis a best effort to understand the underlying vulnerability related to a CVE or vulnerability class.

The next step is to leverage new insights obtained in the previous steps.

Developing a Novel Understanding

The techniques learned in this tutorial can help you progress from knowing about a vulnerability to understanding it.

graph TD;

classDef current fill:#00cc66;

J:::current;

A1[ CVE Research]
A1 --> F[CVE Analysis + Patch Diffing];
F --> I[System Comprehension]
F --> G[Vulnerability Classification];
F --> H[Root Cause Identification];
G --> J[Develop Mitigation Requirements / Novel Understanding];
H --> J;
I --> J;
Loading

Each CVE provides a bit of insight into the security flaws present within a code base. You might say each CVE provides a learning opportunity, and Spooler has been and continues to be a prolific teacher.

gantt

title Windows Print Spooler CVEs
dateFormat YYYY-MM-DD
axisFormat %Y-%m
todayMarker off

section CVE Release Dates
section 2021-Jun
CVE-2021-1675 :cve42, 2021-06-08, 30d
section 2021-Mar
CVE-2021-26878 :cve43, 2021-03-11, 30d
CVE-2021-1640 :cve44, 2021-03-11, 30d
section 2021-Jan
CVE-2021-1695 :cve45, 2021-01-12, 30d
section 2020-Nov
CVE-2020-17001 :cve46, 2020-11-11, 30d
CVE-2020-17014 :cve47, 2020-11-11, 30d
CVE-2020-17042 :cve48, 2020-11-11, 30d
section 2020-Sep
CVE-2020-1030 :cve49, 2020-09-11, 30d
section 2020-Aug
CVE-2020-1337 :cve50, 2020-08-17, 30d
section 2020-May
CVE-2020-1048 :cve51, 2020-05-21, 30d
CVE-2020-1070 :cve52, 2020-05-21, 30d
section 2019-Apr
CVE-2019-0759 :cve53, 2019-04-09, 30d
Loading

Our path of studying the Windows Print Spooler CVEs has granted us a better understanding of the types of vulnerabilities within Spooler, the security boundaries crossed by previous CVEs, and a clear picture of the underlying issues that caused previous attempts to fix the CVEs to fail.

Our novel understanding has come from our analysis and effort. The challenge now as a researcher is to leverage your novel understanding for discovery of the next vulnerability.

Discovery - Exercise for the Researcher

graph TD;

classDef current fill:#00cc66;

K:::current;

A1[ CVE Research] --> A[CVE-2020-1048];
A1 --> B[CVE-2020-1337];
A1 --> C[CVE-2020-17001];
A1 --> D[CVE-2010-2729];
A1 --> E[CVE-2020-1030];
A --> F[CVE Analysis + Patch Diffing];
B --> F;
C --> F;
D --> F;
E --> F;
F --> I[System Comprehension]
F --> G[Vulnerability Classification];
F --> H[Root Cause Identification];
G --> J[Develop Mitigation Requirements / Novel Understanding];
H --> J;
I --> J;
J --> K[Discover New and/or Related Vulnerabilities]
Loading

This discovery step is left as an exercise for the researcher. There are plenty of public examples of researchers using CVEs as a starting point for their research that result in a new discovery:

The end goal doesn't always have to be a new vulnerability, here are some examples of leveraging CVEs for understanding:

Parting Thoughts

Applicability

While this writing was mostly about Windows, the ideas found here can be applied to other platforms. While patch diffing is mostly useful for closed source platforms and software, it still can be used with open source to give you insight to specific changes across time that are sometimes easier to see with "binary truth".

CVE Analysis In the Light

When there are public reports and PoCs, use those via CVE analysis increase your understanding about the vulnerability and try to understand the root cause. Don't take the report as final though, as code is ever changing. Also, you might be able to see a bit further that the researcher writing the report, or understand ways in which a patch might have not fixed the root cause. This can lead to discovery of new vulnerabilities or variants.

Patch Diff In the Dark

When there are no public writeups or PoCs, and all you have is a CVE description, you are not lost.

Remember patch diffing is:

  • is a single source of truth when there is no other information
  • provides clarity in vulnerability comprehension and discovery
  • can be an excellent candidate for improving your competence via deliberate practice. It is complex and challenging yet tractable with the help of today's SRE tooling.

Try It

Hopefully, this tutorial inspires you to start a new research project or helps you find motivation to continue your current one. Go ahead, find a CVE and begin.

Let CVEs be your North Star in your next vulnerability hunting adventure.

If you enjoyed this, consider following me on twitter or giving the cve-north-stars repo a star. I'll be sure to post links and updates as they develop.

Follow @clearbluejar{: .btn .btn-blue .fs-3 .mb-4 .mb-md-0 .mr-2 } Star cve-north-stars {: .btn .fs-3 .mb-4 .mb-md-0 }

Also, consider leaving feedback on Github to help me improve my writing and this tutorial.

Leave Feedback{: .btn .btn-primary .fs-3 .mb-4 .mb-md-0 .mr-2 }