[lug] outgoing port 220 exploit?

[D. Stimits]

Kevin Fenzi wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>>"D" == D Stimits  writes:
>
>
> D> David Anselmi wrote:
>
> >>Every 5 seconds:
> >>
> >>lsof -i4tcp:220
> >>
> >>Dave
>
>
> D> I've tried lsof and netstat with -c, none show it. A failed connect
> D> takes all of about 50 milliseconds, so I'd have to hit it in that
> D> time. Anything taking a "snapshot", and not reading 100% of
> D> anything using the port 6129, or attempting outgoing 220, will
> D> fail. Due to firewall rules, even tcpdump will not work, as blocked
> D> packets do not get recorded.
>
> What do your incoming rules say about port 6129?


All incoming to port 6129 are now blocked, but 6129 is the port on the 
local machine during outgoing. All source ports 6129, no matter where, 
are logged and blocked. All destination ports 220, no matter where, are 
logged and blocked. Both locally and via the bridge.

>
> I suspect this is someone scanning for a windows 'DameWare' server
> thats vulnerable to attack:

See this is the part that does not match that makes it look like a 
compromise...port 6129 is not being blocked, it is the source. 
Destination is 220 imap. I've checked for root kits and all kinds of 
files, I do plan to reinstall one machine, but there are 3 separate KRUD 
machines with 3 separate major versions that all do this. They do not 
correspond to cron times, though they are on a regular basis. Domains 
and ip's are not predictable, so I can't do something like a loopback 
intercept to then allow it to try the exploit to see what it does.

Port 6129 and 220 are both blocked and neither has anything listening on 
the port, I have tried from both inside the local domain and outside.

>
> http://archives.neohapsis.com/archives/incidents/2002-08/0097.html
>
> The packet comes in to port 6129 on your machines, and they have setup
> their incoming packet so the reply goes back to port 220 on the
> sending machine (in this case it should be a connection refused,
> unless you are running DameWare).

I have not tracked the packing coming in, only attempting to go out. 
This is the mystery that makes it look like a compromise (though 
everything I checked says it isn't compromised), that I can't find it. 
But if it is a packet coming in and then the incoming ceases, things 
like lsof and netstat won't see it, they are too slow. I am thinking of 
writing a program to bind 6129 and see what happens.

>
> You are using ipchains, which is not a statefull packet filter, so you
> are likely allowing all non privleged ports in, ie, 1024:65535...
> so they would be able to get a 6129 packet in?

Some of the ports above 1023 are open via firewall, but not running 
services, on only 1 machine. The other 2 machines use iptables and the 
same thing is happening.

>
> Does:
>
> fuser -n tcp 6129


This shows nothing, as does lsof and netstat and tcpdump. FYI, I 
forcibly replaced some of the relative testing tools just in case.

>
>
> show anything on your machines?

Nothing. I need to find the incoming, or verify a process. I fear I have 
to open the firewall outbound to have it run long enough to catch it, 
perhaps 5 seconds.

I wish I knew of some exploit that breaks port 220, then I could 
investigate to see if that particular exploit was on my machine. But it 
looks like a relay at this point rather than compromise. I don't know 
for sure so I can't stop looking.

D. Stimits, stimits AT comcast DOT net