One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 1092951 |
| Date de publication | 2019-04-11 13:00:00 (vue: 2019-04-12 15:00:24) |
| Titre | DNS cache poisoning part 2 |
| Texte |
My last blog on DNS cache poisoning only covered the superficial aspects of this long-standing issue. This installment aims to give a bit more technical detail, and expose some of the tactics used by the "bad-actors" looking to leverage a poisoned DNS cache against you and your network. In a worst-case scenario, the results of a poisoned DNS cache could lead to more than just a headache: civil liability, phishing, increased DNS overhead, and other kinds of nightmares are too easy to overlook with this type of 'attack'.
So, you may be wondering, "What exactly makes a DNS cache poisoning attack so dangerous, and what can we do to prevent it?" Well, as outlined in my first article, not answering DNS requests on the web is a great place to start. If you're only running an internal DNS infrastructure, your attack-surface is much lower. However, this comes with a caveat; "internal-only" DNS attacks are much harder to detect, and can often go weeks or months before even the keenest of sysops recognize them. This has to do with the fundamental structure of DNS. Let me explain.
Fundamental structure of DNS
In a typical DNS server (e.g. Windows DNS, or BIND) there is little mechanism (e.g. NONE) to provide any sanity checking. In its simplest form, a DNS query will look to its local database (the 'cache') first, upon finding no answer for the request it will then send a lookup request to its configured DNS server (the one you hopefully manage) and see if it can find an answer for the request.
If this lookup fails a 2nd time, there is a 'forwarder' configuration that kicks in, and the request goes to a list of pre-specified DNS hosts that your server will send the request to, looking for a resolution to the name. If this final 'forward' lookup fails, the final lookup happens out on the internet, on one of the 'Root' nameservers that share a distributed list of all the DNS hosts that make up the TCP/IPv4 internet. If this final lookup fails, the original requesting client is returned with a 'DNS Name not found' answer, and the name will not resolve. At any point during this journey, a "faked" response can be issued, and the initiator will accept it. No questions asked.
Problems with the model
This model is good when we can trust each one of the segments in the process. However, even during the early days of the web - there were some issues that became apparent with the way DNS works. For example, what if the root servers are unavailable? Unless your local DNS server has a record of ALL of the domains on the web, or one of your 'forwarders' does - the DNS name will not resolve. Even if it is a valid domain, DNS will simply not be able to lookup your host.
There was an "attack" on several of the root servers in the late 1990's. Several of the root servers were knocked offline, effectively taking down the internet for a large portion of the USA. It was during this outage that many network operators realized a large oversight of the DNS system, and a push was made to distribute control of these systems to a variety of trustworthy and capable internet entities. At the time of this attack, much of the internet name resolution duties fell to a single entity: Yahoo. A DDoS of Yahoo effectively killed the internet. Sure, we could still get to our desired hosts via IP, but e-mail, for example, was not as resilient. It was a great learning lesson for the web community at-large.
This was just a denial-of-service at the highest level of the infrastructure. What would happen if the localized database on every computer in your organization had different "answers" for DNS lookups? Instead of consistent |
| Envoyé | Oui |
| Condensat | 'dns 'root 'yahoo happen *had* 1990's 2nd 48hr able about accept access accessible across actor actors actual additionally address adjust admin adoption advantage adverse afforded against aims all allows already also although and begin answer answering answers any apparent appears appended are article asked aspects attack attacker attackers attacks authoritative authoritive back backwards bad basically beat became become been before begin better bind bind9 bit blog both but cache campaigns can capable case cause caveat; challenges changed checking civil client climate com com' com com answer com to combine comes common community compatiblity completely compromise computer conclusion configuration configured consistent control correct could count counting covered cryptography dangerous database days ddos denial depend depending desire desired detail detect different disable distribute distributed dns dnssec does domain domains down during duties each early easiest easy ecosystem educate effectively effects either eliminates encrypted enter entities entity: entries environment especially essential essentially even every exactly example explain expose extremely facing fails fairly fake faked fastest fell fettered final find finding first fix for mycompany form found' from fundamental get gets getting give goes good got great greatly guessing had handled happen happens happy harder has hash have havoc headache: help hex hexadecimal highest hopefully host hosts how however improvements inception increased incredibly individual individually information infrastructure initiate initiator installment instead intercepting internal internet ipv6 issue issued issues it's its job journey just keenest keep kept key keyboard kicks killed kinds knocked know known lan large largest last late layer lead learning least left less lesson for let level leverage leveraging liability like list little local localized locate long look looking lookup lookups love lower made mail main make makes manage managed managing many match mycompany may mechanism merits mitigate mix model modified months more much multiple name nameserver nameservers namesever nana ndr's network new next nightmares none not noted that off offline often once one only operators organization original originating other out outage outlined outright outside overall overhead overlook oversight overview part pass phishing place point poison poisoned poisoning portals portion possibility pre prepared prevent prior private probably problems process protection protocol provide provides providing public puede pull pulled push queries query questions quite range rather realized received recognize record recursive reduce remotely request requesting requests resides resilient resolution resolve resolver response results returned rndc root running an sanity say scary scenario scope second security see segments send server server' servers service several share she should simple simplest simply since single some something somewhat specified standing start stop store string strong structure struggled successfully suffix superficial sure surface susceptible sysops system systems tactics tad takes taking task tasks tcp/ipv4 tech technical than the mycompany them then theory these things think time timeouts too tool touted transit transport trust trustworthy ttl's txid type types typical unavailable undergone understanding undetected unless upon upset usa used useful users valid variety vector very way ways web weeks well what when where who whois will windows wondering work works worst would wreak yahoo you're your |
| Tags | Tool Guideline |
| Stories | Yahoo |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.