Author Archives: derak

by - 0 comments

Warning: RH-Sharpe’s Rootkit

Problem: You ran rkhunter -c on your CentOS powered web server and it found something called “RH-Sharpe’s Rootkit”.

I was cleaning up a minor infection on a WordPress site that wordfence identified. (The irony is not lost on me.) Once I’d verified all the files in wordpress and checked logs to see if the files had been accessed, I also ran clamav and rkhunter just to make sure. rkhunter alerted me to something called “RH-Sharpe’s Rootkit”. 💩 💩 💩

keep calm and check the logs
Always good advice.

rkhunter logs are usually found at “/var/log/rkhunter/rkhunter.log”.
It offers more detail on why a specific alert was generated.

 ....
 [08:15:25] Checking for RH-Sharpe's Rootkit…
 [08:15:25]   Checking for file '/bin/lps'                    [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/lpstree'            [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/ltop'               [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/lkillall'           [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/ldu'                [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/lnetstat'           [ Not found ]
 [08:15:25]   Checking for file '/usr/bin/wp'                 [ Found ]
 [08:15:26]   Checking for file '/usr/bin/shad'               [ Not found ]
 [08:15:26]   Checking for file '/usr/bin/vadim'              [ Not found ]
 [08:15:26]   Checking for file '/usr/bin/slice'              [ Not found ]
 [08:15:26]   Checking for file '/usr/bin/cleaner'            [ Not found ]
 [08:15:26]   Checking for file '/usr/include/rpcsvc/du'      [ Not found ]
 [08:15:26] Warning: RH-Sharpe's Rootkit                      [ Warning ]
 [08:15:26]          File '/usr/bin/wp' found
....

So in this case; it alerted because it found an executable called “wp”. If your a wordpress user; stand down. This is the wordpress command line tool.
It’s a text file. Have a look at it and make sure, but it’s like not something to freak out about.

When I googled for this error; almost nothing came up except for this. Appears “/usr/bin/slice” is also an often found trigger for this warning.

Hopefully this will be useful to the next person who googles for this term mid-panic as I did earlier today.

by - 0 comments

Please stop the FUD about WordPress.

I came across this posting from a web services company with a brief comparison of different cms options.

Craft — Very secure

WordPress — Can be difficult to secure properly (frequent vulnerabilities due to popularity)

Drupal — Very secure

Clients and co-workers come in with this “wordpress is insecure” opinion largely because of misinformed opinions from “experts”.

Better summaries for their security would be;
Craft – So far; secure with regular updates and careful plug-in selection.
WordPress- Secure with regular updates and careful plug-in selection.
Drupal – Secure with regular updates and careful plug-in selection.

Lets look into that a little bit; shall we.

Craft CMS
They do list all the security best practices they engage in which is great.
The Common Vulnerabilities and Exposures database has 11 reported issues with “Craft CMS” since 2017 with 3 in 2019. It doesn’t look like they engage in any kind of project level security review of this code. While I’d say given that low number of issues it probably deserves being called “secure”; more expert eyes looking in a regular way would be better.
They do benefit from the efforts of the Yii2 project its built on and aren’t likely to experience issues with any of their components. It’s smaller ecosystem than say Symfony but still relevant.

WordPress
A quick search of the CVE shows that plug-ins and themes are 99% of all the WordPress related vulnerabilities. WordPress core had 11 reported vulnerabilities in 2019. The WordPress core has security team which reviews its code base. It’s active user community reported most of those; not its security team. The push button nature of WordPress updates is its greatest feature. I’d have no trouble trusting a client to apply updates to their site which to me means its likely more secure than other options.

Drupal
I’d argue that Drupal is less secure than WordPress.
11 vulnerabilities were reported in Drupal in 2019. Plug-ins are also the majority of their issues. Drupal also has a security team which is constantly reviewing its code base and its most popular plug-ins. With version 8; they’ve chosen to use standard components provided from the Symfony project which should eliminate a lot of their potential security issues with core components. Updates are still a pain point; although its much better in version 8. Updates are often more complicated than pushing the “update button” I’d wager that your average client isn’t going to do that very often.

And while we’re on the topic.
The section on “License” is misleading.

Craft is offered under the “Craft” license. It is proprietary open-source software.
You can’t run it without a license and should pixel and tonic go out of business; you won’t be able to run craft.
(Granted; that will likely never happen but it could.)

WordPress and Drupal are licensed under the GPLv2 license. This is free (as in freedom) open-source software which can be used for derivative works.
https://wordpress.org/about/license/
https://www.drupal.org/about/licensing

I likely put more though into this posting than the original author. I understand the demands of making materials accessible to a client but I’m also tired of folks bagging on WordPress. I love php and for better or worse; WordPress is really why we’re still talking about php in 2020.

Stepping down from the soapbox now.

by - 0 comments

GOGS/Gitea Fix Critical API Auth By-Pass

I subscribe to updates from the forums and wasn’t alerted to this critical issue.

Manasseh Zhou reported a critical session bypass issue in the go-marcaron framework which impacts Gogs 0.11.86 @ 2019-01-30 and Gitea < 1.5.4.
Because of missing access checks; an attacker can log into any account and run arbitrary commands on an effected server.

This was reported as CVE-2018-18926 and CVE-2018-18925
Manasseh provides a detailed breakdown of the issue on his site.

Gogs and Gitea users should update immediately to the latest release.

On a side note; I’m concerned about the timeline here. This issue was first reported to the Gogs project in late 2018 and opened as a github issue in Aug. of 2019 which finally got the attention of unknwon and was resolved two days later. Gitea fixed this issue in Oct. of 2018.
I will be looking into other tools to internally host our git repositories.

by

Using php composer with RedHat Software Collections

Software Collections make running more than one version of php on the same server pretty painless. It does take some getting use to.

PHP has lots of command line tools which assume that php is available in the environment; which isn’t the case in an SCL environment.

Assumptions

  • Your using RedHat or CentOS 7.
  • php 7.2 is installed via software collections. (rh-php72)
  • PHP Composer’s “composer.phar” is downloaded in “/opt/php-composer/”

Here is a little bash script to work around this quirk of using SCL packages. 

#! /bin/bash

#choose which scl package we want to use.
source scl_source enable rh-php72

#pass all shell args to composer.
php /opt/php-composer/composer.phar "[email protected]"

Save this as “composer” and make it executable (chmod +x composer) and moved it into the “/usr/local/bin/” folder.

This trick also works for cron jobs which need a specific version of php to run.

by

PHP Warning: PHP Startup: Unable to load dynamic library ‘sodium.so’

When installing php 7.2 on CentOS using RedHat Software Collections; your getting an error from php like:

PHP Warning:  PHP Startup: Unable to load dynamic library 'sodium.so' (tried: /opt/rh/rh-php72/root/usr/lib64/php/modules/sodium.so (libsodium.so.23: cannot open shared object file: No such file or directory), /opt/rh/rh-php72/root/usr/lib64/php/modules/sodium.so.so (/opt/rh/rh-php72/root/usr/lib64/php/modules/sodium.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

This is a library conflict. Yum installed the wrong thing.
Lets have a look at this package:

(rh-mysql56,httpd24,rh-php72) [[email protected]]# yum deplist sclo-php72-php-sodium.x86_64
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.jaleco.com
 * epel: mirror.compevo.com
 * extras: centos-distro.1gservers.com
 * updates: repos.dfw.quadranet.com
package: sclo-php72-php-sodium.x86_64 7.2.12-1.el7
  dependency: libc.so.6(GLIBC_2.4)(64bit)
   provider: glibc.x86_64 2.17-260.el7_6.5
  dependency: libsodium.so.23()(64bit)
   provider: sclo-cassandra3-libsodium.x86_64 1.0.15-2.el7
   provider: libsodium.x86_64 1.0.17-1.el7
  dependency: rh-php72-php(api) = 20170718-64
   provider: rh-php72-php-common.x86_64 7.2.10-3.el7
  dependency: rh-php72-php(zend-abi) = 20170718-64
   provider: rh-php72-php-common.x86_64 7.2.10-3.el7
  dependency: rh-php72-runtime
   provider: rh-php72-runtime.x86_64 1-2.el7
  dependency: rtld(GNU_HASH)
   provider: glibc.x86_64 2.17-260.el7_6.5
   provider: glibc.i686 2.17-260.el7_6.5

Notice the libsodium library has two providers. This means that yum thinks either of these can satisfy the requirements; and in this case; it didn’t choose a compatible library. We’ll need to remove the sclo-cassandra3-libsodium library and manually install the one we want.

[[email protected]]# yum remove sclo-cassandra3-libsodium.x86_64
Loaded plugins: fastestmirror
Resolving Dependencies
--> Running transaction check
---> Package sclo-cassandra3-libsodium.x86_64 0:1.0.15-2.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================================
 Package                                       Arch                       Version                           Repository                             Size
========================================================================================================================================================
Removing:
 sclo-cassandra3-libsodium                     x86_64                     1.0.15-2.el7                      @centos-sclo-sclo                     348 k

Transaction Summary
========================================================================================================================================================
Remove  1 Package

Installed size: 348 k
Is this ok [y/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Erasing    : sclo-cassandra3-libsodium-1.0.15-2.el7.x86_64                                                                                        1/1
  Verifying  : sclo-cassandra3-libsodium-1.0.15-2.el7.x86_64                                                                                        1/1

Removed:
  sclo-cassandra3-libsodium.x86_64 0:1.0.15-2.el7

Complete!

Now install the correct library

[[email protected]]# yum install libsodium.x86_64
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.jaleco.com
 * epel: mirror.compevo.com
 * extras: centos-distro.1gservers.com
 * updates: repos.dfw.quadranet.com
Resolving Dependencies
--> Running transaction check
---> Package libsodium.x86_64 0:1.0.17-1.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================================
 Package                              Arch                              Version                                   Repository                       Size
========================================================================================================================================================
Installing:
 libsodium                            x86_64                            1.0.17-1.el7                              epel                            144 k

Transaction Summary
========================================================================================================================================================
Install  1 Package

Total download size: 144 k
Installed size: 344 k
Is this ok [y/d/N]: y
Downloading packages:
libsodium-1.0.17-1.el7.x86_64.rpm                                                                                                | 144 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : libsodium-1.0.17-1.el7.x86_64                                                                                                        1/1
  Verifying  : libsodium-1.0.17-1.el7.x86_64                                                                                                        1/1

Installed:
  libsodium.x86_64 0:1.0.17-1.el7

Complete!

Now lets test our install

[[email protected]]# php -i | grep sodium
/etc/opt/rh/rh-php72/php.d/20-sodium.ini,
sodium
sodium support => enabled
libsodium headers version => 1.0.17
libsodium library version => 1.0.17

Success!