Why isn't Remoting Disabled by Default on Windows Server?
I was recently involved in a brief and quite lively Twitter discussion with Don Jones and Jeffery Snover about PowerShell Remoting and why it is enabled by default. I have been involved in a number of discussions about this topic, but never with such a distinguished crowd such as this one. My opinion, and my original comments, where along of the line of “I believe Remoting should be off by default”, “Well, RDP is disabled by default, why not Remoting”, and “SSH has been off by default for years”, whilst the counter arguments were of the form “Because Nano Server” or “You could always customise your environment to be off by default”.
Don Jones posted a follow up to this discussion on PowerShell.org titled “Why is Remoting Enabled by Default on Windows Server?” and asked me to put together a post on why I felt it should be off by default. This was difficult for me to put together, so here goes!
It has long been an industry practice, to disable/stop services which are not in use on your clients and servers. The argument is quite simple, enabled services are vulnerable servers, they expose your devices to potential risks. Simply having Remoting off, unless explicitly required, will reduce the attack surface area and increase the security of our systems.
Even Microsoft has followed an off by default methodology for the past 10 to 15 years. Services like POP3 and IMAP are off by default in Exchange, SQL servers do not listen for IP addresses by default, we need to install roles and features individually. Microsoft learnt from a number of major security blunders in the early days (Code Red, Slammer and even Blaster), and focused on a more secure development and deployment model. Why should there be an exception to this posture that has worked extremely well since Windows 2003?
Linux administrators, and developers of Linux distributions have been in a similar situation in the past. For a significantly long period of time, SSHD has been off by default, and administrators have still be able to manage their server fleets. One of the early reasons for an off by default approach in Linux, was that it ensured that administrators were aware of the risks prior to enabling SSHD. Now it can be argued, that this has been a failure, and I think most would agree. I do, however, believe that the failure is not in the off by default configuration, but is in the lack of documentation covering the secure configuration of SSHD. People in glass houses shouldn’t throw stones, as Remoting can be just as poorly deployed.
Remote Desktop is a great example where Microsoft followed these methodologies. RDP is off for a number of reasons with security being only one of them. Ironically, one of the obvious reasons to have RDP off by default is to encourage the move from on server management to remote management. Whilst adoption has not been as high as was expected (due to issues with third party vendors, administrators and to a big extent Microsoft), it is clearly a sign of how ahead of the curve Microsoft has been.
It has become increasingly dangerous to expose management services, be they SSH or RDP on the Internet. If you have ever been responsible to auditing the log files of a server where SSH or RDP is exposed to the Internet, you will be well aware of the automated scan attempts that are performed. Brian Kreb’s has posted on Internet criminals selling access to Linux and Windows servers whose credentials they have brute forced. What happens when the criminals discover Remoting? Bruteforcing credentials via Remoting should be even easier and have written about just such a thing on previous occasions. Should we be enabling these criminals and providing them with even more machines that they can take over?
Well, we are doing this to an extent right now. Users, administrators and developers have all been busy provisioning virtual machines on platforms like Azure and AWS, and whilst in many cases RDP endpoints are on random high ports, the same cannot be said for Remoting. Those who deployed and manage these systems may be well unaware of the risks that they have introduced to their networks. Moving to an off by default model could protect these environments from this sort of configuration error.
As a side note, it is still interesting to me how Microsoft changed Remoting from off to on by default in Windows Server 2012, with very little fanfare. In 2014 when I presented on Lateral Movement with PowerShell, audiences typically responded with a significant amount of surprise, be they from an administration or security background.
In Don’s post, he talks about the fact we could easily create an off by default environment if we so wanted. I really have to disagree with him, and say that he has missed the point to a degree. Whilst it is true, that we could use a customised gold/master image, Group Policy or some other tool to create an environment where Remoting is off by default, it must be highlighted that the inverse, an on by default environment would be just as simple to create with these tools. If you want it on, then turn it on, it isn’t that hard.
Don also talks about the fact that Remoting is an incredibly controllable, HTTP-based protocol. This introduces the other issue I have with Remoting. Unless you are deploying an Azure Virtual Machine, post install, you will be exposing Remoting over HTTP and not HTTPS. Is this 2015 or 2001? Do we really still need to talk about the virtues of HTTPS? It would be trivial for Microsoft to change the default from HTTP to HTTPS in a manner similar to RDP.
Now let’s talk about the big elephant in the room, or should I say Nano elephant in the room? What about Nano Server?!?!? Nano Server, whilst it is a new concept for some of us, isn’t a completely new in our industry. Whilst I agree, it is probably easier to have Remoting (and WMI) enabled by default, it isn’t like the deployment of a Nano Server is currently a simple process. Currently Nano Server is coming as a standalone WIM image, we need to manually add packages providing roles, and we currently need to join a domain during installation. How hard would it be to have a step enabling Remoting? It is trivial.
Having said all of that, perhaps the best middle ground would be to have Remoting enabled on Nano Server, and off for Core and Full installs? Administrators have more option on the latter two than the former. Perhaps a compromise is in order?
Another side note, why doesn’t Microsoft want to enable Remoting on Clients? If Remoting is safe for Internet exposed servers, shouldn’t it be ok for Windows Clients?
So in summary, why should Remoting be off by default?
- Off by default is an industry standard practice.
- Off by default has been Microsoft practice for over 10 years.
- Linux administrators deal with SSHD off, so can we!
- RDP has been off by default, we lived with that.
- RDP and SSH are actively brute forced, why open up another attack vector?
- Off by default reduces administrative misconfiguration/insecure configuration
- It is just as easy to switch it on, as it is to switch it off.
- Nano Server isn’t as much of a challenge as we thing, but it could be the exception.
As Don said, whether you agree or not, it is entirely up to you and you are welcome to add your polite, professional comments to this post, or over at the PowerShell.org forums where I have cross-posted. Like Don, I wanted to explain and attempt to justify why I think Microsoft’s approach is not correct. I often believe the discussion is more important than the outcome, and I believe this is definitely the case here.
Kieran Jacobsen
WinRM in Workgroup Environments
Just a quick blog post this time, mainly focusing on some configuration items you “may” need to do if you are working with WinRM, in particular in workgroup environments. These are settings you may need to configure client side when trying to interact with servers. You probably saw these in the notes section of Get-WinRMPassword.
Firstly, how do you view your configuration?
winrm get winrm/config
Next, if you are connecting to systems where HTTP listeners have been configured on the server, if your running on a later Windows Client, you will need to allow for the connection to be made. By default “unencrypted” that is HTTP sessions will not be allowed.
winrm set winrm/config/service @{AllowUnencrypted="true"}
Now I recommend enabling basic auth, just incase.
winrm set winrm/config/client/auth @{Basic="true"}
Finally, the server a client connects to, actually needs to be listed in trusted hosts. This can be done like this:
winrm set winrm/config/client @{TrustedHosts="myserver"}
Note that the command above will clear any other trusted host entries you might have.
And that is pretty much all you need to do!
The easiest to understand guides are (in no particular order):
PowerShell + WinRM = Get-WinRMPassword
Hi All!
So I was working out what I will be putting in the paper based upon my PowerShell Shenanigans presentation from CrikeyCon, and started to ponder a few things around WinRM. In particular:
- How many machines have WinRM exposed to the public Internet?
- Out of these, are they exposing HTTP or HTTPS endpoints?
- Could this be an interesting remote dictionary/brute force attack?
- Could this be written in PowerShell for humour sake?
- Could we use this to breach a network and go from there?
- Has anyone else thought of this?
Let’s take a look at the answers to these questions.
Well the first two are pretty easy to answer. Turning to our good friend, Shaodan, we can put in some queries to get some rough estimates:
WinRM HTTP Hosts (TCP 5985) 185316
WinRM HTTPS Hosts (TCP 5986) 83840
Now we can’t easily assume that there is 269156 individual hosts out there, because we might have some duplicates (hosts listening on both HTTP and HTTPS) as well as some hosts with other services out there. There could also be older Windows Server systems listening on TCP 80 and 443. Either way, almost 300K is a pretty nice number to work with.
Now surely people really are not enabling HTTP? Well, I found this on some of my “out of the box” test systems. Interesting.
I think this would be an interesting attack method…
Could we make an attack tool and could it be made in PowerShell? It turns out, Microsoft has given us a significant amount code to perform this attack. As usual, let’s see if there is anything in PowerShell which looks like the basis for a brute force or dictionary based attack tool…test-wsman looks good!
Get-Help Test-WSMan: http://pastebin.com/uxKeEPHr
And we know how to read files and build PSCredential objects dynamically. So what would the CMDLet look like then?
CMDLet, Get-WinRMPassword: http://pastebin.com/RdygF0J6
And how would it work?
Examples: http://pastebin.com/pUhVazW3
So has anyone else done this? Yes, and some very smart people pointed out this as a possibility several years ago. TheLightCosine and Mubix (disclosure: I am a massive fan of Mubix’ work) talked about this very thing back in November 2012, and even wrote a MetaSploit module doing just this. And there were some very interesting discussions on Reddit about a year ago, and even a post on NetSPI.Com.
So some bright people pointed it out, and no one really seemed to pay much attention, this is a real shame.
So where to from here? Well, it is really hard to tell to be honest. WinRM has be around for a number of years (almost 10) and yet it isn’t something that has gained a huge amount of attention in the IT community, from an automation or security point-of-view. Brian Krebs wrote late last year on Windows RDP enabled servers to which access was for sale on underground forums. Attackers had gained access to these systems via poorly selected passwords and RDP connections exposed to the internet, whilst it certainly is easy to brute force passwords via RDP, WinRM makes it even easier, yet there doesn’t seem to be much of an appetite.
It could be that we simply do not know about it. It could be the case that a lot of these systems with WinRM exposed could have been taken over my malicious users and we simply don’t know about it. I really hope to see more people looking at why they are exposing WinRM to the internet, and if they have indeed been attacked via it. Perhaps now that we are shinning some light on it, we might really see what is hiding in the dark.