Video Screencast Help

Extremely disappointed

Created: 07 Feb 2013 | 28 comments

Here is the story; I work myself at a software company and one of our customers reported that Symantec Endpoint Protection 11.0 claims that some DLLs in our product are virus infected. We know that our DLLs are free from virus/are not a virus and want Symantec to investigate this and remove their warnings. When I finally reached Symantec support, which is close impossible, I got the answer that I need to buy their product to get a license number. Otherwhise, there is no way whatsoever to register a support case. (Good business idea; warn for everything and force SW vendors to buy their products). Ok, we bought the product, registered a support account but when trying to register a support case, the stupid form that you need to fill in does not accept any version numer in the "Version number" field. I emailed Symantec support several times at 'enterprise_technical_support@symantec.com how to get through this but they just refuse to answer. I don't know what to to get help from this monster company.

/Micael

Comments 28 CommentsJump to latest comment

Rafeeq's picture

Please submit the file to Symantec, they will analyze and if its false positive, it will be corrected in the next defs release.

https://submit.symantec.com/false_positive/

 

sandra.g's picture

Thumbs up. I don't think you need to have a Support contract to submit files for review as a false positive.

sandra

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

Ashish-Sharma's picture

 

 

It's probably a false positive alert.

Software White-Listing Request can be submit here.

submit.symantec.com/whitelist

Check this Symante Blog as well: www-secure.symantec.com/.../software-white-listing-program

Go throught the follwoing helpful articles:

Handling and preventing SONAR false positive detections

www.symantec.com/.../index...

Monitoring SONAR detection results to check for false positives

www.symantec.com/.../index...

Thanks In Advance

Ashish Sharma

 

 

Mithun Sanghavi's picture

Hello,

In reference to your case, For software developers, authors, and Independent Software Vendors (ISVs), the Symantec Software White-List program offers an opportunity to have their software added to a white-list of known good software maintained by Symantec to reduce the possibility of false positives.  Please note that Symantec offers this service to reduce false positives, but cannot guarantee that false positives will not occur.  Decisions made by Symantec are also subject to change depending on a variety of factors that include but are not limited to alterations in the software, distribution of the software, or vulnerabilities in the software to misuse by the publisher or others. Symantec may also change its classification criteria and policies over time to address the constantly evolving security landscape.  To submit software to participate in this program, please submit the candidate software to Symantec using the Software White-Listing Request form.

Software White-Listing Request Formhttps://submit.symantec.com/whitelist/

Note: If an application for white-listing is approved it can take a number of weeks for the software in question to be white-listed.  The applicant will be notified after the white-listing process for that software is completed.  The applicant will be notified if the application is not approved.

Our Security Response team can analyze the file and, if it is a false positive, modify our definitions so we stop detecting it.

 

What version of SEP 11.x are you running??

You could check the version of the SEP by opening the SEP client and click on Help and Support on the right hand side top corner.

Once you have the Version number, insert the same in the form, here are the steps on how to create a case - 

How to create a new case in MySymantec

http://www.symantec.com/business/support/index?page=content&id=TECH58873

I would recommend you to Create a Case with Symantec Technical Support via Phone.

Phone numbers to contact Tech Support:-

Regional Support Telephone Numbers:

  • United States: 800-342-0652 (407-357-7600 from outside the United States)
  • Australia: 1300 365510 (+61 2 8220 7111 from outside Australia)
  • United Kingdom: +44 (0) 870 606 6000

Additional contact numbers: http://www.symantec.com/business/support/contact_t...

Once the case is created, simply PM me your case number and I would look into the same.

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

msoft's picture

The "Software White-Listing Request Form" sounds promising. I have now entered a request.

The first thing we did was to use the "Symantec's on-line False Positive Dispute Submission form" but we just got the answer that "the software submitted should retain detection according to our detection criteria." and no imformation about how to proceed.

peter ashley's picture

Do you get any information from a scan of the files on virustotal.com?

Mithun Sanghavi's picture

Hello,

I agree with Peter's comment. Try Submitting these Files on virustotal.com.

Secondly, In reference to the False Positive submission, I would request you to create a case with Symantec Technical Support and provide the Symantec Engineer with the Tracking Number of the Submission (Tracking number comes as a subject line on your email address after submission).

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

Ajit Jha's picture

Hi msoft,

Don't want to comment on it right now, as i have many comments for you but before that just few Questions:

1. How can you say that you S/W is Virus free?

