Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
Wake On Demand in Snow Leopard

Putting your Mac to sleep saves power, but it also disrupts using your Mac as a file server, among other purposes. Wake on Demand in Snow Leopard works in conjunction with an Apple base station to continue announcing Bonjour services that the sleeping computer offers.

While the requirements for this feature are complex, eligible users can toggle this feature in the Energy Saver preference pane. It's labeled Wake on Network Access for computers that can be roused either via Wi-Fi or Ethernet; Wake on Ethernet Network Access or Wake on AirPort Network Access for wired- or wireless-only machines, respectively. Uncheck the box to disable this feature.

Submitted by
Doug McLean

 
 

DNS Clients Have Small Vector of Risk after Patch

Send Article to a Friend

The SANS Institute installed and tested out Apple's fix for the underlying flaw in the domain name system (DNS) protocol, and found that a patched copy of Mac OS X 10.5 Leopard (the desktop version, not Leopard Server) still suffers from the risky technique that makes DNS vulnerable to exploitation.

This exploitation, so far, seems extremely unlikely, but we won't know how unlikely until security researcher Dan Kaminsky, the discoverer of this flaw, provides full disclosure on 06-Aug-08 in his Black Hat conference talk, "Black Ops 2008: Its (sic) the End of the Cache as We Know It."

As Rich Mogull and I noted in "Apple Fails to Patch Critical Exploited DNS Flaw" (2008-07-24), servers are at a high risk from this DNS vulnerability. The flaw allows an attacker to send tens of thousands of fake responses for a DNS query to a server, which then poisons the server's DNS entries if the attacker matches the right pattern with their forged information before the legitimate response arrives from the DNS server for the domain that's being queried.

However, computers used by individuals without DNS server software in operation are also vulnerable to this flaw in DNS; we just don't know yet quite how vulnerable. With servers rapidly being patched worldwide, it's likely that the low-hanging fruit has largely disappeared, and attacks would then turn to clients - if clients are readily exploitable, too. Clients use stub resolvers, which forward requests for DNS answers to a full-blown, or recursive, DNS server run by their company, ISP, network provider, or co-location facility.

These clients pass their requests along, and it seems unlikely that they could be attacked directly unless an attacker had a computer on the same local network segment as the exposed system. In that case, the attacker would have a panoply of other network information poison available, and could disrupt DNS in a more efficient manner.

The DNS flaw relies on predictability in how ports are assigned to outbound requests for domain name lookups in a DNS query. An attacker forces a DNS server to look up a domain using a DNS server the attacker controls, and from that obtains the current port number being used for requests. If the ports are sequential - each query increments by one the port number used for each subsequent request - then the attacker starts sending forged requests using ports numbered just above the one it sniffed.

This is part of the question about client vulnerability: it's very hard to force a client to look up an evil domain to prime the pump because clients don't answer DNS queries to begin with, and typically aren't running mail servers which can be gamed when an attacker sends incoming email with an evil domain in the return address.

By increasing entropy - choosing a random port for each request - a patched DNS server prevents attackers from producing enough packets quickly enough to win the race with the legitimate DNS server, such that they cannot - statistically speaking - poison the DNS cache. (This is a patch, not a fix, actually; DNS itself must be overhauled to remove the fundamental weakness.)

I checked out my updated Leopard desktop system, and, sure enough, I saw precisely what SANS reported: sequential UDP ports returned in response to outbound requests, regardless of what this entails.

If you'd like to duplicate the SANS experiment, follow these steps:

  1. Launch Applications > Utilities > Terminal.
  2. Type the following, entering your administrative password when prompted.
  3. sudo tcpdump | grep domain

  4. Open another Terminal window, and in it, type the following, press Return, and then press up arrow and Return a few more times to enter the command repeatedly:
  5. dig tidbits.com

  6. In the window with tcpdump running, you should see a series of lines that look like the following.
  7. 15:06:53.900835 IP 192.168.1.16.49229 > yourDNSserver.com.domain: 5228+ PTR? 16.1.168.192.in-addr.arpa. (43)
    15:06:53.947838 IP 192.168.1.16.49230 > yourDNSserver.com.domain: 48400+ PTR? 11.1.168.192.in-addr.arpa. (43)
    15:06:55.003628 IP 192.168.1.16.49231 > yourDNSserver.com.domain: 15730+ PTR? 7.34.232.205.in-addr.arpa. (43)

  8. Press Control-C (not Command-C) to stop tcpdump from running.
  9. (If you don't see any results in step 4, you need to specify the network adapter with the tcpdump command. You can try en1, en2, en3, and so forth as in the following command.)

    sudo tcpdump -i en1 | grep domain

In the example above, you'll notice 49229, 49230, and 49231 after "192.168.1.16". Those are the port numbers used for each request, and the fact that they're sequential shows that Leopard is still vulnerable as a DNS client.

We're not back where we started, because clients are enormously harder to attack. But it's still a hole that needs to be filled. We just won't know how deep a hole until next week.

 

New for iOS 8: TextExpander 3 with custom keyboard.
Set up short abbreviations which expand to larger bits of text,
such as “Tx” for “TextExpander”. With the new custom keyboard,
you can expand abbreviations in any app, including Safari and
Mail. <http://smle.us/tetouch3-tb>