[432] in Athena User Interface

home help back first fref pref prev next nref lref last post

Fwd: breakins to some MIT Linux machines (Case 185834)

daemon@ATHENA.MIT.EDU (Bill Cattey)
Mon Sep 18 23:45:29 2000

Message-ID: <Atli5Epz0001IecGoo@mit.edu>
Date: Tue, 19 Sep 2000 03:45:20 +0000 ()
From: Bill Cattey <wdc@MIT.EDU>
To: beland@MIT.EDU, lcs@MIT.EDU
CC: ops@MIT.EDU, aui@MIT.EDU

Beland: bad news, apparently on Sunday after you installed all the nice
HelixCode stuff, dig-dug got violated.
I don't think it's the case that the new HelixCode stuff listens on port 39168.

I've had Larry unplug dig-dug from the net now.  We should agree on
someone to re-install the requisite everything.

-wdc

P.S. I guess we really DO need that test-cluster-w92 email list.  If
Mike Barker hadn't forwarded this to me, it's unclear the news would
have reached the right people.

---------- Forwarded message begins here ----------

Date: Mon, 18 Sep 2000 19:50:50 -0400
To: wdc@mit.edu
From: Mike Barker <mbarker@MIT.EDU>
Subject: Fwd: breakins to some MIT Linux machines (Case 185834)

Hi, Bill.

I think the relevant machine is probably dig-dug.  I seem to remember that 
as one of the test cluster machines.

Someone should disconnect that machine and fix it up.

(and we still need to get together for lunch or something!)

Thanks
Mike

