Announcement

Collapse
No announcement yet.

Security RISK/WARNING for you folks with shared providers..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Security RISK/WARNING for you folks with shared providers..

    Folks,

    This is such a simple security issue, I'm surprised it even exist.

    There is, in my mind, a huge security issue for folks running forum software such as vB or phpbb on these shared servers. It has to do with the config.php file and your host not knowing what the heck they are doing.

    They have the permissions configured improperly, where they allow "all" read and eXecute permission on this file.

    So, what does this mean to you? It means you can do a "locate config.php" and see all the copies across everyone's home directory. At that point, you can cd to that directory and READ the config.php file.

    Of course, once you have read it, your able to get the dbname and dbpassword that is configured for MySQL.

    Once you have this data, feel free to use mysqldump to dump the data base, change it, etc.

    Check with your host, your config.php file SHOULD NOT be world/all readable. It should be RWX for you, and R for whatever user runs apache (on RedHat, it is the apache user). No reason to have world/all permissions on this file. At least none that I am aware of! ;-)

    Perhaps someone with more security experience can figure out how to better protect this file then having it chown user:apache and chmod 750.

    Two LARGE shared providers are vulnerable to this, to check if yours is, do a:

    [[email protected] cara]$ locate config.php
    /www/html/fn/vb/admin/config.php
    [[email protected] cara]$

    <note user Cara can read that directory, which isn't hers>

    [[email protected] cara]$ ls -l /www/html/fn/vb/admin/config.php
    -rwxr-xr-x 1 tjk tjk 1017 Jan 24 21:50 /www/html/fn/vb/admin/config.php
    [[email protected] cara]$

    <ok, the file is user/group tjk, but has RX permissions for All>

    [[email protected] cara]$ cat /www/html/fn/vb/admin/config.php
    <?php
    /////////////////////////////////////////////////////////////
    // Please note that if you get any errors when connecting, //
    // that you will need to email your host as we cannot tell //
    // you what your specific values are supposed to be //
    /////////////////////////////////////////////////////////////

    // type of database running
    // (only mysql is supported at the moment)
    $dbservertype="mysql";

    // hostname or ip of server
    $servername="localhost";

    // username and password to log onto db server
    $dbusername="vb";
    $dbpassword="vb";

    // name of database
    $dbname="vb";

    // technical email address - any error messages will be emailed here
    $technicalemail = "blah blah blah to protect the innocent";

    // use persistant connections to the database
    // 0 = don't use
    // 1 = use
    $usepconnect = 0;

    // which users are allowed to view the admin log
    // separate each userid with a comma
    $canviewadminlog = "1";

    // which users are allowed to prune the admin log
    // separate each userid with a comma
    $canpruneadminlog = "";

    ?>
    [[email protected] cara]$

    <great, cara now has my db name and my db password! what can they do with it? Hopefully I'm smart enough to not use my dbpassword as my admin login, etc>


    [[email protected] cara]$ mysql dump -uvb -pvb vb > test.dump
    [[email protected] cara]$ ls -l test.dump
    -rw-rw-r-- 1 cara cara 4587 Jan 28 13:09 test.dump
    [[email protected] cara]$

    <hmm, they were able to dump it...not good>

    You get the point from here.

    Check your server/configuration!

    Tom

  • #2
    Its a known risk, and one that you cannot get around, for apache to read it, everyone else must be able to also.... Once Apache 2.x becomes final, this will be fixed, everything will be run as the users UID, and so globaly readable and writeable files will be no more.....

    Comment


    • #3
      Actually..

      That's not true.

      I solved it be making the file:

      chown jdoe:apache and chmod 750.

      This lets the apache user read it when it needs to, and the user has rwx access to it.

      Any other user can't read the file...

      I have it set that way, tested it, and it works, what am I missing?

      Tom

      Comment


      • #4
        Shhh! There might be hackers reading these boards. We don't want to give them any ideas.

        Comment


        • #5
          [[email protected]]:~$ chown nobody.prohack index.html
          chown: changing ownership of `index.html': Operation not permitted
          [[email protected]]:~$ chown prohack.nobody index.html
          chown: changing ownership of `index.html': Operation not permitted
          [[email protected]]:~$
          One problem with your changing ownership, root would have to do it, and when you have 500+ customers thats a real big hassle..

          Like I said, no real easy answer...

          Comment


          • #6
            True...

            BUT if it was done right the first time...

            You know the rest of that story.

            Tom

            Comment


            • #7
              Re: True...

              Originally posted by tomk
              BUT if it was done right the first time...

              You know the rest of that story.

              Tom
              We are running Cpanel, there is nothing done right with it..

              Comment


              • #8
                Are you...

                Are you a service provider/hosting firm or an end user?

                Care to take the dialogue to email? I'd like to discuss more with you.

                [email protected]

                Tom

                Comment


                • #9
                  I'm a webhost....

                  Sure I guess....

                  Comment


                  • #10
                    TomK, with all respect, it is not up to the host to check every site for a copy of config.php on vBulletin and secure it, besides which, if you do your solution all I have to do is write a script that runs in the web server to read the file and get the contents. This is a known risk with shared hosting and effects all sorts of scripts not just vBulletin. Like has been said, Apache 2 is going to help solve this problem.
                    Karl Austin
                    UK Web Hosting and Servers :: KDA Web Services Ltd.
                    Specialists in Custom Solutions

                    Comment


                    • #11
                      Originally posted by Karl
                      TomK, with all respect, it is not up to the host to check every site for a copy of config.php on vBulletin and secure it, besides which, if you do your solution all I have to do is write a script that runs in the web server to read the file and get the contents. This is a known risk with shared hosting and effects all sorts of scripts not just vBulletin. Like has been said, Apache 2 is going to help solve this problem.
                      Karl,

                      You are correct. Sad but true that this exist.

                      Oh well, I'm surprised more folks haven't been affected by this...considering how easy it is to destroy someone's database.

                      tjk

                      Comment


                      • #12
                        Yes, me too. It's a trade off, run Apache with SuExec and put PHP in as a CGI and it's slow and a waste of resources, or make better use of resources and run PHP as a module but run the risk of things being less secure.
                        Karl Austin
                        UK Web Hosting and Servers :: KDA Web Services Ltd.
                        Specialists in Custom Solutions

                        Comment


                        • #13
                          Originally posted by Karl
                          Yes, me too. It's a trade off, run Apache with SuExec and put PHP in as a CGI and it's slow and a waste of resources, or make better use of resources and run PHP as a module but run the risk of things being less secure.
                          Those are the choices?! Oh shi*!
                          JTMON

                          Comment


                          • #14
                            Yes those are the choices and they aren't as clear cut as they sound.
                            Karl Austin
                            UK Web Hosting and Servers :: KDA Web Services Ltd.
                            Specialists in Custom Solutions

                            Comment


                            • #15
                              Well I know my host runs apache with SUexec but it seems fast. I've even had compliments on the speed. Never mind the site going down once a week

                              Good info to know though, thanks for the headsup!
                              JTMON

                              Comment

                              widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                              Working...
                              X