Warning kryptik.AB.trojan !!

hi all 🙂

What is the Problem
Something strange is going on!!!

Problem found in : ChronoForms_V3.1_RC5.5.zip

scan by ClamWin and Nod32

When will we get the stable version ? 😀

Thank you for this wonderful component 😶

After you delete this code
Does not appear warning

<?php eval(base64_decode('JGRvY3VtZW50ID0mIEpGYWN0b3J5OjpnZXREb2N1bWVudCgpOw0KJGRvY3VtZW50LT5hZGRDdXN0b21UYWcoJGhlYWRlcl9jb2RlKTsNCmVjaG8gJE15Rm9ybS0+YWRkaGFzaCgpOw==')); ?>

what this is coding encrypted!! 🤔

Hi faris3d,

There is no Trojan - no virus - nothing at all. This is a false positive i.e. incorrect report by Nod32 (ClamWin doesn't report anything for me).

Good to be cautious, but all is well.

Bob

PS Don't expect any more releases of CF 3.1, The current RC *is* the stable version (at least it's more stable than the previous stable release).

Thank you Bob 😀
Truly a work of this ChronoForms component is very cool 🙂

Note: I speak a little English

I'm having the same problem, but how do I get Chronoforms to work if ESET keeps auto deleting and quaratine my Chronoforms files. When I enable the ChronoContact plugin, my entire site is affected, but when it's disabled I can view the site, but nothing that has chronoforms associated with it. I have nightly backups and have tried to pop in a previous copy of Chronoforms, but no luck...it keeps being attacked by ESET as a Kryptik.AB.trojan...

Really stumped, any help would be greatly appreciated!

Thanks
R

Hi gypsieone,

Complain **very loudly** to ESET.

Bob

Hi GreyHead & ChronoForms developers,

I am virus researcher at ESET, and I am writing you in order to resolve the problem mentioned above.
I confirm the detection is targeted to detect the PHP obfuscation in the form used by malware in the compromised webservers. The detected code indeed has an eval+base64_decode obfuscation. I cannot understand the logic reason why you need to obfuscate the tiny fragment of your code.

The obfuscation being used cannot be considered as a copy protection, since almost every PHP programmer can restore the original code:

$document =& JFactory::getDocument();
$document->addCustomTag($header_code);
echo $MyForm->addhash();

which is already mentioned on the several places on the Internet. The solution what I propose is to put there the original code instead.

The obfuscation is making the whole script a little bit less effective, the script has to be decoded everytime the PHP file is being executed. Isn't is wiser to use more effective version of the code? The server resources are precious especially when running multiple virtual servers.

Another issue:
The is a closing ?> tag after the obfuscated code which is immediately being followed on the second line below by an opening <?php
What is the reason of such sequence? I think they could omitted. Such a trivial change would also resolve the detection problem too. Just try it.

The detection was created to primarily target a nasty malware family which a significant global problem. Dear fellow colleagues, I know you also care about server security and please consider the proposed changes. All I ask you distinguish your code from malware by modifications I hope you find acceptable. Everybody is going to benefit from them in the case you agree.

Best regards,
Daniel

Hi danieln,

Thanks very much for the post.

I checked the code and - like you - I don’t understand why Max has encoded this chunk in this way (or why that particular code is written that way). I can create a re-written file easily enough and make it available here.

Max, the developer, can hopefully include it in the distribution package in the next few days; I don't have access to that.

The remaining problem is that there are 135,000 previous downloads for which ESET will report a false positive. So I'd ask you too to look further at refining the filter discrimination so that you don't make these 'incorrect' reports.

Bob

Hi Bob,

I understand your point, I will check in the following days what can be done on our side regarding the current & older versions of the script.

Daniel

Hi Daniel and all,

I've attached a zipped copy of a modified chronocontact.html.php file that hopefully will not trigger the ESET warning.

[list=a]

Please rename the existing components/com_chronocontact/chronocontact.html.php file to chronocontact.html.php.old

then unzip the attachment and copy the new chronocontact.html.php file into the components/com_chronocontact/ folder

[/list:o]
I have run some quick tests on this and everything appears to be OK. However, I've made a lot of changes to the file code to use Joomla! methods to load scripts and stylesheets into the page header and there may be some errors. If you find anything unusual please let me know as soon as possible.

Once any obvious bugs ae fixed I'll get Max to update the download package.

Bob

PS As a small bonus this version fixes the W3C validation problem on the form action URL.

Hi Bob,

The new version is indeed undetected by ESET. Just the quick question:
There is a line:
eval (base64_decode('SFRNTF9DaHJvbm9Db250YWN0OjphZGRTKCRzLCAkeik7'));
Do you need this fragment of the code to be obfuscated?

D.

Hi Daniel,

Max would prefer that it is encoded. Happy to PM you the reasons if that helps.

Many thanks for running the check.

Bob

Hi
I had the same problem 10 days ago. (and posted ).
Sent this info to ESET (official support) , telling them the problem. ( told them to download the component and see the warning)
They reply me and confirm is a FALSE POSITIVE .
Happily today i download the component again and went OK!
(hope this info helps as many time this forum helped me)
Thanks.