XWiki Instance hacked

Help / Discuss
1

Hi,

I’m taking care of an XWiki Site. The Site is configured as docker-container. I regularly update the container. Nevertheless the XWiki was hacked multiple times and can not be up and running without additional security measures without being hacked again within about one day.

The successful hacking attempt is discovered by detecting high cpu usage within the docker container (monitoring shows that). Once xmrig (a cryptominer software) had been installed. Recreating the docker container clears up the mess temporarily (I hope it’s cleared fully and the host os is not contaminated).

As you can see from below, I’m running the current latest 16.x version of XWiki.

This is my docker-compose.yml file:

version: "3.5"
services:

  xwikistable:
    container_name: xwikistable
    hostname: xwikistable
    image: xwiki:stable-mysql-tomcat
    restart: always
    ports:
      - 127.0.0.1:8094:8080
    environment:
      - DB_USER=...
      - DB_PASSWORD=...
      - DB_DATABASE=xwikistable
      - DB_HOST=xwikistable-mysql
    networks:
      - frontend
    volumes:
      - "./wiki-data:/usr/local/xwiki"

  xwikistable-mysql:
    container_name: xwikistable-mysql
    hostname: xwikistable-mysql
    image: mysql:5.7
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    ports:
        - '127.0.0.1:7707:3306'
    networks:
      - frontend
    environment:
      - MYSQL_DATABASE=...
      - MYSQL_USER=...
      - MYSQL_PASSWORD=...
      - MYSQL_ROOT_PASSWORD=...
    volumes:
      - "./mysql-data:/var/lib/mysql"
      - "./xwikistable.cnf:/etc/mysql/conf.d/xwiki.cnf"
      - "./initstable.sql:/docker-entrypoint-initdb.d/init.sql"
      - "./mysqld.conf:/etc/mysql/conf.d/mysqld.cnf"

networks:
  frontend:

This is my apache reverse proxy configuration:

<VirtualHost *:443>

    ServerName  www.mywiki.com

    SSLEngine on
    SSLCertificateFile      ...
    SSLCertificateKeyFile   ...
    SSLCACertificateFile    ...

    DocumentRoot /var/www/empty
    <Directory />
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ProxyRequests Off
    ProxyPreserveHost On
    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>

    ProxyPass / http://127.0.0.1:8094/
    ProxyPassReverse / http://127.0.0.1:8094/

    ErrorLog ...
    LogLevel warn
    CustomLog ...
    ServerSignature Off

    AddDefaultCharset utf-8
</VirtualHost>

<VirtualHost *:80>

    ServerName  www.mywiki.com

    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=301]

    DocumentRoot /var/www/empty
    <Directory />
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ProxyRequests Off
    ProxyPreserveHost On
    <Proxy *>
        Order allow,deny
        Allow from all
    </Proxy>

    ErrorLog ...
    LogLevel warn
    CustomLog ...
    ServerSignature Off

    AddDefaultCharset utf-8
</VirtualHost>

I checked security best practices from here ([xwiki-users] Security best practices for Xwiki deployment and management) and it did not help.

I also fixed the user permissions (Every user (without public) had been given admin privleges. I revoked that.) I also changed the passwords of the remaing admin accounts to strong passwords. It did not help.

The thing that seems to help is, to restrict certain URLs by webserver configuration. I’m filtering these URLs for now:

RewriteEngine On
RewriteRule .*/admin/ - [F]
RewriteRule .*/webdav/ - [F]
RewriteRule .*/export/ - [F]
RewriteRule ^/bin/view/Main/UserDirectory -[F]
RewriteRule ^/rest/ - [F]

From the webserver log file, it seems that the /rest - URL is the possible break in possibility.

Thanks for any additional help with this.

Regards,
fx919

2

Hello, sorry to hear about that.

We use the Tomcat tomcat:9-jre17 image. The known vulnerabilities can be seen at https://hub.docker.com/layers/library/tomcat/9-jre17/images/sha256-3fca8186663d67794cac54170708a94723670034f67a8e7e2e984def279cc96a?context=explore

BTW make sure you “docker pull” both the image regularly to get the newest version of XWiki and Tomcat (for the 9.x branch).

Concerning XWiki, we regularly fix security issues and if you’re using the latest LTS version (which is currently 15.10.11) there are no known important security issues, especially regarding the REST system. It doesn’t mean that it doesn’t exist but that we don’t know about it.

Does it mean you don’t have the problem any more?

Thanks

7

Yes. After being hacked some days in a row - every day - now it is quiet after reducing the admin users, setting very complex admin passwords and restricting the urls as written above.

I’ll be enabling the url restrictions after some days and then I’ll know.

I do docker-compose pull / docker-compose up -d now once a day. Even the test-copy-docker-compose environment had been hacked after 3 days online or so.

8

After restricting the permissions and setting complex passwords for all accounts, the trouble did not come back. The docker container runs smoothly now - with resource restrictions.