barbut anyone?

[Steve Holdoway]

I'm trying to find out any info about malware that generates an
executable called barbut[0-9], owned by root that keeps infecting a
CentOS5 - patched to current - server.

My google fu gets me to posts from 2007, and I'd be surprised if the
same attack vector would be open. Still looking, but v. worried about
the root ownership...

rkhunter, log mining, etc find nothing untoward.

Please feel free to contact me offlist if you feel it more appropriate.

Cheers,

Steve

[Glenn Enright]

Hate to say it, but root ownership means server ownership in most
cases. I'd be disinclined to trust any executables on that server now.
Especially since you say that keeps returning.

You may have done this already but to find the vector check for hidden
(ls -la) files and folders in /tmp and /var/tmp and also /dev/shm.
Look for recently modified files with find / -ctime <numdays>. Check
webserver logs for recuring IPs that you don't recognize, look for the
wget or other system commands there (in the webserver logs) as well.
And check all crontab entries by looking in /var/spool/cron. Verify
every single user on the system, make sure all passwords are strong.
Check login logs to see if there are any correlations with the malware
running. Add a monitor task to alert in case the malware process
starts and send a process list attached to that. etc

Post by Steve Holdoway
I'm trying to find out any info about malware that generates an
executable called barbut[0-9], owned by root that keeps infecting a
CentOS5 - patched to current - server.
My google fu gets me to posts from 2007, and I'd be surprised if the
same attack vector would be open. Still looking, but v. worried about
the root ownership...
rkhunter, log mining, etc find nothing untoward.
Please feel free to contact me offlist if you feel it more appropriate.
Cheers,
Steve
--
http://www.greengecko.co.nz
Skype: sholdowa
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Jaco]

Post by Glenn Enright
Hate to say it, but root ownership means server ownership in most
cases. I'd be disinclined to trust any executables on that server now.
Especially since you say that keeps returning.

Yip - you may already be in a bad way (thinking rootkits).
If your system is already compromised, you may need to boot up with some
sort of live/recovery system & try your recovery from that.

Recover what data you can & start again from a sterile environment.

This may also mean that other hosts/nodes on your network could be
compromised - nmap may help with analysing suspicious traffic.

