This was updated version of my famous “Seven Deadliest Sins” talk, intended for a technical audience.

The slides with speakers notes are here:

• DNS Security: The Seven Deadliest Sins

OASK is a new security group in Ottawa. It’s supposed to be technical, informal and free. If you’re in town, check out the OASK web site for meeting dates and location.

Related posts:

• DNS security: The seven deadliest sins
• (Unencrypted) site security confirmed!
• DNS root zone getting DNSSEC

Over at InfoWorld, Roger Grimes has written The one essential truth of computer security, saying much the same thing:

…the risk from reckless end-users unwittingly executing Trojans and installing their own software is so high that all the other intrusion methods and their resulting mitigations are but a small percentage of the overall attacks in the wild.

Back in February, CIO Magazine also promoted the idea, citing a security vendor claim that “The vast majority of critical Microsoft vulnerabilities — 92% of them — could have been mitigated by stripping users of administrative rights”.

With a little research, you can also see for yourself. Take the Top Twenty Malware for June 2009 from Viruslist and look at the infection method of each… nearly all malware relies on the user’s local permissions to infect the machine:

Out of the top ten malware, only one exploits a vulnerability to infect the target machine. The rest require the user to have local admin rights.

From the attacker’s perspective this makes sense. Why bother with tricky exploits when the majority of Windows users already have local admin rights? When the malware executes, it inherits those rights and thus has all it needs to insert code, change the Windows registry, and modify the kernel.

As the Grimes article points out, removing admin rights also prevents users from installing their own software, codecs, and drivers. That’s directly in line with the policy of most organizations, though it does force the organization to get better at responding to user requests for new software and otherwise managing the desktops.

Since writing the article in 2006 I’ve audited or reviewed safeguards at nearly a hundred organizations… private sector, government, military, huge financial and accounting firms, and the majority still run their user desktops with local admin rights.

One large global firm went through the contortions of rolling out Windows Vista to all desktops. But they chose to keep all users as local admins, and also disabled the limited additional protection of Vista’s UAC. Sigh.

Removing local admin rights is extremely unpopular with users. But so is every other security safeguard. Users tolerate firewalls, anti-virus, full disk encryption, network access control, attachment filtering, web site blocklists. Though local admin rights for Windows users has been the norm since the days of DOS and Windows 3.1, is it is really impossible to remove this huge vulnerability without facing a user revolt?

Related posts:

• Free host intrusion prevention for Windows
• CWSandbox: automating malware analysis
• The most important Windows security tool

In honor (?) of that that, I gave a quick presentation last week to the Ottawa CitySec group on Domain Name System security. Since the Kaminsky issue has been pretty well covered, I focused on all the other DNS security issues that are often overlooked.

I only had 30 minutes to present, so this is a cut-down version intended for a technical audience who already understand what DNS is and how it works.

The slide deck (with notes) is now online:

• DNS Security: The seven deadliest sins (PDF)

Related posts:

• DNS security talk
• (Unencrypted) site security confirmed!

We’ve had DNS security checks as part of our vulnerability assessments for years, and I’ve yet to encounter a provider’s DNS that is properly protected against attack. DNS tends to be yet another security blind spot, though it did get attention for a while when Dan Kaminsky’s cache poisoning exploit exploit made headlines last summer.

On the client side you can bypass your ISPs DNS with OpenDNS. It’s well maintained and offers a few other benefits like phishing filters.

However, OpenDNS is not meant for servers. For web servers or entire intranets, install a local resolver to go directly to the authoritative servers for each domain.

Using BIND is the default choice for this… it comes with all versions of Linux, but it’s memory intensive and has a history of security issues. Another popular choice is DNSCache, but it’s unmaintained and has some annoying dependencies and requirements.

A better choice is Unbound, a newer DNS caching resolver specifically designed for performance and security.

Unbound is developed by a NLNet, a Netherlands applied research group and supported by big names Verisign and Nominet. Its purpose is to be validating, recursive, and caching DNS resolver with good support for DNSSEC.

To be clear: Unbound is not for providing authoritative DNS. If you need to host DNS records so Internet users can can find your web sites and mail servers use BIND or other authoritative DNS configured to act only as an authoritative server.

Several DNS forgery protections are built in such as filtering private IP addresses from external DNS replies.

Want to block access to certain sites or services? Unbound also has handy features administrative features like  redirecting specific DNS queries to your own IP addresses… whether an entire domain or just specific records.

All this in a package that can be compiled easily on nearly any Linux or Unix, uses as much or as little memory as you tell it to, and has an easy configuration syntax. In short, Unbound rocks.

Compiling from source

Packaged versions of Unbound are in the Ubuntu Linux Universe repository starting with Hardy. Redhat doesn’t offer it yet. Regardless, new releases with many improvements come often and it’s easy to compile, so you’re better off building it yourself:

Download the latest source, extract the tarball then do the usual “./configure; make”. It depends on the libevent library, but the source includes an alternative if that is not installed.

Do “make install” to copy the libraries, executables and man pages to the right places (/usr/local/). A well-commented config file is installed in /usr/local/etc/unbound that has sensible defaults, but you should read through it. The daemon also runs chrooted from that directory.

Installing

Add a user and group to the OS named “unbound” and lock it from interactive access with “passwd -l”.

Download the latest root DNS hints file from ftp://FTP.INTERNIC.NET/domain/named.cache and place it in /usr/local/etc/unbound. Make sure user “unbound” has read permissions on the named.cache file. Edit the unbound.conf file to change the setting “root-hints” to point to /usr/local/etc/unbound/named.cache.

