Hello everyone,
I hope you are having a good day. However, I am concerned by this:
https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229
Has anyone heard yet what the attack vector is, if 5.9 and 6.4 are affected, and if a patch is coming out?
Thanks!
Gilbert
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On 02/21/2013 05:32 PM, Gilbert Sebenste wrote:
Hello everyone,
I hope you are having a good day. However, I am concerned by this:
https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229
Has anyone heard yet what the attack vector is, if 5.9 and 6.4 are affected, and if a patch is coming out?
This issue is not CentOS specific ... here is another discussion:
http://www.webhostingtalk.com/showthread.php?t=1235797
The issue seems to be that someone with local access elevates their privileges in some manner, and after they upgrade their privileges they are then putting a new libkeyutils*.so file on the machine.
There is some talk that this vector might be this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=911937
It is not yet known that this is the issue being used ... just speculation at this point.
There is a 3.4.32 kernel in our Xen4 for CentOS6 testing repo that has the patches rolled in for CVE-2013-0871. 3.4.32 is MUCH newer than the standard EL6 kernel and I am not recommending that people use this kernel in production without lots of testing ... and there should be a distro kernel out to address CVE-2013-0871 soon since it is a priority upstream. Here is a link where you can get that 3.4.32 kernel (x86_64 only) if you want to test it:
http://dev.centos.org/centos/6/xen-c6/x86_64/RPMS/
No one really knows what the vector currently is but there are methods to scan for and fix the issue in the webhostingtalk thread above.
Since the current thought on this issue is that it requires local access ... the machines one needs to be very weary of are ones where many people have non root access and might want to try to gain unauthorized root ... like a shared web hosting machine.
When we know more, we will post it here,
Thanks, Johnny Hughes
Thank you, Johnny, for that clarification, I appreciate it! I can relax a little now. :-)
Gilbert
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** *******************************************************************************
On Thu, Feb 21, 2013 at 6:03 PM, Johnny Hughes johnny@centos.org wrote:
This issue is not CentOS specific ... here is another discussion:
http://www.webhostingtalk.com/showthread.php?t=1235797
The issue seems to be that someone with local access elevates their privileges in some manner, and after they upgrade their privileges they are then putting a new libkeyutils*.so file on the machine.
But don't forget that what the kernel people call 'local' access really means any bug in any network application that lets you execute an arbitrary command even if it is non-root - and those have historically been pretty common.
But don't forget that what the kernel people call 'local' access really means any bug in any network application that lets you execute an arbitrary command even if it is non-root - and those have historically been pretty common.
sounds like local install of famous php scripting language...
-- Eero
On 02/22/2013 01:50 PM, Les Mikesell wrote:
On Thu, Feb 21, 2013 at 6:03 PM, Johnny Hughes johnny@centos.org wrote:
This issue is not CentOS specific ... here is another discussion:
http://www.webhostingtalk.com/showthread.php?t=1235797
The issue seems to be that someone with local access elevates their privileges in some manner, and after they upgrade their privileges they are then putting a new libkeyutils*.so file on the machine.
But don't forget that what the kernel people call 'local' access really means any bug in any network application that lets you execute an arbitrary command even if it is non-root - and those have historically been pretty common.
Sure .. if you can execute code as a user when you are not supposed to have any access ... then you can elevate privileges by stringing things together after you get the unauthorized access.
However, what people are seeing ... in practice today ... is that machines where there are multiple users and which are running control panel software SEEM to be most effected.
Does that mean that a single user machine will never be compromised ... of course not.
Obviously everyone who has any machines that in any way touch the Internet should be scanning/monitoring their machines for compromise on a routine basis. In my last post, I explained how to find out if you have this kit installed (look at the webhosttalk link from that post).
Remember that the library files that are being put on the machines are not installed via an RPM but copied on as files ... and that only kernel branches > 3.4.32 (in the LTS branch), > 3.7.7 and > 3.8rc6 have had the patches applied. That means IF (and that is a big if) this is the input vector, then all Linux machines (not just CentOS or RHEL) with kernels older than those are susceptible to this issue.
Am 22.02.2013 um 21:11 schrieb Johnny Hughes johnny@centos.org:
On 02/22/2013 01:50 PM, Les Mikesell wrote:
On Thu, Feb 21, 2013 at 6:03 PM, Johnny Hughes johnny@centos.org wrote:
This issue is not CentOS specific ... here is another discussion:
http://www.webhostingtalk.com/showthread.php?t=1235797
The issue seems to be that someone with local access elevates their privileges in some manner, and after they upgrade their privileges they are then putting a new libkeyutils*.so file on the machine.
But don't forget that what the kernel people call 'local' access really means any bug in any network application that lets you execute an arbitrary command even if it is non-root - and those have historically been pretty common.
Sure .. if you can execute code as a user when you are not supposed to have any access ... then you can elevate privileges by stringing things together after you get the unauthorized access.
However, what people are seeing ... in practice today ... is that machines where there are multiple users and which are running control panel software SEEM to be most effected.
Does that mean that a single user machine will never be compromised ... of course not.
Obviously everyone who has any machines that in any way touch the Internet should be scanning/monitoring their machines for compromise on a routine basis. In my last post, I explained how to find out if you have this kit installed (look at the webhosttalk link from that post).
Remember that the library files that are being put on the machines are not installed via an RPM but copied on as files ... and that only kernel branches > 3.4.32 (in the LTS branch), > 3.7.7 and > 3.8rc6 have had the patches applied. That means IF (and that is a big if) this is the input vector, then all Linux machines (not just CentOS or RHEL) with kernels older than those are susceptible to this issue.
i use following script to scan top level directories for files that are not packaged:
#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/root/bin BASE=$(echo "$1" |grep ^/) RPML=$(mktemp -t rpml.XXXXXXXXXX) || exit 1
if [ -z "$BASE" ] ; then echo "Usage: $0 /directory" exit 1 fi
if ! [ -d "$BASE" ] ; then echo "Usage: $0 /directory" exit 1 fi
echo "Searching in $BASE"
rpm -qla |sort > "$RPML"
for TARGET in $(find "$BASE" -type f |grep -v "/proc/"| sed s/\[/\\[/g ) do if ! grep -x "$TARGET" "$RPML" 1>/dev/null ; then echo "$TARGET" fi done
if [ -f "$RPML" ]; then rm "$RPML" fi
exit 0
-- LF
On 02/22/2013 09:35 PM, Leon Fauster wrote:
i use following script to scan top level directories for files that are not packaged:
If you trust your rpm-db, then something like my syscleanup script might also come in handy : https://www.gitorious.org/syscleanup/syscleanup/trees/master
I highly recommend reading the README.txt file
- KB
Am 23.02.2013 um 05:52 schrieb Karanbir Singh mail-lists@karan.org:
On 02/22/2013 09:35 PM, Leon Fauster wrote:
i use following script to scan top level directories for files that are not packaged:
If you trust your rpm-db, ...
i used to scan this list
rpm -qa --qf '%{NAME}-%{SIGGPG:pgpsig}-%{SIGPGP:pgpsig}-%{VENDOR}\n'
and checked them against keys that are _not_ in /etc/pki/rpm-gpg/.
Just as a normal sanity check (plus rpm -V).
i aware that this does not substitute a real auditing solution.
-- LF
'rpm -V' can be misleading, if taking into account of prelink on Redhat/Centos Boxes which is running through cron by default. I've shown the steps on reverse the effect of prelink at the comments sections at link https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229?storyid=15229. I'm afraid that 'rpm -V' only will make big noises or false alarms.
But in general, maybe it is a good time to turn off prelink, or more aggressively, remove prelink packages from Centos 5/6? the prelink is said to bring some performance boost, but who really cares in the era of tens of CPUs? nowadays and later on we are -- and will -- more concerned on security threats instead of 3~5 percents CPU/performance gain, right?
________________________________ From: Leon Fauster leonfauster@googlemail.com To: CentOS mailing list centos@centos.org Sent: Saturday, February 23, 2013 3:14 AM Subject: Re: [CentOS] SSHD rootkit in the wild/compromise for CentOS 5/6?
Am 23.02.2013 um 05:52 schrieb Karanbir Singh mail-lists@karan.org:
On 02/22/2013 09:35 PM, Leon Fauster wrote:
i use following script to scan top level directories for files that are not packaged:
If you trust your rpm-db, ...
i used to scan this list
rpm -qa --qf '%{NAME}-%{SIGGPG:pgpsig}-%{SIGPGP:pgpsig}-%{VENDOR}\n'
and checked them against keys that are _not_ in /etc/pki/rpm-gpg/.
Just as a normal sanity check (plus rpm -V).
i aware that this does not substitute a real auditing solution.
-- LF
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 02/25/2013 04:24 PM, Gelen James wrote:
'rpm -V' can be misleading, if taking into account of prelink on Redhat/Centos Boxes which is running through cron by default. I've shown the steps on reverse the effect of prelink at the comments sections at link https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229?storyid=15229. I'm afraid that 'rpm -V' only will make big noises or false alarms.
But in general, maybe it is a good time to turn off prelink, or more aggressively, remove prelink packages from Centos 5/6? the prelink is said to bring some performance boost, but who really cares in the era of tens of CPUs? nowadays and later on we are -- and will -- more concerned on security threats instead of 3~5 percents CPU/performance gain, right?
RHEL does prelinking by default, we therefore will never turn it off in CentOS by default.
It makes some sense to follow RHEL's suit, but Gelen's suggestions gain more points here too.
As end users we probably turn off the default prelink settings after RHEL/Centos initial installation, it is not a rocket technology.
On 2/26/13 8:10 AM, "Johnny Hughes" johnny@centos.org wrote:
On 02/25/2013 04:24 PM, Gelen James wrote:
'rpm -V' can be misleading, if taking into account of prelink on Redhat/Centos Boxes which is running through cron by default. I've shown the steps on reverse the effect of prelink at the comments sections at link https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229?storyid=15229. I'm afraid that 'rpm -V' only will make big noises or false alarms.
But in general, maybe it is a good time to turn off prelink, or more aggressively, remove prelink packages from Centos 5/6? the prelink is said to bring some performance boost, but who really cares in the era of tens of CPUs? nowadays and later on we are -- and will -- more concerned on security threats instead of 3~5 percents CPU/performance gain, right?
RHEL does prelinking by default, we therefore will never turn it off in CentOS by default.
On Monday 25 February 2013 14:24:28 Gelen James wrote:
'rpm -V' can be misleading, if taking into account of prelink on Redhat/Centos Boxes which is running through cron by default. I've shown the steps on reverse the effect of prelink at the comments sections at link https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229?storyid=1522 9. I'm afraid that 'rpm -V' only will make big noises or false alarms.
I think you may be confused as to the normal interaction between prelink and "rpm -V". rpm knows about and disregards prelink sections in its verification:
[root@n1 ~]# md5sum /usr/bin/wc 4d97cc9894946fbb7ba45d0a247f16da /usr/bin/wc [root@n1 ~]# prelink -m /usr/bin/wc [root@n1 ~]# md5sum /usr/bin/wc 2db523c558b713b92987747dcbe59005 /usr/bin/wc [root@n1 ~]# rpm -V coreutils [root@n1 ~]# prelink -vu /usr/bin/wc [root@n1 ~]# md5sum /usr/bin/wc 4d97cc9894946fbb7ba45d0a247f16da /usr/bin/wc [root@n1 ~]# rpm -V coreutils [root@n1 ~]#
/Peter
On 25.Feb.2013, at 23:24, Gelen James wrote:
'rpm -V' can be misleading, if taking into account of prelink on Redhat/Centos Boxes which is running through cron by default. I've shown the steps on reverse the effect of prelink at the comments sections at link https://isc.sans.edu/diary/SSHD+rootkit+in+the+wild/15229?storyid=15229. I'm afraid that 'rpm -V' only will make big noises or false alarms.
rpm is prelink-aware. It does a prelink -y prelink -y will complain if a dependency has changed
prelink: xxx: at least one of file's dependencies has changed since prelinking
This can happen after you updated stuff but did not run prelink yet. Just run prelink again.
Unfortunaly running prelink does not catch all those "has changed since prelinking" messages.
If you have a binary that uses library X and you remove that binary so that nothing uses library X anymore, library X will not prelinked again (if you use -a parameter as the default cronjob does). Thats not a problem per se, but if you then go and update a dependency for library X, then prelink -y for library X will fail and therefore rpm -V will fail too.
Remove library X, it is not needed anyway or unprelink library X manually or reprelink library X manually.
also see https://bugzilla.redhat.com/show_bug.cgi?id=204448
-
Eero Volotinen -
Gelen James -
Gilbert Sebenste -
Guolin Cheng -
Johnny Hughes -
Karanbir Singh -
Leon Fauster -
Les Mikesell -
Markus Falb -
Peter Kjellström