Has Cicada's hack been corrected?

[ToddAndMargo]

Hi All,

News out there flooding the place about Cicada (a.k.a. menuPass, Stone Panda, Potassium, APT10, Red Apollo) using a DLL in VLC to spread custom malware.

https://www.bleepingcomputer.com/news/s ... re-loader/

Has this been corrected vlc-3.0.16-win64 and above?

Many thanks,
-T

[Lotesdelere]

Nothing has to be corrected but the security of your PC. Because the exploit needs an access to the target computer, nothing comes with VLC itself.

Researchers at Symantec, a division of Broadcom, found that after gaining access to the target machine the attacker deployed a custom loader on compromised systems with the help of the popular VLC media player.
Brigid O Gorman of Symantec Threat Hunter Team told BleepingComputer that the attacker uses a clean version of VLC with a malicious DLL file in the same path as the media player's export functions.
The technique is known as DLL side-loading and it is widely used by threat actors to load malware into legitimate processes to hide the malicious activity.
...
Several other utilities have been observed in this campaign include:
RAR archiving tool - helps compress, encrypt, or archive files, likely for exfiltration
System/Network discovery - a way for attackers to learn about the systems or services connected to an infected machine
WMIExec - Microsoft command-line tool that can be used to execute commands on remote computers
NBTScan - an open-source tool that has been observed being used by APT groups for reconnaissance in a compromised network

[Rémi Denis-Courmont]

This is hardly news. The CIA was exposed by Wikileaks to use almost the same trick several years ago. The Chinese services is only a marginally improved approach. The CIA and other countries intelligence services have doubtless figured it out as well already. Call me cynical, but this looks like Symantec marketing more than actual IT security news.

VLC cannot provide system security: there is no hack to be corrected. That would be the job of the hardware and the operating system. If somebody can modify your VLC installation or its installation directory, then they can do whatever they want with it.

The simplest way to protect against this type of attack is to set hard drive encryption up with a strong and unique passphrase, so you will immediately notice if somebody has replaced your operating system while you were not looking. This is not fool proof though, especially not against state-level actors.

[mfessler]

Nothing has to be corrected but the security of your PC. Because the exploit needs an access to the target computer, nothing comes with VLC itself.

Sure, the DLL must first have been placed there, but wouldn't so many software blindly (without any verification) load it, the problem would not exist.
Especially when it comes to folders that are used by several programs and/or normal users have write permissions, like the Download Folder, Temp Files (!), Export...

It is not a specific problem of VLC and depending on the point of view even comprehensible.
The eternal story... it is not our fault, on a non-compromised system there is no problem.
But that doesn't help the user...

Oh boy... my first post and a rant right away. Sorry!
Greetings,
Martin

[InTheWings]

If I sabotage your car, are you going to complain to the car maker, explaining it allows many people to touch it ?

[dont bug]

If I sabotage your car, are you going to complain to the car maker, explaining it allows many people to touch it ?

That is not the correct analogy.

The correct analogy would be, if a car picks up a Gatlin gun lying in the garage and starts firing, would you ask the manufacturer why the car picked something that did not come with the car, and even if it did want to have the feature of picking things lying around, why did it use it without confirming if it was safe?

There is a reason why system partitions have role based access privileges. On a Windows machine, it makes it a bit difficult for non admin users to start putting random things into the program folders or system folders. These checks are not available when an app can run from anywhere, like a portable app. That kind of flexibility allows for risks like side-loading of DLL if the executable willy-nilly loads DLL files or artifacts from the world-writable folder without doing any safety checks.

[Rémi Denis-Courmont]

More like if somebody planted a bomb under your wife or husband's car, and you'd blame it on the car manufacturer.

Or you bought a car from a drug dealer instead of a brand store of the car manufacturer, and complained that the car was not what you expected.

[dont bug]

More like if somebody planted a bomb under your wife or husband's car, and you'd blame it on the car manufacturer.

Or you bought a car from a drug dealer instead of a brand store of the car manufacturer, and complained that the car was not what you expected.

