Whirlpool

Hi Guys,

Just a suggestion that you check your site for possible infections of the adsttnmq1sdioyslkjs2 attack as it is so eloquently being called! A couple of us who are with Jumba have been compromised at around the same time earlier this week.

To check:
1. Log in to your FTP account and open your public_html folder.
2. check for any 3-4 letter directories that you have not seen before. They will be random directory like "mnz" etc. If you see one open it and see what is inside. If there is a three letter file with a php extension (mine was yur.php) and 1 or two other strange looking files then you have prob been compromised.
3. Back in the root directory of your public_html folder open up your index.html/index.php file and check at the bottom for a strange line of code – you might find your close html tags are missing too. If you have something strange in there as well as point 2 then you are definitely compromised.

Remove:
1. Remove the strange directory.
2. remove the line from the bottom of your index.php.
3. check all your pages by clicking view-source on them from your web browser – check the bottom of each file for strange html. Remove from source files as needed.

Important:
If you do find a problem please PM me and/or post your site address in this thread so that we can use strength of numbers to illicit an appropriate response from Jumba on the issue.

Thanks for the information.

Our of curiosity, which server are you on? either by Jumba name or IP... feel free to Whim me if you don't want to make it public.

I'd be interested to know if the 'couple of us' that you mention are on the same server.

mine are all fine on the wentworth server.

All my resold accounts on Stingray are fine.

How do I check which server I am on?

alboydweb.com.au is on Quoll.

http://centralops.net/co/DomainDossier.aspx?addr=alboydweb.com.au+&dom_whois=true&dom_dns=true&net_whois=true

I have posted some advice on this situation at http://forums.jumba.com.au/showthread.php?p=118929#post118929

Gary

Gary Meadows writes...

I have posted some advice on this situation

Hi Gary

I thought all shared hosting accounts were sandboxed? How is this getting from one account to the other?

Edit: Also, the article linked from your Jumba forums post seems to indicate the entry point was via the host management software (CPanel / Plesk). Is this the case here?

Gary

I understand the explanation you are providing however would your customers not consider it a fundamental requirement of your service to securely segregate one customer's site files from another on the same machine?

I'm sure a lot of your customers rely on their website as a source of income – to have their sites removed from the Google index because another Jumba customer has exposed a security hole is not going to be acceptable. Jumba must look into this further rather than shrugging your shoulders and providing an analogy about people with flu on the bus.

A more appropriate analogy – to help you understand the situation better – would you want to fly with an airline that has a track record of letting hijackers onto their planes?

Happy Noodle Boy writes...

I thought all shared hosting accounts were sandboxed? How is this getting from one account to the other?

A virtualhost in a shared hosting environment can never be completely sandboxed, to my understanding. It still needs to resources that are shared among all virtualhosts, and that inevitably leaves the door open for exploits. If an OS, or a control panel, releases a patch that closes it for a while, then of course a provider is responsible to keep these things up to date. But otherwise, the vulnerabilities are there and some folks spend *all* of their waking hours working out ways to exploit them.

Edit: Also, the article linked from your Jumba forums post seems to indicate the entry point was via the host management software (CPanel / Plesk). Is this the case here?

It may be. Highly unlikely in this particular case though. From that post, "This is much more likely a cms/ftp attack rather than an security flaw in apache or other hosting software". I daresay if the particular method used for this case was a hole in cPanel, it would have been patched by now, but we are moving towards the extent of my geekiness so I'm talking in general terms.

Gary

I had a similar XSS injection issue with Jumba a while ago. It affected both Joomla and vbulletin though has since been patched up in Vb. Joomla still has issues.

A custom php.ini seems to fix the issue with shared hosting as Jumba had allow_url_fopen on by default back then – could be still on?

Thread in question http://forums.jumba.com.au/showthread.php?t=7965

It is a good learning experience all the same.

Gary Meadows writes...

This is much more likely a cms/ftp attack rather than an security flaw in apache or other hosting software

In Blackheathsnow's other thread I recommended he contact you to see if you had FTP logs for the times at which the files were modified. Would these be able to shed light on the problem?

The advice in that esuli.it link is certainly relevant, but it doesn't help explain what the vulnerability was, it just covers it up.

I'm sure affected customers would like to know "yes, it was via FTP" or "no, it wasn't; it could be your CMS".

alboyd writes...

I understand the explanation you are providing however would your customers not consider it a fundamental requirement of your service to securely segregate one customer's site files from another on the same machine?

Only to the extent that the environment allows. If there was a more secure way of doing it, widely used applications like cPanel would have already implemented them.

I'm talking in very general terms here. Your website is sitting in a folder on a harddrive. It can only be secure to a point, when it and the files in another folder alongside it are all making use of shared resources. That just seems common sense to a non-geek like me. :)

Gary

And Gary I am concerned that Jumba will just rely on a comment from a stranger about what the likely cause is rather than investigate this themselves. Foonly is on the right track – how about opening some log files and doing some actual investigation rather than relying on the comments of someone who might not have the first clue about what the actual problem is.

That allow_url_fopen setting I would interested to know more info about re: Jumba because when you read what is happening in the php file these people put on my site – there is a bunch of fopen going on.

AzzX writes...

Jumba had allow_url_fopen on by default back then – could be still on?

It is on Stingray.

Foonly writes...

Would these be able to shed light on the problem?

Not if the code wasn't uploaded over FTP, I wouldn't think. Apache logs, perhaps?

The advice in that esuli.it link is certainly relevant, but it doesn't help explain what the vulnerability was, it just covers it up.

I agree, and there would be more information about if Google didn't routinely delete all content relating to malicious code. There used to be thousands of hit results for this, now there's a few hundred.

I'm sure affected customers would like to know "yes, it was via FTP" or "no, it wasn't; it could be your CMS".

But an affected customer may not necessarily have been the culprit. To me, telling a customer who has been affected by a situation like this to "regularly change their passwords" and to "make sure their Joomla is up to date" is just one aspect of dealing with it (and a very important one). Making sure that the OS is fully patched is another, as is maintaining updates to control panels and associated system software on the fleet.

G

