If your system has UEFI firmware and Secure Boot is enabled, that might explain why you aren't "permitted" to load (unsigned) kernel modules.
Ubuntu is supposed to have an automated the signing process for third-party modules, but it is possible that the process hasn't worked as expected. For example, if you've updated your system's UEFI firmware ("BIOS update") since installing Ubuntu, the update may have caused a full reset of the system NVRAM. In that case, this command should start the re-enrollment process:
sudo update-secureboot-policy --enroll-key
If the auto-generated key is already enrolled, or in a few other possible cases, this command will simply print out a message about the state of Secure Boot key on your system, so it should be safe to try it anyway, and the message might be informative.
But if the key needs to be re-enrolled, the command will ask you to set a password. Then you'll need to reboot the system once, and immediately after rebooting, the component responsible for re-enrolling the key will request you to enter that password again. This procedure is designed to ensure that a Secure Boot key cannot be enrolled by without the user knowing what is going on. Once the key is successfully enrolled, that password will never be needed again, so there will be no need to store it for long term.
But if that does not solve the problem, something else might be wrong.
To get more information, you should look at the tail end of the kernel message buffer (
dmesg command output) after attempting to load the module. In other words, please do this:
sudo modprobe vboxdrv
sudo dmesg | tail -30
The output should include a bit more verbose description on why the module loading is failing. If the Secure Boot key was not the problem, then please add the results of the second command to your original question.