Lecture 1-1

CIA Triangle

Components
- Confidentiality: Keeping Data private, only authorized users and processes should be able to access or modify data
- Integrity: System and data have not been improperly altered, data should be maintained in a correct state and nobody should be able to improperly modify it, either accidentally or maliciously
- Availability: The ability to use the system as anticipated

Security Design

How to define a secure system?
- Secure physical facility
- Contactless payment protocol
- Online database
- Private online communication
We need a specified security policy to define a secure system, how to define a security policy?
What should Policy address?
- Threat Model
  - Threats (Attacker-centric)
  - Vulnerabilities (System-centric)
  - Likelihood
  - Impact (Asset-centric)
  - Protection (Cost)
Security Policy is a type of risk assessment
Threats (Who is the adversary?)
- Consider adversary across 2 dimensions:
  - Capabilities: Who are they?
  - Motivation: Why do they do it?
Vulnerabilities (where can system break?)
- Define vulnerabilities with respect to threats
- Threat v.s. Vulnerabilities
  - If there is a water pool, threat is water may overflow, vulnerability may be a crack of the pool
Likelihood (might this happen?)
- Define likelihood with respect to vulnerabilities
- Vulnerability vs. Likelihood
  - Zero if we never add water
Impact (what if bad things happen?)
- Define impact with respect to threat
- Threat? Water might overflow. Impact? Depends on what’s nearby.
Protection (what does it cost?)
- most of academic computer security is protection

Competing Philosophies

Binary Model
- Secure or Insecure
  - Binary Model is longevity but also brittle and expensive
Risk Management Model
- It minimise the biggest threats and focus on the cost
- It is adaptive but the solutions are usually quite reactive so lead to Arms Race

Is the System Secure?

Security is not an absolute property, depends on having a good threat model that captures a range of adversarial behaviours

Security Mechanism

A system is “secure” if there is a security argument that an adversary constrained by a specific threat model cannot violate the security policy

Security argument: rigorous argument that the security mechanisms are maintaining the security policy (subject to the assumptions of the threat model)

Security mechanism: Technical mechanism used to ensure that the security policy is not violated by an adversary operating within the threat model

Lecture 1-2

Security and Human Behavior

Information Security

Digital Security: E.g. Files and web-access to servers

Physical Security: Files can be printed and stored on USB storage device and servers can be in a locked room

Availability - further definitions

Availbility is “the property of a system or a system resource being uable/ upon demand”

If availability is a requirement, an unusable system cannot be regarded as secure

Usability

Considering what a person (a ‘user’) wants to achieve (their ‘primary task’ toward an outcome) provides an approximation of the context of use

Risk Analysis and Risk Perception

Security Theatre

Aim of security measures is not always to increase actual security

Security Theatre: When the purpose of a security measure is to increase perceived, rather than actual, security

Lecture 2-1

Security Mechanism

Security mechanism: Technical mechanism used to ensure that the security policy is not violated by an adversary operating within the threat model

Could be software, hardware, cryptography, or peoples and procedures — this is why we’ll learn about all of these!

Design Principles

Least privilege

The principle of least privilege works by allowing only enough access to perform the required job. In an IT environment, adhering to the principle of least privilege reduces the risk of attackers gaining access to critical systems or sensitive data by compromising a low-level user account, device, or application.

Separation of responsibilities

E.g. For the system maintenance, there will be database admin, antivirus manager, and front-end engineer.

Everyone or every section of the system takes responsibility

Complete mediation

The principle of complete mediation requires that all accesses to objects be checked to ensure that they are allowed. Whenever a subject attempts to read an object, the operating system should mediate the action.

Fail-safe default

The principle of fail-safe defaults states that, unless a subject is given explicit access to an object, it should be denied access to that object. This principle requires that the default access to an object is none.

Defence in Depth

Defense in depth defined. Defense in Depth (DiD) is an approach to cybersecurity in which a series of defensive mechanisms are layered in order to protect valuable data and information. If one mechanism fails, another steps up immediately to thwart an attack.

Open Design

The principle of open design states that the security of a mechanism should not depend on the secrecy of its design or implementation. Designers and implementers of a program must not depend on secrecy of the details of their design and implementation to ensure security.

Psychological Acceptability

The principle of psychological acceptability states that security mechanisms should not make the resource more difficult to access than if the security mechanisms were not present. Configuring and executing a program should be as easy and as intuitive as possible, and any output should be clear, direct, and useful.

