Starting yesterday morning, I’ve not been able to open secure telnet connections using SecureNetTerm www.securenetterm.com. I troubleshooted the situation with local sysadmins and SecureNetTerm support by putting the server SSH daemon in debug mode and reviewing network traffic captured during a connect attempt. Opening secure telnet connections using putty works just fine. I finally noticed that the cmdagent.exe started using CPU cycles as soon as I initiated a connect attempt and then stopped using CPU cycles once the program gave a connect error and then closed. I’m pretty sure the culprit is Comodo’s AV as I can connect successfully if I change the real time scanning from stateful to disabled.
I’d like to find out why the AV started blocking secure telnet connections using SecureNetTerm on Monday and how I can connect w/o having to disable the AV everytime I want to open a new connection.
Here is information about my configuration:
only AV installed; no Comodo Firewall installed; Windows Firewall not running either
running AV 5.3.181415.1237 w/virus version 8064 (updated this morning); checked for updates under the More tab and none were found
Could you provide us a screenshot of your AV logs (CIS → AV → View AV event) and you could meanwhile try to add this in exclusion and see if this helps.
I don’t get any warning message or window from Comodo. All I get is an error dialog from SecureNetTerm indicating there was an unknown error during a connect attempt with an OK button.
And, there are no firewall, Defense+ events w/in the last month. There are only what seem to be normal tasks listed in the task launched log and configuration changes that I’ve made today and yesterday.
Stateful, scan memory on start unchecked, auto quarantine unchecked, auto update virus db checked, show alerts/notification messages checked, heuristics low, do not scan files larger than 40 MB, keep alert for 120 seconds.
I’ve only used Comodo AV on this machine starting with version 3.x. 5.x was installed late Oct. I seem to remember having problem with an avupdate that got stuck and remember doing a clean install sometime last year.
Just to reiterate, there was no connect problem on Friday and started having problems on Monday morning. What changed? The only thing I can think of is that something in the AV DB changed causing this exe to be flagged. Looking at the AV Event history, SecureNetTerm.exe was flagged on 11/2/2010 and 12/17/2010 by the AV process as malware Heur.Packed.MultiPacked@-1 during the detect action. I then remembered that I submitted SecureNetTerm.exe for review on 11/2/2010 according to the Submitted Files tab under Unrecognized Files.
Maybe Comodo still hasn’t reviewed the submitted file? or they came to the wrong conclusion?
Is it trying to load plugins or something as these are located in …\temp I suspect the tool to use a plugin that get’s blocked or it’s trying to auto-update which get blocked.
Can you expand the full path of the “utility” that is show in the screenshot, and do you know if that tool is related to the SecureNetTerm client?
I don’t believe the tool has any plugins and updates are manual uninstall/re-install for the program.
The “utility” in the screenshot is Util-2.05.js. This file is used in a web site that I help maintain and has nothing to do with the SecureNetTerm program. When doing diffs on this .js file with what is in source control, AV alerts are thrown. That’s what happened for the alerts listed in the screenshot.
Update: Wednesday, I was able to use SecureNetTerm to create telnet connections. Then, I removed the exclusion for SecureNetTerm.exe and it still worked on Wednesday to the present. I have no idea what happened, between Monday to Wednesday, but I suppose it could have been an error in the Comodo AV DB definitions that blocked SecureNetTerm.exe from creating telnet connections? But then you would have expected to see something the in the AV alerts. Oh well! At least it is working now.
could have had something to do with a memory signature or so, but it keeps being strange that no log or alert was triggered, at least glad it i seems fixed now.