Some interesting reading-material as mitigation for future reference:
* DSD Top 35 Mitigation Strategies
(http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm)
(still struggling to get my head around AppArmor/SELinux - it's a beast!)

Would be curious to know what AV's & other security
suites/products/solutions other folks are using (Clam just doesn't cut it)

- J

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Adrian Mageanu]

Post by Jaco

Post by Glenn Enright
Hate to say it, but root ownership means server ownership in most
cases. I'd be disinclined to trust any executables on that server now.
Especially since you say that keeps returning.

Yip - you may already be in a bad way (thinking rootkits).
If your system is already compromised, you may need to boot up with some
sort of live/recovery system & try your recovery from that.
Recover what data you can & start again from a sterile environment.
This may also mean that other hosts/nodes on your network could be
compromised - nmap may help with analysing suspicious traffic.
* DSD Top 35 Mitigation Strategies
(http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm)
(still struggling to get my head around AppArmor/SELinux - it's a beast!)
Would be curious to know what AV's & other security
suites/products/solutions other folks are using (Clam just doesn't cut it)
- J
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

f-prot on an F14 box used as desktop / development workstation

http://www.f-prot.com/products/home_use/linux/

free for personal home use.

I run it about once a month and it never found anything so can't say how
good it is at removing viruses and malware.

Adrian



_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Martin D Kealey]

Post by Jaco

Post by Glenn Enright
Hate to say it, but root ownership means server ownership in most
cases. I'd be disinclined to trust any executables on that server now.
Especially since you say that keeps returning.

Yip - you may already be in a bad way (thinking rootkits).
If your system is already compromised, you may need to boot up with some sort
of live/recovery system & try your recovery from that.

First thing I use is a hand-rolled version of "ls" that's written entirely
in Perl (see attached).

It does pretty much everything that normal "ls" does, and you can read it to
make sure it hasn't been compromised. It's conceivable that /usr/bin/perl
gets compromised, or the kernel, but it's a good start.

If the "mtime" is older than the "ctime" on a file, my "lsx" puts a "*" next
to the date. This is useful for spotting files which have been touched and
then rewound. Some of them will be harmless -- like if you've unpacked a
tarball -- but anything like that in /bin or /etc indicates trouble.

I'd start with "lsx -3 --find /*bin /usr/*bin /etc" to check what's been
interfered with. As long as "/bin/mount" and "/etc/fstab" are OK, I'd then
mount an external drive with a root filesystem, and set $PATH to point at
/mnt/bin:/mnt/usr/bin:...etc...

All this assumes you can't (or can't afford) to reboot the host off a
LiveCD, which is on the whole a lot simpler.

Post by Jaco
Recover what data you can & start again from a sterile environment.
This may also mean that other hosts/nodes on your network could be compromised
- nmap may help with analysing suspicious traffic.
* DSD Top 35 Mitigation Strategies
(http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm)
(still struggling to get my head around AppArmor/SELinux - it's a beast!)
Would be curious to know what AV's & other security suites/products/solutions
other folks are using (Clam just doesn't cut it)
- J
_______________________________________________
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Steve Holdoway]

Post by Martin D Kealey

Post by Jaco

Post by Glenn Enright
Hate to say it, but root ownership means server ownership in most
cases. I'd be disinclined to trust any executables on that server now.
Especially since you say that keeps returning.

Yip - you may already be in a bad way (thinking rootkits).
If your system is already compromised, you may need to boot up with some sort
of live/recovery system & try your recovery from that.

First thing I use is a hand-rolled version of "ls" that's written entirely
in Perl (see attached).
It does pretty much everything that normal "ls" does, and you can read it to
make sure it hasn't been compromised. It's conceivable that /usr/bin/perl
gets compromised, or the kernel, but it's a good start.
If the "mtime" is older than the "ctime" on a file, my "lsx" puts a "*" next
to the date. This is useful for spotting files which have been touched and
then rewound. Some of them will be harmless -- like if you've unpacked a
tarball -- but anything like that in /bin or /etc indicates trouble.
I'd start with "lsx -3 --find /*bin /usr/*bin /etc" to check what's been
interfered with. As long as "/bin/mount" and "/etc/fstab" are OK, I'd then
mount an external drive with a root filesystem, and set $PATH to point at
/mnt/bin:/mnt/usr/bin:...etc...
All this assumes you can't (or can't afford) to reboot the host off a
LiveCD, which is on the whole a lot simpler.

Post by Jaco
Recover what data you can & start again from a sterile environment.
This may also mean that other hosts/nodes on your network could be compromised
- nmap may help with analysing suspicious traffic.
* DSD Top 35 Mitigation Strategies
(http://www.dsd.gov.au/infosec/top35mitigationstrategies.htm)
(still struggling to get my head around AppArmor/SELinux - it's a beast!)
Would be curious to know what AV's & other security suites/products/solutions
other folks are using (Clam just doesn't cut it)
- J

To the best of my knowledge linux doesn't save the file creation time.
There's the last mod time of the inode, but that's not the same thing...

I just compared and contrasted md5s of a known, clean, up to date
system. The few files left, I checked by hand.

As I had a last mod date on the files - all 3 the same, as was the last
mod of rc.local, I'm pretty sure it's clean.

It's only a web server, so no need to be that paranoid about it... I
just needed to work out how it was hacked, and being reinfected (:

Cheers,

Steve

[Martin D Kealey]

Post by Steve Holdoway

Post by Martin D Kealey
If the "mtime" is older than the "ctime" on a file, my "lsx" puts a "*" next

To the best of my knowledge linux doesn't save the file creation time.
There's the last mod time of the inode, but that's not the same thing...

I didn't say creation time, I said ctime; in the manual that is described as
the inode CHANGE time. It records the last time a change is made to the
inode metadata, rather than to the content (which is recorded by the mtime).

In particular, the ctime is set to the current time when the "utime" system
call is used to change the atime and/or mtime values.

(It's also set-to-current if links are added or removed or renamed, or if
ownership or permissions change, or on the root directory of a filesystem
when it's mounted or unmounted (although that's version-dependent).)

-Martin

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Tomislav Skunca]

Post by Steve Holdoway
I'm trying to find out any info about malware that generates an
executable called barbut[0-9], owned by root that keeps infecting a
CentOS5 - patched to current - server.
My google fu gets me to posts from 2007, and I'd be surprised if the
same attack vector would be open. Still looking, but v. worried about
the root ownership...
rkhunter, log mining, etc find nothing untoward.
Please feel free to contact me offlist if you feel it more appropriate.
Cheers,
Steve

It's probably this:
http://bit.ly/vJ1xUN
http://bit.ly/uSgXlE

You could compile the source and check the MD5 hash to see if it's the
same Trojan.

It might be in your init scripts or a .bashrc file and it could be
disguised as a 'normal' binary in /usr/bin. Check if it's connecting
to an IRC channel. As for the entry vector, do you have packages that
are not in the CentOS repos and potentially out of date? It would be
smart to take a snapshot of the current machine

If rebooting is a problem I'd setup a new machine, transfer any
services to it and then rebuild the infected machine. That way you can
migrate to CentOS 6 if you want to and only have to check the
transfered files for tampering.

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Steve Holdoway]

Post by Tomislav Skunca

Post by Steve Holdoway
I'm trying to find out any info about malware that generates an
executable called barbut[0-9], owned by root that keeps infecting a
CentOS5 - patched to current - server.
My google fu gets me to posts from 2007, and I'd be surprised if the
same attack vector would be open. Still looking, but v. worried about
the root ownership...
rkhunter, log mining, etc find nothing untoward.
Please feel free to contact me offlist if you feel it more appropriate.
Cheers,
Steve

http://bit.ly/vJ1xUN
http://bit.ly/uSgXlE
You could compile the source and check the MD5 hash to see if it's the
same Trojan.
It might be in your init scripts or a .bashrc file and it could be
disguised as a 'normal' binary in /usr/bin. Check if it's connecting
to an IRC channel. As for the entry vector, do you have packages that
are not in the CentOS repos and potentially out of date? It would be
smart to take a snapshot of the current machine
If rebooting is a problem I'd setup a new machine, transfer any
services to it and then rebuild the infected machine. That way you can
migrate to CentOS 6 if you want to and only have to check the
transfered files for tampering.

Yes, that's the one. Clam does recognise the executable ( barbut1.i386:
Trojan.Tsunami.B FOUND ), and I've found the source code. I've scanned
the whole server now, and not found anything.

All packages are up to date, although checking all this plesk ( yeugh! )
stuff is difficult to prove. Published services are ftp, ssh, mail, dns,
web, mysql, plesk.

I think I've found the vector... /etc/rc.d/rc.local contains

touch /var/lock/subsys/local
/usr/include/php/dropbear
/usr/sbin/iptables -I OUTPUT 1 -p tcp --dport 45295 -j DROP


and /usr/include/php also contains a copy of busybox. That would give it
root privileges at least. I've never come across dropbear installed on
CentOS, who would install it there...

As an aside, I'm extremely concerned about the state of CentOS, as the
patch time for 6.0 is measured in months of delay when compared to RH.
The key departure of Dag Wieers is even more worrying. I won't be
voluntarily migrating to CentOS 6 ( RH is already 6.1 ). My fave server
distro is currently debian squeeze.

Cheers,

Steve

[Clark Mills]

Post by Steve Holdoway
As an aside, I'm extremely concerned about the state of CentOS, as the
patch time for 6.0 is measured in months of delay when compared to RH.
The key departure of Dag Wieers is even more worrying. I won't be
voluntarily migrating to CentOS 6 ( RH is already 6.1 ). My fave server
distro is currently debian squeeze.
Cheers,
Steve

Hi Steve.

I'm readying to jump ship too but I'm looking at:

http://www.scientificlinux.org/

It seems to have a good and honourable past / future.

( I'm sure you know about it but there might be someone who doesn't ;)

Cheers... Clark

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Philip Charles]

