Soma-notes - User contributions [en]

SystemsSec 2018W Lecture 16

2018-03-25T03:58:39Z

Trent: separated definitions of signature based/specification based/anomaly dection intrusion detection from host based/network based/hybrid. Updated definitions.

==Audio==

[https://homeostasis.scs.carleton.ca/~soma/systemssec-2018w/lectures/comp4108-2018w-lec16-12Mar2018.m4a Lecture 16 Audio]

=='''Intrusion Detection'''==

Intrusion detection is normally an underappreciated aspect of Internet Security. Alerts are sent when we don’t know or we're not confident what the network traffic is.
Why Intrusion detection matters:
1) Firewalls are not as effective.
2) Firewalls have limitations.

Intrusion detection is not anti-malware. It is meant to detect intrusions, but it may involve malware.

==Intrusion vs. malware==

-ex. industrial espionage: We want access to a competitors system.
OPTIONS:
1) Gain access by malware via email or link etc.
2) Password hack as alternative.
3) Call help desk and impersonate.

- In each example our goals have been satisfied but the means are different.
- intrusion detection focuses on the goals of the attacker and to stop them.
- The attacker can still gain access by intrusion without using malware.

==Three main methods of Intrusion Detection==

1) Signature based - pattern recognition. You have a blacklist of signatures of attacks, and if it matches a signature, a warning is issued.
2) Specification based - based on rules. A whitelist of normal system specifications. If something not on your list is detected, a warning is issued.
3) Anomaly Detection - Normal vs abnormal. You have some way of detecting "weird". Implies something adaptive.
Any of these 3 types of intrusion detection can be host based, network based, or hybrid (combination of host and network)

==IDS In Linux==
1) Snort - Signature Based Detection
2) Bro - Specification Based Detection

Each method has a cost which has to be weighed ie. cpu cycles, to many false alarms and etc.

==Signature Based==

Is based on code pattern and code expressions ie. worms and bytes associated the worm, regex and Bad packets
- Involves white list
- We must know what signatures belong to the list there is no limit to bad signatures.
- Only “known” attacks can be caught.
- How do you match bad code with legit behaviours?
- Easily evaded. Can hide code signature???

- Since we don't know for sure which signatures belong on the list. The network will generate lots of alarms, to lower false positives the detection rules may be adjusted which may
compromise the system.

- Why not update to defend code signatures? May effect existing software.

==Specification based==

We know how the systems behaviour and rules on how it operate. Involves blacklists

For Example: Assume three clients: A,B,C

Client A and B can communicate to each other: Client A <----> Client B
Client A and C can communicate to each other: Client A <----> Client C

But Client B can not talk to C

-If packets are rerouted throught Client B <------> Client C then we consider an attack took place.
-Can detect forged packets, specify the behaviour of every application.
-Each client needs a separate installation and is a different specification.
-In order for Specification Intrusion Detection to work we need to understand what are the networks need and to specify the rules.

-Vary rare that one person understand the entire network and is able to write the rules for every client.
-Borders on access control: Users will enable/disable permissions and will find methods to bypass access control.

==Anomaly Detection==

Whats normal vs whats abnormal? ie. computer is suddenly not running is it a driver issue? or actually malware?. Its adaptive, statistical information how the system behaves and deviations, involves some training.

-Example someone wearing a fluorescent shirt? But is it dangerous?
-We care only if its dangerous, a mix of dangerous and weird

-We Must define whats weird and its connection to dangerous ie. a person walking in with a bazooka vs awkard guy wearing the fluorescent shirt.

==History ( Anomaly Detection )==

In the 1970's Ross Anderson and the US Airforce had a problem. They had computers with sensitive data and were worried spies may extract information. Access control existed but wasn't the best idea.

MOS was then implemented to allow some users privileges to view these files based on levels.

The level of clearance according to level:

Top secret
secret
unclassified

Problem: The document may become top secret if only one word needs to be kept secret. The rest of the document may not have to be classified but the one word whould make the document classified. Gets complicated!!!.

Didn't work since it the level of clearance can be bypassed the same way passwords can be bypassed.

That's why audits were invented.