Your logs would be the biggest give-away. look for urls with various url includes around the time you think the site was originally hacked. Something like yoursite.com/index.php?redir=http://xxx.xx.xx.xxx/id.php

alboyd writes...

And Gary I am concerned that Jumba will just rely on a comment from a stranger about what the likely cause is rather than investigate this themselves.

Don't be. I can assure you some great minds are at work on our servers. But this is neither the first time something like this has happened, nor will it be the last. There's only one way to completely secure a system from online attacks, and it starts with the network port. :)

G

Email received from Jumba Support:

Hi Al,

Our servers have not been compromised. We have seen this type of attack all too often where people have outdated or custom written scripts (php
etc) which can easily be exploited.

If you are running any type of CMS systems, or any php/pearl/python/javascript on your website, i would advise having them updated or locked down.

Kind Regards,

Suggested response:

Hi Al,

At Jumba we take your security concerns very seriously. We will review your site's access logs straight away and advise you of the outcome of our investigations.

Do you run any CMS or custom PHP/Pearl/Python applications on your site? If so could you please provide us details about these including version numbers. Sometimes these can be the cause of the security breach but we would like to rule this out.

Can you provide us any more information about the incident such as when the strange files appeared on your site – this will help us to narrow down our investigations.

Thanks again for being a customer of Jumba and please be assured we will look into your matter immediately.

Kind Regards,

Seewhymit writes...

Suggested retail price: alot more then your paying now.

Oh come on!

I'm also on Quoll and really appreciated Gary's reply on Jumba although I think a customer service rep might look better without a pic of him with his sunnies on. ;-)

The only thing that disappointed me in this episode is that the ticket response I got from a Jumba rep this morning said in part:

"The code you have found on the bottom of your website is almost certainly due not to password insecurity, but rather code injection using a vulnerability in the code used to make the site."

But I don't use any software like Joomla or WordPress or anything like that. Nothing at all. It seems it may have come from someone else's vulnerability with this sort of software on the same shared hosting server as me, that was using software that was badly out of date.

I guess it would just have been nice to have had an alert about this known issue so I could have actively taken responsibility for it ages ago.

So anecdotally the problem is with someone else's site on QUOLL. Now Jumba could have picked that up by now if they had paid any attention or in anyway taken it more seriously. And then they would be on their way to plugging the hole so that none of their other customer's need to catch the "cold".

But I probably should stop larking on because my contactme.php form is not secure I don't think! :( oops...

Blackheathsnow writes...

The only thing that disappointed me in this episode is that the ticket response I got from a Jumba rep this morning

Agreed. That's a bit too "stock standard" a response, when a quick check of your home folder (and the lack of any databases at all) would have indicated that there is probably isn't a CMS in use, and I'll raise that point with our tech staff.

Gary

No worries Gary. That's professional of you to say so. I don't expect miracles or instant support when I'm on shared hosting. I'm paying $10 a month not a $100 and respect the limitations of this.

Just a basic advisory of this invasive issue though, would have been helpful and could have saved Jumba and me time. Maybe there is an advisory and I have missed it.

Generally speaking, I am very happy with the service that Jumba has provided.

Don't get me wrong either Gary! I have always been a strong advocate of Jumba hosting and never had any problems! I have referred a couple of people to you as well who have also signed up.

I just feel that regardless of how little money I spend I should be entitled to a higher level of customer service than I have received via email and via you on this forum on this particular issue. I just want some sort of investigation done and as Foonly points out – how about Jumba find the culprit to block that hole rather than simply saying "oh yeh that happens all the time – you or someone else has caused the problem by exposing security holes".. it's just not good enough no matter how much you spend.

alboyd writes...

I just want some sort of investigation done and as Foonly points out – how about Jumba find the culprit to block that hole rather than simply saying "oh yeh that happens all the time – you or someone else has caused the problem by exposing security holes".. it's just not good enough no matter how much you spend.

I'm sure the OS/apache/mysql/php developers are constantly researching ways to better lock down their apps.

I don't know enough about the technical side of what happens when code can be injected in to a website file through http, so I am talking in a general sense here. Not you/Jumba/anyone specific.

Perhaps it doesn't produce anything more obvious than someone making a normal post to a database-driven forum in the server logs. If that's the case, where do the propeller-heads start, if the operating system and other server software is fully patched/up to dates.

In saying it's been a known issue for months, I'm referring to this particular bit of code that has found its way on to websites globally for quite some time. These sorts of incidents can adopt a following by name due to the nature of what they seek to do – and that is usually to inject a link to www.abcdef.com – therefore "abcdef.com" hits the headlines.

That doesn't mean that the actual process of how *any code* is being injected in to sites is being disregarded. I just dont think the right balance of security measures versus the ability for a site to sit on a server and share resources with others (and therefore allow providers to offer "shared hosting" at all) has been reached, yet.

G

I believe this same exploit has been used for the past year or so against other big providers incl. smartyhost who had a lot of compromised servers.

Let me just say this, servers that have been compromised are ROOTED, there is no other way for these things to affect all accounts and to recur once files are cleaned out esp. if a site in question has no php content at all but simple html.

So the only solution is to reformat and install a fresh OS, lock the security down better than it was before eg. very strict modsecurity rules, php restrictions etc

If that is true I want to hear it from jumba. What do you base that statement on?

Yeah, would need more background to your comments there. What is your experience with this issue and can you post links or references to your claims?

Make sure you check your .htaccess for any code that shouldn't be there.

allow_url_fopen = Off should be a global setting but it appears not to be as this allows most http / XSS Injections – mostly script kiddy based attacks and zombie network dodgyness.

This is part of my default php.ini for both Jumba and Cove.

register_globals = off
allow_url_fopen = off
allow_url_include = off
expose_php = Off
log_errors = On
disable_functions = show_source, system, shell_exec, passthru, exec, phpinfo, popen, proc_open

and put this in your .htaccess:

<Files 403.shtml>
order allow,deny
allow from all
</Files>

alboyd writes...

If that is true I want to hear it from jumba. What do you base that statement on?

I work with servers and I've seen this before and I've done my research. This is a private (non public) root which exploits one of the major services such as apache.

