Wrong techniques to obfuscate code ?
I noticed today that some very popular extension providers such as nonumber.nl (Peter provides some splendid and very useful plugins!) and Chronoforms for instance use a rather confusing technique to obfuscate code. On our hosting platform we use Configserver.com suite to enhance protection and they are awesome. However we get results from exploit scans that might (!) seem worrying. I am absolutely sure that you are all on the tip of your toes when you see in code something starting with " [eval\s*\(?( etc
Example nonumber:
(98) besdev03, Scanning /home/besdev03:
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev03/public_html/tmp/install_4cd19d0bb1856/BetterPreview-v1.6.1/files/elements/plugins/system/nonumberelements/elements/license.php'
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev03/public_html/plugins/system/nonumberelements/elements/license.php'
Example Chronoforms:
(97) besdev05, Scanning /home/besdev05:
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev05/public_html/components/com_chronocontact/chronocontact.html.php'
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev05/public_html/components/com_chronocontact/plugins/cf_paypal_api.php'
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev05/public_html/components/com_chronocontact/plugins/cf_Authorize_dotnet.php'
We all know that the Gumblar uses an almost identical regular expression regular expression ("eval\s*\(\s*gzinflate\s*\(\s*base64_decode") . This expression is marked by Configserver as a possible threat to any server "suspicious".
I quote the specialists from Configserver.com: "Genuine applications really should not be using such techniques to obfuscate code and should either encrypt it or leave it in plain text. It's up to you whether you want to accept the risk of allowing such PHP scripts to be uploaded, with the knowledge that often that regex is all that will identify an exploit." end of quote (source: http://forum.configserver.com/viewtopic.php?f=26&t=3155)
This is by no means meant to be negative towards these 2 excellent extension providers. We use them ourselves daily in our applications but my server managers are getting nervous when they receive output scans with regex similar to Gumblar on first sight.
I know all about false positives but as a general question should extension developers obfuscated code with this techniques or should it be plain text (encrypt is not acceptable in GPL) as advised by Configserver?
Example nonumber:
(98) besdev03, Scanning /home/besdev03:
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev03/public_html/tmp/install_4cd19d0bb1856/BetterPreview-v1.6.1/files/elements/plugins/system/nonumberelements/elements/license.php'
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev03/public_html/plugins/system/nonumberelements/elements/license.php'
Example Chronoforms:
(97) besdev05, Scanning /home/besdev05:
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev05/public_html/components/com_chronocontact/chronocontact.html.php'
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev05/public_html/components/com_chronocontact/plugins/cf_paypal_api.php'
# Regular expression match = [eval\s*\(?(\"\?\>\"\.)?\s*base64_decode]:
'/home/besdev05/public_html/components/com_chronocontact/plugins/cf_Authorize_dotnet.php'
We all know that the Gumblar uses an almost identical regular expression regular expression ("eval\s*\(\s*gzinflate\s*\(\s*base64_decode") . This expression is marked by Configserver as a possible threat to any server "suspicious".
I quote the specialists from Configserver.com: "Genuine applications really should not be using such techniques to obfuscate code and should either encrypt it or leave it in plain text. It's up to you whether you want to accept the risk of allowing such PHP scripts to be uploaded, with the knowledge that often that regex is all that will identify an exploit." end of quote (source: http://forum.configserver.com/viewtopic.php?f=26&t=3155)
This is by no means meant to be negative towards these 2 excellent extension providers. We use them ourselves daily in our applications but my server managers are getting nervous when they receive output scans with regex similar to Gumblar on first sight.
I know all about false positives but as a general question should extension developers obfuscated code with this techniques or should it be plain text (encrypt is not acceptable in GPL) as advised by Configserver?
-
Comment by Leo Lammerink on December 28, 2010 at 7:21pm -
Not mentioned as a wall of shame but I am flabbergasted that one of the developers who uses this obfuscation technique states on Brian's blog:
"Just to let you all know: All my extensions have been updated and no longer have base64 encoded code for the license check."
The above mentioned report from CFX is dated from yesterday on a download and install of the extension from few days ago........
I have emailed the developer (which is private correspondence and won't be published for obvious reasons) that I am very concerned with this technique and I have asked this specific developer if he is willing to change this since all server based virus and exploit scanners go into highest alert status as soon as they discover this with base_64 encoded code. That sucks since it gives the security staff a load of additional checking to do
-
Comment by Ken McD on December 29, 2010 at 10:51pm -
.
Your scan above is looking in the /tmp/directory
/home/besdev03/public_html/tmp/install_4cd19d0bb1856/BetterPreview-v1.6.1/
The current version of Better Preview is v1.8.1
The last version which included base64_decode was v1.6.2.
I found nothing in versions 1.7.0, 1.7.1, 1.8.0, or 1.8.1.
Leo the issue may be resolved by cleaning-out the old install files from the /tmp/ directory
.
-
Comment by Amy Stephen on December 31, 2010 at 9:06am
-
Thanks Ken. I appreciate hearing that.
-
Comment by Leo Lammerink on January 4, 2011 at 10:55am
-
Thanks Ken,
Late reaction but was celebrating holiday with wife/kids.
Issue is not only resolved by the /tmp cleanup but we needed on this sample site also to upgrade to the latest indeed. Thanks for notifying. I did receive a message from Peter van Westen that he is not using any longer the method. I can confirm that now indeed.
Leaves many others though such as (just examples) Chronoforms, Sobi to mention a few. These extension providers should imho follow Peter's good example.
Brian: I do know that some extensions need it and seemingly Paypal and Authorize use it as well since they turn up in the scans as well regretfully.
Comment
© 2012 Created by Amy Stephen.
You need to be a member of All Together, As A Whole to add comments!
Join All Together, As A Whole