Dan Griffin's Blog
Comments on security, PKI, smart cards, cryptography, and entrepreneurship.
Hacking SharePoint, Part 2
September 10, 2008
Wanted to do a follow-up to my previous post about Windows SharePoint Services (WSS) security, and using NMap to fingerprint WSS servers.
Actually, this post is closely related. While NMap is useful for enumerating and classifying computers on a LAN, it doesn’t scale nearly as well to larger address spaces (although it has its place there; more on that at the end of this post). The thing is, if you’re looking for WSS servers on the internet, Google is a great tool.
There’s a great introductory post on this subject here. For a taste, try the following search:
"all site content" site:.com
The results you see consist of all of the sites in the .com TLD that have exposed their WSS content publicly to the internet. And not to spoil the surprise, but there are lots of them.
Here’s the thing. Gartner suggests that, in the next couple of years, WSS will be more prevalent than LAN-based file shares. For the majority of those who make that transition, it’ll be the same content exposed via WSS that was previously on the LAN shares.
This is a slippery slope, though, because as you can see from the Google search above, large numbers of WSS servers are now publicly exposed on the internet. There are several reasons for this:
- WSS is a more natural collaborative environment than previous technologies such as net shares.
- As is the case with productivity technologies in general, once users are ramped up on it, they want to use it in every possible applicable situation, rather than having to learn something new. In other words, people assume that what works well on the intranet works well on the internet too.
- Since WSS is a web server, it’s easy to put on the internet (even unintentionally), and it feels natural to most sysadmins to do so. Unlike web servers, net shares are typically protected by a firewall and are only intentionally exposed externally via VPN.
So there are going to be some juicy targets out there.
Aside from your sensitive data, there’s other scary stuff that can be exposed by a misconfigured WSS server. For example, FrontPage extensions have a user password reset option. You don’t want to find your site this way via Google:
"use this page to reset a user's password"
There are more common WSS administrative pages that you wouldn’t want anyone to be able to access, either. You can find them by scrolling over the admin links on your WSS site internally, and then confirming that they aren’t accessible from the internet. For example, http://www.mysite.com/_layouts/deleteweb.aspx.
An equally important consideration regarding WSS admin URLs such as the above is they expose a logon prompt that doesn’t implement account lockout. That is, a bad guy can do brute-force automated password guessing on your WSS admin account until he gets it right. Those attacks can be audited, but that capability isn’t exposed in a way that the typical WSS operator is likely to find it. Use a strong password.
Another interesting one that I haven’t fully researched yet: this link, http://www.mysite.com/_layouts/mysite.aspx, dynamically generates a personal site for you, if one doesn’t already exist. There’s a redirection URL that fires at the end of that process the first time around. Probably not a good idea if that be done from the internet.
Finally, for small sites that use a public WSS server intentionally, it’s natural to conclude that many of these are remotely administered, either by a local IT services firm or by a friend. Be sure to check for open ports (see, again, my previous post), including not just the WSS admin port, but others such as Terminal Services. Keep in mind that, if Google can find your site, so have the bad guys, and they’ll be trying those ports too.
Permalink |No Comments »
No comments yet.
RSS feed for comments on this post. TrackBack URL