The compromised files are NOT uploaded to the server or modified manually by anyone, the code is inserted dynamically by apache itself and to be able to control apache like that you need root.

The exploit is very complex and very hush-hush and is most likely perpetrated by the russian mafia.

intertubeman writes...

The exploit is very complex and very hush-hush

So you know about it and the Apache folks don't?

Don't you think that's a bit selfish?

lol I can't tell if he is taking the piss :)

The server may not have been rooted.

Accounts can be effectively sandboxed using the cPanel feature called "phpsuexec" or the newer version, "suphp". This changes the way PHP (and other code) runs so it runs as the user and not as the shared web user. Without it, everything runs as the shared web user ("nobody") and users can inspect, and thus attack, each other's files.

brianoz writes...

The server may not have been rooted.

Then why is more then one site on the Server affected?

Well apparently that's all I am going to get from Jumba on this matter. My ticket has been closed with another email explaining how I need to ensure my site is secure when using third party software (which I wasn't using at the time anyway and either was blackheathsnow who given the same line).

I've just converted my site from static HTML to Wordpress and that is now live. I'll always ensure it is up to date though and do what I can to make it secure.. I'm still concerned about a re-occurrence of this "intrusion" but I'll be more vigilant.

I'll be more vigilant than most and therefore I would be likely to pick the problem up and resolve it before my site was taken out of a google index. I just hope the rest of Jumba's customers can catch intrusions of this kind as quick – otherwise Jumba will be in a world of hurt!

Yes, I will be keeping an eye on things too. If it re-occurs or becomes a persistent problem, I would have to look at other options. As much as I like Jumba, the hassles that I went through with this event was significant.

Keep in touch alboyd, let me know if you have a re-occurence.

Foonly writes...

So you know about it and the Apache folks don't?

Don't you think that's a bit selfish?

It's not an Apache exploit per se, it's a ROOT exploit. Once the machine is rooted, apache starts serving up these bits of code with existing content. (rooted servers can be made to do anything and traces of its actions extremely well hidden)

I've never seen any company get rid of the problem without formatting and doing a clean install. Smartyhost had infected servers for more than a year and just kept restoring accounts over and over. Do a search you'll find lots of discussions on it ..goes back a year or 2, same exploit.

Thanks a lot for this thread – my site(s) have been compromised.

I have a folder in public_html called zsdge, containing a file called lms.php.

In index.php there isn't one line of code, there is almost 200 lines of code listing all different web site addresses.

So far I can't find any other .php files that contain any code they shouldn't – only index.php at the moment.

Hey mate – you with Jumba I take it? What machine are you on?

EDIT: Also Gary perhaps you would like to get your guys to make a comment on this ROOT thing? If it's possible this is your cause/solution then not only will you guys be helping your customers out by fixing it properly – it sounds like you will save yourselves a bunch of time too!

Today I noticed this exploit on one of my sites, which is hosted on AussieHQ. Are AussieHQ and Jumba using the same servers, seeing they have merged? Or is this a new issue now?

alboyd writes...

Hey mate – you with Jumba I take it? What machine are you on?

If this was directed at me, I'm on Bilby.

Andreas B writes...

Today I noticed this exploit on one of my sites, which is hosted on AussieHQ. Are AussieHQ and Jumba using the same servers, seeing they have merged? Or is this a new issue now?

Unless your on one of the old cPanel/Soho servers they have, it would be a completely different vulnerability(which makes it seem like it would be a customer level thing, not server OS/Software level).

Their Customers are probably the ones being targetted, but it's the customers with out of date software somewhere on their FTP account and weak passwords which will be the easiest to break...

Myzteriouz1 writes...

Unless your on one of the old cPanel/Soho servers they have, it would be a completely different vulnerability

I am fairly sure I am on a CPanel/Soho plan with them. So probably one of the old servers, hey? I contacted them, sure I will hear back from them, soon.

I had this exploit when I had hosting with another company, before I became a refugee last year and shifted to Jumba in Feb.

I created a cron job that fired off every hour and did a checksum on the main index.php file. If it had changed, the script replaced the modified index.php with a copy of the original and then notified me.

The only pain was when I updated the page, I had to remember to regenerate the hash for the page.

intertubeman writes...

It's not an Apache exploit per se, it's a ROOT exploit. Once the machine is rooted,

A vulnerability needs to be exploited for a rootkit to be installed (I'm assuming by 'root exploit' you're referring to a rootkit).

On a secured webserver there should be very few services running that are capable of exploitation leading to code executing with root privilages and installation of a rootkit. Like Foonly suggested exploiting apache might be an avenue but if such exploit existed you wouldn't know about it and Apache would be all over it at the first sign of unexplainable server compromises.

Man am I glad I came to whirlpool today. A friend asked me about Jumba and I stated that Yeh, go ahead they are part of the AussieHQ group, you should be right. I have just shot him a text going mate, go read this thread first...

With the miniscule amount of posts... I'd say it's actually not that large a demographic of accounts which have been compromised... It's an account level issue, and not a server wide as I've checked some sites on servers posted here that I know of and they're not affected...

Mr Stego writes...

I created a cron job that fired off every hour and did a checksum on the main index.php file. If it had changed, the script replaced the modified index.php with a copy of the original and then notified me.

That's a lot of effort when you could have simply changed hosts and amended your DNS records accordingly.

I've recently made the change to VPS-based hosting. I've had enough of the difficulties associated with shared hosting.

As Jumba doesn't do any 256MB VPS'es, I've also given them the flick.

So far, so good.

Any more problems with this issue for anyone?

Everything seems to be going fine for me now. I'm still curious exactly how it happened.

Myzteriouz1 writes...

cPanel/Soho servers

AussieHQ run lesk 8.3 on their servers with CentOS 4.5 as the OS.

There was mention back in December last year of rolling out Plesk 9 but nothing further has been mentioned since then.

alboyd writes...

Just a suggestion that you check your site for possible infections of the adsttnmq1sdioyslkjs2 attack as it is so eloquently being called!

Shouldn't Jumba do that for us as their customers?

TSP writes...