2. Do you really know on what basis Symantec is detecting it as a malicious acitvity.

3. You are working around a Security Product and wondering around for the Support Matrix.

4. Most importantly you have no rights to Blam untill you have evidence.

 

Please mind it.

Regard's

Ajit Jha

Technical Consultant

ASC & STS

ShadowsPapa's picture

How can you possibly be asking a software developer "how can you say that your software is virus-free" ??

They write the bloody software, and you are asking how he can say it's virus-free?

If I write an application or any code that is part of a larger application - I'd certainly hope I've not written a virus into it. Having worked in a high-end electronic engineering company that wrote software that help dozens of patents and sold for hundreds of thousands of dollars a shot - if I were asked that question I'd be rather offended.

Seems like you are blaming. Their customer reported SEP is calling this software a threat. That seems pretty cut and dried to me!

msoft's picture

Ajit,

My main concern is not wether our files are virus infected or not. It is Symantechs ignorant support that don't reply on my emails and force me to buy their product to register a support case.

 

Peter and Mithun,

virustotal.com does not detect any threat. Detection ratio: 0 / 46.

 

Mithun Sanghavi's picture

Hello,

Appreciate it for updating us with the status. Once the case is created, simply PM me your case number and I would look into the same.

 

I would suggest you to create a case with Symantec Technical Support.

How to create a new case in MySymantec

http://www.symantec.com/business/support/index?page=content&id=TECH58873

I would recommend you to Create a Case with Symantec Technical Support via Phone.

Phone numbers to contact Tech Support:-

Regional Support Telephone Numbers:

  • United States: 800-342-0652 (407-357-7600 from outside the United States)
  • Australia: 1300 365510 (+61 2 8220 7111 from outside Australia)
  • United Kingdom: +44 (0) 870 606 6000

Additional contact numbers: http://www.symantec.com/business/support/contact_t...

 

Hope that helps!!

Mithun Sanghavi
Senior Consultant
MIM | MCSA | MCTS | STS | SSE | SSE+ | ITIL v3

Don't forget to mark your thread as 'SOLVED' with the answer that best helped you.

MichaelD50's picture

...please reply with the EXACT version of the SEP 11 client. Also be aware that even the latest release of SEP 11 doesn't protect as well as SEP 12.1.

 

MJD

sandra.g's picture

msoft, please try the False Positive link given above (and here again for your convenience: Report a Suspected Erroneous Detection). You do NOT need to open a Support case in order to do this, but you do need to provide a copy of the software.

I hope this helps.

Edit to add: Oh, sorry--I just saw this was tried. Yes, try the whitelisting option. You might also encourage your customer to open a case with Support.

sandra

Symantec, Senior Information Developer
Enterprise Security, Mobility, and Management - Endpoint Protection

Don't forget to mark your thread as 'solved' with the answer that best helps you!

hforman's picture

I had a similar problem.  One of our contractors created a "setup.exe" file to install his application.  It was rejected by SEP (SONAR/Insight) because the setup.exe file had "no reputation".  I did make a suggestion that we be allowed to configure SONAR with the same sliding bar in other parts of SEP.  If something has no reputation at all, it should be allowed.  There was no virus found in the file.  Unfortunately, a reputation of zero means the file will be quarantined.  I managed to setup an exception but we filed a request for whitelisting and that took care of it.

One of the things we were told was that, if the developer "digitally signed" the file, that would have increased the reputation and the file would have been allowed.  If you are a developer, you should consider obtaining a certificate and sign the files.

 

Howie

 

msoft's picture

Hi Howie,

Thank you for this information. We are actually looking into digitally signing our files so maybe this helps.

Further, I'm looking forward to the response from the "Software White-Listing Request Form" that we submitted at Symantec last week.

/Micael

cus000's picture

hmm the situation sounds hairy... while i understand that onus is at developer end i don't think they need to buy\have Symantec product to get their software whitelisted or cleared from false-positive...

imagine if a piece of their software being detected as "false-positive" at 3-5 different security vendors and each of their support asked this developer to buy their product?

 

not very bright...* that* Symantec support could have answered better imo

ShadowsPapa's picture

We are faced with a problem somewhat similar - we are trying to contract to use a video conferencing software. The company that produces it often has updates - it's roughly once a month.

