Linux root access recovery by booting on the console
Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!
See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)
boot security root console
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
add a comment |
Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!
See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)
boot security root console
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.
– Brandon
Jun 23 '16 at 23:31
This is why you lock computers in cages
– Neil McGuigan
Jun 24 '16 at 17:40
add a comment |
Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!
See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)
boot security root console
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!
See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)
boot security root console
boot security root console
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
edited Jan 13 at 21:19
Rui F Ribeiro
39.5k1479133
39.5k1479133
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
asked Jun 23 '16 at 18:22
Sam Si TayebSam Si Tayeb
4015
4015
Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.
– Brandon
Jun 23 '16 at 23:31
This is why you lock computers in cages
– Neil McGuigan
Jun 24 '16 at 17:40
add a comment |
Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.
– Brandon
Jun 23 '16 at 23:31
This is why you lock computers in cages
– Neil McGuigan
Jun 24 '16 at 17:40
Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.
– Brandon
Jun 23 '16 at 23:31
Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.
– Brandon
Jun 23 '16 at 23:31
This is why you lock computers in cages
– Neil McGuigan
Jun 24 '16 at 17:40
This is why you lock computers in cages
– Neil McGuigan
Jun 24 '16 at 17:40
add a comment |
2 Answers
2
active
oldest
votes
Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.
Ultimately, though, you're correct - this is a very exploitable attack vector.
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
add a comment |
A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.
In /etc/default/grub you can uncomment the following line
GRUB_DISABLE_RECOVERY="true"
And poof! Single User mode is now gone.
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
3
You should also set a GRUB password (to prevent someone from appendinginit=/bin/bashto your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted/bootpartition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)
– Martin von Wittich
Jun 23 '16 at 19:22
4
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f291686%2flinux-root-access-recovery-by-booting-on-the-console%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.
Ultimately, though, you're correct - this is a very exploitable attack vector.
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
add a comment |
Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.
Ultimately, though, you're correct - this is a very exploitable attack vector.
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
add a comment |
Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.
Ultimately, though, you're correct - this is a very exploitable attack vector.
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.
Ultimately, though, you're correct - this is a very exploitable attack vector.
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
answered Jun 23 '16 at 18:31
JohnJohn
11.6k11730
11.6k11730
add a comment |
add a comment |
A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.
In /etc/default/grub you can uncomment the following line
GRUB_DISABLE_RECOVERY="true"
And poof! Single User mode is now gone.
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
3
You should also set a GRUB password (to prevent someone from appendinginit=/bin/bashto your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted/bootpartition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)
– Martin von Wittich
Jun 23 '16 at 19:22
4
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
add a comment |
A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.
In /etc/default/grub you can uncomment the following line
GRUB_DISABLE_RECOVERY="true"
And poof! Single User mode is now gone.
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
3
You should also set a GRUB password (to prevent someone from appendinginit=/bin/bashto your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted/bootpartition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)
– Martin von Wittich
Jun 23 '16 at 19:22
4
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
add a comment |
A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.
In /etc/default/grub you can uncomment the following line
GRUB_DISABLE_RECOVERY="true"
And poof! Single User mode is now gone.
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.
In /etc/default/grub you can uncomment the following line
GRUB_DISABLE_RECOVERY="true"
And poof! Single User mode is now gone.
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
answered Jun 23 '16 at 18:31
Zachary BradyZachary Brady
3,406932
3,406932
3
You should also set a GRUB password (to prevent someone from appendinginit=/bin/bashto your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted/bootpartition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)
– Martin von Wittich
Jun 23 '16 at 19:22
4
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
add a comment |
3
You should also set a GRUB password (to prevent someone from appendinginit=/bin/bashto your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted/bootpartition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)
– Martin von Wittich
Jun 23 '16 at 19:22
4
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
3
3
You should also set a GRUB password (to prevent someone from appending
init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)– Martin von Wittich
Jun 23 '16 at 19:22
You should also set a GRUB password (to prevent someone from appending
init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)– Martin von Wittich
Jun 23 '16 at 19:22
4
4
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.
– Satō Katsura
Jun 24 '16 at 7:15
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f291686%2flinux-root-access-recovery-by-booting-on-the-console%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.
– Brandon
Jun 23 '16 at 23:31
This is why you lock computers in cages
– Neil McGuigan
Jun 24 '16 at 17:40