15

Few of our web servers are managed by an outsourced partner who works as us in the same office, uses our laptops connected to our corp network, and has user accounts in our AD. They requested and applied wildcard certificates to make some of the IIS sites (all internal facing) https.

Someone in IT raised a concern that it is not advisable, from a security point of view, that outsourced admins request and apply certs on websites. Here is the argument:

With a wildcard certificate you can "impersonate" any service, even the ones not managed by the specific team on the specific servers they have an agreement to manage. If the certificate is leaked outside of our company, it could pose a security risk, e.g. potentially be used to setup services pretending to be owned/validated by us when they are not. We may have NDA in place, but it would still be good practice IMHO to limit number of hands with access to certificates (I'd say even internal hands!), and considering that we even used pseudo-role based usernames as we expect that people may rotate more often than internal employees.

It is an internal certificate which wouldn't resolve on the internet. What do others think of this?

  • 1
    Who/what is the CA? Only an internal entity? The CA cannot be contacted by external parties? – schroeder Oct 11 '17 at 13:01
  • 4
    @Jacco For one, Let's Encrypt - or any publicly-trusted CA - logs all certs they issue to CT. For internal resources (servers not visible to the internet), like for example the corporate AD or Exchange servers, I don't really want their domain names to be public knowledge. – Mike Ounsworth Oct 11 '17 at 13:20
  • 6
    @Jacco local CAs are free certificates – schroeder Oct 11 '17 at 13:22
  • 1
    Why can't they have a wildcard subdomain specific to them? IE *.partner1.xyz.abc.com which is also valid for parter1.xyz.abc.com – Erroneous Oct 11 '17 at 14:58
  • 1
    @Sneftel fair enough. Seems the most obvious solution then is explicitly state all the required sub domains in a single cert. As long as they can enumerate all the domains they need up front (or you can reissue as more are added) then no problem. – Erroneous Oct 11 '17 at 15:53
22

I'll supplement @schoeder's answer with some technical details.

My understanding of your situation is that you have servers applications like this:

intranet.xyz.abc.com
documents.xyz.abc.com
applications.xyz.abc.com
...

and your partner also has some applications running on the same server:

partner1.xyz.abc.com
partner2.xyz.abc.com

All of the above are internal-facing (not accessible from the internet). Now, the partner was too lazy to make individual certs for each of their IIS applications, so they made and installed a global a cert for:

*.xyz.abc.com

Cool. That covers all of their applications. But it also covers all of yours. Assuming they have access to the private key that belongs to this wildcard cert, then they can Man-in-the-Middle your intranet or documents servers and read all the traffic.

Also, if your company has (or a malicious admin with your partner decides to stand up) any public-facing websites that match the wildcard, for example:

www.xyz.abc.com

then, since it's a private internal CA, the general public would not be fooled by their spoof, but any of your employees connecting from internally (with that CA installed into their OS) would trust the spoofed version of www.xyz.abc.com.

As @schroeder points out, the potential for insider-threat here is huge.

  • Mike, partner is only supporting few applications hosted on couple of our servers. For example, we have a site intranet.xyz.abc.com & documents.xyz.abc.com, applications.xyz.abc.com etc. which are all internal websites of organiation abc.com. So they raised a request for cert *.xyz.abc.com and applied to the IIS server. – Manu Oct 11 '17 at 13:22
  • @Manu Ok. I've updated my answer with your example domain. Does this agree with your situation? – Mike Ounsworth Oct 11 '17 at 13:30
  • It does mostly other than there isn't a partner*.xyz.abc.com site, all the sites are abc.com related no partner/extranet. I get your point and we need to work on our processes and policies if we have to continue working with non-employees managing our systems. Thank you @MikeOunsworth – Manu Oct 11 '17 at 14:39
20

Insider threats are a major problem that not enough organizations think about. The IT person is correct to bring this up.

But the argument is just one factor. A 'threat' has been raised, and now a 'threat analysis' needs to be performed. What is the impact if a malicious insider (outsourced or not) can impersonate services? If this impact is low, then you can choose to ignore this threat.

Just because something could happen does not mean that we need to freak out. We need to consider the impacts and likelihoods and determine if this is something we need to deal with.

Without further details about your environment, services, data flows, etc, (which you probably should not disclose here), that's about as much as we can respond.

  • By internal CA I meant local Certificate Authority. To Rephrase, what is the security threat if someone who has access to 2 application servers (as admin) get hold of an internally issued TLS certificate? What are the potential damage they can cause assuming they do not have access to any other business application as administrator? – Manu Oct 11 '17 at 13:12
  • the threat is what your IT explained: impersonated services. An admin running a malicious service on their own laptop with one of those wildcard certs, for instance. – schroeder Oct 11 '17 at 13:23
  • Agreed, if the privilege of these partner user accounts are managed properly using roles, etc can the threat be minimised? – Manu Oct 11 '17 at 13:26
  • 5
    @Manu I don't think it has anything to do with accounts or roles. The basic question is: when an employee points their browser to your intranet and gets a green HTTPS lock, how do they know they are talking securely to the server, and a rogue admin is not using that wildcard cert to man-in-the-middle the connection from their laptop? With a shared wildcard cert, this is completely possible, and the connection is already broken before the user even sees the login page. – Mike Ounsworth Oct 11 '17 at 13:33
  • 2
    @MikeOunsworth meh, I can imagine a tight account security ship where admins can't launch new services. But I've never seen such a ship float. And accounts are not the correct place to address this threat – schroeder Oct 11 '17 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.