I have just noticed that on my site now, www.your-shopping.co.uk an alert in Internet Explorer asking me to allow a Microsoft application to run which has never happened before asking to run outlook.exe,
Also in my AVG virus alert pops up with an alert to a virus,
I have viewed my source from the homepage and can notice this bit which I dont recognise and I can see the sites try to open up, any ideas?
Does anyone know if there is already a fix out there for this, is there something I should have done but haven't? (or done but shouldn't?)
splatcat
8 Oct 2007 3:15 PM
I have been waiting most of the day for some sort of response... nothing in forum or support ticket or even from phone call.....
Is it just me, am I thinking this is serious when it isn't?
Could someone please reply even if its to tell me there's nothing to worry about ( and hopefully what I can do to stop it happening again)
At the moment the shop is offline... my client is VERY unhappy and I can't seem to get a response from anyone
SajMalik
8 Oct 2007 5:40 PM
This is serious. I could not get my site to load this afternoon after working on it all morning - both public and admin - so I looked at index.php and index.html.
Both had some of the links added that Andrew lists above.
I reloaded these files and the site works again.
Surely this must be a hack that needs urgent attention?!!!
splatcat
8 Oct 2007 6:30 PM
I am talking to them now about it through the support ticket system
splatcat
8 Oct 2007 8:01 PM
If it helps these are the 3 places we found it in our instillation:
The following files have had the hack lines removed:
I have found these exploits as well. Follow the advice in the links above, you should be ok. Does anyone have or will anyone produce a CRON script that we can use on our servers to tell us what files in our production directories have been written to in a given day?
Ed
Eugene (Guest)
9 Oct 2007 9:18 AM
Yes, the update can and should be used for version 3.2
WBR,
ViArt Support Team
Eugene (Guest)
9 Oct 2007 10:09 AM
Hi,
Here are some more clarifications.
The fix of payments/ideal_process.php was issued to prevent iDEAL payment module to compromise iDEAL merchant's certificates and key if they are accessible via HTTP protocol. It has no relation to malicious code that could be found in index.php files.
This virus code is another problem that can be solved by using some antivirus software. We may confirm that standard package of any ViArt Software doesn't contain any malware and doesn't contain any code that affect merchant's or buyers' privacy.
WBR,
ViArt Support Team
SajMalik
9 Oct 2007 10:21 AM
I am sorry, I am quite confused, Eugene.
I have full anti-virus protection on my PC and I did get warnings of attempted intrusion over the weekend - I was advised that the AV had blocked these.
BUT - how does that affect my site if I do not upload any (possibly) infected from my PC?
I know that experienced programmers may understand what is going on but for those of us who are more in the customer/marketing arena sometimes need a little more clarification
Eugene (Guest)
9 Oct 2007 10:33 AM
Well,
In brief, now there are some viruses that gather FTP accounts' credentials and place a malware code on web sites that can by accessed using them. These viruses usually reside on local PCs of web masters and developers, or some other staff that have access to web sites. The only thing I can propose is to use some other antivirus software and scan PC's hard drive once more.
WBR,
ViArt Support Team
hyperconx
11 Oct 2007 7:57 AM
Eugene,
Sorry to be the devils advocate here but a script kiddie can't just write to an index file without a security hole for it to get through. What you are stating above doesn't make any sense.
The following files have had the hack lines removed:
The preceding was written into the index files by utilizing a function that writes to index files. That is how these exploits work. What you are doing here lacks accountability and it isn't a very professional practice. You might as well point up in the air and scream "Look it's Superman!"
Have you found the function that allows them to write to the index.php files?
SajMalik
11 Oct 2007 8:56 AM
Well, now, what do I do?
I have run my Norton full scan again and it reports no viruses, spyware, malware, etc. I take this issue very seriously - I may not be competent with php but I am certainly not an IT novice either.
Mine is the only PC with ftp access, Eugene.
... and, can I really not trust Norton to finds a problem?
SajMalik
11 Oct 2007 8:59 AM
Oh, and by the way, my PC also has access to my other shop which is on a different server — and that one has not suffered this problem.
If it were local PC based why would the hack not seek out all my ftp's?
hyperconx
11 Oct 2007 9:28 AM
One thing I notice is that parent and child files aren't defined such as is done with some other good CMS engines out there.
Any file that will be accessed via the web is a parent file and includes this at the top of the script:
// Set flag that this is a parent file
define( '_VALID_PARENT', 1 );
Now on any dependencies or include files that are NEVER accessed via the web begin the script with this:
// Check the parent flag
defined( '_VALID_PARENT' ) or die( 'Restricted access' );
This will keep script kiddies and hackers from using your includes as functions without being called from a valid parent script.
------------
Also I can see in the various scripts something like this:
include("./admin_config.php");
include $root_folder_path . "includes/common.php");
Since it seems that common.php loads up your check_admin_security("xyz") function wouldn't something like this be a little safer:
include("./admin_config.php");
include($root_folder_path . "/includes/common.php");
check_admin_security("xyz");
Then give them access to the rest of the includes after the security test.
-----
Also might be good to include a blank index.html file for those web hosts out there that have directory indexing turned on. Shame on them.
-----
Now to speak as a ViArt advocate. The preceeding hacks that wrote to your index files could also be a non-secured web server or non-hardened PHP install. The security of PHP BEGINS with your web host. Here is a prime example.
Web host has a basic default installation of PHP on an Apache server. Very common install. PHP writes temporary files into the /tmp directory. Also very common. The web host being some schmo right out of college doesn't know better than to format their /tmp directory so that it doesn't allow executable permissions. Along comes 80% of the free PHP scripts out there that allow for file uploads. Where do these upload but the /tmp directory. The script allows them to upload a PHP file even though the upload is only supposed to be for image uploading purposes. WHAM! You now have a PHP file uploaded and ran from the /tmp folder that grabs a trojan from anywhere off of the Internet placing it also in the /tmp folder and your server has been exploited and people are running around with your credit card numbers and logins.
% of web hosts that have unhardened installs of PHP on Apache - 80%
% of web hosts that are too schmo to format their /tmp and /var/tmp folders properly - 30%
% of web hosts that don't run a software firewall to protect the world from badly written upload scripts - 90%
So if you are hosting your e-commerce site with an offshore web host or garage based web host for $6.95 a month because you are too cheap to pay more for real technicians with real experience..... DON'T GET MAD AT VIART! GET MAD AT YOUR WIFE FOR SPENDING ALL OF YOUR MONEY AND MAKING YOU SO CHEAP! Just a little joke there. Smile.
Kami
11 Oct 2007 9:52 AM
well, anyhow we're supposed to get next version tomorrow, where it is fixed, so I'd just wait for that...
SajMalik
11 Oct 2007 10:02 AM
Thank you hyperconx
As I use 1and1 and spend a good sum on a dedicated sever I can ignore the bit about my wife's spending )
I am afreaid that this whole issue is not a joke even though I do appreciate the good intention.
Hopefully Kami is right and Viart will ensure our safety [smile?]
Chris
hyperconx
11 Oct 2007 10:25 AM
Where does it say they identified what needed fixed? Just because they are fixing the ideal_process.php script doesn't mean that the vulnerability that allowed the writing to your index.php files will be fixed. The Iframe and the ideal_process.php are two completely separate issues.
Dedicated servers aren't always the answer. Actually sometimes it is worse because the host figures there is only one person on the server so they lower their security standards thinking they need less protection.
hyperconx
11 Oct 2007 10:58 AM
I think I need to make some better sense out of this all for you. The link Eugene gives above about the IFrame vulnerability is a farse when given in this context. Sorry Eugene. People will be infected BY your website due to this vulnerability. That is what that link is about; the aftermath.
The fact that your website is being IFrame written in the first place is the real issue. Especially as it turns your website into the "Bad Guy" that is infecting other peoples' machines should the IFrame src lead the end user to an infection.
I can't tell if the src in this case is an infection or not. I have tried loading it up in a nice safe Lynx browser but only get <<< as output. Kind of useless and I certain am not going to tempt fate and load it into a regular browser. Besides I don't need to. It isn't about the end result at all but rather the origin of the issue. Something is allowing outsiders to write to the index.php files.
Experience is telling me that it is one of the functions that either moves and writes templates, edits files within the admin program, or an upload function reading in the page and uploading it with the change. These are typically where these sorts of vulnerabilities are found.
Tell me a little about your systems, Windows servers running IIS, Apache version, PHP version, SQL version, etc. Lets look for some common ground and work up from there.
hyperconx
11 Oct 2007 11:23 AM
One last post before I retire for the evening. Was the index.php file being written or was it the index.html file that the php reads in? In other words, when you folks deleted those iframe lines what file were they residing in?
I have looked around and the only functions I see that ViArt uses to write to files wouldn't be vulnerable with the exception of those that contain the fwrite functions. A list of those files are below:
Has anybody checked their logs to see if any of these were directly accessed from the outside world? Compared any time of access to the file modification time of the file that contained the iframe? Did your host recommend or assist you in doing this before you modified the file losing the timestamp forever?
