I am back at my office -- here is that piece with a trace of a MS
box phoning home.
The NTP protocol requires the presence of 'strong' crypto for
authentication, such that it was covered by the previous ITAR
regulations, and was issued in an 'exportable' and a
'non-exportable' version by Red hat prior to the change late in RH
6.2. Once the need for differientiation was gone, RH re-issued the
former 'xntp3' package as simply 'ntp'
Ditto the DNS protocol, from bind, ver. 8 on ...
So: "dns query for time.windows.com" will cause your nameserver
(which is probably less subject to outbound content monitoring) to
query a MicroSoft controlled server, which can be hacked to provide
serial number uinformation as part of the query.
Then: the NTP conversation with 207.46.228.33 can carry
(steganographicly encoded) keying information, bearing with it
various host serial numbers.
see eg working code at: http://www.outguess.org/ which discusses
balancing methods to defeat statistical traffic pattern analysis to
detect steganographic encrypted content.
-- Russ
---------- Forwarded message ----------
Date: Mon, 14 May 2001 13:54:46 -0700 (PDT)
From: Max Vision <vision@whitehats.com>
To: VULN-DEV@securityfocus.com
Subject: WinXP calls back to Microsoft
WinXP Pro default install is really noisy. In a typical boot in a Windows
environment you will probably see the following:
1 udp dhcp/bootp request [0.0.0.0:68 -> 255.255.255.255:67]
3 arp wh-ohas for my new ip [ARP who-has x.x.x.x tell x.x.x.x]
20 udp netbios broadcast (many types) [x.x.x.x:137 -> x.x.x.255:137]
8 udp netbios broadcast (many types) [x.x.x.x:138 -> x.x.x.255:138]
1 udp dns query for time.windows.com [x.x.x.x:1026 -> your.dns.server:53]
1 udp ntp update request [x.x.x.x:123 -> 207.46.228.33:123]
1 icmp echo request to dns server [x.x.x.x -> your.dns.server]
2 igmp broadcast to IGMP.MCAST.NET [x.x.x.x -> 224.0.0.22] (ttl = 1)
3 printer solicitations [x.x.x.x:3004 -> 239.255.255.250:1900]
1 ethernet II broadcast type 0x888e (similar to arp, local only)
The ethernet ii packet is only considered such based on the value of the
type/length field being more than 1500, otherwise it might have been
intended to be a IEEE 802.3 packet. Either way there is no meaningful
payload - the destination mac was some unassigned broadcast or multicast
mac 01:80:c2:00:00:03.
(not listed at http://www.cavebear.com/CaveBear/Ethernet/multicast.html)
The above is all based on a session I captured a few weeks ago when
troubleshooting a dhcp problem I had with a winxp beta2 box. What caught
my eye was the time.windows.com request. It seems a good way for
microsoft to gather the IP addresses of WinXP users. It is probably worth
noting that this is the default but falls back to time.nist.gov.
Paranoid smarties will go to the registry and remove the time.windows.com
request (depending on how you feel about microsoft having your info:)
Possible keys of interest:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers\
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\
I saw the 239.255.255.250 broadcast but I assumed the first router out
would drop it as not publicly routable (mine does).
Max Vision
http://whitehats.com/
http://maxvision.net/
On Sun, 6 May 2001, George wrote:
> Running Windows ME or Whistler/Windows XP I have noticed that upon bootup I
> see packets addressed to 239.255.255.250 port 1900. Upon investigating this
> I find that this is some sort of multicast or broadcast network address
> that's meant for UPnP devices but for some reason if you are connected to
> the internet these packets are routed out to the internet (the local 224
> route does not cover them).
>
> I've posted more information about this at
> http://www.nthelp.com/upnpscrewup.htm and was wondering if anyone here can
> explain to me what this is all about? I believe it has something to do with
> IPP, UPnP, and SSDP but I don't understand what any of this has to do with
> the general internet which is where the packets are headed.
>
> Geo.
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:50:22 EDT