The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

JS/Exploit-BO.gen

Discussion in 'General Discussion' started by groefie, Apr 3, 2007.

  1. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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.
     
  2. tAzMaNiAc

    tAzMaNiAc Well-Known Member

    Joined:
    Feb 16, 2003
    Messages:
    559
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    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
     
  3. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    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.
     
    #3 chirpy, Apr 3, 2007
    Last edited: Apr 4, 2007
  4. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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:
     

    Attached Files:

    #4 groefie, Apr 3, 2007
    Last edited: Apr 3, 2007
  5. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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
     
    #5 groefie, Apr 3, 2007
    Last edited by a moderator: Apr 3, 2007
  6. tAzMaNiAc

    tAzMaNiAc Well-Known Member

    Joined:
    Feb 16, 2003
    Messages:
    559
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Sachse, TX
    Did you check ftp xferlogs to see if they keep uploading that file to change it?

    /var/log/xferlog



    Brenden
     
  7. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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... :(
     
  8. tAzMaNiAc

    tAzMaNiAc Well-Known Member

    Joined:
    Feb 16, 2003
    Messages:
    559
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Sachse, TX
    How about the .htaccess file in that dir?
     
  9. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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:
     
  10. Spiral

    Spiral BANNED

    Joined:
    Jun 24, 2005
    Messages:
    2,023
    Likes Received:
    7
    Trophy Points:
    0
    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
     
  11. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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?
     
  12. ramprage

    ramprage Well-Known Member

    Joined:
    Jul 21, 2002
    Messages:
    667
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    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.
     
  13. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    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.
     
  14. msi200

    msi200 Registered

    Joined:
    Jul 14, 2003
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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:

    root@server:~# 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
     
  15. Kelmas

    Kelmas Well-Known Member

    Joined:
    Nov 6, 2006
    Messages:
    121
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Lithuania
    I've noticed several similar exploits some months ago. PHP is compromised here - the code is inserted during PHP script rendering, so I belive at first you should follow Chirpy's advice to set enable_dl = Off.
     
  16. ramprage

    ramprage Well-Known Member

    Joined:
    Jul 21, 2002
    Messages:
    667
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    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.
     
  17. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    enable_dl = Off in php.ini does not solve the problem. Restarted apache, but the code is still inserted in the pages. :(


    root@server [~]# 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>
     
  18. msi200

    msi200 Registered

    Joined:
    Jul 14, 2003
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    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
     
  19. groefie

    groefie Active Member

    Joined:
    May 30, 2003
    Messages:
    31
    Likes Received:
    0
    Trophy Points:
    6
    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...
     
  20. techark

    techark Well-Known Member

    Joined:
    May 22, 2002
    Messages:
    280
    Likes Received:
    0
    Trophy Points:
    16
    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.
     
Loading...

Share This Page