SEP reports the software update download as a thread because it's not got a reputation established. With monthly updates being downloaded, of course not. And it's not a software like Windows where it's on millions of computers. It's never going to be in the tens of thousands of users arena. And the whitelisting process takes SO long, by the time they submit a request for the April update to be whitelisted, the May update would be out and April would be of no concern. (I base that on the fact that the Symantec docs for this state that is may take several weeks to process the request. Several weeks is actually over a month, so it could be June before the April update is accepted and whitelisted)

So, what do we do?

SEP won't let us exclude the file! It will not go by file names with wildcards. And the file name chances monthly to reflect the version. Can't go by file path as it's the browser cache.

Catch-22 situation here! Symantec makes it hard to get something whitelisted, and impossible to exclude it programmatically in SEP itself.

And what's worse - the developer must go through this rigerous process each and every update - which would be roughly once a month - that's a heck of a lot of overhead for a small developer to have to go through - it takes quite a bit of effort - it's not been made easy from the forms I have seen.

Shawn T.'s picture

While this doesn't change the whitelisting process, if you know where the updates are coming from it is possible to permit them. SEP has a function to add a Trusted Web Domain which should allow you to prevent Download Insight from picking it up. See: http://www.symantec.com/docs/HOWTO80926.

ShadowsPapa's picture

Been there, tried that as well. The updates came from a cloud service the last time. IT's a small company, and like other small companies that can't afford huge server farms around the globe - Akaimi (sp) enters the picture - might be a different DNS resolution, or in the last case, it was from the Amazon cloud.

I could allow ALL downloads from cloudfront.net or whatever the domain or url is, but what is someone with bad stuff hires on with Amazon to host their wares (malwares)? Then I've opened up all of Amazon's cloud computing services to our computers. Would using that trusted domain part of SEP not open up any process on any url based on cloudfront.net - so to add a trusted domain, I'd add "cloudfront.net" - and the files or content we want are abc.cloudfront.net.

Then someone else comes along and shares malware at xyz.cloudfront.net - would we not then trust that as well?

The problem with "trusted domains" is that not everyone can afford to host their own, and a times, files are off-loaded to other servers or services.
Trusted domains work if the vendor with the files we use has and uses their own servers and owns the domain name and doesn't distribute via other cloud services - is that not correct? Or is the above all wrong?
 

hforman's picture

Here is what I see as an issue:

I just attended a Symantec Roudtable where we were given a lecture on "Hygiene" by one of the developers of the concept.  He kept insisting up and down that we should reject all software that has NO (zero) reputation.  Unfortunately, there is no easy way to tell Symantec that you wrote this yourself other than to SIGN the files.  So, the expectation of Symantec is that all developers should be signing their files.  What is worse is that a slider to control this is under the Administrator Scans and does NOT appear under realtime protection, so there is no way to easily say that files with zero reputation should be allowed.  We have enough exceptions in place that Intranet downloads are OK for us but autoprotection is coming up with WS.Reputation.1 errors.

While I agree that files with zero reputation that appear from external sources should be met with at least a query of "Are you sure you want to allow this?", Symantec has made things very difficult (I consider having to sign files as being difficult; maybe requiring us to buy a certificate from Symantec).

We can all complain to Symantec but moving to other Endpoint Protection solutiuons may not be feasible if we are distributing software to outside entities who may or may not be using SEP.

My suggestion would be to sign your files and submit them to Symantec every time you make a code change.

.Brian's picture

Maybe if you worked for the DoD, I could see this as a possibility.

Doesn't work like that in most companies today. Although I agree with the conept.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

hforman's picture

I agree with your assessment.  I would like to see that this action can be changed by individual customers but I don't see any easy way to do that in the current release especially for the realtime protection leg.  I don't know what can be done about it as small developers are probably not going to put up with signing just to satisfy Symantec.  Like you, I agree with the concept but I think a warning would be more that sufficient.  Apparently, with continued use of the application files, they would be treated as having a higher reputation.  (I was not defending this, just explaining what the Symantec representative told me).

.Brian's picture

What I want is a more finely tuned approach to adding exceptions, especially with Download Insight.

Since it uses a hash, why not have an option to add an exception based on the hash value. Would take care of a lot of my issues than.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

ShadowsPapa's picture

That option is there - however, the hash on an update changes each month. Further, we don't know the hash until people have scheduled a meeting, some of the computers are seen as "out of date" and get the latest update download.

I use a hash for files that may have the same or similar names, but that requires having or knowing the hash, or having the file first to get that hash and enter it. What if I'm not here?
What about an update in a month, or 2 weeks, or 4 months from now? Different file - different hash.

.Brian's picture

