Serious Discussion Three Unpatched Vulnerabilities Plague Comodo. Documented Online.

Would you use vulnerable and outdated software, when alternatives exist?

  • Yes

  • No

Results are only viewable after voting.
Status
Not open for further replies.
piquiteco said:
@rashmi Why don't you play Superman? :) Or maybe you want to tone it down like 0Pathy. Like, you activate ARP blocking, block PowerShell to prevent attackers from delivering Metasploit payloads, another thing would be to monitor that folder ../../../ProgramData/Microsoft/Windows/Start Menu/Programs/Startup/ maybe you have another card up your sleeve? (y)
Click to expand...
I currently have separate Eazy Fix screenshots for Comodo and AndyFul's Tools. Andy's Tools are excellent, and I might consider making a permanent switch from Comodo to H_C Tools.
 
  • Like
  • +Reputation
Reactions: Khushal, Moonhorse, Sorrento and 3 others
piquiteco said:
@Trident How awful of Comodo. It's been a month since this was posted on 7 July 2025. That was the most terrible thing to read: "Comodo has not responded to attempts to disclose vulnerabilities." Was Comodo not going to pay the reward for the discovery, or is it just sloppy?
Click to expand...
Comodo is not running any bug bounty programmes so neither it will fix the vulnerability, nor it will reward the person who discovered it.
 
  • Like
  • Hundred Points
  • +Reputation
Reactions: Sorrento, ForgottenSeer 116559, simmerskool and 4 others
@Trident @rashmi Now I'm going to rest. Good night, good morning, or good afternoon to all of you and all MT members who follow us. Rest too if it's time, of course, health comes first. We'll talk tomorrow. Thank you both for keeping me informed. Hugs! ;)
 
  • Like
Reactions: simmerskool and rashmi
I'm going to say this comodo got so bad with development even languy99 gave up on it that speaks volumes. The windows xp days was comodo's time to shine and bring the company up but comodo has been walking in "dirty underwear" ever since and has not "changed" quality wise.
 
  • Like
  • Hundred Points
Reactions: Sorrento, simmerskool and ForgottenSeer 67091
piquiteco said:
What a shame, just because I was ✍ my manifesto, you replied, perhaps to mitigate this vulnerability?
Click to expand...
I didn't get you.

piquiteco said:
@rashmi Why don't you play Superman? :) Or maybe you want to tone it down like 0Pathy. Like, you activate ARP blocking, block PowerShell to prevent attackers from delivering Metasploit payloads, another thing would be to monitor that folder ../../../ProgramData/Microsoft/Windows/Start Menu/Programs/Startup/ maybe you have another card up your sleeve? (y)
Click to expand...
I prefer Comodo with minimal tweaks. Configuring Comodo is troublesome; for example, enabling scripts makes it kinda impossible to whitelist some files. I can strengthen Comodo with some advanced configurations, but the proactive configuration and some tweaks are sufficient for my usage. Anyway, I'm enjoying H_C Tools and may permanently switch to them.

piquiteco said:
Is Eazy Fix, which you mentioned, a snapshot program? Similar to RBX? Or did I misunderstand?
Click to expand...
Yes, Eazy Fix, a snapshot program similar to RollBackRx.
 
  • Like
  • Thanks
Reactions: piquiteco, Sorrento and simmerskool
Victor M said:
DLL hijacking can be countered. You check your PATH for writable directories. You make sure the app's own directory where their dll's reside is not writable.
Click to expand...

Such attacks often do not use the PATH environment variable. They can usually trick users into downloading a benign, vulnerable portable application with a weaponized DLL (side loading) or by adding a weaponized DLL with a file name of a system DLL (search order hijacking). The attack happens in the current application directory. There are also some other stealthier methods (not so popular).
 
Last edited:
  • Like
  • +Reputation
Reactions: Sorrento, Victor M, simmerskool and 2 others
Trident said:
Comodo is not running any bug bounty programmes so neither it will fix the vulnerability, nor it will reward the person who discovered it.
Click to expand...
dragon spinner GIF
 
  • HaHa
  • Like
Reactions: piquiteco, rashmi, Sorrento and 4 others
Andy Ful said:
by adding a weaponized DLL with a file name of a system DLL (search order hijacking)
Click to expand...
So search order hijacking depends on have their malicious DLL in the PATH var ? So I made every PATH dir non-writable. Or did I mis-understood what search order hijacking means ?
 
