Soma-notes - User contributions [en]

Computer Systems Security (Winter 2016)

2016-03-27T05:53:26Z

Michelberg:

==Course Outline==

[[Computer Systems Security: Winter 2016 Course Outline|Here]] is the course outline.

==Hacking Opportunities==

The [[SystemsSec 2016W Hacking Opportunities|Hacking Opportunities]] page lists potential hacking opportunities that you can attempt for your hacking journal. If you attempt but do not successfully accomplish one of them, be sure to document what you tried. As you learn more, you may come back to them and try again.

==Resources==

===Readings===

* For the first part of the course we will be reading selections from Trent Jaeger's [http://www.morganclaypool.com/doi/abs/10.2200/S00126ED1V01Y200808SPT001 Operating Systems Security] textbook. You can download the PDF [http://www.morganclaypool.com.proxy.library.carleton.ca/doi/abs/10.2200/S00126ED1V01Y200808SPT001 through Carleton's library]. In the reading assignments this text will be referred to as "Jaeger".
* An excellent but dated text on browser security is Michal Zalewski's [https://code.google.com/p/browsersec/wiki/Main Browser Security Handbook].

===Other Courses===

* Dan Boneh ran an excellent course at Stanford in Spring 2015 on [https://crypto.stanford.edu/cs155/ Computer and Network Security]. This course has many interesting readings that we will not be covering. Also, the assignments are very good sources for hacking opportunities.
* The assignments from the Winter 2015 run of COMP 4108 [https://ccsl.carleton.ca/~dmccarney/COMP4108/ are available]. They are a reasonable start for several hacking opportunities.

==Lectures and Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
<th>
Readings
</th>
</tr>
<tr>
<td>
Jan. 7

</td>
<td>
[[SystemsSec 2016W Lecture 1|Introduction]]

</td>
<td>Jaeger, Chapter 1 (Introduction)</td></tr>
<tr>
<td>
Jan. 12

</td>
<td>
[[SystemsSec 2016W Lecture 2|Access Control, Security Hacking 101]]

</td>
<td>Jaeger, Chapter 2 (Access Control Fundamentals)</td></tr>
<tr>
<td>
Jan. 14

</td>
<td>
[[SystemsSec 2016W Lecture 3|Multics, UNIX, and Windows]]

</td>
<td>Jaeger, Chapter 3 (Multics) and Chapter 4 (UNIX & Windows) </td></tr>
<tr>
<td>
Jan. 19

</td>
<td>
[[SystemsSec 2016W Lecture 4|Secure OSs, theory and practice]]

</td>
<td>Jaeger, Chapter 6 (Security Kernels) and Chapter 7 (Securing Commercial Operating Systems)</td></tr>
<tr>
<td>
Jan. 21

</td>
<td>
[[SystemsSec 2016W Lecture 5|LSM, SELinux, & Capabilities]]

</td>
<td>Jaeger, Chapter 9 (LSM & SELinux) and Chapter 10 (Secure Capability Systems)</td></tr>
<tr>
<td>
Jan. 26

</td>
<td>
[[SystemsSec 2016W Lecture 6|Secure Virtual Machines, Systems Assurance]]

</td>
<td>Jaeger, Chapter 11 (Secure Virtual Machine Systems) and Chapter 12 (System Assurance)</td></tr>
<tr>
<td>
Jan. 28

</td>
<td>
[[SystemsSec 2016W Lecture 7|Lecture 7]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 2

</td>
<td>
[[SystemsSec 2016W Lecture 8|Lecture 8]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 4

</td>
<td>
[[SystemsSec 2016W Lecture 9|Defensive Security Technologies / Hacking Opportunities]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 9

</td>
<td>
[[SystemsSec 2016W Lecture 10|Security Research, Hashes, and Secure Protocols]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 11

</td>
<td>
[[SystemsSec 2016W Lecture 11|Modeling a potential attack/ Midterm FAQ]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 23

</td>
<td>
[[SystemsSec 2016W Lecture 12|Midterm Review]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 25

</td>
<td>
Midterm (in class)

</td>
<td></td></tr>
<tr>
<td>
Mar. 1

</td>
<td>
[[SystemsSec 2016W Lecture 13|Buffer Overflow/Memory Corruption Attacks]]

</td>
<td>Aleph One (aka Elias Levy), [http://www.phrack.com/issues/49/14.html#article Smashing The Stack For Fun And Profit] (Phrack 49, 1996)</td></tr>
<tr>
<td>
Mar. 3

</td>
<td>
[[SystemsSec 2016W Lecture 14|Buffer Overflow/Memory Corruption Defenses]]

</td>
<td>
Wikipedia, [https://en.wikipedia.org/wiki/Buffer_overflow_protection Buffer Overflow Protection] 
Crispin Cowan et al., [https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks] (USENIX Security, 1998)
</td>
</tr>
<tr>
<td>
Mar. 8

</td>
<td>
[[SystemsSec 2016W Lecture 15|Bypassing ASLR and Buffer Overflow Exploits using return-into-libc]]

</td>
<td>Hovav Shacham et al., [http://dx.doi.org/10.1145/1030083.1030124 On the effectiveness of address-space randomization] (ACM CCS, 2004) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1030124&ftid=285463&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)] 
Hovav Shachem [http://dx.doi.org/10.1145/1315245.1315313 The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86)] (ACM CCS 2007) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1315313&ftid=476749&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)]</td></tr>
<tr>
<td>
Mar. 10

</td>
<td>
[[SystemsSec 2016W Lecture 16|Lecture 16]]

</td>
<td>Bellovin and Cheswick, [http://dx.doi.org/10.1109/35.312843 Network Firewalls] (IEEE Communications Magazine, 1994) [http://ieeexplore.ieee.org.proxy.library.carleton.ca/stamp/stamp.jsp?tp=&arnumber=312843 (proxy)]</td></tr>
<tr>
<td>
Mar. 15

</td>
<td>
[[SystemsSec 2016W Lecture 17|Lecture 17]]

</td>
<td>Dingledine, Mathewson, and Syverson, [https://www.usenix.org/legacy/events/sec04/tech/dingledine.html Tor: The Second-Generation Onion Router] (USENIX Security 2004) Albert Kwon et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kwon Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Services] (USENIX Security 2015) (background)[https://www.torproject.org/about/overview.html.en Tor: Overview]</td></tr>
<tr>
<td>
Mar. 17

</td>
<td>
[[SystemsSec 2016W Lecture 18|Lecture 18]]

</td>
<td>Blase Ur et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ur Measuring Real-World Accuracies and Biases in Modeling Password Guessability] (USENIX Security 2015) 
Nikolaos Karapanos et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/karapanos Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 22

</td>
<td>
[[SystemsSec 2016W Lecture 19|Lecture 19]]

</td>
<td>Giancarlo Pellegrino et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/pellegrino In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services] (USENIX Security 2015) Ramya Jayaram Masti et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/masti Thermal Covert Channels on Multi-core Platforms] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 24

</td>
<td>
[[SystemsSec 2016W Lecture 20|DDoS and Pinning]]

</td>
<td>Seyed K. Fayaz et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fayaz Bohatei: Flexible and Elastic DDoS Defense] (USENIX Security 2015) Marten Oltrogge and Yasemin Acar, [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge To Pin or Not to Pin—Helping App Developers Bullet Proof Their TLS Connections] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 29

</td>
<td>
[[SystemsSec 2016W Lecture 21|Lecture 21]]

</td>
<td>David A. Ramos and Dawson Engler, [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ramos Under-Constrained Symbolic Execution: Correctness Checking for Real Code] (USENIX Security 2015) Nav Jagpal et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/jagpal Trends and Lessons from Three Years Fighting Malicious Extensions] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 31

</td>
<td>
[[SystemsSec 2016W Lecture 22|Lecture 22]]

</td>
<td>Xiaofeng Zheng et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng Cookies Lack Integrity: Real-World Implications] (USENIX Security 2015) Sebastian Lekies et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies The Unexpected Dangers of Dynamic JavaScript] (USENIX Security 2015)</td></tr>
<tr>
<td>
Apr. 5

</td>
<td>
[[SystemsSec 2016W Lecture 23|Lecture 23]]

</td>
<td>Michael Backes et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android] (USENIX Security 2015) Primal Wijesekera et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity] (USENIX Security 2015)</td></tr>
<tr>
<td>
April 7

</td>
<td>
[[SystemsSec 2016W Lecture 24|Lecture 24]]

</td>
<td></td></tr>
<tr>
<td>
April 19, 9 AM

</td>
<td>
Final Exam

</td>
<td></td></tr>
</table>

==Lecture Notes Guidelines==

Part of your participation mark is doing notes for at least one of the lectures. Here are the guidelines for those notes.

The class TA Borke (BorkeObadaObieh at cmail.carleton.ca) will be handling course notes. Please contact her to schedule your class to take notes.

Borke or Anil will set you up with an account on this wiki. You'll enter your initial draft notes here and then work with Borke to make sure they are of sufficient quality. This may require a few rounds of revisions; however, if you follow the guidelines below it shouldn't be too bad.

You should plan on organizing your notes as follows:
* Organize them in at least the following sections: Topics & Readings and Notes.
* The Topics & Readings section lists the main topics covered in the class, e.g. "buffer overflows". Please use an unordered bulleted list (using *'s in wiki markup). In this section also list readings relevant to the lecture that were mentioned in class.
* Put your notes in the Notes section.

Use (nested) lists if appropriate for the notes; however, please have some text that isn't bulleted. Please try to make the notes even if you did not attend lecture; however, you don't need to cover every small bit of information that was covered. In particular the notes do not need to include digressions into topics only tangentially related to the course. Complete sentences are welcome but not required.

==Security Reading Analysis Guidelines==

A security reading analysis is a detailed analysis of a security research paper. In it you analyze the key arguments of the paper and give your informed opinion.

Most security papers can be classified as attack or defense papers. You should analyze them differently.

For attack papers:
* What systems are vulnerable to the attack?
* What is the nature of the vulnerability?
* What is the the exploit? In particular, what is its technical core?
* How reproducible is the exploit?
* Are there likely to be many similar exploits, in the targeted system or other systems?
* How difficult will it be mitigate/fix the vulnerability in targeted systems?

For defense papers:
* What is the security problem the paper addresses? In what kind of threat model(s) does the problem exist?
* How significant is the problem? Specifically, to what degree do existing solutions not work sufficiently well?
* What is the defense? How does it work?
* To what degree will the defense potentially solve the targeted security problem? In particular, how difficult will it be for attackers to adapt to this defense?
* What are the challenges facing deployment of the defense? Are they likely to be overcome?

For both kinds of papers, you should give your reaction by addressing questions like the following:
* Did you like the paper?
* Was it easy to understand, or was it hard to read?
* Did you learn much from the paper?
* How surprised were you by the result?

Your analysis should not cover the above questions separately (this would tend to make for a very wordy analysis); instead, use these questions as a guide in writing a short essay (1-2 pages) on the paper in question.

Each analysis will be graded out of 10 as follows:
* U: 3 for demonstrating understanding of the content (preferably without summarizing)
* T: 3 for technical analysis (does it work)
* C: 3 for contextual analysis (does it matter)
* V: 1 for your viewpoint

SystemsSec 2016W Lecture 20

2016-03-27T05:52:35Z

Michelberg:

==Topics and Readings==
*Distributed Denial of Service (DDoS) Attacks
**Seyed K. Fayaz et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fayaz Bohatei: Flexible and Elastic DDoS Defense]'' (USENIX Security 2015)
*Certificate Pinning
**Marten Oltrogge and Yasemin Acar, ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge To Pin or Not to Pin—Helping App Developers Bullet Proof Their TLS Connections]'' (USENIX Security 2015)

==Notes==
===DoS (Denial of Service) Attacks===
====Introduction====
A '''DoS attack''' occurs when a host system floods a target system or any of its resources with illegitimate traffic, preventing the legitimate requests from being processed. This flood can involve network queues or even a server's CPU or RAM resources, though the readings concentrate primarily on the networking aspects.
*An example of a memory-based DoS attack involves Zip Bombs. A Zip Bomb is a large amount of arbitrary data that is efficiently compressed to a very small size. When it is opened by a server for malware detection purposes, it quickly exhausts the system's available RAM and potentially even its swap space, grinding the system to a hault.

A '''network-based DoS attack''' stems from a problem in a computer network's traffic management. Many systems do not have proper protections in place to deal with attack-style requests, so they are typically treated as legitimate traffic and as a result are not ignored.
*An example of this is in a SYN flood attack, where the first part of a TCP connection (SYN message) is sent to the server without the attacker caring for the SYN-ACK response. The server will wait for the attacker's ACK message, keeping resources open for a set amount of time. When the server's resources eventually run out, the server will no longer accept new SYN requests from legitimate users.

The resulting effects are pretty simple: you can't use the network as intended. There are too many packets being received by the server, and yours can't get through.

DoS attacks can be on both public and private networks, though private attacks (e.g. preventing one specific n00b from accessing a lobby server after a CS:GO match didn't go your way) are far less of a concern than, say, a multinational banking server going down.

====DDoS (Distributed Denial of Service) Attacks====
Because no one computer is powerful enough to flood any sensible network nowadays, to effectively perform a DoS attack the barrage is carried out by many different computers instead of just one. The amount of traffic generated by multiple computers can more effectively overwhelm a target network's resources, especially when the individual attacking hosts—which need not belong to the attacker, in the case of public servers or compromised systems—are limited in their own bandwidth as well. This is called a '''Distributed Denial of Service attack''', due to its distributed nature.

====Amplification Attack====
An '''amplification attack''' is an attack that is propagated on public networks. It is made possible by small requests that receive substantially larger responses from a server.
*An example discussed in class is the NTP (Network Time Protocol) server, which responds to a single UDP "monlist" packet with a list of the last 600 IP addresses connected [[http://arstechnica.com/security/2014/02/biggest-ddos-ever-aimed-at-cloudflares-content-delivery-network/ article]]. By spoofing the return address of many of these requests, a DDoS attack can be directed to a particular network.

====Preventing a DoS Attack====
In order to minimize or prevent the effects of an attempted DoS attack, a server needs a way to differentiate legitimate traffic from illegitimate traffic—preferably before the spurious packets propagate through your network. This can be done by routing major points in a network through powerful, high-bandwidth computers to process incoming traffic before it is allowed to propagate to the less powerful routers and switches that would be more devastated by large scale traffic floods. This can present some problems, however:

A traffic analogy:
*Many cars drive along a highway. They typically travel at high speeds, utilizing and filling up the 4 lanes available.
*When construction cuts the number of lanes down to one, every car must merge into one lane at the threshold. This slows traffic considerably.
*A preventative measure is to redirect the traffic around these narrow roads.
**Like with roads, a network's topology cannot typically reconfigure itself on the fly. Roads cannot be built and destroyed whenever traffic gets slow.
*Another method for preventing traffic is to just vaporize the cars.

Going back to networking, the last point above is much easier when dealing with packets: just drop them. Typically legitimate traffic is of a certain type; we can drop the odd ones before they get to the inner network. Legitimate traffic can still be faked, but this can prevent ''some'' less sophisticated attack traffic. But for those remaining however, to know which packets are the ones that need to be dropped can be resource-intensive, even for powerful computers. Deep packet scanning or authentication works, but that takes time.

====SDN (Software Defined Networking) and ''[https://github.com/ddos-defense/bohatei Bohatei]''====
The actual process of networking is to route packets to their destinations. This is done by using routing tables and other networking rules. For high-speed routers, these rules are on specialized, super-fast pieces of silicon to make these table-lookups highly optimized and very efficient. Unfortunately it also makes it very ''proprietary'' and ''expensive''. SDN (Software Defined Networking) removes some of these limitations by replacing the expensive silicon with flexible software designed for general purpose computers.
*Some of the operations are therefore going to be slower. This is a given, and likely a fair trade.
*This software is much more flexible and scalable than other physical DDoS protection deployments (expensive machines added to a network designed to handle DDoS-related attacks).

The paper discusses planning (what attacks you ''could'' get, not what attacks you ''will'' get) for attacks:
*During certain attack scenarios, (e.g. SYN flood), it will route that specific type of traffic (i.e. SYN packets) using a different set of routing rules and network topologies.
**The new (temporary) topology is not optimal, but that is because it is case-specific. As a result, there will be a degradation of service (SYN packets are slower), but the rest of the network should be able to deal with it and recover after the attack is finished by reverting back to the more optimal topologies and routing tables.
**Going back to the traffic analogy, it would be like changing or redefining roads on the fly (changing directions of one-way streets... sort of like the Champlain Bridge between Ottawa and Gatineau).

A caveat for the above, related to the paper:
*It is assuming that an entire network is running on SDN, which is not the case at present.
**The paper does not cover hybrid solutions.
**If a corporation is looking for DDoS protection services, it would likely be inclined to just add a specialized machine to handle that traffic instead of migrating the ''entire'' network over to SDN.
*All classes of attacks need to be defined in advance for Bohatei and other software to operate properly.
*The paper doesn't take into consideration friendly DDoS attacks (e.g. accidental DDoS when a low-traffic public webserver hosts content that suddenly goes viral).

====Side Note====
'''''Attribution''''' - The internet was not designed with metering, so how do you know who is responsible for a DDoS attack? When talking about attack packets (typically spoofed source addresses, sent from compromised machines), it is important to note that it is very difficult to legitimately trace these back to their sources. DDoS attacks are very ''noisy'' attack methods, meaning packets are leaked all over.

==Pinning==
====CA (Certification Authority) Certificates & PKI (Public Key Infrastructure)====
A modern web browser has a built in set of CA (certification authority) certificates. When you visit a website, the SSL connection's CA is verified by the browser. If your connection's certificate is signed by something else (e.g. an unauthenticated/expired certificate), then the connection is dropped. TLS is reliable, but once keys are changed, those TLS connections are refused.
*Websites typically use only a certain set of certificates. For example, Facebook supposedly always goes with Verisign certificates (though upon verification it appears to be issued by DigiCert).
*Wildcard certificates are certificates that can be used for any number of subdomains (e.g. *.facebook.com).
**Wildcard certificates are typically less secure than individual (more specific) certificates.
**More specific certificates can be specified (i.e. ''pinned'') for a stricter subset of those subdomains, however. This is called '''Certificate Pinning'''.

====Certificate Pinning====
Pinning is the specification of which certificates you explicitly trust. It is a way to make verification more trustworthy (at the cost of speed).

Facebook example:
:Verisign → FB1 → FB2
*''Verisign'' is the fingerprint (hashed public key used to represent a longer public key). This is the root certificate, and it is verified.
*Each certificate down the chain is more specific. ''FB2'' is a more specific CA certificate than ''FB1''. If you "pin" a certificate further down the chain, you specify that you trust that less-generic certificate. More specific certificates are more secure.

====Some Problems with Pinning====
As a developer, you cannot change which CA certificates a user's browser will accept. As an app developer, you can leave certificate pinning to third-party libraries and services.
*If you're using a third party library to handle certain networking connections however, there is a possibility that the library might be opening connections that you (the developer) know very little about.
**An example of this? ''Ad networks''. They talk to many servers, sometimes without even the developer's knowledge.

Certificates can instead be hard-coded to explicitly state which CA certificates your app deems acceptable. This can easily prevent connections to 50 servers when you only need 1, but certificates sometimes change. When that happens without the app being updated first, subsequent network connections are refused, and the app breaks.

Organizations also aren't disciplined in how they use their certificates—or if they are, there is no standard between organizations. Facebook could be using upwards of 1,000 certificates. Same with Google. Or they could be using one.

SystemsSec 2016W Lecture 20

2016-03-27T05:46:19Z

Michelberg:

{{DISPLAYTITLE:DDoS and Pinning}}
==Topics and Readings==
*Distributed Denial of Service (DDoS) Attacks
**Seyed K. Fayaz et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fayaz Bohatei: Flexible and Elastic DDoS Defense]'' (USENIX Security 2015)
*Certificate Pinning
**Marten Oltrogge and Yasemin Acar, ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge To Pin or Not to Pin—Helping App Developers Bullet Proof Their TLS Connections]'' (USENIX Security 2015)

==Notes==
===DoS (Denial of Service) Attacks===
====Introduction====
A '''DoS attack''' occurs when a host system floods a target system or any of its resources with illegitimate traffic, preventing the legitimate requests from being processed. This flood can involve network queues or even a server's CPU or RAM resources, though the readings concentrate primarily on the networking aspects.
*An example of a memory-based DoS attack involves Zip Bombs. A Zip Bomb is a large amount of arbitrary data that is efficiently compressed to a very small size. When it is opened by a server for malware detection purposes, it quickly exhausts the system's available RAM and potentially even its swap space, grinding the system to a hault.

A '''network-based DoS attack''' stems from a problem in a computer network's traffic management. Many systems do not have proper protections in place to deal with attack-style requests, so they are typically treated as legitimate traffic and as a result are not ignored.
*An example of this is in a SYN flood attack, where the first part of a TCP connection (SYN message) is sent to the server without the attacker caring for the SYN-ACK response. The server will wait for the attacker's ACK message, keeping resources open for a set amount of time. When the server's resources eventually run out, the server will no longer accept new SYN requests from legitimate users.

The resulting effects are pretty simple: you can't use the network as intended. There are too many packets being received by the server, and yours can't get through.

DoS attacks can be on both public and private networks, though private attacks (e.g. preventing one specific n00b from accessing a lobby server after a CS:GO match didn't go your way) are far less of a concern than, say, a multinational banking server going down.

====DDoS (Distributed Denial of Service) Attacks====
Because no one computer is powerful enough to flood any sensible network nowadays, to effectively perform a DoS attack the barrage is carried out by many different computers instead of just one. The amount of traffic generated by multiple computers can more effectively overwhelm a target network's resources, especially when the individual attacking hosts—which need not belong to the attacker, in the case of public servers or compromised systems—are limited in their own bandwidth as well. This is called a '''Distributed Denial of Service attack''', due to its distributed nature.

====Amplification Attack====
An '''amplification attack''' is an attack that is propagated on public networks. It is made possible by small requests that receive substantially larger responses from a server.
*An example discussed in class is the NTP (Network Time Protocol) server, which responds to a single UDP "monlist" packet with a list of the last 600 IP addresses connected [[http://arstechnica.com/security/2014/02/biggest-ddos-ever-aimed-at-cloudflares-content-delivery-network/ article]]. By spoofing the return address of many of these requests, a DDoS attack can be directed to a particular network.

====Preventing a DoS Attack====
In order to minimize or prevent the effects of an attempted DoS attack, a server needs a way to differentiate legitimate traffic from illegitimate traffic—preferably before the spurious packets propagate through your network. This can be done by routing major points in a network through powerful, high-bandwidth computers to process incoming traffic before it is allowed to propagate to the less powerful routers and switches that would be more devastated by large scale traffic floods. This can present some problems, however:

A traffic analogy:
*Many cars drive along a highway. They typically travel at high speeds, utilizing and filling up the 4 lanes available.
*When construction cuts the number of lanes down to one, every car must merge into one lane at the threshold. This slows traffic considerably.
*A preventative measure is to redirect the traffic around these narrow roads.
**Like with roads, a network's topology cannot typically reconfigure itself on the fly. Roads cannot be built and destroyed whenever traffic gets slow.
*Another method for preventing traffic is to just vaporize the cars.

Going back to networking, the last point above is much easier when dealing with packets: just drop them. Typically legitimate traffic is of a certain type; we can drop the odd ones before they get to the inner network. Legitimate traffic can still be faked, but this can prevent ''some'' less sophisticated attack traffic. But for those remaining however, to know which packets are the ones that need to be dropped can be resource-intensive, even for powerful computers. Deep packet scanning or authentication works, but that takes time.

====SDN (Software Defined Networking) and ''[https://github.com/ddos-defense/bohatei Bohatei]''====
The actual process of networking is to route packets to their destinations. This is done by using routing tables and other networking rules. For high-speed routers, these rules are on specialized, super-fast pieces of silicon to make these table-lookups highly optimized and very efficient. Unfortunately it also makes it very ''proprietary'' and ''expensive''. SDN (Software Defined Networking) removes some of these limitations by replacing the expensive silicon with flexible software designed for general purpose computers.
*Some of the operations are therefore going to be slower. This is a given, and likely a fair trade.
*This software is much more flexible and scalable than other physical DDoS protection deployments (expensive machines added to a network designed to handle DDoS-related attacks).

The paper discusses planning (what attacks you ''could'' get, not what attacks you ''will'' get) for attacks:
*During certain attack scenarios, (e.g. SYN flood), it will route that specific type of traffic (i.e. SYN packets) using a different set of routing rules and network topologies.
**The new (temporary) topology is not optimal, but that is because it is case-specific. As a result, there will be a degradation of service (SYN packets are slower), but the rest of the network should be able to deal with it and recover after the attack is finished by reverting back to the more optimal topologies and routing tables.
**Going back to the traffic analogy, it would be like changing or redefining roads on the fly (changing directions of one-way streets... sort of like the Champlain Bridge between Ottawa and Gatineau).

A caveat for the above, related to the paper:
*It is assuming that an entire network is running on SDN, which is not the case at present.
**The paper does not cover hybrid solutions.
**If a corporation is looking for DDoS protection services, it would likely be inclined to just add a specialized machine to handle that traffic instead of migrating the ''entire'' network over to SDN.
*All classes of attacks need to be defined in advance for Bohatei and other software to operate properly.
*The paper doesn't take into consideration friendly DDoS attacks (e.g. accidental DDoS when a low-traffic public webserver hosts content that suddenly goes viral).

====Side Note====
'''''Attribution''''' - The internet was not designed with metering, so how do you know who is responsible for a DDoS attack? When talking about attack packets (typically spoofed source addresses, sent from compromised machines), it is important to note that it is very difficult to legitimately trace these back to their sources. DDoS attacks are very ''noisy'' attack methods, meaning packets are leaked all over.

==Pinning==
====CA (Certification Authority) Certificates & PKI (Public Key Infrastructure)====
A modern web browser has a built in set of CA (certification authority) certificates. When you visit a website, the SSL connection's CA is verified by the browser. If your connection's certificate is signed by something else (e.g. an unauthenticated/expired certificate), then the connection is dropped. TLS is reliable, but once keys are changed, those TLS connections are refused.
*Websites typically use only a certain set of certificates. For example, Facebook supposedly always goes with Verisign certificates (though upon verification it appears to be issued by DigiCert).
*Wildcard certificates are certificates that can be used for any number of subdomains (e.g. *.facebook.com).
**Wildcard certificates are typically less secure than individual (more specific) certificates.
**More specific certificates can be specified (i.e. ''pinned'') for a stricter subset of those subdomains, however. This is called '''Certificate Pinning'''.

====Certificate Pinning====
Pinning is the specification of which certificates you explicitly trust. It is a way to make verification more trustworthy (at the cost of speed).

Facebook example:
:Verisign → FB1 → FB2
*''Verisign'' is the fingerprint (hashed public key used to represent a longer public key). This is the root certificate, and it is verified.
*Each certificate down the chain is more specific. ''FB2'' is a more specific CA certificate than ''FB1''. If you "pin" a certificate further down the chain, you specify that you trust that less-generic certificate. More specific certificates are more secure.

====Some Problems with Pinning====
As a developer, you cannot change which CA certificates a user's browser will accept. As an app developer, you can leave certificate pinning to third-party libraries and services.
*If you're using a third party library to handle certain networking connections however, there is a possibility that the library might be opening connections that you (the developer) know very little about.
**An example of this? ''Ad networks''. They talk to many servers, sometimes without even the developer's knowledge.

Certificates can instead be hard-coded to explicitly state which CA certificates your app deems acceptable. This can easily prevent connections to 50 servers when you only need 1, but certificates sometimes change. When that happens without the app being updated first, subsequent network connections are refused, and the app breaks.

Organizations also aren't disciplined in how they use their certificates—or if they are, there is no standard between organizations. Facebook could be using upwards of 1,000 certificates. Same with Google. Or they could be using one.

SystemsSec 2016W Lecture 20

2016-03-25T02:44:40Z

Michelberg: Created page with "==Topics and Readings== *Distributed Denial of Service (DDoS) Attacks **Seyed K. Fayaz et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/present..."