- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ a r t i c l e ] [ a u t h o r ] Trojan horse hiding under Linux Iron Code - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Table Of Contents: 1. Intro 2. Trojans as a single program 2.1. Starting the Trojan 2.1.1. Completion using rc.d 2.1.2. Completion using cron 2.1.3. Completion using at 2.1.4. Using a wrong PATH 2.2. Hiding 2.2.1. Names of the processes 2.2.2. When using cron and at 2.2.3. When using rc.d 2.2.4. When using a wrong PATH 2.2.5. Making procps a Trojan 3. Trojans, hidden in other programs 4. In general (more specific - hiding traffic) 4.1. Hiding IP traffic 4.2. Sending mail 4.2.1. Using a direct connection 4.2.2. Using sendmail 4.2.3. A Trojan in sendmail 1.Intro Trojans are alway the best way to get something others wouldn't give us. Trojans are programs that claim to do something but actually do something else without the knowledge of the user. I'm not going to teach you Trojan since this is not the subject of the article. I'll try to give you a push at the start when you start writing a Trojan. There are many different types of Trojans. But mainly they're divided into 2 major groups - 1) a Trojan hidden in a program; 2) a Trojan that is a program itself which hides and starts itself. The first group has some advantage that the second - for example no one is going to concern sendmail sending mail as an unusual thing. 2.Trojans as a single program This type of Trojans are easier to be created and have some advantages too. They're perfect for places where you have the root account(meaning you acquired it, not being yours:) and you can install it by yourself. 2.1 Starting the Trojan These Trojans can be started 2 ways. The first one is to start the Trojan manually (by the coder who coded it or by the victim). The other is the Trojan to start itself automatically. These 2 ways can be combined too - for example when the Trojan is st arted for the first time to be added for automatic start. The Trojan also can be resident/not-resident - to do something periodically or just to do it once and then aborts their action. 2.1.1 Completion using rc.d When Linux is being started after the kernel is loaded starts the scripts from the /etc/rc.d These scripts are not being configured frequently so they're good place to hide the Trojan. And if someone decides to configure them he may not see a single ro w added there (if it looks convincing enough). So the scripts from rc.d are very good for hiding resident Trojans. I recommend you use rc.M and rc.inet2 (and maybe rc.modules) 2.1.2 Completion using cron Cron is the system for periodical start of processes. It's very suitable for Trojans which don't need to be active all the time and have to do something periodically(for example - send the password and shadow files or scan periodically the /var/spool/m ail). Cron (mainly Dillon's Cron) consists of 2 parts - cron daemon(crond)which takes care for the processes when necessary and crontab (used to edit the cron tables). Every user has his own cron table where he can put processes to be executed. The processes will be executed at the correct time no matter if the user is logged at the moment or not. Sounds cool, eh :-) The format of the cron tables is this: "MIN HOUR DAY MONTH DAYOFWEEK COMMAND". You can define masks if you like, you can list (separated by ",") For example I'll paste some of the man page of crontab: # MIN HOUR DAY MONTH DAYOFWEEK COMMAND # at 6:10 a.m. every day 10 6 * * * date # every two hours at the top of the hour 0 */2 * * * date # every two hours from 11p.m to 7a.m., and at 8a.m 0 23-7/2,8 * * * date # at 11:00 a.m. on the 4th and on evert mon, tue, wed 0 11 4 * mon-wed # 4:00 a.m. on january 1st 0 4 1 jan * date # once an hour, all output appended to log file 0 4 1 jan * date >>/var/log/messages 2>&1 One of the advantages of this method is that when you look at the process list you won't find anything strange - the process is just not there. And if you make it start once a day or once an hour for half a second - no one is going to notice it! The weakness if this method is that the user may use the crontab to view the cron tables and then he's going to see the process which cannot be hidden. But if you think of a nice name for the program and a suitable comments for it this can trick the user. Other problem is that is the mashine is turned off when the process is supposed to start it just won't start. But if you're doing this on a computer that is suposed to be on constantly (maybe an ISP server) there is no need to worry about it. This method can be combined with the rd.c method in order to achieve bigger effect. For example the Trojan should start once a week (cron method) and anytime the system starts(rd.c). 2.1.3 Completion using at at is a system, similar to cron which schedules a one time execution of a program. It's perfect for destructive Trojans, log destroyers, etc. Actually at uses cron. It consists of 2 parts - atrun (which executes the process when the time has come) and the commands at, batch, atq and atrm. Atrun is situated in the cron table of the root. It starts periodically, checks if there are commands which time has come and should be executed. Normally it should have "* * * * *" mask in cron, but for example in Slack 3.6 it starts every 5 minutes. But this is of no great value to us. The commands at and batch are used to set a program for execution. The command atq shows a list of the command waiting to be executed and those who have been executed already. Atrm removes programs from the list. The weakness of this method is that when atq is started from the root user is shows the list of all the users (not only the root's) including those programs that have been executed already. So if you don't give a shit about this go ahead and do your thing. 2.1.4 Using a wrong PATH The system variable PATH shows a list of directories, which are searched when a program should be executed. The order of search is the order of the directories written in PATH. The variable starts with the log of a user and sets in the files .profile and .login (the system's PATH is stored in /etc/profile) If a user makes the running directory first in the PATH then the programs from the running directory are going to be executed first. Programs with the same name will be ignored. That's how you can make the user start the Trojan. You have to hide it as well that he won't see it. For example you put your command cat in the directory the user is often using and ....that's all :-) The advantage of this method is that you don't need to know the password of the user. You only need to have permission to write in some of the directories he uses frequently. This way when the program executes, it will have the privileges of the user. This method can also be combined with some of the others. 2.2 Hiding The Trojans wich are single programs is impossible to be hidden from the proclist. Well, unless you install a newer version of procps :-) But that's not an easy solution either. You can use different tricks to fool the user even if he sees the process running. 2.2.1 Names of the processes When you know that the program is going to be seen in the proclist (using ps, top, etc)it's nice if you choose a suitable name for the process so it won't be so obvious. This depends on you, but there are some ideas which SHOULD be mentioned. The Apache web server starts a couple processes, which are restarted after their work is done (to prevent exploiting). If the system is charged more processes are started. So no one will suspect one more httpd process: PID TTY TIME CMD 89 ? 00:00:00 httpd 90 ? 00:00:00 httpd 91 ? 00:00:00 httpd 92 ? 00:00:00 httpd 93 ? 00:00:00 httpd 94 ? 00:00:00 httpd This way you name the Trojan "httpd" and everything is perfect! You can also name the process agetty also. But if a man looks he'll see that there is no defined tty. But after all it's better to name it agetty than my_Trojan_horse :-) 2.2.2 When using cron and at As I already said this method is good because the processes are actually in the memory only when they're running and they're not seen in the processes list. But they can be seen when opening the cron table and at tasks. But this happens very rarely and you can use tricky names (it won't be suspicious if there is some strun running even if not in the /usr/lib). You can also change the commands atq and crontab so they wouldn't show some information. 2.2.3 When using rc.d Adding Trojans in the rc.d scripts you should pray that the user won't see that there is another program starting. To achieve this you should add it into : 1)Large scripts; or 2)scripts which are hardly ever configured. It's better to add the Trojan in both types of scripts. To give you a clue about the places you can place the Trojan here are some of the scripts : rc.0 , rc.6 - these are scripts used with system shutdown. rc.0 is used with halt, rc.6 - reboot. Very often these two are the same - on my machine rc.0 is just a link to rc.6 These cannot be used for Trojans. I mean - come on - how can you start a process at shutdown :-) rc.K - used at a passage into runlevel 1 which is single mode to kill all the processes. Not recommended to place the Trojan here - it's going to be killed:) And you won't need it in single mode. rc.S - started when the system boots. Turns on the swap and starts rc.modules, rc.pcmci and rc.serial rc.M - used at a passage to multi-user mode (after the start of the system). I believe this is the best place for Trojans to be put. Other good places are thescripts that are started by rc.M - rc.cdrom, rc.inet1, rc.inet2, rc.atalk, rc.font, rc.ibcs2, rc.httpd, rc.samba, rc.keymap, rc.local. Most suitable from those are rc.inet1 and rc.inet2. rc.cdrom - initialises the non-ATAPI CD-ROM's. If there is no CD-ROM or the CD-ROM is ATAPI it won't start. Not a good idea to use it. rc.inet1 - used to boot the base INET system. Makes the loopback connection and sets up the LAN(if there is one) rc.inet2 - this one boots the whole INET system; mounts the remote file systems; starts syslogd, portmap and inetd and all the necessery daemons needed for network. As I said - a perfect place for hiding Trojans. rc.atalk - loads the AppleTalk daemons - very rarely used. rc.font - setup the fonts. Don't trust this one since not everybody uses his fonts. rc.ibcs2 - loads iBCS. The scriot consists of 3 rows - the Trojan si going to be seen very easy, but noone is looking at this script. rc.httpd - the cript consists of 1 row - starts the httpd server (usually Apache). Small and there are people opening it. Not good idea! rc.samba - another short script for installation of samba server. rc.keymap - I don't have this script on my mashine :-) rc.local - initialises the local system. Mostly used only to start the gpm only. rc.modules - the script that installs some extra drivers. Nice because there is enough place to hide the start process. But there are always people editing it. 2.2.4 When using a wrong PATH With this method the only thing you should be concerned is that the user may see the program. But even then you may rely on "the biggest weakness of the humans"(Copyright EXo) - curiosity. But anywise, it's better if the user don't see the program. It's good to use the 'ls' command for example. Make your program a stealth-comand 'ls' so despite the fact that it's a Trojan it should do the normal job 'ls' does. 2.2.5 Making procps a Trojan The packet procps consists of tools for system information - ps, free, sessreg, skill, snice, tload, top, uptime, vmstat, w and watch. If you change them you may consider you've changed all the system tools for watching processes. Or at least 99% of them :-) When you start changing the procps mind the proc subdirectory in the sources.There you'll find the main headers and C-files used by all commands (top, pc, etc.) If you change somethig there, after the recompilation all the problems change. There's some food to think. An interesting file is proc/readproc.c and more precise - the functions readproc() and ps_readproc(). Its them who search processes, matching the criteria (list of pid's for example). They have to return information about the next suitable process to be added into the list. These functions are the basic, all other functions refer to them. So if you change this your problem is solved. These 2 functions actually search all the pid's and if the process doesn't match the criteria it's rejected and they continue searching the next. They continue until they find the right process or till the list is over. So it's convenient to us just to change a little bit so they can reject the process we want to :-) The 2 functions are almost similar - ps_readproc() is a copy/paste copy of readproc() and then just made a minor changes to fit in the 'ps' command requirements. If you change one of the functions it would be easy to change the other which is a good idea. 3. Trojans, hidden in other programs I have not much to say about this kind of Trojans, since they depend on what you want them to do. If you want to hide a process you just make a Trojan out of procps(read 2.2.5); if you want to trace the modem traffic you can make a Trojan in the source of the kernel and its modules. You can also give the user a program with hidden Trojan inside( the standart method used for Windows systems) who is going to extract itself somewhere and stay hidden there. there is one major advantage in Trojans hidden in other programs that the ones that are a program themselves. In the first case you don't need to hide the process because the user knows and thinks that this is a legal program. You have to be careful not to be obvious that you changed the original program. 4. In General (more specific - hiding traffic) Despite the differences between the two kinds of Trojans there are some common thing about them. One of them is the hiding of traffic. In most cases the Trojans are used to send us some data. How are we going to hide this data transfer? 4.1 Hiding IP traffic If you have to hide the traffic of a Trojan hidden in other program it's better to put the Trojan in the program which the administrator uses to trace his connections. For example you can put the Trojan in 'netstat'. Or if you know that on the certain machine tcpdump is active all the time (like the machines of ManiaX and mine too) it would be good idea to put the Trojan in tcpdump. It's possible to put the Trojan in the kernel to hide exact connections, but I don't have the slightest idea how this can be made. 4.2 Sending mail A Trojan is often made to send the results via e-mail. In order to do this the Trojan should send it. This can be done in a couple of ways: 4.2.1 Using a direct connection A good idea is using a direct connection to a specified SMTP server that you know is going to forward the mail. The Trojan connects to the server, sends what he's got and closes the connection. This method is very suitable if you've already taken care of tcpdump (or even better - if your Trojan is in tcpdump) 4.2.2 Using sendmail Other way to send mail is using 'sendmail' program. Not by the command (which can be seen) but by establishing connection using loopback interface to the local SMTP port (127.0.0.1:smpt) This way sendig the mail is done by 'sendmail' whose mail activity won't be suspicious to anyone. Another advantage is that tcpdump watches only one defined interface(meaning that when watching the traffic in the LAN or PPP connection the activity of your program using loopback won't be seen) 4.2.3 A Trojan in sendmail Puting Trojan in sendmail is maybe the best sollution when sending mail is a criteria. We have no loopback connections, no unusual processes - we just have a program doing what is is supposed to do - sending mail :-) That's from me for now. If I missed something don't blame me - I'm not able to write everything. Besides, what you're going to do depends on what you need the Trojan for. I hope you liked the ideas. Cya soon :-) Iron Code Copyright (C) 1999 Phreedom Magazine www.phreedom.org | phreedom.orbitel.bg staff@phreedom.org :: mboard.phreedom.org