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
logoutIt 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
/usr/local/bin/ls
root@598aff7ee097:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
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 .viminfoThough, 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=exitFor 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
/etc/apt/auth.conf.d/safepass/etc/apt/auth.conf.d/safepass
Loading password, please wait: | =
Loading password, please wait: | ==
Loading password, please wait: | ===
(..)
Loading password, please wait: | ======================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== | %100
d89b6a680212a1491055e8af4cbee432
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
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]'