TightVNC Service & port opened on 5800 installed w/GeekBuddy w/o user knowledge

Dear Comodo, and fellow security experts.

As a penetration tester and ethical hacker it has been a joy to use COMODO Internet Security in Safe Mode as it is extremely paranoid and blocks many known attacks. I have used it for many joyful years.


Upon performing a port scan of my local machine with my Kali Penetration Testing Box I was really rather alarmed to see a port 5800 vnc-http tcp/open when performing an NMAP -Ss and NMAP -St scan from within my Green segment of my local network. In fact I was darn right frightened. Having full knowledge of all the services that run on my machine such a discovery is of course not taken well.

Indeed upon telnetting to the local machine with http-vnc 5800 lit up indeed tightvnc was responding, this was a service! JESUS were my initial impressions, obviously. Upon locally connecting in a browser localhost:5800 I am directed to a message “TIGHTVNC.COM

root@kali:~# nmap -sS

Starting Nmap 6.47 ( http://nmap.org ) at 2015-05-12 02:30 BST
Nmap scan report for
Host is up (0.00020s latency).
Not shown: 986 filtered ports
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
554/tcp open rtsp
2869/tcp open icslap
5357/tcp open wsdapi
5800/tcp open vnc-http

Naturally, one may note that performing such a scan from within the GREEN zone of my network, this would be considered an almost minor absurdity. Were it not for the fact that the tightvnc service was installed by comodo internet security and this port opened without my knowledge. How could this happen? Have I been naive? Maybe but it is not very good is it.

At the very least it was unclear that the Geekbuddy service installed a remote service that would open to all local connections immediately, and this concerns me greatly.

It’s only by the stroke of luck that I had a SECOND hardware firewall between my Green and Red zone (that is to say my router and my local network hub) that port 5800 tcp was not directly exposed to the outside world, and whilst I completely appreciate that Geek Buddy is a remote assistance program that is used by comodo engineers to provide remote assistance to comodo users, I’m rather quite alarmed that the port is open and the service actively running on a permanent basis.

In fact it resembles a Back Door application. Which is what frightened me so greatly in the first place.

Surely something can be done about this, is it really necessary to leave that port exposed like that? Not what I would expect from a company such as COMODO who’s motto is “Creating Trust Online”.


I infinitely appreciate the fact that I may have been naive to not expect this opened by default, but I think you will find my point is also well made and that something should be done about this! No?

I am happy to say after removing the geek buddy in add/remove programs of my OS that the tcp 5800 http tcp port is no longer open. It would have however been nice to not have had this nasty surprise. Users and staff I am sure will be quick to correct me but I think my initial point DOES STAND!

Thank you for taking the time to read my letter and I hope it has been directed to the right place where proper attention can be given to it!

I certainly was not exposed to any kind of risk, however someone who is behind a router would be unhappy to see this port exposed and would naturally be frightened if not understanding what it is and this could be avoided by more clear message given when installing the Geek Buddy service as it were.

I can’t help but mention the user is of course one part to blame, but if this could be avoided then it would be the naturally most secure and sensible routine to actually mention what is being done in this process. Albeit my personal and professional opinion I think it not an entirely unreasonable or disparate one!

Thank you!

Best Wishes,

There is a silver lining to this in the fact that Geekbuddy is under protection of CIS making it very hard to abuse it.

Well that is nice to hear, and I felt the same after the initial shock.

There is a silver lining. Especially for me being behind a segmented network, but for all those who aren’t however I wouldn’t hesitate to add that there is no reason (that I can see) why the port and service could not be opened in the application workflow when the user requests assistance. As opposed to the port/service being open permanently from install.

Again, I do infinitely appreciate that the port needs to be open for the handshake / workflow to succeed, and also appreciate that this is probably why it is the way it is configured, nonetheless I do certainly hope that my comments do reach someone who can have a think about this at COMODO, because maybe this is something that could be remedied without too much effort.

Although - I am NOT a developer.

Nonetheless very much appreciate the reply. Thanks!

Best Wishes,

You’ve got a good point here although I don’t think the port would be needed for handshake. I would like to ask you to post your request as a wish in the Geekbuddy release topic. Then you have much better chances a Comodo developer will see it.

Nonetheless very much appreciate the reply. Thanks!

Best Wishes,

I am not a developer or employee of Comodo. I’m just an end user with common sense who happens to wear a badge.

OK going to do that now chap.

My best wishes,