Post by Clark Mills

Post by Steve Holdoway
As an aside, I'm extremely concerned about the state of CentOS, as
the patch time for 6.0 is measured in months of delay when compared
to RH. The key departure of Dag Wieers is even more worrying. I
won't be voluntarily migrating to CentOS 6 ( RH is already 6.1 ). My
fave server distro is currently debian squeeze.
Cheers,
Steve

Hi Steve.
http://www.scientificlinux.org/
It seems to have a good and honourable past / future.
( I'm sure you know about it but there might be someone who doesn't ;)
Cheers... Clark

There is a hopeful post at http://qaweb.dev.centos.org/qa/blog

Phil.

[Volker Kuhlmann]

Post by Clark Mills
http://www.scientificlinux.org/

Oh my goodness. I installed that once on request for someone (it didn't
last long). It's made for a specific purpose: desktop with science
software. It was woefully out of date and doesn't have the maintenance
power of more mainstream choices. Security is probably not a priority
for most of its users. If you're looking for something to make a server
with, keep looking.

Volker

[Clark Mills]

Post by Volker Kuhlmann

Post by Clark Mills
http://www.scientificlinux.org/

Oh my goodness. I installed that once on request for someone (it didn't
last long). It's made for a specific purpose: desktop with science
software. It was woefully out of date and doesn't have the maintenance
power of more mainstream choices. Security is probably not a priority
for most of its users. If you're looking for something to make a server
with, keep looking.
Volker

