Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: TCP port 10000 cont. / Connecting mismatched protocols - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
TCP port 10000 cont. / Connecting mismatched protocols
More than Veritas on TCP port 10000

Stephane Nasdrovisky sent us a list of other things listening on TCP port 10000.

- webmin: web based unix system administration
http://www.webmin.com/

- Dumaru: worm starting an ftp server on port 10000
http://securityresponse.symantec.com/avcenter/venc/data/w32.dumaru.b@mm.html
(and many more vendors and variants, just one URL as an example)

- Cisco VPNs: use a default TCP port 10000 to do IPSEC over TCP. E.g.:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_tech_note09186a00800946af.shtml#encap

- Backdoor XHX, oracle.zip, ... : there's a collection of malware creating backdoors like port 10000 as well to connect telnet servers among other to it.
http://www.simovits.com/sve/nyhetsarkiv/1999/nyheter9902.html

- Video multicast IETF 56 uses port 10000 (udp)
http://www.ncast.com/ietf/ietf56sfo-info.html

We'll appreciate insight our readers can share esp. in the form of captures of what is being scanned for.

Connecting mismatched protocols and making it work?

It doesn't come as a normal thing to see clients and servers hooked together that speak a different protocol and still expect it to work. At least for me it's almost unnatural to think of it that wat.

Still that's exactly what the less honest people out there do nowadays.

Consider this scenario: You're evil and will try to relay spam through a normally closed network. You don't care all that much about who gets the spam or what it is for, you're hired hand and get paid by the message.

First you slowly scan the net for proxies, especially proxies accidentally configured on web servers are attractive. Sending packets to a web server won't attract all that much attention from defenders and can learn you a lot about their make and chance of it being misconfigured.

Once you see a not so security minded configuration of an apache you fire off a connect request. Such a request is normally used to be able to proxy SSL requests.

Once you have found such a proxy that is either configured to be open (most likely by accident) or a web server also acting as proxy, again most likely an error, you start to learn more about the inside of the network, where's the outgoing smtp server is one of your most pressing questions. But if you find a usenet server you might note it to have some "fun" later on with posting nasty messages in some discussion boards.

Once you find an outgoing SMTP server with an open proxy in it's service are, you're in business if that proxy doesn't restrict you in talking to port 25.
Most defenders won't realize they're not safe, after all they don't have an open relay. Nor will they presume hooking HTTP and SMTP together as a viable option.

So how do they hook together?
the HTTP proxy will send a HTTP header to the SMTP server and the SMTP server won't understand the commands, but that's all to be discarded. After the header you, the hacker gets control and due to the friendliness in these protocols they won't break the connection due to excessive errors all that easily. So one the data you supplied get through, you managed to type SMTP commands and that the SMTP server will understand.
NNTP works the same, it just has other commands it will understand but it will sit through the errors from it's perspective while receiving the HTTP headers.

Back to the real world.

So what can a defender like you do ?
- make sure your proxies do not allow connections to well known ports other than typical HTTP and HTTPS ports.

- make sure your web server do not have proxies enables without need (apache has the option of having a proxy compiled in, try to compile your own without that possibility)

- Esp. for ISPs and the like: consider your NTTP, SMTP, ... servers that don't need to have your web servers, proxy servers etc in their service area to have those servers removed from being able to relay email.

- Stopping connections after a number fo errors in SMTP and/or NNTP needs to be done carefully, e.g. ESMTP and SMTP servers always exchange an error in the EHLO/HELO handshake but is something for e.g. the IETF to consider in my opinion...

And if you don't prevent this, you'll likely get blacklisted a few times for sending out spam or worse.

--

Swa Frantzen
Swa

760 Posts

Sign Up for Free or Log In to start participating in the conversation!