Sec, blogmal!
02 2009

Categories:

Everything

September '17

MiMiMiMiMiMiMi
28293031123
45678910
11121314151617
18192021222324
2526272829301

Archive:

Tue, 10 Feb 2009

The case of the unknown socket.

A few days ago knarf noticed something strange on one of his boxes:

netstat showed an open socket, but both sockstat or lsof didn't list it at all.

A quick test with telnet confirmed that the port was indeed open.

The port number did not ring a bell - although it was below 1024 (so it was a privileged port) - it was not listed in /etc/services.

Trying to find out where that socket came from we discussed a few ideas - starting with the obvious: A rootkit. It would be unlikely that both sockstat and lsof would be patched to skip that socket and netstat would've been forgotten, but it was still an option.

The second idea was, that lsof/sockstat didn't show anything, because there was no process there. – As the socket did react to connection attempts, this meant that the kernel had to be involved.

Checking the system include headers, the struct socket was quickly located and contained an interesting looking field named so_upcall.

To look at the socket in question, we first need to find it in memory. The easiest way is to get netstat -A. This command gives us the address of the tcp control block (tcpcb) for tcp sockets or the address of the internet protocol control block (inpcb) for udp sockets:

netstat -Aan | grep ' \*\.portno .* LISTEN'

The tcpcb structure contains a pointer to the inpcb structure which in turn has a pointer to the stuct socket which we're currently interested in.

So, lets fire up kgdb and look at the so_upcall element:

p ((struct tcpcb*)0xc1a6bde0)->t_inpcb->inp_socket->so_upcall (for tcp)
p ((struct inpcb*)0xc1a6bde0)->inp_socket->so_upcall (for udp)

A quick test on the ssh socket returned:

$1 = (void (*)(struct socket *, void *, int)) 0

Which is the expected result, as there is an actual process listening, and no upcall necessary.

Our mysterious socket returned:

$2 = (void (*)(struct socket *, void *, int)) 0xc0974250 <svc_vc_soupcall>

So now we can be sure that it is the kernel listening here.

Another quick search for the svc_vc_soupcall function returns a hit in rpc/svc_vc.c pointing us to the source of the socket: The sunrpc subsystem.

And 'lo and behold, a call of rpcinfo listed the strange socket as belonging to nlockmgr, the locking manager for nfs.

Case closed.

- Sec


posted at: 10:08 | Category: /tidbits | permanent link to this entry | 0 comments (trackback)
<< older

powered by blosxom
in 0.00 s