AussieHQ run lesk 8.3 on their servers with CentOS 4.5 as the OS.

There was mention back in December last year of rolling out Plesk 9 but nothing further has been mentioned since then.

Actually, they do have some old cPanel servers from AussieHosts days IIRC.

Stereotype writes...

Shouldn't Jumba do that for us as their customers?

As far as I'm aware, it falls underneath a coding issue, as it isn't a server compromisation(if it was, there'd be more then a few people complaining).

Myzteriouz1 writes...

there'd be more then a few people complaining

Somehow i don't think all of AHQ's customers visit Whirlpool, do you?

TheFamilyMan writes...

i don't think all of AHQ's customers visit Whirlpool, do you?

Nope & any business would want to close up if they did I'm sure.

5% is the rough estimate, you wouldn't want any more than that.

There was 3-4 of us from Whirlpool – I think 4 was the final number.

What percentage of Jumba customers do Whirlpoolians represent? 10% would be a little much but even at that proportion you looking at 40 sites compromised :)

Make that 5. My reseller account was affected (on Kangaroo).

I've deleted the directories, and checked all my index files for additional fluff (thankfully I found nothing).

So is this all over now?

TheFamilyMan writes...

Somehow i don't think all of AHQ's customers visit Whirlpool, do you?

However, they have their own forums also, and I know they have a huge amount of customers. I've checked a few domains I know of on the different servers and they have been fine, so it's just insecure accounts themselves being attacked, and not a server level exploit.

As I said earlier, I don't use any software like Joomla or WordPress or anything like that. My site is just a basic html and css site. So how would my account have been vulnerable? I'm just trying to learn here and understand this a bit better.

I guess it was just that someone's account was vulnerable on the shared hosting server that I'm on.

My previous password wasn't a dictionary word and was pretty hard to crack, I would have thought. My new one is even tougher.

Yeh I was the same blackheath – my password like all my password is about 16 digits and contains every imaginable combination of characters ( I don't even know any of my passwords – they are stored in keepass ). And I didn't have Wordpress or anything on my site – simply static HTML/CSS (and one pretty crappy PHP contact form). But the PHP contact form may have been open to exploitation as an emailing bot but not to write files to my directories..

I think when people are referring to it being a user fault not a system fault they are talking, as you say, about other people on the same shared server who don't take care to update their wordpress' etc

Having your CP and all its various scripts accessible via http://www.mysite.com:2082 seems like a bad idea to me. Seems cPanel has had XSS issues with auth details disclosure in the past too. So there's one thing that the host has control of.

It looks pretty strange that nobody at Jumba with more technical knowledge than the customer relations manager has weighed in on this issue yet. (No offence, Gary; nobody can know everything.)

shuriken writes...

It looks pretty strange that nobody at Jumba with more technical knowledge than the customer relations manager has weighed in on this issue yet.

They have, in support tickets/phone calls/etc with clients. For everyone that I have been able to identify who has posted here, it has either been confirmed as an FTP password leak or an SQL injection. Our techs have worked at length with some clients, going through various malware/spyware/trojan cleaning softwares till something was found.

Those with more technical knowledge don't need to waste too much time on forums when there's work to be done. :)

Gary I have had a response from your technical people and I don't believe it goes very far to explain what has happened at all. It sounds like a fob off in my opinion. On the other hand I have subsequently learnt through this thread that when your technical support responds with "caused by insecure FTP passwords" they are not necessarily pointing a finger at me – but rather other people on the server which I am sharing.

I raised my concerns previously regarding the lack lustre customer service/technical support response that I initially received so I won't harp on about that – but obviously it would be better for your guys to explain the above link a little better so as not to rub us the wrong way – especially those of us that have a good understanding of SQL injection and FTP password security...

It would also be great to hear from a technical perspective what has been done to identify the accounts which have caused the breach and what has been done to rectify their vulnerabilities so as the rest of your customers are not put at further on-going risk.

alboyd writes...

Gary I have had a response from your technical people and I don't believe it goes very far to explain what has happened at all.

When a support ticket is closed, you're invited to email feedback@ if you weren't happy with the response. There's a link in the auto-notice that comes out when a ticket is marked as resolved, with a link to follow. That will escalate the ticket to management for review.

That's the way you can get more information from us about what did or didn't happen with regards to a support issue.

Gary

Thanks Gary. I still love Jumba btw!:)

Just a little more care and attention when these issues arise and more thoughtful responses from your support people would be great!

EDIT: As small as any one customer might be now doesn't mean they won't be your biggest customer in the future. Contrary to what some people said early in this thread, I think you should always be mindful of giving a high level of customer service to all your customers regardless of their current value.

Hi

Just an update. My client's site on woylie was hacked with this same attack on 17/07. Have alerted Jumba support to the fact

+1 to Jumba intrusion.

I got intruded yesterday. Thought i'd like to point out/request everybody check the sizes of the intrusive files – all mine are 30k for a very simple php file (yep checked em..).

I'm wondering if there is compiled code in the .php files that the php parser will execute, but which will not appear in notepad???

My site is on Galah and I have a weird directory in my Public_html directory with a yqn.php file in it (8.92kb). Can't see any weird lines of code though.

I have just received an email from Jumba (Gary Meadows). This is the gist of it:
"We wish to make you aware of a client-side virus that has the potential to affect any hosted websites you have with us or any other web host.

As the threat from this virus has been evolving, we have been proactively monitoring our systems and dealing with the threat appropriately. The measures taken to date have been to reset infected customer accounts' passwords, clean infected websites, and proactively monitor for re-infection.

This is a global threat that is affecting hundreds of web hosts, and hundreds of thousands of websites. The virus, a variant of which was originally known as 'Gumblar', searches for FTP credentials stored on a client's computer, logs into the web server using those details, and modifies site files in order to propagate itself to other machines (when the infected site is viewed in a web browser)."

I have checked my Jumba site files and can't see anything suspicious but I can't access cPanel on my account (possibly another issue). This sort of attack would overcome any strength through length.

Does FileZilla have encryption on its Site Manager files?

Bill writes...

Does FileZilla have encryption on its Site Manager files?