Again - it is incorrect analogy - either it is deliberate or erroneous. Let me assume an error of judgement and try and explain. (if it is deliberate burying of the head in sand, then obviously, all logical points are moot).

1. Planting a bomb : In such cases, the bomb itself has the ability to wreck havoc, without any support or assistance from the car. In the case of VLC, it is actively loading the unknown DLL and executing malicious code that it knows nothing about. Without the VLC executable in the folder, the malware does not work. A bomb however, will go off with or without the car. Hence this analogy is completely incorrect.

2. Car bought from a drug dealer : Had it only been such cars, you would be correct. However, if the car bought from the authorized dealership also picks up the Gatlin gun lying in the garage and starts shooting people, then we have a problem.
We are not talking about apps downloaded from shady places. It is obvious that if people download apps from non-standard or reputable places, they put themselves and others at risk. The malware problem has been documented with pristine and unmodified VLC program, so this is a strawman argument. Sideloading of unknown and malicious DLLs is a Videolan problem and it appears that all you want to do is point fingers outside without sharing anything that your team might be doing to avoid VLC being used for such nefarious activities.

[Rémi Denis-Courmont]

There is no such thing as a perfect metaphor. The point is that yours are much worse, as they point to plainly incorrect representation of the problem.

If there was a security issue in VLC, you bet that the Symantec researchers would have filed for one or more CVEs against VLC by now, and other IT security organisations would have minded than just some incompetent morons within one single country's government.

[Rémi Denis-Courmont]

And FWIW, the metaphorical car bomb is triggered by the car ignition, so the car is very much involved.

Also the official VLC releases don't pick up DLLs from random places (that bug was fixed almost two decades ago), nor do they come with trojan DLL builtins.

If you have a problem with unofficial portable VLC versions, don't install them. We can't prevent third parties making and installing unofficial portable versions.

[wisnoskij]

Just for curiosities sake, would it not be possible to create a side-loading proof app by using the full path when accessing the dll?
Not that I really think this is a overall good idea, so much old software is fixed by sideloading the correct outdated dlls, not to mention the compatibility issues with different versions of windows. But presumably somewhere in the code is something similar to `include <directx.dll>`. And this could just be replaced by `include <C:/Windows/System32/directx.dll>` and it would prevent this specific virus from working?

Not something you would want to do in general, but their might be a use for such a program in specific circumstances where security is a bigger concern than compatibility and a specific virus is running rampant.

[dont bug]

And FWIW, the metaphorical car bomb is triggered by the car ignition, so the car is very much involved.

Also the official VLC releases don't pick up DLLs from random places (that bug was fixed almost two decades ago), nor do they come with trojan DLL builtins.

If you have a problem with unofficial portable VLC versions, don't install them. We can't prevent third parties making and installing unofficial portable versions.

While I have a feeling that you are trying hard to avoid responsibility - your car bomb example is incorrect as it actually modifies the car by attaching the bomb to the ignition. Something akin to a patched or modified VLC.

Let us not discuss analogies if it makes it difficult for you to understand it, and for it is worth, none of us are discussing patched/unofficial VLC apps.

My concern stems from the apparent misrepresentation of how a pristine VLC works. Noone has apparently rebutted the findings of BleepingComputer, specifically around the malware being propagated by pristine official VLC executable.

Also, from your own documentation in the Hacker's guide : https://wiki.videolan.org/Documentation ... s_Loading/ : It says very clearly that on startup VLC scans and loads plugins and has an order of using the plugins. Nowhere does it say that the app cross checks on the authenticity of the modules and if they have malware before running them, and this appears to be the mechanism to turn it into a delivery agent for malware. Quoting from the link :

Code: Select all

How does the loading of modules happen The first time you load VLC, it will scan the default plugins directories that should contain VLC modules and generate a cache (named the plugins cache) so that the modules can be loaded quickly the next time VLC launches. Modules can be organized into directories (up to 5 layers deep) beneath the plugins directory. Recent versions of VLC require that the modules follow a specific naming convention or they will not be loaded. Modules must be named in the following format: libmodule_name_plugin.ext where module_name should be the name of your module in lower case, and ext is the system's shared library extension. For example, the http access module is named libaccess_http_plugin.dll on a Windows machine. When VLC needs a module, it tries to open the module with the highest score that has the required capability and accepts the request.

