Troll (bronze, 50p)

Tony really messed up this time.
He gave quick access to a stranger he met online to one of servers he owns and now Tony can't get back in to retrieve very important password from password manager he wrote called safepass.
To make it even worse some Troll who got server access hid the binary in some other location and Tony can't find it anymore since there are constant disconnections happening over SSH.

Try to log in with username: root and password: Cool2Pass into machine 10.XX.32.141 and help Tony to retrieve important password from safepass.
Can You help Tony to retrieve very important password from server?


Connecting to server via ssh and running ls, disconnects.

$ ssh root@10.XX.32.141
root@10.XX.32.141's password: Cool2Pass
Last login: Wed Oct  6 09:33:33 2021 from 10.XX.32.10Y
root@598aff7ee097:~# ls

It means that either ls is a command alias or ls binary forced disconnect. Let's check for alias.

$ ssh root@10.XX.32.141
root@10.XX.32.141's password: Cool2Pass
Last login: Fri Wed  6 09:33:37 2021 from 10.XX.32.10Y
root@598aff7ee097:~# alias
alias cd='exit'
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias find='exit'
alias flag='exit'
alias grep='grep --color=auto'
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -alF'
alias ls='exit'
alias w='exit'

Looks like commands cd, find, flag, ls and w are aliased to exit, which explains the disconnect. Let's fix that by clearing aliases and try ls again.

root@598aff7ee097:~# unalias -a
root@598aff7ee097:~# ls -al
qlqxi 78
aotu------ 6 ollq ollq 9596 Ozq  6 58:65 .
aotuo-uo-u 6 ollq ollq 9596 Sbm 79 59:97 ..
-ot------- 6 ollq ollq   88 Ozq  8 59:88 .yxpe_efpqlov
-ot-o--o-- 6 ollq ollq 8779 Nls  6  7575 .yxpeoz
-ot-o--o-- 6 ollq ollq  779 Nls 66  7575 .molcfib
aotuo-uo-u 7 ollq ollq 9596 Nls 66  7575 .ppe
-ot------- 6 ollq ollq  765 Ozq  6 58:65 .sfjfkcl

Now it looks like ls is mangling the output. Turns out, it is running /usr/local/bin/ls. Let's fix that by modifying PATH environment variable to use original /bin/ls.

root@598aff7ee097:~# which ls
root@598aff7ee097:~# echo $PATH
root@598aff7ee097:~# export PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin
root@598aff7ee097:~# ls -al
total 28
drwx------ 1 root root 4096 Oct  6 08:10 .
drwxr-xr-x 1 root root 4096 Sep 29 09:47 ..
-rw------- 1 root root   33 Oct  6 09:33 .bash_history
-rw-r--r-- 1 root root 3279 Nov  6  2020 .bashrc
-rw-r--r-- 1 root root  279 Nov 11  2020 .profile
drwxr-xr-x 2 root root 4096 Nov 11  2020 .ssh
-rw------- 1 root root  765 Oct  6 08:10 .viminfo

Though, we get disconnected after a while. Again and again.

Connection to 10.XX.32.141 closed by remote host.

It means something is killing our session. Turns out it is defined in the same place as malicious aliases - .bashrc file. Every 30 seconds a crontab is written and session killed. Entry in crontab kills session every minute. Below is the excerpt of .bashrc maliciousness.

alias flag="exit"
trap '' 2
(sleep 30; echo '* * * * * pkill -9 -u root 2>&1' > /etc/cron.d/cron  && crontab /etc/cron.d/cron && pkill -9 -u root) &
alias grep="exit"
alias find="exit"
alias ls=exit
alias ls=exit
alias cd=exit
alias w=exit

For good measure .profile file also contains the same malicious commands to kill the session, only every 40 seconds.

trap '' 2
(sleep 40; echo '* * * * * pkill -9 -u root 2>&1' > /etc/cron.d/cron  && crontab /etc/cron.d/cron && pkill -9 -u root) &

To not execute those start-up files, provide a command to execute when connecting with ssh. Also, fix PATH environment variable for usable ls command and remove all crontab entries to keep the session connected.

$ ssh root@10.XX.32.141 /bin/bash
export PATH=/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin:/usr/local/sbin
crontab -l
* * * * * pkill -9 -u root 2>&1
crontab -r
crontab -l
no crontab for root

Returning to challenge description and looking for safepass, reveals its location. Running it, takes a bit of time, but at the end, gives the flag.

find / -name safepass
Loading password, please wait: | =
Loading password, please wait: | ==
Loading password, please wait: | ===
Loading password, please wait: | ======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== | %100

bonus #1

Idea for this challenge is to execute /etc/apt/auth.conf.d/safepass (binary), which takes more than 30 seconds and session would be killed. One solution is to stop all session killers, but another solution is to download the file with sftp and run it locally or reverse engineer it. Looking at the file with radare2, reveals the flag quite nicely (read from bottom to top).

|           0x000009dc      e81ffdffff     call sym.imp.putchar        ; int putchar(int c)
|           0x000009e1      4c8d0d340620.  lea r9, obj.t2              ; 0x20101c ; "ee432"
|           0x000009e8      4c8d05410620.  lea r8, obj.t5              ; 0x201030 ; "e8af4cb"
|           0x000009ef      488d0d320620.  lea rcx, obj.t4             ; 0x201028 ; "1055"
|           0x000009f6      488d15250620.  lea rdx, obj.t3             ; 0x201022 ; "2a149"
|           0x000009fd      488d350c0620.  lea rsi, obj.t1             ; 0x201010 ; "d89b6a68021"
|           0x00000a04      488d3dea0000.  lea rdi, str._s_s_s_s_s     ; 0xaf5 ; "%s%s%s%s%s" ; const char *format

bonus #2

Modified /usr/local/bin/ls (binary) actually executes /bin/ls, but mangles it's output. It runs the following command:

/bin/ls $*|tr '[a-z]' '[x-za-w]'|tr '[0-4]' '[5-9]'