cPanel navigates the requests that are sent to the server to the correct account according to domain. Of course, the account owner must declare that the domain belongs to him. In order to ensure that the domain does, in fact, belong to him, cPanel offers two options (without EPP code):
1. To refer the domain DNS to the DNS storage server.
2. To create a randomly-named file on the domain, created by cPanel, which is unique per-user.
I will go into some detail regarding the first option.
In order to move from one storage to another, the site owner performs the following steps:
- 1. Creates a copy of the website in the second storage.
- 2. Forwards the domain to the second storage (DNS referral).
- 3. Waits for DNS servers to be updated.
- 4. Connects to the new storage cPanel and takes ownership of the domain.
You can immediately notice that this option does not have any authorization check. In the critical step, step 4, any other user in the cPanel can take ownership of the domain.
Even if the site owner discovers this and complains, serious damage can be caused within minutes.
1. Sending and receiving emails from the stolen domain, can be exploited for social engineering to phish passwords, which will be useful also after the victim take over the account.
2. Create SSL certificate for the site using mail addresses such as email@example.com / firstname.lastname@example.org and use it to MITM a long time after the victim take back his account.
3. Sending spam, it will take a while before the domain is removed from spam lists.
Using the siteitself:
1. Phishing users’ account credentials, after that, all users needs to set a new password.
2. Insertion of malware, which will cause the website to be rejected by search engines and it will take a while to get it re-approved.
3. Defacement of the website
The attackerwill scan websites that are located on shared storages, register the domain => IP, write a small script that will sample whether the domain IP has changed. As soon as the IP changes, it is reasonable to assume that the website has moved to a new storage. Now the attacker must quickly create an account in the new storage supplier of the victim, link the domain to it and… DONE.
P.S. Another problem that exists on cPanel is that the TOKEN protection against CSRF is performed via OPT-IN, which leaves most of the storages vulnerable to serious CSRF – but that is an entirely new subject…