groefie

Active Member
May 30, 2003
31
0
156
It seems one of our servers is infected with the JS/Exploit-BO.gen exploit. Many customers get warnings of their virus scanner when they open a webpage on the server. Strange enough i can't find anything in the source of the infected pages and also rootkit scans didn't find anything.

I'm searching for this over a week now. Any idea how to find the exploit and how to fix this?

Thanks in advance.
 

tAzMaNiAc

Well-Known Member
Feb 16, 2003
558
0
166
Sachse, TX
It is at the end of your customer's page.. look at the end of index.htm index.html or index.php and remove the weird coding.

Brenden
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,453
31
473
Go on, have a guess
Most likely a php script on a users site has been compromised and a hacker has injected the worm into html files. You need to identify which site was the cause and remove the offending script.
 
Last edited:

groefie

Active Member
May 30, 2003
31
0
156
Ok, it seems the exploit adds a random javascript code to the page. When you reload the page, sometimes the code is there, after a reload it's gone and a few reloads later it's back again in the source of the page, but it has a different src name. For example the first time it adds

<script language='JavaScript' type='text/javascript' src='qixmu.js'></script>

and a few reloads later it adds

<script language='JavaScript' type='text/javascript' src='rjhzl.js'></script>

Strange enough qixmu.js or rjhzl.js are not found on the server, but the javascript adds a link 'nothing here' which links to the non existing page 'test.html' and a picture include that seems to be loaded from http:// 86.39.128.144/download/167212/file.jpg. As it's a non existing picture it places an X instead of the image. See the attachment for a screenshot of the inserted code in a page (left top of the page).

Any idea how this is possible? Maybe i have to reinstall apache? :confused:
 

Attachments

Last edited:

groefie

Active Member
May 30, 2003
31
0
156
Correction: http:// 86.39.128.144/download/167212/file.jpg exists but is not a real jpg. It has a code in it that links to http:// 86.39.128.144/download/167212/bin.exe
 
Last edited by a moderator:

groefie

Active Member
May 30, 2003
31
0
156
What uploaded file do you mean? 86.39.128.144 isn't a server of ours.

A random javascript code is injected in the customers pages. The code is not in the source of the page on the server, i've checked that in the file manager, but you can see it (not always) in the source of the page when viewing the page in the web browser. I really don't understand where the code comes from. When inserted it's always right behind the <body> tag in the page. The problem is not related to one account but to all accounts on the server so the code loads from a module i suppose.

I've rebuild apache, but the problem still exists... :(
 

groefie

Active Member
May 30, 2003
31
0
156
Nothing to find in the .htaccess-files, they all contain the regular stuff. I've checked all folders too on a few of the accounts and everything seems fine. My thought is the code (that changes by reloading the page) is injected/inserted from a vulnerable (apache) module or isn't that possible? Both php and straight html files are infected. This is very weird :confused:
 

Spiral

BANNED
Jun 24, 2005
2,018
8
193
It's not coming from your server but rather the visitor's browsers!

JS/Exploit-BO.gen filters viewed web pages on the client (browser) side
and adds the Javascript links from that side to insure continued infection
of the victim's own computer as the victim browses the web.

Nothing you need to do on your end.

Your clients need to do full virus and trojan scans on their computers
 

groefie

Active Member
May 30, 2003
31
0
156
I'm not sure of that and here's why: the past weeks we received about 25 complaints from different customers regarding to trojan warnings when they (and their visitors) visit their pages. We're running over 80 servers, all complaints are related to the same server. We noticed the problem isn't there when using the IE7 browser, in IE6 (or prior) and firefox the problem exists. Today we received 8 complaints about those trojan warnings on that server. Two customers were talking about a JS/Exploit-BO.gen warning, another one about a A0059595.exe virus.

The same server also has another trojan problem, the same as mentioned in this thread: http://www.directadmin.com/forum/showthread.php?p=94375 . The server gets over 100 post requests from different ip's (infected computers) a minute to http://193.***.***.235/trustm3now/getpr0n.php. This seems an ip related problem. The folder 'trustm3now' or the file 'getpr0n.php' are not present on the server and never were as far as we know. This problem exists about 2 months, we're using the ip over 2 years now so it can't be a problem from the past. We've talked about this with our network manager but he says there's nothing they can do about it as long as we're using that ip address.

Maybe the 2 problems are related to eachother?
 

ramprage

Well-Known Member
Jul 21, 2002
651
0
166
Canada
The javascript attack is targetting a firefox exploit in this case. I've seen this type of attack before.

Its possible the server has been rooted, I can investigate and help clean this up.
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,453
31
473
Go on, have a guess
One thing to ensure when you see things on pages that don't appear to actually be there is to make sure that you do not have PHP dynamic library loading enabled. It's another of the horrendous PHP security flaws where any any user can load a dynamic library and affect all sites on a shared server. To stop that particular issue, incase it's related, make sure you have the following set in /usr/local/lib/php.ini:

