Legit Norton/Symantec virus update connection or malicious redirect?

Norton Security | Norton Internet Security
1

I had once posted a question similar to this, BUT there is one different/important variable that was not in effect with the previous question

Use NAV2008 on Vista Home Premium OS with vista  service pack 2

 

I noticed in my internet connection log that last night my computer connected to
209.8.118.90
This happened when my computer was scheduled to and checking for virus def updates from Norton/Symantec

My activity log shows that liveupdate was running.

But in the internet connection log it showed the IP name as
content.yeildmanager.com
When I Google stuff on content.yeildmanager.com I get some shady impressions


When I do a WHOIS check on the IP address, it shows as belonging to
Beyond the Network America, Inc and again when I google that it shows some questionable information
Now the strange part is that I show to have received virus defs from Norton/Symantec at this same time

I think the virus update was 20100610 rev 25 or rev 48. So I received an updated Norton file


As an additional note- there was another check for Norton Antivirus updates 3 hours after ( I have it set to check every 3 hours) and this next check went to Symantec.com

Could it be:
1. An error in the logging of both the IP address and the domain name?


2. Norton/Symantec uses this server as a delivery system of Norton Virus def updates
( I have seen sometimes virus def updates from Norton come from different servers other than Symantec, but the domain name in the internet connection log says symantecliveupdate or Symantec not something different like content.yeildmanager.com)

 

3. So is this a malicious redirect?

Subsequent scans show no virus/spyware  other than the normal tracking cookies tracking cookies and further virus updates have been good and look normal

So does this sound malicious? Just seems so odd it would show up as content.yeildmanager.  com

This never seemed to happen before

Any help to understand this is much appreciated. Hope it is nothing serious

 

2

I had once posted a question similar to this, BUT there is one different/important variable that was not in effect with the previous question

Use NAV2008 on Vista Home Premium OS with vista  service pack 2

 

I noticed in my internet connection log that last night my computer connected to
209.8.118.90
This happened when my computer was scheduled to and checking for virus def updates from Norton/Symantec

My activity log shows that liveupdate was running.

But in the internet connection log it showed the IP name as
content.yeildmanager.com
When I Google stuff on content.yeildmanager.com I get some shady impressions


When I do a WHOIS check on the IP address, it shows as belonging to
Beyond the Network America, Inc and again when I google that it shows some questionable information
Now the strange part is that I show to have received virus defs from Norton/Symantec at this same time

I think the virus update was 20100610 rev 25 or rev 48. So I received an updated Norton file


As an additional note- there was another check for Norton Antivirus updates 3 hours after ( I have it set to check every 3 hours) and this next check went to Symantec.com

Could it be:
1. An error in the logging of both the IP address and the domain name?


2. Norton/Symantec uses this server as a delivery system of Norton Virus def updates
( I have seen sometimes virus def updates from Norton come from different servers other than Symantec, but the domain name in the internet connection log says symantecliveupdate or Symantec not something different like content.yeildmanager.com)

 

3. So is this a malicious redirect?

Subsequent scans show no virus/spyware  other than the normal tracking cookies tracking cookies and further virus updates have been good and look normal

So does this sound malicious? Just seems so odd it would show up as content.yeildmanager.  com

This never seemed to happen before

Any help to understand this is much appreciated. Hope it is nothing serious

 

3

Thanks Send, puts mymind at ease. I know that Symantec uses difference servers to deliver updates, its justt hat the name shown in the log with that IP 209.8.118.90  showed odd. maybe it was just an error or abberation. It was the only connection to the internet at the time. Plus I did get my def updates.

I did check my host files and nothing weird on it

I think it would be odd if there were some malicious behavior but then I'd still get my defs, eh?

 

also ran malwarebytes and scan was clean

 

Only thing that is weird, when I look up the IP 209.8.118.90 using different IP look ups, I get different information

tools. whois.net  shows 209.8.118.90 as Beyond The Network America, Inc

ws.arin.net/whois shows it as Beyond The Network America, Inc

 