Economy of Mechanisms

KISS Principle: Keep it simple, stupid!

The principle of economy of mechanism states that security mechanisms should be as simple as possible. If a design and implementation are simple, fewer possibilities exist for errors. The checking and testing process is less complex, because fewer components and cases need to be tested.

Privacy Promotion

Don’t collect more data than strictly necessary

Fundamentals of Computer Architecture Design

Code is data
Layers of abstraction
Moore’s law
Halting problem

von Neumann Computer Architecture

von Neumann computer architecture does not distinguish between instructions for computer programs and data
Consequently, Code is data
- Enables great flexibility in reprogramming computers
- Programs can be costlessly reproduced, not just data
There are unfortunate security implications

Layers of Abstraction

Abstraction: specifying meaning and behaviour of software while hiding implementation details
Modular code exploits abstraction and enables composition and reuse
Abstraction and code modularity enables rapid software development (which has in turn led to a rapid rise in software complexity)
Unlike for mechanical engineering, in software engineering there is no practical limit to the potential combinations of code

Moore’s Law

Intel founder Gordon Moore noticed in 1965 that integrated circuit density had been doubling since the 1950s
Moore’s Law: computer performance roughly doubles every 18-24 months

Halting Problem

In 1936, Alan Turing proved that it is impossible to write a general- purpose program that can determine whether another program will stop
Can be generalised: anything sufficiently interesting cannot be determined about a program
Implication: Security can never be solved!

Lecture 2-2

How does the Internet work?

http://me.bob.com/hi.html
- http:: protocol specifier
- me.bob.com: domain name
- hi.html: page location

Step1: find content host

Goal: get IP address for domain name

Find root Name Server
Find .com Name Server
Send ip(.com NS)
Get ip(bob.com NS)
Find bob.com NS
Send ip(bob.com NS)
Get ip(me.bob.com NS)
Find me.bob.com NS
Send ip(me.bob.com NS)
Get ip(me.bob.com)
Send back to the browser

Step 2: request content

Where is the Internet?
- “the Internet is […] a series of tubes” (Senator Ted Stevens)
- Leased Lines
  - pros
    - incredibly fast
    - reliable
    - secure
  - cons
    - Incredibly expensive
- Internet Backbone
q: how does your router pick another router to ask?

a: fascinating topic! autonomous systems (ASes), BGP, etc.
q: how do you actually find these name servers?

a: the magic of routing!
q: what information are these routers sending?

a: packets.
q: could requests just go around in a circle?

a: no! packets contain information on when to give up. Time to live (TTL): how many hops before dying?

(decremented by each router; also used for DNS records)
Proxy Server and VPNs
- pros
  - get around firewalls
  - borrow access credentials

Step3: Receive Content

Content at hi.html is split into packets
Anyone can read the web traffic

Overview

goal: get Alice to that website!
get IP address for me.bob.com (“domain name resolution”)
send GET request to IP address (routing via the internet backbone)
wait for response from IP address, then render hi.html and enjoy

What Webpages are Made Of

HTML

Markup language
HTML5 added interactive components:
- Canvas
- Audio
- Video

CSS

Style language
Built to separate content from style
CSS3 — built in tandem with HTML5

JavaScript

Scripting language (similar to Python) • Server side (NodeJS)
Client side
Stateless

Cookies

Used to store state on user’s machine
Name, value, attributes: • expiration date
hostname valid for
Secure (?)
- only over HTTPS
- HTTPOnly (?)
- not over JavaScript

Lecture 3-1

Web Architecture

Websites are programs: HTML + CSS + JSS + Plugins

Partially executed by the client (HTML, JavaScript, plugins, etc.)
Partially executed by the server (PHP, Ruby, SQL, etc.)

Web Server

It serves Static Content (HTML + CSS pages)

And it also generates Dynamic Content:

CGI (Conmmon Gateway Interface): PHP, Python, etc
Web server modules: Rails, etc
Database Backend: SQL

Web Cookies

The web server provides a token in its response that looks like:

Set-Cookie:<cookie-name>=<cookie-value>

This is then attached to every future request sent to the server

Kinds of cookies:

Session cookies
- Deleted when the user close the browser
- Expiration property is not set
Persistent cookies
- A persistent cookie is a data file capable of providing websites with user preferences, settings and information for future visits.
- Are saved until some server-defined expiration

