[00:01.080 --> 00:03.400] Okay, I guess we'll go ahead and get started. [00:04.400 --> 00:06.860] I am Julian Grizzard and I'm a graduate student [00:06.860 --> 00:10.500] at Georgia Tech and studying computer security. [00:10.780 --> 00:12.960] And today I'm gonna give you a talk on [00:12.960 --> 00:17.100] Surgical Recovery from Current-Level Rootkit Installations. [00:17.740 --> 00:20.360] And this is on Linux-based systems. [00:22.890 --> 00:25.710] So first off, the latest slides, tools, [00:25.710 --> 00:29.010] and our spine architecture work is available online. [00:29.110 --> 00:31.110] The links to this is on your CD. [00:31.110 --> 00:33.930] And so definitely download the latest, [00:33.930 --> 00:35.090] spent a lot of changes. [00:36.850 --> 00:40.630] All right, so first off, some background on Rootkits. [00:40.630 --> 00:42.270] What does a Rootkit do? [00:42.710 --> 00:45.290] So a Rootkit is a toolkit that an attacker will use [00:45.830 --> 00:47.930] to retain access to your system [00:47.930 --> 00:52.290] and hide activity that he's doing on your system. [00:52.790 --> 00:54.590] A Rootkit doesn't give you access to a system [00:54.590 --> 00:57.070] if you don't have prior access. [00:57.070 --> 00:59.570] You have to exploit the system by some known vulnerability [00:59.570 --> 01:01.230] or something you figured out, [01:01.230 --> 01:02.990] or social engineering or whatever. [01:03.630 --> 01:07.350] And then the attacker will usually install a Rootkit [01:07.850 --> 01:10.670] in order to come back into the system at a later point [01:10.670 --> 01:14.350] in case the password changes or his vulnerability's patched. [01:18.630 --> 01:22.530] So how many people have personally had experience [01:22.530 --> 01:25.230] with a Rootkit installed on a system they administered? [01:25.790 --> 01:28.430] We got some people, oh wow, we got lots of people out there. [01:28.430 --> 01:32.450] Interesting, and so what is the recommended thing to do [01:32.450 --> 01:35.090] when you get a Rootkit installed on your system? [01:37.070 --> 01:39.490] That's right, format and reinstall. [01:39.790 --> 01:43.630] So I'm actually going against that grain, [01:43.630 --> 01:44.050] you know what I'm saying? [01:44.050 --> 01:46.530] Okay, maybe there's more efficient ways [01:46.530 --> 01:48.130] to recover from a Rootkit. [01:48.130 --> 01:49.710] I mean, what if you got a server [01:49.710 --> 01:53.650] that every minute of downtime costs millions of dollars? [01:53.690 --> 01:56.310] I mean, how can you format and reinstall that system? [01:58.210 --> 02:00.470] So we're going to look at different ways [02:00.470 --> 02:02.110] to recover from a Rootkit. [02:02.910 --> 02:06.230] So first off, I want to give you guys some background [02:06.230 --> 02:09.210] on operating systems because what a Rootkit does [02:09.210 --> 02:11.850] is it replaces parts of your operating system. [02:11.850 --> 02:15.090] So it's important to understand how an operating system works [02:15.090 --> 02:18.490] in order to understand the design of Rootkits. [02:19.030 --> 02:22.210] So this is a monolithic operating system. [02:22.490 --> 02:25.850] That's just a fancy term for this particular architecture. [02:25.850 --> 02:28.050] Linux looks like this. [02:28.070 --> 02:29.830] Windows, all the windows look like this. [02:29.830 --> 02:31.430] Most systems look like this. [02:32.270 --> 02:34.830] So you've got two parts to an operating system. [02:34.830 --> 02:38.610] You've got the kernel space and this is the code [02:38.610 --> 02:40.410] that runs right on top of your hardware, [02:40.410 --> 02:44.210] controls all your devices, schedules your processes, [02:44.690 --> 02:47.950] does your file access, network stack, these kinds of things. [02:50.580 --> 02:52.800] And you have user space. [02:52.800 --> 02:54.340] User space is where the programs [02:54.340 --> 02:55.740] that you really care about run. [02:55.740 --> 02:57.840] So P1 could be your word processor, [02:57.840 --> 03:02.880] P2 could be a LS, bash command, and so on and so forth. [03:04.420 --> 03:08.080] Now I want to give you a contrasted operating system design [03:08.080 --> 03:09.680] that I'll come back to later. [03:09.840 --> 03:10.980] But I just want to give you a preview [03:10.980 --> 03:14.200] and compare and contrast to current OSs. [03:14.200 --> 03:17.540] This is the microkernel operating system design. [03:18.260 --> 03:20.820] The difference here is you have a very thin layer [03:20.820 --> 03:22.280] for the kernel space. [03:22.700 --> 03:26.280] You have minimal, I mean, only code you have in the kernel [03:26.280 --> 03:28.780] is the minimum amount of code needed [03:28.780 --> 03:31.800] to guarantee isolation among processes [03:31.800 --> 03:33.420] and that kind of thing. [03:33.420 --> 03:37.620] All the drivers, video, disk, hardware, network, [03:37.620 --> 03:39.960] all this stuff is pushed into user space [03:39.960 --> 03:43.120] sitting alongside your user space processes. [03:43.220 --> 03:46.200] And each bubble here is guaranteed isolated [03:46.200 --> 03:47.980] by the microkernel. [03:50.430 --> 03:53.450] So what guarantees this isolation? [03:53.850 --> 03:56.210] Well, on the Intel x86 architecture, [03:56.350 --> 03:58.450] a lot of you have probably heard of this ring architecture [03:58.850 --> 04:01.650] where you have level 0, 1, 2, 3. [04:01.930 --> 04:04.350] And it turns out modern operating systems [04:04.870 --> 04:06.190] only use two levels. [04:06.190 --> 04:08.930] They use level 0 for the kernel, [04:08.930 --> 04:11.370] which gives you unlimited access to the hardware. [04:11.490 --> 04:14.890] If you have a program running at level 0, [04:14.890 --> 04:18.970] you can do anything to any bit anywhere in the computer. [04:19.630 --> 04:22.770] And the user space processes run at level 3, [04:22.770 --> 04:24.170] which is shown in yellow here. [04:24.730 --> 04:26.770] And if you want access, [04:26.770 --> 04:28.890] they don't have direct access to the hardware. [04:28.890 --> 04:30.450] If you want access to the hardware, [04:30.450 --> 04:31.650] you have to make a system call, [04:31.650 --> 04:33.430] ask the kernel to do it for you. [04:36.090 --> 04:38.550] So I want to show you just real quick [04:40.910 --> 04:42.970] how this is implemented in the hardware. [04:42.990 --> 04:44.970] There's a 16-bit code segment register [04:44.970 --> 04:49.970] on Intel Pentiums and x86 processors. [04:50.570 --> 04:52.950] And the lower two bits of that register [04:52.950 --> 04:56.390] specify what privilege level you're running at, [04:56.390 --> 04:57.970] which is which ring you're in. [04:58.710 --> 05:01.410] And this is some test code to test [05:01.410 --> 05:02.890] and see which ring you're in. [05:05.110 --> 05:08.950] So I'm going to demo this code running real quick. [05:08.950 --> 05:11.490] Just a quick demo here. [05:13.840 --> 05:17.640] So I have a Linux box running over here to my right. [05:18.320 --> 05:19.940] I'm going to log into that. [05:30.190 --> 05:33.990] All right, so I have this getcpl program [05:33.990 --> 05:36.290] that gets your current privilege level. [05:36.450 --> 05:37.710] And it returns three, [05:37.710 --> 05:39.590] because I'm running a user space process [05:39.590 --> 05:41.870] forking off the command line. [05:43.350 --> 05:45.090] Now let's check out the kernel. [05:53.880 --> 05:57.820] All right, so I inserted a kernel module called... [06:00.360 --> 06:02.440] Well, it's way too big on there. [06:03.780 --> 06:06.220] I inserted a kernel module called getcpl, [06:06.220 --> 06:08.420] which all it does is... [06:10.200 --> 06:13.740] Right here, all it does is pops the CS register [06:13.740 --> 06:16.080] from into a variable, [06:16.080 --> 06:19.460] and ends it with a three to get the ring level. [06:19.960 --> 06:23.820] And if you look at the bar log sys log, [06:24.620 --> 06:26.360] you can see that, in fact, [06:26.360 --> 06:28.060] the kernel is running at ring zero. [06:37.490 --> 06:39.850] All right, I'm going to get my next demo set up, [06:39.850 --> 06:41.430] and we'll go back to the presentation. [06:50.220 --> 06:51.900] And so these slides here are just showing that. [06:51.900 --> 06:59.840] All right, so if you're looking at the operating system, [06:59.840 --> 07:02.000] and you want to make a user level rootkit, [07:02.000 --> 07:02.800] how do you do it? [07:02.800 --> 07:05.140] Well, you attack files on the hard disk, [07:05.140 --> 07:06.500] shown in red here. [07:06.960 --> 07:11.080] And so you replace ps, netstat, ls, top, password. [07:11.120 --> 07:13.400] These kinds of files, you replace those [07:13.400 --> 07:16.280] with malicious files that hide your activities. [07:16.280 --> 07:18.320] Hide files, hide network connections, [07:18.320 --> 07:19.480] these kinds of things. [07:19.840 --> 07:21.500] And so when you replace those files, [07:21.500 --> 07:24.520] they get loaded into your processes, [07:24.520 --> 07:26.060] the green bubbles up there. [07:27.020 --> 07:29.300] So that is pretty much the user level rootkit. [07:29.320 --> 07:30.680] It's pretty easy to detect. [07:30.680 --> 07:33.280] You just run tripwire, check your system [07:33.280 --> 07:34.840] against your known good state, [07:34.840 --> 07:36.660] and it's not too difficult. [07:36.660 --> 07:37.900] We know how to do that. [07:38.480 --> 07:40.280] Definitely tripwire has its issues, [07:40.280 --> 07:43.900] but there's a way to deal with those. [07:44.480 --> 07:46.000] Now kernel level rootkit attacks, [07:46.000 --> 07:48.720] they modify the running kernel code [07:48.720 --> 07:50.500] and the running data structures, [07:50.500 --> 07:52.800] which is this block shown here in red. [07:53.280 --> 07:55.480] So anything in there is suspect [07:55.480 --> 07:58.180] to being attacked by a kernel level rootkit. [07:58.520 --> 08:01.100] And all a kernel is, is a running program [08:01.100 --> 08:02.820] on your computer. [08:02.860 --> 08:04.620] So in essence, these kernel level rootkits [08:04.620 --> 08:08.000] are modifying code on the fly [08:08.000 --> 08:11.320] and redirecting that code to malicious code. [08:11.820 --> 08:14.480] In particular, the system calls [08:15.060 --> 08:18.920] is the gateway from user space to kernel, [08:18.920 --> 08:20.200] and that's a good target. [08:20.200 --> 08:22.500] And I'll go over those two examples. [08:23.600 --> 08:26.040] So first I want to go over a system call [08:26.040 --> 08:31.720] and why that is the most popular attack target [08:31.720 --> 08:33.240] for kernel level rootkits. [08:33.380 --> 08:36.040] So it's important to understand how a system call works [08:36.460 --> 08:39.940] in order to A, detect that the system call [08:39.940 --> 08:43.020] has been tampered with, and B, recover from it. [08:43.600 --> 08:47.120] So what happens, what do you use a system call for? [08:47.120 --> 08:48.440] Okay, say you're a user process [08:48.440 --> 08:51.300] and you want to read files from a hard disk. [08:51.440 --> 08:53.320] Then you can't do that directly [08:53.320 --> 08:55.260] because you don't have access to the hardware. [08:55.260 --> 08:58.340] So you issue a system call to the kernel [08:58.920 --> 09:01.440] to open, read the contents of those files, [09:01.440 --> 09:02.660] and so on and so forth. [09:03.240 --> 09:06.120] So for instance, let's say we have a sys read system call. [09:06.120 --> 09:07.080] What happens? [09:07.260 --> 09:08.400] Well, the first thing that happens [09:08.400 --> 09:14.660] is your user space process issues an int 0x80 instruction, [09:14.660 --> 09:16.980] which says a software interrupt, [09:16.980 --> 09:20.420] which indexes into 0x80th entry [09:20.420 --> 09:22.800] of the interrupt descriptor table. [09:23.380 --> 09:24.860] And that's shown right here. [09:25.100 --> 09:27.540] So as soon as you issue that interrupt, [09:27.540 --> 09:29.020] you go over to the kernel, [09:29.020 --> 09:31.860] the kernel looks up where the IDT is in memory, [09:31.860 --> 09:33.840] looks up that 0x80th entry, [09:33.840 --> 09:37.320] and executes the code pointed to by that entry. [09:37.760 --> 09:39.360] The code pointed to by that entry [09:39.360 --> 09:41.660] is the system call handler. [09:42.680 --> 09:45.100] And the system call handler is responsible [09:45.100 --> 09:48.620] for setting up parameters of your system call, [09:48.620 --> 09:50.600] generic parameters, it works, [09:50.600 --> 09:53.380] that's the first thing that's called for any system call. [09:53.680 --> 09:55.420] And then it calls the system call [09:55.420 --> 09:57.520] you specifically requested. [09:57.960 --> 10:00.500] So you see this pointer coming out of the code [10:00.500 --> 10:02.340] in the system call handler, [10:02.340 --> 10:04.660] which points to the system call table. [10:05.020 --> 10:08.920] So it references, let's say for sys read, [10:08.920 --> 10:11.040] you look up this entry number three [10:11.040 --> 10:13.720] in the system call table over here. [10:14.380 --> 10:15.940] And that redirects you down here [10:15.940 --> 10:17.900] to the sys read system call. [10:18.480 --> 10:20.980] And the sys read then takes the parameters [10:20.980 --> 10:22.620] given to it by a system call handler [10:22.620 --> 10:24.960] and executes your request. [10:28.890 --> 10:31.070] So what's the attack points here? [10:31.110 --> 10:34.310] Anything in this chain is an attack point. [10:34.690 --> 10:37.110] You could redirect the IDT entry, [10:37.110 --> 10:39.070] you could redirect the system call handler [10:39.070 --> 10:41.030] reference to the system call table, [10:41.030 --> 10:43.910] you could redirect individual system calls, [10:43.910 --> 10:45.630] you could overwrite the system call [10:45.630 --> 10:48.850] with a jump instruction to go somewhere else. [10:48.850 --> 10:50.890] All these are susceptible. [10:59.310 --> 11:03.290] So, how do you recover from this system call attack? [11:03.470 --> 11:04.690] Well here's the algorithm, [11:04.690 --> 11:08.950] it's basically installing a new system call table [11:08.950 --> 11:11.290] into the running kernel. [11:11.290 --> 11:13.910] This is exactly what a rootkit will do, in fact. [11:13.910 --> 11:15.790] But we're gonna use a good system call table [11:15.790 --> 11:18.450] that has known good state. [11:19.070 --> 11:22.290] So the best place to get that is to keep a copy [11:22.290 --> 11:25.410] of your kernel on another disk on safe storage [11:25.810 --> 11:27.530] and you can rip out these system calls [11:27.530 --> 11:31.650] using what I did was modify GDB to get that code out. [11:32.250 --> 11:34.890] And so you, it's pretty simple, you just, [11:34.890 --> 11:37.770] well, it's somewhat simple, it is kernel stuff, [11:37.770 --> 11:42.850] but basically you copy each system call into kernel memory [11:42.850 --> 11:45.630] and then you create a new system call table [11:45.630 --> 11:47.130] pointing to all those system calls [11:47.550 --> 11:49.270] and then you can set the handler [11:49.270 --> 11:51.570] to point to that system call table. [11:52.330 --> 11:54.270] And there's, you can go full blown, [11:54.270 --> 11:56.950] you can, if we go back to this picture, [11:56.950 --> 12:01.210] you can set this pointer right here [12:01.210 --> 12:03.630] which is on the left for you guys [12:05.190 --> 12:07.690] and you can point that to a new system call handler [12:07.690 --> 12:09.390] if you want and that way you'll know [12:09.390 --> 12:11.310] the whole chain is correct. [12:15.360 --> 12:17.440] Okay, so it's a little bit, [12:17.440 --> 12:19.180] just want to give you guys some details on, [12:19.180 --> 12:21.980] it's not quite that simple, you can't just copy stuff over. [12:22.080 --> 12:24.340] When you copy code around in memory, [12:24.340 --> 12:26.760] x86 code has these call instructions [12:26.760 --> 12:28.820] with relative offset parameters, [12:28.820 --> 12:30.520] so you have to adjust them, [12:30.520 --> 12:32.640] basically relink them into the kernel. [12:33.180 --> 12:34.880] So you could recompile the code [12:35.400 --> 12:36.720] if you know where it's gonna be loaded, [12:36.720 --> 12:40.800] but I chose just to recompute those relative offsets [12:40.800 --> 12:44.820] as I was inserting each system call into memory. [12:45.300 --> 12:47.880] And you adjust the relative offset [12:47.880 --> 12:50.500] based on where it's placed in memory [12:50.500 --> 12:52.860] because you allocate dynamic memory for it [12:52.860 --> 12:55.860] and you compare that to where it was originally in memory [12:55.860 --> 12:57.940] and you just subtract the difference. [12:58.880 --> 13:00.680] Of course, it's a little bit more confusing [13:00.680 --> 13:03.320] with the way the Intel architecture works, [13:03.320 --> 13:05.140] but that's the gist of it. [13:06.800 --> 13:11.080] So another thing is there's multiple ways into the kernel. [13:11.440 --> 13:12.620] I'll just give you some background. [13:12.620 --> 13:15.220] This is another tidbit of kernel-level rootkit stuff [13:15.220 --> 13:18.960] is you can insert a kernel module into the kernel [13:18.960 --> 13:21.060] and muck with the system call table. [13:21.300 --> 13:23.760] And that's one way to penetrate the kernel. [13:24.480 --> 13:26.340] Another way you can get into the kernel [13:26.340 --> 13:29.260] is through the dev.kmem.device file. [13:29.580 --> 13:34.680] This device file gives you access to the kernel memory [13:35.440 --> 13:36.900] as a file. [13:37.400 --> 13:38.880] So if you're a user space process, [13:38.880 --> 13:41.540] you can open that dev.kmem like it's a regular file. [13:41.660 --> 13:45.000] You can seek to it and you pass it a kernel memory address [13:45.000 --> 13:46.500] and it seeks that memory [13:46.500 --> 13:49.440] and then you can read that data or write to it. [13:51.140 --> 13:54.540] Is anybody familiar with the SuckIt rootkit [13:54.540 --> 13:56.960] from those people that have had installations [13:56.960 --> 13:58.220] on their computers? [13:59.040 --> 14:01.120] We got some people, all right. [14:02.460 --> 14:03.760] So there's a few more. [14:03.760 --> 14:06.780] Okay, so if you want to install your rootkit [14:06.780 --> 14:09.480] from dev.kmem without doing a kernel module, [14:09.480 --> 14:11.260] there's a couple of things that are tricky. [14:12.300 --> 14:14.500] First, how do you find the system call table? [14:14.640 --> 14:15.960] You don't have the symbols. [14:16.400 --> 14:19.520] And two, how do you allocate memory [14:19.520 --> 14:22.160] to insert new code into the kernel? [14:26.470 --> 14:28.270] All right, so first I'll just go over [14:28.270 --> 14:30.830] how you find the system call handler right quick. [14:31.490 --> 14:35.090] This is some code pulled out of SuckIt. [14:35.090 --> 14:41.190] First thing you do is you pop the IDT register into memory. [14:41.890 --> 14:45.530] And what that is, is that tells you the address. [14:45.530 --> 14:47.610] Let's go back a few slides real quick. [14:47.610 --> 14:50.670] That tells you where this table is in memory. [14:54.210 --> 14:56.730] All right, so now you know where that table is. [14:56.790 --> 15:01.070] So then you read the 0x80th entry of that table [15:02.670 --> 15:06.730] and you can compute where the system call handler is [15:06.730 --> 15:08.870] in memory. [15:08.870 --> 15:10.390] And then you can parse the system call handler [15:10.390 --> 15:12.870] to find out where the system call table is. [15:15.980 --> 15:20.460] All right, so how do you get dynamically allocated memory [15:20.460 --> 15:24.460] from the kernel from user space? [15:24.460 --> 15:27.880] If you write a kernel module, you just use kmalloc, [15:27.880 --> 15:31.040] but you don't have access to that code from user space. [15:31.460 --> 15:35.460] Well, the way SuckIt does it is sets up kmalloc [15:36.000 --> 15:37.820] as a system call. [15:38.480 --> 15:40.460] So there's a number of unused system calls [15:40.460 --> 15:42.120] in the system call tabler. [15:42.980 --> 15:44.660] SuckIt takes over one of those system calls [15:44.660 --> 15:47.420] and points it to kmalloc. [15:47.420 --> 15:51.320] So now you can issue system call 180 or something like that [15:51.320 --> 15:54.660] and pass it a size, memory allocation size [15:54.660 --> 15:57.400] and you'll get kernel memory returns. [16:01.140 --> 16:04.020] Okay, so now I wanna do my next demo. [16:24.770 --> 16:28.070] Okay, so the scenario here is [16:28.710 --> 16:31.430] I've already got root access to this machine, [16:31.430 --> 16:34.690] so I'm wanting to install my rootkit to retain access [16:34.690 --> 16:36.390] and to hide some files. [16:36.650 --> 16:38.310] In this folder right here, [16:40.090 --> 16:43.270] I have some bank accounts I wanna store on this computer [16:44.990 --> 16:47.170] and don't worry, these are not legit. [16:49.990 --> 16:51.270] At least I hope not. [16:53.230 --> 16:55.270] Okay, so we've got this data [16:55.270 --> 16:56.790] that I don't wanna store on my own computer, [16:56.790 --> 16:58.690] but I wanna store it on this machine [16:58.690 --> 17:01.230] that I've compromised so I can trade it with somebody else, [17:01.230 --> 17:02.710] something like that. [17:06.140 --> 17:08.300] So then I've already downloaded [17:08.300 --> 17:10.480] my SuckIt rootkit onto the system [17:12.180 --> 17:17.360] and I'm going to install it and it's done. [17:17.800 --> 17:22.240] So now that directory that I was just showing you up here, [17:22.240 --> 17:26.320] this hidden info.sk12 is now hidden. [17:26.700 --> 17:31.220] The way this works is anything that ends in .sk12 [17:31.220 --> 17:32.440] will be hidden. [17:32.440 --> 17:37.520] For instance, if I touch a file called hide.me, [17:38.880 --> 17:40.580] you can see that it's there. [17:40.640 --> 17:46.720] If I move hide.me to hide.me.sk12, it's gone. [17:51.840 --> 17:54.960] So now I'm the administrator of this computer [17:55.520 --> 17:58.720] and I believe I may have a rootkit on my system. [17:59.360 --> 18:02.100] So what I'm going to do is try [18:02.100 --> 18:04.040] and install a new system call table [18:04.040 --> 18:07.280] to see if there's any differences in the file system. [18:10.120 --> 18:12.280] Okay, so this takes a little bit of time [18:12.280 --> 18:13.860] because it's not optimized. [18:14.100 --> 18:15.100] It's good for demo though [18:15.100 --> 18:17.160] because I can explain a few things. [18:17.520 --> 18:20.380] So what you see here is each little block of code, [18:20.380 --> 18:24.100] it's copying a system call into kernel memory. [18:25.500 --> 18:28.360] It issues a kmalloc for each one of these, [18:28.360 --> 18:29.800] copies it in, and then you see these [18:30.500 --> 18:33.780] asterisks, asterisks, asterisks, found, dot, dot, dot. [18:33.780 --> 18:35.860] It's finding these call instructions [18:35.860 --> 18:40.320] and it's recomputing where they need to be relinked to [18:40.320 --> 18:41.880] and setting that. [18:43.960 --> 18:47.020] So right now we're at about 130 system calls [18:47.020 --> 18:48.740] that have been copied into memory. [18:48.740 --> 18:53.440] Turns out Linux has 255-ish system calls. [18:54.400 --> 18:57.640] And so we'll be through this here in a second. [19:12.400 --> 19:14.500] Does anybody have any questions so far? [19:14.500 --> 19:15.900] We've got a few more minutes. [19:29.980 --> 19:31.420] From what I've found, I mean, [19:31.420 --> 19:34.100] that's a possibility that they have absolute calls, [19:34.100 --> 19:36.680] but you could relink those in as well. [19:36.780 --> 19:40.060] From what I've found, they don't have absolute calls. [19:50.470 --> 19:51.870] Excellent, excellent question. [19:51.870 --> 19:53.730] I will get to that very shortly. [19:56.050 --> 20:02.050] All right, so the new system call table has been installed. [20:02.050 --> 20:04.890] Now notice these hidden files come back up. [20:05.810 --> 20:07.390] So as you can see, all Sucket was doing [20:07.390 --> 20:09.050] was redirecting some system calls. [20:09.050 --> 20:11.630] So we install a known good system call table into memory. [20:11.710 --> 20:13.990] All of a sudden, these files come back up. [20:24.140 --> 20:25.820] Does anybody have any other questions [20:25.820 --> 20:28.320] while we got a stopping point in the presentation? [20:43.830 --> 20:45.330] How does it catch it? [20:48.680 --> 20:50.480] Right, let's go back to that figure. [20:53.860 --> 20:59.200] All right, so you're saying this code right here [20:59.200 --> 21:01.840] is being overwritten or something like that. [21:02.440 --> 21:05.520] Okay, so first off, the tools I was just showing you [21:05.520 --> 21:07.820] do not do rootkit detection. [21:07.820 --> 21:09.060] Well, some of them do, [21:09.060 --> 21:11.780] but the recover rootkit itself does not. [21:12.240 --> 21:14.940] I do have the ability to read any system calls, [21:14.940 --> 21:20.440] or I could dump this code for sysread to a file [21:20.440 --> 21:22.740] and see if it's been overwritten. [21:22.740 --> 21:24.620] For instance, to answer your question, [21:24.620 --> 21:25.400] that would be the way to do it. [21:25.480 --> 21:26.860] It's changing memory. [21:29.740 --> 21:34.280] So the way the recovery tools work is, [21:34.280 --> 21:37.700] right now it actually just replaces this pointer [21:37.700 --> 21:39.340] to a new system call table. [21:40.100 --> 21:43.200] And so that's gonna shoot over here into memory somewhere. [21:43.520 --> 21:45.060] You got a new system call table over here, [21:45.060 --> 21:46.800] you got a new sysread over here. [21:46.940 --> 21:49.780] So even if this sysread right here was overwritten, [21:49.780 --> 21:52.420] that's not a problem because we aren't depending on that. [21:52.780 --> 21:53.800] Good question. [21:59.250 --> 22:03.830] Okay, so back to our gentleman's over here's question. [22:04.330 --> 22:08.730] Okay, so it turns out if you use devkmem [22:09.550 --> 22:14.870] to modify the kernel, as I do with my recovery tools, [22:15.210 --> 22:19.370] or even if you use a kernel module to do the recovery, [22:19.370 --> 22:23.950] either one of these approaches relies on system calls [22:23.950 --> 22:25.370] to do the recovery. [22:25.490 --> 22:27.410] So there's an obvious problem here. [22:27.410 --> 22:31.550] If you've installed a rootkit that's redirected system calls [22:32.410 --> 22:34.430] and you're depending on those system calls [22:34.430 --> 22:39.450] that's redirected, then you may be depending on code [22:40.010 --> 22:44.030] that's going to prevent your recovery tools from working. [22:45.110 --> 22:46.730] Does that make sense to everybody? [22:46.730 --> 22:48.030] It's a little bit confusing. [22:48.430 --> 22:55.910] Okay, so how do we deal with this? [22:56.710 --> 23:03.110] Well, I propose we need a new system architecture. [23:03.310 --> 23:07.870] And let me take a minute to explain the vision I have here, [23:07.870 --> 23:09.770] which goes much beyond rootkits [23:09.770 --> 23:13.290] and much beyond anything like that. [23:13.290 --> 23:18.010] I've got this vision of intrusion recovery system. [23:18.670 --> 23:20.270] So this is like, you know, [23:20.270 --> 23:22.130] you've got your intrusion detection system, [23:22.130 --> 23:24.310] you've got your intrusion prevention system, [23:24.870 --> 23:28.790] but bottom line is we still have compromises every day. [23:28.790 --> 23:30.950] It's still a problem for the foreseeable future. [23:31.190 --> 23:34.730] So we need to think about ways [23:34.730 --> 23:37.370] to more quickly recover from compromises [23:37.370 --> 23:39.090] given that they're going to be a problem. [23:39.090 --> 23:40.790] Systems are so complex. [23:41.510 --> 23:44.130] So that's why I've come up with this notion [23:44.130 --> 23:46.270] of an intrusion recovery system, [23:46.270 --> 23:49.050] which has a new system architecture [23:49.510 --> 23:52.690] that's not currently used in widely available OSs. [23:52.690 --> 23:55.690] And it's capable of verifying [23:55.690 --> 23:57.390] the integrity of the running system [23:57.970 --> 24:02.030] and repairing that state if it has some problems. [24:02.690 --> 24:04.170] And it has, you know, [24:04.170 --> 24:07.790] obviously there's got to be some kind of, [24:07.790 --> 24:11.370] this has got to be the top most secure piece of your system [24:11.370 --> 24:15.230] because you rely on it for, you know, [24:15.230 --> 24:16.570] your system running good. [24:16.750 --> 24:19.350] So you have to have some kind of way [24:19.350 --> 24:21.930] to store known good state for your system. [24:22.430 --> 24:24.510] Because if you store the known good state in your system [24:25.010 --> 24:28.250] that is accessible by root, then that can be changed. [24:28.310 --> 24:32.370] So this new architecture supports these kinds of things. [24:32.450 --> 24:34.550] It supports what I call a state hold, [24:34.550 --> 24:35.990] which is kind of like a strong hold, [24:35.990 --> 24:37.770] but it stores your state instead. [24:38.710 --> 24:40.490] And it does these other things. [24:40.490 --> 24:43.890] And I'll go over, this is my research right now. [24:43.890 --> 24:45.350] So it's certainly in development. [24:45.470 --> 24:47.970] And I'm looking for any kind of feedback you guys have. [24:47.970 --> 24:49.710] It's probably got some problems, [24:49.710 --> 24:51.110] but I'll show you what I've got. [24:51.110 --> 24:53.710] And we'll see what you say. [24:54.630 --> 24:57.990] So back to the beginning, I showed you, [24:57.990 --> 25:00.050] you've got the monolithic operating systems [25:00.050 --> 25:03.370] and then you've got these microkernel operating systems. [25:04.230 --> 25:05.030] Well, I'm gonna go back [25:05.030 --> 25:07.070] to this microkernel operating system. [25:07.490 --> 25:10.990] Turns out this looks really good for security applications. [25:11.630 --> 25:13.630] If you look at the microkernel, [25:13.630 --> 25:19.050] it has about 20,000 lines of code that run the kernel. [25:19.670 --> 25:21.610] Compare that to the Linux kernel, [25:21.610 --> 25:23.530] which has on the order of 4 million. [25:23.950 --> 25:27.310] So we can hopefully better guess [25:27.310 --> 25:30.370] or better rely on the microkernel for correctness. [25:30.470 --> 25:33.770] Matter of fact, there's some research microkernels out there [25:33.770 --> 25:38.050] that try and formally prove that the microkernel is correct. [25:40.980 --> 25:43.360] The system calls to the microkernel, [25:43.360 --> 25:47.240] there's only 14 or so, just depends on the implementation. [25:47.440 --> 25:49.460] Maybe on the order of 10. [25:49.460 --> 25:51.720] So you've got a small number of system calls [25:51.720 --> 25:52.980] that do basic stuff. [25:52.980 --> 25:57.960] You do IPCs, you do inter-process communication, [25:57.960 --> 25:59.540] you do thread management, that kind of thing. [25:59.540 --> 26:00.800] That's it, actually. [26:00.880 --> 26:02.680] All the hardware access, [26:02.680 --> 26:04.760] these kinds of things are pushed to user level. [26:09.140 --> 26:12.520] So based on this microkernel design, [26:13.460 --> 26:16.060] I've laid out this spine architecture [26:16.060 --> 26:18.580] for the intrusion recovery system. [26:20.340 --> 26:24.100] At the base of the architecture you have the microkernel, [26:24.100 --> 26:27.500] which I'm using L4 Fiasco implementation, [26:27.500 --> 26:31.360] which is developed by a university in Dresden, Germany. [26:33.060 --> 26:37.100] And on top of that runs the guest kernel, [26:37.100 --> 26:40.040] the L4 Linux implementation runs on top of that. [26:40.040 --> 26:41.940] So you can run a full-blown version of Linux [26:41.940 --> 26:43.920] on top of the microkernel. [26:44.660 --> 26:46.820] So you're probably more familiar [26:46.820 --> 26:49.980] with the term virtual machine than you are microkernel. [26:49.980 --> 26:53.480] Turns out these are very highly related topics. [26:53.900 --> 26:56.440] Essentially the microkernel does the same thing for us. [26:56.660 --> 26:58.820] And so we have this guest kernel, [26:58.820 --> 27:01.900] which is L4 Linux running on top of it. [27:02.580 --> 27:06.500] At the next level you've got your user processes, [27:06.500 --> 27:08.760] and those run just like they do on Linux. [27:08.760 --> 27:10.180] You don't even have to modify them. [27:11.480 --> 27:14.900] And then over here on the first, [27:14.900 --> 27:17.440] only Fiasco runs in kernel mode. [27:17.440 --> 27:21.480] So only Fiasco runs in that ring zero, [27:21.480 --> 27:24.020] and everything else runs in ring three. [27:24.460 --> 27:27.600] That means even if you have root access [27:27.600 --> 27:30.240] on the kernel machine, [27:30.240 --> 27:33.080] you're not guaranteed access to all bits [27:33.080 --> 27:35.060] in the computer system. [27:39.310 --> 27:42.870] So on the right here I have at each level [27:43.750 --> 27:46.470] a component of the intrusion recovery system. [27:46.470 --> 27:49.470] I call them L0, L1, L2, L3. [27:49.930 --> 27:51.550] And L0 is just the hardware. [27:51.550 --> 27:53.290] There's really no support for that right now, [27:53.290 --> 27:55.850] just except the ring stuff. [27:56.390 --> 28:00.050] Turns out Intel and IBM, these kinds of companies, [28:00.050 --> 28:02.670] are very interested in hardware support [28:02.670 --> 28:04.010] for virtual machines. [28:04.010 --> 28:06.710] So in the future this will definitely be huge. [28:08.050 --> 28:11.530] L1 is a component I have running at the microkernel. [28:11.890 --> 28:13.950] The importance of this component [28:14.310 --> 28:17.790] is it's able to verify that the guest kernel [28:17.790 --> 28:20.810] and the L2 component are operating correctly. [28:21.550 --> 28:24.190] And similarly for L2 to L3. [28:24.270 --> 28:30.190] And why do I have these various levels in the system? [28:30.190 --> 28:31.710] Well it turns out if you're looking at [28:31.710 --> 28:38.790] the entire Linux operating system from L1, [28:38.790 --> 28:40.730] you're gonna have a hard time interpreting [28:40.730 --> 28:42.010] all the data structures, [28:42.010 --> 28:43.930] interpreting what's good, what's bad. [28:43.930 --> 28:48.750] So it's much easier to run components in each level [28:49.970 --> 28:53.670] in order to understand the semantics of that level. [28:54.770 --> 28:59.010] And the vertical hierarchy is a way of guaranteeing [28:59.010 --> 29:02.410] that those components are not trojaned or stopped [29:02.410 --> 29:04.410] or bypassed, these kinds of things. [29:07.250 --> 29:09.150] So there's a lot more details here. [29:09.150 --> 29:10.470] I just wanna give you a few. [29:10.470 --> 29:12.310] I'll just show you the memory real quick. [29:12.310 --> 29:14.530] How does the memory work for instance? [29:14.890 --> 29:16.470] So down here at the bottom, [29:16.470 --> 29:22.190] you have the microkernel L1 which owns all the memory. [29:24.510 --> 29:28.190] And it can allocate some of the physical, [29:28.190 --> 29:30.050] by memory I mean the RAM. [29:30.050 --> 29:32.850] It can allocate some of the RAM to the guest kernel [29:32.850 --> 29:34.710] which is shown in red here. [29:35.030 --> 29:37.210] And you can see that portions of the memory [29:37.210 --> 29:38.790] are still owned by the microkernel [29:38.790 --> 29:42.090] and the Linux guest kernel cannot touch that memory. [29:42.750 --> 29:45.930] And then in turn, the guest kernel, [29:45.930 --> 29:48.670] the Linux kernel can map some of its memory [29:48.670 --> 29:50.710] to user space processes. [29:53.050 --> 29:56.050] All right, so this is the system. [29:56.050 --> 29:57.290] How do we attack it? [29:57.290 --> 30:00.090] So you can attack any of these things in user space. [30:00.090 --> 30:01.950] If you have root access, you have access [30:01.950 --> 30:05.370] to all these components highlighted in red here. [30:06.070 --> 30:08.810] So again, the L2 and L3 components [30:09.180 --> 30:13.950] of the intrusion recovery system are suspect to attack. [30:14.070 --> 30:15.890] And that's why we need L1 to verify [30:15.890 --> 30:17.630] that they're operating correctly. [30:18.950 --> 30:22.830] So right now, I'm still working on algorithms [30:23.380 --> 30:26.350] to determine when L2 and L3 are operating correctly. [30:26.350 --> 30:30.510] So far, I only have monitoring the PC instruction counter [30:30.510 --> 30:35.430] and verifying the hash of the code at L2 [30:35.430 --> 30:38.330] to verify and check that the program counter [30:38.330 --> 30:40.230] runs in that code periodically. [30:41.130 --> 30:44.310] If anybody's got some ideas on other ways to verify, [30:44.310 --> 30:45.970] I'd definitely like to talk to you. [30:47.630 --> 30:50.330] Okay, so now I wanna look at another [30:50.330 --> 30:52.650] kernel-level rootkit target. [30:53.490 --> 30:56.510] So it turns out these same kernel-level rootkits [30:56.510 --> 31:01.110] will work on this new spine architecture. [31:01.310 --> 31:02.670] They will attack the guest kernel [31:02.670 --> 31:04.790] instead of the host kernel. [31:05.410 --> 31:07.730] So I wanna go through another target [31:08.250 --> 31:09.690] to give you guys some more background [31:09.690 --> 31:11.890] on how kernel-level rootkits work. [31:12.510 --> 31:15.870] This target is the virtual file system. [31:16.350 --> 31:18.050] Now, the virtual file system in Linux [31:18.690 --> 31:23.650] is a wrapper that gives you access [31:23.650 --> 31:26.090] to all file systems in Linux. [31:26.090 --> 31:28.790] And so you can insert your own virtual file systems. [31:28.790 --> 31:32.150] If you have an ext3 formatted partition, [31:32.150 --> 31:34.470] then you insert that in the VFS [31:34.470 --> 31:38.310] and you don't have to readjust your system calls [31:38.310 --> 31:39.270] to point to that. [31:39.270 --> 31:41.570] Everything goes through the virtual file system. [31:42.130 --> 31:43.670] Let me show you how it works. [31:45.070 --> 31:49.210] So first off, a system call is issued. [31:49.210 --> 31:53.450] Let's say I'll go over the proc file system in this example. [31:53.770 --> 31:55.610] Let me back up a minute. [31:56.110 --> 31:59.070] So you have lots of different file systems in Linux. [31:59.070 --> 32:02.550] You have your file system for your hard disk. [32:02.550 --> 32:07.990] You have remote disk storage stored on another network drive. [32:07.990 --> 32:10.110] You have the proc file system, [32:10.110 --> 32:12.830] which is a file system built by the kernel [32:12.830 --> 32:14.950] and gives you information from the kernel, [32:14.950 --> 32:20.590] such as task IDs, and so on and so forth. [32:21.510 --> 32:23.850] So if you want to, remember, [32:23.850 --> 32:25.590] if you wanna get access to the file system, [32:25.590 --> 32:28.230] any file system, you have to issue a system call. [32:29.210 --> 32:30.730] So in this example, [32:30.730 --> 32:33.930] I want to read the contents of the proc directory [32:33.930 --> 32:37.110] to see what processes are running on my system. [32:37.790 --> 32:41.670] So first, my program will issue a sys read dir. [32:42.750 --> 32:47.130] That sys read dir indexes into the virtual file system, [32:47.130 --> 32:50.590] which then, and you've told it to open up this proc, [32:50.590 --> 32:51.990] some directory in proc. [32:52.570 --> 32:54.650] So the virtual file system knows, [32:54.650 --> 32:56.530] based on the path you gave it, [32:56.530 --> 32:59.430] where it needs to go to service your request. [32:59.590 --> 33:01.810] For proc, that's a special file system. [33:01.810 --> 33:04.730] It indexes into its root structure. [33:05.570 --> 33:09.650] And there's a lot of pointers in that root structure. [33:09.810 --> 33:14.170] The F underscore op stands for file operations, I believe. [33:14.710 --> 33:17.790] And so for the proc, you look up [33:17.790 --> 33:22.390] what are the file operations for that file system. [33:22.850 --> 33:25.790] And so there's a F op structure, which is standard. [33:25.790 --> 33:28.110] And for each file system, [33:28.110 --> 33:30.630] you have to implement a number of function pointers. [33:30.630 --> 33:34.430] In this case, read dir is the one I'm going to highlight. [33:34.930 --> 33:37.950] So you've indexed all the way in here to read dir. [33:38.050 --> 33:42.310] And finally, you get to the proc read dir code. [33:43.150 --> 33:45.250] And so that'll then return information [33:45.250 --> 33:46.450] back to your system call, [33:46.450 --> 33:49.830] and then return that information back to your user program. [33:53.530 --> 33:56.370] Okay, so what's the attack points here? [33:56.370 --> 33:59.870] Again, it's the same basic idea. [33:59.950 --> 34:01.690] Anytime you've got a function pointer, [34:01.690 --> 34:03.210] anytime you've got a reference, [34:03.210 --> 34:06.230] any code along the path can be redirected. [34:11.760 --> 34:15.840] All right, so what's the recovery algorithm for this? [34:15.840 --> 34:17.840] Well, now's when we sort of step back [34:17.840 --> 34:19.620] and make it more general. [34:19.860 --> 34:21.780] So generally, the recovery methods [34:21.780 --> 34:25.140] for kernel-level rootkits is consistency checking [34:25.140 --> 34:28.700] on the data structures in the kernel and the code running. [34:28.700 --> 34:31.580] And you can store a copy of this, [34:31.580 --> 34:32.700] what it should look like [34:32.700 --> 34:34.720] in your protected spine architecture. [34:35.500 --> 34:38.000] And you can use that to check and see [34:38.000 --> 34:42.540] if it's been modified in a manner [34:42.540 --> 34:44.280] that's against your policy. [34:44.600 --> 34:49.320] And if so, then you repair it back to its known good state. [34:50.840 --> 34:53.800] And the IRS can do this automatically. [34:53.800 --> 34:58.460] And that's sort of the vision, [34:58.460 --> 35:01.160] is you have this system that's constantly monitoring [35:01.160 --> 35:05.800] your computer for malicious rootkit installations. [35:05.800 --> 35:09.960] If that happens, it undoes the damage from it. [35:09.960 --> 35:13.760] And furthermore, have longer-term goals of, [35:13.760 --> 35:16.200] okay, so yeah, you've got a rootkit installed. [35:16.200 --> 35:17.620] You undo this damage. [35:17.620 --> 35:19.740] The attacker still got in your system somehow. [35:20.300 --> 35:22.400] You also have to figure out how he got out, [35:22.400 --> 35:24.320] kick him out, change passwords. [35:24.320 --> 35:26.620] It's more than just repairing the system. [35:26.620 --> 35:27.860] It's a lot more complicated. [35:29.420 --> 35:31.560] All right, so let's go for another demo. [35:52.660 --> 35:55.920] Now, for the purposes of this demo, [35:55.920 --> 35:59.400] I'm not using the automated repair of the system [36:00.240 --> 36:02.920] because you wouldn't be able to see that anything happened. [36:05.490 --> 36:07.650] But one thing I wanna show you real quick [36:07.650 --> 36:13.450] is I am, in fact, running the spine architecture now. [36:16.380 --> 36:17.640] And you can see that I'm running [36:17.640 --> 36:24.020] the Linux 2.6.11-L4 kernel, [36:24.020 --> 36:27.400] which is, the way it works for the Linux kernel [36:27.400 --> 36:31.240] is you port the Linux kernel to the L4 architecture [36:31.240 --> 36:35.480] as opposed to the I386, the alpha, so on and so forth. [36:37.100 --> 36:38.960] So, in fact, we can go in here [36:38.960 --> 36:41.060] and check out our getcpl again [36:41.700 --> 36:44.980] to see if our privilege levels have changed. [36:45.960 --> 36:49.400] And so, the user processes still run at ring three, [36:49.400 --> 36:50.520] which is expected. [36:51.680 --> 36:55.220] And let's see what the kernel is now running at. [37:00.100 --> 37:02.860] And so, can everybody see this in the back? [37:02.860 --> 37:04.420] Or should I call it out for you guys? [37:05.640 --> 37:06.740] Move it up? [37:09.600 --> 37:10.920] Sorry about that. [37:13.320 --> 37:14.520] Is that better? [37:15.980 --> 37:16.860] Thanks. [37:17.400 --> 37:18.980] Okay, so what I've just done, [37:18.980 --> 37:20.620] let me scroll back up for you guys then. [37:22.000 --> 37:26.700] Um, so right here I just did the getcpl [37:27.300 --> 37:30.580] and it returned ring three, running in ring three. [37:31.620 --> 37:36.400] And I've just inserted the getcpl into the running kernel. [37:36.660 --> 37:40.660] And you can tell the var log, sys log, [37:41.340 --> 37:42.760] and see that it was printed out [37:42.760 --> 37:44.500] as running in ring three now. [37:44.500 --> 37:47.100] So now the kernel is running in ring three. [37:47.100 --> 37:50.000] If anybody out there is familiar with user mode Linux, [37:50.000 --> 37:51.940] it's a very similar concept to that, [37:51.940 --> 37:53.600] but it's much, much faster. [37:55.360 --> 37:58.440] In terms of performance, I'll take a slight venture. [37:58.560 --> 38:01.160] Just in case you guys are wondering, [38:01.160 --> 38:03.460] you figure about a 10% performance penalty [38:03.460 --> 38:05.760] for running in this architecture. [38:06.360 --> 38:10.340] So it runs about 90% the speed of Linux [38:10.340 --> 38:11.900] running directly on your hardware. [38:18.780 --> 38:22.340] Okay, so for the second demo, [38:22.340 --> 38:28.000] I'm going to install the Adore Next Generation rootkit. [38:28.000 --> 38:31.760] And this rootkit works on the Linux 2.6 kernel. [38:34.620 --> 38:36.920] And what this rootkit does is exactly [38:36.920 --> 38:40.860] what I was just showing you with the virtual file system. [38:40.860 --> 38:42.880] It redirects the virtual file system [38:43.260 --> 38:51.020] to malicious structures so it can hide files and processes. [38:57.710 --> 39:02.950] Okay, so I've just loaded the rootkit. [39:04.170 --> 39:08.430] Notice first off that my Adore NG directory [39:08.430 --> 39:10.990] that I was just in is now hidden. [39:10.990 --> 39:12.450] That's part of the configuration. [39:12.450 --> 39:15.550] It hides whatever your rootkit directory is. [39:16.090 --> 39:21.410] And then I'm going to launch this rootme binary, [39:21.410 --> 39:23.990] which doesn't really do anything, but it runs. [39:24.310 --> 39:26.130] And you can see right here in the process list [39:26.130 --> 39:28.330] that rootme is running. [39:29.430 --> 39:30.870] Now I've got to scroll back up here [39:30.870 --> 39:32.750] and see what my directory was. [39:34.150 --> 39:37.910] So I'm going to go back into the Adore NG directory. [39:37.910 --> 39:41.530] I'm tabbing over right now, and that's another system call. [39:41.530 --> 39:45.410] It doesn't find that there's an Adore NG directory, [39:45.410 --> 39:47.310] so I have to type the full path. [39:48.470 --> 39:50.630] And there's a user-level utility [39:50.630 --> 39:52.950] to go with this Adore NG rootkit, [39:52.950 --> 39:56.010] which can hide processes for you. [39:56.590 --> 40:00.210] So I want to hide this process 644. [40:09.250 --> 40:10.970] So now rootme's gone. [40:12.490 --> 40:16.010] All right, so now I'm going to put on [40:16.010 --> 40:18.130] my system administrator hat again, [40:18.130 --> 40:22.690] and I suspect that a rootkit's been installed. [40:23.330 --> 40:24.550] This could be done automatically [40:24.550 --> 40:26.790] with the intrusion recovery system, [40:26.790 --> 40:28.850] but again, for the purposes of this demo, [40:28.850 --> 40:30.270] I will do it manually. [40:32.830 --> 40:36.830] And so what I'm going to do is a similar algorithm [40:36.830 --> 40:40.250] to the system call table repair. [40:40.590 --> 40:44.170] I am going to, but this time I made it a little bit simpler. [40:44.170 --> 40:45.850] I just fixed the pointers back [40:45.850 --> 40:47.070] to where they're supposed to be. [40:52.560 --> 40:56.060] Okay, so I've just repaired the proc file system, [40:56.640 --> 41:00.660] and now you can see the rootme file, our process is back. [41:02.680 --> 41:06.360] And you can see the adore-ng directory is back. [41:06.820 --> 41:08.480] So in fact, we've been able to recover [41:08.480 --> 41:10.380] from these kernel-level rootkits. [41:15.210 --> 41:18.610] Okay, let's go back to wrap up things here. [41:31.600 --> 41:34.920] All right, so I've shown you the ability to recover [41:34.920 --> 41:37.120] from some kernel-level rootkits, [41:37.120 --> 41:38.600] and presented you with an architecture [41:38.600 --> 41:41.400] that's perhaps more robust, [41:41.400 --> 41:44.300] and you can somewhat rely on for this recovery. [41:45.160 --> 41:47.380] So, I mean, definitely there's some limitations [41:47.380 --> 41:49.980] to this system, I'm still developing it now, [41:49.980 --> 41:53.100] so any feedback you guys have would be great. [41:53.680 --> 41:56.580] Some of the limitations, you know, first off, [41:56.580 --> 41:58.120] how can you trust this microkernel? [41:58.120 --> 42:01.060] What if the attacker installs a rootkit [42:01.060 --> 42:02.340] into the microkernel? [42:02.340 --> 42:04.760] Well, you know, that's a hard question, [42:04.760 --> 42:08.680] but it's relying on the smallness of the microkernel [42:08.680 --> 42:12.360] to be correct to prevent that capability. [42:13.020 --> 42:15.560] You know, one of the things that some of you guys [42:15.560 --> 42:17.220] are probably thinking about already is, [42:17.220 --> 42:19.500] what about direct memory access, [42:19.500 --> 42:21.040] where you program a controller [42:21.040 --> 42:23.920] to overwrite the microkernel? [42:23.920 --> 42:26.440] Well, that's definitely a problem right now, [42:27.200 --> 42:28.880] that's a limitation. [42:29.020 --> 42:32.620] In future, Intel architectures that support [42:33.860 --> 42:38.760] better isolation, that hopefully will not be a problem. [42:39.260 --> 42:41.180] So, and finally, you know, [42:41.180 --> 42:43.400] just like everything else with security, [42:43.400 --> 42:46.120] there's no be-all, end-all solution. [42:46.320 --> 42:50.120] However, I believe this IRS can make your systems [42:50.120 --> 42:54.720] more reliable and save us a lot more time and trouble. [42:55.960 --> 42:58.400] So thanks to a lot of people that have helped me out, [42:58.400 --> 43:00.000] you know, there's lots more people on here [43:00.000 --> 43:01.800] than I have listed. [43:02.380 --> 43:05.000] These people in particular have been helpful. [43:06.140 --> 43:07.500] I got some links for you guys, [43:07.500 --> 43:08.800] if you wanna find out some more information [43:08.800 --> 43:10.280] about what I've been talking about. [43:10.600 --> 43:13.380] Various architectures, system projects here, [43:13.380 --> 43:15.900] you know, check rootkit, our research. [43:17.200 --> 43:20.100] And at this time, we got a few starter questions, [43:20.100 --> 43:21.420] if anybody wants to comment on, [43:21.420 --> 43:23.920] and if not, if you got your own questions, that's fine. [43:23.920 --> 43:26.280] We got about five minutes or so. [43:26.480 --> 43:28.160] And also after the talk, [43:28.160 --> 43:30.500] I will be heading out that door over there. [43:30.500 --> 43:32.180] So if you guys wanna catch me, [43:32.180 --> 43:34.720] definitely link up with me outside. [43:35.560 --> 43:39.360] So first off, let me just ask these three questions, [43:39.360 --> 43:41.820] and I'll take either answer these comments [43:41.820 --> 43:43.880] to these questions or your own questions. [43:44.240 --> 43:45.840] So I've already asked this question, [43:45.840 --> 43:47.020] how many people have personally dealt [43:47.020 --> 43:48.280] with the recovery of rootkit? [43:48.280 --> 43:50.220] If anybody has a testimony, [43:50.220 --> 43:51.880] we might can share that in a minute. [43:51.960 --> 43:52.980] Let me read all three of these [43:52.980 --> 43:54.660] and then I'll start calling on people. [43:55.260 --> 43:58.100] Secondly is, I would definitely be interested to see [43:58.100 --> 44:01.980] if anybody's seen any rootkits that use DMA, [44:01.980 --> 44:02.900] direct memory access. [44:02.900 --> 44:04.320] I've seen a lot of talk about it. [44:04.320 --> 44:08.300] Maybe I just have not seen the public talk about it [44:08.300 --> 44:10.480] or public implementation. [44:12.020 --> 44:15.640] And finally, if anybody has not followed [44:15.640 --> 44:19.120] the conventional wisdom of wiping their system clean [44:19.520 --> 44:22.260] and reinstalling, I'd be interested to hear that. [44:22.260 --> 44:25.260] So this time I'll open it up for questions and comments. [44:28.320 --> 44:29.540] Over there. [44:36.430 --> 44:38.610] Okay, so the question was with the L4 architecture, [44:38.610 --> 44:41.170] can you run multiple instances of your kernel? [44:41.170 --> 44:42.770] And the answer is yes. [44:42.770 --> 44:44.490] The L4 architecture is in fact [44:45.530 --> 44:47.610] pretty much virtual machine architecture. [44:47.610 --> 44:50.210] So you can run multiple instances of Linux. [44:54.510 --> 44:56.130] System pipes and log files? [44:56.130 --> 44:57.910] I have not addressed that yet. [44:58.650 --> 45:00.070] Good question. [45:07.100 --> 45:09.080] Certainly, but I mean, [45:12.320 --> 45:15.300] so it's suspicious, but that's, [45:15.300 --> 45:18.180] it's kind of like running a virtual machine, you know. [45:18.180 --> 45:20.240] You can tell when you're running on VMware. [45:20.240 --> 45:22.540] But, you know, legitimate systems run on there. [45:22.540 --> 45:24.840] So that definitely would be able to tell [45:24.840 --> 45:26.420] something that's not a normal system. [45:26.420 --> 45:27.240] Absolutely. [45:43.210 --> 45:43.850] Right. [45:43.850 --> 45:45.730] Actually, a lot of the tools that I've written [45:46.130 --> 45:47.770] for the system call stuff, [45:48.110 --> 45:49.970] it gives you all kinds of information [45:49.970 --> 45:51.490] on the system call table. [45:51.490 --> 45:53.570] So for instance, you can check and, [45:53.570 --> 45:55.390] you can check out all the, [45:55.390 --> 45:57.250] each individual system call with these tools. [45:57.250 --> 45:59.330] And that is much more surgical. [45:59.730 --> 46:00.770] Definitely. [46:01.350 --> 46:02.850] Good, good comment. [46:03.570 --> 46:04.730] Question here. [46:27.920 --> 46:28.940] Hmm. [46:28.940 --> 46:30.720] So the question was, [46:30.720 --> 46:34.220] one, this system would be useful just for detection, [46:34.220 --> 46:35.040] correct? [46:35.220 --> 46:36.600] And absolutely. [46:36.880 --> 46:39.920] Why am I doing intrusion recovery system as well? [46:39.920 --> 46:41.280] Because I'm a research student [46:41.280 --> 46:43.820] and we gotta do new and exciting things. [46:45.420 --> 46:46.540] So absolutely. [46:46.540 --> 46:47.620] And lots of people have talked about [46:47.620 --> 46:50.020] using similar architectures for intrusion detection. [46:50.020 --> 46:51.120] That's an excellent idea. [46:51.120 --> 46:53.620] That'll be the way it works 10 years from now. [46:53.920 --> 46:55.420] Got guys in the back? [46:55.520 --> 46:56.540] People over here? [47:01.920 --> 47:03.420] Oh yeah, absolutely. [47:03.660 --> 47:05.440] Matter of fact, I was gonna do a demo on that [47:05.440 --> 47:08.800] for this presentation, but didn't have enough time. [47:09.160 --> 47:10.900] Recovery from user level rootkits, [47:10.900 --> 47:12.200] I've done some work on that. [47:12.300 --> 47:15.620] It's pretty much tying a tripwire or aid kind of thing [47:15.620 --> 47:18.620] to a recovery program, [47:18.620 --> 47:21.000] which just checks your file system periodically [47:21.000 --> 47:23.040] and replaces the binaries back to normal. [47:23.040 --> 47:24.680] That's absolutely a part of the system. [47:24.800 --> 47:26.600] Cause you need the full system. [47:26.860 --> 47:28.320] We got a question way back there in the back [47:28.320 --> 47:29.560] and then I'll come back up here. [47:35.700 --> 47:37.240] That's an excellent question. [47:37.240 --> 47:40.860] So Xen is another very similar architecture. [47:40.860 --> 47:42.920] In fact, I got a link to that in the slides. [47:43.040 --> 47:44.840] Xen is very hot right now. [47:44.840 --> 47:49.340] It's a virtual machine architecture, open source. [47:49.380 --> 47:51.800] I believe it's England people are doing that. [47:51.820 --> 47:53.460] And it's very fast. [47:53.460 --> 47:56.320] Matter of fact, so Xen and L4 compete. [47:56.580 --> 47:59.280] I am going to compare Xen to L4 in my thesis [47:59.280 --> 48:01.760] to see which one would be better. [48:02.560 --> 48:04.140] That's just an implementation difference. [48:04.140 --> 48:05.760] Either one is certainly suitable. [48:05.760 --> 48:07.420] I just chose L4. [48:07.760 --> 48:08.620] We had a question up here [48:08.620 --> 48:11.500] and then I'll quit after this guy. [48:19.820 --> 48:21.280] Okay, so the question is, [48:21.280 --> 48:23.280] what's more background on this microkernel? [48:23.500 --> 48:26.840] And the reason I chose L4 fiasco implementation [48:26.840 --> 48:33.120] is basically it's one of the more mature L4 implementations [48:33.120 --> 48:35.240] developed by a university at Dresden. [48:35.520 --> 48:39.080] And the team there has been really good at helping me out. [48:39.080 --> 48:41.060] You know, any kind of questions I've got, [48:41.060 --> 48:43.540] big team there, lots of questions, [48:43.540 --> 48:45.240] you know, they've got the mailing list and everything. [48:46.680 --> 48:47.960] Comparing it to other, [48:47.960 --> 48:50.700] there's also two or three other implementations [48:50.700 --> 48:51.560] I could have used. [48:51.680 --> 48:53.880] I happen to know the guys a little bit at Dresden, [48:53.880 --> 48:55.860] so that's really the only reason. [48:55.940 --> 48:56.720] It's a good question. [48:56.860 --> 48:58.260] And okay, so I'm going to wrap up [48:58.260 --> 48:59.880] and let the next speaker get in. [48:59.880 --> 49:01.260] I'll be out here in the hall [49:01.260 --> 49:02.560] if you guys got any more questions. [49:02.980 --> 49:03.240] Thank you.