Is my paranoia unfounded or not

Em Quarta, 6 de Junho de 2007 18:56, Ignoramus27187 escreveu:

? Is there any rootkit detection software for Linux?
>
> i

run rkhunter too

On Wed, 06 Jun 2007, in the Usenet newsgroup comp.os.linux.misc, in article
, notbob wrote:

>If you weren't paranoid enough, before, read this:
>
>http://www.cio.com/article/114550

He learned, for example, that an aquarium employee had downloaded an
audio file while eating a sandwich on her lunch break. He learned that
when she played the song, a rootkit hidden inside the song installed
itself on her computer. That rootkit allowed the hacker who'd planted
it to establish a secure tunnel so he could work undetected and "get
root"-administrator's access to the aquarium network.

Windoze user running as "administrator" (which is why everyone tells you
not to try to run as 'root')

What's worse, that lunch break with the sandwich and the song download
had occurred some time before he got there. In fact, the hacker had
captured every card transaction at the aquarium for two years.

Not wishing to belittle the problem, but this story smells of embellished
folklore - the windoze luser being able to remember that she downloaded
the song at lunch (where/how) two years earlier while eating a sandwich.
Did the "song" source (including rootkit) still exist on the lusers hard
disk? Sounds rather inept for a malware author, don't you think?

>IOW, chkrootkit may be useless.

May??? Talk about an understatement!

