6.033 | Spring 2018 | Undergraduate

Computer System Engineering

Week 13: Security Part III

Lecture 23: Network Security and Distributed Denial of Service (DDoS) Attacks

Lecture 23 Outline

  1. Today’s Threat Model
  2. DDoS Attacks
  3. Botnets
  4. Network Intrusion Detection Systems (NIDS)
  5. How to Evade NIDS
  6. Attacks that Mimic Legitimate Traffic
  7. Attacks on Routers
  8. Moral of the Story

Lecture Slides

Reading

  • [No readings]

Recitation 23: Botnets

Lecture 24: Bitcoin

Lecture 24 Outline

  1. Introduction
  2. Currency
  3. A Decentralized Digital Currency (Almost)
  4. Dealing with Double-spending
  5. Proofs-of-work
  6. Ordering Transactions
  7. Did we prevent Double-spending?
  8. Discussion

Lecture Slides

Reading

  • [No readings]

Recitation 24: Memory Corruption

Tutorial 13: [No Tutorial]

Read “Your Botnet is My Botnet: Analysis of a Botnet Takeover” by Stone-Gross, et al. You can skim sections 5.2.1–5.2.3.

  • Section 2 explains how Torpig infects a user’s machine. After reading this section, you should understand how that happens: how the rootkit gets installed and why its installation remains undetected.
  • Section 3 explains the technique (domain flux) by which Torpig bots communicate with the C&C (command and control) server. After reading this section, you should understand why it’s difficult to simply block bots from accessing the C&C server.
  • Section 4 explains how the authors were able to take control of the Torpig botnet for a few weeks.
  • Sections 5 and 6 give an analysis of the botnet based on the authors’ takeover. (Remember you can skim sections 5.2.1–5.2.3)

As you read, think about

  • What tools and/or threat models are violated by Torpig?
  • Think about the key factors that allowed the authors to infiltrate the Torpig botnet. Would their techniques work for all botnets?
  • Was the authors’ methodology—taking over the botnet—necessary to collect the data they wanted? Was it ethical?

Questions for Recitation

Before you come to this recitation, write up (on paper) a brief answer to the following (really—we don’t need more than a couple sentences for each question).  

Your answers to these questions should be in your own words, not direct quotations from the paper.

  • What does it mean for a computer to be a “bot”?
  • In Torpig, how does a machine become a bot, and how does it receive instructions to carry out attacks?
  • Why is it difficult to prevent a machine from becoming a bot? Why is it difficult to simply block bots from accessing the C&C server?

As always, there are multiple answers to each of these questions.

