SEATS AVAILABLE: CLASS CANCELLED
Checking Java software for the absence of vulnerabilities typically includes review of the source code, which in most cases is Java code. This is where the tools and toys of the software industry can help you with. But for a complete understanding you may need to understand the third party dependencies, which may be written in Scala, JShell, Groovy
or other, or even be available as compiled bytecode, or written in C/C++ and provided in a native iibrary (JNI). No worries, you don't need to learn these languages too, you need to know what is important to look for, and that can be different for each of the above code sources.
- You will start with a brief walkthrough of the Java Security
architecture, following by a first round of presenting usual suspects
that may cause security problems
- To practically manifest the above list of culprits we present a range
of tools to allow basic scanning of software projects, we will see what this tools can do, we will see where these tools fail, and how to
construct code that bypass checks in these tools
- You will learn about usage patterns with advanced APIs (Reflection,
MethodHandles, scripting extensions), and also about typical
antipatterns that cause security fails. This is followed by a history of
flaws in typical 3rd party libraries and frameworks (Apache, Spring). At this point it is good to learn about the typical categorization schemes (such as CVE, CWE) and learn about strategies to find more information than the typical advisories and update reports tell you.
- This day will be completed with a practical session a scavenger hunt
of live Java projects on Github. Everything you find there could be
your first 0-day, and all we care for is defense, so at this point you
could also learn how to write a good security patch and how to submit it to the vendor.
- This day starts with a brief introduction to the relevant guidelines
to writing secure Java software (Oracle Secure Coding Guidelines, CERT SEI), where to find those being supported by tools, or write your own tool extensions (we will cover SpotBugs and PMD, as well as a standalone scanner).
- We now enter the areas, where Java code security is influenced by the security level of dependencies, such as code supplied in Jars without source code, or written in native code. We learn about bytecode, decompilers and native debuggers. We learn about to tools to generate bytecode, but also those tools for a better understanding of what goes on inside the JVM when the JIT compilers sets in or a garbage collection occurs (and how that that reletes to the source code).
- Next on the agenda are typical server-side scenarios, such as bugs in web servers and web applications, the goal is to show how integrity of remote systems could be compromised and how protection mechanisms can be constructed.
- A security training would not be complete without a fuzzing session, therefore we dive into the wonderful world of mutated data and code coverage by the help of AFL, Kelinci and JQF. Of course, to comply with the training goal we analyze the findings on a source code level and try to come up with good patches.
- To wrap up the training we now enter the topic of malware, and how to adapt and identify the coding skills used to construct it. This lesson will be important to understand that code scanning tools can only be of help if the author of the software we analyzed is coded by the book. We will learn about typical obfuscation tools and about a systematic behavior-based approach to work around obfuscation.
For the training you should be familiar with:
- Developing software in Java
- Be able to use the editor and compiler with elegance
- Have a basic understanding about typical threats that may hide in software.
- Please bring a machine with a working docker installation
- An image with tools and examples will be provided at the beginning of the course.
- You may want to have 20GB free.