SharePoint administration port security

Been doing some research on SharePoint lately, mostly focused on SharePoint Services 2.0, since that’s a dependency of Team Foundation Server.

The SharePoint “administration port” is an interesting feature, if for no other reason than what this TechNet article has to say about it. See the “About Remote Administration and Security” section about two-thirds of the way down.

My recommendation to SharePoint administrators (even if that’s your title only by default) of the world would be to read those instructions carefully, since the default installation requires authentication (good) to the remote admin site, but doesn’t require encryption (bad). Thus, you may be entering sensitive information, such as a password, that can be sniffed on the wire. Be sure to require SSL – there are instructions on that page for doing so.

As an aside, I don’t see why the default installation doesn’t require SSL (and update the shortcuts to the https URL). If there’s no suitable Server Authentication certificate available, just create a self-signed one and warn the admin. That’s better than no-encryption-by-default. Maybe SharePoint 3.0 fixed that; I haven’t checked.

Anyway, what prompted me to post about this is the following text from that article:

“Require the use of a non-standard HTTP port for accessing the Central Administration pages. This precaution makes it much more difficult for malicious users to guess the URL of HTML Administration pages or the remote administration programs. When you install Windows SharePoint Services on the Microsoft Windows platform, a random non-standard administration port is automatically used for the SharePoint Central Administration pages.”

Much more difficult, huh? Well, the use of a non-standard port is not an effective security measure. In fact, the fact that the SharePoint administration console requires its own web port actually makes remote fingerprinting easier. That is, it helps an attacker identify server roles, and versions, simply by scanning for open ports. I’ll demonstrate with the port scanning tool nmap.

Suppose that I’m initiating a network-based penetration test, I’ve identified some interesting IP addresses, and I want to learn more about what’s running on each server. One way to gather more information is to start scanning high ports:

>nmap.exe -r -p1025-65535
Interesting ports on
Not shown: 64507 closed ports
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
2383/tcp open unknown
15130/tcp open unknown

Now we know there are two high ports on the target server that don’t have known protocol or product associations. A more thorough scan of both doesn’t reveal much more about 2383, but tells us that IIS is listening on 15130 and that it requires authentication:

>nmap.exe -A -p15130
Interesting ports on
15130/tcp open http Microsoft IIS webserver 6.0
|_ HTML title: You are not authorized to view this page
| HTTP Auth: HTTP Service requires authentication
| Auth type: Negotiate
|_ Auth type: NTLM
Running: Microsoft Windows 2003
OS details: Microsoft Windows Server 2003 SP1 or SP2

Putting my attacker hat on, I’m thinking to myself, ‘why is there a web server listening on a seemingly random port and why does it require authentication? Not only that, but this machine is running SQL as well. Must be a juicy target! And hey, SQL plus a high web port … could be SharePoint!’

A quick test on the server itself confirms the research:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN>STSADM.EXE -o getadminport
The SharePoint administration port is ":15130:".

I’m summary, SharePoint administration might as well use a fixed port. And I’d rather that the product not open a management port at all, since securing it requires extra work that many customers won’t understand.

5 Responses to “SharePoint administration port security”

  1. […] to do a follow-up to my previous post about Windows SharePoint Services (WSS) security, and using NMap to fingerprint WSS […]

  2. Thanks for excellent article and raising the awarness of security risks. I sure to bookmark your site.

  3. […] Dan Griffin talks to us about his latest research into hacking sharepoint. […]

  4. Very exciting but I found this website not working in the same way you explained?!
    It has SharePoint server installed but you cannot see using nmap command except the port 80 so you cannot guess the central Admin port?

  5. […] Dan Griffin talks to us about his latest research into hacking sharepoint. […]

Leave a Reply