Re: [vox-tech] inject false information into dns
I'm going try to keep the signal to noise high. So I'm going to avoid the point/counter point, especially since I agree with Rick. I'm quite fond of ssh key pairs. They offer numerous advantages: * very impractical to brute force * reduce the exposure of whatever passwords you do use * if a server is compromised you do not need to change your user key pairs. * Reduces any pressure to have a short/simple password since you use don't use them for logins. * Can restrict a key to running a specific command, very handy to allow a user to run one and only one thing. However as Rick pointed out they aren't magic and can be compromised if the client is compromised. You are pretty much doomed with any system if the client is compromised. The most important thing to start with is physical security. If you eliminate your connection to the internet (often called an air gap) and have physical security you have the best security there is. So even a piece of paper in your wallet, or say a palm pilot can be a very secure place to store passwords. Personally I keep my password database encrypted on my phone and do not use any network sync functionality with my encrypted database. So a compromise on my phone would sniff my password next time I decrypt the database. I take steps to minimize the risk, but it's certainly higher than an offline database. I do however avoid shoulder surfing risk since I can cut/paste without revealing the password to even a very sharp eyed attacker. I actually had one of my users compromised because of the sourceforge compromise. Sourceforge at the time used passwords for ssh access. They got compromised and started collecting passwords. Then started logging into machines where users logged in from and compromise those accounts. This is exactly what is prevented with key pairs. As a result they switched from passwords to key pairs. Exactly the same thing happened at kernel.org... with exactly the same result. ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] inject false information into dns
Quoting Bill Broadley (b...@broadley.org): What you said. > * Authoritative only servers don't cache Well, yeah, authoritative-ONLY servers would have no use for caching by definition, as they aren't accepting data from elsewhere. DNSSEC is definitely quite worthwhile. I just am mostly wary of people treating it as if it were magic crypto sauce and the solution to Internet site authentication and key managment -- when attention to a few fundamentals elsewhere gets you a lot further. > * DNS based Amplification attacks are a major issue these days A lot of this results directly from the widespread reliance on open recursive servers. So, Don't Do That, Then -- thus my polite disagreement with Tony on that key point. The more I've pondered this problem space, the more attractive 'split split' DNS (where authoritative and recursive service are completely decoupled) seems. http://www.ida.liu.se/~TDDC03/literature/dnscache.pdf https://www.sans.org/reading-room/whitepapers/dns/current-issues-dns-32988 If nothing else, having a highly protected recursive-only server that's as local as possible is a really good idea. I like having a localhost-only recursive server, actually, e.g., on laptops -- the last word in 'can't flood _this_ with spoofed responses'. > SSH prevents this by using public keys to exchange > a secret key, which is used for that session. However, the keypair (and passphrase) can be stolen on the usage end if that host has been compromised, and this is how public-key SSH credentials get stolen and abused all the time. Example: http://linuxmafia.com/faq/Security/breakin-without-remote-vulnerability.html The firm where this happened, which I didn't care to identify at the time, was VA Linux Systems, which was h4x0red by a kiddie in South Lake Tahoe who'd compromised a university shared computer, used that host to collect outgoing public-key SSH credentials a developer used to ssh into shell.sourceforge.net, escalated to root on that shared host and installed trojaned /usr/bin/ssh there, then last collected the public-key credentials of a VA Linux Systems IT Dept. employee (not me!) who made the error of then sshing or scping inbound into corporate servers from the shared Sourceforge host. > * DNSSEC can protect against local ISP Just to clarify: If you use the 'forwarders' keyword in BIND9 to offload traffic to the ISP recursive server, the DNSSEC capabilities of your local nameserver are going to be undermined. Even BIND10 is not yet aimining to fully validate forwarding: http://www.isc.org/blogs/dns-forwarders/ So, Tony, that's yet another reason not to keep using your forwarding scheme. > Additionally even if the government did do that, you could immediately > notice the change in signing key and if you knew me you could enquire > why such a change happened. This is key point, and bringing the 'temper-evident' quality back into HTTPS is one of my _other_ current measures, as see below: > Similar applies to SSL certificates. If you are worried about secure > communications with someone you can store their public key. While a > government can publish a new public key, they can't magically produce > the missing private key. > > So even the NSA has to be careful, faking a public key on any kinda of > wide scale is lightly to draw significant attention. Word. And one step towards making SSL tamper-evident (on the Web) is to change Web browsers' happy-go-lucky default of saying absolutely nothing about changes in SSL certs or their CA attestations as long as they continue to be attested by some CA or other that's in the browser's keyring. Those keyrings have proven to be a joke. Even the Turkish government has been able to use a captive CA to promulgate forgeries. One tool for alerting browser users to cert or attestation changes is Firefox extension CertWatch (Certificate Watch). It's not very clever; it just tells you when an SSL cert or its attestation has changed since last encounter, leaving entirely up to you how to interpret that change and what to do about it. That is not a comprehensive solution, but I find knowing about the fact of a change a great deal better than not knowing. For my own self-signed Web site SSL cert, I carry around its hash value in my PDA for comparison, same as with my SSH host and personal keys. > Sadly certificate authorities are anything but trustworthy. So I prefer > the ssh model. There are some projects to build an alternative to the laughably broken CA attestation scheme. http://web.monkeysphere.info/ http://convergence.io/ > * Pick good passwords, never use them for more than one site/service, >preferably generated by a machine. I susggest an open source password >database like keepass (It works on windows, linux, android, and IOS). I consider an online password safe program suboptimal because it is exposed to attack and compromise if your machine is -- albeit it's hugely better than no password safe at all.
Re: [vox-tech] inject false information into dns
I've gave a talk a few DNSSEC and DKIM talks and run a few DNSSEC protected domains. I was involved in getting UCD to finally go DNSSEC which happened recently. I was (AFAIK) the first DNSSEC enabled domain on campus. Ah, rats, for years I was the top hit on google for DNSSEC and DKIM, but campus was hosting my slides and apparently killed the site 8-(. Some points I wanted to make: * Name servers have two main categories of functionality, Authoritative and Recursive. * Authoritative only servers don't cache * Buffer overflows/bugs in implementation certainly exist, but aren't a major point of concern these days. Bind is large, and complex. But sufficiently audited that the serious issues are getting fairly rare. * DNS based Amplification attacks are a major issue these days * DNS was by design a VERY insecure protocol, even assuming a perfect implementation. * DHCP suggestions for a name server can get used or ignored. Traditional MitM (Man-In-The-Middle) involved, er, a man in the middle. So with a telnet connection someone who was between the source and the destination could listen in, record the username and password, then login from anywhere. SSH prevents this by using public keys to exchange a secret key, which is used for that session. So not only can someone not sniff a ssh connection, but they can't replay a session. DNS has a much more serious issue. The default uses UDP, and UDP packets don't have a source address. So you can't tell where the packet came from. So if you ask a DNS server for google.com anyone on the planet could send you (or the DNS server) a UDP packet that says google.com is some ip address in Russia. So it's really Man-On-The-Planet, they do have to hit a rather narrow time window though. Cache poisoning builds on this. Normally you'd have a very short window between a request and a valid response to lie to the DNS server with a forged UDP packet. But say you can trigger a remote name server, say one for a large ISP to look up foobarbaz.google.com. Then you know that A) it's not going to be cached, B) the DNS server is going to ask RSN, and C) since you know ahead of time you can send a valid looking answer in the very next packet. The trick is you'd send two answers, one for foobarbaz.google.com and one for google.com. At the time (2008ish) most name servers would accept both, and suddenly an arbitrarily large number of users would get the forged results. That however was fixed quite a long time ago, so winning the race conditions are hard. Additional protections have made this even harder, but not impossible. The real fix is DNSSEC. Neither of the above lets a remote attacker change the address a name server forwards to. Not sure of any practical attack that would. Sure a serious buffer overflow could, but at that point you'd likely just take control of the server instead of just redirecting dns queries. DNSSEC used public key encryption to validate DNS requests. A few points: * DNSSEC does prevent cache poisoning * DNSSEC does prevent MITM attacks * DNSSEC does not require a secure network * Room 641A is pretty much irrelevant * DNSSEC can protect against local ISP * DNSSEC can not protect you from those who sign the root. Thus US Gov can get verisign and related to delete/change zones. * However tinkering with the zones is easy to detect. So basically a DNSSEC aware resolver typically stores the key for ".", called the anchor, then does query .com, then foo.com, and so on. At each stages the key above signs the record on the next level. So say for broadley.org (which is signed). The root key is held by verisign I believe, which signs ".". The public interest registry signs the .org domain, and my registrar allows me to upgrade the records for broadley.org. So sure the USA government could pressure a registrar to delete or change my domain. But that has little to do with spying hardware installed in various large network hubs. Additionally even if the government did do that, you could immediately notice the change in signing key and if you knew me you could enquire why such a change happened. So for instance: $ dig +short +dnssec broadley.org ds 16276 5 2 7BCB5E40E630C8F77F168FFA1380BBBF25356A0B474FDDFA6F89FF1D 0AD4301B 16276 5 1 3397132E041EC17D59206FC318047D4D5128EB65 One is a KSK = Key Signing Key, and the other is a Zone Signing Key (ZSK). Similar applies to SSL certificates. If you are worried about secure communications with someone you can store their public key. While a government can publish a new public key, they can't magically produce the missing private key. So even the NSA has to be careful, faking a public key on any kinda of wide scale is lightly to draw significant attention. The more they use it, the less effective it will be. Various national governments have tried this to intercept communications with various email/messaging sites. It worked for
Re: [vox-tech] inject false information into dns
Quoting Tony Cratz (cr...@hematite.com): > > This prevents hackers from injecting false information (aka DNS cache > > 'poisoning'), in an attempt to re-direct people trying to access a real > > website to a fake, phishing or criminal site. > > I will attempt to answer you question by giving a very high > level overview. > > I do ask others (Rick, Alex and any other person who knows DNS) > to keep me correct if (when) I say something wrong, if if they > feel I left something out which needs to be covered. Thanks for your thoughtful run-through. It makes me feel like a bad penny breezing in and doing drive-by comments: Apologies for not having the time to write a more-careful and considered rejoinder. > Paul Vixie (and others) decided we needed a better method > and developed Bind which used the Domain Name System instead > of bang-paths. FWIW (and not any kind of criticism, just historical trivia), there was an overlapping step where first ARPANET and then the InterNIC at SRI International maintained a central HOSTS.TXT file (per RFC 953) that could be fetched from a standard location via ftp. > Of late, Ubuntu has gone one more step, they have set-up what is > called a 'caching name server' when you use DHCP. Have they? Good. OTOH, it's always been trivial to set up a local nameserver for better performance, reliability, and security. The term 'caching name server' is one I would avoid using in favour of clearer alternatives that are more specific and meaningful. (Again, I mean no criticism of your fine explanation, but wish to bring additional clarity to the subject.) 1. _All_ DNS servers of various and sundry sorts do caching -- so saying that a nameserver is a 'caching name server' really doesn't tell you much. 2. Far more meaningful is whether the nameserver does authoritative service or not. (By 'authoritative' service, I mean serves up information of its own, as opposed to querying, caching, and providing DNS data sourced from elsewhere.) The other type of DNS service -- serving up and caching data queried from elsewhere -- is somewhat loosely called recursive service. Complicating the nomenclature somewhat is the fact that a DNS server's query to another DNS server can either have the 'recursion desired' (RD) bit or not. The query thus characterised (RD bit set vs RD bit unset) is called either a recursive query or an iterative query. Those queries are treated differently by the receiving nameserver. Last, there is the issue of forwarding, to which you alluded. A few DNS server packages (dproxy, Dnsmasq) have essentially no local DNS-resolution intelligence of their own and are capable _only_ of forwarding to a more-capable nameserver any queries local processes + hosts submit to them. (As you said, BIND9 can be configured to forward elsewhere queries whose answers it doesn't have in cache. It differs from dproxy and Dnsmasq in having a considerable amount of local DNS-resolving intelligence that can be used if you wish to do so.) As these nuances are a bit complex and a bit counter-intuitive, I long ago wrote a (metaphorical) 'networking fairy tale' about the mythical Village of Lan to illustrate them: http://linuxmafia.com/~rick/lan.html Also, I have classified and summarised all DNS software for Linux according to what sort of service it does: http://linuxmafia.com/faq/Network_Other/dns-servers.html > If you run your own name service (BIND-9), depending on how you > set it up you can still use your ISP as a 'forwarder'. This > means, instead of doing a recursive search up to the TLD and > then down to the DNS server for the domain we just ask the ISP > if they have the domain in their cache (and most of the major > sites will be already in the cache). By using 'forwarders' you > can save a lot of time by not having to do the full search. I beg your indulgence for my polite difference of opinion. (I have the discussion often.) As background: Specifying forwarders tells BIND9 to not use its independent ability to resolve DNS questions whose answers aren't already in the local cache (aside for records for which it's authoritative), but rather to offload all uncached queries to one or more remote nameserver (with the RD bit set) and have those do the work. The belief that this 'saves a lot of time' rests on the undeniable fact that ISP nameservers tend to run with a bountiful cache set. Thus, initially the ISP nameserver has an advantage on account of the loaded cache. However, over a quite short period of time, your local cache fills quite beautifully with or without a forwarders line, so any initial advantage evaporates almost entirely within minutes. But then the longer-term consideration becomes of interest: ISP nameservers (even those of good and praiseworthy ISPs) are a very serious security and performance / reliability weak spot. The security pr
Re: [vox-tech] inject false information into dns
On 09/16/2013 04:08 PM, Tony Cratz wrote: > I will attempt to answer you question by giving a very high > level overview. I see I made a number of small mistakes which could have been corrected if I would have read over my message before I hit send. The base information is still correct. Please read it as if there is no miss spellings, or use of an incorrect word, or even a missing word or two. Tony ___ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
Re: [vox-tech] inject false information into dns
On 09/16/2013 01:13 PM, Brian Lavender wrote: > How is it that attackers inject false information into DNS? > > https://wiki.sonic.net/wiki/DNSSEC > This prevents hackers from injecting false information (aka DNS cache > 'poisoning'), in an attempt to re-direct people trying to access a real > website to a fake, phishing or criminal site. I will attempt to answer you question by giving a very high level overview. I do ask others (Rick, Alex and any other person who knows DNS) to keep me correct if (when) I say something wrong, if if they feel I left something out which needs to be covered. Quick History Before what we now know of as the 'Internet' we had a network of machines which were mostly connected via modems and would use UUCP to pass files and E-mail. This networked used was was known as the 'bang path' method figure out how to get to a machine. For example an old address I use to use was along this line: intelca!decvax!inhp4!!username which means send the E-mail to intelca, then to decvax, then to inhp4 (in HP Indian Hills New Jersey), and then to a machine which was connected to it and then to the user mbox. Latter we added a couple of other symbols ie '@' to help with the processing. Then to make life easier, Peter Honeyman developed a program which would take what was called the UUCP maps and build a file by the name of 'path-file'. This text base file would contains the hostname and a bang-path line for how to reach the site. Paul Vixie (and others) decided we needed a better method and developed Bind which used the Domain Name System instead of bang-paths. What this now does is provide a key-value database which contains the domain name such as 'mydomain.tld' (tld means top level domain, such as .com, .org, .net and so on). The value part of the database contains one or more IP addresses. Really it is much more complicated then this but this is a very nice and simple way to thing of it. There is a lot more which can be covered in the history area but I have a quick dirty overview. Today with DNS Let me cover what happens with Ubuntu as this is what most of us are currently using. And the ideas are very close to all systems. Depending on how you are connected to the Internet, somewhat controls type type of name services you run. For most of us we are on a dynamic IP and uses DHCP when we connect. Even if we are using a M$ system, a Mac or whatever we still follow the same base set-up. When we connect using DHCP we receive the IP address of the name servers we are to use. This information goes into the file /etc/resolv.conf. Of late, Ubuntu has gone one more step, they have set-up what is called a 'caching name server' when you use DHCP. This means we keep a cache of domains and their IP address which we use to look-up instead of having to ask our ISP for this information (thus adding a slight handshake delay). In Brian's and my case our ISP DNS 'forwards' is the Sonic DNS servers. If you run your own name service (BIND-9), depending on how you set it up you can still use your ISP as a 'forwarder'. This means, instead of doing a recursive search up to the TLD and then down to the DNS server for the domain we just ask the ISP if they have the domain in their cache (and most of the major sites will be already in the cache). By using 'forwarders' you can save a lot of time by not having to do the full search. The default method of setting up a DNS server (BIND-9) is to not use forward and do your own searches. Cache Poisoning - man-in-the-middle BIND-9 like all programs has bugs in it. Because of how serious the bugs can be, BIND normally has a very quick turn around time to fix problem. But that does means all of the bugs have been found. For this lets assume that I have found a bug in an older version of Bind which Brian has not updated to yet. Buy using this bug I can change Brian's DNS cache to point to me as a 'forwarder' (or ever as a TLD DNS server). This means I know become a Man-In-The-Middle, and I can now force Brain to use my fake-Google search engine, or even point his browser to nude-babes.ru instead of Google.com. And depending on where he is at, at the time (think being at work and having this happen), he could be put into a very bad spot. Reason for DNSSEC To try to prevent the man-in-the-middle issue, we now want to insure that the machine we a