Hi Volker.

How long ago did you install it? I haven't installed it yet but looking
at their site they seem up to date (at a glance at least...).

Cheers... Clark

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Steve Holdoway]

Post by Clark Mills

Post by Volker Kuhlmann

Post by Clark Mills
http://www.scientificlinux.org/

Oh my goodness. I installed that once on request for someone (it didn't
last long). It's made for a specific purpose: desktop with science
software. It was woefully out of date and doesn't have the maintenance
power of more mainstream choices. Security is probably not a priority
for most of its users. If you're looking for something to make a server
with, keep looking.
Volker

Hi Volker.
How long ago did you install it? I haven't installed it yet but looking
at their site they seem up to date (at a glance at least...).
Cheers... Clark

The problem with this is that it is a *superset* of RedHat. An absolute
irrelevance I know, but it'll be enough for third party providers to
suck their teeth and refuse to honour guarantees. Which is something
they couldn't really do with CentOS.

For a server, I look no further than debian by choice.

Cheers,

Steve

[Clark Mills]

Post by Steve Holdoway
The problem with this is that it is a *superset* of RedHat. An absolute
irrelevance I know, but it'll be enough for third party providers to
suck their teeth and refuse to honour guarantees. Which is something
they couldn't really do with CentOS.
For a server, I look no further than debian by choice.

Hi Steve.

Vendors have been using that excuse with CentOS forever but generally we
can make things work and if it's important enough then getting a RHEL
license isn't too much.

CentOS is just falling too far behind. When I think about it, I would
probably trust the makers of SL over CO given both of their histories.
Still, I'll be able to comment a bit better once I've actually used the
thing.

PS: Surely if it's just a superset, it's simple enough to strip out the
extras?

Cheers... Clark

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Bruce Clement]

Post by Clark Mills
Vendors have been using that excuse with CentOS forever but generally we
can make things work and if it's important enough then getting a RHEL
license isn't too much.

Not wishing to appear to justify arbitrary refusal to honour guarantees but
I see this from the other side in my day job.

My employers certify their product to work in certain environments
(Operating system incl version numbers / Database incl versions / minimum
CPU power / minimum memory size / minimum disk size). For each of those
environments we maintain virtual machine(s) and pay someone to ensure that
the product tests have run correctly before making a release and where
necessary a developer has made the necessary changes. There is a real cost
involved in this testing.

Customers do sometimes ignore our advise about supported versions and if we
can't reproduce the problem on a version we know about we have big problems
... do we add the version to our list of supported versions, incurring the
cost of ongoing testing, do we establish and then discard a development
environment for a "one off" fix or do we dig our heels in and risk losing
that customer? This is a commercial decision each time & I'm glad I'm not
the one who makes it.

