Does Automatic Update service (wuauserv) use generated IP addresses?

[Vince C.]

Hi.

I've installed a firewall on my server and I can see SVCHOST.EXE connect to
IP addresses that look "weird". For instance, my firewall reported SVCHOST
wanted to connect to "mail.lamediatheque.be" (194.78.106.1) on port 80! It
is definitely *not* a Windows Update web service.

I have installed the latest security hotfixes and this installation of
windows has never been in trouble with viruses of any kind: my anti-virus,
AVG, is always up-to-date with the latest virus patterns and I even made a
scan from a remote machine and found no know sources of infection. Hence I
consider my machine is safe.

Can some one confirm whether WUAUSERV is generating IP addresses to find a
local Windows Update web service in the country I reside (I live in Belgium)
?

Thanks in advance.

 

[Steve Parry [MVP]]

Hi.

I've installed a firewall on my server and I can see SVCHOST.EXE
connect to IP addresses that look "weird". For instance, my firewall
reported SVCHOST wanted to connect to "mail.lamediatheque.be"
(194.78.106.1) on port 80! It is definitely *not* a Windows Update
web service.

I have installed the latest security hotfixes and this installation of
windows has never been in trouble with viruses of any kind: my
anti-virus, AVG, is always up-to-date with the latest virus patterns
and I even made a scan from a remote machine and found no know
sources of infection. Hence I consider my machine is safe.

Can some one confirm whether WUAUSERV is generating IP addresses to
find a local Windows Update web service in the country I reside (I
live in Belgium) ?

Thanks in advance.

try running ad aware on your system to check for spyware

http://www.lavasoftusa.com/support/download/

 

[Vince C.]

"Steve Parry [MVP]" <[email protected]> a écrit dans le message
de [...]

try running ad aware on your system to check for spyware