JavaScript

Same-origin policy: script can read properties of documents only from the same server, protocol, and port

But, same-origin policy does not apply to scripts loaded from arbitrary site, so

1	<script type="text/javascript" src="http://www.example.com/myscript.js"></script>

runs as if it were loaded from the site that provided the page!

Server can also explicitly tell browser other domains that are allowed using Access-Control-Allow-Origin header

HTML Injection

Many interactive web applications echo user input:

Search queries

What if user input contains HTML markup tags?

Similar story as with SQL injection: if the server doesn’t sanitise and encode it, markup is rendered by the web browser as it is provided by any user of the website

Cross Site Scripting

A vulnerability that allows an attacker to run JavaScript on a victim webpage

Type of XSS

Methods for injecting malicious code:
- Reflected XSS
  - the attack script is reflected back to the user as part of a page from the victim site
- Persistant/Stored XSS
  - the attacker stores the malicious code in a resource managed by the web application, such as a database
- Others, such as DOM-based attackers

Reflected XSS

A reflected XSS (or also called a non-persistent XSS attack) is a specific type of XSS whose malicious script bounces off of another website to the victim’s browser. It is passed in the query, typically, in the URL. It makes exploitation as easy as tricking a user to click on a link.

E.g.
- PayPal 2006
- Attackers contacted users via email and fooled them into accessing a particular URL hosted on the legitimate PayPal website.
- Injected code redirected PayPal visitors to a page warning users their accounts had been compromised.
- Victims were then redirected to a phishing site and prompted to enter sensitive financial data.

Persistant XSS

XSS attacks enable attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.

Protecting Against XSS

Validates all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed.
Do not attempt to identify active content and remove, filter, or sanitize it. There are too many types of active content and too many ways of encoding it to get around filters for such content.
Adopt a ‘positive’ security policy that specifies what is allowed. ‘Negative’ or attack signature based policies are difficult to maintain and are likely to be incomplete.

Input Data Validation + Filtering

allow only what you expect
Remove/encode special characters

Output filtering/encoding

Remove / encode HTML special chars
- < for <, > for >, &quot for “
Allow only safe commands (e.g., no <script>…)
- Caution: filter evasion tricks
See XSS Cheat Sheet for filter evasion
E.g., if filter allows quoting (of <script> etc.), use malformed quoting: <IMG “””><SCRIPT>alert(“XSS”)

CSRF (Cross Site Request Forgery)

Ineffective Defense: POST

GET requests are easier to launch CSRF attacks, so some people naively switch to POSTs
This does not help

Ineffective Defense: URL Rewriting

dangerous to pass auth tokens in URLs (middleperson, logging issues)

Imperfect Defense: Referer Validation

Does not work if Referer is missing
Referer Privacy Problems
- HTTP Referer may leak privacy-sensitive information
- Common sources of blocking:
  - Network stripping by the organisation
  - Network stripping by the local machine
  - Stripped by browser for HTTPS -> HTTP transitions

Denfense

Form keys
CSRF tokens
- Requests include a hard-to-guess secret
  - Unguessability substitutes for unforgeability
Short cookies expiration date
Encourage users to log out

Double-Submitted Cookies

Instead of writing separate nonce, re-use the session ID
When server replies to user, writes session ID to cookie as usual, plus writes into hidden form field
User posts form with value from hidden field and cookie, server verifies these are same
Why does this defence work?
- Attacker cannot reliably guess session ID (unless there is also an XSS vuln)
Solution is completely stateless
Downside: passing session IDs in HTTP requests and responses is risky
- Solution: put hash(session ID) in hidden form field instead

XSS v.s CSRF

XSS

Server-side vulnerability
Attacker injects a script into the trusted website Trusting browser executes attacker’s script

CSRF

Server-side vulnerability
Attacker gets trusted browser to issue requests Trusting website executes attacker’s requests

Lecture 3-2

(Code Injection + Return-oriented Programming)

Code Injection Attacks

Attacker executes arbitrary code on Server

Not Sanitising user inputs/outputs

Unintended Functionality

Security involves understanding both intended and unintended functionalities of the system.

An exploit is a mechanism by which an attacker triggers some unintended functionality of the system (it is a blind spot for the developers)

What makes security special?

These properties must hold even in the presence of a resourceful and strategic adversary

