commit 62fd713e7398446854575c215af62e07ea7f0e94
parent da6135696994016ae90d81adbf1f15139f4a4cc4
Author: Alex Balgavy <alex@balgavy.eu>
Date: Mon, 12 Oct 2020 14:29:00 +0200
Updated CNS notes
Diffstat:
4 files changed, 123 insertions(+), 0 deletions(-)
diff --git a/content/computer-network-security/Lecture 13_ advanced exploitation 2.md b/content/computer-network-security/Lecture 13_ advanced exploitation 2.md
@@ -0,0 +1,38 @@
++++
+title = "Lecture 13: advanced exploitation 2"
++++
+# Lecture 13: advanced exploitation 2
+
+## BlindSide
+- Combines thread models of spectre attacks (speculative execution) + hacking blind (exploits crash-resistant programs)
+- enables hacking blind in crash-sensitive domain
+- makes buffer overflows more powerful by adding possibility of exploitation
+
+Speculative execution
+- modern CPUs need deep pipelines for performance (CPU simultaneously executes many instructions in different steps)
+- CPU can't always determine next instruction because of conditional ⇒ branch prediction
+- branch prediction: predict target of branch based on previous executions, speculatively execute, roll back if needed
+
+Spectre vulnerability
+- in Intel CPUs
+- related to speculative execution where rollback is incomplete (mem read stays in cache)
+- attacker can train branch prediction to expect a path, have program execute this path, determine which memory was speculatively loaded into cache by timing mem accesses
+- v1: bounds check bypass, make program e.g. predict that index will be in bounds when checking conditionals
+- v2: branch target injection, make call instruction mis-predict to trained target
+
+Hacking blind
+- requirement: crash-resistant program (cause a crash, but program continues running without re-randomizing ASLR), not possible in kernel
+- lacks information leaking primitive
+- use buffer overflow to corrupt and probe memory
+- infer targets from measurable side-effects of probes
+
+BlindSide:
+- use buffer overflow to corrupt function pointer
+- execute corrupted function pointer speculatively to probe memory
+- infer targets from measurable side effects of probe
+- lets you do crashless probing in crash-sensitive domain (speculation is suppressor of crashes)
+
+Newton:
+- instead of static analysis for ROP, does dynamic analysis
+- taint tracking (lol), taint tracker-controlled bytes and monitor branches (taint sinks) that depend on tainted memory, dump taint source for each sink
+- newton gadgets: callsite is tainted by addresses and may call a function
diff --git a/content/computer-network-security/Lecture 14_ Intrusion Detection Systems (IDS)/3dd38ed3705348899b10d823c06f5ee1.png b/content/computer-network-security/Lecture 14_ Intrusion Detection Systems (IDS)/3dd38ed3705348899b10d823c06f5ee1.png
Binary files differ.
diff --git a/content/computer-network-security/Lecture 14_ Intrusion Detection Systems (IDS)/index.md b/content/computer-network-security/Lecture 14_ Intrusion Detection Systems (IDS)/index.md
@@ -0,0 +1,83 @@
++++
+title = "Lecture 14: Intrusion Detection Systems (IDS)"
++++
+# Lecture 14: Intrusion Detection Systems (IDS)
+
+## Intrusion Detection Systems (IDS)
+- analysis of actions performed by users and apps to identify evidence of maliciousness
+- stream of events generated by event sources (traffic dumps, system calls, kernel messages, logs)
+- typically streams go to analysis engine, which can dispatch actions for protection and add stuff to databases
+- approaches:
+ - misuse detection: relies on models of wrong behavior, identifies matching entries in event stream
+ - pros: not many false alarms, givs explanation, attack modesl are easy to understand, more resilient and usually faster
+ - cons: needs constant updating, vulnerable to over-stimulation, detects only known attack types
+ - anomaly detection: have a model of "normal behavior", identifies anomalous entries in event stream
+ - pros: detects previously unknown attacks, doesn't need updating
+ - cons: hard to configure, assumes anomalous == malicious, many false alarms, easy to evade, usually slow and resource-intensive
+- event sources: OS audit records, network packets, app logs, intrusion detection alerts
+- timeliness: real-time or non-real-time (offline/periodic)
+- response type: passive (logs, alerts) or active (reconfigures e.g. firewalls)
+- state-dependency: stateful or stateless analysis
+
+
+Confusion matrix:
+- "hit": detecting an actual attack (true positive)
+- "miss": not detecting an actual attack (false negative)
+- "false alarm": detecting a non-attack(false positive)
+
+
+
+Metrics:
+- Accuracy: (true_positives+true_negatives)/total
+- Precision: true_positives/(true_positives+false_positives)
+- Recall: true_positives/(true_positives+false_negatives)
+- F-measure: 2×(precision×recall)/(precision+recall)
+
+ROC curves
+- ROC (receiver operating characteristic): curve expressing performance of classifier
+- plots true positive rate vs false positive rate
+- false positive rate: false_positives/(false_positives+true_negatives)
+- true positive rate: true_positives/(true_positives+false_negatives)
+- ideally, area under the curve should be 1.
+
+The false positive rate dominates the effectiveness of an IDS (look at Bayes' Theorem calculation of P(intrusion|alert)).
+
+IDS output should have truth file: meta-information about even stream describing attacks and relationships between each attack and events in stream
+
+## Host vs Network IDS
+Host IDS:
+- monitors internals of computing system for unusual activities, file changes, signature patterns
+- honeypots: special machines that are there to be attacked and are used to analyze the attacker's activities
+- taint analysis (e.g. Argos): mark some bytes as tainted with propagation using shadow memory, raise alarm when tainted bytes are loaded into program counter
+
+Network IDS:
+- based on analysis of network traffic
+- sniffing traffic:
+ - pros: access to events from multiple host at single point, no performance effect on hosts.
+ - cons: vulnerable to evasion techniques, limited by switched architectures and encryption
+ - vulnerable to:
+ - susceptible to DOS attacks
+ - insertion: an IDS may accept packet that end-system rejects, so victim forms proper payload but IDS misses it
+ - evasion: end-system may accept packet that IDS rejects
+- OS-level network tap:
+ - pros: can analyze encrypted traffic after decryption, IDS view == host view, less traffic
+ - cons: affects performance of host, must be deployed on each host, can't access info related to other hosts.
+- desynchronising viewpoints
+ - IP:
+ - IP TTL field may not be large enough for number of hops to destination
+ - packet may be too large for downstream link without fragmenting
+ - destination may drop source-routed packets
+ - processing of fragmentation may be different
+ - TCP:
+ - destination may not accept packets with certain options
+ - destination may silently drop packets with old timestamps (protection against wrapped sequence numbers, PAWS)
+ - destination may not check sequence numbers on RST
+ - destination may resolve conflicting segments differently
+ - reassembly may be different
+- a potential solution: "normalizer" at network access point to process suspicious packets ('scrubbing')
+
+Evaluating IDS:
+- effectiveness: how many detected
+- precision: how many false positives
+- performance: how much traffic can be processed
+- descriptiveness
diff --git a/content/computer-network-security/_index.md b/content/computer-network-security/_index.md
@@ -16,3 +16,5 @@ title = "Computer and Network Security"
- [Lecture 10: Web attacks](lecture-10-web-attacks)
- [Lecture 11: Web attacks on user](lecture-11-web-attacks-on-user)
- [Lecture 12: advanced exploitation](lecture-12-advanced-exploitation)
+- [Lecture 13: advanced exploitation 2](lecture-13-advanced-exploitation-2)
+- [Lecture 14: Intrusion Detection Systems (IDS)](lecture-14-intrusion-detection-systems-ids)
/3dd38ed3705348899b10d823c06f5ee1.png.html){kind=link}