The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Hijacking domains with cPanel API

Discussion in 'Security' started by nibb, Jan 12, 2014.

  1. nibb

    nibb Well-Known Member

    Joined:
    Mar 22, 2008
    Messages:
    301
    Likes Received:
    1
    Trophy Points:
    18
    I posted this to the security team at cPanel some months back and without luck they told me this is not a security issue but how their DNS and API works.

    So I will decide to make it public based on the consideration that other users can or should test it in their own setup and decide if indeed this is not a security hole but a feature I requested.

    The issue allows for a provider that provides DNS management to customers via their API and runs a cPanel DNS cluster for their users to hijack domains, put them off line or redirect all traffic. This means you can change the IP, records and zones for any domain that is in the hosting company. Quite a HUGE security hole if you ask me, but then again im not here to decide that.

    When a users adds a domain or addon via his cPanel interface, or a reseller does via WHM, cPanel adds the correct DNS zones as well. This in the local server and as well in the DNS cluster. If the domain exists as a DNS record it will fail, from WHM you should be able to see all zones from all servers in the cluster. You can´t of course edit or delete zones which you don´t belong to your user from cPanel or WHM. This checks seems pretty basic and are in the GUI itself but works. You should not be able to add accounts that exists, and cPanel tells you so that DNS records exists. This is fine and it works.

    But what happens when you use the cPanel DNS API calls? Well here comes the issue. API calls runs as root which and for DNS records it allows to do functions like add, edit, delete, etc.

    If you send an add API call to the sever and the domains exists in the local server where you are sending the API call it will fail, telling you similar to the GUI that it exists already. But if the domain or DNS record exists in another cPanel server, which is normal in a clustered setup, again assume you have a cPanel DNS cluster, it will pass. Don´t be confused here with the domain existing, you could have just fine only DNS records without hosting the account on cPanel. So this applies to his case as well. If the DNS zone exists for a domain in server a even without being hosted it will securely inform with a failure, not so in the cluster.

    This means if "example.com" is hosted in Server A or DNS zones for "example.com" exists and we are sending API calls always to server A, the API will correctly deny it as the domain/zones exist.

    But if you send the same api call to add example2.com, again to Server A, and example2.com exists in another cPanel server it will pass because Server A only checks its local domains, not the DNS records on the whole cluster. You will not overwrite the zones for that domain.

    So now you have taking control on example2.com which does not belong to you, you can change it records and even deleted it.

    The same applies to the delete API call. Here you first send the API call to add example2.com, then its yours and you can deleted it.

    You can actually send a delete call for all domains hosted by the hosting company and take each down, if the company happens to host their zones in their cPanel DNS cluster, that customer will now also be able to take control over the company infrastructure completely. How? Lets assume cPanel.net provides me the hosting for the DNS services, and they use a cPanel DNS cluster. I purchase their DNS services and then I can add my domain from the control panel the company provides me which just runs the API calls in the background. I would then just add cpanel.net to my account and it will overwrite the zones that existed already. Now I control the zones.

    The API calls regarding the DNS fails completely to check zones in the cluster, only locally. So now you can hijack, delete, erase, or update zones of ALL domains in the cluster.

    If you are a hosting provider and are providing DNS services to your customers, using the cPanel API, I assume your DNS servers are at least 2, which is clustered already. I assume a provider does not just 1 local DNS server which does not give redundancy. Most providers have 2 separated DNS servers in separate server or network and I assume most providers using cPanel for DNS have the clustering enabling.

    So if you give customers access to manage this DNS zones, or give DNS services, outside cPanel or WHM you are probably using the API and in this case I advice you immediately to check this issue since your customers can hijack and use zones that do not belong to them as there is absolutely no pre check done by the API. Unless you do some other checks. I tested this failure in at least one popular billing systems that has cPanel DNS features advertised and it works just fine.

    The correct procedure is for the API to fail if the zones for that domain exists already, not overwrite them. This means that if the API call would fail if the records exists, it could potentially avoid this issue. The API fails to realize the domain exists in another server in the cluster and so this issue.
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,694
    Likes Received:
    654
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello :)

    We have an existing feature request open expressing the same concerns:

    Ownership and access control of zones in the dns server. | cPanel Feature Requests

    There is an internal case open to address this issue. For reference, the case number is 56417. While there is currently no specific time frame available on when a change to the existing system may occur, there are plans to address this in the future.

    Thank you.
     
  3. nibb

    nibb Well-Known Member

    Joined:
    Mar 22, 2008
    Messages:
    301
    Likes Received:
    1
    Trophy Points:
    18
    Michael, implementing the check I mentioned should take what, 1 hour? I reported this last year.

    All it needs to do to avoid this is issue in its initial steps is "check if records exists" if yes "error message, block" if no, "allow call".

    Actually the code does not even need to be written because the both the cPanel GUI and WHM already do this. If you use the graphical interface it already disallows this behavior. I don´t see how hard it should be to copy it.

    The ownership and access control you mentioned is of course better but way more advanced and would take more time to be developed. I think that is open for years and I don´t see it coming in the next 5 years either. A company needs to offer products today, not in 5 years. The fix I mentioned is so basic that even a newbie developer should be able to implement the check first.

    The issue is highly critical as far as I know the only solution then so far is completely disallow DNS management via the API. The problem is that some providers are actually using this like this. I would not be nice marketing if on the media some articles land that a hosting company domains where stolen and data diverted because a bug in the cPanel products which was amazingly easy to patch. A DNS hack is serious as it allows you to have control of all the traffic for everything. And some companies are actually offering DNS zones via cPanel which is rather scary.
     
    #3 nibb, Jan 13, 2014
    Last edited: Jan 13, 2014
  4. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    Disillusioned in England
    cPanel Access Level:
    Root Administrator
    Interesting, I'd not come across this before. Just having a scroll through the various threads it seems that the official position is that this is partially a breakdown in understanding of documentation and definiitions of terms?

    Nibb, I've not played with the API in this manner (i.e for dns not having a cluster setup right now) can I just clarify that root is required on a given server in the cluster to make the modifications you're tallking about?
     
  5. nibb

    nibb Well-Known Member

    Joined:
    Mar 22, 2008
    Messages:
    301
    Likes Received:
    1
    Trophy Points:
    18
    The problem is that I don´t think any provider that sells hosting and cPanel for DNS management would not be using a cluster. It just does not make sense. DNS regulations explicit say you need two separated servers in different subnets.

    Its fine to host your own local DNS in one server if you are using it for personal use or a few domains, but for providing DNS services to customers? I don´t think so. You will not be able to host or use some domains, which I know for a fact check for this and will fail if you use nameservers where both the 1 and 2 (which are the bare minimum required) are in the same server.

    This means that anyone even with 2 DNS servers which is of course the minimum is using the cluster feature, chances are that most providers that sell hosting or use cPanel DNS features have this setup. This does not affect you if you don´t use the API but I know for a fact some providers are using it to provide customers access to create their own zones and they are not even aware of the risk this is representing as we speak. The reason is that it does not make sense to create them a full account only for zone editing not to mention it requires another extra login to cPanel, so they use the API to let customers manage their zones.

    I did tested this several times and the issue is real.
     
    #5 nibb, Jan 14, 2014
    Last edited: Jan 14, 2014
  6. ThinIce

    ThinIce Well-Known Member

    Joined:
    Apr 27, 2006
    Messages:
    346
    Likes Received:
    7
    Trophy Points:
    18
    Location:
    Disillusioned in England
    cPanel Access Level:
    Root Administrator
    I wasn't in any way arguing the premise. I was attempting to understand the discrepency between the seriousness of the issue as you and others portrayed it and the response in the related feature request. A security issue is a security issue, regardless of who it impacts be they small or large :)

    In my experience there are a whole bundle of small shops, i.e. less than 10k active clients making use of single server DNS, I totally agree this absolutely isn't ideal or RFC compliant and indeed you run into brick walls with for example .de domains in doing so, but one of the reasons I've heard of for doing it is to avoid linking the servers in a trust relationship. (The same reasoning rightly or wrongly gets thrown around a lot when discussing using the CSF lfd clustering feature).

    Anyway, I guess we'd agree the above is immaterial to the discussion of the security issue you raise.

    Yup, not arguing, what I wasn't clear on (not having used the API for DNS) is whether root api level access is required to do what you were referring to. If I'm reading right it is, or can (via the api) a cPanel user account or a Reseller also do this?

    If my understanding is right, it does seem strange if the API doesn't return a "this domain already exists in cluster" error to an add request if applicable so that this can be handled appropriately in software on the other side of the call.
     
  7. nibb

    nibb Well-Known Member

    Joined:
    Mar 22, 2008
    Messages:
    301
    Likes Received:
    1
    Trophy Points:
    18
    Yes you are correct, I guess people prefer not to have servers linked for security purposes, but for DNS I don´t think there is a choice, if you want customers to manage their zones via their accounts, then cPanel needs to access the cluster.

    From what you say it actually seems it would be wiser not to use cPanel DNS at all and have the DNS servers completely separated, this would have a security benefit but users in their cPanel accounts will not be able to edit records or zones anymore.

    Yes, the API requires root as far as I know, since it probably needs to edit BIND records and you require root access for this, or a reseller account with root privileges.

    Well the issue I pointed out can be avoided with just that simple pre-check and message.

    About the security of the cluster, I don´t know, if one server is hacked will they be able to get access to the other server via the trust relationship? Lets hope no.
     
  8. nibb

    nibb Well-Known Member

    Joined:
    Mar 22, 2008
    Messages:
    301
    Likes Received:
    1
    Trophy Points:
    18
    I just did some tests again and it seems even while cPanel ignored this threat they did implemented silently some security checks on the API calls which is now making it safer. In my recent checks I was able to call the API and now they fail with the correct errors depending if the zone exist with:

    Sorry, the domain example is owned by another user (example)

    If the zone is the same local server you are calling the API calls or:

    Sorry, a DNS entry for example2.com already exists

    If the zone is already in another server.

    This is great !

    What I find it strange is that cPanel does not mention anything about this in the logs or features, but I can confirm the latests versions of WHM seems to have implemented better security check on this API calls, before you could add zones (which existed already) overwritten any zone, or even hihacking and taking control of zones already on the server and then just deleting them. That was very nasty....

    I would really appreciate if cPanel can confirm if they indeed implemented some checks now from the developing side or its just luck in my new tests, because strangely in the my firsts tests tonight I was able to overwrite zones, but then it started to change some settings from the reseller account which they are run to correctly receive the errors when zones exists already. I´m still worried because the 5 or 6 first times I tested this I managed to replicate the issue overwritten existing zones.
     
Loading...

Share This Page