Attacks on DNS: Risks of Caching. March 21, 2018
|
|
- Jonah Powers
- 5 years ago
- Views:
Transcription
1 ttacks on DNS: Risks of Caching March 21, 2018
2 The Inside Story of How Facebook Responded to Tunisian Hacks It was on Christmas Day that Facebook's Chief Security Officer Joe Sullivan first noticed strange things going on intunisia. Reports started to trickle in that political-protest pages were being hacked. "We were getting anecdotal reports saying 'It looks like someone logged into my account and deleted it' " Sullivan said.
3
4
5
6
7
8 DNS Overview DNS translates to It s a performance-critical distributed database. DNS security is critical for the web. (Same-origin policy assumes DNS is secure.) nalogy: If you don t know the answer to a question, ask a friend for help (who may in turn refer you to a friend of theirs, and so on).
9 DNS Overview DNS translates to It s a performance-critical distributed database. DNS security is critical for the web. (Same-origin policy assumes DNS is secure.) nalogy: If you don t know the answer to a question, ask a friend for help (who may in turn refer you to a friend of theirs, and so on). Security risks: friend might be malicious, communication channel to friend might be insecure, friend might be well-intentioned but misinformed
10 DNS Lookups via a Resolver Host at xyz.poly.edu wants IP address for eecs.mit.edu local DNS server (resolver) dns.poly.edu 2 root DNS server (. ) TLD DNS server (.edu ) Caching heavily used to minimize lookups authoritative DNS server (for mit.edu ) dns.mit.edu requesting host xyz.poly.edu eecs.mit.edu
11 Group Discussion Please discuss the potential attacks towards DNS and illustrate it.
12 Security risk #1: malicious DNS server Of course, if any of the DNS servers queried are malicious, they can lie to us and fool us about the answer to our DNS query (In fact, they used to be able to fool us about the answer to other queries, too. We ll come back to that.)
13 Security risk #2: on-path eavesdropper If attacker can eavesdrop on our traffic we re hosed. Why? We ll see why.
14 Security risk #3: off-path attacker If attacker can t eavesdrop on our traffic, can he inject spoofed DNS responses? This case is especially interesting, so we ll look at it in detail.
15 DNS Threats DNS: path-critical for just about everything we do Maps hostnames IP addresses Design only scales if we can minimize lookup traffic o #1 way to do so: caching o #2 way to do so: return not only answers to queries, but additional info that will likely be needed shortly What if attacker eavesdrops on our DNS queries? Then similar to DHCP/TCP, can spoof responses Consider attackers who can t eavesdrop - but still aim to manipulate us via how the protocol functions Directly interacting w/ DNS: dig program on Unix llows querying of DNS system Dumps each field in DNS responses
16 dig eecs.mit.edu Use Unix dig utility to look up IP address ( )for hostname eecs.mit.edu via DNS ; ; <<>> DiG PPLE- <<>> eecs.mit.edu a P2 ;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu ;; UTHORITY SECTION: NS BITSY.mit.edu. mit.edu. mit.edu NS W20NS.mit.edu. mit.edu NS STRWB.mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu
17 dig eecs.mit.edu ; ; <<>> DiG PPLE- <<>> eecs.mit.edu a P2 ;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu ;; UTHORITY mit.edu. mit.edu. mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu. SECTION: N BITSY.mit.edu S. The question we asked the server NSN STRWB.mit.edu. W20NS.mit.edu S
18 dig eecs.mit.edu ; ; <<>> DiG PPLE- <<>> eecs.mit.edu a P2 ;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: bit transaction identifier that enables eecs.mit.edu. 00the DNS client (dig, in this case) to match up the reply with its original request ;; UTHORITY SECTION: mit.edu NS BITSY.mit.edu. mit.edu NS W20NS.mit.edu. mit.edu NS STRWB.mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu
19 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a;; global options: +cmd ;; Got answer: ;; ->>HEDER<<flags: qr rd d UERY: eecs.mit.edu with eecs.mit.edu 1, NSWER: is , and UTHORITY: we can cache and3, we thecan resultionl: 3 opco e: nswer nswer QUERY, tells status: tells us the the NOERROR, IP IPaddress id: associated with ;; ra; for cache DDIT 21,600 the seconds result for 21,600 seconds ;; QUESTION SECTION: Q ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu ;; UTHORITY SECTION: NS BITSY.mit.edu. mit.edu. mit.edu NS W20NS.mit.edu. mit.edu NS STRWB.mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu
20 dig eecs.mit.edu ; ; <<>> DiG PPLE- <<>> eecs.mit.edu a P2 ;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu ;; UTHORITY mit.edu. mit.edu. mit.edu. ;; DDITIONL SECTIO STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu. SECTION: NS In general, a single Resource Record (RR) like BITSY.mit.e this includes, left-to-right, a DNS name, a timeto-live, a family ( for our purposes - ignore), NS W20NS.mit.e a type (here), and an associated NS. value du. du. edu.
21 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a;; global options: +cmd uthority tells us the name servers responsible for ;; Got answer: the answer. Each RR gives the hostname of a different ;; ->>HEDER<<- opcode: name QUERY, server status: ( NS )for NOERROR, names in mit.edu. id: 19901We should ;; flags: qr rd ra; QUERY: cache1, each NSWER: record for 1, 11,088 UTHORITY: seconds. 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu. If the nswer had been empty, then the resolver s next step would be to send the original query to one of these name servers ;; UTHORITY mit.edu. mit.edu. mit.edu. SECTION: ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu NS NS NS BITSY.mit.edu. W20NS.mit.edu. STRWB.mit.edu
22 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a ;; global options: +cmd ;; Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. dditional provides extra information to save us from making separate lookups for it, or helps with bootstrapping. ;; NSWER SECTION: eecs.mit.edu. Here, it tells us the IP addresses for the hostnames of the name servers. We add these to our cache. ;; UTHORITY SECTION: NS BITSY.mit.edu. mit.edu. mit.edu NS W20NS.mit.edu. mit.edu NS STRWB.mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu
23 DNS Protocol IP Header Lightweight exchange of query and reply messages, both with same message format Primarily uses UDP for its transport protocol, which is what we ll assume Frequently, both clients and servers use port 53 UDP Header UDP Payload 16 bits 16 bits SRC port checksum Identification Flags # Questions # nswer RRs DNS Query DST port # uthority RRs # dditional RRs Questions (variable # of resource records) or length nswers (variable # of resource records) Reply uthority (variable # of resource records) dditional information (variable # of resource records)
24 DNS Protocol IP Header Lightweight exchange of query and reply messages, both with same message format Primarily uses UDP for its transport protocol, which is what we ll assume Frequently, both clients and servers use port 53 UDP Header UDP Payload 16 bits 16 bits SRC=53 checksum Identification Flags # Questions # nswer RRs DNS Query DST=53 # uthority RRs # dditional RRs Questions (variable # of resource records) or length nswers (variable # of resource records) Reply uthority (variable # of resource records) dditional information (variable # of resource records)
25 DNS Protocol, cont. Message header: Identification: 16 bit # for query, reply to query uses same # long with repeating the Question and providing nswer(s), replies can include uthority (name server responsible for answer) and dditional (info client is likely to look up soon anyway) Each Resource Record has a Time To Live (in seconds) for caching (not shown) SRC=53 checksum Identification IP Header 16 bits 16 bits D ST=53 length Flags # Questions # nswer RRs # uthority RRs # dditional RRs Questions (variable # of resource records) nswers (variable # of resource records) uthority (variable # of resource records) dditional information (variable # of resource records)
26 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a;; global options: +cmd ;; Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 19 1, NSWER: 1, What if the mit.edu server is untrustworthy? UTHORITY: 3, Could 901 DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. its operator steal, say, all of our web surfing to ;; NSWER SECTION: berkeley.edu s main web eecs.mit.edu server? ;; UTHORITY SECTION: NS BITSY.mit.edu. mit.edu. mit.edu NS W20NS.mit.edu. mit.edu NS STRWB.mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu
27 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu. Let s look at a flaw in the original DNS design (since fixed) ;; UTHORITY SECTION: NS BITSY.mit.edu. mit.edu. mit.edu NS W20NS.mit.edu. mit.edu NS STRWB.mit.edu. ;; DDITIONL SECTION: STRWB.mit.edu. BITSY.mit.edu. W20NS.mit.edu
28 dig eecs.mit.edu ; ; <<>> DiG PPLE- <<>> eecs.mit.edu a P2 ;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: What ;eecs.mit.edu. What could could happen happen if the if the mit.edu mit.edu server server returns the following to us instead? ;; NSWER SECTION: eecs.mit.edu. ;; UTHORITY SECTION: returns the following to us instead? mit.edu NS BITSY.mit.edu. mit.edu NS W20NS.mit.edu. mit.edu. 30 NS ;; DDITIONL SECTION: BITSY.mit.edu. W20NS.mit.edu
29 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a ;; global options: +cmd ;; Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu. ;; SECTION: UTHORITY mit.edu. mit.edu.;; DDITIONL SECTION: mit.edu BITSY.mit.edu. W20NS.mit.edu. We d dutifully store in our cache a mapping of to an IP address under MIT s control. (It could have been any IP address they wanted, not just one of theirs.) NS NS NS BITSY.mit.edu. W20NS.mit.edu
30 dig eecs.mit.edu ; ; <<>> DiG PPLE- <<>> eecs.mit.edu a P2 ;; global options: ;; +cmd Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. In this case they chose to make the ;; NSWER SECTION: mapping disappear after 30 seconds. eecs.mit.edu They could have made it persist for 6 weeks, or disappear even quicker. ;; UTHORITY SECTION: mit.edu NS BITSY.mit.edu. mit.edu NS W20NS.mit.edu. mit.edu. 30 NS ;; DDITIONL SECTION: BITSY.mit.edu. W20NS.mit.edu
31 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a ;; global options: +cmd ;; Got answer: ;; ->>HEDER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, NSWER: 1, UTHORITY: 3, DDITIONL: 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu. How do we fix such cache poisoning? ;; UTHORITY SECTION: mit.edu NS BITSY.mit.edu. mit.edu NS W20NS.mit.edu. mit.edu. 30 NS ;; DDITIONL SECTION: BITSY.mit.edu. W20NS.mit.edu
32 dig eecs.mit.edu ; ; <<>> DiG PPLE-P2 <<>> eecs.mit.edu a;; global options: + cmd Don t accept dditional records unless ;; Got answer: ;; ->>HEDER<<- opcode: they re QUERY, for status: the domain NOERROR, we re id: looking up ;; flags: qr rd ra; QUERY: E.g., 1, looking NSWER: up1, eecs.mit.edu UTHORITY: 3, DDITIONL: only accept 3 ;; QUESTION SECTION: ;eecs.mit.edu. ;; NSWER SECTION: eecs.mit.edu. additional records from *. mit.edu No extra risk in accepting these since server could return them to us directly in an nswer anyway ;; UTHORITY SECTION: mit.edu. = mit.edu mit.edu. 30 ;; DDITIONL SECTION: BITSY.mit.edu. W20NS.mit.edu N S NS NS BITSY.mit.edu. W20NS.mit.edu
33 Security risk #1: malicious DNS server Of course, if any of the DNS servers queried are malicious, they can lie to us and fool us about the answer to our DNS query and they used to be able to fool us about the answer to other queries, too, using cache poisoning. Now fixed (phew).
34 Security risk #2: on-path eavesdropper If attacker can eavesdrop on our traffic we re hosed. Why?
35 Security risk #2: on-path eavesdropper If attacker can eavesdrop on our traffic we re hosed. Why? They can see the query and the 16-bit transaction identifier, and race to send a spoofed response to our query.
36 Security risk #3: off-path attacker If attacker can t eavesdrop on our traffic, can he inject spoofed DNS responses? nswer: It used to be possible, via blind spoofing. We ve since deployed mitigations that makes this harder (but not totally impossible).
37 Blind spoofing 16 bits 16 bits SRC=53 D ST=53 Say we look up mail.google.com; how can an off-path attacker feed us a bogus answer before the legitimate server replies? checksum Identification length Flags # Questions # nswer RRs # uthority RRs # dditional RRs Questions (variable # of resource records) How can such a remote attacker even know we are looking up mail.google.com? Suppose, e.g., we visit a web page under their control: nswers (variable # of resource records) uthority (variable # of resource records) dditional information (variable # of resource records)...<img src=" >...
38 Blind spoofing 16 bits 16 bits SRC=53 D ST=53 Say we look up Identification mail.google.com; how can an off-path attacker feed us a bogusthis answer HTML before snippet thecauses our legitimthis browser ate server HTML to replies? try snippet to fetch causes an image our from browser mail.google.com. to try to fetch To do anthat, image our from How cmail.google.com. browser an such an first attacker has to look To doup that, the our IP even know address we are associated looking with up that name. mail.google.com? Suppose, e.g., we visit a web page under their control: checksum length Flags # Questions # nswer RRs # uthority RRs # dditional RRs Questions (variable # of resource records) nswers (variable # of resource records) uthority (variable # of resource records) dditional information (variable # of resource records)...<img src=" >...
39 Blind spoofing Once they know we re looking it up, they just have to guess the Identification field and reply before legit server. How hard is that? Originally, identification field incremented by 1 for each request. How does attacker guess it? SRC=53 checksum Identification Fix? 16 bits 16 bits D ST=53 length Flags # Questions # nswer RRs # uthority RRs # dditional RRs Questions (variable # of resource records) nswers (variable # of resource records) uthority (variable # of resource records) dditional information (variable # of resource records) <img src=" > <img src=" They observe ID k here > So this will be k+1
40 DNS Blind Spoofing, cont. Once we randomize the Identification, attacker has a 1/65536 chance of guessing it correctly. re we pretty much safe? ttacker can send lots of replies, not just one However: once reply from legit server arrives (with correct Identification), it s cached and no more opportunity to poison it. Victim is innoculated! 16 bits 16 bits SRC=53 checksum Identification D ST=53 length Flags # Questions # nswer RRs # uthority RRs # dditional RRs Questions (variable # of resource records) nswers (variable # of resource records) uthority (variable # of resource records) dditional information (variable # of resource records) Unless attacker can send 1000s of replies before legit arrives, we re likely safe phew!?
41 Extra Material
42 Summary of DNS Security Issues DNS threats highlight: ttackers can attack opportunistically rather than eavesdropping o Cache poisoning only required victim to look up some name under attacker s control (has been fixed) ttackers can often manipulate victims into vulnerable activity o E.g., IMG SRC in web page to force DNS lookups Crucial for identifiers associated with communication to have sufficient entropy (= a lot of bits of unpredictability) ttacks only get better : threats that appears technically remote can become practical due to unforeseen cleverness
43 Common Security ssumptions (Note, these tend to be pessimistic but prudent) ttackers can interact with our systems without particular notice Probing (poking at systems) may go unnoticed even if highly repetitive, leading to crashes, and easy to detect It s easy for attackers to know general information about their targets OS types, software versions, usernames, server ports, IP addresses, usual patterns of activity, administrative procedures
44 Common ssumptions ttackers can obtain access to a copy of a given system to measure and/or determine how it works ttackers can make energetic use of automation They can often find clever ways to automate ttackers can pull off complicated coordination across a bunch of different elements/systems ttackers can bring large resources to bear if needed Computation, network capacity But they are not super-powerful (e.g., control entire ISPs)
45 Common ssumptions If it helps the attacker in some way, assume they can obtain privileges But if the privilege gives everything away (attack becomes trivial), then we care about unprivileged attacks The ability to robustly detect that an attack has occurred does not replace desirability of preventing Infrastructure machines/systems are well protected (hard to directly take over) So a vulnerability that requires infrastructure compromise is less worrisome than same vulnerability that doesn t
46 Common ssumptions Network routing is hard to alter other than with physical access near clients (e.g., coffeeshop ) Such access helps fool clients to send to wrong place Can enable Man-in-the-Middle (MITM) attacks We worry about attackers who are lucky Since often automation/repetition can help make luck Just because a system does not have apparent value, it may still be a target ttackers are undaunted by fear of getting caught
Attacks on DNS: Risks of Caching
Attacks on DNS: Risks of Caching CS 161: Computer Security Prof. David Wagner March 30, 2016 Today Midterm 2 grades available Reminder: Start Project 2, Part 2! Today, DNS: protocol for mapping hostnames
More informationNetwork security (DNS caching and DoS)
Network security (DNS caching and DoS) CS 161: Computer Security Prof. Raluca Ada Popa March 1, 2018 Slides adapted from David Wagner DNS Overview DNS translates www.google.com to 74.125.25.99 It s a performance-critical
More informationNetwork Attacks. CS Computer Security Profs. Vern Paxson & David Wagner
Network Attacks CS 161 - Computer Security Profs. Vern Paxson & David Wagner TAs: John Bethencourt, Erika Chin, Matthew Finifter, Cynthia Sturton, Joel Weinberger http://inst.eecs.berkeley.edu/~cs161/
More informationNetwork Attacks. CS Computer Security. Once again thanks to Vern Paxson and David Wagner
Network Attacks CS 334 - Computer Security Once again thanks to Vern Paxson and David Wagner 1 Layers 1 & 2: General Threats? 7 4 3 2 1 Application Transport (Inter)Network Link Physical Framing and transmission
More informationThis time. Digging into. Networking. Protocols. Naming DNS & DHCP
This time Digging into Networking Protocols Naming DNS & DHCP Naming IP addresses allow global connectivity But they re pretty useless for humans! Can t be expected to pick their own IP address Can t be
More informationWeaver. Computer Science 161 Fall Network Security 3
Network Security 3 1 Spot the Zero Day: TPLink Miniature Wireless Router 2 Spot the Zero Day: TPLink Miniature Wireless Router 3 DNS Resource Records and RRSETs DNS records (Resource Records) can be one
More informationMore on DNS and DNSSEC
More on DNS and DNSSEC CS 161: Computer Security Prof. Raluca Ada Popa March 6, 2018 A subset of the slides adapted from David Wagner Domain names Domain names are human friendly names to identify servers
More informationLocal DNS Attack Lab. 1 Lab Overview. 2 Lab Environment. 2.1 Install and configure the DNS server. SEED Labs Local DNS Attack Lab 1
SEED Labs Local DNS Attack Lab 1 Local DNS Attack Lab Copyright c 2006-2015 Wenliang Du, Syracuse University. The development of this document is partially funded by the National Science Foundation s Course,
More informationDNSSEC. CS 161: Computer Security Prof. David Wagner. April 11, 2016
DNSSEC CS 161: Computer Security Prof. David Wagner April 11, 2016 DNSSEC Last lecture, you invented DNSSEC. Well, the basic ideas, anyway: Sign all DNS records. Signatures let you verify answer to DNS
More informationDNS: Useful tool or just a hammer? Paul DNS-OARC 06 Oct 2013, Phoenix
DNS: Useful tool or just a hammer? Paul Ebersman pebersman@infoblox.com, @paul_ipv6 DNS-OARC 06 Oct 2013, Phoenix 1 Attacking your cache 2 Recursion DNS queries are either recursive or nonrecursive recursive
More informationCSC 574 Computer and Network Security. DNS Security
CSC 574 Computer and Network Security DNS Security Alexandros Kapravelos kapravelos@ncsu.edu (Derived from slides by Will Enck and Micah Sherr) A primer on routing Routing Problem: How do Alice s messages
More informationTCP/IP SECURITY GRAD SEC NOV
TCP/IP SECURITY GRAD SEC NOV 14 2017 TODAY S PAPERS WHY DOES THE INTERNET WORK? 1. PROTOCOLS Agreements on how to communicate Publicly standardized, esp. via Requests for Comments (RFCs) RFC 826: ARP RFC
More informationWEB SECURITY: XSS & CSRF
WEB SECURITY: XSS & CSRF CMSC 414 FEB 22 2018 Cross-Site Request Forgery (CSRF) URLs with side-effects http://bank.com/transfer.cgi?amt=9999&to=attacker GET requests should have no side-effects, but often
More informationDNS Review Quiz. Match the term to the description: A. Transfer of authority for/to a subdomain. Domain name DNS zone Delegation C B A
DNS Review Quiz Match the term to the description: C B A Level: Domain name DNS zone Delegation Descriptions: A. Transfer of authority for/to a subdomain B. A set of names under the same authority (ie.com
More information2008 DNS Cache Poisoning Vulnerability Cairo, Egypt November 2008
2008 DNS Cache Poisoning Vulnerability Cairo, Egypt November 2008 Kim Davies Manager, Root Zone Services Internet Corporation for Assigned Names & Numbers How do you attack the DNS? A typical DNS query
More informationCSE 127: Computer Security Network Security. Kirill Levchenko
CSE 127: Computer Security Network Security Kirill Levchenko November 28, 2017 Network Security Original TCP/IP design: Trusted network and hosts Hosts and networks administered by mutually trusted parties
More informationDNS Security. *http://compsec101.antibozo.net/pa pers/dnssec/dnssec.html. IT352 Network Security Najwa AlGhamdi
DNS Security *http://compsec101.antibozo.net/pa pers/dnssec/dnssec.html 1 IT352 Network Security Najwa AlGhamdi Introduction The DNS provides a mechanism that resolves Internet host names into IP addresses
More informationDomain Name Service. DNS Overview. October 2009 Computer Networking 1
Domain Name Service DNS Overview October 2009 Computer Networking 1 Why DNS? Addresses are used to locate objects (contain routing information) Names are easier to remember and use than numbers DNS provides
More informationOutline NET 412 NETWORK SECURITY PROTOCOLS. Reference: Lecture 7: DNS Security 3/28/2016
Networks and Communication Department NET 412 NETWORK SECURITY PROTOCOLS Lecture 7: DNS Security 2 Outline Part I: DNS Overview of DNS DNS Components DNS Transactions Attack on DNS Part II: DNS Security
More informationDomain Name System (DNS) Session-1: Fundamentals. Joe Abley AfNOG Workshop, AIS 2017, Nairobi
Domain Name System (DNS) Session-1: Fundamentals Joe Abley AfNOG Workshop, AIS 2017, Nairobi Computers use IP addresses. Why do we need names? Names are easier for people to remember Computers may be moved
More informationshortcut Tap into learning NOW! Visit for a complete list of Short Cuts. Your Short Cut to Knowledge
shortcut Your Short Cut to Knowledge The following is an excerpt from a Short Cut published by one of the Pearson Education imprints. Short Cuts are short, concise, PDF documents designed specifically
More informationDNS CACHE POISONING LAB
University of Trento Network Security - Malware lab 2 th May 2016 DNS CACHE POISONING LAB GROUP #15: MATTEO FIORANZATO MATTEO MATTIVI ANDREA SIMONELLI MICHELA TESTOLINA DON T CLOSE OR MOVE ANY WINDOW Lab
More informationThe Application Layer: Sockets, DNS
The Application Layer: Sockets, DNS CS 352, Lecture 3 http://www.cs.rutgers.edu/~sn624/352-s19 Srinivas Narayana 1 App-layer protocol Types of messages exchanged, e.g., request, response Message format:
More informationCSE 565 Computer Security Fall 2018
CSE 565 Computer Security Fall 2018 Lecture 18: Network Attacks Department of Computer Science and Engineering University at Buffalo 1 Lecture Overview Network attacks denial-of-service (DoS) attacks SYN
More informationCS 161 Computer Security
Raluca Ada Popa Spring 2018 CS 161 Computer Security Discussion 7 Week of March 5, 2018 Question 1 DHCP (5 min) Professor Raluca gets home after a tiring day writing papers and singing karaoke. She opens
More informationDOMAIN NAME SECURITY EXTENSIONS
DOMAIN NAME SECURITY EXTENSIONS The aim of this paper is to provide information with regards to the current status of Domain Name System (DNS) and its evolution into Domain Name System Security Extensions
More informationImplementing DNSSEC with DynDNS and GoDaddy
Implementing DNSSEC with DynDNS and GoDaddy Lawrence E. Hughes Sixscape Communications 27 December 2017 DNSSEC is an IETF standard for adding security to the DNS system, by digitally signing every resource
More informationSecuring Internet Communication: TLS
Securing Internet Communication: TLS CS 161: Computer Security Prof. David Wagner March 11, 2016 Today s Lecture Applying crypto technology in practice Two simple abstractions cover 80% of the use cases
More informationCS 3640: Introduction to Networks and Their Applications
CS 3640: Introduction to Networks and Their Applications Fall 2018, Lecture 19: Application Layer III (Credit: Prof. Phillipa Gill @ University of Massachusetts) Instructor: Rishab Nithyanand Teaching
More informationSicurezza dei sistemi e delle reti
Sicurezza dei sistemi e delle reti LAB: DNS LOCAL ATTACK Pharming attacks The main objective of Pharming attacks on a user is to redirect the user to another machine B when the user tries to get to machine
More informationLocal DNS Attack Lab. 1 Lab Overview. 2 Lab Tasks (Part I): Setting Up a Local DNS Server. SEED Labs Local DNS Attack Lab 1
SEED Labs Local DNS Attack Lab 1 Local DNS Attack Lab Copyright 2018 Wenliang Du, Syracuse University. The development of this document was partially funded by the National Science Foundation under Award
More informationInternet Engineering. DNS Message Format. Contents. Robert Elz.
Internet Engineering 241-461 Robert Elz kre@munnari.oz.au kre@coe.psu.ac.th http://fivedots.coe.psu.ac.th/~kre Contents The Domain Name System The DNS Database DNS Protocols DNS Message Formats ueries
More informationCS519: Computer Networks. Lecture 6: Apr 5, 2004 Naming and DNS
: Computer Networks Lecture 6: Apr 5, 2004 Naming and DNS Any problem in computer science can be solved with another layer of indirection David Wheeler Naming is a layer of indirection What problems does
More informationCYBER ATTACKS EXPLAINED: PACKET SPOOFING
CYBER ATTACKS EXPLAINED: PACKET SPOOFING Last month, we started this series to cover the important cyber attacks that impact critical IT infrastructure in organisations. The first was the denial-of-service
More informationAgenda. Review DNS Fundamentals DNS Security Summary 1/22
Agenda Review DNS Fundamentals DNS Security Summary 1/22 Which of the following is NOT a commonly used routing metric? A. Hop count B. Bandwidth C. Delay D. Destination s IP address E. Reliability of links
More informationCS118 Discussion 1A, Week 3. Zengwen Yuan Dodd Hall 78, Friday 10:00 11:50 a.m.
CS118 Discussion 1A, Week 3 Zengwen Yuan Dodd Hall 78, Friday 10:00 11:50 a.m. 1 Outline Application Layer Protocol: DNS, CDN, P2P Transport Layer Protocol: UDP, principles of reliable transport protocol
More informationDomain Name System.
Domain Name System http://xkcd.com/302/ CSCI 466: Networks Keith Vertanen Fall 2011 Overview Final project + presentation Some TCP and UDP experiments Domain Name System (DNS) Hierarchical name space Maps
More informationChair for Network Architectures and Services Department of Informatics TU München Prof. Carle. Network Security. Chapter 8
Chair for Network Architectures and Services Department of Informatics TU München Prof. Carle Network Security Chapter 8 System Vulnerabilities and Denial of Service Attacks System Vulnerabilities and
More informationDNS Cache Poisoning Looking at CERT VU#800113
DNS Cache Poisoning Looking at CERT VU#800113 Nadhem J. AlFardan Consulting Systems Engineer Cisco Systems ANOTHER BORING DNS ISSUE Agenda DNS Poisoning - Introduction Looking at DNS Insufficient Socket
More informationICS 351: Today's plan. IPv6 routing protocols (summary) HTML HTTP web scripting languages certificates (review) cookies
ICS 351: Today's plan IPv6 routing protocols (summary) HTML HTTP web scripting languages certificates (review) cookies IPv6 routing almost the same routing protocols as for IPv4: RIPng, OSPFv6, BGP with
More informationLecture 6 Application Layer. Antonio Cianfrani DIET Department Networking Group netlab.uniroma1.it
Lecture 6 Application Layer Antonio Cianfrani DIET Department Networking Group netlab.uniroma1.it Application-layer protocols Application: communicating, distributed processes running in network hosts
More informationProgress Report 1. Group RP16. All work done by Ivan Gromov and Andrew McConnell
Progress Report 1 Group RP16 All work done by Ivan Gromov and Andrew McConnell Steps completed: Task Mode Task Name Duration Start Finish Predecessor s Resource Names Manually Schedule d First Lab research
More informationDNS and HTTP. A High-Level Overview of how the Internet works
DNS and HTTP A High-Level Overview of how the Internet works Adam Portier Fall 2017 How do I Google? Smaller problems you need to solve 1. Where is Google? 2. How do I access the Google webpage? 3. How
More informationIntroduction to Network. Topics
Introduction to Network Security Chapter 7 Transport Layer Protocols 1 TCP Layer Topics Responsible for reliable end-to-end transfer of application data. TCP vulnerabilities UDP UDP vulnerabilities DNS
More informationA Security Evaluation of DNSSEC with NSEC Review
A Security Evaluation of DNSSEC with NSEC Review Network Security Instructor:Dr. Shishir Nagaraja Submitted By: Jyoti Leeka November 16, 2011 1 Introduction to the topic and the reason for the topic being
More informationCPSC 441 COMPUTER COMMUNICATIONS MIDTERM EXAM SOLUTION
CPSC 441 COMPUTER COMMUNICATIONS MIDTERM EXAM SOLUTION Department of Computer Science University of Calgary Professor: Carey Williamson March 2, 2012 This is a CLOSED BOOK exam. Textbooks, notes, laptops,
More informationRemote DNS Cache Poisoning Attack Lab
CS482 Remote DNS Cache Poisoning Attack Lab 1 1 Lab Overview Remote DNS Cache Poisoning Attack Lab The objective of this lab is for students to gain the first-hand experience on the remote DNS cache poisoning
More informationDNS Pharming Attack Lab
CNT 5140 - Fall 2017 1 DNS Pharming Attack Lab Copyright c 2006-2011 Wenliang Du, Syracuse University. The development of this document is funded by the National Science Foundation s Course, Curriculum,
More informationCSCE 463/612 Networks and Distributed Processing Spring 2018
CSCE 463/612 Networks and Distributed Processing Spring 2018 Application Layer IV Dmitri Loguinov Texas A&M University February 13, 2018 1 Chapter 2: Roadmap 2.1 Principles of network applications 2.2
More informationFoundations of Network and Computer Security
Foundations of Network and Computer Security John Black Lecture #25 Dec 1 st 2005 CSCI 6268/TLEN 5831, Fall 2005 Announcements Remainder of the semester: Quiz #3 is Today 40 mins instead of 30 mins Next
More informationHow to Stay Safe on Public Wi-Fi Networks
How to Stay Safe on Public Wi-Fi Networks Starbucks is now offering free Wi-Fi to all customers at every location. Whether you re clicking connect on Starbucks Wi-Fi or some other unsecured, public Wi-Fi
More informationChapter 2 Application Layer. Lecture 5 DNS. Computer Networking: A Top Down Approach. 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012
Chapter 2 Application Layer Lecture 5 DNS Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Application Layer 2-1 Chapter 2: outline 2.1 principles
More informationComputer Security CS 426
Computer Security CS 426 Lecture 34 DNS Security 1 Domain Name System Translate host names to IP addresses E.g., www.google.com 74.125.91.103 Hostnames are human-friendly IP addresses keep changing And
More informationECE 435 Network Engineering Lecture 7
ECE 435 Network Engineering Lecture 7 Vince Weaver http://web.eece.maine.edu/~vweaver vincent.weaver@maine.edu 25 September 2018 HW#3 was Posted Announcements 1 HW#2 Review C code will be discussed next
More informationR (2) Implementation of following spoofing assignments using C++ multi-core Programming a) IP Spoofing b) Web spoofing.
R (2) N (5) Oral (3) Total (10) Dated Sign Experiment No: 1 Problem Definition: Implementation of following spoofing assignments using C++ multi-core Programming a) IP Spoofing b) Web spoofing. 1.1 Prerequisite:
More informationEE 122: Network Security
Motivation EE 122: Network Security Kevin Lai December 2, 2002 Internet currently used for important services - financial transactions, medical records Could be used in the future for critical services
More informationDomain Name System (DNS) DNS Fundamentals. Computers use IP addresses. Why do we need names? hosts.txt does not scale. The old solution: HOSTS.
Domain Name System (DNS) Computers use IP addresses. Why do we need names? Names are easier for people to remember DNS Fundamentals Computers may be moved between networks, in which case their IP address
More informationNETWORK SECURITY. Ch. 3: Network Attacks
NETWORK SECURITY Ch. 3: Network Attacks Contents 3.1 Network Vulnerabilities 3.1.1 Media-Based 3.1.2 Network Device 3.2 Categories of Attacks 3.3 Methods of Network Attacks 03 NETWORK ATTACKS 2 3.1 Network
More informationInternet Protocol and Transmission Control Protocol
Internet Protocol and Transmission Control Protocol CMSC 414 November 13, 2017 Internet Protcol Recall: 4-bit version 4-bit hdr len 8-bit type of service 16-bit total length (bytes) 8-bit TTL 16-bit identification
More informationTransaction oriented DNS flow analysis (WIP)
Transaction oriented DNS flow analysis (WIP) Shigeya Suzuki / Bill Manning WIDE Project USC/ISI & Keio University + Auto-ID Labs Japan CAIDA Workshop 2006 @ISI, March 17th 2006 Topics Current on-going
More information6.033 Computer System Engineering
MIT OpenCourseWare http://ocw.mit.edu 6.033 Computer System Engineering Spring 2009 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms. M.I.T. DEPARTMENT
More informationCS 3640: Introduction to Networks and Their Applications
CS 3640: Introduction to Networks and Their Applications Fall 2018, Lecture 18: The Application Layer II (Credit: Christo Wilson @ NEU) Instructor: Rishab Nithyanand Teaching Assistant: Md. Kowsar Hossain
More informationThe Domain Name System
The Domain Name System Stefano Vissicchio UCL Computer Science COMP0023 Today 1. The Domain Name System (DNS) 2. A Brief Word on DNS Security A name indicates what we seek. An address indicates where it
More informationMan-In-The-Browser Attacks. Daniel Tomescu
Man-In-The-Browser Attacks Daniel Tomescu 1 About me Work and education: Pentester @ KPMG Romania Moderator @ Romanian Security Team MSc. Eng. @ University Politehnica of Bucharest OSCP, CREST CRT Interests:
More informationICANN and Technical Work: Really? Yes! Steve Crocker DNS Symposium, Madrid, 13 May 2017
ICANN and Technical Work: Really? Yes! Steve Crocker DNS Symposium, Madrid, 13 May 2017 Welcome, everyone. I appreciate the invitation to say a few words here. This is an important meeting and I think
More informationDNSSEC DNS SECURITY EXTENSIONS INTRODUCTION TO DNSSEC FOR SECURING DNS QUERIES AND INFORMATION
DNSSEC DNS SECURITY EXTENSIONS INTRODUCTION TO DNSSEC FOR SECURING DNS QUERIES AND INFORMATION Peter R. Egli 1/10 Contents 1. Security Problems of DNS 2. Solutions for securing DNS 3. Security with DNSSEC
More informationWhat is the relationship between a domain name (e.g., youtube.com) and an IP address?
DNS, CDNs March 30, 2009 Lecture 14 Sam Madden DNS What is the relationship between a domain name (e.g., youtube.com) and an IP address? DNS is the system that determines this mapping. Basic idea: You
More informationDNS Mark Kosters Carlos Martínez {ARIN, LACNIC} CTO
DNS Workshop @CaribNOG12 Mark Kosters Carlos Martínez {ARIN, LACNIC} CTO DNS Refresher and Intro to DNS Security Extension (DNSSEC) Outline Introduction DNSSEC mechanisms to establish authenticity and
More informationCS4/MSc Computer Networking. Lecture 3: The Application Layer
CS4/MSc Computer Networking Lecture 3: The Application Layer Computer Networking, Copyright University of Edinburgh 2005 Network Applications Examine a popular network application: Web Client-server architecture
More informationRemote DNS Cache Poisoning Attack Lab
SEED Labs Remote DNS Cache Poisoning Attack Lab 1 Remote DNS Cache Poisoning Attack Lab Copyright 2006-2016 Wenliang Du, Syracuse University. The development of this document was partially funded by the
More information(DNS, and DNSSEC and DDOS) Geoff Huston APNIC
D* (DNS, and DNSSEC and DDOS) Geoff Huston APNIC How to be bad 2 How to be bad Host and application-based exploits abound And are not going away anytime soon! And there are attacks on the Internet infrastructure
More informationOFF-PATH ATTACKS AGAINST PUBLIC KEY INFRASTRUCTURES. Markus Brandt, Tianxiang Dai, Elias Heftrig, Amit Klein, Haya Shulman, Michael Waidner
OFF-PATH ATTACKS AGAINST PUBLIC KEY INFRASTRUCTURES Markus Brandt, Tianxiang Dai, Elias Heftrig, Amit Klein, Haya Shulman, Michael Waidner 1 AGENDA Objectives Attacking Impact Mitigation Summary 2 AGENDA
More informationSPOOFING. Information Security in Systems & Networks Public Development Program. Sanjay Goel University at Albany, SUNY Fall 2006
SPOOFING Information Security in Systems & Networks Public Development Program Sanjay Goel University at Albany, SUNY Fall 2006 1 Learning Objectives Students should be able to: Determine relevance of
More informationCSCE 463/612 Networks and Distributed Processing Spring 2018
CSCE 463/612 Networks and Distributed Processing Spring 2018 Application Layer III Dmitri Loguinov Texas A&M University February 8, 2018 Original slides copyright 1996-2004 J.F Kurose and K.W. Ross 1 Chapter
More informationOSI Session / presentation / application Layer. Dr. Luca Allodi - Network Security - University of Trento, DISI (AA 2015/2016)
OSI Session / presentation / application Layer Dr. Luca Allodi - Network Security - University of Trento, DISI (AA 2015/2016) 1 Higher level protocols On top of IP, TCP, UDP, etc. there are a plethora
More informationHow to Enable Internet for Guest Virtual Machine using Datacard Tata Photon.
How to Enable Internet for Guest Virtual Machine using Datacard Tata Photon. Table of Contents 1) Host, Guest and VBox version.... 2 2) Check your current Host and add 3 rd Adapter to Host windows... 3
More informationDomain Name System (DNS) Session-1: Fundamentals. Computers use IP addresses. Why do we need names? hosts.txt does not scale
Domain Name System (DNS) Computers use IP addresses. Why do we need names? Names are easier for people to remember Session-1: Fundamentals Computers may be moved between networks, in which case their IP
More informationComputer Forensics: Investigating Network Intrusions and Cyber Crime, 2nd Edition. Chapter 3 Investigating Web Attacks
Computer Forensics: Investigating Network Intrusions and Cyber Crime, 2nd Edition Chapter 3 Investigating Web Attacks Objectives After completing this chapter, you should be able to: Recognize the indications
More informationAttacks Against Websites. Tom Chothia Computer Security, Lecture 11
Attacks Against Websites Tom Chothia Computer Security, Lecture 11 A typical web set up TLS Server HTTP GET cookie Client HTML HTTP file HTML PHP process Display PHP SQL Typical Web Setup HTTP website:
More informationThe Anatomy of a Man in the Middle Attack
Before we dig into this tutorial, lets take an opportunity to cover a fundamental ARP based attack, the Man in the Middle. We re going to cover how this attack works and then we re going to launch this
More informationBank Infrastructure - Video - 1
Bank Infrastructure - 1 05/09/2017 Threats Threat Source Risk Status Date Created Account Footprinting Web Browser Targeted Malware Web Browser Man in the browser Web Browser Identity Spoofing - Impersonation
More informationOverview of SSL/TLS. Luke Anderson. 12 th May University Of Sydney.
Overview of SSL/TLS Luke Anderson luke@lukeanderson.com.au 12 th May 2017 University Of Sydney Overview 1. Introduction 1.1 Raw HTTP 1.2 Introducing SSL/TLS 2. Certificates 3. Attacks Introduction Raw
More informationCSEN 404 Introduction to Networks. Mervat AbuElkheir Mohamed Abdelrazik. ** Slides are attributed to J. F. Kurose
CSEN 404 Introduction to Networks Mervat AbuElkheir Mohamed Abdelrazik ** Slides are attributed to J. F. Kurose HTTP Method Types HTTP/1.0 GET POST HEAD asks server to leave requested object out of response
More informationMore Internet Support Protocols
More Internet Support Protocols Domain Name System (DNS) Ch 2.5 Problem statement: Average brain can easily remember 7 digits On average, IP addresses have 10.28 digits We need an easier way to remember
More informationNetwork Security (and related topics)
Network Security (and related topics) EE122 Fall 2012 Scott Shenker http://inst.eecs.berkeley.edu/~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson and other colleagues at Princeton
More informationNext Week. Network Security (and related topics) Project 3 Q/A. Agenda. My definition of network security. Network Security.
Next Week No sections Network Security (and related topics) EE122 Fall 2012 Scott Shenker http://inst.eecs.berkeley.edu/~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson and other
More informationWireshark Lab: DNS v7.0
Wireshark Lab: DNS v7.0 Supplement to Computer Networking: A Top-Down Approach, 7th ed., J.F. Kurose and K.W. Ross Tell me and I forget. Show me and I remember. Involve me and I understand. Chinese proverb
More informationICS 351: Today's plan. web scripting languages HTTPS: SSL and TLS certificates cookies DNS reminder
ICS 351: Today's plan web scripting languages HTTPS: SSL and TLS certificates cookies DNS reminder 1 web scripting languages web content described by HTML was originally static, corresponding to files
More informationRecent advances in IPv6 insecurities Marc van Hauser Heuse CCC Congress 2010, Berlin Marc Heuse
Recent advances in IPv6 insecurities Marc van Hauser Heuse CCC Congress 2010, Berlin 2010 Marc Heuse Hello, my name is Who has already heard my previous talk? played with IPv6? IPv6 at home?
More informationComputer Networks - Midterm
Computer Networks - Midterm October 28, 2016 Duration: 2h15m This is a closed-book exam Please write your answers on these sheets in a readable way, in English or in French You can use extra sheets if
More informationComputer Networks - Midterm
Computer Networks - Midterm October 30, 2015 Duration: 2h15m This is a closed-book exam Please write your answers on these sheets in a readable way, in English or in French You can use extra sheets if
More informationInternet Layers. Physical Layer. Application. Application. Transport. Transport. Network. Network. Network. Network. Link. Link. Link.
Internet Layers Application Application Transport Transport Network Network Network Network Link Link Link Link Ethernet Fiber Optics Physical Layer Wi-Fi ARP requests and responses IP: 192.168.1.1 MAC:
More informationHomework Problems. 1. Stallings Problem 2.4 from the Problems section, not the Review Questions. 2. Stallings Problem 2.7.
ECE 2305: Introduction to Communications and Networks D-term 2014 Homework+Lab 2: Due at start of class on 01-Apr. Please complete all five homework problems, and the twenty lab problems. Homework Problems
More informationDNS Mark Kosters Carlos Martínez ARIN - LACNIC
DNS Workshop @CaribNOG8 Mark Kosters Carlos Martínez ARIN - LACNIC DNS Refresher and Intro to DNS Security Extension (DNSSEC) Outline Introduction DNSSEC mechanisms to establish authenticity and integrity
More informationNetworking Overview. CS Computer Security Profs. Vern Paxson & David Wagner
Networking Overview CS 161 - Computer Security Profs. Vern Paxson & David Wagner TAs: John Bethencourt, Erika Chin, Matthew Finifter, Cynthia Sturton, Joel Weinberger http://inst.eecs.berkeley.edu/~cs161/
More informationIPv6 Traffic Hijack Test System and Defense Tools Using DNSSEC
IPv6 Traffic Hijack Test System and Defense Tools Using DNSSEC Lin Tao lintao850711@sina.com Liu Wu liuwu@cernet.edu.cn Duan Haixin dhx@cernet.edu.cn Sun Donghong sdh@cernet.edu.cn Abstract IPv6 is widely
More informationSo Many Ways to Slap a YoHo: Hacking Facebook & YoVille
Tom Stracener Strace, Contract Engineer MITRE EvilAdamSmith, Sr. Security Consultant Sean Barnum, Cybersecurity Principal MITRE So Many Ways to Slap a YoHo: Hacking Facebook & YoVille Misclaneous Disclaimers
More informationArchitecture. Steven M. Bellovin October 31,
Architecture Steven M. Bellovin October 31, 2016 1 Web Servers and Security The Web is the most visible part of the net Two web servers Apache (open source) and Microsoft s IIS dominate the market Apache
More informationDNS Cache Poisoning Chris Racki CMPT-585 Dr. Robila 8 Dec 2008
DNS Cache Poisoning Chris Racki CMPT-585 Dr. Robila 8 Dec 2008 Abstract Using the internet any computer can theoretically communicate with any other computer in the world so long as they are both connected
More informationSECURITY STORY WE NEVER SEE, TOUCH NOR HOLD YOUR DATA
SECURITY STORY WE NEVER SEE, TOUCH NOR HOLD YOUR DATA CTO Office www.digi.me another Engineering Briefing digi.me keeping your data secure at all times ALL YOUR DATA IN ONE PLACE TO SHARE WITH PEOPLE WHO
More information