It should... There are alot of FTP applications out there. I'd just be careful :)

Myzteriouz1 writes...

It should

Rats. Google is your friend. This is what I found. It is talking about a proposed master password for Site Manager encryption:
"Actually, even if you trust root (which you normally do) *and* encrypt your home directory, this doesn't solve the problem: Once you are logged in, any data in your home directory is decrypted on read access. This means that the FileZilla passwords are readable to any application that you start including malware that you caught by browsing some or other website. And in no time at all, "all your FTP accounts are belong to us".

Edit: The Jumba email mentioned http://www.malwarebytes.org/index.php for security against this exploit.

Only just became aware of any issue tonight – via the Jumba email. I notice my cPanel and webmail logins no longer work. The websites seem fine, though.

The email further said:
"If we detect that your account has been infected, we will reset your password and clean the infection from your hosting account. We will then notify you of the action taken and request you run the abovementioned scans on your computer once more.

Further information about this virus outbreak and our response can be obtained from the following forum thread:

http://forums.jumba.com.au/showthread.php?t=11185"

It is pleasing that they are being pro-active and helpful. It would have been nice to know whether the cPanel non-access was part of a problem or part of Jumba's security response.

Edit: I have just finished a ZoneAlarm anti-virus and spyware scan. Bit painful really because it took about 1.5h. I am now running a scan by Malwarebytes but no sausages as yet.

alboyd writes...

3. check all your pages by clicking view-source on them from your web browser – check the bottom of each file for strange html. Remove from source files as needed.

Not a good idea. An attacker could have slipped some code in there that may take advantage of a security vulnerability in your browser.

If you can ssh into the server, then perhaps you can just use a text editor to view the source. I'm not sure what the attack involves, but if they can write to disk then I'd be worried about dodgy files or programs being dumped there...

Tim.

Bill writes...

It is pleasing that they are being pro-active and helpful.

Yes, much appreciated! :-)

TimMc writes...

If you can ssh into the server, then perhaps you can just use a text editor to view the source.

