API Tokens Concerns
Can someone explain what's so secure about these tokens? It seems to me that the token is just a hash - it's not an actual token like you see with authentication - it doesn't expire, or form part of a pair that can only work together. It's just one plain text hash that can give full root access to the server.
Surely using one of these access hashes by itself, especially if it has full ACL privileges, is just as bad as providing a plain text password inside a text file? How is it any different? The file itself is not encrypted. It's simply a text file with a golden key to full root access. In fact, even if you disable most of the ACL's, simply leaving the "create session" ACL enabled is enough to give root access.
I've been looking at the way certain applications use these access tokens alone to submit API commands to cpanel servers. Isn't this dangerous? The tokens are not stored encrypted like a password would be. There is no other layer of security involved.
I don't want plugins that are installed in WHM to have this level of access. I spoke to one provider recently who said that the full root access token is unavoidable because cpanel's API tokens are still "experimental". That must be some sort of joke right? The plugin only needs to hook into creation / deletion of accounts and change DNS records, so why does it require full root access? The developers say there is no way around it - blaming cpanel as the cause of the problem.
I wouldn't give out a servers root password to a third party developer. Would you? And you certainly wouldn't allow them to create a plain text file with the servers root login details in it and store them in their own systems. Well it seems that's exactly what you're doing by setting up an API token.
One plugin we've used actually creates its own API token, so it seems that's possible to do programmatically without any authorisation.
Would you install a plugin that you knew had the power to create its own root level access to your server whenever it wanted?
Is there no way to prevent API tokens from being able to perform certain tasks, even if the ACL within the token allows it? For example, you might want WHMCS to have the ability to change users passwords - but you wouldn't want that token to have the ability to change the servers root password. I don't think it's very secure at all.
You'd think at the very least there should be two layers of security in place here.
-
Hello @4u123, Can someone explain what's so secure about these tokens? It seems to me that the token is just a hash - it's not an actual token like you see with authentication - it doesn't expire, or form part of a pair that can only work together. It's just one plain text hash that can give full root access to the server.
One of the intents of API Tokens was to address some of the security concerns with access hashes (the previous method). Here's a quote explaining the key differences: [QUOTE] We deprecated Access Hashes because they had some security concerns we wanted to address. A few big differences between the Access Hash system and the API Token are:- Keys are no longer stored in plaintext
- Keys are no longer stored in the users home directory
- When a key is created the key is displayed just once. After which is stored in a nonreversible encrypted format. You will be unable to see the key again, so please store it somewhere safe.
- As of cPanel & WHM version 68, keys can be created with limited permissions.
You can also assign privileges to tokens per the information documented on the link below: Manage API Tokens - Version 78 Documentation - cPanel Documentation Though, as you noted, the ability to assign privilege restrictions to API tokens is experimental and may change in future versions. I recommend opening a0 -
Correct me if I'm wrong here - but the access hash is needed to gain access. So once the user has it in their possession, they would use it when connecting to the server? I understand what you mean when you say the key isn't stored in plain text or in the users home directory. I appreciate that there needs to be a key on the cpanel server itself. I'm not talking about that. The security issue is with the plain text key they take with them, for access. You said "You will be unable to see the key again". I don't get that. The key is provided in plain text so you can copy it and then use it to gain access. There is no authentication. All you need is that key - which in most cases IS stored in plain text. That's where there is a security issue. Are you following me? 0 -
Hello @4u123, I understand your point, that despite the fact the API token isn't stored on the server in plaintext, the administrator/developer will often store the token in plaintext on their local workstation or in their custom script. You could implement third-party encryption technologies to ensure the token isn't viewable as plaintext on the local workstation, or to ensure the source code for the script that makes use of the API token is encrypted. However, to your point this isn't necessarily a common practice. Thus, an additional layer of security would add value to this feature. Currently, the following feature request exists: 0 -
I don't think that's an acceptable response. The way your API tokens work is that you produce a plain text "key" which isn't really any different to a simple password (other than it would be much harder to brute force). That key is then used to provide root access to the server via the API interface with no other level of security or authentication in place. So essentially what you're doing is providing what is effectively a root password in plain text to be given to a third party so they can do what they want with the server. You haven't secured that with a secondary password, or with any other form of authentication or protection. It can be used on its own to gain full root access to the server. I appreciate that you've tried to add permission levels to the keys, which is great, but unfortunately no third party product I've seen is actually using them effectively, claiming that higher levels of access are required due to some failing or other with the way cpanel have developed it. While it's good that you've started to add this functionality, it still isn't enough. When a third party plugin or product uses this key on its own to access a cpanel server, they are simply storing it as a text file, or within a database, unencrypted. In the event of a vulnerability in the application being compromised, the API token is right there to be stolen and used by a hacker to take full control of the cpanel server. As I said above, it would be madness to simply give out the root password of all your servers to any third party in plain text. This is no different. In fact, it is LESS secure than using a strong password because there are pre-existing methods for encrypting passwords when storing them. In all the cases I've seen, there has been no attempt to encrypt or to secure this key. You might argue that the responsibility is on the third party, but from what I've been reading, a simple "single key" approach is woefully inadequate. Basic good practice with regards to API security is not being met here and it is again very disappointing to hear you suggest that I create a feature request to ask you to please put the basic bare minimum levels of security in place so that my servers don't get compromised via a third party plugin with a vulnerability. It's just madness. Access control should be there as standard. Of course you should specify what IP's a token can be used from - but that's not nearly enough. You should be looking at authentication, authorization, security and access control with at least two combined methods of security so that access to the plain text key alone is not enough to compromise a server. At the very least, accompany the key with password authentication too, so that both are required. Have your developers not done any research on best practice in this area? Why not? You're not taking it seriously and I'm sure before too long you'll end up reacting to a catastrophic incident. 0 -
I agree with many of your points... but... You can't do automation if you are requiring secondary authentication - then the question becomes what's the point of the access key if secondary user interaction is required to do anything? WHMCS (or any billing system) can't automatically suspend accounts on a server if it has to have user interaction to authenticate the key. Is requiring user interaction good for security? Absolutely. But it's going to come at the expense of automation - which is not going to be an easy sell. This is actually no different than using a passphrase-less SSH key for root. If that private key is ever compromised then whoever has access to that key can log into any server with that matching public key with no push back. I don't know how many administrators actually use passphrase-less SSH keys, if you do anything automated over SSH, you almost have to - but you also have to take extreme care with that associated private key (as in, I would not recommend putting it on any public facing servers). A lot of hosts also block off SSH access to certain IPs... but you can't do that with cPanel and WHM ports. Ultimately a lot of this has to do with the fact that cPanel and WHM run everything as root with cPanel/WHM system itself arbitrarily lessening the permissions based on the access key being used. If I'm wanting to automate something via SSH, I can create a user on the server, restrict that key to a certain IP address and to a certain command, add that command into sudoers to elevate that user to root level for that specific task. Personally, if it were me (and I don't have all of the facts), I would consider dropping all of xml-api, json-api, etc level of API interaction with cPanel and WHM and utilize SSH. Create a wrapper that basically logs into the server via SSH - as an under-privileged user - and tie specific commands to specific keys and elevate to root with sudo as needed. This would be mindboggling complex, but would solve a lot of these security concerns. Could a key still be compromised? Yes. But if you tie the key to a specific IP address, that's going to stop a lot. And even if you don't, at worst, that compromised key is only going to be able to perform one task. But this also means that you would need a key for every server that you connect from just to (for example) suspend an account. That's potentially a lot of keys. cPanel has a lot of this functionality built into SSH when they created command-line commands for accessing the API interface. 0 -
You can't do automation if you are requiring secondary authentication - then the question becomes what's the point of the access key if secondary user interaction is required to do anything? WHMCS (or any billing system) can't automatically suspend accounts on a server if it has to have user interaction to authenticate the key.
Yes you absolutely can do automation. The key (or token) provides authorization to perform certain tasks and a stored username and password provides authentication. Just like any system, you can pass both a password login and an API key to a server from an application or script.This is actually no different than using a passphrase-less SSH key for root. If that private key is ever compromised then whoever has access to that key can log into any server with that matching public key with no push back.
It is different because the context is completely different. When handing out SSH keys you are providing access to a server for administrators and we're talking about very carefully selected individuals. These also have the benefit of sudo'ing once logged in, so they are never logging in with absolute root credentials - they need a secondary password. With the API keys, you're handing over root level access to a third party company and relying on the security of their programming alone to make sure the key can't be compromised. It's not good enough.Ultimately a lot of this has to do with the fact that cPanel and WHM run everything as root with cPanel/WHM system itself arbitrarily lessening the permissions based on the access key being used.
Yes. In the case of plugins, you have no choice but to use the root user in the access token. In the case of other apps like WHMCS, where you are creating and deleting accounts etc, the risk could be lessened by setting up a reseller in WHM that owns all the accounts and using an access token for that only, avoiding a potential password change on the root user or similar issue. WHMCS uses access token privileges that would allow a root session normally, so a nightmare could be avoided if it was possible to use a reseller login instead. I suspect that's already possible. I think its very important for cpanel to develop an API that can be used by software developers who create products for the hosting industry. I'd love to see more and more third party services for cpanel - but right now I'm considering removing a particular plugin because the level of security is really not good enough. All it takes is one security issue on their web facing applications - one data breach and someone can gain access to the API keys, which without any secondary security would give them full root access. I'm amazed that anyone would create an API with such low security - especially when we are talking about the root user of a linux server. That's the main issue here. I've used API's for different things over the years, Some have been a simple password - some have been an access key and a password. Almost all of the ones I've used have been locked down to specified IP's - and those systems are just things like reseller accounts and affiliate accounts, or simple things that don't need a high level of security, yet every API I've used has been more secure than this one. The risk in connecting to a root account on a linux server is so much higher - thus it requires a higher level of security, whatever that may be.0 -
Hello @4u123, While it doesn't address all of your concerns, I did want to bring up one option that I didn't see referenced on this thread: Limit logins to verified IP addresses The option is found under WHM Home " Security Center " Configure Security Policies and is extendable to remote API requests. It will force remote servers to answer configured security questions before authentication is successful. Thus, in addition to having the API token, security questions must be answered before authentication is successful. That said, I understand this doesn't address all of your concerns. Could you open a 0 -
Hello @4u123, While it doesn't address all of your concerns, I did want to bring up one option that I didn't see referenced on this thread: Limit logins to verified IP addresses
I'm glad you brought that up, because the Limit logins to verified IP addresses option is completely useless under normal circumstances. The logic behind it is flawed. The idea that under normal circumstances you would feasibly lock down cpanel, webmail and WHM all to be accessed only by humanly "question verified" IP's is just dumb. The only time you would want to do that is if the cpanel server is being used for only one project with a small handful of users. These are shared hosting servers! You are going to have lots of different people from many different places logging into cpanel and webmail. Where there are hundreds, or even just dozens of accounts on a cpanel server, locking down the cpanel and webmail logins with a fixed set of security questions is simply not feasible or practical. You'd have to give out the same questions and answers to hundreds of people and then tell them to give out those details to anyone else they want to have access. It's completely impractical - and a pain in the ass for the end user. Nobody wants to answer 5 individual questions just so they can login to their Email. On top of that, it seems to me that the security questions are the same no matter what. Is that right? So you'd answer the same questions for WHM access as for cpanel access? If so, that's just stupid. You would definitely want to lock down access to WHM, API and DNS cluster operations. That goes without saying. But this really isn't the way to do it. Maybe its ok for WHM manual logins - but for anything automated like the DNS cluster and API requests, which are internal or initiated from scripts, there is no human interaction, so how could that possibly work? Would you have to hard code the questions and answers into the API requests? Seems implausible. Also, how exactly does that work with the DNS cluster? Also, you can't make it so you can choose what services to lock down. It's all or nothing. That makes it completely unfeasible to use. You also can't choose the set of questions and answers for each service individually, as far as I can tell. In this Security Policies feature you have grouped together the customer facing access (cpanel and webmail) with the admin facing access (WHM API and DNS). By doing so you've made it an impossible to use feature. I appreciate your suggestion Michael but you'd be mad to think that the Limit logins to verified IP addresses feature could be of any help minimize the serious root level security weakness that you've presented with these API tokens.0 -
Hello @4u123, A feature request is really the best path forward if you'd like to see the security functionality you are seeking. If you can open the request detailing your feedback and what you'd like to see, then I can bring it up internally and start referencing it when I see similar concerns/requests in order to demonstrate community demand for it. Thank you. 0 -
Hello @4u123, A feature request is really the best path forward if you'd like to see the security functionality you are seeking. If you can open the request detailing your feedback and what you'd like to see, then I can bring it up internally and start referencing it when I see similar concerns/requests in order to demonstrate community demand for it. Thank you.
My aim here, since this is a discussion forum, is to have a discussion about the blatent weakness in cpanel's very insecure API system that allows full server root access via a simple text string without any other form of security and without any authentication. It isn't a request for a new feature, so I'm sorry if you got the wrong idea there. I appreciate your input Michael. I hope others would like to provide their opinions or suggestions here too.0 -
I don't want plugins that are installed in WHM to have this level of access. I spoke to one provider recently who said that the full root access token is unavoidable because cpanel's API tokens are still "experimental". That must be some sort of joke right? The plugin only needs to hook into creation / deletion of accounts and change DNS records, so why does it require full root access? The developers say there is no way around it - blaming cpanel as the cause of the problem.
I do want to point out that support for cPanel API tokens (in addition to the WHM API tokens feature) is tentatively planned for cPanel & WHM version 80. We'll have more information to share about this feature once version 80 is closer to publication on the EDGE release tier. Thank you.0 -
I also feel that this shouldn't be considered a feature request, as it's a lack of security. In regards to API tokens, they can't even be restricted to a single IP, or even 2FA. I hate that I have to grant WHMCS root access to a reseller server, and not be able to restrict it's access to a single IP. ACL's don't work as the reseller accounts hosted wouldn't be able to access WHM. The only thing that leaves is restricting the token or user to a specific IP (since WHMCS can't handle the 2FA request). cPHulk should be able to easily handle the IP:user check since it already gets called through PAM auth, and performs a blacklist/whitelist check. You should refactor the authentication mechanism to be able to restrict access to a token/user to a specific IP as well as the current 2FA option, which can't be integrated with software such as WHMCS. On shared cPanel servers I can easily restrict WHM access to the IPs runs at WHMCS, but this doesn't work for cPanel servers hosting reseller accounts, as resellers wouldn't be able to access. 0 -
It would be nice if the api token ACL permissions allowed restriction of that API token to a source IP as an option. 0 -
@horizon2021 - you're always welcome to submit a feature request using the link in my signature! 0
Please sign in to leave a comment.
Comments
14 comments