|
Sandstorm Enterprises develops and sells, among other security tools,
an appliance for monitoring and analyzing network traffic. Several of
our developers had expressed curiosity about exactly what Windows XP
did when it "called home" on its first boot, so when a new Dell Inspiron
2650 laptop arrived last week with a sacrificial copy of Microsoft's
Windows XP Home Edition installed on it, we took a moment to study its
network traffic using our
NetIntercept product.
NetIntercept (NI) is unique among network monitoring tools. Complete
network traffic data from the monitored network is saved to a
continuously-updated traffic archive and made available for analysis.
NI can perform TCP and UDP stream reassembly and heuristic content
analysis on selected traffic.
Figure 1. Traffic selected for reassembly on the Traffic tab
As the streams are analyzed, NetIntercept identifies distinguishing
criteria and stores them in an SQL database. The user can then search for
connections of interest. To find the network traffic we wanted to observe,
we searched for traffic to (DST) and from (SRC) the laptop's MAC address
(00:08:74:E9:5F:C8).
Figure 2. Query for network traffic involving the laptop
Our query found 71 sessions involving the laptop's MAC address. In Figure
3, they are sorted by time of the first packet in the session (START).
Figure 3. Query results
We can see WinXP begin by using BOOTP/DHCP over UDP to configure the
network interface. Next it opens a connection to the local nameserver, and
gets the time from a Microsoft site (time.windows.com). Attempts to locate
resources via NetBIOS Nameservice (port 137), NetBIOS Datagram (port 138)
and Simple Service Discovery Protocol (port 1900) go unanswered. Next,
connection 174 uses HTTP to download Javascript from
wpa.one.microsoft.com. Slightly more than two minutes later, connection 284 uses HTTP over SSL to
contact reg.register.microsoft.akadns.net and (presumably) register this
copy of the Windows XP operating system.
When the initial installation and selection of usernames is complete,
Windows XP asks if the user wishes to create a .NET Passport account. We
had agreed to this, and went through the dialog. After an initial exchange
with host nexus.passport.com using HTTP over SSL, we were surprised to
see that subsequent HTTP connections to login.passport.com,
register.passport.net and register.msnia.passport.net used normal HTTP on
port 80.
The most revealing component of the web traffic was the sequence of POST
commands to register.msnia.passport.net (207.46.188.249 in this case) in
connections 477 through 551. The bulk of the URL-encoded object POSTed was
a hashed or coded value tagged "PPTProf=", but this value was preceded by
the plaintext answers to the previous screen's questions. Each object sent
in response by the server contained HTML and Javascript to display the
next screen in the sequence.
From this set of connections, anyone observing the network traffic between
the new .NET Passport user and Microsoft's server farm could have
determined a number of personally-revealing facts (easily readable in
plaintext, highlighted in the figures below):
Figure 4. Sign-in name and email address revealed in plaintext
In this example, we see the sign-in name and email address. In the
subsequent connections, we saw the following information about the person
registering:
The last 40 connections selected were generated by our experimenting
with Microsoft Messenger. Connections of interest included:
- A protocol on UDP port 1863 which sends the MSN email address in the clear
- Another use of SSDP
- Several uses of UDP port 7001, which is assigned to Andrew File System cache management
- HTTP over SSL to login.passport.com and msnialogin.passport.com
The unencrypted web connections all made use of a Passport-related
cookie, and didn't contain any confidential user information.
Security Considerations
We found the insecurity at about 11:30 AM EST on Friday, March 14,
2003. Microsoft was informed as soon as we made our way through the
obfuscation protecting the proper channels. The tests we performed
on the morning of Monday, March 17th led us to believe that the problem
had been fixed, and towards the end of the day, we received formal
notification of that fix. Microsoft indicated that the problem had been
introduced earlier in the week during routine engineering work, and
that since it was in the Passport server itself, they wouldn't be
issuing a security bulletin.
We aren't representing this as anything earthshaking. Hundreds if not
thousands of people have inspected more or less the same sequence of
operations since .NET Passport was rolled out, without encountering
information leakage. We found a transient problem, probably
introduced by an error during routine web site maintenance. Microsoft
fixed it promptly, and even consented to inform us roughly how long
it was in effect.
Looking a little further, one can speculate on two underlying causes
for the problem we found: First, routine web site development is often
done without encryption, so the exchanges on the wire can be studied
with common monitoring tools. In this scenario, adding security is the
last step, and in this case it was omitted. Second, not all monitoring
tools provide traffic reassembly, and those that do usually require a
separate step to reassemble and view each individual connection. Doing
an independent verification of proper behavior after an update can be
inconvenient or time-consuming.
I consider it likely that similar problems happen fairly often, and that
maintainers of most large web sites may be aware of such instances. Our
NetIntercept tool can help in two ways. First, NI makes it very simple
to identify a web transaction or set of transactions and view them.
Second, if web developers make use of our SSL decryption feature, and
configure their NI system with keys from their test servers, they can do
their work with encryption in place.
It's a truism that security won't happen without ceaseless vigilance.
This problem did not demonstrate Microsoft's lack of concern or
vigilance. Instead, I believe we (and not Microsoft's web maintainers)
found this problem because we happened to be working with a tool that
makes this kind of vigilance more convenient.
James Van Bokkelen
Sandstorm Enterprises
www.sandstorm.net
"NetIntercept", "Sandstorm Enterprises", "Dell", "Inspiron", ".NET
Passport", "Windows XP Home Edition", "Microsoft Messenger", and
"Microsoft" are all trademarked, I'm sure.
| 
Sandstorm Home
Products