Correctness: For a given input, a program should provide the correct output

Safety: Well-formed programs cannot have bad (wrong or dangerous) outputs, no matter the input

Robustness: Programs should be able to cope with errors in execution

Software Vulnerability

A software vulnerability is a bug in a program that allows a user capabilities that should be denied to them
One very common type of vulnerability is ones that violate control flow integrity (CFI)

Today we’ll look at SQL injections and buffer overflows

SQL Injection

Post malicious input to form
1. SQL Injection Based on 1=1 is Always True
  1
  2
  txtUserId = getRequestString("UserId");
  txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
  If users enter inputs like: UserID 105 OR 1=1, then the SQL statement will look like this:
  1
  SELECT * FROM Users WHERE UserId = 105 OR 1=1;
  The SQL above is valid and will return ALL rows from the “Users” table, since OR 1=1 is always TRUE.
2. SQL Injection Based on “”=”” is Always True
  1
  2
  3
  4
  uName = getRequestString("username");
  uPass = getRequestString("userpassword");
  
  sql = 'SELECT * FROM Users WHERE Name ="' + uName + '" AND Pass ="' + uPass + '"'
  A hacker might get access to user names and passwords in a database by simply inserting “ OR “”=” into the user name or password text box:
  
  User Name: " OR ""="
  
  Password: " OR ""="
  
  The code at the server will create a valid SQL statement like this:
  1
  SELECT * FROM Users WHERE Name ="" OR ""="" AND Pass ="" OR ""=""
  The SQL above is valid and will return all rows from the “Users” table, since OR “”=”” is always TRUE.
Requests unintended SQL query
Returns unintended data to attacker

SQL Injection Mitigations

Server-side applications generate SQL queries based on arbitrary user input

Solution? Don’t accept arbitrary user input!

Parameterised queries: pre-compiled queries that separate commands from input

Input sanitisation: make sure only safe input is accepted What is unsafe?

Single quote? Dashes? But these could be legitimate Sanitise on the client or the server
- Use proper escaping/encoding?

Buffer Overflows

Program variables get allocated regions of physical memory in the form of buffers

Buffer overflows happen when a program writes data beyond its allocated buffers

These are ubiquitous in systems-level languages (C/C++), made worse by the fact that many standard library functions make it easy to go beyond array bounds

String functions like strcpy() and strcat() write to the destination buffer until they encounter \0 in input, so the user providing the input (who can easily be the attacker!) controls how much gets written

Memory Allocation of Programs

The computer keeps track using a Stack when you make fucntion calls

Call Frame

When a function is called:

Allocate new frame for the callee
Caller pushes arguments and return address
Callee:
- pushes old frame pointer (fp): this points to bottom of frame of currently executing function
- Sets fp = sp (stack pointer): this points to top of stack

When a fucntion is returned:

Callee pops local storage and sets sp = fp
Callee pops fp(frame pointer)
Callee pops return address and returns to next instruction in caller frame

Smashing the Stack

What happens if you overwrite a malicious value past the bounds of a local variable?

Could overwrite:

another local variable
- What happens if you overwrite another local variable?
- It depends.
Saved fp
- What happens if you overwrite the saved fp?
- Probably terrible things!
  - When the function returns, the stack moves to an attacker-supplied address ⇒ complete control of execution
  - Even a single byte may be enough for this attack
return address
- What happens if you overwrite the return address?
- Terrible things!
- When the function returns, control is transferred to an attacker-supplied address ⇒ complete control of arbitrary code execution (re-direct to their own code)
function argument
Deeper stack framess
exception control data

Shellcode

Shellcode is defined as a set of instructions injected and then executed by an exploited program. Shellcode is used to directly manipulate registers and the functionality of a exploited program.s

Attacker ensures shellcode is somewhere in the stack before overwriting return address but they might not know exactly where it is

NOP sleds

Instead, attacker can rely on the NOP (“no- op”) instruction to create something called a

NOP sled (or a NOP slide)

As long as the attacker’s guess lands somewhere in this sequence of NOPs they can jump at the end to the start of the shellcode as desired

DEP

Data Execution Prevention
Maybe not everything needs to be executable?

ASLR

Randomisess address space
Now an attacker need to guess even more where they will land

Stack Canaries

Write a random value to the end of the frame at the beginning of a function call.
Check that it is still there at the end.
If it’s not, then throw an error.