Anatomy of a Break In
His careful attack won't be discovered for three days. Checking the logs from the scanner he left running overnight, he finds a suitable target on the east coast of the US; fast processor, lots of drive space but, most importantly, a fat pipe to the Net. It's running the right version of named, the one with the buffer overflow that hasn't made bugtraq yet. No patches are even out for it yet.
He runs the script he pulled off the H4x0rs board: he's in. ("H4x0r" is one of a number of creative misspellings often used in computer cracking discussions.) He edits the logs and gets to work installing the root kit to make sure the sysadmin can't kick him off even if he's found.
Now it's time to make sure the machine is secure. He doesn't want his rivals taking this hacked computer away from him. He disables named and, to make sure it won't come back on reboot, he removes /etc/init.d/named. He remembers that there might be a buffer overflow with lpd too, so he disables it the same way. "I should send them a bill for security consulting", he chuckles while "stealing" the machine.
He creates a couple of directories recommended in the root kit, /dev/ttyyy is easy for the rightful sysadmin to overlook. His friends recommend /dev/..., so he creates one of those as well.
The root kit includes a loadable kernel module. He's not sure exactly how it works, but the cracking board says its very new and very 'l33t. What the kernel module does is make discovering the new files placed on the system difficult; it hides them and hides itself. lsmod, which lists the currently loaded kernel modules, shows nothing. It also hides files and processes beginning with .kore. He installs the trojaned identd included in the kit. He doesn't know that /usr/sbin/in.identd is a symlink to /usr/sbin/identd.d, and he copies it over as both. He changes the user and group of one to root and, in his haste, forgets to change the other. He's anxious; this is only the second computer he's ever broken into, and he's worried he might be discovered before he gets completely setup.
He installs his IRC server; it goes easily. That will earn him some "cracker currency", goodwill, for proving a service to his peers. He's a little worried about using the trojaned identd to get back into the system, so for good measure he edits /etc/inetd.conf to open a root shell on port 24452. When he tries to restart inetd he can't find it. He figures out that the new Red Hat Linux 7.0 uses the more sophisticated xinetd. He goes off to educate himself on xinetd. When he figures it out, he uses it to open his root shell port. Now, getting root on the machine is as easy as telnet hacked_computer 24452.
Happy with what he's done, he logs out and starts spreading the word of his newly 0wn3d machine. After looking around on his new (though physically remote) computer for a while, he logs out and starts checking his scanner logs for another host. He'll revisit it several times over the next few days, performing various system administration tasks.
Three days later, a system administrator comes in and checks his morning logs. He's been tweaking his logcheck for a couple of years, and it usually spews very little garbage. Today, his automated log reporting shows that someone has been knocking on his computers' doors. "Nobody at that university should be connecting to this machine", he thinks, so he pulls out his standard "Somebody's hacking me, please make it stop" letter. He pastes in the lines from the syslog and starts looking for his counterpart at the university to send it to. Eventually it finds me.
I get into work Thursday morning and start reading my logs. They're all e-mailed to me, which helps make sure I see them; but it makes for a lot of e-mail. I get Tripwire notices and logchecks, Sendmail bounces and various other crond-generated messages from a dozen or two workstations, mostly Solaris on Suns and Linux on Intels. I start a couple of Tripwire updates and question the number of brain cells I actually have for not being able to get certain noise out of my logcheck e-mails, no matter how hard I try. "egrep on Solaris must be broken", I think. I flirt with the idea of actually reading my copy of Mastering Regular Expressions, realize it's at home and instead start reading my other e-mail in reverse chronological order.
First I notice an e-mail from Mike (name is changed to protect the innocent), a colleague of mine, saying he had shut down the Ethernet interface on a computer he had recently set up, and maybe that would hold them for a little while. Mike was out for the day, but logging in from home, he read the common sysadmin e-mail we share and had started damage control. That sounded serious.
After reading the rest of the related e-mails, I figured out part of what was going on and went to the cracked computer and sat down at the console. Time to do some of that Linux sysadmin stuff they pay me for.
I didn't really know much about the computer in question. I logged on. who and w, showed no one logged on but me. I checked last--nothing. Having dissected several cracked boxes before, I knew better than to really trust anything it told me. System tools are often replaced with versions that lie. I hate it when "my" computer lies to me. But I also know that crackers seldom replace all the tools, and when they disagree it's a clue. So I keep checking and rechecking. I try netstat. It shows a couple of recent connections, including an IRC port. My department doesn't run any IRC servers. Bingo. That tells me something is really amiss with this computer. I know the machine has been "0wn3d" ("owned", that is to say taken over by crackers.) I open a file and start taking notes, verbally expressing my dissatisfaction to myself under my breath and acknowledging its going to be a long morning. I cut and paste the info from netstat into the file. I've captured half a dozen IP addresses. One may belong to the blackhat jerk that interrupted my morning e-mail reading. (Note to self: try to find a source of IP-address-seeking cruise missiles.)
- Machine Learning Everywhere
- Own Your DNS Data
- Bash Shell Script: Building a Better March Madness Bracket
- Understanding OpenStack's Success
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- From vs. to + for Microsoft and Linux
- Natalie Rusk's Scratch Coding Cards (No Starch Press)
- The Weather Outside Is Frightful (Or Is It?)
- Ensono M.O.