Community Forums
Connect with us on LinkedIn
Community Notice
+ Reply to Thread
Page 2 of 41 FirstFirst 1 2 3 4 12 ... LastLast
Results 16 to 30 of 613
  1. #16
    Member
    Join Date
    Sep 2003
    Location
    UK, Luton
    Posts
    197

    Default

    Quote Originally Posted by ramprage View Post
    iframe attacks are pretty old actually, while the method in which they're impletmented varies, the effect is the same. To gain control of a wide array of site pages at once and launch a form of spyware, adware, malware or whatever else junk they want from the page rendering using another form of Zero day hole in something like your browser.

    You really need to setup mod_security on your server with a custom ruleset. The exploit string in which you posted is really really old. Basically the attackers using a php include on a remote file that runs as if it were part of the code on the users page.

    Any clients machines I secure and configure haven't been affected by this so it must be related to a few different things.

    1) The attacker finds a hole in your users local PHP script
    2) The inject their own PHP code from a remote file making it run as if they uploade the page by regular FTP.
    3) There are numerous ways you can easily collect the usernames of accounts, very very very easy.
    4) You can start to then brute guess passwords of user accounts
    5) You can then start scouring the server for local exploits and use them to your advantage. EG: The script you metioned in that include checks to see if wget, gcc and other system binaries are on the system and asssible for the attacker to use.
    6) With a list of whats installed and what they can use, they can now download hacks and start trying to crack your machine and compiling code attempting to gain root, etc.
    7) They can search any and all 777 permission files/directories and inject whatever they feel like. Good times for them, crappy time for the site owners and server owners to clean up the mess.


    Preventing this is a combination of things that I won't go into complete details about but I'll brief over so you get the idea.
    1) Lock your system binaries, like wget, gcc, and others to stop anyone from using them.
    2) Secure PHP by disabling functions used such as: proc_open, exec, system, passthru and so on.
    3) Make sure PHP/Apache is up to date
    4) Install mod_security and have CURRENT ruleset! Mod_security through cPanel install has NO ruleset! I have rulesets I give all my clients which are tried, tested and true.
    5) Have a current kernel installed, there are many exploits that still work on a lot of providers.

    There are tons you can do to help lock your machine. If you don't know, then hire someone that's what we're here for, besides our good looks of course
    You failed to read my post entirely.

    That is what cPanel "found" on the server, but it was completely irrelevant to what was happening. Out of 800 sites on one server 60 have had the "iframe" added to them and over half of these were simply .html single page sites, with no dodgy permissions and no PHP scripting at all.

    The index files were downloaded over FTP and then 5 secs later re-uploaded. There is no manipulation of PHP or insecure scripts that is allowing them to FTP to these user accounts and the usernames are not being brute forced because there are no failed authentication attempts from the IPs that upload the amended and infected index files.

    So the question is, how have the username + passwords been obtained in the first place.
    Regards,
    James Smith
    UH Hosting Ltd

  2. #17
    Member
    Join Date
    Jul 2002
    Location
    Canada
    Posts
    675

    Default

    Quote Originally Posted by JamesSmith View Post
    You failed to read my post entirely.

    That is what cPanel "found" on the server, but it was completely irrelevant to what was happening. Out of 800 sites on one server 60 have had the "iframe" added to them and over half of these were simply .html single page sites, with no dodgy permissions and no PHP scripting at all.

    The index files were downloaded over FTP and then 5 secs later re-uploaded. There is no manipulation of PHP or insecure scripts that is allowing them to FTP to these user accounts and the usernames are not being brute forced because there are no failed authentication attempts from the IPs that upload the amended and infected index files.

    So the question is, how have the username + passwords been obtained in the first place.
    Probably a insecure script in one of the 800 accounts.... with this I could easily get a list of users. Or, someone signed up for malicious reasons which happens but not as often. For example, a reseller client of yours has a automated account signup script...

    If I compromise a single PHP script on a server I can get all the user accounts and start digging in users directories as well. Users usually make their account login password the same as MySQL passwords, etc.

    As you can see, i'm just trying to offer suggestions and show you how easy getting into a system is.
    Last edited by ramprage; 01-24-2007 at 11:45 AM. Reason: changes
    Upload Guardian 2.0 - Sign up for our early beta
    ServerProgress - Server security, consulting and assistance

  3. #18
    Member
    Join Date
    Sep 2003
    Location
    UK, Luton
    Posts
    197

    Default

    Quote Originally Posted by ramprage View Post
    Probably a insecure script in one of the 800 accounts.... with this I could easily get a list of users. Or, someone signed up for malicious reasons which happens but not as often. For example, a reseller client of yours has a automated account signup script...

    If I compromise a single PHP script on a server I can get all the user accounts and start digging in users directories as well. Users usually make their account login password the same as MySQL passwords, etc.

    As you can see, i'm just trying to offer suggestions and show you how easy getting into a system is.
    I'm well aware of how easy it can be to obtain sensitive information that could be used in a malicious way. But you didn’t bother to read post before you replied which riled me

    As I said, some of the affected accounts are very basic one page html holding pages. No MySQL and no PHP.
    Regards,
    James Smith
    UH Hosting Ltd

  4. #19
    Member
    Join Date
    Jul 2004
    Posts
    182

    Default

    Hi JamesSmith,

    I think ramprage is saying that you CAN get the list of account user/pass via some script vulnerabilities, and hence go on to do any kind of mischief with these, such as the multiple FTP logins we have been discussing.

  5. #20
    Member
    Join Date
    Sep 2003
    Location
    UK, Luton
    Posts
    197

    Default

    You certainly *shouldnt* be able to do anything with the passwd file.
    Regards,
    James Smith
    UH Hosting Ltd

  6. #21
    Member
    Join Date
    Jul 2002
    Location
    Canada
    Posts
    675

    Default

    JamesSmith - update to this.
    Were you using ProFTP when your servers were affected or Pure-FTP?
    Upload Guardian 2.0 - Sign up for our early beta
    ServerProgress - Server security, consulting and assistance

  7. #22
    Member
    Join Date
    Sep 2003
    Location
    UK, Luton
    Posts
    197

    Default

    Quote Originally Posted by ramprage View Post
    JamesSmith - update to this.
    Were you using ProFTP when your servers were affected or Pure-FTP?
    Yes and No.

    We're aware there was an unpatched hole in ProFTPd at the time but we have since switched every server to Pure-FTPd. But we're still seeing possible instances of exploits appearing on the boxes with Pure-FTPd.
    Regards,
    James Smith
    UH Hosting Ltd

  8. #23
    Member
    Join Date
    Sep 2005
    Posts
    37

    Default

    Could this be anything to do with it? http://secunia.com/advisories/24097/

    Could affected people check /var/cpanel/objcache?

    Doesn't seem like it's terribly useful, but it's all I can drag up to contribute

  9. #24
    Member
    Join Date
    Sep 2003
    Location
    UK, Luton
    Posts
    197

    Default

    Quote Originally Posted by Beansprout View Post
    Could this be anything to do with it? http://secunia.com/advisories/24097/

    Could affected people check /var/cpanel/objcache?

    Doesn't seem like it's terribly useful, but it's all I can drag up to contribute
    Nothing suspicious in that directory on any of our servers affected.
    Regards,
    James Smith
    UH Hosting Ltd

  10. #25
    Member
    Join Date
    Jun 2005
    Posts
    103

    Default

    I am no expert but maybe I found a potential problem.

    The same happened with two different servers in different countries so I start digging and check any file that was modified on that particular date.

    Except for the hacked/changed files as well as system files such as logs, on both servers I got the following.

    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBI/PurePerl.pm
    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBI/Gofer/Response.pm
    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBI/Gofer/Transport/Base.pm
    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/pipeone.pm
    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/http.pm
    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/Base.pm
    ./usr/lib/perl5/site_perl/5.8.7/i686-linux/DBD/Gofer/Transport/stream.pm


    ./usr/lib64/perl5/site_perl/5.8.0/DBD/Gofer/Policy/Base.pm
    ./usr/lib64/perl5/site_perl/5.8.0/DBD/Gofer/Policy/classic.pm
    ./usr/lib64/perl5/site_perl/5.8.0/DBD/Gofer/Policy/pedantic.pm
    ./usr/lib64/perl5/site_perl/5.8.0/DBI/ProfileDumper.pm
    ./usr/lib64/perl5/site_perl/5.8.0/DBI/Gofer/Request.pm
    ./usr/lib64/perl5/site_perl/5.8.0/DBI/Gofer/Transport/stream.pm
    ./usr/lib64/perl5/site_perl/5.8.0/DBI/Gofer/Transport/pipeone.pm

    Anyone perhaps knows perhaps more about this please?

  11. #26
    Member
    Join Date
    Mar 2006
    Location
    Brno, Czech Republic
    Posts
    507

    Default

    perl ? )
    Not everything that is counted counts and not everything that counts can be counted

  12. #27
    Member
    Join Date
    Feb 2003
    Location
    Sachse, TX
    Posts
    567

    Default

    Ramprage --

    Nice post, but that is not what is happening here.. We are having a cpanel root exploit no matter what. I have 3 servers experencing ALL the same thinga nd they are at C8800!!!!!!!!!!!!!!!!!!!!!!!!

    Not to mention ftp logins at will -- probably using a "master" password cpanel left in for pure-ftpd use.. You know, how we all can still login ftp using our root password on any account? SAME IDEA!

    Explaining it away as a list of excuses isnt gonna do any good.
    The issue is -- it is not from a hack, it is not from a brute force (I have brute force detection.. nothing).. etc.. it is from a simple ONE time login, upload, mess, thats it.

    Brenden

  13. #28
    Member
    Join Date
    Jul 2004
    Posts
    182

    Default

    tAzMaNiAc, can you specify what PHP version, what FTP server (pure/pro)? Thanks.

  14. #29
    Member
    Join Date
    Feb 2003
    Location
    Sachse, TX
    Posts
    567

    Default

    PureFTPd is latest version (i forced it on all) 1.0.21 or something..

    PHP is 4.4.4...

    Brenden

  15. #30
    Member
    Join Date
    Jul 2004
    Posts
    182

    Default

    OK, how about phpSuExec? and PHP Safe Mode? Thanks.

Similar Threads & Tags
Similar threads

  1. Replies: 123
    Last Post: 06-17-2010, 10:07 PM
  2. SOLUTION for Gumblar/IFRAME/JS hacks with stolen FTP Passwords...
    By hidonet in forum cPanel and WHM Discussions
    Replies: 98
    Last Post: 12-22-2009, 11:44 PM
  3. iframe / javascript hacks?
    By jack01 in forum cPanel and WHM Discussions
    Replies: 612
    Last Post: 11-20-2009, 10:14 PM
  4. IP addresses from IFrame Hacks
    By noimad1 in forum cPanel and WHM Discussions
    Replies: 22
    Last Post: 01-29-2008, 05:41 AM
  5. JavaScript & IFRAME Insert Hacks Through xfercpanel
    By dynaweb in forum cPanel and WHM Discussions
    Replies: 3
    Last Post: 09-15-2007, 02:46 PM
Linkedin       Facebook       Twitter       RSS       Flickr       YouTube