16

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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Manu
  • 261
  • 2
  • 5
  • 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
  • Which part of the argument are you asking about? The certificate leaking, or internal impersonation? – schroeder Oct 11 '17 at 13:02
  • why not use free certificates instead (letsencrypt)? – Jacco Oct 11 '17 at 13:14
  • 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
  • @Mike Ounsworth, fair point. – Jacco Oct 11 '17 at 14:32
  • @schroeder, yes, of course they are, but that was not the point of my comment. – Jacco Oct 11 '17 at 14:33
  • @Jacco so, why promote letsencrypt for internal use when sub-sub-domains are so tricky to manage with letsencrypt, let alone internal domains? – schroeder Oct 11 '17 at 14:39
  • 2
    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
  • @Erroneous Usability considerations... You don't really want hrhelpdesk.mycompany.com to become hrhelpdesk.partner1.partners.itreallylikesthislayout.mycompany.com. – Sneftel Oct 11 '17 at 15:28
  • Do these wildcard certs have [Subject Alternative Names](https://en.wikipedia.org/wiki/Subject_Alternative_Name)? – JimmyJames Oct 11 '17 at 15:42
  • 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

2 Answers2

21

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 Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 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
19

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 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
  • that would have to be some incredibly tight controls: any computer/server could host a service - there are a lot of factors to consider in order for account security to be the right risk mitigation here - most orgs I have worked in would not be able to use account security in this way effectively – schroeder Oct 11 '17 at 13:27
  • 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
  • @schroeder I guess I'm confused why services are necessary. Can't you already do full sniffing with a laptop on the same network + wildcard private key + wireshark ? And if you can direct traffic _through_ your laptop, then you can do worse? – Mike Ounsworth Oct 11 '17 at 13:43
  • @MikeOunsworth the stated threat is impersonation, but yes, there are other threats to consider. Account security could prevent an admin from using their latop in this way (especially if wireshark cannot be installed) – schroeder Oct 11 '17 at 13:44
  • The OP is in the EU. If there is a single shred of PII data in this network, the threat cannot simply be ignored, as there are legal complications. **I bet** this outsourced partner broke his contract by using the wildcard certificate. Or *"usability at the cost of security comes at the cost of liability"* – Mindwin Oct 11 '17 at 16:28
  • @Mindwin that's not how GDPR or DPA works ... – schroeder Oct 11 '17 at 16:36
  • I thought it was under Article 25, but I might be mistaken. I'm no expert after all. – Mindwin Oct 11 '17 at 17:24
  • @Mindwin this article 25? http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679&from=EN how is a wildcard cert contrary to this? – schroeder Oct 11 '17 at 17:48