>From: <mhpower@MIT.EDU>
>Date: Sun, 17 Sep 2000 23:52:47 -0400
>To: sshurt@MIT.EDU, amayc@MIT.EDU, ntt@MIT.EDU, cluhrs@MIT.EDU,
>         the_geek@MIT.EDU, sswenson@MIT.EDU, frey@MIT.EDU, rgmisra@MIT.EDU,
>         mrewiens@MIT.EDU, konda@MIT.EDU, mbarker@MIT.EDU, bac@MIT.EDU,
>         rph@MIT.EDU, bonawitz@MIT.EDU, hell2001@MIT.EDU, dodoo@MIT.EDU,
>         walt@MIT.EDU, sidchang@MIT.EDU, bruen@MIT.EDU,
postmaster@lids.mit.edu,
>         strohon@MIT.EDU, baker@deslab.mit.edu
>Cc: net-security@MIT.EDU, rcc-dorm-w61@MIT.EDU, rcc-dorm-w70@MIT.EDU,
>         rcc-dorm-nw61@MIT.EDU, rcc-dorm-e2@MIT.EDU, rcc-dorm-w51@MIT.EDU,
>         rcc-dorm-62@MIT.EDU, rcc-dorm-w1@MIT.EDU, rcc-dorm-nw10@MIT.EDU,
>         rcc-dorm-w85@MIT.EDU, test-cluster@MIT.EDU, rcc-dorm-64@MIT.EDU,
>         rcc-dorm-w4@MIT.EDU, rcc-dorm-w71@MIT.EDU, rcc-dorm-w7@MIT.EDU,
>         rcc-dorm-w84@MIT.EDU
>Subject: breakins to some MIT Linux machines (Case 185834)
>Reply-To: net-security@MIT.EDU
>X-Reply: n
>X-Cc: n
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
>If you are named on the "To:" line above, this message concerns a
>security situation on a computer that is either registered under your
>name, or is located in your research lab. This computer (the names are
>specified below) must be immediately disconnected from MIT's network,
>e.g., by unplugging the network cabble from the machine.
>
>There has been a recent breakin to these MIT Linux machines:
>
>GLOBALIZATION.MIT.EDU (18.172.0.106)
>GYRO.MIT.EDU (18.239.2.158)
>WIMANMEG.MIT.EDU (18.241.2.40)
>WEAPONOFWOOT.MIT.EDU (18.243.0.104)
>MAD-HACKER.MIT.EDU (18.244.1.198)
>SLAPSHOT.MIT.EDU (18.247.1.172)
>DISCREPANCY.MIT.EDU (18.248.2.53)
>NOIDEA.MIT.EDU (18.250.3.154)
>MREWIENS.MIT.EDU (18.252.2.79)
>KONDA.MIT.EDU (18.98.2.47)
>DIG-DUG.MIT.EDU (18.18.1.242)
>BENELLI.MIT.EDU (18.238.1.40)
>SIBELIUS.MIT.EDU (18.240.1.191)
>CHEESEHAT.MIT.EDU (18.242.1.162)
>SHAGADELIC.MIT.EDU (18.245.2.251)
>SAHARA.MIT.EDU (18.247.2.29)
>WINKLE.MIT.EDU (18.250.1.248)
>BARLEY.MIT.EDU (18.251.2.240)
>ISELA.MIT.EDU (18.38.0.236)
>JOURNEY.MIT.EDU (18.78.0.100)      
>
>These machines were found listening on tcp port 39168, which is the
>port used by the server side of the rpc.statd exploit code. It is
>extremely unlikely that any Linux system would be listening on tcp
>port 39168 unless it had been a victim of this exploit.
>
>The intruder most likely installed a modified version of sshd
>listening on tcp port 1524. The intruder almost certainly knows the
>password that can be used to connect to that port and obtain root
>access. There were very likely many Linux programs replaced by the
>intruder with versions that either (a) provide another backdoor root
>access mechanism, or (b) help to hide the intruder's changes to the
>system. These may include in.fingerd, in.ftpd, named, top, and ps --
>however, this is definitely not a comprehensive list.
>
>To recover from the breakin, it will be necessary to erase your entire
>current Linux installation and reinstall. A reinstallation procedure
>for Red Hat Linux 6.2 i386 (currently the most common Linux
>distribution in use at MIT) is appended below. Please leave the
>network cable disconnected from this machine until after finishing
>step four in the reinstallation procedure.
>
>The rpc.statd vulnerability that led to the breakin is described at
>http://www.cert.org/advisories/CA-2000-17.html
>
>The rpc.statd issue is currently, by far, the most common method of
>breakins to MIT computers, with a few dozen affected so far this
>month.
>
>To keep up with Red Hat security patches in the future, fill out the
>"Subscribing to Redhat-watch-list" form on this web page:
>
>    https://listman.redhat.com/mailman/listinfo/redhat-watch-list
>
>(There are similar resources available for software other than
>Red Hat's.)
>
>Please let us know (via e-mail to net-security@mit.edu) when the
>reinstallation is completed.
>
>Matt Power
>Network Security team, MIT Information Systems
>
>
>- ------- Forwarded Reinstallation Notes
>
>REINSTALLATION PROCESS
>
>If you will be using Red Hat Linux version 6.2, be sure to obtain all
>applicable security patches from Red Hat or a mirror site such as
>
>   ftp://rpmfind.net/linux/redhat/updates/6.2/i386/
>
>(By "applicable" security patches, we mean ones that update a package
>that you already chose to install. The -F rpm option may be useful
>for installing the applicable patches; from the rpm man page:
>
>    rpm [-F|--freshen] [install-options] <package_file>+
>
>    This will upgrade packages, but only if an earlier version
>    currently exists.
>)
>
>In general, the reinstallation process needs to be:
>
>1) Backup any files of your own that are stored on this system.
>
>2) Reinstall your operating system, being sure to choose the
>    option to format the drive that will hold the operating-system
>    files. Also, select a root password (and a user account
>    password, if a user account is added during installation) that
>    is different from any password used in the past.
>
>3) After reinstallation, you will be able to boot the machine
>    from its hard drive, and then log in as root.
>
>4) Shut down some services that are affected by vulnerabilities
>    in the default installation. For Red Hat 6.2, the three commands
>    to type are:
>
>      /etc/rc.d/init.d/inet stop
>      /etc/rc.d/init.d/nfslock stop
>      /etc/rc.d/init.d/smb stop
>
>5) Contact net-security to have your network connectivity restored.
>    [Applicable if network connectivity was turned off due to a
>    system compromise]
>
>6) Download and apply all vendor security patches.
>
>7) When re-adding user accounts, make sure each account gets a
>    different password than it had during the time when the
>    machine was compromised. This is important because the intruder
>    probably copied your machine's encrypted-password file and
>    fed it to a password-guessing program.
>
>8) If any passwords for any other systems had been typed on the
>    compromised machine (either typed directly on its keyboard or
>    typed in a remote-login session involving the compromised
>    machine), arrange for those passwords to also be changed.
>
>
>After this is complete, we ask that you send us mail (to
>net-security@mit.edu) asserting that you have completed the above
>steps. This will allow us to take your machine off of our 'watch
>list'.
>
>You must not allow this machine to remain connected to the network 
>until the full process is complete. Please disconnect the network 
>cable if you need to leave the machine before finishing, so that it 
>cannot be used by the intruders.
>
>To keep up with Red Hat security patches in the future, fill out
>the "Subscribing to Redhat-watch-list" form on this web page:
>
>    https://listman.redhat.com/mailman/listinfo/redhat-watch-list
>
>Please do not run unnecessary services. Red Hat 6.2 defaults to
>having many programs running (or accessible over the network) that
>are seldom needed on Linux systems at MIT. Some services can be 
>disabled by editing /etc/inetd.conf, for example the linuxconf remote 
>access service. Other services can be disabled using chkconfig, for 
>example:   chkconfig --level 0123456 portmap off
>
>- ------- End of Forwarded Reinstallation Notes
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.2
>
>iQCVAwUBOcWQ8KXcG113/1BtAQGXmAP9FgRM20ty839J79C8ED2SKnZTrCLrU8+t
>y8ogbEUK+ThAwbzooFSBDRhrpnd+gg4TLoH7z5nMfWaHGRm8wTLs4qtxlAs4mEn5
>dxtyl8t0fOy3Uu/roP1S6hyuFs2WnbGXJ3zO2ybEDuKWS8G+4fspa9c8SdaK24b5
>cj0blG/4yYI=
>=8KvZ
>-----END PGP SIGNATURE----- 




home help back first fref pref prev next nref lref last post