19

I'm looking for any guidance around testing a service I've found running on a target server. I'm doing a 'black-box' pen-test and the company is one of those 'I-don't-want-to-tell-you-anything' types so they won't tell us what service is running.

NMap picked up an open port and suggested it was a SIP service, however after testing a number of different SIP attacks/clients it almost certainly is not (the box i'm testing is also supposed to be just a webserver).

I've not had much experience with fuzzing TCP ports before and from what I've found it seems you need to have some information about the protocol first before you can start fuzzing (a template of sorts). Additionally, a 'dictionary' of different things to throw at the service is required as well (which is usually relevant to the type of application your testing). What can I do if I don't have either of these things?

Since I know nothing about the application and what it's expecting it seems like I can't run anything against it. Is that correct? Am I missing something obvious here that will help?

Edit: To be clear, there is Also an Apache+Tomcat web server running on 443 and this is a linux box. That part is not an issue as i've already tested it. Its just this other 'random' port which I have no idea about.

NULLZ
  • 11,426
  • 17
  • 77
  • 111
  • Can you use MITM to capture any legitimate traffic on that port? – Matrix Nov 06 '13 at 07:49
  • @matrix28 no sadly, im an external attacker on the internet and dont have any special acces between me or even the intended users(app is still in dev) – NULLZ Nov 06 '13 at 08:21

3 Answers3

12

You are correct: technically, fuzzing is usually regarded as sending invalid or random requests/data, it's implied that you know what you're testing in order to "break" the input. In some terminology (PDF) white-box fuzzing is the close to former (generated input) and black-box fuzzing (random input) is the latter.

What you're attempting is better described as just "black box testing". The general problem here is that while some protocols (SMTP, IMAP) freely offer details with banners, or some (HTTP) are overly chatty about protocol transgressions, there are many that need a magic protocol handshake (LDAP, RPC, and many more).

Try nmap again, but with the version detection turned up to 11 (actually only to 9, but no matter):

nmap -sV --version-all --all-ports -p $port $host

nmap -vvv -A --reason --script="+(safe or default) and not broadcast" -p $port $host

Note in the second example the script prefix of + -- this means run scripts even though they would not ordinarily run. Many plugins will fail to run anyway, you'll need to read the output carefully. Hopefully this will give you some extra info (make sure to use a recent nmap, scripts often hang in old versions).

You haven't given the port or the nmap reason, so I cannot explain why it concluded it was SIP, my best guess is it either responded to a GET or OPTIONS request or it is port 5060 or 5061.

More general advice:

  • it should be easy to confirm or deny the existence a public web server, tune down the nmap rate with -T1 or -T0 in case an IPS is blocking you.
  • make sure to scan SSL with a recent tool in order to properly support contemporary TLS versions and options

Finally, there are other application scanners out there, amap isn't nearly as comprehensive an nmap, but it's worth a shot.

SYN
  • 103
  • 4
mr.spuratic
  • 7,937
  • 25
  • 37
  • You can't use --all-ports and -p $port i don't think...? Neither nmap scan provided any extra information unfortunately.. :( – NULLZ Nov 06 '13 at 23:03
  • 2
    Bother... compare the TTLs, it's possible that a filtering device upstream is catching you out. `--all-ports` is misleading, what it does is override the excluded ports in [version scanning](http://nmap.org/book/vscan-technique.html). – mr.spuratic Nov 07 '13 at 10:50
8

Maybe fire up Wireshark and see if one of the more popular Wireshark protocol dissectors successfully identifies the traffic while you interrogate/probe the service (i.e. use the “decode as” feature to force Wireshark to decode the packets as a particular protocol).

Current list of dissectors: http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/

If it is some private protocol then reverse engineering it may be possible -> https://reverseengineering.stackexchange.com/a/2494.

Community
  • 1
Tate Hansen
  • 13,714
  • 3
  • 40
  • 83
  • Thats an awesome idea. Perhaps it'll pick up something in the initiation (although i dont know what the correct 'initialization' is). Thanks! – NULLZ Nov 06 '13 at 08:19
  • "The Future of Protocol Reversing and Simulation Applied on ZeroAccess" on YouTube: http://www.youtube.com/watch?v=0DRuax76kek – Lex Nov 06 '13 at 11:42
  • 3
    I always run Wireshark while running an nmap scan on unusual ports. It's amazing what you can pick up. – schroeder Nov 06 '13 at 22:26
0

If you face a port with an unknown service you could try amap. Besides, p0f could also help you. These tools were designed exactly for info gathering purpose, so it can be your first try.

r0bag
  • 1