Unless you are willing to have some control and checks on code that your app runs, it will always be open to misuse. So claiming that nothing needs to be fixed at Videolan end is downright dereliction of responsibility, and you seem to be a willing accessory. FWIW, it had been pointed out to you months ago, I can see support posts where people have been worried about it and no action was taken.

[dont bug]

To be crystal clear : All everyone is asking is that when VLC/Videolan scans for, and loads modules from the folders, VLC app should check and verify that it is not malicious, before it actually runs the unknown code.

If one goes by your logic, one could argue that the default Windows OS that comes from Microsoft has no malware, so there should never be a need for Microsoft Defender or Anti-Virus programs. But we know that being cautious is the only way to prevent heartburn for the users.

[Rémi Denis-Courmont]

A piece of software cannot check its own integrity. This has been established for decades. Reflections on trusting trust was published in 1984.

Protecting the integrity of the VLC installation directories is the job of the OS. If the directories are "world-writable", then anyone can substitute the VLC executables anyway. Checking modules integrity would only make the software considerably slower for absolutely zero actual security benefits.

If you don't like it, then you're welcome not to use VLC, but pretty much all ISV software works that way too. Or you're free to use a better OS or to better configure your Windows installation so untrusted third parties can't tamper with app installation directories.

The VLC plugin directories are modifiable only by the system administration account on my computers.

[Rémi Denis-Courmont]

Bottom line: what you ask would require considerable engineering that nobody wants to pay for, considerably worsen the software performance characteristics, would not fix any actual security issue and be trivial for the malicious third parties to work around.

If you want that, fine. Fork VLC and do it yourself.

[dont bug]

So the TLDR version is that VideoLan does not want to fix it because:
(1) it requires considerable engineering,
(2) nobody wants to pay for it,
(3) any fix that you provide would likely be worked around by third parties.

As a third party, I would have assumed that keeping a centrally maintained database of whitelisted plugins would have been trivial, so that the unmodified VLC app can be sure of what it is running - but yes, it would need both engineering effort, and hence development cost, and may entail worsening of start up performance as plugins would need to be whitelisted. One query - just a thought experiment : If you did that, how 'trivial' will it be for third parties to work around that without modifying the VLC app itself (in which case the signatures of the app might change and it might be possible to flag it as compromised).

Currently, a user does not have a mechanism to confirm if a malicious DLL has been introduced into his VLC installation which can potentially be disastrous if the safe looking VLC app is executed.

PS : When Intel fixed one of the famous security flaws, it was a massive engineering effort, was a huge cost to the company and it reduced performance by as much as 30% - It might come as a surprise to you, but they did fix it despite all that, as they believed that the hit on reputation and the consumers' loss of trust was worse than all these considerations.

[Lotesdelere]

Currently, a user does not have a mechanism to confirm if a malicious DLL has been introduced into his VLC installation which can potentially be disastrous if the safe looking VLC app is executed.

Introduced into ANY program. Because this is not a VLC or any other program flaw, this is a Windows flaw to allow such exploit to occur. VLC is one of the targets because it is widely used, just like RAR is, just like Adobe Flash was.
This is not about the programs you use, this is about the security of YOUR computer. So blame Microsoft for not providing by default a protection against DLL and other executables modification and to have to rely on third party security suites.

Because this is how it works, read carefully:
https://www.zdnet.com/article/cicada-ha ... tack-wave/
https://symantec-enterprise-blogs.secur ... nt-attacks

The fix is simple: do NOT use Windows.
If you still want to use Windows then it's actually YOUR responsibility to take appropriate measures for the security of your computer since it looks like Microsoft just doesn't care enough about that.

[Rémi Denis-Courmont]

If you thought about it 10 seconds, you'd realise that only loading known plugins would simply call for malicious attackers to blame their DLL after an known VLC plugin.

And it would make it impossible to install legitimate third party plugins (which judging from this very forum, a lot or Windows users actually want).

