On Wed, Jul 30, 2014 at 1:29 AM, Brandon Vincent
<[log in to unmask]> wrote:
> On Wed, Jul 30, 2014 at 4:27 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
>> Once someone is in as root, they can manipulate your basic system
>> libraries, including the ones used to build checksums and audit for
>> intrusion. Take it offline and *replace* that OS, ASAP, and consider
>> any passwords used on it to have been compromised.
>
> Thanks for mentioning this, my response was pretty vague.
>
> My recommendation (from an information security standpoint) was aimed
> at determining the root cause of the infection, including reconnecting
> it to a VERY isolated network with detailed host and network
> monitoring. If you have hundreds of similarly configured systems, you
> could have a very large problem soon on your hands. It is always a
> good idea to figure out how an attacker gained access to a system.
>
> Once "cleaned" (note the quotation marks), you can expect the system
> to get reinfected quickly because the botnet operators assume that you
> will restore from your last good backup, leaving the system in its
> vulnerable state once again, so an re-infection will occur easily in
> minutes.
>
> As Nico pointed out, the only solution for returning a system to
> production use is to perform a clean reinstall of the operating system
> with careful analysis of any files copied over to the freshly
> installed system.

I was also only mentioning a single issue. The situation is also a
firm reminder that the "hard crunchy outer shell, soft chewy
underbelly" approach to security is flawed. Once an attacker has
gained access, careless and casual practices like
un-passphrase-protected SSH keys for root access, credential stored in
NFS shares for Subversion or chef administrative access, and don't get
me *started* on folks that use their AD passwords on HTTP based
websites, etc., etc. should all be considered vulnerable.

There are effective approaches to handling network security. They're
often based on layered approaches, so that a penetration of one
externally exposed server does not provide access to user's
credentials because they're not stored locally, and don't provide root
access on the rest of the network.

But I'm afraid they're often ignored, or only applied after the
security vulnerability has been exploited and the credentials stolen
for later entry. There are strong reasons that the Morris Worm
penetrated so much of the UNIX baed Internet, and that Kevin Mitnick
and his followers continue to penetrate "secure" environments.

> Since any passwords on that system may have been compromised, you need
> to change passwords including the root password on all impacted
> systems that share credentials.

And this should be a matter of normal operations. It doesn't mean
"every system needs its own passwords", but sensible Kerberos based
password handling can go a long way towards reducing the risks.


> Since that means they may have gained access to additional systems,
> this would be a good time to look into setting up file integrity
> monitoring and detailed remote logging.

Also assume they've been network sniffing. If they've gotten in with
one kit, you can assume they've been dumping other payloads elsewhere
inside your network. Time for a serious lockdown!!!

>
> Brandon Vincent