Odd log messages from ISC BIND named

[VirginSnow at vfemail.net]

> Date: Tue, 3 Feb 2009 18:58:51 -0500
> From: Ben Scott <dragonhawk at gmail.com>

> On Tue, Feb 3, 2009 at 6:29 PM,  <VirginSnow at vfemail.net> wrote:
> >> Okay, I might buy that, but what's it doing on our DNS server?
> >
> > If the payload space being searched included the destination IP field,
> > the destination IP could just coincidentally have been that of
> > liberty.
> 
>   Maybe I'm misunderstanding something.  As I understand it, a
> known-plaintext attack means you've got some plaintext, and you've
> also got the corresponding ciphertext, but you don't know the key.
> You're interested in the key because you've got other ciphertext
> *without* the corresponding plaintext.  Right?

Close.  Known plaintext is when you know the plaintext P1 for a
corresponding ciphertext C1 and want to know the plaintext P2 for
another ciphertext C2.  There are many ways of achieving that, but the
most *general* is finding the key because with the key, you can find
Pn for *any* Cn.  Technically, any attack which uses P1, C1, and C2 to
reveal P2 would be known a plaintext attack.

>   I'm having trouble envisioning a scenario where the above attack
> would find it useful to send a flood of DNS packets for bogus names to
> an arbitrary IP address.  We're trying to crack an encrypted network.

A DNS IP packet has the structure:

    /* IP header */
    u_int8_t ihl_and_version;
    u_int8_t tos;
    u_int16_t tot_len;
    u_int16_t id;
    u_int16_t frag_off;
    u_int8_t ttl;
    u_int8_t protocol;
    u_int16_t check;
    u_int32_t saddr;
    u_int32_t daddr;

    /* UDP header */
    u_int16_t uh_sport;
    u_int16_t uh_dport;
    u_int16_t uh_ulen;
    u_int16_t uh_sum;

    /* DNS header */
    u_int16_t       id;
    u_int16_t       options;
    u_int16_t       qdcount;
    u_int16_t       ancount;
    u_int16_t       nscount;
    u_int16_t       arcount;

    /* Question section */
    u_int8_t        len;
    char[32]        name;

In your case, len = 32 and name = all those strange domain names.
Note that daddr occurs on a 32-bit boundary and that the domain name
comes last.  Since most modern block ciphers use 128 or 256 bit
blocks, twiddling bits in daddr and/or name could reveal important
information about the cryptosystem.

> Presumably, the attacker doesn't have full access to the encrypted
> network, or he wouldn't need to do this.

In practice, if an attacker was able to change the daddr of DNS
packets, he would also likely be able view/change the WEP key.  But
suppose he had a laptop say, on his employer's LAN and his employer's
LAN was connected to the company's WAN via VPN (which all too many
tech staff think solves everything), he wouldn't have access to the
key but would be able to generate any packets desired.

This is less likely to be the case with WiFi, because WEP usually
terminates at hosts.  If any kind of wireless bridge between two wired
networks were used (the "wireless ethernet cable"), however, such an
attack against the wireless link would be possible.

> That would be even harder to spot in the traffic, and might make the
> cryptanalysis easier, since the domain name wouldn't be changing
> every packet.

Actually, fiddling with the end of a plaintext is often the best place
to start.  If, for example, the message is encrypted with a CBC mode
cipher, all the preceeding blocks in the ciphertext would remain the
same.

> And why not send the packets to some zombie, so you can get the full
> plaintext datagram (ports, sequence numbers, etc.), rather than just
> the domain name?  And if they're not interested in knowing more than
> the domain name, why not vary the IP address each each and every
> packet?

I'm not sure what you mean by that...