Last edited:
  • Like
Reactions: rashmi and Sorrento
Victor M said:
So search order hijacking depends on have their malicious DLL in the PATH var ? So I made every PATH dir non-writable.
Click to expand...
In programming as you know, there is this concept of breaking down code to small chunks. For various reasons, nobody wants one long pile of spaghetti code.

The code is broken down across many executables and modules.

For the software to know which module it has to load from where, the following is possible:
  • You can write hardcoded paths set in stone. It can be written in the registry, in various files like ini, in the executable logics. This is HIGHLY undesirable for various reasons.
  • Potentially, I can write the installdir and various other directories needed for functionality, then construct the paths in real time.

The other way to do it, is to just specify the name of the module that needs to be loaded. Windows will then go around looking for module with this name in this order:
  • The Application's Directory: The folder where the application's executable (.exe) is located. This is the primary location attackers target
  • The System Directory: C:\Windows\System32
  • The 16-bit System Directory: C:\Windows\System (mainly for legacy reasons)
  • The Windows Directory: C:\Windows
  • Directories in the PATH Environment Variable: The folders listed in the system's PATH variable, searched in order.
  • The Current Directory: The directory from which the application was launched.

So let's say that my portable application TudaPlayer has TudaPlayer.exe and ccCodecSupport.dll.
TudaPlayer is a very popular and widespread app that I've signed submitted to AV vendors as well. Most of these vendors now trust TudaPlayer, potentially excluding it from behavioural monitoring as well (some AVs do not monitor trusted and prevalent apps).

When I've been writing TudaPlayer, I couldn't have placed hardcoded variables/constants with the module paths - it is a portable app, I don't know where you will download and extract it.

Attacker replaces ccCodecSupport.dll with a fake copy that performs malicious actions. These actions are now hidden behind my trusted app and potentially, the AV has a blind spot.
There is very little you can do to prevent this. To make things more exciting, attacker can create subdirectories, something like "Resources" and place a few fictional files, along with the real DLL. Attackers can load the real DLL through instructions in the malicious one. In this case, the player will function.
Assuming that ccCodecSupport.dll is not signed, SAC could block its loading.
 
Last edited:
  • +Reputation
  • Like
Reactions: piquiteco, simmerskool, Andy Ful and 4 others
@Trident
Trident said:
Attacker replaces ccCodecSupport.dll with a fake copy that performs malicious actions. These actions are now hidden behind my trusted app and potentially, the AV has a blind spot.
There is very little you can do to prevent this.
Click to expand...
You can make sure that the app directory is not writable by users group, only by administrators group. So the adversary cannot overwrite ccCodecSupport.dll. But maybe portable apps are meant to be deployable by end users who are not admins. I never quite get the advantages of portable apps. Sorry but I am an IT N**i :)
 
Last edited:
  • Like
Reactions: piquiteco, simmerskool, rashmi and 2 others
Victor M said:
@Trident

You can make sure that the app directory is not writable by users group, only by administrators group. So the adversary cannot overwrite ccCodecSupport.dll. But maybe portable apps are meant to be deployable by end users who are not admins. I never quite get the advantages of portable apps.
Click to expand...
It can be anything, it can be a fictional software installer as well. Attacker is not gonna try to modify installed apps. They will target apps that the user is attempting to install now. Cracked and hacked applications on not so trusted websites would be the golden mine.

The attacker will exploit the trust in the installer (which has been ran times and times again) and will perform whatever they wanna perform on the side. Making application directories not writeable is not a good idea.
What will happen when there is an update and the updater wants to modify files in this directory?

System hardening is a good idea when it remains that — hardening. When it turns to system breaking, this is not what you want.

However, behavioural blocking and anomaly detection can detect DLL sideloading. Potentially, the malicious DLL could be identified by anti-malware.
Behavioural blocking can create reports both locally and on the cloud, of what the application is normally trying to load (metadata of the modules and so on). The malicious DLL likely won’t match that and becomes anomalous.
 
Last edited:
  • Like
  • +Reputation
  • Hundred Points
Reactions: piquiteco, oldschool, simmerskool and 4 others
Status
Not open for further replies.

You may also like...