Hi mates,
few months ago some friends asked me some additional info regarding specific attacks that were done to redirect user traffic to a desired/different web site.
The attack is called DNS Poisoning and it's done, simply speaking, polluting the DNS cache of specific servers.
More popular is the web site attacked, more amplified will be the impact.
In that way when a user will try to resolve the name of the website that he/she is asking for, the DNS will give him/she a different IP instead of the right one.(consider that the same approach could be used for mail system for example)
In this way the end user could be deceived and may type some sensitive/personal info in some forms that the attacker built specifically to let him/she believe that they are "talking" with the original site.
In this way the attacker will steal anything is possible to steal (pharming).......
Anyway this kind of attack could also be used for other purposes : MITM, spread out virus and worms, DoS or DDos and so on.
The BEST solution (so far) to this problem would be DNSSEC (using a PKI infrastructure).....but this is another topic and, in any case, is RARELY used.
Another partial solution could be accomplished randomizing the UDP source port that is used to reply to a query (search for Kaminsky attack). Obviously using firewall (NAT) and other useful devices in our border side of the network could reduce the effectiveness of the randomization. Some firewalls could reset the randomization of the UDP source ports : be sure to configure your FW correctly (even if some others say that it's aways possible to poison it).
Also switching the reply to the query from UDP to TCP could be great and will , for sure, make more difficult for the attacker, guess the request ID (RFC 5966).
Spoof an internal/legitimate IP address is one of the first steps used by the Kaminsky attack : for this reason the correct configuration of firewall and any other complementary device is for sure a good defence (for example the IPS could intercept an high rate of DNS packets and interfere in some way).
Last but not least is the monitoring and alerting system : promptly inform the sysadmin that some abnormal number of fake responses from a single source to a DNS query is another way to "react-preventively".
HOW IT WORKS : PRAGMATICALLY SPEAKING
The attacker sends a lot of request to a DNS server that doesn't have, inside its cache, the record "saved". The caching server asks/forward the request in order to reply to the initial requests. The attacker sends fake answers to the cache server creating fake or polluted DNS cache for a specific domain or record. The end users that will try to resolve the domain asking to the compromised DNS server will be redirected to another destination.......
When a server forward the query to, for example, the authoritative server for the searched domain, include, in the subject, a unique transaction ID composed by a 16 bit random number.
The interrogated server could reply in several ways : answer, referral or failed. The resolver store in the cache the reply. The reply can contain, additionally, some specific condition that are not mandatory to implement (i.e. bailiwick rule). Theoretically the problem is that a forged/malicious reply could overwrite an already/pre-existing cached record.
Considering in addition that the calculation of the TXID is "regulated" by the birthday paradox you will have an idea on how relatively easy to guess the right ID; the response must have the same ID as the query (here you have some additional explanation regarding this mathematics theory --> in ITALIAN
http://www.ilpost.it/2013/02/05/il-paradosso-del-compleanno/2/
and in ENGLISH
https://betterexplained.com/articles/understanding-the-birthday-paradox/
So if a forger response arrive before the right one, sent by the authoritative server, the resolver will cache it until the new TTL expires.
The above mentioned exploit (Kaminsky) is more complex and efficient compared to the older ones :
1. the attacker force the resolver to start querying the authoritative DNS server choosing it preventively
2. the number of responses could be very high thanks to the today power of computers and network bandwidth
3. for more or less the same reasons declared on the previous point, the "bad-guy" sends hundreds of forged replies trying to guess the right one
Add new mappings or overwrite existing ones is regulated, for some DNS servers software (i.e. Bind) by the trust level of the Resource Record Set received. This level depends on the provenance of the response : authoritative server or referral.
In Windows environment there's a security update that introduce source port randomization but there's another setting that could be done regarding the cache locking value : with an higher value correspond a lower possibility that the cache is "polluted".
Additionally ensuring only secure dynamic update (in Active Directory) will add another secure layer.
Anyway there several consideration to do :
- first of all most of public DNS are running under *NIX OS. There are a lot of video that show how to poison Bind (specific versions) with Metasploit.
Here you have two video that explain how to do it (for Bind)
--> https://www.youtube.com/watch?v=UtEPfAgp2Xg
--> https://www.youtube.com/watch?v=B4NwtrWOxiU
- there other ways to do it : also using Ettercap
--> https://www.youtube.com/watch?v=Aw5CQK6F_O4
- under Windows there is a video (one of several that I liked) that shows a vulnerability --> https://www.youtube.com/watch?v=m2GkLL9d68E
This video refers that another blog --> http://blog.watchfire.com/wfblog/2011/10/dns-poisoning-via-port-exhaustion.html
Please refer to the following articles for Windows DNS :
https://technet.microsoft.com/it-it/library/jj649852.aspx
https://technet.microsoft.com/it-it/library/ee649148(v=ws.10).aspx
https://support.microsoft.com/en-us/kb/951746
https://technet.microsoft.com/en-us/library/ee683907(v=WS.10).aspx
Some useful/generic references :
https://technet.microsoft.com/en-us/library/cc961401.aspx
https://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
http://meetings.ripe.net/ripe-50/presentations/ripe50-dns-in-bailiwick.pdf
https://www.dnssec-tools.org/wiki/index.php?title=RRset
Something about Kaminsky attack :
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
A nice video that explain, easily, DNS poisoning :
https://www.youtube.com/watch?v=1d1tUefYn4U
No comments:
Post a Comment