I don't see the option in the Exception policy so unless I'm missing something...

What happens with us is we put a new build of our in house software and it gets caught. If I could add a hash exception early in the final build process this could be avoided. We're working with our developers to get a process in place but until that happens, it will get caught.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

ShadowsPapa's picture

The solution for us is literally to TURN OFF protection.

That reject all files with 0 reputation is so unrealistic in the REAL world it's laughable. Honestly - if we all did this, then no file, ever, I mean NO file, would have a reputation. It would never be used or analyzed or checked out as we'd all reject it catagorically due to the 0 reputation.

They also need to understand that they aren't the only game in town. Even with thier marketshare - some of these files have been used by hundreds if not thousands of people around the world who do NOT use Symantec products. Say their product just isn't used by certain locations, cultures, business-types, societies or whatever, but there are valid good files out there and the few who do use the Symantec product are in a miniority in these certain parts -  guess what......  Same as above - it will never reach "safe reputation".

I have to challange that thinking as it's isolationist - it's not realistic in entities such as ourselves. I have better solutions - and that is our lockdown of our images, and SEP's app control. We went through some recent "pen testing" and I wished them luck prior to starting. Their USB devices simply didn't work, and the apps couldn't get a toe-hold in here. Even the weekly scans by the appliance used to check all network devices, including printers and routers, switches, servers, etc. - get shut down by SEP so fast they don't register.

If we need to use a file that's fairly new because it's an update by a small respected company that is as aware and concerned about security as we are - we should have a way to tell SEP to ignore those files. But the problem is that this company doesn't have a lot of customers who are ALSO Symantec customers. Their files have no reputation - worse, the fore-thinking people who left us no way to exclude such files have instead of protecting us, left us with no recourse other than shut down SEP while we download the files and have our meetings.

It's nuts. I know what I'm doing, but the product is being dumbed down as if it's a MAC app with no way to tweak settings to suite our needs.
I'm just asking for the ability to tell SEP here locally - accept any file with this name PATTERN in these locations - and allow wildcards. It's that simple.
Instead, next meeting we have I must ensure SEP is disabled on dozens of computers or explain to management why their meeting failed.

Then after granting us that - tell that person who lectured you that they need to spend a week in my shoes here. They also need to be accountable to our managment when things go wrong.
A few hours at the desks of the people who posted their problems here might just see us getting some more options next release.

hforman's picture

By the way, sometimes we, as developers create what I call "accidental malware".  Are you sure the program was flagged as a virus?  If so, which one?  Malware is a different issue.  For exaple, if I was given the task of writing a program that is supposed to authenticate to another system and perform some tasks.  If I write my code such that the user name and password are located inside of my program for the login, then I have just created malware.  Why?  The program does nothing malicious.  It performs its task very well.  Why would I call it malware?  Well, if I have a user name and password inside my code, someone can then reverse-engineer of just do an ascii DUMP of the program, obtain the target system and the user name and password and use this to attack the other system.  To me, that program is malware even if it does nothing wrong and every thing else correctly, putting credentials inside a program creates malware.

I am NOT suggesting this is something that you did!  I'm simply pointing out that malware comes in many forms.  Usually, a product like SEP would not catch what I described.  That is usually handled by vulnerability scanners and application firewalls.  And this is only an example.  So, while are programs are not "viruses" we can make security-related poor decisions in the name of ease-of-use or ease-of-coding that, while they work can be considered malicious if it is not secure.  The other thing would be using a technique in our programs that we found online but that might have OTHER uses by people writing malware.  In that case, SEP could warn of what would appear to be an attack even if we know it is not.

My suggestion would be to contact Symantec and find out what triggered the call against the program.  It is no longer something where the program itself is malware but could also be a technique you used whether it is for good or bad.

As I said, there is no criticism here of your code or your talent.  I respect other programmers.

hforman's picture

It is strange that this is being flagged by SEP 11.x. What a couple of us are talking about is SONAR and Insight since reputation was not added until version 12.x.  (Sorry, I missed that small point).  Is it possible that you are using what is actually a vulnerability in the software that may be eventually closed?  or that he customer has Heueristic settings too high?  I'm NOT suggesting that you are creating vius software by any means, but it would be intersting to see exactly why the file was flagged without a discussion of your code.  There have always been "false positives" and those may continue especially as Symantec has to narrow down the scope of what can be scanned on a signature-based level vs. reputation and heueristic means.  I apologize for not catching that this was SEP 11 in my last comment that was about 12.x.