Re: RH 7.2 intrusion ?

• Previous message: payton: "Re: buffer overflow to spawn shell"
• In reply to: nwjb: "RH 7.2 intrusion ?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Wed, 02 Feb 2005 10:43:46 -0600

In article <opslkabao0ya5exm@news.online.fr>, nwjb wrote:

>On one of ou customer's site a RH 7.2 HP server

Version Released Name Last Updated "in service"
redhat-7.2 22 Oct 01 enigma 31 Dec 03 26 mo
redhat-7.3 6 May 02 valhalla 31 Dec 03 20 mo
redhat-8.0 30 Sep 02 psyche 31 Dec 03 15 mo
redhat-9 7 Apr 03 shrike 30 Apr 04 13 mo

Why is the system using such an obsolete version? When was it last
updated for the numerous security holes that were discovered over the
life of that distribution?

>no web access (no dns, ...), but a netgear dsl router on the lan,

And the DSL router connects to...

>Before yesterday:
>.connecting as root through console was always OK
>.connecting as root through telnet sometimes gave "illegal password" ,

"sometimes"??? Who screwed up the security setting (man securetty)?
The system should return "login incorrect" for that idiocy - ALWAYS.

>in this case we used to connect as "normal" user and su - root , this
>always worked.

This infers possibly unfound trust in the security of the packets over
the wire. EVERYTHING in a telnet session including the password in the
'su' command is sent over as clear text that anyone can sniff.

> From yesterday on:
>.We just created a new user account for FTP transfers. This account worked
>for a while.
>.15 minutes later this account no longer worked (invalid password) with
>FTP , but sometimes worked with telnet (but not always).
>.the su - account gives "cannot set groups" and exits
>.the /var/log/messages contains pam messages indicating that some files
>are world readable/writable (securetty , ftpusers,shells).
>.oracle executable has 777 protection instead of 6751
>.Investigating shows that all /etc files are 777 protection , /bin/su no
>longer has suid attribute

Take your pick - the box has been r00ted, or there is an individual with
root privileges logged in who is issuing incredibly stupid commands without
understanding their effects.

>.we reset file protections to what it shouls be (/etc ..., /bin/su, oracle)
>.system works OK
>.15 minutes later : the file protections are reset to 777

Need I repeat myself?

>.Active processes seen "normal" , no special cron's,
>.bashrc,bashrc,.bash-profile
> seem OK, the rc.d xxx contains no recent files

Normally, I'd suggest running 'rpm -Va > files.2.check' but this sounds
as if the box has been so badly compromised that a better solution is to
simply wipe and reinstall from scratch. However, the distribution is so
ancient, that it should be replaced with something ANYTHING current.

  Newsgroups: comp.security.announce
  Subject: CERT Summary CS-98.06
  Date: 11 Jun 1998 20:05:13 GMT

  3. Root Compromises

   We continue to receive daily reports of sites that have suffered a
   root compromise. Many of these compromises can be traced to systems
   that are unpatched or misconfigured, which the intruders exploit
   using well-known vulnerabilities for which CERT advisories have
   been published.

>What we did:
>.disconnect the router from dsl line (it seems there remains other routers
>on the LAN)
>.change root password

1. Disconnect this system - not the DSL router
2. Most rootkits install a shell that doesn't need access to the root password

>Other information (not related , but ...) this server was installed in
>september and

Why was a distribution that has been unsupported since December 2003
installed in September 2004?

>replaced an older one. The new one has thes same IP@ than the old one ,
>which has a new address. Could "something" in the old server run with old
>IP address and do "things" on the new one. We just changed IP@ in hosts
>and sysconfig/network...

A fubared configuration on the old server will break connectivity with
the new server, but isn't going to be changing permissions and such on
the new system. That requires commands to be run ON the new server.

Changing the IP address is done by changing /etc/hosts and the appropriate
/etc/sysconfig/network-scripts/ifcfg-eth? file. If you use DNS or NIS, the
zone files on all DNS/NIS servers also must be changed. If you do not use
DNS or NIS, then the hosts files on all other systems that had the old data
have to be changed. If you change the _hostname_ on the system, then
/etc/HOSTNAME and /etc/sysconfig/network also have to be changed at the
very least.

>Thanks for any idea about the cause and remedy....

You are posting from Club Internet, France. See

http://tldp.org/guides.html
  2. Linux Consultants Guide
     http://tldp.org/LDP/lcg/html/index.html

which, while old, lists 42 companies/organizations/individuals in France
(see section 26) who can provide some guidance.

        Old guy

• Previous message: payton: "Re: buffer overflow to spawn shell"
• In reply to: nwjb: "RH 7.2 intrusion ?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]