Smells FISH(y)
August 16th, 2005 by ido, Filed under: Web
I’m an administrator of a VPS (Virtual Private Server). A few days ago I noticed something weird on the VPS : a weird process running a Perl script, that redirects its output to the O mighty black hole: /dev/null. The prompt variable of Bash (PS1) was set to be empty and the script itself was written like a VBA code (without indentation or line breaks). When I made a quick glance at the script, I saw that one Regex inside was looking for a command such as rmdir (for example), and it will unlink a directory.
Sounds like a back door that someone wrote, and all that it needs now is to open a shell for you and get over with it …
Well NO! This script was used by KDE (in this case) for simple SSH connection, that mimics the behavior of sftp, but over a simple ssh connection. The owner of the VPS used the KDE’s way (Konqueror ?) to login into the server… and KDE installed the script for the user.
Now when the user logged in, the commands “users” and “who” will not show you the user itself (“who -a” will show something, but not who is the user or the IP of the connected user). “last” also will not give you much information about the login, and if you try to hide the process, then even “ps” will not help (I first saw that issue using ps)…
Oh btw the script also read and wrote information to and from /var/log/messages.
BTW, this script implements the FISH protocol.
How do I know that you ask? Well thats what the Perl script says 
.
It seems that KDE (and other clients) try to help their users by implementing a sftp like actions without leaving the ssh client.
Sounds cool ? well I guess so… but then again, it IS a back door. That is if someone will be able to make the “server” talk with him without any need for authentication.
People should stop being lazy, and start using the right tool for the right job. Using FISH, can be exploited the same way that rlogin, telnet and NULL Session are .
-
Is your site safe from SQL Injection? Sign up for an Automated Vulnerability Detection Service today!
Subscribe
Subscribe
Ahmm.. I use fish all the time - its the best way to work remotely. I think its relatively secure - I mean, you can only get to the script after going through the SSH authentication process (key, interactive, whatnot), and its not like its suid or something.
I agree that KDE should put some effort into making the FISH session more obvious to the server’s owner, what that script is and what it does (i.e - have it cooperate with ‘who’) and I’m sure that if you open a ticket in their bugzilla about it they’ll be glad to help (or not - there are many open tickets, some which I submitted, some which are very important, which has gotten very little notice).
The problem that FISH solves, is that many non-OpenSSH servers do not implement SFTP (its just an extension anyway), and also it can easily be disabled in OpenSSH. Some poor souls I know has access to an non-SFTP server, for which FISH and WinSCP is the only way to have a graphical frontend - unless you are ok with insecure FTP.
At any case, possibly there might be security issues if one user can access the fishsrv.pl script of another (though I don’t see that as likely as the files are chmoded 444), but if you feel that there is cause for concern - you can implement a simple job (cron or something) that scans users’ home directories and remove them every couple of minutes. It won’t negatively affect users’ experience, as KDE would simply recreate the script if it can’t find it, and as you can only unlink (contrary to “delete”) open files - it won’t even hurt running sessions.