Again, if that's how you want VLC and if it's as easy as you make it sound, you can fork it and alter it yourself. But your antifeature is not going to go into the official releases.

[dont bug]

I think it is very easy to blame everyone else like the OS does not do its job effectively, the users do not know what risks they run, users are too incompetent to know whether a malicious DLL has been placed somewhere in their folders, taxes are too high, etc.

Until you ask yourself the question : Do all Windows apps scan for and side-load **all** dlls they find?

Also - `If you thought about it for 10 seconds` : You would guess that maintaining a central database of file hashes/signatures/checksums is as trivial as maintaining the names of known VLC plugins. I mean, SHA2 is not exactly rocket science in this day and age. Installing legitimate third party plugins (which judging from this very forum, a lot or Windows users actually want) would not be an issue in such a scenario.

Finally, of course users have a choice, they may fork VLC or they may choose to go with an app which does not entail the same trust issues of side loading, as well as inability to confirm if a non state actor has compromised the installation.

And if a government bans you for possible trust issues, maybe it is an inefficient and not fully effective plan, but at least you should not go about claiming that you don't know why you might have been banned.

[Rémi Denis-Courmont]

Big talk and nothing to show for it.

All your technical argumentd were destroyed. Show us the code and the performance metrics, or this is just political support for the Indian government.

[InTheWings]

Also - `If you thought about it for 10 seconds` : You would guess that maintaining a central database of file hashes/signatures/checksums is as trivial as maintaining the names of known VLC plugins. I mean, SHA2 is not exactly rocket science in this day and age. Installing legitimate third party plugins (which judging from this very forum, a lot or Windows users actually want) would not be an issue in such a scenario.

And you are going to ask vlc to fingerprint the possibly shipped system libraries are well ?
Again you're focusing on the last chain link.

[InTheWings]

Finally, of course users have a choice, they may fork VLC or they may choose to go with an app which does not entail the same trust issues of side loading, as well as inability to confirm if a non state actor has compromised the installation.

Nah, users don't care. They want a "Free as a beer" software, not an "Open source" one.
They'll just install random junk "crap player super turbo plus" they'll find and get silently abused because those unknown ones goes under the radar.
Indian govt has made this now open bar.

We can't prevent users to install random crap. We can't prevent users to run Win XP in administrator mode.
If you really want to focus on Circada, you'll have a lot of time to waste explaining all the other projects what they should do, because there's plenty (known).

Meanwhile, there's still no official reason, just speculation and people propagating unverified information sources... Surprising !

[dont bug]

Big talk and nothing to show for it.

All your technical argumentd were destroyed. Show us the code and the performance metrics, or this is just political support for the Indian government.

That was some scope creep - Starting from "No they used a patched VLC" to "They used a unmodified executable but it side loaded malicious DLLs - nothing needs to be fixed" to "it is too difficult to fix" to "go fix it yourself" to "why did you not fix it for the world"!!!

Did you seriously expect users to recreate something like the NSRL database for you, or to recreate the functionality in Visual Studio which allows developers to create manifest files which can specify the DLL name along with its hash? I mean, these methodologies aren't rocket science either and even a lay-person like me has heard of it.

Technical arguments 'destroyed'??

I was chuckling when I saw that your understanding of maintaining a central DB for whitelisting meant keeping a repository of names/metadata of the plugins :

If you thought about it 10 seconds, you'd realise that only loading known plugins would simply call for malicious attackers to blame their DLL after an known VLC plugin.

And when I hinted at using something more robust than say names, like hashes and signatures, along with a query on how a third party would work around that without modifying the VLC binary, you seemed lost in the woods. I would be still happy to hear your ideas on this - I am sure you can destroy this argument with technicality!!

One query - just a thought experiment : If you did that, how 'trivial' will it be for third parties to work around that without modifying the VLC app itself (in which case the signatures of the app might change and it might be possible to flag it as compromised).

)