Disclaimer: This is part of the security section in 6.033. Only use the information you learn in this portion of the class to secure your own systems, not to attack others.
  1. Today’s Threat Model
    • Last time: adversary tried to observe or tamper with packets.
    • Today: adversary is not just passively observing the network, but actively using it to attack users (more actively than the replay/reflection/man-in-the-middle attacks we saw last time).
    • Some attacks today don’t require adversary to observe packet contents; secure channels won’t help.
  2. DDoS Attacks
    • Adversary’s goal: bring down a service (e.g., take down the root DNS servers).
    • Strategy: congest the service. Make it spend time handling the adversary’s requests so that it can’t get to legitimate ones.
    • DoS (“denial of service”) attack:
      • Adversary sends a bunch of traffic to the service (in many cases even invalid requests will work), queues fill up, packets dropped, etc.
    • DDoS (“distributed DoS”) attack:
      • Mount the attack from multiple machines.
    • Can target any resource: bandwidth, routing systems, access to a database, etc.
    • Consequences of (D)DoS attacks:
      • A server being down for a few hours might not seem like the end of the world. But…
      • Could be bank transactions.
      • Could be DNS root servers (would bring Internet to a stand-still).
      • Could be on high-frequency trading machines, affect the stock market, etc.
  3. Botnets
    • Can’t we just toughen up our defenses? Add more bandwidth? How much traffic can one adversary generate?
    • Botnets: large (~100,000 machines) collection of compromised machines controlled by an attacker.
      • Make it very easy to mount DDoS attacks.
      • Can be rented surprisingly cheaply.
        • PLEASE DO NOT DO THIS.
    • How botnets work in five minutes:
      • How do machines get compromised (and become part of the botnet)?
        • Lots of ways. Common way: user visits vulnerable website. Vulnerability is usually a cross-site scripting attack.
          Example:
          • TrustedBlog.com has a box for users to enter comments on blogs.
          • Attacker embeds an executable script in his comment.
          • When users browse, server sends comments to their browsers which execute the script, which sends the user’s cookie to the attacker’s site.
        • XSS script to compromise a botnet machine causes user to download a “rootkit”, which compromises the machine.
          • See tomorrow’s recitation.
        • Bots contact command and control (C&C) servers which give them commands.
      • How to combat botnets:
        • Block IP addresses? Ineffective. Bots can change IP addresses rapidly.
        • Distribute systems so that DDoS attacks don’t have a centralized component to bring down? Not bad, but as we’ve seen, distribution => complexity.
  4. Network Intrusion Detection Systems (NIDS)
    • If we wanted to block IP addresses, how would we even figure out which IPs were part of the botnet?
    • Broader question: how do we detect network attacks?
    • Two approaches:
      • Signature-based: Keep a database of known attack signatures and match traffic against the database.
        • Pros: Easy to understand the outcome and ccurate in detecting known attacks.
        • Cons: Can’t discover new attacks and can only get the signature after the attack has already happened at least once.
      • Anomaly-based: Match traffic against a model of normal traffic and flags abnormalities.
        • Pros: Can deal with new attacks.
        • Cons: How do we model normal traffic? Less accurate detection of known attacks.
    • Many systems take a hybrid approach.
      • Most also give users the ability to, once an attack is (passively) detected, do something to (actively) prevent it.
    • Example intrusion-detection systems:
  5. How to Evade NIDS
    • Suppose we build a NIDS to scan traffic for a particular string (“root”). Seems easy.
    • Difficult because attacker can force confusing state on the NIDS (see slides).
    • Another way to evade NIDS: mount an attack on the detection mechanism.
  6. Attacks that Mimic Legitimate Traffic (and thus are even harder to detect)
    • HTTP flooding:
      • Attacker floods webserver with completely legitimate HTTP requests to download a large file or perform some computationally intensive database operation.
    • TCP SYN floods:
      • TCP connections start with a “handshake”, which cause the server to keep some state about the connection until the client completes the handshake.
      • Attacker can initiate many handshakes, exhaust state on the server.
    • Optimistic ACKs:
      • Attacker starts TCP communication with victim, ACKs packets that it hasn’t received yet.
      • Victim sends more and more traffic to the attacker, saturating their own link.
    • DNS reflection/amplification:
      • Bots locate DNS nameservers (even better if they are DNSSEC-enable).
      • Bots send DNS requests to these nameservers.
        • Spoof sources to be the victim’s IP address.
        • If DNSSEC-enable, request the relevant info. DNSSEC responses tend to be very large.
      • Result: Large DNS responses that go to the victim’s machine.
  7. Attacks on Routers
  8. Moral of the Story
    • Secure channels are great, but adversaries can still use the network to mount attacks.
    • These attacks become devastating if they attack parts of the Internet’s infrastructure (e.g., DNS, BGP).
    • Proposals exist to secure the infrastructure (DNSSEC, Secure BGP), but there are problems.
    • It should blow your mind—and worry you—that so much of the Internet is unsecured.

Disclaimer: This is part of the security section in 6.033. Only use the information you learn in this portion of the class to secure your own systems, not to attack others.