I forgot to mention I ran Ad-Aware 6 (latest version, build 181) and only
tracker cookies were found. Deleted them. Ran Spybot 1.2 found only cookies
as well. Deleted them. In fact I get this behaviour since the very beginning
I installed Win2K (i.e. "random" IP addresses hit by SVCHOST.EXE.

Hence I seem to have no virus, no Trojan, no spyware. Machine is protected
with a firewall, anti-virus and all critical updates are installed. So...?

Vince C.

 

[malamort]

Le Mon, 18 Aug 2003 12:20:39 +0200

"Steve Parry [MVP]" <[email protected]> a écrit dans le message
de [...]

try running ad aware on your system to check for spyware

I forgot to mention I ran Ad-Aware 6 (latest version, build 181) and only
tracker cookies were found. Deleted them. Ran Spybot 1.2 found only cookies
as well. Deleted them. In fact I get this behaviour since the very beginning
I installed Win2K (i.e. "random" IP addresses hit by SVCHOST.EXE.

Hence I seem to have no virus, no Trojan, no spyware. Machine is protected
with a firewall, anti-virus and all critical updates are installed. So...?

Vince C.

Hello Vince,

I have exactly the same strange outside connection on at least two of
my PC. I have a software firewall on all my PC, this has been installed
just after setup windows and I have an hardware firewall on each
internet connection. I am also from belgium. I have 3 different
Provider: easynet, tiscali, skynet, depending the location.

On one of my PC, I have, like you, SVCHOST.EXE which try to connect to
mail.lamediatheque.be:80.
On the other PC, this is IEXPLORER.EXE ! ! which try this and not
SVCHOST.EXE.

On the first one, I accepted a time SVCHOST make the connection and I
could see that my PC has sent 7 Mo of data to this server...
I don't think this have any link with MSBLAST because I saw it on the
first PC more than 15 days ago. I searched on the web without succes.
For IEXPLORER.EXE,I saw it only today because I let internet explorer
going to port 80 without any restriction. Today, I decided to block all
communication to this IP address and log the traffic, so I saw today 3
times IEXEPLORER trying to connect to mail.lamediatheque.be.........
So I searched again on the web and I found your post.

 

[Vince C.]

"malamort" <[email protected]> a écrit dans le
message de [...]

Today, I decided to block all
communication to this IP address and log the traffic, so I saw today 3
times IEXEPLORER trying to connect to mail.lamediatheque.be.........
So I searched again on the web and I found your post.

Thanks, Malamort.

I personally think SVCHOST is gathering a range of IP addresses to find an
appropriate Windows update server. This is my understanding since I took
extreme precaution for this installation of Windows 2000. I mean I installed
a firewall, antivirus, spy tracker (ad-aware) and all scans are negative. So
I don't think security is compromised.

But as my machine exhibits the same behaviour since the very first time I
(re-)installed it, one year ago, if it were a virus or Trojan it should have
been detected. I remember sweating a lot when I first saw SVCHOST.EXE making
such kinds of connection attempts to sites I didn't even visit or know and
that weren't obviously MS'. After a couple of days, I saw a stable address
range to use.

I truly believe MS product is randomly (for someone who doesn't know the
process) connecting to address ranges to find the closest WU server or, at
least, one that is not saturated. I've been quiet for one year,
approximately and I didn't change the FW config as for Windows Update and
SVCHOST. So why is it doing it again now?

I think because of Blaster worm, MS might have changed the way they
distribute updates: to prevent from using servers that might be targeted by
the worm. This is a scenario that looks acceptable to me as there are
millions of machines with Windows versions that must regularly self update.
So always branching to the same server might result in a DoS. They must have
found a way to automatically select another server from which updates are
downloaded.

One reason would be because MS is not hosting WU servers. Akamai does. So
there might be reasons why Akamai server addresses be unknown at a given
time. And even reasons why those addresses change without any notification
to Microsoft. So WU client would have to find an original way to dynamically
redirect to another server.

I suspect this but I have no clue. I'd like not to reverse-engineer the WU
process, though... Hence I'd like to have a confirmation from Microsoft.

Vince C.

 

[Vanguard]

Hi.

I've installed a firewall on my server and I can see SVCHOST.EXE
connect to IP addresses that look "weird". For instance, my firewall
reported SVCHOST wanted to connect to "mail.lamediatheque.be"
(194.78.106.1) on port 80! It is definitely *not* a Windows Update
web service.

I have installed the latest security hotfixes and this installation of
windows has never been in trouble with viruses of any kind: my
anti-virus, AVG, is always up-to-date with the latest virus patterns
and I even made a scan from a remote machine and found no know
sources of infection. Hence I consider my machine is safe.

Can some one confirm whether WUAUSERV is generating IP addresses to
find a local Windows Update web service in the country I reside (I
live in Belgium) ?

Thanks in advance.

If svchost.exe is making a connection to mail.lamediatheque.be then it
sounds like you have an NT service running that is making the connection
(see http://support.microsoft.com/default.aspx?scid=kb;en-us;250320 for
info on svchost.exe). If it is an NT service, and if it has something
to do with Windows Update (Automatic Updates service), why does it go to
a "mail" subdomain? I'm not sure a connection is even made. A local
nslookup and use www.samspade.org on "mail.lamemediatheque.be" or
"www.lamemediatheque.be" returns no results. RIPE says
lamemediatheque.be uses DNS servers on skynet.be. The RIPE registration
data for lamediatheque.be says their web site is www.belgacom.be and the
registration for that domain also uses DNS servers on skynet.be. But
when I use SamSpade's safe web browser, all I see this site do is create
a cookie file (with a URL using a ,jsp file to display a web page).

I'm in the USA. I defined a firewall rule to block and alert on inbound
and outbound connections to/from mail.lamediatheque.be. It triggered
which makes me wonder why Microsoft would have me connect to IP name
that doesn't have a DNS lookup to get an IP address. Ad-Aware, SpyBot,
Norton Anti-Virus (up to date) don't find anything. Sure looks like it
is embedded in something from Microsoft. The .doc at
http://www.microsoft.com/windows2000/windowsupdate/sus/susdeployment.asp
for SUS (Software Update Service) server mentions "public Windows Update
servers". To synchronize your SUS server, they say to sync against
other SUS servers or "To synchronize content from the Microsoft.com
Windows Update servers, click Synchronize directly from the Microsoft
Windows Update servers." Maybe someone running SUS could tell in the
logfiles just what are those Microsoft.com Windows Update servers. The
article mentions that content can be regulated according to your region
so, for example, you could only include updates on your SUS server
applicable to your country. Apparently the Automatic Updates service
running in my Windows 2000 Pro isn't so picky.

At first I was concerned that lamemediatheque.be was some "lame" site.
But looking around, it seems this is French for "La Médiathèque" which,
I think, means "The Media Library". Maybe someone that know French
could figure out what "services" are provided by www.lamediatheque.be.
Trying to find info from Microsoft on how exactly Windows Update works
is like pulling your own wisdom teeth. Actually, that would be easier
than getting info on WU from Microsoft.

 

[malamort]

Le Mon, 18 Aug 2003 17:50:08 +0200

Hence I'd like to have a confirmation from Microsoft.

Me too!
I can understand your senario but on my PC all automatic update are
disable, so why a process to find WU server.
Yesterday, I sent a mail to lamediatheque and belgacom to ask if they
have any information about that.

 

[Jose Morris]

WUAUSERV connects only to the windowsupdate site.
www.windowsupdate.microsoft.com. There are no other servers to which this
service connects to. It doesnt generate IP addresses to find local Windows
Update Web service because there arent any.

SVCHost can host lots of services. And at any point of time you can see lots
of svchost.exe running. And a single host can host multiple services.
Wondering if the service you are mentioning also runs something else which
is trying to access that address.

Thanks,
Jose

 

[Vince C.]

WUAUSERV connects only to the windowsupdate site.
www.windowsupdate.microsoft.com.

C:\>nslookup www.windowsupdate.microsoft.com
Server : ns.nrb.be
Address: 217.117.32.3

*** ns.nrb.be can't find www.windowsupdate.microsoft.com : Non-existent
domain

There are no other servers to which this
service connects to. It doesnt generate IP addresses to find local Windows
Update Web service because there arent any.

C:\>nslookup windowsupdate.microsoft.com
Serveur : ns.nrb.be
Address: 217.117.32.3

Name : a822.cd.akamai.net
Addresses: 80.15.236.8, 80.15.236.30, 80.15.236.33, 80.15.236.25
80.15.236.16, 80.15.236.31, 80.15.236.38, 80.15.236.32,
80.15.236.9
Aliases: windowsupdate.microsoft.com
windowsupdate.microsoft.com.edgesuite.net

or

C:\>nslookup v4.windowsupdate.microsoft.com
Server : ns.nrb.be
Address: 217.117.32.3

Nom : a1510.cd.akamai.net
Addresses: 80.15.236.22, 80.15.236.31, 80.15.236.14, 80.15.236.17
80.15.236.32, 80.15.236.23, 80.15.236.30
Aliases: v4.windowsupdate.microsoft.com
v4.windowsupdate.microsoft.com.edgesuite.net

SVCHost can host lots of services. And at any point of time you can see lots
of svchost.exe running. And a single host can host multiple services.
Wondering if the service you are mentioning also runs something else which
is trying to access that address.

On the machine I checked (W2K Adv. Server) there is only one process that
makes such connections, which command line is:
\WINNT\system32\svchost.exe -k wugroup. And wugroup denotes Windows Update
DLL group. I got these results from Systeml Internals networking toools like
TCPView.

Here's the DLL dump of the one SVCHOST that generates the traffic we're
talking about. They all look like legitimate DLLs from MS. I couldn't go
further and determine which of these DLLs owned the connection. Maybe you
can check which of these are for real and legitimate and which are fakes or
spyware but I doubt there might be ones.

The system is a W2K Adv. Server SP4 with all critical updates installed at
the time I posted my first message (Aug. 18th).

svchost.exe pid: 1588
Command line: D:\WINNT\system32\svchost.exe -k wugroup

Base Size Version Path
0x01000000 0x5000 5.00.2134.0001 D:\WINNT\system32\svchost.exe
0x78460000 0x81000 5.00.2195.6685 D:\WINNT\system32\ntdll.dll
0x78ed0000 0x62000 5.00.2195.6710 D:\WINNT\system32\ADVAPI32.DLL
0x77e70000 0xc4000 5.00.2195.6688 D:\WINNT\system32\KERNEL32.DLL
0x770c0000 0x6e000 5.00.2195.6753 D:\WINNT\system32\RPCRT4.DLL
0x77a40000 0xec000 5.00.2195.6769 D:\WINNT\system32\OLE32.DLL
0x77f40000 0x3c000 5.00.2195.6660 D:\WINNT\system32\GDI32.dll
0x77e00000 0x65000 5.00.2195.6688 D:\WINNT\system32\USER32.DLL
0x00440000 0x6000 5.04.3630.2554 d:\winnt\system32\wuauserv.dll
0x78000000 0x45000 6.01.9844.0000 D:\WINNT\system32\msvcrt.dll
0x70bd0000 0x65000 6.00.2800.1106 D:\WINNT\system32\SHLWAPI.dll
0x00470000 0x32000 5.04.3630.2554 D:\WINNT\system32\wuaueng.dll
0x779a0000 0x9b000 2.40.4522.0000 D:\WINNT\system32\OLEAUT32.dll
0x715f0000 0x27000 6.00.2800.1106 D:\WINNT\system32\ADVPACK.dll
0x77810000 0x7000 5.00.2195.6623 D:\WINNT\system32\VERSION.dll
0x75950000 0x6000 5.00.2195.6611 D:\WINNT\system32\LZ32.DLL
0x78d20000 0x63000 5.00.2195.6711 D:\WINNT\system32\USERENV.dll
0x76930000 0x1b000 5.00.2195.6673 D:\WINNT\system32\sfc.dll
0x67df0000 0xf1000 5.00.2195.6717 D:\WINNT\system32\sfcfiles.dll
0x65510000 0xd000 5.00.2195.6701 D:\WINNT\system32\WINSTA.dll
0x65370000 0x7000 5.00.2134.0001 D:\WINNT\system32\WTSAPI32.dll
0x66400000 0xa000 5.00.2195.6701 D:\WINNT\system32\UTILDLL.dll
0x77500000 0x22000 5.00.2195.6664 D:\WINNT\system32\TAPI32.dll
0x71710000 0x84000 5.81.4916.0400 D:\WINNT\system32\COMCTL32.DLL
0x783c0000 0x91000 5.00.2195.6622 D:\WINNT\system32\SETUPAPI.dll
0x750f0000 0x4f000 5.00.2195.6601 D:\WINNT\system32\NETAPI32.dll
0x78fb0000 0xf000 5.00.2195.6695 D:\WINNT\system32\SECUR32.DLL
0x75140000 0x6000 5.00.2134.0001 D:\WINNT\system32\NETRAP.DLL
0x750d0000 0xf000 5.00.2195.6666 D:\WINNT\system32\SAMLIB.DLL
0x74fb0000 0x14000 5.00.2195.6601 D:\WINNT\system32\WS2_32.DLL
0x74fa0000 0x8000 5.00.2134.0001 D:\WINNT\system32\WS2HELP.DLL
0x77940000 0x2b000 5.00.2195.6666 D:\WINNT\system32\WLDAP32.DLL
0x77970000 0x24000 5.00.2195.6680 D:\WINNT\system32\DNSAPI.DLL
0x74fd0000 0x9000 5.00.2195.6603 D:\WINNT\system32\WSOCK32.DLL
0x68880000 0xb000 5.00.2195.6602 D:\WINNT\system32\REGAPI.dll
0x772f0000 0x17000 5.00.2181.0001 D:\WINNT\system32\MPRAPI.dll
0x77380000 0x30000 5.00.2195.6601 D:\WINNT\system32\ACTIVEDS.DLL
0x77350000 0x23000 5.00.2195.6701 D:\WINNT\system32\ADSLDPC.DLL
0x77820000 0xe000 5.00.2168.0001 D:\WINNT\system32\RTUTILS.DLL
0x70200000 0x96000 6.00.2800.1106 D:\WINNT\system32\WININET.dll
0x77410000 0x79000 5.131.2195.6661 D:\WINNT\system32\CRYPT32.dll
0x77400000 0x10000 5.00.2195.6666 D:\WINNT\system32\MSASN1.DLL
0x77580000 0x24f000 5.00.3700.6705 D:\WINNT\system32\SHELL32.dll
0x72c60000 0x86000 2000.02.3504.0000 D:\WINNT\system32\CLBCATQ.DLL
0x69a00000 0x1d000 5.00.2195.6666 D:\WINNT\system32\NTMARTA.DLL
0x777f0000 0x1e000 5.00.2195.6659 D:\WINNT\system32\WINSPOOL.DRV
0x793c0000 0x11000 5.00.2195.6611 D:\WINNT\system32\MPR.DLL
0x77be0000 0x11000 5.00.2195.6666 D:\WINNT\system32\NTDSAPI.dll
0x76230000 0x3e000 2000.02.3504.0000 D:\WINNT\System32\es.dll
0x74100000 0x64000 2000.02.3504.0000 D:\WINNT\System32\TxfAux.Dll
0x782d0000 0x1f000 5.00.2195.6680 D:\WINNT\system32\msv1_0.dll
0x76080000 0x50000 5.01.2600.1188 D:\WINNT\system32\winhttp.dll
0x00b90000 0x8000 6.02.3630.2522 D:\WINNT\System32\qmgrprxy.dll
0x774b0000 0x33000 5.00.2195.6625 D:\WINNT\system32\RASAPI32.DLL
0x77490000 0x11000 5.00.2195.6604 D:\WINNT\system32\RASMAN.DLL
0x75a50000 0x5000 5.00.2195.6627 D:\WINNT\system32\sensapi.dll
0x77310000 0x13000 5.00.2195.6602 D:\WINNT\system32\iphlpapi.dll
0x774f0000 0x5000 5.00.2134.0001 D:\WINNT\system32\ICMP.DLL
0x77330000 0x19000 5.00.2195.6685 D:\WINNT\system32\DHCPCSVC.DLL
0x00c70000 0x204000 2.00.2600.1183 D:\WINNT\system32\msi.dll
0x77830000 0xc000 5.00.2195.6603 D:\WINNT\System32\rnr20.dll
0x777d0000 0x8000 5.00.2160.0001 D:\WINNT\System32\winrnr.dll
0x777e0000 0x5000 5.00.2168.0001 D:\WINNT\system32\rasadhlp.dll
0x74f50000 0x1e000 5.00.2195.6602 D:\WINNT\system32\msafd.dll
0x74f90000 0x7000 5.00.2195.6601 D:\WINNT\System32\wshtcpip.dll
0x768e0000 0x2b000 5.131.2195.6624 D:\WINNT\system32\wintrust.dll
0x77910000 0x23000 5.00.2195.6613 D:\WINNT\system32\IMAGEHLP.dll
0x7ca00000 0x23000 5.00.2195.6611 D:\WINNT\system32\rsaenh.dll
0x69b10000 0x115000 8.30.9926.0000 D:\WINNT\system32\msxml3.dll
0x78160000 0x27000 5.01.2195.6705 D:\WINNT\system32\schannel.dll
0x67400000 0x27000 5.00.2195.6612 D:\WINNT\system32\dssenh.dll
0x70440000 0x8f000 6.00.2800.1106 D:\WINNT\System32\mlang.dll

 

[Vince C.]

"malamort" <[email protected]> a écrit dans le
message de [...]

Me too!
I can understand your senario but on my PC all automatic update are
disable, so why a process to find WU server.

This process could be also part of a discovery mechanism that is also loaded
with MSIE when automatic updates are disabled. Windows Update is part of a
DLL that is loaded with SVCHOST -k wugroup.

MSIE also tries to auto update. So it could also use the same DLL (for the
sake of code reuse). Why not... And the same DLL could also be used when
running Windows Update from IE.

Vince C.

 

[Vince C.]

"malamort" <[email protected]> a écrit dans le
message de [...]

Effectively, it could. I have not enough knowledge to know how these
update mechanism work. So my input is certainly not the best.
Yesterday, I also discovered a lot of connection to AKAMAI that I
didn't know. I saw that there was already a lot of thread in this news
group regarding these automatic update. I will take time to read them.

Yep, I think it's normal since Windows Update servers are hosted by AKAMAI.
If you try to nslookup v4.windowsupdate.microsoft.com or
windowsupdate.microsoft.com you will see they are in fact aliases to Akamai
machines.

Thanks for all information.

It's my pleasure.

Best regards,
Vince C.

 

[Sam]

Vince,

The fact that you are reaching akamai servers through windows fqdns
may be related to the Blaster worm. It is their strategy against the
attacks of the 15th 16th.

Found on http://www.netcraft.com/
<< On Friday Microsoft changed its DNS so that requests for
www.microsoft.com no longer resolve to machines on Microsoft's own
network, but instead are handled by the Akamai caching system, which
runs Linux. >>


Today, my ISP has confirmed that the IP address 194.78.106.1 ( which
we received less than one year ago ) has never been used for caching
file systems or microsoft related services. That points the problem
directly inside windows code.


In my opinion, your assumption that windowsupdates uses an algorithm
to generate IP addresses to find an update site is the most accurate,
but i really don't understand why they would not use a DNS based
solution, which is really easier to setup and more reliable...

I will try to look in other newsgroups for similar issues to see how
important this thing is.


Looking at the log files of last days on the IIS server, i couldn't
find any connexion error of computers that would have tried to fetch
pages for mail.lamediatheque.be. ...

No more comments.

 

[malamort]

I continue to have very strange constatation:

Starting situation: I have a PC with Windows2000, Mcafee and
TinyFireWall from the first day. checked by ad-aware 61, connected to
internet using a linux FireWall solution (floppyFW) setup on a
Pentium1, I tough safe.
*Tiny is configured to block ALL connection to mail.lamediatheque.be
(from ANY program with ANY protocol), it is also configured to "alert
when rules apply" and "log to file vhen apply"*. This rules is the
first rule configured in tinyFW.
Linux FloppyFW is configured to let all outgoing connection.

So, I decide to update windows2000 from SP3 to SP4. I open an IExplorer
windows and point to windowsupdate.microsoft.com. I clic on "search for
windows update"
Then I think to check all my opened connection in tinyFW.

What a surprise, I can see an OUTgoing connection from *IExplorer.exe*
to mail.lamediatheque.be:443 !!! (RX:224k Tx:18k)
Not sure, I check my Tiny configuration and can see the correct rule.
Then I check again all opened connection in tinyFW and can see another
OUTgoing connection, mostly the same, from IExplorer.exe to
mail.lamediatheque.be:443 !!! (RX:2k Tx:2k)

Then I decide to open an IExplorer windows to test this tiny rules by
myself. I put the adresse: http://mail.lameditheque.be and put enter.
Tiny open an alert, block the connection and log the problem
correctly!!!
So I try httpS://mail.la mediatheque.be. Same reaction from tinyFW
(alert+block conn.+log problem)

I also observe that there are other strange connection to other
IPadresses (194.78.133.201, 194.78.133.198). These adresses reply to
ping but they do not reply to whois query.

So, I note that even if tinyFW is correctly configured, it is not able
to block this strange outgoing connection ! ! ! -> then, if this is a
standard WU process, I know now that my operation system has
functionnalities to pass over a software FW solution... In my opinion,
this is a security problem!
I note also that I receive more data than I send even if this is an
outgoing connection.
I note that this connection can be done by SVCHOST.EXE, IEXPLORER.EXE
and they point to port 80 and 443.

Finaly, I would like to investigate more in depth this connection, is
there someone who could give me an adress for a good and easy-to-use
snifer.

I have print screen of
- all these strange connection that I saw today on this PC with tinyFW
- config of my TinyFW
- Log of tinyFW
If one of you would see it, I can send it by mail without any problem.
Just ask me.

 

[Vince C.]

I continue to have very strange constatation:
[...]
I also observe that there are other strange connection to other
IPadresses (194.78.133.201, 194.78.133.198). These adresses reply to
ping but they do not reply to whois query.

I also observed this. In fact these addresses are part of BE-SKYNET (Skynet
Belgium) network. You can check at www.arin.org/whois.

So, I note that even if tinyFW is correctly configured, it is not able
to block this strange outgoing connection ! ! ! -> then, if this is a
standard WU process, I know now that my operation system has
functionnalities to pass over a software FW solution... In my opinion,
this is a security problem!

Not necessarily. If you didn't explicitly block these IPs, there are no reasons
your firewall should block them. (Unless you used a network/mask rule. But in
that case you would be likely to block the whole Skynet network...)

I note also that I receive more data than I send even if this is an
outgoing connection.

This is not an exception. TCP/IP connections open a full duplex channel, i.e. a
link between two devices for sending and receiving on both sides. There is no
relation between an outgoing connection and the direction of the data flow just
because it is bi-directional. You get the same when you download your mails from
your ISP. The request is generally shorter than the response.

For instance, when your browser opens a web page it sends a request to the
server that may be as simple as:

GET /

and the response an entire web page. So this is not surprising if there is a
server behind these addresses.

I note that this connection can be done by SVCHOST.EXE, IEXPLORER.EXE
and they point to port 80 and 443.

The one made by IE is, I think, for self update. IE is configured by default to
search for updates.

Finaly, I would like to investigate more in depth this connection, is
there someone who could give me an adress for a good and easy-to-use
snifer.

I have run built-in tool "netmon" on a W2K server. I'm not sure it also runs on
a non-server version of Windows 2K. Otherwise you have network tools at Mark
Russinovich & Bryce Cogswell's www.sysinternals.com. You can take a look at
TDIMon v1.1. I have never use it but System Internals is a must. Bookmark it
. Oh! and it's free ;-)


Regards,
Vince C.

 

[KB]

I continue to have very strange constatation:

I recently discovered these same symptoms on all 3 of my XP boxes, at
home and at work.

I would see an outgoing HTTP (and HTTPS) connection to IP addresses
that made no sense to me. I used TCPView to find out what
executable(s) were making these connections. I discovered it was
svchost.exe, but that was just a wrapper to multiple service DLLs
doing different things. So I modified my registry so that *every*
service started up in its own svchost.exe. (I can share how to do
this.) I then discovered that it was wuauserv.exe (or dll) that was
making these outgoing connections to places other than microsoft.com.

I have used latest spybot, adaware, and McAffee anti-virus; none found
anything wrong with my wuauserv and the problem persists. Also, my XP
patches are all "up-to-date". I am obviously suspicious of the truth
of this given wuauserv is the leading suspect.

I also observe that there are other strange connection to other
IPadresses (194.78.133.201, 194.78.133.198). These adresses reply to
ping but they do not reply to whois query.

I notice (by leaving TCPView running overnight) that these events
occur in pairs. Last night produced: (1) an HTTP connection to
80.15.249.113 and (2) an HTTPS connection to
67.106.64.38.ptr.us.xo.net. I don't what order they occured. The
previous night was the same, except the addresses were different. They
were (1) HTTP to 81.52.248.145 and (2) HTTPS to 63.240.175.17. Three
of these addresses don't have reverse DNS which seems highly
suspicious to me.

So, I note that even if tinyFW is correctly configured, it is not able
to block this strange outgoing connection ! ! ! -> then, if this is a
standard WU process, I know now that my operation system has
functionnalities to pass over a software FW solution... In my opinion,
this is a security problem!

I think this is a HUGE security problem.

Finaly, I would like to investigate more in depth this connection, is
there someone who could give me an adress for a good and easy-to-use
snifer.

For this problem I have recently used ethereal for XP; it does pretty
good. I did like to use tcpdump on FreeBSD, but now I am on switched
network and can't watch neighboring traffic. I have not captured any
of this packet traffic yet to look at it.

-kb

 

[KB]

WUAUSERV connects only to the windowsupdate site.
www.windowsupdate.microsoft.com. There are no other servers to which this
service connects to. It doesnt generate IP addresses to find local Windows
Update Web service because there arent any.

SVCHost can host lots of services. And at any point of time you can see lots
of svchost.exe running. And a single host can host multiple services.
Wondering if the service you are mentioning also runs something else which
is trying to access that address.

Thanks,
Jose

I have narrowed it down to wuauserv being the origin of these outgoing
connections.

Could someone run a MD5 checksum on "good" copies of a few files
related to Windows Update so I can compare mine? To get the info
below, I looked at properties for each file, plus I ran two different
MD5 tools on these files (I used unix md5 and slavasoft fsum.exe).

C:\WINDOWS\system32\wuauserv.dll
version 5.4.3630.1106
9216 bytes
created = 9/26/2002,7:11:59pm
modified = 8/29/2002,7:00:00am
MD5 (wuauserv.dll) = b85d727aa4de3bf6bebea364a250fcda

C:\WINDOWS\system32\wuaueng.dll
version 5.4.3630.2550
199,288 bytes
created = 9/26/2002,7:11:59pm
modified = 1/15/2003,10:28:30am
MD5 (wuaueng.dll) = 0d072f86f21f55fb6799d22eb2100722

C:\WINDOWS\system32\wuauclt.exe
version 5.4.3630.2550
148,088 bytes
created = 9/26/2002,7:11:59pm
modified = 1/15/2003,10:28:28am
MD5 (wuauclt.exe) = 2176fd6697d4e39669dc41429bab3245

-kb

 

[Vince C.]

"KB" <[email protected]> a écrit dans le message de (e-mail address removed)...
[snipped and snipped again ]

3 of these addresses don't have reverse DNS which seems highly
suspicious to me.

Well, don't know if suspicious is the right term but it tends to confirm the
subject of this thread ;-). It would be dangerous if:
1. WU uses generated IP addresses
2. our famous "malicious user" knows how to build a web site that acts the
same...

Hmmm... that's... terrifying! :-D
Would be the supreme virus (note for later: think of installing BEOS instead ;-)

I think this is a HUGE security problem.

Wonder if it's the same on Windows 98... I wish someone had time to check
that... 'Would tell if this is a technology in use since the early days. But I
bet this was active only since they introduced the new version of Windows
Update.

Vince C.
- The truth is out there...

 

[Vanguard]

Well, here's another way to trigger a firewall rule looking for
connections to lamediatheque.be:

- Open a DOS shell window.
- Start an FTP session with Microsoft's FTP site:
ftp ftp.microsoft.com
user: anonymous
pass: whatever
- Do an "ls" command (to list the files/directories).

Whenever you do an ls command, lamediatheque.be gets hit. So it isn't
just part of Windows Update. And I don't think ftp.microsoft.com is
considered a Windows Update site.

 

[Vince C.]

Well, here's another way to trigger a firewall rule looking for
connections to lamediatheque.be:

- Open a DOS shell window.
- Start an FTP session with Microsoft's FTP site:
ftp ftp.microsoft.com
user: anonymous
pass: whatever
- Do an "ls" command (to list the files/directories).

Whenever you do an ls command, lamediatheque.be gets hit. So it isn't
just part of Windows Update. And I don't think ftp.microsoft.com is
considered a Windows Update site.

Where you also told about being infected with a blaster-like virus when you
reported this? This is slightly getting fascinating...

Vince C.

 

[Sam]

===

What a surprise, I can see an OUTgoing connection from *IExplorer.exe*
to mail.lamediatheque.be:443 !!! (RX:224k Tx:18k)
Not sure, I check my Tiny configuration and can see the correct rule.
Then I check again all opened connection in tinyFW and can see another
OUTgoing connection, mostly the same, from IExplorer.exe to
mail.lamediatheque.be:443 !!! (RX:2k Tx:2k)

That is impossible as port 443 is not opened to the public network on
that computer.

This connection could confirm a step in the akamai process that is
handling the update :

<< Q: My Firewall is reporting an "Unknown" Akamai Connection from
port 443 of your server. Why?

A: When you connect to a site that is "Akamaized" with SSL content
(Secure Sockets Layer), your browser downloads an HTML file containing
embedded URLs that tell your browser that some of the objects
necessary to finish displaying the page are located on Akamai servers.
Next, your browser contacts an Akamai server to obtain these images or
streaming content. Since the contact is made from port 443 of our
server, this transaction is a legitimate HTTPS connection. Generally a
TCP service runs on a server on a well-known port number less than
1024; in this case SSL service runs on port 443. A client connects
with a random port number greater than 1023 that is assigned by the
local operating system. >>

For your infos, here are the other connections that could be
established from akamaïzed services.

http://www.akamai.com/en/html/misc/support_faq.html


===


The fact that you are receiving data from "an impossible connexion"
could mean that there is a malfunction in the find_an_ip algorithm.

What about a loop that is looking for a valid WUS :

1. at a givent step it finds 194.78.106.1
3. it checks if it is a valid WUS
2. then it records in another variable the ip_fqdn =
mail.lamediatheque.be. with a reverse dns query
4. if it is a valid WUS, it writes the IP/FQDN in the DNS cache

This bad implementation could lead to having mail.lamediatheque.be.
point to another IP that could be a valid WUS.

WindowsUpdate then uses mail.lamediatheque.be to connect to that IP
and your firewall doesn't use the cache of your workstation to get the
IP of mail.lamediatheque.be.


This is just an idea...


===


Vince,

I was also reporting to my boss that our IP address could be
interresting for crashers. And if your theory is true, this could be a
huge hole in the windows update process. I am sure ( i hope )
microsoft is signing its files and has some control over their
integrity.

But imagine if this is true, the latest RPC bug used to take over
servers to create fake WU services containing patches with blank dll
files. That could lead to a pretty nasty global chaos...


Hopefully, we live in a perfect world.