Whataboutery regarding the OS flaws is easy to do : But do not come up with disingenuous strawman arguments like whitelisting system libraries.
Did anyone ask for it?
All the suggestions were around VLC whitelisting what it is using - not what the OS is using. Let OS teams/CPU teams worry about their flaws.. and the excuse that other links might have weakness, hence there is no need to fix the link under VLC control is a rather shredded and tiny fig-leaf.

Given that you have displayed ample reluctance in ensuring that the VLC app knows what it is doing and not become a malware delivery agent, I am sure with all this time not being used to come up with ideas that could fix it, the developers put together can invest the time saved to come up with a more plausible excuse.

I think this can suffice for my daily shot of comedy - I should cancel my ComedyCentral subscription!!

PS: I have no idea why that government banned you, please do not take my word for it, I have no association with them - all I said was that given the situation, and your approach to it (which they might have known well before I was enlightened by your messages), it is not an entirely far fetched idea.

[Rémi Denis-Courmont]

That was some scope creep - Starting from "No they used a patched VLC"

Do you understand English? I wonder because I never said that this was a patched VLC. The original CIA hack that I already mentioned in my very first answer over months ago was already using additional DLLs rather than modified code.

...to "it is too difficult to fix"

Nobody wrote that. 3 different people pointed out that it is easy to fix, but that the fix lies in the system, not in the application: write-protected directories (as done on BSD or Linux) or read-only filesystem images (as done on macOS).

to "go fix it yourself"

That's only fair game when somebody claims to have an easy solution in spite of all evidences.

So, again, show us the code or we'll have to continue to assume that you're wrong.

[dont bug]

Do you understand English? I wonder because I never said that this was a patched VLC.

That was for your metaphorical car modified by linking its ignition to the bomb. I think you find your own analogies quite difficult to follow. Maybe you should not do analogies going forward if your own end up confusing you.

...to "it is too difficult to fix"

Nobody wrote that.

Looks like someone did write that, wonder who this was :

what you ask would require considerable engineering that nobody wants to pay for

What else is difficult to fix in software, if not something that takes considerable engineering and costs a bunch? Time to retake your comprehension tests?

but that the fix lies in the system, not in the application: write-protected directories

From the very beginning, this has been about state-actors surreptiously placing a malicious DLL in the victim's folder and the victim having no way of knowing something like this has happened as for all that the user can tell, the VLC app is the same unmodified binary as on the official site. Yet, when this safe looking app runs, it runs the malware without any information or alert or as much as a by your leave.

What other global problems would you like to be solved before you decide you need to fix something at your end? World poverty? Global warming? State sponsored hackers? None of them are going away. We do ask the Government to improve law and order, but we still lock our front door and not wail how ineffective that solution is.

That's only fair game when somebody claims to have an easy solution in spite of all evidences.
So, again, show us the code or we'll have to continue to assume that you're wrong.

Did I not just give you the examples of NSRL databases and manifest files with DLL hash values? Did I also not ask if it would be trivial for third parties to create a work around for that without modifying the core VLC code? You did not answer any of that probably for risk of contradicting yourself. Or, if you did not understand what these were, you could have asked and not leave us questioning your comprehension skills. A trivial solution like maintaining a central whitelist of plugin hashes need not be an easy solution - specifically why I gave the example of the Intel fix. It was a huge cost and effort for the company, but they valued their reputation and their users' trust at a level significantly higher than what you and your organisation are displaying.

If you do want to revert to this post, please ensure that you respond to the suggestion and your thoughts on the work around before anything else - repeatedly ignoring a question only buttresses the arguments against you.

Plus, users in this day and age have far easier alternatives to forking and compiling code, and maintaining the whitelist of plugins that other users might need.

Do Note - and this is the most IMPORTANT part: The only people who will suffer are the ones who have trusted the VideoLan brand and are actively looking for the VLC app for their media player needs. They will either get a suspect installer, or if they get the official installer, they will never know if their installation has been hacked by a state/non-state actor.

This causal approach towards trust issues where you do not even want to figure out ways to ensure that your app is not the one being an enabler for malware and/or being blamed for it, is symptomatic of the actual problem - It is not engineering but the value placed on users' trust.

Do note, that trust and confidence take a long time to build, and once lost, are quite hard to win back.