I have developed a windows service using C#.Net which collects data and send to my server using custom APIs on a regular interval basis with the client user's permission.
It was working fine until the user installed the anti-virus software (Kaspersky). It, false positively, detected my .exes as PDM:trojan.win32.generic, thrown away into quarantine and removed its service because I am doing web requests using HTTPWebRequest and HTTPWebResponse to push and pull data.
As for temporary, I have white listed .exes and program directory under exclusions rules in anti-virus software program settings and installed service once again. As so it is working fine for now.
But as for final solution, I want to know can we fix this within program itself (programmatically). So that any anti-virus software do not detect it as trojan or any other kind of virus as soon as my program and its service get installed.
Edit - 8th, June 2015
Earlier forgotten to mention that within service .exe it downloads its own latest .exe file to update itself. I wonder if this process is making it to appear as a Trojan.
You can apply to have your program added to the Kasperky whitelist. You may also want to apply for the Kaspersky Lab Trusted Logo.
Other anti virus solutions offer similar whitelist programs, Symantec for example.
Going through these whitelists -IMHO- is the proper way here. If your users place their trust in those solutions your making an effort to be whitelisted i.e. labeled as trustworthy by these solutions should go a long way with your user base.
Related
Has anybody had any experience of calling AMSI from ASP.NET? I have a web application that allows users to upload files, and we want to perform a virus scan on each file before we save it to the DB and make it downloadable to other users.
I have developed against Windows AMSI, and when running locally (IISExpress from VS) on my machine it works fine (my test case is that it rejects the EICAR test string in a text file).
However, when I build the application and put it onto our test server (running IIS 10) the test file is not being picked up as malware. I get all of the right return codes when initialising the interface, and scanning the file I get a valid result (of not detected).
Anybody got any ideas? I am running Windows 10 locally and the server is 2016. One thing I have noticed is that on the website it states [desktop apps only] next to supported server. Does this just mean no UWP? Or could it mean nothing running as a service either?
https://learn.microsoft.com/en-us/windows/win32/api/amsi/nf-amsi-amsiscanbuffer
Cheers,
Andy
I found the problem, after much headache. It appears that out of the box Windows Defender will automatically exclude the IIS process from malware checks. The effect of this is that the scan method doesn't reject malware.
https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-antivirus/configure-server-exclusions-windows-defender-antivirus#opt-out-of-automatic-exclusions
The automatic exclusions can be turned off.
I confirm that turning off automatic exclusions works. On Windows server 2016, using the local group policy editor, this causes AMSI to start working from IIS. On Windows 10, under Virus & threat protection, adding an exclusion for process w3wp.exe causes AMSI to stop working. So the exclusion is the culprit.
To me it is unclear why this is the behaviour. Windows Defender should not interfere with crucial parts of the operating system, at the risk of causing corruption. Having an exclude list of parts not to be scanned is understandable. So given the standard exclude list Defender will not scan the IIS process. However our route is in the opposite direction. In IIS we want to check a user upload for malware. IIS sends the payload to AMSI. AMSI sends the payload to Windows Defender. Defender should scan the payload for malware. Why does it decide: this is a request by IIS, no need to scan the payload, just return that the payload is clean? If anyone can explain this logic I would be very grateful.
We don't want to turn off automatic exclusions. This would put the production systems at risk. Exclusions are there for a reason.
We still want to use AMSI; we like the idea of a vendor agnostic interface to the locally installed virus product. We now consider the following workaround: from IIS launch a commandline exe that in turn talks to AMSI. Send the payload from IIS to the commandline process, probably using an anonymous pipe. The commandline forwards the payload to AMSI which forwards it to Windows Defender. Defender will scan the payload, as the name of the requesting process is that of the commandline and not w3wp.exe or another name in the exclusion list.
Not too happy with this approach, but it should work. We welcome suggestions for improvement.
I have several WinForm tools now. I publish them on an internal website. So my issue is that in case SmartScreen filter is turned on in IE then the users can't download them. They get "blocked" error message. If it's turned off then everything is fine, so it is SmartScreen for sure.
All the files are signed by Verisign certificates and all the file details are filled.
So the question: Ho can you make SmartScreen to trust your files, or how can you bypass it without making all the users turning it off?
Since this is an internal company tool, you should ask the company's systems administrators to deploy it for you.
It can be deployed using Group Policy, Systems Management Server or whatever management system they use.
Systems administrators have the ability to enable ClickOnce, then you can deploy it using ClickOnce.
No doubt they have other methods they use for other internal tools.
But the short answer is: You should not be trying to circumvent the protections that your company has put in place.
Instead, talk to them and they will help you find a way to get it done.
Smartscreen creates problems when you are trying to send binary files.SmartScreen responds by stating that the file is not commonly downloaded and can therefore install harmful files on your system. A common distribution trick to bypass SmartScreen warnings is to pack the installation package (Setup.exe) into ZIP-archive and distribute it that way.
I have an XBAP that needs to be able to burn cd's. When running from inside Visual Studio, everything works okay. However when running from a browser, the IMAPI dll reports that the environment is not supported as soon as it tries to access the drive.
I am assuming this is coming down to permissioning. I have a signed certificate which I have installed and the xbap is set to run as a full trust application (although I'm guessing that it can't be or I wouldn't be having this problem).
Currently this is all running on my local machine, however eventually I want this to be deployed to a web server (all users will already have the certificate installed on their clients).
Does anyone have any ideas as to what I've missed / done wrong?
Update:
I have tried creating a new, test certificate which I've installed in my certificate store and then signed the XBAP against it, but it makes no difference.
Really could do with some ideas if anyone has any?
Further Update:
I have created a console application which is able to burn cd's. Shelling out to this console application allows me to burn the cd from my xbap, but not from inside the xbap itself.
However, this is really not what I want. Ideally I want to have all this contained within the xbap. Failing that, is there a way to include the console application in the xbap's one click deployment?
Thanks
I believe this is not possible to do with XBAP. According to MS documentation on XBAPs,
Examples of permissions not available
in the Internet zone:
FileIOPermission - This permission controls the ability to read and write files on disk. Consequently, applications in the Internet zone cannot read files on the user's hard disk.
RegistryPermission - This permission controls the ability to read/write to the registry. Consequently, applications in the Internet zone cannot access or control state in the user's registry.
SecurityPermission.UnmanagedCode - This permission controls the ability to call native Win32 functions.
When you run your XBAP over the internet, you'll hit issue #3: trying to interop with unmanaged code.
I would recommend deploying your app as a stand-alone app with ClickOnce. That way, you can have full access to the system, but still get easy deployment and upgrades like you do with XBAP.
*edit*
One thing you could try -- and I can't guarantee it will work -- but you could have your users go into IE Internet Options, add your site to the trusted sites list. I'm betting then your CD burning code will work because it will be in the trusted zone, rather than the Internet Zone.
Try going to
HKLM\SOFTWARE\Microsoft.NETFramework\Windows Presentation Foundation\Hosting
in the registry
create a new DWORD named RunUnrestricted with value 1.
I wrote a C# application that is running well on my xp development machine.
When my client is running it on different PC, it seems to freeze on both vista and 7 machines.
I would like to know if there is any issue on running dotnet applications on vista/7.
I compiled the application for both framework 2.0 and 3.5 but it didn't help.
The log file neither doesn't help.
Is there any way to know where is the application freezing (of course, the client doesn't have VS for attaching to the application) ?
Thank you in advance for any help.
Pierre.
Generally, .NET application should run the same on any Windows version with .NET framework installed. Most common problem that occur are related to the new User Account Control policy in Vista and 7, which prevents applications from accessing areas requiring elevated privileges (which would otherwise run fine under an Administrator account in XP).
For example, if your application is trying to write configuration settings to the Program Files folder (which is a really bad idea, btw), or is using some hardcoded disk or registry paths instead of environment variables provided in .NET classes, it may fail under Vista.
To quickly check if this is an UAC privilege problem, try to run the application as an administrator (have your client right click the .exe file and select Run as Administrator). If it works, then this suggests that you need to examine your code and update it to make sure you are only accessing allowed areas.
Check this link for more information: Making apps UAC aware.
As redsquare suggested, the best way to test your application in a variety of Windows systems is to run them in several virtual machines (MS Virtual PC or VMWare Player, both of them free for download).
You do not give much information in order for us to help a great deal.
I would start by trying to recreate the issue locally on a virtual machine (vista one available here) and then profiling the app with something like memprofiler.
Ask your client to capture a process dump using Windows Task Manager,
In Task Manager, find the process that hangs.
Right click and capture a memory dump.
Then you can do some analysis on the dump to see why it hangs.
If you are not familiar with dump analysis, find someone who can help or open a support case via http://support.microsoft.com
csharp applications are supposed to run on vista/win7. This is their home:)
Your problem is not the OS. its your application.
Most probably the application is looking for a file, a folder, something on the client side that is not there and its freezing. this is my experience.
Check for project independencies and make sure you have shipped to your clients everything your project needs.
and last, distribute to one client the debug version with debug messages enable and get the feedback from their system.
I've got an app that publishes and updates from an http update location (I publish to the ftp site of the host, and update from the website).
The publish.htm page is very handy as I can install the app on any machine, anywhere without needing media. The problem is, so can anyone else. How can I secure the update location so that only authorized users can install the app without buggering the auto-update feature of clickonce?
Is this an internal application? If so you could just exclude the publish.htm page from your deployment. Then to install you would then just use the application manifest link http://yoursite/YourApplication.application which should kick the install off, this would not affect automatic updates. This may be just enough obfuscation to for your purposes.
Failing that you can dynamically generate the application manifest using a little bit of asp.net which would only produce the manifest for the users you want. The other benefit this has is that you can isolate a small group of users when rolling out a new version.
Just a thought.
If you're still transferring over HTTP, it's as easy as running a traffic sniffing program like Wireshark to see where the application is downloading from. To evade this you'll need to make sure to transfer over HTTPS, on top of whatever obfuscation you do to hide the update location.