Don't like this style? Click here to change it! blue.css

Welcome .... Click here to logout

Class 0: ((((Why) teach) this) way)?

Secure Software Design

Let's start with a video:

Why teach this, this way?

Zero-Days vs Script Kiddies

There are two types of attacks we can prepare for:

  1. Very common, every day torrent of attacks
  2. Very rare, nation-state level, advanced persistent threats

Preparing for the first, script kiddie style, attack model is important but easier for you to pick up on the job.

Preparing for the second, APTs and zero-days, that is much harder and this course is just the start.

I'm choosing to aim higher. Let's teach the thing that is rare and difficulty and will push you.

But since the first is common and a reasonable expectation for an undergrad class let's just talk about it real-quick:

Good things to know (that I am NOT planning on emphasizing):

Secure Software Design - the standard way:

Third Party Software

Most of the software you write will never end up with exploit scripts in metasploit.

But almost all of the software you write will end up using standard libraries that are in metasploit/nessus common vulnerability scanners.

So standard advice part 1: always patch when possible and scan your stack regularly

Secure Software Lifecycles

Traditional secure software design is really about process more than practice.

If you go to work at Microsoft or some such place, you'll have code review with a security mindset.

The code goes through a whole iteration process before making it to production. That sort of process is very valuable, but slows down delivery time a lot. You'll learn these things on the job and you can prep for it relatively quickly.

Best Practices

In previous versions of this class I've concentrated the attention almost entirely on preventative practices. Super sensible to spend time learning and practicing good code practices that prevent your code from becoming featured on metasploit.

Here is the best set of said practices I know of: SEI CERT Coding Practices

When we get to the heap if you're interested in doing a study of these as an alternative let me know and I can give some of you a different version of the last chunk of the class.

Static Analysis

Making a habit of testing your code with static analysis tools, like rose checkers or linters, can help you catch bugs before you release them.

This again fits the sort of process-oriented version of secure software design.

What I AM planning on:

Threat Hunting and zero-days

This course is instead going to take an offensive cyber perspective.

No code is bug-free, always be hunting, and everything above this line is created to stop what you will learn in the harder version of the class that I will teach instead.

We will take the approach of existing code, that your company is using, running on servers (internal or external).

You are tasked with deciding how to fully exploit a given binary.

The binaries I give you will start with lots of vulnerabilities and you will learn the craft of zero-day hunting on these easily exploited programs.

As the course progresses we will steadily protect the binaries better and better until, at the very end of the course, you will have the opportunity to exploit a program which is completely fortified and on the most recent operating systems.

This is a much harder task than simply learning good practices that you hope protect you.

Creating an exploit is ten times harder than preventing an exploit.

So why do it the hard way?

When a student learns a good practice without facing the actual problem that it avoids the student becomes dogmatic and superstituous.

This is true for every bit of advice you've ever gotten, from variable naming conventions to dating advice.

Following advice that you haven't earned might avoid problems but it keeps you from being the originator of future advice.

I believe that showing you real exploits on real software will show you WHY the good practices exist. It will also make you a very valuable insight into how the highest levels of cyber really work.

You'll also become a lot better at understanding how computers really work.

It is up to you to finish the task that we won't have time to finish.

That is: once you know these things, meditate on them in the context of the daily battles.

OK, but why x86?

Well, it's the primary architecture for the vast majority of the world's processors.

Yes there are many others, but this one is the most common and I would argue the most valuable to learn.

If you learn how to do linux x86 executable exploitation then transitioning to arm or windows or even NES exploitation will be much easier from the framework of one you know really well.

What about the CTF stuff?

So CTFs are my favorite way to teach the right type of gritty, out-of-the-box creative problem solving, that the world really needs right now. This course will make you better at any CTF problem labelled PWN or REV.

CTFs act as nice way to gamify this topic. The dopamine hit is real and I hope it can make the hours pass pleasantly.

We happen to have a top CTF team and this is one of the more important topics to know well to do well in CTFs.

Being a good CTFer is seen roughly equivalent with advanced cyber certs to HR folks in the know.