App Review SEP PoC

[[correlate]]

Content source

https://www.youtube.com/watch?v=QIjzMQF-gbw&feature=emb_logo

Symantec Endpoint Protection (SEP) 14.2 RU2 Elevation of Privileges (CVE-2020-5837)

 

[Vitali Ortzi]

Patched in 14.3.
Can this vulnerability be exploited remotely?

No. This vulnerability can be exploited locally. The attacker should have authentication credentials and successfully authenticate on the system.

 

[[correlate]]

Patched in 14.3.
Can this vulnerability be exploited remotely?

No. This vulnerability can be exploited locally. The attacker should have authentication credentials and successfully authenticate on the system.

You can view this here.

Symantec Endpoint Protection (SEP) 14.2 RU2 Elevation of Privileges (CVE-2020-5837) - REDYOPS Labs

Symantec Endpoint Protection (SEP) 14.2 RU2 Elevation of Privileges via Arbitrary Write (CVE-2020-5837) writeup.

labs.redyops.com

 

[Vitali Ortzi]

You can view this here.

Symantec Endpoint Protection (SEP) 14.2 RU2 Elevation of Privileges (CVE-2020-5837) - REDYOPS Labs

Symantec Endpoint Protection (SEP) 14.2 RU2 Elevation of Privileges via Arbitrary Write (CVE-2020-5837) writeup.

labs.redyops.com

Well my SEP config doesn't run any kind of scan since I removed auto protect and proactive compenets further more any lolbin/script won't be able to run because of application control .
The malware won't able to access any document before accessing the fake deception honypots I put in place Wich will revel the true intentions of an attacker.

 

[MacDefender]

This still is fundamentally dangerous in that it allows an unprivileged user to gain SYSTEM-level privileges at least to create and modify files. Saying it cannot be exploited remotely (like via a zero click attack) isn't too much reassurance. This is still something you can have malware do on-device as part of their exploit, and not even using a non-Admin account can protect you.

Yes you can have layered security that makes it less likely for yourself to fall victim to such an attack (not to mention don't run untrusted binaries on your machine), but that doesn't downplay the danger that exists, where it seems like at least once a year someone finds an exploit like this in every AV.

 

[Vitali Ortzi]

This still is fundamentally dangerous in that it allows an unprivileged user to gain SYSTEM-level privileges at least to create and modify files. Saying it cannot be exploited remotely (like via a zero click attack) isn't too much reassurance. This is still something you can have malware do on-device as part of their exploit, and not even using a non-Admin account can protect you.

Yes you can have layered security that makes it less likely for yourself to fall victim to such an attack (not to mention don't run untrusted binaries on your machine), but that doesn't downplay the danger that exists, where it seems like at least once a year someone finds an exploit like this in every AV.

So true .

 

[Vitali Ortzi]

This still is fundamentally dangerous in that it allows an unprivileged user to gain SYSTEM-level privileges at least to create and modify files. Saying it cannot be exploited remotely (like via a zero click attack) isn't too much reassurance. This is still something you can have malware do on-device as part of their exploit, and not even using a non-Admin account can protect you.

Yes you can have layered security that makes it less likely for yourself to fall victim to such an attack (not to mention don't run untrusted binaries on your machine), but that doesn't downplay the danger that exists, where it seems like at least once a year someone finds an exploit like this in every AV.

Anyways project zero rekt Symantec endpoint protection and uncovered use of out dated libraries other av engine exploits and what not .
I bet that windows defender is more secure with dealing with malware then then SEP auto protect./ Proactive compenets

 

[MacDefender]

So true .

Overall I think this is why the balance between reputation / cloud intelligence, static heuristic scanning, and runtime behavior blocking is so important. Your best chance at preventing malware from doing something evil is stopping it in exactly that order above!

1. Cloud lookup just involves computing a hash of the file. If you can't do that in year 2020 without being exploited, you've got major problems.
2. Static scanning starts getting a little dangerous. Unpackers and complex parsers can have buffer overflows and other weaknesses, and this has been exploited in the past. Yet if you don't use an unpacker you have almost no chance at statically detecting obfuscated binaries or scripts.
3. Runtime behavior blocking is where you are really getting into dangerous territory. You're basically allowing the malware to execute natively on your machine, hoping that your behavior blocker has hooked and has proper detection for every potentially malicious action.

At the end of the day I think it's a difficult balance to strike. You can make an AV suite less vulnerable by doing less complex scanning but that comes at the cost of protection and means more things result in the scanner saying it's clean but on execution bad things happen (e.g. everyone who pairs BitDefender sigs with an average behavior blocker)

But in SEP's case, I think it's a little disappointing that it's simply a log file. No matter how you slice it, it is a very bad practice to be creating and deleting log files in the user's AppData directory as a SYSTEM account with kernel level privileges. It should be either using an unprivileged helper, or even better, the scanner should simply not be using system level privileges at all.

At least we can be thankful it's "just" arbitrary file write and not arbitrary code execution as SYSTEM, which has also happened in the past with many AVs.

 

[Vitali Ortzi]

Overall I think this is why the balance between reputation / cloud intelligence, static heuristic scanning, and runtime behavior blocking is so important. Your best chance at preventing malware from doing something evil is stopping it in exactly that order above!

1. Cloud lookup just involves computing a hash of the file. If you can't do that in year 2020 without being exploited, you've got major problems.
2. Static scanning starts getting a little dangerous. Unpackers and complex parsers can have buffer overflows and other weaknesses, and this has been exploited in the past. Yet if you don't use an unpacker you have almost no chance at statically detecting obfuscated binaries or scripts.
3. Runtime behavior blocking is where you are really getting into dangerous territory. You're basically allowing the malware to execute natively on your machine, hoping that your behavior blocker has hooked and has proper detection for every potentially malicious action.

At the end of the day I think it's a difficult balance to strike. You can make an AV suite less vulnerable by doing less complex scanning but that comes at the cost of protection and means more things result in the scanner saying it's clean but on execution bad things happen (e.g. everyone who pairs BitDefender sigs with an average behavior blocker)

But in SEP's case, I think it's a little disappointing that it's simply a log file. No matter how you slice it, it is a very bad practice to be creating and deleting log files in the user's AppData directory as a SYSTEM account with kernel level privileges. It should be either using an unprivileged helper, or even better, the scanner should simply not be using system level privileges at all.

At least we can be thankful it's "just" arbitrary file write and not arbitrary code execution as SYSTEM, which has also happened in the past with many AVs.

SEP has too many exploits around the AV Engine will hard pass on it till a good hardening and isolation takes place.