heads up ... another imapd attack source

Just a few minutes ago, another attempted IMAPD breakin.
This one originated from rock.careers.csulb.edu [134.139.149.100].
It was logged at Dec 14 16:59:56 CST.

As a general question, is this mailing list concerned with the
operation of end nodes? It was always my thought that network
operations covered the ether between end nodes.

I don't want to start a big debate, though I would prefer a public
answer by a clued party.

BR

Yea... They are going on all over the net. The problem is that many people are
on the net putting up boxes that have the 'standard' OS install and not
patching the system or following bugtraq etc. They get into one and than
another and another.

There really needs to be a clearing house for companies to get together and
help track down these so called great hackers (script kiddies).

We had a breakin from gtecablemodem.com around midnight and couldn't get a
hold of anyone. We don't peer with them so our contact info was limited. I
even check out the noc page info sites and they (as well at GTE) were not
listed.

But, to this day, they still have an open relay on their cable modem network
that allows script kiddies from around the world to use them(1).

We are starting to put together information for nocs and now we need
numbers for network security in each company... Maybe NANSG (North American
Network Security Group). Than when we attend mettings, we can sign each others
PGP key so we know who we are dealing with.

Christian

(1) if anyone from GTE Cable would like to contact me, I would be glad to give
them the site they are using as a relay.

FYI: Not that I sell shell accounts anyway, but I additionally block all
non-http access, from *.EDU, with tcp_wrappers and my POP3 is wrapped up in
SSH. IMAPD was shot and buried(deleted) a long time ago.

Just about everyone here is running multiple *NIX servers on a *.NET
somewhere, including Phil Howard.

You will find this same situation with most cable modem providers
who give out "wingate" to users. There is a certain cable modem
provider who has significant amounts of open wingates on their network,
capable of being used from the outside.

Nothing is being done to close these, though, until they're abused.
Scanning for them is considered a 'breach of privacy' (rather than a
security assessment) and unfortunately allows people day after day to
abuse other systems with a very difficult-to-trace open relay.

I've been told that newer versions of wingate handed out by these
providers have disabled open relaying from the outside; however,
users can (and do) play and can easily misconfigure them to allow
access from anywhere.

/cah

FYI: Not that I sell shell accounts anyway, but I additionally block all
non-http access, from *.EDU, with tcp_wrappers and my POP3 is wrapped up in
SSH. IMAPD was shot and buried(deleted) a long time ago.

this means that any user who is traveling, and happens to try to get their
mail while accessing from a .edu site won't be able to pick it up.

Only if they are accessing mail on MHSC systems, from an *.EDU dial-up.
There are other dial-up options and MHSC has direct dial-up ports
available. Also, we do allow VPN tunnels from *.EDU, but only to directed
hosts with no routing and on advanced arrangement. The user that does so,
does it under our TOS and AUP.

since imap popularity is growing, lack of imap service is also problematic.

It's balance of problems. We consider the rootkit risk more severe than the
loss of business from *.EDU sites. We have secure POP3 and Web-based (SSL)
mail, we are investigating POP3 over SSL. Those services are allowed to
*.EDU, from MHSC.

As has been shown by others, IMAPD attacks are on the rise. It would not do
for a security advocate to get rootkit'd, just think of the publicity
<grin>. It's one of the things that keep me up at night. Many of the
vulnerable systems are in *.EDU, as has already been shown to my
satisfaction. Granted, MHSC has always viewed *.EDU is a huge potential
security risk. That is an unapologized bias on our part. It is the nature
of the beast. When the reference code, for IMAPD, becomes better written,
or we (MHSC) re-write it ourselves, we will reinstantiate the IMAPD
service. Until then, it remains dead.

A current example is a spammer that I've been tracing for weeks. They
always come from a different host, but it's obviously the same guys, they
are very good. Many of the relays they use have been root'd. The latest one
I've found is at sun.soci.niu.edu. So a SAINT run against it yourself and
see how vulnerable they are. If they aren't root'd now, they soon will be,
IMHO.

I am quickly gaining the unsupported suspicion that spammers may be behind
many of the IMAPD attacks. They are looking for hosts to send their spew
from. Note that this *is* an unsupported view/suspicion, I claim no solid
evidence.

this means that any user who is traveling, and happens to try to get their
mail while accessing from a .edu site won't be able to pick it up.

Only if they are accessing mail on MHSC systems, from an *.EDU dial-up.

That's right. Only an MHSC customer.

There are other dial-up options and MHSC has direct dial-up ports
available. Also, we do allow VPN tunnels from *.EDU, but only to directed
hosts with no routing and on advanced arrangement. The user that does so,
does it under our TOS and AUP.

If they know enough detail "ahead of time". Hence they are prevented from
the benefit of opportunistic access.

since imap popularity is growing, lack of imap service is also problematic.

It's balance of problems. We consider the rootkit risk more severe than the
loss of business from *.EDU sites. We have secure POP3 and Web-based (SSL)

It isn't a question of loss of business from a .edu site. It is a question
of loss of business from an MHSC customer who is traveling.

d/