run grep "iframe" public_html/* > grep.txt from the home directory... Assuming the attacks are using iframes.

Lord Ultra writes...

Only just became aware of any issue tonight – via the Jumba email. I notice my cPanel and webmail logins no longer work. The websites seem fine, though.

i did have this problem originally, see beginning of the thread but re-installed everything and reset all of my passwords with the help of jumba.

I got this new email and now my site cannot be reached via ftp but Jumba hasn't contacted me at all re new password details.

I run a Linux box at home and just to be sure I re-installed my whole system and reset all my passwords (including Jumba ftp) so why was my ftp password reset again? Is everyone getting this on certain servers?

I only install stuff from the repositories and use no script in my browser. If its client side, why have my other two sites with other hosts been running perfectly?

Nothing has been touched in my others sites at all. I've been monitoring them carefully for the last month.

I followed the instructions on their website post to reset my password but it would have been good to see these instructions in the email.

I do repeat my initial question. If I am using an Ubuntu (Linux) box with sudo as the only access to root and only installing repo software, how on earth did my system get infected?

My other two sites with other hosts have not been infected at all via this computer.

I have received a few emails:

The first was:
We have needed to do a password reset on all accounts due to a security
risk with the "Gumblar" virus.

The second contained new login details for ftp and cPanel

Edit: Those spyware and virus scanners found very little. ZoneAlarm found nothing in 1.5h of scanning and Malware in a similar scan time found three instances of a keygenerator that I already knew about for a particular software suite that I used during my TAFE course (I now use Aptana and GIMP instead), something else that was boring and some registry entry for IE that it found to be benign but I deleted anyway. Waste of money, really. All that expense buying these programs and they come up with nothing of interest!

Has anyone actually found a virus / malware on their client-side computer that would explain the password leak?

I caught the folder and password creation within an hour of it happening (just by fluke), removed it and changed passwords. But I have not found any evidence of corruption on either of the computers that I use and they are definitely not simple passwords.

The affected site is on Koala by the way.

I didn't get any emails at all. I have to repeat the question I asked over at Jumba:

So how could my Ubuntu (Linux) system infect the server I am on if Windows virii can't run on my machine?

I also ftp often to two other websites that I have with other hosts from this machine and nothing is wrong with those sites at all. No suspicious files or activity on them.

So, why would only my Jumba site have problems but not my other websites, if it was my computer that was infected?

I'm trying to make sense of this. I've posted on a Linux security forum to try and get more help.

Blackheathsnow writes...

I didn't get any emails at all. I have to repeat the question I asked over at Jumba:

I didn't get any emails until last night, 10 days after I caught the infection and removed the folder. There is no symptoms on my site any more.

I also have a number of other sites I manage (both shared hosting and dedicated servers) from my two computers and it is only the Jumba site that is affected.

I think we definitely need more information about this.

I got this email from them last night – well actually i assume it was for me since it had my email address on it – just a shame it was addressed to the wrong person.....of the opposite sex.

Yeah good one Jumba!

I had one Jumba site that I look after for a friend hacked, and another with a changed password, but no virus on my pc that I can find and none of the other sites in my FTP prog were touched.

I got this from a Linux guy who is pretty much expert on the forums he is involved with:

"It is a windows attack. It does not infect the server (at least I could not find a report where the server was infected). The compromised windows clients use ftp to upload files to the server.

Once the files are deleted from the server, the server is clean. The hack does not propagate on the server.

The way to protect the server is – delete /var/www (or similar) an restore from backup and do not use ftp.

Many sites say the best way to protect yourself is to avoid using windows and likewise I could not find any report where a Linux client was affected."

So, if he is right, and this is indeed the problem. Why were we sent a generic email that looks like it doesn't related to Linux or Apple?

Blackheathsnow writes...

"It is a windows attack.

But aren't you guys on a shared Linux server?

The way to protect the server is – delete /var/www

In this case, since it is a shared hosting server, you would be deleting /home, which is un-necessary

and do not use ftp

Good luck getting all of your web hosting customers to stop using ftp.

So what does he thinks the root cause is? FTP? Or, an FTP vulnerability?

Out of curiosity, are all affected customers on the same server?

foxx510 writes...

I had one Jumba site that I look after for a friend hacked, and another with a changed password, but no virus on my pc that I can find and none of the other sites in my FTP prog were touched.

So to clarify for people like me who don't know much about web hosting security, did the hacked site get access by finding out your username/password? Or was it done some other way?

HK-47 writes...

"It is a windows attack.

But aren't you guys on a shared Linux server?

Yeah, I'm asking some more questions re your post on a Linux forum.

HK-47 writes...

But aren't you guys on a shared Linux server?

It's a Client side attack, not a server-side :)

And there's a similar virus on OSx out there from what I hear.

HK-47 writes...

But aren't you guys on a shared Linux server?

yes they are shared linux servers

Out of curiosity, are all affected customers on the same server?

no, there are a number of servers affected, how many i'm not sure but a few have been mentioned in this thread

OZusenet writes...

So to clarify for people like me who don't know much about web hosting security, did the hacked site get access by finding out your username/password? Or was it done some other way?

As far as I know, the explanation so far has been that some malware on the client computer (ie, NOT the webserver, but your home computer) finds ftp passwords and then uploads malicious code to the affected website.

This explanation does not appear to fit all the symptoms however. It doesn't explain how a windows exploit could affect people using linux on their home computers (aka, Blackheathsnow). It also doesn't give any information as to what this exploit is or whether it has actually been detected, I can't find any malware on my computers. It also doesn't explain why only some hosts are susceptible (I have only had this issue on one Jumba shared hosting site despite managing many sites from my computers).

oops

After receiving the email from Gary and looking around the Jumba forums, feeling that I still knew practically nothing about what has happened, I looked around and pieced this together:

The Gumblar/Martuz virus uses a PHP script¹ to inject JavaScript into a webpage. The JavaScript, when run in a visitor's browser, exploits an old Adobe Reader and/or Flash² vulnerability to execute code on Windows XP or older which tries to discover FTP account passwords. It does this both by snooping on the network and by reading the config files of certain programs that store passwords in plain text, notably Filezilla. It then uploads PHP scripts to any web hosting accounts it can access and the cycle begins again.

• The virus deliberately avoids triggering its payload when the visitor's browser is Chrome or Safari because these browsers would then detect it and display a warning.
• It may rely on an Adobe Reader browser plugin, definitely relies on non-current versions of Reader and/or Flash².
• It doesn't work on Windows Vista or any non-Windows OS.
• It can't read passwords from CuteFTP. Vulnerable password stores that are targeted include those of Filezilla and DreamWeaver.

I didn't spend a lot of time on that so if you know any part of it to be inaccurate, it might help people if you rewrite that part.

¹ about 95% of the infected sites used PHP. It is not possible to say for sure if the rest sites used PHP

² Hard to find details about this, would appreciate any info.

Blackheathsnow writes...

Blackheathsnow...I got this from a Linux guy who is pretty much expert on the forums he is involved with:

I'm sure there is some merit to what he's referring to, probably a different hack/issue althogether though. This is however a linux server exploit, it's not accounts that are being compromised, servers are rooted – take my word for it.

I'm just curious to know how long before Jumba realizes it and does the only thing that can be done it for them to install fresh OSs on affected servers. It took smartyhost more than a year and in the process they lost a lot of their customers.

If it was a simple password theft, Jumba would be able to see that the affected pages are being uploaded via ftp.

righto..

Im totally confused. My cpanel passwords got changed (have since reset them). No 4 or 4 letter strange dirs, so not compromised?

However there are error_log files in the root directories – this is from Jumba?

Phuzz

phuzzy writes...

However there are error_log files in the root directories – this is from Jumba?

Usually is the case of a php file executing with some errors in it.

puzzling – never seen it before – and these are sites which have been in place for a while.

Whats more puzzling is the request to scan one's computer for malware and virus'. I'm running on a mac, which has been a clean build for the last 3 – 4 weeks.

So I find it hard to be a client side issue? Confusing..very confusing..

Yep i'm confused! Why would I scan my PC. Are you saying you think my sites are infected if that was the case shouldn't all the people who visit my sites scan their PC?

chaosmaster writes...

Why would I scan my PC. Are you saying you think my sites are infected if that was the case shouldn't all the people who visit my sites scan their PC?

If they have vulnerable password stores containing FTP logins for websites, yes they should. But if your site is infected then it's because the FTP login for your site was harvested and therefore it was probably your own client that was exploited.

Jumba or yourself should determine whether your site is infected though.

shuriken writes...

But if your site is infected then it's because the FTP login for your site was harvested and therefore it was probably your own client that was exploited.

Nope; I have the logs, the scans, and the timelines to prove it. Someone apparently infected my account, and I can definitively state that it wasn't me.

Edit: I've had a good chat with them and it's definitely possible that it was a client-side exploit that happened many months ago. Looking into the way Gumblar spreads, it's likely that my details were harvested quite a while ago before I cleaned up my security.

So maybe my login details were harvested last year when I was still on Windows? That's about the only explanation I can see.

Still doesn't explain why my other sites with other hosts are totally fine. Why only the Jumba site affected?

Blackheathsnow writes...

So maybe my login details were harvested last year when I was still on Windows?

That's assuming your site hack involved Gumblar. Does anyone have code from their Jumba-hosted site that can be identified as Gumblar?

I'm trying to work out how to get my ftp access logs, but it doesn't want to accept my password when I log in using the ftp details that cpanel suggests.

shuriken writes...

Does anyone have code from their Jumba-hosted site that can be identified as Gumblar?

The site that I look after that was hacked had a heap of hidden links inserted into the end of the index page, and a new folder in public_html with a php file in it. Couldn't find any javascript that wasn't supposed to be there.

Strange that only one of the sites of the 8 or so of my filezilla accounts was touched.

I went into my old Windows XP machine and did an Avira check, Spybot and Malwarebytes and all was well, no problems at all. Still, just to be sure, I restored a very early, bare bones Acronis image of XP and updated it to all the latest patches. Then I installed the latest Avira Free and FF3.5.

Nothing at all was detected on this old XP machine. Its behind a hardware firewall, XP firewall and has Noscript installed.

I still can't quite work out why my other sites hosted elsewhere and accessed from the same Linux machine, have remained untouched.

Yep it makes no sense that just one of the 8 here were affected.

foxx510 writes...

Yep it makes no sense that just one of the 8 here were affected.

Why is it strange? Other than the fact that we have removed all instances of the malicious code in the forms that we know it exists in, there are numerous instances of people reporting that "one of my websites got infected", which to me means others under their control haven't. I haven't seen any reports stating that it will specifically attack every site that it might be able to get hold of ftp credentials for.

Gary

Gary Meadows writes...

I haven't seen any reports stating that it will specifically attack every site that it might be able to get hold of ftp credentials for.

That seems reasonable when you first read it Gary but have we heard of ANY reports yet of people with Jumba accounts that also have other hosting accounts that are infected?

A number of us here have accounts with other hosts and none of these accounts that I know of are infected. You would think at least some of these accounts would be infected.

I also can't remember reading a post here or elsewhere, where anyone has found anything nasty on their systems when using Malwarebytes or other good quality detectors.

That seems strange.

And what about shifting to a SFTP connection instead of FTP. I understand its safer in this context?

I don't think anyone is pointing the finger here, we are just trying to save ourselves lots of work client side and understand clearly what is actually happening.

That seems reasonable when you first read it Gary but have we heard of ANY reports yet of people with Jumba accounts that also have other hosting accounts that are infected?

A number of us here have accounts with other hosts and none of these accounts that I know of are infected. You would think at least some of these accounts would be infected.

I don't understand your logic, unless you consider the world-wide issue with browser-based attacks is limited to Jumba?

The fact is that a small percentage of WP users have sites hosted with Jumba, and a small percentage of those have had one or more sites attacked. The issue itself, is much greater than that. We're just a drop in the...whirlpool.

That seems strange.

Not to me, but I'm looking at the bigger picture. If it was as cut and dry as you're implying, it wouldn't be such a widespread problem.

And what about shifting to a SFTP connection instead of FTP

I'd be all for it, though I'm not sure those who can't use port 22 would be. That, or shut down FTP altogether and force web-based uploads, like some file hosting providers do, but I don't think it would win us too many fans either.

I don't think anyone is pointing the finger here

I don't think anybody can, unless it can be proven that we've been negligent in any way. We're not doing anything that's wildly different to any other provider, we just do it better.

Gary

Gary Meadows writes...

Why is it strange?

Well to me it seems strange as I thought the aim of a virus was to infect as many machines/sites as possible, but I'm not an expert. If you say it was my fault then I'll have to take your word for it. I'm not sure what else to do though if I can't find the virus on my machine using the tool you recommended.

Yes, I'll leave this to others now. I don't want to get into a back and forth type situation here. Gary's entitled to his opinions. I don't have any concrete ones as yet – still trying to work it all out.

I might be wrong but I think there may be some confusion of issues. I think the current topic raised by jumba in recent email is quite separate to the issue that I raised in the op? Or are they the same?

Do the logs show FTP access from an unexpected source in these cases?

It doesn't need to be your own computer infected. it can be ANY computer that has had password access to the site in the past. This might be someone else with access, like staff members, contracted web designers/programmers, friends, laptops, etc.

This seems like a lot of obfuscation and very little addressing the issues here.

1. I have found evidence of hacking in my Jumba account with a directory and php code consistent with the adsttnmq1sdioyslkjs2 attack (as per the OP alboyd) on July 23. Thankfully I detected it within a few days and before any malicious code was injected into the rest of my website.

2. After alerting Jumba of evidence of hacking I receive the generic security alert email blaming the Gumblar.cn Windows-based Flash-injection virus (which is no doubt quite bad) and a client-side attack harvesting FTP passwords. Apart from this I have received no further information from Jumba. In fact they tried to close my support ticket because I didn't reply to their email saying they would get back to me when they had more information.

3. I run Mac OSX with current Sophos Antivirus (which detects the relevant virus even though I am immune to it) and I am as sure as possible that I do not have a client side virus as described by Gary and am not responsible for this compromise.

4. Despite following the instructions to reset my passwords I am still locked out of my WHM and cPanel accounts due to a brute force attack. I therefore cannot get in to download any of my logs to check what is going on.

5. It is not clear whether Gumblar and adsttnmq1sdioyslkjs2 are the same thing, but I don't think so, as the PHP code copied into my webspace looks different. What worries me more is that if this is adsttnmq1sdioyslkjs2 then it may have nothing to do with me and is due to some poor other user being compromised and infecting the whole shared hosting server as suggested by the esuli.it website:

Update: a probable answer to question 1 is that the attack is based on a flaw in the hosting management software, see comments below, and it is not related to the blogging/CMS/etc. software used by the site.

If this is something that is propagating on the server then all shared server accounts on affected servers are vulnerable (and may already be compromised), while virtual servers would hopefully be relatively protected. There is no information from Jumba whether or not this is the case but it should be pretty clear. Similarly if it is propagated on the server then accounts will be affected even without suspicious FTP logs. This should be pretty straightforward to establish but no news has been distributed about this.

6. Lastly three days ago my credit card details (as registered with Jumba) were used for an attempted >$600 charge to "alleys.com". Luckily the bank contacted us to confirm but I am highly suspicious that Jumba's customer details have been compromised. Can Jumba please confirm or deny?

It is one thing that my access is curtailed or inconvenienced while the servers are investigated and rebuilt. It is another if my customer details have been hacked. Other customers deserve to know ASAP so they can check their credit card bills.

jj28.

I have over 20 sites for myself and clients hosted with jumba and at least 5 had the adsttnmq1sdioyslkjs2 attack.
Spent a long time cleaning up etc and that was at least 3 weeks ago or more.
Have just checked and seems all cpanel passwords etc have been changed by jumba so now the headache of phonecalls to to clients jumba etc to obtain new ones and get them sent to me for acess.

alboyd writes...

Or are they the same?

They're different.

G

jj28 writes...

I have found evidence of hacking in my Jumba account with a directory and php code consistent with the adsttnmq1sdioyslkjs2 attack

I've moved your copy of this on our forum to a new thread and we can discuss that there if you're after some help in finding out how that might have happened.

Can Jumba please confirm or deny?

Your customer details with us are fine.

Gary

Folks, AussieHQ CEO Michael McGoogan has gone into some detail about the problems at Jumba:

http://www.itnews.com.au/News/151709,gumblar-mutates-into-spam-beast.aspx

We've been talking to several IT security vendors, none of which have reported a large spike in spam or Gumblar-related activity.

There is a small possibility this is a targeted attack on Jumba. But more likely, its an exploit that hits any service provider that offers FTP access to a large number of users.

B.

Gary – can you guys please send information to me (you might want to send it to your other customers too) about how I get a password reset since I have just checked my cpanel access and it's no go.

alboyd writes...

Gary – can you guys please send information to me (you might want to send it to your other customers too) about how I get a password reset since I have just checked my cpanel access and it's no go.

Login to your Billing account, and underneath Packages you should be able to set the password for cPanel there :)

Tis the same in everyone's WHMCS, so I'd say it'd be the same with theirs :)

Myzteriouz1 writes...

I'd say it'd be the same with theirs

Yep, details are posted here – http://forums.jumba.com.au/showthread.php?t=11185

bdubs writes...

http://www.itnews.com.au/News/151709,gumblar-mutates-into-spam-beast.aspx

I'd have to take exception to the "yes we're rife with it, other hosts are too but just aren't saying" speil.

From posts here, there doesn't seem to be a rash on other hosts. My talking to people doing support say yes they have seen it, but in nothing like these numbers. Not even close to 1%.

Given the fact that the infection doesn't necessarilly need to be on the clients computer and just on a computer that has access to the FTP info – plus the fact that they have clients here saying they have scanned and found nothing, and have other hosts accounts remaining uninfected – AHQ/Jumba might want to look at little more closely at why they in particular are being hit so hard, and stop the media spin pretending all hosts are seeing the same huge infection rate.

ursulasays writes...

AHQ/Jumba might want to look at little more closely at why they in particular are being hit so hard

I doubt we're being hit any harder than any sizeable provider, we just prepared to talk about it. I've only heard of a few others doing the same – http://www.webhostingtalk.com/showthread.php?p=6226835 – but essentially it's not a problem with any specific provider.

The statistics speak for themselves – http://www.securecomputing.net.au/News/150874,website-infected-every-36-seconds.aspx – there's no 'spin' on it by us.

There is a HUGE statistical difference between seeing a small % sites infected, which seems to be anecdotal of most hosts, large or small, and the 50% Michael referred to in that article. There is zero evidence to suggest any other hosts have anything like this infection rate. Saying other hosts have the problem to the extent you do and are being secretive about it instead is plain spin/damage control.

If the 50% quoted in that article is right, far more than co-incidence or bad luck is at work, there is a commonality somewhere that needs to be identified.

"The statistics speak for themselves – http://www.securecomputing.net.au/News/150874,website-infected-every-36-seconds.aspx – there's no 'spin' on it by us."

Yes lets looks at the statistics according to your article, which only serves to illustrate my point that your infection rate is WAY over the norm.

"Approximately 23,500 infected webpages are discovered every day"

is 23,500 webpages 50% of the all web pages hosted? (going by your theory that other hosts also have a 50% infection rate and aren't talking about it)? no, even multiplying the number by x days/x weeks won't get you close.

ursulasays writes...

there is a commonality somewhere that needs to be identified.

Indeed. A whole heap of it malicious code. We cleaned it off, put in some safeguards to alert us if it comes back (in a form that we're able to detect at least), reset FTP passwords to protect websites and gave clients a heads up.

If the 50% quoted in that article is right, far more than co-incidence or bad luck is at work, there is a commonality somewhere that needs to be identified.

Of course not. That's simply the number of sites that are actually being detected. Per day, not in total. They're not our figures, they're what's being put out there by reputable internet security organisations.

My points are they're certainly not all hosted by us, not too many providers have gone out on a limb over this, and that it's a client-side issue, not one to be poking any web host in the chest about.

Gary

Gary Meadows writes...

reset FTP passwords to protect websites

Were all passwords reset or just those people whose computers had been infected by Gumblar?

I have scanned my computer using Malwarebytes (as well as ZoneAlarm Security). I have checked my files on Jumba's servers. My son, who also has access, uses Ubuntu. Nothing was found. This dearth of viruses might have been because a few months ago I replaced the motherboard and re-installed the OS etc and Gumblar might have been there months ago.

Mind you, this exercise has been very useful. I have improved the security of my passwords and nuked FileZilla in favour of FireFTP that has encryption on backup passwords.

Personally I am in favour of Jumba being pro-active in securing their servers and checking the files on them for malware. Consider the alternative. This is so much better than complaining about having infected sites and the provider being lackadaisical and un-informative in their attitude.

Bill writes...

Were all passwords reset or just those people whose computers had been infected by Gumblar?

As far as I'm aware, any sites that met a broad criteria had their passwords reset. Other providers have gone ahead and reset all ftp passwords, we avoided doing that. The criteria would have included things like instances of malicious code, and the existence of certain IPs in ftp logs, that have been reported by security agencies as having hosted the payloads at some stage.

I have improved the security of my passwords

That's good, and they also need to be changed regularly. Some clients have advised that their sites have been infected yet they haven't uploaded anything in for "months". A regular routine of updating ftp passwords helps to alleviate any problems if the details were compromised on a person's system months ago. I read one report of a site being found to contain 40,000 ftp details, and the problem is only exacerbated by the number of those details that remain valid for months on end.

Gary

Hi,

Is http://yabby.cbr.hosting-server.com.au one of the affected servers,
I have had a few issues recently with sites not showing up, cannot acces it either through "My Products and Services". receiving the following message "The server at yabby.cbr.hosting-server.com.au is taking too long to respond."

I have added a support ticket for this, and also 3 other support tickets for other issues, so far have had no response, I assume everyoneis quite busy there if you had a issue.

Thanks
Richard