enable_dl = Off

Then restart httpd. If you allow the use of ioncube you'll have to load that from the global php.ini instead of individually.
 

msi200

Registered
Jul 14, 2003
3
0
151
Bulgaria
We are having the same problem on 2 of our servers:

Randomly, even simple pages that consist of only 1 or 2 html files randomly display a piece of javascript:

[email protected]:~# tcpdump -nAs 2048 src port 80|grep "[a-zA-Z]\{5\}\.js'"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 2048 bytes
<script language='JavaScript' type='text/javascript' src='xjrtw.js'></script>
<script language='JavaScript' type='text/javascript' src='fejrk.js'></script>
<script language='JavaScript' type='text/javascript' src='hhzhg.js'></script>
<script language='JavaScript' type='text/javascript' src='mqlmn.js'></script>
<script language='JavaScript' type='text/javascript' src='neafx.js'></script>

The code is not within the pages. It is somehow inserted before the page is displayed to the visitor.

If there is an antivirus program it prompts for a variant of Win32/TrojanDownloader.Ani.Gen trojan

Does anyone else have this problem?

Mike
 

ramprage

Well-Known Member
Jul 21, 2002
651
0
166
Canada
Yep enable_dl is one way. It can allow an attacker to add a dynamically loadable apache module - meaning a custom hack that inserts code to the visitor, upon output. So its not actually in the pages.

Restarting apache usually is a temporary fix until its loaded again. Enable_DL in php.ini is the way to go.


Also there are attacks where they change 777 files/folders and inject javascript code right into users pages. Usually with an .htaccess change as well.

Use phpsuexec to prevent these type of attacks.


There is yet another attack where they brute force customer(s) accounts, get a username/password list then they do a MASS ftp upload of the changed files with the javascript code inserted.

Make sure you enfoce a strong password policy, cpanel does. Also make sure that when you setup accounts for the first time the password is difficult. Brute force protection is what you need in this case as well.
 

groefie