"chkrootkit" (http://www.chkrootkit.org) and the equally flawed "rkhunter"
(http://www.rootkit.nl) are just about the most useless applications
available. Both are mainly shell scripts, and thus easy to understand.
Both are window dressing ONLY, and are trivial to fool. For example,
both look for a file named "/tmp/.../a" or "/tmp/.../r" and if that is
found they declare you are infected with the 55308 worm (a port scanner
from June 2003). Now, should the malware author do the unthinkable and
change the name of the file to something exotic like "/tmp/.../A" (or
indeed _anything_ other than "/tmp/.../a" or "/tmp/.../r"), neither of
these useless "tools" will find the worm. (In fairness, at least both
make an attempt to search for a file or directory named "...", BUT ONLY
IN SPECIFIC DIRECTORIES - not globally.)

The other problem with both "tools" is frequent false alarms caused by
shoddy coding techniques. An example of this is using 'grep' to search
for the string 'adore' (the Adore worm targeted Red Hat 7.0 system
vulnerabilities in 2001) which will be found in the string 'Isadore' or
'Labradorean', never mind words that are based on 'adore' like 'adorer'
or 'unadored'.

Saw an article in another newsgroup last week where _both_ 'chkrootkit'
and 'rkhunter' were crying about the 'eth0' interface having a packet
sniffer running when none in fact were - the false alarm caused by a
dumb test that used 'grep' on the output of '/sbin/ifconfig' and noted
the string 'PROMISC' in the third line. This was caused by running a DHCP
client, but neither "malware detector" bothered to explain the test, or
note the possible false alarm. Rather interesting, as DHCP and BOOTP
predate either application by over five years.

Bottom line - if either 'chkrootkit' or 'rkhunter' report a positive,
either it's a false alarm, or you've managed to get infected by something
written by a really stupid malware author who hasn't bothered to take the
trivial steps needed to prevent detection by either "tool".

>Your only way to really be sure is to do a fresh reinstall and keep
>security patches current while constantly monitoring your system.

The clean install from trusted media and security updates is always the
sure solution. As for monitoring the system, many users lack the skills
to do so, and must depend on other tools. The classic tool is "tripwire"
(which I understand to be unmaintained now) or it's replacement 'aide'.
There are others of similar concept. These work by using cryptographic
hashes of all files on the system, and comparing these hash values with
a set you created when you installed on a known clean system. This
allows detection of _changes_ (but if it detects a change, is it one
that _you_ made. or a bad guy - you have to update the hashes every time
you do ANY updates). As the hashes are unique to your system rather than
generic, they have an enormously better chance of detecting problems.

Old guy

Moe Trin wrote:
: On Wed, 06 Jun 2007, in the Usenet newsgroup comp.os.linux.misc, in article
: , notbob wrote:

: when she played the song, a rootkit hidden inside the song installed
: itself on her computer. That rootkit allowed the hacker who'd planted
: it to establish a secure tunnel so he could work undetected and "get
: root"-administrator's access to the aquarium network.

: Windoze user running as "administrator" (which is why everyone tells you
: not to try to run as 'root')

Indeed. Someone running as root ( administrator ) pretty much
deserves what they get. This hasn't been needed in half a decade
in the Windows world ( since ME went away ) and has never been
needed in the unix world. The real problem is that so many
folks are stuck back in the 90's or simply don't know
any better.

But whatever- most folks reading COLM aren't that naive (hopefully).

Stan
--
Stan Bischof ("stan" at the below domain)
www.worldbadminton.com

On 2007-06-07, stan-at-worldbadminton.com wrote:
>
> Indeed. Someone running as root ( administrator ) pretty much
> deserves what they get.

I've always felt bad for somebody named Robert Oot, or his cousin,
Richard Oliver Ot.

--keith


--
kkeller-usenet-at-wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

On 06 Jun 2007 20:38:22 GMT, Peter J Ross wrote:
> In comp.os.linux.misc on Wed, 06 Jun 2007 12:56:53 -0500,
>
> Ouch.

I was reading about Julie Amero today (google if you are not
familiar), I would go to my utmost not to access internet from those
home Windows computers, especially with IE.

>> I used it to log on to my home Linux computer using putty and
>> also to a couple sites (eBay and some unimportant informational
>> sites).
>
> You're right to assume that those passwords may have been compromised.
>
>> Later we downloaded some antivirus software and found some viruses.
>>
>> I am now worried that perhaps my keyboard was spied on and that my
>> passwords became known to bad people. Though I changed my passwords in
>> a few days, I am worried that perhaps the "hackers" already broke into
>> my home computer and installed rootkits (so "last" no longer reports
>> correct info, etc).
>
> Do you have sudo permissions when connecting remotely? Did you use su
> and type the root password?

No, I use GNU screen, and had root session open permanently in one of
the screen's virtual sessions. I used root functionality, but did not
type root password. (this means that a hacker who accesses my account,
could get root, but there was no obnvious pattern to look for root
access, like having typed su - ENTER.

> If not, you're probably OK.
>
> Otherwise, I suggest a clean installation. Save your existing files
> and examine them carefully before putting them back.

I will upgrade to F7.

>> Is my paranoia unfounded (eg the probability of this happening is very
>> low), or not?
>
> In general, paranoid people don't get hacked much.
>
>> Is there any rootkit detection software for Linux?
>
> Yes, see other replies.
>
>

I ran one, and will declare vistory at this point.

i

On 2007-06-07, Moe Trin wrote:
>
> ...
>
> The clean install from trusted media and security updates is always the
> sure solution. As for monitoring the system, many users lack the skills
> to do so, and must depend on other tools. The classic tool is "tripwire"
> (which I understand to be unmaintained now) or it's replacement 'aide'.
> There are others of similar concept. These work by using cryptographic
> hashes of all files on the system, and comparing these hash values with
> a set you created when you installed on a known clean system. This
> allows detection of _changes_ (but if it detects a change, is it one
> that _you_ made. or a bad guy - you have to update the hashes every time
> you do ANY updates). As the hashes are unique to your system rather than
> generic, they have an enormously better chance of detecting problems.

Yes, you do have to update the tripwire database every time
you do any changes. My usual operating procedure is to run
tripwire and update the hashes, looking _VERY_ carefully for
anything unexpected; then do the updates or whatever; then
rerun tripwire again. The second tripwire run often detects
many changes to libraries and binaries involved in the
package updates. I try to minimize the time lag through the
process to reduce the time window an attacker could sneak
his changes past me by hiding them among the changes that
are properly the result of the package updates.

I have sometimes wished there was a connection between the
package manager(s) and tripwire, where tripwire would be
more strict about changes to files _NOT_ owned by the
packages that got updated. Reducing the signal to noise
ratio might increase chances to catch the signal if it were
to be present.

--
Robert Riches
spamtrap42-at-verizon.net
(Yes, that is one of my email addresses.)

On Thu, 7 Jun 2007, in the Usenet newsgroup comp.os.linux.misc, in article
<1181246500.156230@newsreg.cos.agilent.com>, stan-at-worldbadminton.com wrote:

>Moe Trin wrote:

>: Windoze user running as "administrator" (which is why everyone tells you
>: not to try to run as 'root')
>
>Indeed. Someone running as root ( administrator ) pretty much
>deserves what they get.

Unfortunately, the world isn't entirely black and white - there are a lot
of gray areas as well. There are some things on a system that require
extra privilege for some tasks. You need only run the command (watch the
line wrap here - this is all on one line from "find" to "null")

[compton ~]$ find / -type f -perm +6000 -a -perm -001 -print | wc -l
2>/dev/null
53
[compton ~]$

to prove this. (find files, starting at /, with SUID or SGID permission
that are world executable, passed to a line count - send errors to the
bit-bucket). What might these be? Delete the pipe to 'wc' to see the
such things as /bin/login, /bin/su, /usr/bin/passwd, /usr/bin/chsh, and
so on. Then ask yourself _why_ these binaries _must_be_ S[GU]ID.

>This hasn't been needed in half a decade in the Windows world ( since
>ME went away ) and has never been needed in the unix world. The real
>problem is that so many folks are stuck back in the 90's or simply
>don't know any better.

I agree with your premise, but as noted above, it's not quite that
simple. (I can't speak of the requirements of windoze - I stopped
using that in 1992, before they invented security.) However, looking
at the headers in some newsgroups I follow, I still see people using
win98 (occasionally win95), so I'm not sure ME "went away". ;-)

>But whatever- most folks reading COLM aren't that naive (hopefully).

In the cited story, the windoze luser snarfed a "song" from somewhere,
and when _playing_ the song, it supposedly installed a root kit. While
this is _much_ less likely in *nix, remember that a lot of applications
used in multi-media are often SUID root (or possibly SGID root) in order
to access the hardware - setting volume, or even shoving bits to
/dev/audio, /dev/mixer, or similar. Are you sure that the "song" (or
what-ever) you downloaded is benign? It used to be that you were told
to download things from trusted locations, which typically included
big name companies, but Sony/BMG screwed that duck in 2005 by including
root-kits on their music CDs (http://catless.ncl.ac.uk/Risks/24.09.html).

Please remember that when you are installing software using the package
manager that comes with your distribution, it almost always _requires_
root permissions to operate. This is the reason less experienced users
are STRONGLY recommended to use packages/applications that are supplied
by their distributor, and avoid installing stuff that they found on some
web-site from Lower Spamistan or what-ever. This is not to say that you
should avoid such applications, but that you should _audit_ them to see
what they are doing. For an 'rpm' based system (Fedora, Mandrake, RedHat,
SuSE and GPL clones thereof), try 'rpm -qlvp /path/to/package-1.2.3-rpm'
to see "what's in there". Debian based distributions like *buntu can use
the 'dpkg -c package-1.2.3.deb' command.

Old guy

On Thu, 7 Jun 2007, in the Usenet newsgroup comp.os.linux.misc, in article
, Keith Keller wrote:

>On 2007-06-07, stan-at-worldbadminton.com wrote:
>>
>> Indeed. Someone running as root ( administrator ) pretty much
>> deserves what they get.
>
>I've always felt bad for somebody named Robert Oot, or his cousin,
>Richard Oliver Ot.

While a lot of tradition exists that UNIX usernames are often formed
from the 'first initial, last name' - there is also the tradition of
using 'first name, last initial' when the other scheme may conflict
with an existing user. Thus, 'roberto' and 'richardo' would be
worth looking at. What - you say you have another individual named
Roberto Clements? OK - who is going to be "robert1" or similar ;-)

Hmmm, that piqued my interest... the Phoenix (Arizona, USA - metro
population about 2.5e6) telephone book lists

[compton ~]$ grep ^OOT phone.PHX | cut -d' ' -f1 | column
OOTE OOTEN OOTON OOTS
[compton ~]$ egrep '^OT.? ' phone.PHX | cut -d' ' -f1 | column
OTA OTO OTT OTU
[compton ~]$ wc -l phone.PHX
837489 phone.PHX
[compton ~]$

Well, those names don't seem to be very common - of course, Mister Oot
or Mister Ot might have unlisted phones. ;-)

Old guy

On Fri, 08 Jun 2007, in the Usenet newsgroup comp.os.linux.misc, in article
, Robert M. Riches Jr. wrote:

>Yes, you do have to update the tripwire database every time
>you do any changes. My usual operating procedure is to run
>tripwire and update the hashes, looking _VERY_ carefully for
>anything unexpected; then do the updates or whatever; then
>rerun tripwire again. The second tripwire run often detects
>many changes to libraries and binaries involved in the
>package updates. I try to minimize the time lag through the
>process to reduce the time window an attacker could sneak
>his changes past me by hiding them among the changes that
>are properly the result of the package updates.

IN THEORY - if you are that paranoid about someone sneaking in and
altering the system, you really shouldn't be running tripwire on a
system - much less a system that is in multi-user mode. For maximum
assurance (though still not fool-proof), down the system completely,
and run the tripwire style checks from a separate O/S (perhaps a liveCD
or boot-floppy. To be safer, you should run from 'read-only' media
and cut a new CD (or similar) when there are updates.

IN PRACTICE, most of us are not targets of three-letter agencies or
similar, and need not go to those extremes. The tripwire databases
should certainly be on separate media that is normally locked in a
safe or similar, and the tripwire _binary_ should be statically
compiled (also stored on removable media) and you may want to avoid
using a modular kernel when security is paramount, but are they
really out to get you? ;-)

>I have sometimes wished there was a connection between the
>package manager(s) and tripwire, where tripwire would be
>more strict about changes to files _NOT_ owned by the
>packages that got updated.

I'm not using tripwire, but check the configuration file. It is
_possible_ (not necessarily _practical_) to exclude files and such
from the oversight. Depending on how paranoid you are, I'm not
sure I'd decide to ignore (or reduce surveillance) system files just
because they are under package management. Neither debsums -s, rpm -V,
or pkgchk are as thorough in checking files, and in some cases they
ignore files they know will change.

[compton ~]$ rpm -Vf /etc/passwd | column
S.5....T c /etc/hosts.allow S.5....T c /etc/profile
S.5....T c /etc/hosts.deny ..?..... c /etc/securetty
missing /etc/printcap S.5....T c /etc/services
[compton ~]$

I _really_ doubt that my /etc/passwd is unchanged from that which was
supplied by the package manager.

>Reducing the signal to noise ratio might increase chances to catch
>the signal if it were to be present.

I know what you are saying - but that's what computers are for. I'm
sure you could create a script that queried your package manager for
dates, and would alter the process (alarm level? I dunno) in some
manner. Would it be an equitable tradeoff?

Old guy

On 2007-06-08, Moe Trin wrote:
>
> In the cited story, the windoze luser snarfed a "song" from somewhere,
> and when _playing_ the song, it supposedly installed a root kit. While
> this is _much_ less likely in *nix, remember that a lot of applications
> used in multi-media are often SUID root (or possibly SGID root) in order
> to access the hardware - setting volume, or even shoving bits to
> /dev/audio, /dev/mixer, or similar. Are you sure that the "song" (or
> what-ever) you downloaded is benign? It used to be that you were told
> to download things from trusted locations, which typically included
> big name companies, but Sony/BMG screwed that duck in 2005 by including
> root-kits on their music CDs (http://catless.ncl.ac.uk/Risks/24.09.html).

Actually, there is no need for audio players to be suid
root. On my Mandriva 2007.0 system, when I do

ls -l `which play mplayer realplay` /usr/lib/RealPlayer10GOLD/realplay

I get

-rwxr-xr-x 1 root root 7152796 Mar 12 10:58 /usr/bin/mplayer
-rwxr-xr-x 1 root root 7715 May 8 2006 /usr/bin/play
lrwxrwxrwx 1 root root 39 Dec 29 17:04 /usr/bin/realplay -> ../../usr/lib/RealPlayer10GOLD/realplay
-rwxr-xr-x 1 root root 2485 Sep 14 2006 /usr/lib/RealPlayer10GOLD/realplay

Those programs work just fine when run as a normal user,
perhaps with the user needing to be added to the audio
group. I just tested all three programs playing the old
standby phone.wav file.

--
Robert Riches
spamtrap42-at-verizon.net
(Yes, that is one of my email addresses.)