An invaluable resource for Bitcoin is this blog post: How the Bitcoin Protocol Actually Works.

  1. Introduction 
    • We’ve covered how to provide confidentiality, integrity, and authenticity.
    • Today we’re talking about anonymity.
    • Focus for next two lectures: Bitcoin and Tor.
      • Bitcoin: Digitial currency system, which (possibly) provides anonymity.
      • Tor: Network for users to remain anonymous.
      • Both deal with interesting technical problems.
      • Both solve problems using things we’ve taught you (public keys, signatures, etc.).
      • Very popular as of late.
    • You’ll see some threat models we haven’t considered yet.
    • So today: Bitcoin; next lecture: Tor.
  2. Currency 
    • What is money?
      • A medium for exchange. It’s not valuable for itself, but for future exchanges.
      • A store of value.
    • Good things about physical money:
      • Portable
      • Semi-anonymous (modulo, e.g., tracking serial numbers)
      • Can’t double-spend: I can’t spend the same bill in two places, since once I spend the bill it’s gone from my possession.
      • Can’t “repudiate” after payment: Once I pay someone with bills, I can’t lie and say “Oh no I didn’t really pay that person.”
      • No need for trusted third-party to make a transaction. You just hand the bill to the other person.
      • Government can print more as the economy expands or conditions dictate.
    • Neutral thing about physical money:
      • Difficult to tax/monitor transactions (good or bad depending on your goals).
    • Bad things about physical money:
      • Easy to steal.
      • Doesn’t work online.
    • Good things about electronic money (credit cards, paypal):
      • Works online.
      • Harder to steal (sometimes).
    • Bad things about electronic money:
      • No privacy.
  3. A Decentralized Digital Currency (Almost) 
    • Goal for right now: Try to build a digital currency that doesn’t require a trusted third party (a bank).
    • Need to address:
      • Forgery (can’t generate money you don’t have)
      • Double-spending (can’t spend the same money twice)
      • Theft
    • Idea 1:
      • Every time Alice wants to give Bob a coin, she simply sends him a message that says “I, Alice, am giving Bob one coin.”
      • Problem: Forgery! Anyone could forge that message.
    • Idea 2:
      • Sign those messages. Prevents forgery.
      • Problem: Duplicates. If Alice sends ten messages like the one above, did she give Bob ten coins? Were some retransmission?
    • Idea 3:
      • Add sequence numbers. It’s money, so let’s call those “serial numbers” instead.
    • Still to solve:
      • Keeping track of who owns which coins.
      • Assigning new serial numbers.
      • Verifying that a particular coin hasn’t already been spent.
    • Those unsolved problems are the things banks normally deal with.
  4. Dealing with Double-spending 
    • Problem: Alice tries to send the same coin to Bob and Charlie, i.e., to spend the coin twice.
    • Idea: Publish all transactions in some sort of public log. Instead of having a centralized bank keep track of all transactions, we’ll let everybody* keep track of all transactions.
      • Need a way to secure the log, and to make sure everyone has the correct version of the log.
    • Sketch of this idea:
      • If Alice sends a coin to Bob, he publishes that transaction and alerts everyone.
      • If Alice later tries to send the same coin to Charlie, all parties in the network will know that something is amiss: They’ll see that Alice already sent that coin to Bob.
    • Problem: What if Alice sent the coin to Bob and Charlie at the time, effectively spending it with both parties before either has had a chance to publish the transaction.
    • One idea: Get consensus. Agreement from “enough people” as to which transaction is valid (either the one with Bob or the one with Charlie).
    • Instead of “enough people”, let’s say, specifically, “more than 50% of the network”. There are at least two problems with this:
      1. We might not know how many people are in the network.
      2. Even if we know how many people are in the network, Alice could create multiple identities herself. This is known as a Sybil Attack: A user subverts a system by creating multiple identities.
  5. Proofs-of-work 
    • Proofs-of-work thwart Sybil Attacks. Make it computationally expensive to perform an action. Then, multiple identities don’t help. You need a lot of computational power to perform a Sybil Attack, which is much harder to get.
    • Bitcoin’s proof of work:
      • A user K broadcasts the following message to users on the network: “I, K, want to spend coin 198601 with Bob.”
      • Users who hear that message add it to their queue of pending transactions. Their goal is to verify a block of those transactions.
      • After a user checks that the block is valid - that everyone owns the coins they’re trying to spend—they set about solving the following “puzzle”:
        • t = block of transactions (as a bitstring).
        • Find x such that H(t|x) < target.
        • Target changes frequently. Adjusted so that it takes roughly ten minutes to solve this puzzle.
      • When a user solves the puzzle (finds x), they broadcast the block out along with x. They receive a monetary reward for solving the proof of work, to motivate users to take part in this process.
      • This process is known as “mining” bitcoins.
    • What if two people solve the puzzle at the same time? We’ll save that problem for a second.
  6. Ordering Transactions 
    • How does validating with the log work?
    • Log contains verified transaction blocks *and* a pointer to the previous block. This provides an ordering on the transactions, so we know who owns what coin.
      • The “pointer” is a hash of the previous block.
      • The log is actually called the blockchain.
    • If two people solve the puzzle at the same time, the blockchain forks:
  7. Did We Prevent Double-spending? 
    • Can Alice validate a block that includes a transaction with the same coin at two different people? No, the rest of the network will see something is amiss when they get that block.
    • Can Alice try to spend the same coin twice with Bob and Charlie and get the network to verify it? No. At best, the blockchain will fork, but eventually only one fork (and so one transaction) will be validated.
    • Can Alice spend the same coin with Charlie and herself (as a Sybil)? Send the coin to Charlie, wait for the transaction to be entirely confirmed, then have her Sybil fork the chain prior to the transaction with Charlie, and “catch up” with the system so that the new branch becomes longer? (Effectively invalidating the previous transaction, but Alice already spent that coin.) Unlikely—other miners won’t help, so she’d need a lot of compute power.
  8. Discussion 
    • Bitcoin provides you with a distributed public ledger. You can build other things on top of that, not just a digital currency.
    • Possible criticisms:
      • Proofs-of-work waste computation.
      • In practice, users are either “normal” users who spend but don’t mine, or mining pools who mine but don’t spend.
      • It can take a long time to confirm a transaction.
    • Alternatives exist for solving some of these problems.
      • Ethereum and Algorand are two.
    • Are users actually anonymous?