infobyip.com  shows it as Domain: a209-8-118-90.deploy.akamaitechnologies.com

 

webyield.net shows it as deploy.akamaitechnologies.com

 

so that is why it gets confusing to me.

What is the correct result?

 plus the fact that Beyond The Network America, Inc seems to have a shady rep made that a little concerning

 

Now overnight  there we several checks for def updates with connections to

204.2.215.67

209.8.118.82

209.8.118.130

204.2.215.31

and all either showed the name as symantec.com or liveupdate.symantecliveupdate.com so thats cool. And around 3am the connection to 209.8.118.82 did deliver update defs

 

One side note, could this be evidence of a DNS name changer infection? Just wondering

 

 

 

4

HI Calls

 

Symantec has a lot of its Servers hosted out so doing a whois lookup will give you results that are not Symantec themselves.

5

Hi Calls,

 

I think some of the whois information you encountered is out of date.  Check the updated dates for the IP address in your search results.

 

I would also suggest that checking your logs about this is sort of a waste of time.  LiveUpdate authenticates download packages by checking the files' digital signatures.  If there is a problem, instead of an update you will get an error message.  As vectors for malware go, LiveUpdate is not something you need to worry about.

6

Thanks Send OfJive- You took a huge worry off my mind. But I do have one more question about virus def update files if you don't mind.

You said

LiveUpdate authenticates download packages by checking the files' digital signatures.

 

When I look at my current Virus Def update folder  2010.06.14.025

Which items in the folder should have digital signatures?

I see several DAT files and they do NOT have digital signatures

I see some .dll files and they do.

 

Or am I misunderstanding the point and if the folder was not valid, I would like you said, get an error message? And as lomg as I have the most recent def folder, I need not worry?

7

Hi Calls,

 

I am not versed in the specifics of how the authentication is handled, as the current methods may differ from those I have seen discussed in some Symantec literature from a few years ago.  But, yes, any definition file that is successfully downloaded will be authenticated first.  If authentication fails  you will get one of those dreaded LiveUpdate error messages telling you that the update was unsuccessful.  So you needn't have any worries about the integrity of your definitions files.

8

 

Calls wrote:

Thanks Send OfJive- You took a huge worry off my mind. But I do have one more question about virus def update files if you don't mind.

You said

LiveUpdate authenticates download packages by checking the files' digital signatures.

 

When I look at my current Virus Def update folder  2010.06.14.025

Which items in the folder should have digital signatures?

I see several DAT files and they do NOT have digital signatures

I see some .dll files and they do.

 

Or am I misunderstanding the point and if the folder was not valid, I would like you said, get an error message? And as lomg as I have the most recent def folder, I need not worry?

 

In the Beta release of the 2011 products, you can find the signatures in a folder like:

C:\Program Files (x86)\Norton Internet Security\Engine\18.0.0.128\SPManifests

 

Search for .grd files or .sig files on you system and you'll probably find. The sig file is a binary Symantec signature that your Norton program validates when it applies the associated patch.

9

Thanks Reese- But I'm still using the NAV2008 ( I know all this will be a moot point once I upgrade)

 

Until then- Do I need to check for signed .grd files or .sig files to make sure all is ok?

 

I'm Using Vista OS and I find the virus defs in this path

C:/ProgramData/Symantec/Definitions/VirusDefs/20100615.005

there is an

 ERASER.sig

ERASER.grd

v.grd

v.sig

 

AND NONE OF THEM ARE SIGNED  IS THAT A DANGER?????

 

Or as SendOfJive indicated that if the virus def files were not legit, then I would encounter an error during the updating process (even if the update happens as a scheduled update attempt by my machine)?

 

And really am I making more of this than necessary that if I have the lates virus def update folder, then it is obviously a legit update

(my guess is that it would be very weird if I DID NOT have legit updates but yet still have the same file version as the recent update)

10

Reese- when you say

"Search for .grd files or .sig files on you system and you'll probably find. The sig file is a binary Symantec signature that your Norton program validates when it applies the associated patch."

