15_dns (1)

18
DNS HIJACKING Supervisor: Chao-Li Tarng Team: Surya Abhijith Kumar Devaraju (009179300) Bharadwaj Ananthula (009290489) Sarath Kumar Gupta Sunku (009326213) Anirudh Sri Jayendra Janga (008681907)

Upload: sarath-gupta

Post on 24-Nov-2015

14 views

Category:

Documents


1 download

TRANSCRIPT

PowerPoint Presentation

DNS HIJACKING

Supervisor: Chao-Li Tarng

Team:Surya Abhijith Kumar Devaraju (009179300) Bharadwaj Ananthula (009290489) Sarath Kumar Gupta Sunku (009326213) Anirudh Sri Jayendra Janga (008681907) 18/22/2012DefenseChristo WilsonUnderstanding DNSHow DNS Work ?VulnerabilitiesAttacks and Defense SchemesDNSSEC (DNS Security)Attack DemonstrationDNSSEC ImplementationOutline2Domain Name System3Developed in 1983 Application Layer ProtocolScalable way to map hostnames to IP addressesUses a hierarchal tree structure beginning at the root Below the root are generic top level domains (edu., com., net., etc) and country code top level domains (uk., cn., etc) Each TLD further subdivides to produce domains such as colostate.edu. and deterlab.netEvery Internet application requires some DNS lookupDNS Queries4Two Types

1. Recursive QueryPuts the burden of resolution on the contacted name server

2. Iterative QueryContact server replies with the name of the next authority in the hierarchyI dont know this name, but this other server might

This is how DNS works today

The Importance of DNS5Without DNSHow could you get to any websites?

DNS is the root of trust for the webWhen a user types www.bankofamerica.com, they expect to be taken to their banks websiteWhat if the DNS record is compromised?DNS Hijacking6Infecting OS or browser with a virus/trojanE.g. Many Trojans change entries in /etc/hosts*.bankofamerica.com evilbank.comMan-in-the-middle Attack

Response SpoofingEavesdrop on requestsOutrace the servers responseDNS Vulnerabilities7DNS wasn't designed with any security concerns in mind. Classical DNS uses plaintext messages - third party can easily readIt also does very little by way of message verificationEnd-user has no way of knowing if the message was altered en-route or if DNS servers supplying the information are acting maliciously. This leaves the service open to several well-known vectors of attack

MITM Man In The Middle AttackBirthday AttackKaminsky Attack

Man In The Middle Attack8MITM is common to network services Effective on communications that don't use cryptographic encryption or authentication. Attacker positions between the client and the server on a networkCan intercept messages going in either direction Can alter or deny them at will, violating either the integrity or the availability of the service. In the context of DNS, the attacker to position somewhere between the end-user and the relevant DNS serverAlter the DNS response to supply a different IP address for the requested internet address, effectively rerouting the user anywhere they want. MITM Attack Defense9DNSSECFor preventing the DNS poisoning attackUse CertificatesAgainst public key encryption MitMTrusted Certificate Authority (CA) to verify certificate, digital signature or keyDHCP snooping Used against DHCP spoofing Helps in differentiating trusted and non-trusted portsAgainst ARP poisoningDHCP snooping creates MAC to IP table Monitors ARP packets and checks them against the table

Birthday Attack10A type ofcryptographicattack Exploits themathematicsbehind thebirthday problemAn attacker will send a query to the caching server quickly followed by a response to that same queryIf the response appears valid to the caching sever, it will accept it and add the "poison" data into cache ignores subsequent response for same query

Birthday Attack Defense11Problem:DNS servers cannot restrict the number of simultaneous requests for same IP. This paves way for birthday attackSolutionRestrict the multiple DNS requests for the same resource Implement birthday attack protection mechanism in firewallRespond to first DNS Query and ignore others

Store the first request and set the flag to 1 and subsequent requests reset flag, respond to the first request and discard the rest.Kaminsky Attack12Transaction IDs prevent from assigning their own IP to any domainBut they are ineffective as security measures An attacker could flood a DNS server with multiple, slightly varied requests for a domain, such as "1.foo.com" or "2.foo.com." Transaction IDs can only be a number between 0 and 65535Attacker can launch multiple requestsEventually the attacker could spoof a domain by matching the ID through chance.

Once this domain is spoofed, the attacker can flood a name server with spoofed replies to poison its cache for the domain being attacked, "foo.com." Requests for foo.com would direct a user to a site of the attacker's choosing.Kaminsky Attack Defense13Randomize the UDP used to send the DNS queryThe attacker has to guess that port correctly as well Increase the space of possible IDs

Real" fix is to notice lot of requests and only communicate using TCP, which can't be spoofed A further fix would be to have carriers communicate using DNSSEC, a form of DNS which is encryptedDNSSEC14DNSSEC is an enhancement to the DNS protocolIntegrates cryptographic authentication into DNS messages. DNSSEC assures data integrity, mitigating man in the middle and cache-poisoning attacks using a "chain of trust." DNSSEC works bydigitally signingrecords for DNS lookup usingpublic-key cryptography. The correct DNSKEY record is authenticated via achain of trust, starting with a set of verified public keys for the DNS root zonewhich is thetrusted third partyRequires DNSSEC to be enabled on authoritative and cache machines15

LETS ATTACK !!!Attack Demonstration16Login to attacker machineEnable ettercap to redirect traffic to attackers machineNow verify that traffic passes through attackerNow edit etter.dns file to spoof the DNS response for google.comVerify that the client now gets a spoofed response

Attack Successful !!!

Enabling DNSSEC17Login to Authoritative MachineUsing zonesigner create signed copies of google.comNow open named.conf.options and make necessary changesIn named.conf.local file make a change for signed copy of google.comNow restart bind9 service to make the changes savedVerify DNNSEC is workingCopy the public key for signed google.comRepeat same steps in cache machineLogin to client machine and use dig with DNSSECObtain authoritative answers and this verifies DNSSEC is working

Conclusion18DNS is important protocolCurrent Internet system fails without DNSIts vulnerable and can be easily attackedImplementation of DNSSEC can be helpful to mitigate the vulnerability