Re: RST.B .... can anyone shed some light?
From: Rick Moen (rick_at_linuxmafia.com)
Date: 01/17/05
- Next message: Murphy: "Re: Basic Permissions"
- Previous message: Vilmos Soti: "Re: Basic Permissions"
- In reply to: jayjwa: "Re: RST.B .... can anyone shed some light?"
- Next in thread: jayjwa: "Re: RST.B .... can anyone shed some light?"
- Reply: jayjwa: "Re: RST.B .... can anyone shed some light?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 17 Jan 2005 08:44:07 GMT
jayjwa <jayjwa@nowhere.org> wrote:
> On 2005-01-09, twism78@gmail.com <twism78@gmail.com> wrote:
>> Hello all,
>>
>> My name is Dave Rosendahl, and unfortunately it seems one of my
>> company's servers has been hit by the RST.B virus.
>>
>> Does anyone know of an appropriate solution? It seems everything I can
>> find online is at least 3 years old.
>>
>> If so, any advice would be appreciated!
>> Thanks in advance,
>> Dave Rosendahl (twism78@gmail.com)
>>
>
> If you just want to remove it, login to this ftp server:
>
> us-2.updates.f-prot.com
"Just remove it"? I would think he'd want to know what happened, and
whether there's been a security breach. If the latter, then "just
removing it" plainly doesn't solve the real, underlying problem that
the system is broken and needs to be rebuilt and the holes plugged.
The original poster didn't really tell us what happened, but let's
assume for the sake of discussion that he has good reason to believe
that RST.B has really been appended to one or more system binary, i.e.,
by someone with privileged access. _If so_, then he doesn't know what
else about his system has been gimmicked, and basically can no longer
trust the system software, user accounts/passwords, system configuration
files, or user dotfiles. His best course of action, in that case, is
to immediately kill system power, then bring the system back up using
separate maintenance media, then do at least one full backup, then a
full system rebuild from trusted media without reusing any of the
aforementioned compromised data.
"Just removing" an artifact of root compromise doesn't cut it. It may
be standard practice on OSes with no hope of lasting system security in
the first place, but not on *ix.
> Here's some extra info on RST. I've got a disassembly of it as well, but it's
> too big to post here. Why you're seeing this old virus now is likely thanks to
> the SSH attacks by script kiddies a few months back. Almost all of their tools
> I came across where infected by RST and also OSF viruses. So, any machine the
> little maggots touched got infected, probably without them even knowing it.
> The server that RST tries to contact is long gone, and it's easy to spot RST
> binaries as they have the strings "snortdos" and "tory" in them. Frequently
> you will find RST attached to a root exploit, such as the old ptrace bug (my
> new prediction: more RST, this time, attached to binfmt_elf uselib bug, spread
> by script kiddies thru SSH attacks. I've seen a five-time increase this week
> in SSH bruteforce attempts !).
And so you think he's _root-compromised_, but recommend that he "just
remove" an aftereffect of that compromise? You're joking, right -- or
am I misinterpreting?
-- Cheers, Hardware: The part you kick. Rick Moen Software: The part you boot. rick@linuxmafia.com
- Next message: Murphy: "Re: Basic Permissions"
- Previous message: Vilmos Soti: "Re: Basic Permissions"
- In reply to: jayjwa: "Re: RST.B .... can anyone shed some light?"
- Next in thread: jayjwa: "Re: RST.B .... can anyone shed some light?"
- Reply: jayjwa: "Re: RST.B .... can anyone shed some light?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