Active Member
May 30, 2003
31
0
156
enable_dl = Off in php.ini does not solve the problem. Restarted apache, but the code is still inserted in the pages. :(


[email protected] [~]# tcpdump -nAs 2048 src port 80|grep "[a-zA-Z]\{5\}\.js'"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 2048 bytes
<script language='JavaScript' type='text/javascript' src='ochtz.js'></script>
<script language='JavaScript' type='text/javascript' src='jfmcy.js'></script>
<script language='JavaScript' type='text/javascript' src='gqeey.js'></script>
<script language='JavaScript' type='text/javascript' src='jikcp.js'></script>
<script language='JavaScript' type='text/javascript' src='jzaog.js'></script>
<script language='JavaScript' type='text/javascript' src='guckh.js'></script>
<script language='JavaScript' type='text/javascript' src='ncesn.js'></script>
<script language='JavaScript' type='text/javascript' src='ftnoe.js'></script>
<script language='JavaScript' type='text/javascript' src='guckh.js'></script>
<script language='JavaScript' type='text/javascript' src='tjvyl.js'></script>
<script language='JavaScript' type='text/javascript' src='eyqcm.js'></script>
<script language='JavaScript' type='text/javascript' src='dqgas.js'></script>
<script language='JavaScript' type='text/javascript' src='pesza.js'></script>
<script language='JavaScript' type='text/javascript' src='vigvo.js'></script>
<script language='JavaScript' type='text/javascript' src='ulnhz.js'></script>
<script language='JavaScript' type='text/javascript' src='efvjm.js'></script>
<script language='JavaScript' type='text/javascript' src='aqaae.js'></script>
<script language='JavaScript' type='text/javascript' src='iyuuo.js'></script>
<script language='JavaScript' type='text/javascript' src='yqqlg.js'></script>
<script language='JavaScript' type='text/javascript' src='qtwjq.js'></script>
<script language='JavaScript' type='text/javascript' src='zgmea.js'></script>
<script language='JavaScript' type='text/javascript' src='msvob.js'></script>
<script language='JavaScript' type='text/javascript' src='pfwzf.js'></script>
<script language='JavaScript' type='text/javascript' src='ugria.js'></script>
<script language='JavaScript' type='text/javascript' src='tmzzh.js'></script>
<script language='JavaScript' type='text/javascript' src='sigoe.js'></script>
<script language='JavaScript' type='text/javascript' src='kklyx.js'></script>
<script language='JavaScript' type='text/javascript' src='picxo.js'></script>
<script language='JavaScript' type='text/javascript' src='rotme.js'></script>
<script language='JavaScript' type='text/javascript' src='wtzvc.js'></script>
<script language='JavaScript' type='text/javascript' src='qqgxy.js'></script>
<script language='JavaScript' type='text/javascript' src='crlak.js'></script>
<script language='JavaScript' type='text/javascript' src='dbdnh.js'></script>
<script language='JavaScript' type='text/javascript' src='vlbrl.js'></script>
<script language='JavaScript' type='text/javascript' src='jwpkb.js'></script>
<script language='JavaScript' type='text/javascript' src='ckizj.js'></script>
<script language='JavaScript' type='text/javascript' src='ppdrb.js'></script>
<script language='JavaScript' type='text/javascript' src='ebouf.js'></script>
<script language='JavaScript' type='text/javascript' src='hilnq.js'></script>
<script language='JavaScript' type='text/javascript' src='faktl.js'></script>
<script language='JavaScript' type='text/javascript' src='vlxzf.js'></script>
<script language='JavaScript' type='text/javascript' src='icfqb.js'></script>
<script language='JavaScript' type='text/javascript' src='niyqa.js'></script>
<script language='JavaScript' type='text/javascript' src='ynrfg.js'></script>
<script language='JavaScript' type='text/javascript' src='ogtvv.js'></script>
<script language='JavaScript' type='text/javascript' src='hjrjw.js'></script>
<script language='JavaScript' type='text/javascript' src='wsshk.js'></script>
<script language='JavaScript' type='text/javascript' src='tszmt.js'></script>
<script language='JavaScript' type='text/javascript' src='ujebh.js'></script>
<script language='JavaScript' type='text/javascript' src='lgjpp.js'></script>
<script language='JavaScript' type='text/javascript' src='qttzu.js'></script>
<script language='JavaScript' type='text/javascript' src='ztxib.js'></script>
<script language='JavaScript' type='text/javascript' src='hwwwi.js'></script>
<script language='JavaScript' type='text/javascript' src='svscy.js'></script>
<script language='JavaScript' type='text/javascript' src='vdqko.js'></script>
<script language='JavaScript' type='text/javascript' src='exssw.js'></script>
<script language='JavaScript' type='text/javascript' src='hvxkg.js'></script>
<script language='JavaScript' type='text/javascript' src='nuxug.js'></script>
<script language='JavaScript' type='text/javascript' src='xdmyz.js'></script>
<script language='JavaScript' type='text/javascript' src='oxgvv.js'></script>
<script language='JavaScript' type='text/javascript' src='rjjfn.js'></script>
 

msi200

Registered
Jul 14, 2003
3
0
151
Bulgaria
Disabling dynamic linking does not help in this case.

Even plain html pages are displaying the js, which means that they are somehow intercepting the output from apache.

The files that have the code inserted are not infected themselves. Actually, the pages that display the code have not been modified in any way.

We recompiled apache, php and cpanel, but with no luck yet.

We have phpsuexec enabled, firewalls, etc, however this seems like a major exploit to me.

I am curious to see how many people have it.

Mike
 

groefie

Active Member
May 30, 2003
31
0
156
Same story here. We recompiled apache, php and cpanel as well, the problem is still there. A complete reinstall of the box seems to be the only option to get rid of this...
 

techark

Well-Known Member
May 22, 2002
280
0
316
You may be infected with a in memory process. It is loading a dynamic module in memory as Chripy suggested. If as I suspect it is killing apache for a minute or two then restarting it you will see the process does not happen right away but a few minutes later it will start up again.

The first version of this exploit I saw was called flame.so and was normally uploaded to a web site that had a weak password brute forced. Was 3 files flame.so flame.php and a index. file.

The flame.php was called by web browser from the hacker and it along with the flame.so file would start a in memory process that modified index pages and inserted code at random times.

It was based off an older hack that was a google link stealer script, one where that process would run in memory and any link that came into the server from google was directed instead to another web site normally a porn site.

The hack has grown and they have modified it a bit since the original flame.so script.
Used to a be a grep of /var/log/messages for flame would turn up the gulity pretty fast but of the host I have talked to lately that have seen this thing it is a lot harder to find now.

Some suggestions stop cron in case the have a cron file running starting the process.
Kill apache for about 2 minutes then restart watch your log files you will probably not see any code inserted into the pages then it will start again all the sudden if that is that case then you can be sure it is a file loaded on the server that is being called from somewhere remote.

Next thing to do if that is the case is to recompile apache with phpsuexec enabled and keep stopping and starting apache as I described above and watch the access_log file for common file that gets called every time when the code starts getting injected again.

Lastly if none of that helps you might want to talk to Steven over at Rack911 he has had some experience with this exploit also and has probably seen it more in the newer incarnations than I have. Or you can also try and contact Tim Green who used to be active here I think he is still head system admin at HostGator and they got hit pretty hard with this exploit about a year ago. He might lead you to some better understanding of it also.

Good luck cause it is one nasty bug.