For this recitation, you’ll be reading “SoK: Eternal War in Memory (PDF)” by Lazlo Szekeres, Mathia Payer, Tao Wei, and Dawn Song. This paper describes a variety of memory corruption bugs, and potential solutions. Don’t worry about memorizing every single type of attack described in this paper; aim to understand what makes these attacks possible, and the general ideas behind the solutions.

(We’ve also written a quick guide (PDF) to some of the memory corruption bugs described in the paper, which you might want to take a look at before you start reading.)

The paper is fairly well organized:

  • Section I gives you an introduction to the general problem, and a brief history of memory corruption attacks and defenses.
  • Section II details many different types of memory corruption attacks. Figure 1 is particularly helpful in organizing these attacks and their defenses. As stated above, don’t worry about memorizing every single type of attack described in this section; aim to understand what makes the various attacks different from one another, as well as what makes each of these possible in the first place.
  • Section III describes two currently-deployed defenses, and their drawbacks.
  • Section IV outlines some properties and requirements for defenses against memory corruption bugs; those defenses are discussed in Sections V-VIII (each section is a different category of defense).
  • Sections IX and X conclude.

As you read, think about the following:

  • Stack canaries (or cookies) and ASLR are both widely-deployed. What is good about those solutions? What attacks do they prevent? What attacks don’t they prevent?
  • Many of the proposed solutions worsen performance. Are we at a point where these performance hits are outweighed by security concerns?

Questions for Recitation

Before you come to this recitation, write up (on paper) a brief answer to the following (really—we don’t need more than a couple sentences for each question).  

Your answers to these questions should be in your own words, not direct quotations from the paper.

  • What do the authors mean by “the eternal war in memory”?
  • How has this war progressed over time? (i.e., how have attacks and solutions evolved)
  • Why hasn’t the war ended?

As always, there are multiple correct answers for each of these questions.

Course Info

Instructor
Departments
As Taught In
Spring 2018
Level
Undergraduate
Topics
Learning Resource Types
Lecture Notes
Written Assignments
Projects with Examples
Instructor Insights
Download Course
MIT Open Learning
Over 2,500 courses & materials
Freely sharing knowledge with learners and educators around the world. Learn more
© 2001–2024 Massachusetts Institute of Technology
Accessibility
Creative Commons License
Terms and Conditions
Proud member of:
© 2001–2024 Massachusetts Institute of Technology