Munged Napster Sessions

[spb () SCHADENFREUDE MESHUGGENEH NET (Stephen P. Berry)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Over the past week or so, I've started seeing a number of peculiar
traffic patterns associated with the napster browser.

If you're already familiar with what `normal' napster traffic looks
like, you might want to skip the following background information:

        The napster client allows the luser to search for and
        download MP3 files from other napster clients.  When the
        napster client is started, it connects to a central directory
        server, from which it can obtain information about what
        MP3 files are currently available, do searches, u.s.w.  If some
        client foo wants to download a particular MP3 from another
        client bar, foo will first attempt to contact bar directly.
        If this fails, foo will contact the central directory server,
        which will use its existing connection with bar to forward
        the request.  At this point bar will attempt to connect to
        foo, to allow foo to obtain the file.

        To an IDS sensor looking at the traffic on the external
        interface of a firewall doing NAT, this might look something
        like:

        952996524.800155 foo > fw: icmp: echo request
        952996525.198126 fw:65535 > foo:6699: S 1111111:1111111(0)
                win 8192 <mss 1460> (DF)
        952996525.536798 foo:6699 > fw:65535: S 2222222:2222222(0)
                ack 1111112 win 8760 <mss 1460> (DF)
        952996525.537759 fw:65535 > foo:6699: . ack 1 win 8670 (DF)

        ...u.s.w.  Where `fw' is the external IP address of the firewall
        behind which the client bar lives.  Just looking at the
        above fragment should tell you that there's some other data
        channel between foo and some machine behind fw, as the ICMP_ECHO
        will be dropped if NAT is many-to-one---the internal host
        sending the SYN to foo certainly won't see it.  And even if
        the internal host was getting the ICMP_ECHOs, this would still
        be fairly odd[0][1].

        Disclaimer:  I am neither a napster developer nor a napster
        user, so the above summary could quite possibly use some
        tuning.  If anyone wants to supply a more detailed description
        of napster mechanics, please do so.

Okay, so there's a fundamental Badness associated with the way
napster behaves in that an arbitrary client foo[2] outside your network
perimeter can cause a client bar inside your network perimeter to
initiate a connection back to foo, assuming the access policy across
the perimeter allows reasonably unrestricted outbound access[3].

None of this is news, and I only mention it all to establish context
for describing the odd traffic I've been seeing recently.

Over the past week or so, I've noticed (on a number of otherwise
unrelated[4] networks) some napster sessions with what appears to
be unrelated garbage insterted into the established TCP session.

Notably, the traffic of interest includes various bogus TCP flag
combinations (everything from SYN-FIN packets to full Xmas packets),
bogus TCP flags, and tiny fragments.

In absence of the established napster session, the anomalous traffic would
look powerfully like some sort of TCP fingerprinting attempt to
me.

So what I'm wondering is if there's some new widget out there that
uses napster to do TCP fingerprinting or[5] firewalk-ish network mapping.

Has anyone else seen this sort of thing?  Anyone got an alternate
hypothesis?

- -Steve

- -----
0     Unless you believe in coincidences.
1     One (of several) distressing things about this sort of traffic
      pattern is that---since it is `usual' for one relatively
      innocuous application---it can tend to create a blind spot
      through repetition.  I.e., knowing the above napster
      behaviour, one might choose to design a backdoor that listens
      for ICMP_ECHOs and attempts to establish a TCP connection on
      port 6699 on the source machine.
2     Mod the other client (foo) being behind a firewall which would block
      the initial SYN from the client on your network (bar).
3     Which may or may not be a good idea in your environment.  Discussion
      of the merits of this sort of policy is outside the scope of
      this message.
4     As far as I know, and with the exception of me collecting data
      from both.
5     Not an XOR.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4zaEaG3kIaxeRZl8RAn+nAKCh9Y3DeM/ZmxSI1Alv9GvcTR88dgCcDKNg
4gsYHB2r1XJhMKhLkwLOFmg=
=ujBu
-----END PGP SIGNATURE-----