Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Im a linux newbie im trying to understand how the hacker gained privileges from hacking an unprivileged account. Here are the commands used.Trying to understand "mv getlogs.sh" and why the "echo /bin/sh > getlogs.sh" was issued? Im a newbie to Linux so this is probably something easy thanks for your support.
cd scripts
ls -lah
sudo -l
cat getlogs.sh
mv getlogs.sh getlogs.bkup
echo "/bin/sh" > getlogs.sh
cat getlogs.sh
chmod x getlogs.sh
ls -l
./getlogs.sh
id
exit
sudo getlogs.sh
sudo /home/ccoffee/scripts/getlogs.sh
id
They had execute and write privileges for the directory.
They had write privileges for getlogs.sh, but not execute privileges.
So they moved, thus wrote, getlogs.sh to another file, because they had rwx for the directory.
Then they created a new getlogs.sh which contained the /bin/sh command.
They made that executable, and then ran it.
Somehow that allowed them into a group they weren't supposed to be within and thus they were able to do the sudo command. Or maybe not, maybe they persisted in trying, but never succeeded. Seems like they were still checking their user and group ids.
I think the point was to replace the original script with one that opens a shell, then run the new script with sudo to get the shell with elevated permissions. Hence the first use of sudo -l to see if any of the scripts could be run with sudo.
The way I read it, the cracker was going slowly and testing every step.
Yes I don't think they succeeded, but they were able to do those things based on the privileges they had for the directory and at least were able to delete and then create a new script where originally they were not able to run or modify that script.
This points out that the directory permissions are equally important.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.