-How does one install a rootkit on a running box, while minimizing traces left behind -How do you leave your rootkit code on the machine such that booting it off of secure media and checking hashes of a class of files won't detect any changes -How do you maintain control over the machine from early in the boot process. Note that this isn't the only was to hide, depending on exactly what is checked in question two.
How to get on the box in the first place is the easiest step. It's done all day, every day. Buffer overflows are not a solved problem. Buffer overflows are not the only way to break into a box. Your questions about binary signatures, hashes etc... at this point do not matter. You have nothing checking binaries on the fly. Or I can do my work using binaries with a perfectly valid signature, or binaries that already exist on the system. Or I can do everything in RAM. I believe all the popular exploit frameworks have options that work straight out of RAM. I know Metasploit does. I can install the rootkit into the live kernel by modifying kernel RAM. That was done several years ago.
Question two: So, describe your file checking process to me. I believe you may have been originally talking about the RPM hash checking. That only covers a portion of your files. What about config files, your mail spool, your temp files, your documents, your log files, your profile files, and on and on. There are all these places code could be hidden. And then there is slack space, unused sectors, unpartitioned space, etc... Hiding isn't a problem.
The third question is really the only hard one. There are simple cases, like DOS. Bootsector viruses are 20+ years old on DOS. Here's how I'd do one for Linux, conceptually. I wouldn't want to actually tackle this, mind you...
Every operating system that wants to boot from a hard drive on a PC has to go through a particular process. After the BIOS is done, you sector 0, and start running it. Sector 0 knows enough to get to a several sectors, which know a little about a filesystem, which know how to find an OS-specific file, which switches the machine into real mode, and can load a disk driver, or a kernel, and so on.
So, I would substitute a part of the boot sector or the next chain of sectors in the process. Instead of loading the next piece that gets us to the real grub, I load my modified grub, which I have hidden on the disk. My modified grub loads my modified kernel, which I have hidden on the disk. From there, I can use the rest of the real filesystem.
The trick is, if you boot from a CD and inspect the filesystem, you find the original grub and kernel files. If you try to check things once Linux is up, my modified kernel is feeding you a version of reality that matches what you expect. I.e. if you check grub and the kernel file from the running Linux, it hands over copies of the original files for you to inspect.
True. But I'm starting to see a significant amount of the binaries that I analyze check to see if they are admin, and do different things based on that, and/or install themselves to multiple "startup" registry locations, including at least one HKCU.
If Windows culture were such that everyone switched to using a non-admin account, the malware is fully ready to adapt.
In fact, if I understood correctly, some of the MS05-039 worms this week are in essense using a local priv escalation. On XP & Win2K3 boxes, you can't get to the named pipe over the anonymous connection. However, one it's running on the box... you can use the loopback interface, and you are authenticated, and can attach the named pipe.
Or from memory. Or from a binary, which is then erased. Or from a 'text' file that is really shellcode designed to only use ASCII characters. What's your point?
There are tons of places hide rootkit code on the hard drive that do not fall under the category of binary files that you can check with tripwire.
Whatever code runs first on boot gets to own the box.
In the hardware examples I've been told about, this is a factory-set set of keys burned into the crypto processing chipset. One of the proposed features of a Palladium-like system is nonrepudiation. I.e. if they are trying to tie a piece of DRM music to only one machine, they don't want me swapping my keys about.
So no, that wouldn't be a place that a piece of rootkit would move into.
I've not heard of any proposal for nonvolitile storage for Palladium. So worst case, you'd have to reformat your hard drive and reinstall. Or are you being sarcastic?
To address part of your point though, I DO believe that it will be possible for someone to find a hole inthe Palladium software, and install a rootkit on the "Secure" side. If they do it right, then you might have to reformat to get rid of it.
Indeed you are correct. It was already called the "Next Generation Secure Computing Base" when I went up to interview for a job working on it.:) I find that more people know the term Palladium, though. Another (presumbaly different?) AC pointed out that it has been "cancelled". I believe that it was cancelled as it was previously constituted. The general project isn't dead at Microsoft, though.
Indeed. The technical and security capabilities behind something like Palladium are quite atractive. Rootkits are an excellent example of why. It's the loss of control over your own machine that has everyone freaked out, myself included.
I don't think I've ever seen Jose be so complimentary about a book before. Nice job, guys. I have the book as well, and I like what I've seen so far, but I haven't read enough yet to comment meaningfully.
I will point out though that the rootkit.com site has been around for a few years now, and obviously predates the book. In fact, I hope the book will explain in greater detail a lot of the technical topics from the site that are often only presented via code.
To give you fair warning, I don't think you'll find the tech level in this one any different from Continent. I think it's quite relative to the reader, and the reviewer's comments reflect his impression.
Having said that, I would of course love to have you thumb through it in a bookstore, and decide yourself. I expect you will be abe to find it on store shelves in a few weeks. The first printing just finished this week, and so far the only place you could have purchased it is at Black Hat. And tomorrow at Defcon.
Amazon, etc... should show stock in a week or two, I hope.
The claim is that a c/c++ compiler can do better assembly than a human. The only definitions of "better" that I would assume are faster and smaller. You might make a case for maintainability, which I don't care to argue. I've seen a lot more sloppy C code than assembly, but maybe that's just because there is so much more.
And I dispute your claim that a human can't write better assembly 100% of the time. I say they can write as good or better. After all, who wrote the compiler? Don't go giving extra-human abilities to a compiler.
This all assumes a skilled assembly coder, of course.
Well, I don't know how far it is from default at this point, but I've got the iBook in front of me, running 10.3.8. Looks like it's listening on the following:
TCP 548 (dunno) TCP 22 (SSH, I believe this was purposly enabled) TCP 139 UDP 137 (NB Name resolution, I assume) UDP 5353 (mDNS - aka Rendevous) UDP 631 (dunno) UDP 68 (DHCP client, I assume) UDP 514 (syslog, if memory serves)
Slashdot Mirror
Well, thanks for listening instead of just disagreeing. That's unusual around here. :)
You've asked about three things:
-How does one install a rootkit on a running box, while minimizing traces left behind
-How do you leave your rootkit code on the machine such that booting it off of secure media and checking hashes of a class of files won't detect any changes
-How do you maintain control over the machine from early in the boot process. Note that this isn't the only was to hide, depending on exactly what is checked in question two.
How to get on the box in the first place is the easiest step. It's done all day, every day. Buffer overflows are not a solved problem. Buffer overflows are not the only way to break into a box. Your questions about binary signatures, hashes etc... at this point do not matter. You have nothing checking binaries on the fly. Or I can do my work using binaries with a perfectly valid signature, or binaries that already exist on the system. Or I can do everything in RAM. I believe all the popular exploit frameworks have options that work straight out of RAM. I know Metasploit does. I can install the rootkit into the live kernel by modifying kernel RAM. That was done several years ago.
Question two: So, describe your file checking process to me. I believe you may have been originally talking about the RPM hash checking. That only covers a portion of your files. What about config files, your mail spool, your temp files, your documents, your log files, your profile files, and on and on. There are all these places code could be hidden. And then there is slack space, unused sectors, unpartitioned space, etc... Hiding isn't a problem.
The third question is really the only hard one. There are simple cases, like DOS. Bootsector viruses are 20+ years old on DOS. Here's how I'd do one for Linux, conceptually. I wouldn't want to actually tackle this, mind you...
Every operating system that wants to boot from a hard drive on a PC has to go through a particular process. After the BIOS is done, you sector 0, and start running it. Sector 0 knows enough to get to a several sectors, which know a little about a filesystem, which know how to find an OS-specific file, which switches the machine into real mode, and can load a disk driver, or a kernel, and so on.
So, I would substitute a part of the boot sector or the next chain of sectors in the process. Instead of loading the next piece that gets us to the real grub, I load my modified grub, which I have hidden on the disk. My modified grub loads my modified kernel, which I have hidden on the disk. From there, I can use the rest of the real filesystem.
The trick is, if you boot from a CD and inspect the filesystem, you find the original grub and kernel files. If you try to check things once Linux is up, my modified kernel is feeding you a version of reality that matches what you expect. I.e. if you check grub and the kernel file from the running Linux, it hands over copies of the original files for you to inspect.
True. But I'm starting to see a significant amount of the binaries that I analyze check to see if they are admin, and do different things based on that, and/or install themselves to multiple "startup" registry locations, including at least one HKCU.
If Windows culture were such that everyone switched to using a non-admin account, the malware is fully ready to adapt.
In fact, if I understood correctly, some of the MS05-039 worms this week are in essense using a local priv escalation. On XP & Win2K3 boxes, you can't get to the named pipe over the anonymous connection. However, one it's running on the box... you can use the loopback interface, and you are authenticated, and can attach the named pipe.
With a binary
Or from memory. Or from a binary, which is then erased. Or from a 'text' file that is really shellcode designed to only use ASCII characters. What's your point?
There are tons of places hide rootkit code on the hard drive that do not fall under the category of binary files that you can check with tripwire.
Whatever code runs first on boot gets to own the box.
Sure thing. Never heard of boot sector viruses?
In the hardware examples I've been told about, this is a factory-set set of keys burned into the crypto processing chipset. One of the proposed features of a Palladium-like system is nonrepudiation. I.e. if they are trying to tie a piece of DRM music to only one machine, they don't want me swapping my keys about.
So no, that wouldn't be a place that a piece of rootkit would move into.
Why would not being Administrator be a significant barrier for malware?
I didn't say "root", I said system. As in sufficient access to control the access control mechanisms. For example, a kernel bug.
You've got checksums for every single temp file on your Linux box, and all the slack space too? Impressive. :)
I've not heard of any proposal for nonvolitile storage for Palladium. So worst case, you'd have to reformat your hard drive and reinstall. Or are you being sarcastic?
To address part of your point though, I DO believe that it will be possible for someone to find a hole inthe Palladium software, and install a rootkit on the "Secure" side. If they do it right, then you might have to reformat to get rid of it.
Indeed you are correct. It was already called the "Next Generation Secure Computing Base" when I went up to interview for a job working on it. :) I find that more people know the term Palladium, though. Another (presumbaly different?) AC pointed out that it has been "cancelled". I believe that it was cancelled as it was previously constituted. The general project isn't dead at Microsoft, though.
Indeed. The technical and security capabilities behind something like Palladium are quite atractive. Rootkits are an excellent example of why. It's the loss of control over your own machine that has everyone freaked out, myself included.
Perhaps you should do a little reading on what Palladium is.
What do you think Microsoft is going to do about it? If someone has system access there isn't anything to be done about them moving in with a rootkit.
Oh wait, did you mean you want Palladium? Microsoft is way ahead of you, then.
I don't think I've ever seen Jose be so complimentary about a book before. Nice job, guys. I have the book as well, and I like what I've seen so far, but I haven't read enough yet to comment meaningfully.
I will point out though that the rootkit.com site has been around for a few years now, and obviously predates the book. In fact, I hope the book will explain in greater detail a lot of the technical topics from the site that are often only presented via code.
Cool, I'm glad you liked it.
To give you fair warning, I don't think you'll find the tech level in this one any different from Continent. I think it's quite relative to the reader, and the reviewer's comments reflect his impression.
Having said that, I would of course love to have you thumb through it in a bookstore, and decide yourself. I expect you will be abe to find it on store shelves in a few weeks. The first printing just finished this week, and so far the only place you could have purchased it is at Black Hat. And tomorrow at Defcon.
Amazon, etc... should show stock in a week or two, I hope.
Right. Take for example, Stephen King. The moral is, don't burn your fingers on the meteorite, and then stick them in your mouth.
(Note: I am in no way attempting to equate my fiction abilities with those of Stephen King.)
It's actually all written by one person, but you don't find that out til the last chapter.
:)
I wrote it by myself? The publisher owes me some more roylaties, then.
Yes, we will. Please come say hi if you're here.
Huh?
You might want to read the artcile linked, which clearly indicates that Dan does not work for Microsoft.
The claim is that a c/c++ compiler can do better assembly than a human. The only definitions of "better" that I would assume are faster and smaller. You might make a case for maintainability, which I don't care to argue. I've seen a lot more sloppy C code than assembly, but maybe that's just because there is so much more.
And I dispute your claim that a human can't write better assembly 100% of the time. I say they can write as good or better. After all, who wrote the compiler? Don't go giving extra-human abilities to a compiler.
This all assumes a skilled assembly coder, of course.
and I hope you wouldn't, modern c/c++ compilers can do better asm then humans anyway
No they can't, not even close.
You know the built-in software does that, right?
Or did you specifically mean for the uCLinux port?
Port 68 is open by default if your network requires DHCP.
And the others (that you didn't address in your reply) are on by default, then?
Well, I don't know how far it is from default at this point, but I've got the iBook in front of me, running 10.3.8. Looks like it's listening on the following:
TCP 548 (dunno)
TCP 22 (SSH, I believe this was purposly enabled)
TCP 139
UDP 137 (NB Name resolution, I assume)
UDP 5353 (mDNS - aka Rendevous)
UDP 631 (dunno)
UDP 68 (DHCP client, I assume)
UDP 514 (syslog, if memory serves)
What does netstat -an show on your box?