Linux Privilege Escalation > Logrotate

A helpful thing I found on this one, was that once you get it to kick a shell back to you, have a second listener ready and quickly paste in a second reverse shell before the connection closes, this closed the 2nd shell right away and kicked back to the first shell which remained open and let me have plenty of time on the target.

I can’t run logrotten and i am not able to clone it using git clone.Anyone has an idea how to solve this issue.

1 Like

yeah you have to trigger the log rotate yourself, this post shows you how to trigger it HackTheBox – Book | Ivan's IT learning blog, but you also need need to do something for the payload to execute and I recommend using the suid bit payload on bash cause you gotta be really fast for the reverse shell. I made a post asking for help some awesome person posted screenshots. I’ll give you a hint if you don’t wanna look for it: it requires you to remove a file

Can you explain why bash and dash drop seuid privilege? I thought when file set with +s i always obtain privilege of owner. Does it feature of bash skip privilege or system?

Someone else can correct me if I’m wrong, but I believe it’s the decision of the ones who write bash and dash source code. A root program can set it effective uid to be the uid of any user. Therefore, I think in bash/dash source code has a line where it checks whether the -p flag is declared, and set the euid of the running bash/dash program from root to the uid of the user that calls the program. Once the program euid is dropped to a normal user, the program itself cannot change its euid back to root anymore. You will need to terminate that program and run a new one. You can read bash/dash source code (it is written in C) to confirm what I said here

1 Like

You should echo ‘messagw’ > ./backups/access.log several time and if first time nothing happens.
you should run ./logrotten again and add newmessage unique before

  1. Open the ssh session in another terminal
  2. Run
  3. Keep the rotation running

Good Luck !!!

Its fine i made it. Also uploaded a video on youtube so other people who stuck can help themself.

1 Like

I’m getting this error: ./logrotten: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.34’ not found (required by ./logrotten)`
I can’t install anything in the target so I don’t know how to solve the problem

1 Like

If anyone need help with this can PM me

1 Like

Holy ■■■■ did I get hung up on this one. I’m not sure what my issue even was. I had the right log file. I had a good payload. I could trigger the rotation. I could see logrotten made the temporary symbolic link. However, no file was ever being written to the target dir. After contacting @tonymustgo for help, I decided to reset my instance and try again. Suddenly everything worked!!

Edit: One thing I did different after the reset was I used scp to copy logrotten.c over (thanks again for that suggestion @tonymustgo) where before I was using wget. So not sure if that caused my issue somehow.

1 Like

need help

Hello dear @zjkmxy can you please help. I am stuck and lost. Don’t know what exactly to do. The payload is not functioning on the file access.log.

Can anyone tell me the location of the correct log file?

well , it seems that it’s a random success , i got it worked one time only … . The only thing i did different is to reset the box then it works one time … even i did the exact same things it didn’t work a second time …

can you help me pls
i’m related htb-student@ubuntu:~$ ./logrotten -p ./payload /home/htb-student/backups/access.log
Waiting for rotating /home/htb-student/backups/access.log…

i do everything correctly

why he is not work

you have to trigger the rotate yourself by inputting random text into the log file. Good Luck this thread should help you. Academy linux priv esc > logrotate

1 Like

i find flag

I sent you a pm. Still stuck on it

Only use this help if you are really trapped.


What I did was following how IppSec exploited ‘Book’ HTB machine.

  • You create a simple bash script that throws a reverse shell and save it as a .sh file. Let’s suppose that I saved my script as /tmp/myscript.sh. Remember always to give execution permissions to these scripts with chmod +x /tmp/myscript.sh (this last suggestion applies for any machine and module).
  • I recommend you to build the logrotten binary inside the machine, since building it in your own machine could lead to errors with some libraries. So, basically, pass the .c file from logrotten Github repo to the victim machine (with wget, curl, scp or whatever you choose) and build it there.
  • Somewhere in the system htb-student has access to .log files (we could find it using find / -name "*.log" 2>/dev/null and selecting a directory that might be really interesting). I will call the directory where these htb-student logs files are stored as <DIRECTORY>.
  • Inside <DIRECTORY> you might find 2 files: a*****.log and a*****.log.1
  • Now to the “hard” part. How to “trigger” logrotten? You need to change/modify the target log file. I’ve been reading a lot of people that just runs the command and waits… and you can keep waiting infinitely, since you are the one that has to do the change in the log file and trigger logrotten. Start the nc listener. I copy the .log files and immediately I execute logrotten (all in one line):
cp <DIRECTORY>/a*****.log.1 <DIRECTORY>/a*****.log; /tmp/logrotten -p /tmp/myscript.sh <DIRECTORY>/a*****.log
  • How dou you know if this actually worked?

    • A new file .log should be created into /etc/bash_completion.d (just how the exploit itself works)
  • You should have received a reverse shell in your nc listener as the module teaches

Suggestion if you want to learn more: Now, many people encounter a problem: the reverse shell quickly dies. For the module it is more than enough just to quickly type and read the flag. But what I would like to do (for example, if I find a machine that is vulnerable to this exploit and the shell quickly dies) is, for example, to give SUID permissions to the bash. So I copy the command chmod 4777 $(which bash) in my machine and keep it on my clipboard, re-execute logrotten exploit with nc previously listening, and in the rev. shell as root I quickly past and execute the command above.

If this worked and you type ls -la $(which bash) you should see the output -rwsrwxrwxm where the important thing there is the s (indicating that the binary has now SUID permissions). If the reverse shell dies now it does not matter, since the bash has SUID permissions and in SSH session we can type bash -p and become root

1 Like