To test the installation, start the daemon from the command line by typing “unbound”. If it works, you will see a process named “unbound” running. If not, errors are written to syslog: check /var/log/daemon.log, /var/log/messages or whereever your system’s syslog writes daemon messages.

Once running, try a few lookups using dig, e.g.:

dig @127.0.0.1 www.advosys.ca

Configure the server to use Unbound for DNS lookups by editing file /etc/resolv.conf to add the following to the top:

nameserver 127.0.0.1

Now the part everyone hates: writing the startup script. For Unbound to start automatically when the server boots, a suitable script must be placed in /etc/init.d (for most Unix and Linux systems) then symlinked to appropriately named files in the /etc/rc.x directories.

To save you some work, we’ve written the following simple startup scripts for Unbound:

• Redhat / CentOS 5.x
• Ubuntu / Debian

Place the appropriate script in directory /etc/init.d, rename it to “unbound” then use the install method appropriate to your version of Linux:

Redhat / CentOS:

chkconfig --add unbound
chkconfig unbound on

Ubuntu / Debian:

update-rc.d unbound defaults

There are several options in the unbound.conf configuration file worth customizing, e.g. to disable IPv6 if you’re not using that, add sanity checks to weed out spoofed DNS replies, etc.  However, Unbound works well right out of the box in most situations.

With a good caching resolver like Unbound, your servers can directly query authoritative DNS servers, bypassing your provider’s probably polluted DNS. At the cost of slightly more network traffic and more memory usage, you can be reasonably confident that DNS answers legitimate and not pointing to malicious IP addresses.

Related posts:

• Hardening DNS with the Cymru Secure BIND template
• DNS cache poisoning made easy

I revisted each project to see if anything had changed, and also surveyed a few more popular ones:This time there are twenty projects in the survey, including popular application software:

I couldn’t find any mention of GPG signatures on the OpenSUSE web site, but they exist if you manually edit the URL of a download site to get a directory listing (e.g. visit http://download.opensuse.org/distribution/11.1/iso/).

Why does signing matter? Much of the world’s business is conducted using these and other Open Source software projects, including e-commerce sites, banks, government and the military. A back door or other compromise would have a far reaching impact. And it has happened:

• In 2003 someone tried to sneak a backdoor into the Linux kernel source code. The change was only uploaded to a public CVS server and was caught immediately, partially because of how well managed the Linux development process is. A similar attack
• In August 2008 the main Fedora servers were compromised via an unprotected SSH key. Backdoors were inserted into some packages.

Even when central project servers are protected, most projects use multiple download mirrors around the world, mostly provided by universities and volunteers and with varying levels of security. Without signed files there’s no assurance files on the the mirror have not been altered.

This happened to then Debian project several times. Fortunately, they sign their files so cleanup the efforts were straightforward. Can the same be said of PHP, Perl or the three most popular content management systems? Imagine the money you could make sneaking a backdoor into any of those.

Of course, secret source projects are not necessarily any better. Anyone remember when Microsoft’s network was compromised? Intruders rummaged around their network for three months and managed to leak (though, we’re told, not alter) source code of Windows and Office.

Commercial vendors benefit from the assumption that their development and release processes are better. Yet we see from the post-mortems of every card data and privacy breach that having a bottom line often results in worse security, not better. I’ve audited several commercial organizations who had appalling development practices. Even when good controls exist, those inconvenient security thingies are often the first to go when a release deadline approaches or costs rise.

Signing files isn’t a panacea. The whole development process needs to address integrity of the code. But signing files is not hard. At the very least it mitigates the weakness of using miscellaneous mirror sites to distribute files. It also kills one argument used by secret source proponents to spread fear, uncertainty and doubt.

Related posts:

• Dear developers: sign your code!
• Nasty little bug in Gnu Privacy Guard (GPG)

So far the squatter hasn’t done anything malicious with the web site, but how much can you trust someone whose business model is extortion? The Bastille scripts are popular, especially among less experienced sysadmins. Just the right audience to foist a “new and improved” hardening script onto… containing rootkits and botnet clients.

That scenario would be made a little less easy if the Bastille project cryptographically signed their files. Unfortunately, none of the files produced by the project are signed by Gnu Privacy Guard (GPG) or Pretty Good Privacy (PGP). Without a strong way to verify that the files are unaltered, hosting malicious versions on the now hijacked web site would be trivial.

Nearly all of the larger open source projects now sign their code, with a few appalling omissions:

So when building a typical LAMP server it’s possible to verify the authenticity of all components except the PHP and Perl interpreters… unless you’re building on OpenSUSE in which case the entire OS is unverifiable.

The situation is better than a few years ago. In 2002 there were separate incidents where backdoors were inserted into Sendmail and into OpenSSH. Those incidents woke up many developers to the importance of signing their code.

Most of the major open source projects got the message but smaller projects like Bastille rarely sign their files. Seems a little silly when the typical open source source code is mirrored on hundreds of servers around the world, many of which are either rooted or run by less than trustworthy individuals. It’s like a chef meticulously preparing a fine meal then giving it to a random passerby to deliver to the customer.

Of course, cryptographic signing of files is not foolproof: the “web of trust” model for verifying keys used by GPG is hardly robust, and GPG is clunky to use (though various front-ends make it less of a chore).

So developers… please sign your code. Right now it’s the best open solution there is to prevent someone from doing evil things to your hard work, even if you forget to renew your domain registration.

Many tutorials exist on creating a GPG key and using it to sign files. The GNU Privacy Handbook itself is awful, but these are pretty good:

• http://wiki.openskills.org/OpenSkills/GPG+Signing+and+Encrypting

• http://www.masuran.org/node/9

• http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html

Related posts:

• The state of code signing in Open Source
• Nasty little bug in Gnu Privacy Guard (GPG)