Do you mean there is a file with a digital signature from symantec? Or do you mean that a .bin file in the folder IS the signature to authenticate the virus def folder?

I found a file that is:

esrdef.bin

that file does not have a digital signature itself

11

Reese was pretty clear on this.

 

"The sig file is a binary Symantec signature....." 

12

You have to understand that some of us are so far from understanding computers

with all due respect and appologies

 

"The sig file is a binary Symantec signature....." 

Unfortunately is not something clear and simple to me. So as I said earlier, does that mean the

esrdef.bin file is the "authenticating signature" itself?

or that a .bin file must be digitally signed?

Please understand, I get no kicks out of not understanding

 

13

Did you find any .grd or .sig files? 

 

Nothing was said about .bin files.

14

LiveUpdate is a more complicated matter than just a definitions file download.  My understanding (limited as it is) is that the digital signature is not located within the virus definition file.  Instead it is compressed into a .ZIP file that is part of the download package that is used to process and install each new update.  In other words you will probably find the signature file stuffed away somewhere in a LiveUpdate download file, rather than in a definitions file.  I hesitate to name the .ZIP file because the information I have looked at may be out of date, and also I am not sure it would be a wise thing to mess with  - especially since such a search is unnecessary to begin with:  Obviously, if the download could not be authenticated by virtue of its digital signature you would not find it on your computer.  The very fact that you have an update to search through means it had to be signed.

15

 

Calls wrote:

 

[...]

 

Until then- Do I need to check for signed .grd files or .sig files to make sure all is ok?

 

I'm Using Vista OS and I find the virus defs in this path

C:/ProgramData/Symantec/Definitions/VirusDefs/20100615.005

there is an

 ERASER.sig

ERASER.grd

v.grd

v.sig

 

AND NONE OF THEM ARE SIGNED  IS THAT A DANGER?????

 

Or as SendOfJive indicated that if the virus def files were not legit, then I would encounter an error during the updating process (even if the update happens as a scheduled update attempt by my machine)?

 

[...]

There is nothing that you need to check with regard to LiveUpdate. The LiveUpdate process for many, many, many years has implemented methods to validate that only packages coming from Symantec are allowed to be applied.

 

 

As I mentioned previously, the .sig file IS the signature associated with the other parts of the associated LiveUpdate package. If any part of the LU package is tampered with, the .sig file won't match and nobody except Symantec can create the .sig file. The .sig file is very similar to the code signing signatures that you are looking for but isn't in a format that you can view with any of your tools and is used to 'sign' all of the other files in the LU package whereas a code signing certificate signs the .exe that it is attached to.

16

Thanks reese-

I think I confused digital signatures with what you were trying to explain to me. No longer worried but now more curious

 

So in the updated def file, is the v.sig and v.grd the "signature identification" file you are talking about? Or is that signature file you are speaking of one that I and us normal Joes and Joans cannot see?

17

 

Calls wrote:

Thanks reese-

I think I confused digital signatures with what you were trying to explain to me. No longer worried but now more curious

 

So in the updated def file, is the v.sig and v.grd the "signature identification" file you are talking about? Or is that signature file you are speaking of one that I and us normal Joes and Joans cannot see?

The v.sig file is the signature file associated with the update.

 

18

Thanks Reese

 

Not worried at this point any longer on this issue, but do have a"learning" question

I checked the recent set of defs I received and again there was a v.sig item. It showed to be only about 3kb in size.

Does that sound right?

19

 

Calls wrote:

Thanks Reese

 

Not worried at this point any longer on this issue, but do have a"learning" question

I checked the recent set of defs I received and again there was a v.sig item. It showed to be only about 3kb in size.

Does that sound right?

3kb is fine. And you don't need to be worried about that either, only Symantec can create the cryptographic hashes that are contained within. If the file were damaged or provided by somebody other than Symantec, LiveUpdate would reject it.

 

20

Thanks Reese- My mind is at ease. Much thanks to you and all those who have helped, like SendOfJive and everyone