Post by Clark Mills
PS: Surely if it's just a superset, it's simple enough to strip out the
extras?

Sounds good, unfortunately you do sometimes get unexpected breakages on
apparently trivial version changes.

At a previous job I saw an in-house developed system that worked just dandy
on one version of database server software break on a minor patch level
change ... the system had errors in the parameters it passed to the
database software but this was masked by a fault in the older version of
the database server ...
--
Bruce Clement

Home: http://www.clement.co.nz/
Twitter: http://twitter.com/Bruce_Clement
Directory: http://www.searchme.co.nz/

"Before attempting to create something new, it is vital to have a good
appreciation of everything that already exists in this field." Mikhail
Kalashnikov
_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Volker Kuhlmann]

Post by Steve Holdoway
The problem with this is that it is a *superset* of RedHat. An absolute
irrelevance I know, but it'll be enough for third party providers to
suck their teeth and refuse to honour guarantees. Which is something
they couldn't really do with CentOS.

?!????

You make as much sense as S.L.'s "based on Enterprise Linux" when there
isn't one...

Volker

[Steve Holdoway]

Post by Volker Kuhlmann

Post by Steve Holdoway
The problem with this is that it is a *superset* of RedHat. An absolute
irrelevance I know, but it'll be enough for third party providers to
suck their teeth and refuse to honour guarantees. Which is something
they couldn't really do with CentOS.

?!????

CentOS is built from the same source code as RedHat. Only the branding
is removed. End result = executables bit compatible with RedHat.

Post by Volker Kuhlmann
You make as much sense as S.L.'s "based on Enterprise Linux" when there
isn't one...

http://www.redhat.com/rhel/

Post by Volker Kuhlmann
Volker

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Volker Kuhlmann]

Post by Steve Holdoway
CentOS is built from the same source code as RedHat. Only the
branding is removed. End result = executables bit compatible with
RedHat.

Yes but who cares? Nobody has warranties anyway.

Post by Steve Holdoway

Post by Volker Kuhlmann
You make as much sense as S.L.'s "based on Enterprise Linux" when there
isn't one...

http://www.redhat.com/rhel/

You must be wrong. They must mean SLES.
D'oh.

Volker

[Steve Holdoway]

Post by Volker Kuhlmann

Post by Steve Holdoway
CentOS is built from the same source code as RedHat. Only the
branding is removed. End result = executables bit compatible with
RedHat.

Yes but who cares? Nobody has warranties anyway.

Whether it's a warranty or an added product not playing nice with the
core RHEL ones, you're out on your own. As we're talking server software
here, neither is perferable.

Post by Volker Kuhlmann

Post by Steve Holdoway

Post by Volker Kuhlmann
You make as much sense as S.L.'s "based on Enterprise Linux" when there
isn't one...

http://www.redhat.com/rhel/

You must be wrong. They must mean SLES.
D'oh.
Volker

The sellouts?? No I don't think Novell is a serious contender to any
except the most die-hard supporter, remembering the SuSE glory days of
yore.

Steve.


_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug

[Volker Kuhlmann]

Post by Clark Mills
How long ago did you install it? I haven't installed it yet but
looking at their site they seem up to date (at a glance at
least...).

Good question - bad guess about 3 years ago. It's possible they're more
uptodate now, but there wouldn't be a particular reason to do so. I
wouldn't use it for a server, uptodate or not.

Volker

[Clark Mills]

Post by Volker Kuhlmann
Good question - bad guess about 3 years ago. It's possible they're more
uptodate now, but there wouldn't be a particular reason to do so. I
wouldn't use it for a server, uptodate or not.
Volker

Fair enough but I'm going to give it a whirl, DL'ing it now.

Whee! It's coming down so FAST. I guess everyone has been scared off
downloading and there is bandwidth to spare! ;)

I'll give my first impressions (not that anyone cares but more for the
record) once I've had a play.

Cheers... Clark

_______________________________________________
NZLUG mailing list ***@linux.net.nz
http://www.linux.net.nz/cgi-bin/mailman/listinfo/nzlug