''Audit'''
An audit whould produce an audit trail of all the computer activities ie. log in,log out, what applications are being accessed and etc.

The idea was a security officer whould monitor and view the audit logs then investigate if suspicious activity was detected.The process was simmilar to a financial audit but the pattern recognition was based on computers.

Statistics based on a the audit trail whould be used to determine the users activities ie. how many times a user logged in.

The fundamental issue: 1) Creating a model of what a human is doing is difficult.
2) Auditing was created with the intention of a human doing the processing.
3) The computer does not have sufficient data to analyze.

Possible solutions: machine learning ?? neuronetworks?? Spy on your email ( foolish idea)!!!!
Why is it "foolish" 1) We must be able to model the real world
2) We can't learn everything based on the limited scope.
3) Assuming we really know someone?? Can we really perdict there behaviour? even surprises??

The computer can understand programs but not humans. It can detect weird program behaviour but not weird users and programs acting weird ie. backdoors and memory overflows.

SystemsSec 2018W Lecture 4

2018-01-17T18:16:42Z

Trent: Notes from class, first draft

= Notes =

Today we discussed psswd as a way of touching on a number of security topics

== passwd ==

*the linux program for modifying a user password
*seems like a simple program, but has a number of features that could present a security concern.
*where are they stored?
*used to be in one file, including the hashed passwords (/etc/passwd)
*problem is that data in that if attackers can read the hashes, the hash can be cracked.
*on more modern systems, this is split into /etc/passwd and /etc/shadow
*root owns the file
*in order to modify the password, the program needs root priveleges in the classic model
**this gives the program the ability to modify any file on the system

=== the setuid bit ===
*every process has a user id (uid) and a group id (gid). Every file has bits that set the permissions for the users and groups associated with it.
*in addition to the classic read, write and execute (rwx) for the uid and gid, there are also setuid and setgid (s) bits
*without the set bit, when a new process is created, execv loads the new process, but the uid and gid don't change.
*setuid bit allows the new process to be created with a new uid (effective uid). It runs with the priveleges associated with the new uid.

if a process has an effective uid of root, it can do basically anything to the system (the all powerful root model)

for a program like passwd, it may seem very simple, but it does lots of things, including things that might make the system vulnerable to attack.

*attack?
**the chroot option lets you change the etc/passwd for a subdirectory
**by using a symlink to a different file, you could take control of the system

in general, '''flexibility is the enemy of security'''
*more functionality means more corner cases, and more things that you haven't thought about.

how could we make the process less dangerous?

could we run it without full root priveleges?

we are going to have this binary. It will have root priveleges, it will have full control.
*how to we protect ourselves? what measures can we take?
**limit the scope of our mistakes
***limit the time that you have the dangerous priveleges
***limit the priveleges
***ideally audit to make sure that the priveleges were used appropriately.

Just knowing about basic mechanisms, what could we do?
*separate the part of the program that needs priveleges from the parts that don't.
*analyzing user input is the most dangerous part, and should be separated as much as possible from parts of the program with powerful privegeles
**malious input attacks

passwd is one of the simplest examples, and it touched on a number of topis:
*access control
*(least) privelege (time and space)
**for passwd, this can be a problem because there isa file with everyone's password information. In order to change this file, you need root priveleges.
***Could you change that basic premise? You would have to split it out so that everyone had there own separate passwd files. This could cause problems for legacy software, and

could even open up other potential security vulnerabilities.
*unsanitized input
**not all input is trusted. This what programs do: they process data.
*trust
**trust is hard.
**in computer security, trusted means that if it betrays you, it can hurt you.
**trust can be limited.
**like with people, applications should behave differently towards trusted and untrusted inputs
*kernel mechanisms
**the setuid bit
**if you have priveleges, they were usually granted by the kernel
*other attacks
**breaking the hash

== Similar problems ==

*What other command line tools have similar security issues?
**anything with the setuid bit, executables that run as other users.
*what binaries have setuid root?
**mount
**fuse
**cron
***for scheduling tasks.
**sudo
**ping

Determining access by users and groups is coarse.
*root is a collection of priveleges
**could we have a subset of these priveleges?
*capababilities
**a differnt way of thinking about access control
**you can drop capabilities that you don't need.
**however, some capabilies are still very powerful, ie modify files or modify devices
*there are more complex mechanism for access control and privileges, but they often aren't used. In order for something to be used effectively, it needs to be understandable to

people using it. Simple mechanisms remain widely used.

== Exercises ==
Two exercies will be posted:
*Write your own version of passwd
**any language
**setuid root and change password
**think through the features and the implementation, and she security issues tha arise.
**process input carefully and drop unneccessary privelegs.
**for the write up, not looking for documentation about perfectly working code. what went wrong, what paths did you take, what issues did you have, what did you learn?
*What priveleges are required for networking?
**what operations require higher priveleges.
**at first distinction, it may seems simple (users can use the network, root can modify)
***however it is more complex. Can an application set up connection to a new wifi access point?

If you have any ideas for exercises, feel free to discuss them in slack

Computer Systems Security (Winter 2018)

2018-01-17T17:00:14Z

Trent: /* January 14, 2018 */

'''This page is not yet finalized.'''

==Course Outline==

[[Computer Systems Security: Winter 2018 Course Outline|Course Outline]]

==Schedule==

===January 8, 2018===

[[SystemsSec 2018W Lecture 1|Introduction]]

===January 10, 2018===

[[SystemsSec 2018W Lecture 2|Threat Modelling]]

===January 12, 2018===

[[SystemsSec 2018W Lecture 3|Common tools]]

===January 17, 2018===

[[SystemsSec 2018W Lecture 4|passwd]]

===January 31, 2018===

Assignment 1 due

===February 14, 2018===

Assignment 2 due

===February 19 & 21, 2018===

Winter break, no classes

===February 26, 2018===

Mid-term review

===February 28, 2018===

Mid-term Exam

===March 19, 2018===

Assignment 3 due

===April 4, 2018===

Assignment 4 due

===April 9, 2018===

Last day of class

SystemsSec 2018W Lecture 1

2018-01-16T01:56:52Z

Trent: edits to format.

= Notes =
Class 1, January 8

== About the course: ==
Lectures will not be posted online.

Notes will be posted online.

In order to succeed, you need to come to class. Things will be discussed, and you need to be present.

* Grading Criteria
** Midterm 25%
** Final 35%
** Participation 10%
** Experiences 10%
** Assignments (4) 20%

The midterm and final will basically be short answer, possibly with some essay questions.

The assignments will be in the style of the midterm and final, and will let you know how prepared you are for the exams. 2 assignments before the midterm and 2 after the midterm.

Participation – being present, taking notes for the class, raising your hand, discussing things (not purely in class, also there will be a slack instance).

If for some reason participation will be a problem for you, email the professor now to work it out)

Experiences – in 2 portions reading and tools

Reading – submit a reading response. Make a diligent effort to understand the reading before coming to class. Not a summary. What was your interaction with the reading?

Tools – Computer Systems Security is fundamentally an applied field. It is tied to tools. Applied learning is important. Some exercises will be provided, but other things you will come across yourself (ie try to set up a firewall, or play around with iptables, you don’t have to succeed). Write a tool response. Plan on sitting down a couple of times and doing some hacking. It is important to get your hands dirty. To start, pick something that you can handle, and maybe ramp it up as the term goes along.

Assignments will be submitted through CULearn.

== The material covered today: ==
In the news recently: Meltdown and Spectre security flaws

Meltdown in the Intel version, Spectre is the more general version.

Basically every modern CPU that has high performance is affected

Problem with processor design.

Design strategy used to increase performance in modern processors allows for information leakage.

Software programs and processes don't trust each other (and they shouldn't), but this flaw means that the barriers between them aren't fixed, you can read across them.

It is a timing attack. The basis of timing attacks is that the time to compute depends on the data that you are computing. By knowing how long something takes to compute, you can figure out what is being computed.

There was previously a well known timing attack on public key encryption, which was solved by responding to all requests in the same constant time.

Meltdown and Spectre exploit branch predictors (ie, the processor speculates at which branch of the code will be run next and “runs ahead”. If it predicts correctly, there is a performance advantage). However, flaws were found that enabled kernel memory to be read, or a virtual machine to read data from another virtual machine running on the same processor. This particularly affects cloud computing.

These types of flaws come because no one was thinking about the design from a security point of view.

System Security is difficult. Attackers find flaws, defenders try to fix them. This happens in real systems, with enormous complexity. Theoretically we can design perfectly secure systems, but attackers will keep finding flaws. This game, as it is today, is weighted towards attackers. Rebalancing the game would require radical ideas.

=== A (noncomprehensive) list of some security tools and methods: ===
*The purpose of this list is to show what a vast area computer security is, not making a list of everything that will be covered.
**Firewalls
**Antivirus/Antimalware
**Network monitoring/NIDS
**Reverse engineering.
**Cryptography (encryption/digital signing) (for system security, encryption is a tool of last resort)
**Air gaps
**Social Engineering
**(D)DoS
**White list
**Black list
**One way info-gate
**Virtual machines
**Encapsulation
**Virtual memory
**Formal verification
**Randomization (ASLR)
**Passwords
**Captchas
**Biometrics
**Location monitoring
**Mandatory access control (ie SELinux, very inconvenient)
**Discretionary access control (traditional Unix, Windows…)
**Automatic memory management (garbage collection)
**Static analysis
**Dynamic analysis

Security can affect just about any area of computer science. If there I a branch that doesn’t appear to be affected by security, someone just hasn’t thought about it for long enough.

This course isn’t about a specific tool or method, although many will be touched on. Primarily, we want to look at how to think about problems so that you see security issues. What can I do as an attacker? What can I do as a defender.

There are always benefits and costs to any security decision, By strengthening security in one way, you can weaken it in another.

For example, if you can’t risk lockouts and downtime, having passwords could cause problems.

If you make usability too difficult, users can find ways to bypass your security measures. Security is always a secondary concern. The primary concerns of users are the tasks that they are using the computer systems to complete.

The most secure system is one that is off, in a locked room in a secure facility. However, that system is also completely useless.

Even if you do not become a computer security professional, you will design systems and make decisions that have security implications.

=== Reverse Engineering ===
Picked from the list at random to discuss

*What is it?
**Normal engineering process would be Design -> code -> system.
**Reverse engineering is reversing that process. Looking at the system to figure out the code and the design.

*Who?
**Attackers
***analyzing defenses
****If you can figure out how it works, then you can find weaknesses and exploit them.
You become an expert safecracker by learning about safes. In order to find flaws in systems you must have a deep knowledge of those systems. What an attacker wishes to attack he must master, and by finding the flaw, the attacker '''proves his knowledge'''. It is like solving a puzzle. That is what drives the people developing these attacks. The negative impacts are often secondary.

**Defenders
***Analyze defenses like attackers
***Analyze attacks
****(ie, figure out what a botnet does and how it works)
****Botnet – illegal cloud computing.

=== DRM – Digital Rights Management ===
*People have been using reverse engineering crack DRM since DRM was released
*Interesting thing about DRM – it works to protect the content from the legitimate user that you want to have the content.
*Most secure current DRM- iOS. It is currently very difficult to crack (or “jailbreak”). In fact, it may even be “effectively unbreakable” because the cost and time involved in breaking it isn’t worth it.
*Jailbreaking iOS used to be very popular, as it allowed users to use their iPhones in ways that Apple didn’t allow. However, it would also negatively impact the security of the device.
*The jailbreak community showed Apple where the security flaws in their devices were found. Apple could then fix the flaws. The community would find new flaws, and Apple would fix them.
*This evolution or “trial by fire” is the only way that security gets strong. No theoretical security can be trusted until it has had people try to crack it.

Today, attacks get put into usable software and distributed quickly. They spread fast.

Nation-states pay lost of people to reverse engineer systems and find the security holes. They do it in secret, but they can’t keep secrets, so the attacks they create get leaked.

The code of much modern malware that is causing problems has been written by
nation-states.

We cannot make any system perfectly secure, but we don’t build systems under that assumption. We build systems that store large amounts of important data (how much data does Facebook have? Google? Governments?). We assume that we can do this securely, but we can’t.

SystemsSec 2018W Lecture 1

2018-01-16T01:47:56Z

Trent:

= Notes =
Class 1, January 8

== About the course: ==
Lectures will not be posted online.
Notes will be posted online.
In order to succeed, you need to come to class. Things will be discussed, and you need to be present.

* Grading Criteria
** Midterm 25%
** Final 35%
** Participation 10%
** Experiences 10%
** Assignments (4) 20%

The midterm and final will basically be short answer, possibly with some essay questions.
The assignments will be in the style of the midterm and final, and will let you know how prepared you are for the exams. 2 assignments before the midterm and 2 after the midterm.
Participation – being present, taking notes for the class, raising your hand, discussing things (not purely in class, also there will be a slack instance). If for some reason participation will be a problem for you, email the professor now to work it out)
Experiences – in 2 portions reading and tools
Reading – submit a reading response. Make a diligent effort to understand the reading before coming to class. Not a summary. What was your interaction with the reading?
Tools – Computer Systems Security is fundamentally an applied field. It is tied to tools. Applied learning is important. Some exercises will be provided, but other things you will come across yourself (ie try to set up a firewall, or play around with iptables, you don’t have to succeed). Write a tool response. Plan on sitting down a couple of times and doing some hacking. It is important to get your hands dirty. To start, pick something that you can handle, and maybe ramp it up as the term goes along.
Assignments will be submitted through CULearn.

== The material covered today: ==
In the news recently: Meltdown and Spectre security flaws
Meltdown in the Intel version, Spectre is the more general version.
Basically every modern CPU that has high performance is affected
Problem with processor design.
Design strategy used to increase performance in modern processors allows for information leakage.

Software programs and processes don't trust each other (and they shouldn't), but this flaw means that the barriers between them aren't fixed, you can read across them.
It is a timing attack. The basis of timing attacks is that the time to compute depends on the data that you are computing. By knowing how long something takes to compute, you can figure out what is being computed.
There was previously a well known timing attack on public key encryption, which was solved by responding to all requests in the same constant time.
Meltdown and Spectre exploit branch predictors (ie, the processor speculates at which branch of the code will be run next and “runs ahead”. If it predicts correctly, there is a performance advantage). However, flaws were found that enabled kernel memory to be read, or a virtual machine to read data from another virtual machine running on the same processor. This particularly affects cloud computing.

These types of flaws come because no one was thinking about the design from a security point of view.
System Security is difficult. Attackers find flaws, defenders try to fix them. This happens in real systems, with enormous complexity. Theoretically we can design perfectly secure systems, but attackers will keep finding flaws. This game, as it is today, is weighted towards attackers. Rebalancing the game would require radical ideas.

=== A (noncomprehensive) list of some security tools and methods: ===
*The purpose of this list is to show what a vast area computer security is, not making a list of everything that will be covered.
Firewalls
Antivirus/Antimalware
Network monitoring/NIDS
Reverse engineering.
Cryptography (encryption/digital signing) (for system security, encryption is a tool of last resort)
Air gaps
Social Engineering
(D)DoS
White list
Black list
One way info-gate
Virtual machines
Encapsulation
Virtual memory
Formal verification
Randomization (ASLR)
Passwords
Captchas
Biometrics
Location monitoring
Mandatory access control (ie SELinux, very inconvenient)
Discretionary access control (traditional Unix, Windows…)
Automatic memory management (garbage collection)
Static analysis
Dynamic analysis

Security can affect just about any area of computer science. If there I a branch that doesn’t appear to be affected by security, someone just hasn’t thought about it for long enough.
This course isn’t about a specific tool or method, although many will be touched on. Primarily, we want to look at how to think about problems so that you see security issues. What can I do as an attacker? What can I do as a defender.
There are always benefits and costs to any security decision, By strengthening security in one way, you can weaken it in another.
For example, if you can’t risk lockouts and downtime, having passwords could cause problems.
If you make usability too difficult, users can find ways to bypass your security measures. Security is always a secondary concern. The primary concerns of users are the tasks that they are using the computer systems to complete.
The most secure system is one that is off, in a locked room in a secure facility. However, that system is also completely useless.
Even if you do not become a computer security professional, you will design systems and make decisions that have security implications.

=== Reverse Engineering ===
Picked from the list at random to discuss

What is it?
Normal engineering process would be Design -> code -> system.
Reverse engineering is reversing that process. Looking at the system to figure out the code and the design.

Who?
*Attackers
**analyzing defenses
***If you can figure out how it works, then you can find weaknesses and exploit them.
You become an expert safecracker by learning about safes. In order to find flaws in systems you must have a deep knowledge of those systems. What an attacker wishes to attack he must master, and by finding the flaw, the attacker '''proves his knowledge'''. It is like solving a puzzle. That is what drives the people developing these attacks. The negative impacts are often secondary.

*Defenders
**Analyze defenses like attackers
**Analyze attacks
***(ie, figure out what a botnet does and how it works)
***Botnet – illegal cloud computing.

=== DRM – Digital Rights Management ===
*People have been using reverse engineering crack DRM since DRM was released
*Interesting thing about DRM – it works to protect the content from the legitimate user that you want to have the content.
*Most secure current DRM- iOS. It is currently very difficult to crack (or “jailbreak”). In fact, it may even be “effectively unbreakable” because the cost and time involved in breaking it isn’t worth it.
*Jailbreaking iOS used to be very popular, as it allowed users to use their iPhones in ways that Apple didn’t allow. However, it would also negatively impact the security of the device.
*The jailbreak community showed Apple where the security flaws in their devices were found. Apple could then fix the flaws. The community would find new flaws, and Apple would fix them.
*This evolution or “trial by fire” is the only way that security gets strong. No theoretical security can be trusted until it has had people try to crack it.

Today, attacks get put into usable software and distributed quickly. They spread fast.
Nation-states pay lost of people to reverse engineer systems and find the security holes. They do it in secret, but they can’t keep secrets, so the attacks they create get leaked.
The code of much modern malware that is causing problems has been written by nation-states.

We cannot make any system perfectly secure, but we don’t build systems under that assumption. We build systems that store large amounts of important data (how much data does Facebook have? Google? Governments?). We assume that we can do this securely, but we can’t.