start	end	text
1080	3400	Okay, I guess we'll go ahead and get started.
4400	6860	I am Julian Grizzard and I'm a graduate student
6860	10500	at Georgia Tech and studying computer security.
10780	12960	And today I'm gonna give you a talk on
12960	17100	Surgical Recovery from Current-Level Rootkit Installations.
17740	20360	And this is on Linux-based systems.
22890	25710	So first off, the latest slides, tools,
25710	29010	and our spine architecture work is available online.
29110	31110	The links to this is on your CD.
31110	33930	And so definitely download the latest,
33930	35090	spent a lot of changes.
36850	40630	All right, so first off, some background on Rootkits.
40630	42270	What does a Rootkit do?
42710	45290	So a Rootkit is a toolkit that an attacker will use
45830	47930	to retain access to your system
47930	52290	and hide activity that he's doing on your system.
52790	54590	A Rootkit doesn't give you access to a system
54590	57070	if you don't have prior access.
57070	59570	You have to exploit the system by some known vulnerability
59570	61230	or something you figured out,
61230	62990	or social engineering or whatever.
63630	67350	And then the attacker will usually install a Rootkit
67850	70670	in order to come back into the system at a later point
70670	74350	in case the password changes or his vulnerability's patched.
78630	82530	So how many people have personally had experience
82530	85230	with a Rootkit installed on a system they administered?
85790	88430	We got some people, oh wow, we got lots of people out there.
88430	92450	Interesting, and so what is the recommended thing to do
92450	95090	when you get a Rootkit installed on your system?
97070	99490	That's right, format and reinstall.
99790	103630	So I'm actually going against that grain,
103630	104050	you know what I'm saying?
104050	106530	Okay, maybe there's more efficient ways
106530	108130	to recover from a Rootkit.
108130	109710	I mean, what if you got a server
109710	113650	that every minute of downtime costs millions of dollars?
113690	116310	I mean, how can you format and reinstall that system?
118210	120470	So we're going to look at different ways
120470	122110	to recover from a Rootkit.
122910	126230	So first off, I want to give you guys some background
126230	129210	on operating systems because what a Rootkit does
129210	131850	is it replaces parts of your operating system.
131850	135090	So it's important to understand how an operating system works
135090	138490	in order to understand the design of Rootkits.
139030	142210	So this is a monolithic operating system.
142490	145850	That's just a fancy term for this particular architecture.
145850	148050	Linux looks like this.
148070	149830	Windows, all the windows look like this.
149830	151430	Most systems look like this.
152270	154830	So you've got two parts to an operating system.
154830	158610	You've got the kernel space and this is the code
158610	160410	that runs right on top of your hardware,
160410	164210	controls all your devices, schedules your processes,
164690	167950	does your file access, network stack, these kinds of things.
170580	172800	And you have user space.
172800	174340	User space is where the programs
174340	175740	that you really care about run.
175740	177840	So P1 could be your word processor,
177840	182880	P2 could be a LS, bash command, and so on and so forth.
184420	188080	Now I want to give you a contrasted operating system design
188080	189680	that I'll come back to later.
189840	190980	But I just want to give you a preview
190980	194200	and compare and contrast to current OSs.
194200	197540	This is the microkernel operating system design.
198260	200820	The difference here is you have a very thin layer
200820	202280	for the kernel space.
202700	206280	You have minimal, I mean, only code you have in the kernel
206280	208780	is the minimum amount of code needed
208780	211800	to guarantee isolation among processes
211800	213420	and that kind of thing.
213420	217620	All the drivers, video, disk, hardware, network,
217620	219960	all this stuff is pushed into user space
219960	223120	sitting alongside your user space processes.
223220	226200	And each bubble here is guaranteed isolated
226200	227980	by the microkernel.
230430	233450	So what guarantees this isolation?
233850	236210	Well, on the Intel x86 architecture,
236350	238450	a lot of you have probably heard of this ring architecture
238850	241650	where you have level 0, 1, 2, 3.
241930	244350	And it turns out modern operating systems
244870	246190	only use two levels.
246190	248930	They use level 0 for the kernel,
248930	251370	which gives you unlimited access to the hardware.
251490	254890	If you have a program running at level 0,
254890	258970	you can do anything to any bit anywhere in the computer.
259630	262770	And the user space processes run at level 3,
262770	264170	which is shown in yellow here.
264730	266770	And if you want access,
266770	268890	they don't have direct access to the hardware.
268890	270450	If you want access to the hardware,
270450	271650	you have to make a system call,
271650	273430	ask the kernel to do it for you.
276090	278550	So I want to show you just real quick
280910	282970	how this is implemented in the hardware.
282990	284970	There's a 16-bit code segment register
284970	289970	on Intel Pentiums and x86 processors.
290570	292950	And the lower two bits of that register
292950	296390	specify what privilege level you're running at,
296390	297970	which is which ring you're in.
298710	301410	And this is some test code to test
301410	302890	and see which ring you're in.
305110	308950	So I'm going to demo this code running real quick.
308950	311490	Just a quick demo here.
313840	317640	So I have a Linux box running over here to my right.
318320	319940	I'm going to log into that.
330190	333990	All right, so I have this getcpl program
333990	336290	that gets your current privilege level.
336450	337710	And it returns three,
337710	339590	because I'm running a user space process
339590	341870	forking off the command line.
343350	345090	Now let's check out the kernel.
353880	357820	All right, so I inserted a kernel module called...
360360	362440	Well, it's way too big on there.
363780	366220	I inserted a kernel module called getcpl,
366220	368420	which all it does is...
370200	373740	Right here, all it does is pops the CS register
373740	376080	from into a variable,
376080	379460	and ends it with a three to get the ring level.
379960	383820	And if you look at the bar log sys log,
384620	386360	you can see that, in fact,
386360	388060	the kernel is running at ring zero.
397490	399850	All right, I'm going to get my next demo set up,
399850	401430	and we'll go back to the presentation.
410220	411900	And so these slides here are just showing that.
411900	419840	All right, so if you're looking at the operating system,
419840	422000	and you want to make a user level rootkit,
422000	422800	how do you do it?
422800	425140	Well, you attack files on the hard disk,
425140	426500	shown in red here.
426960	431080	And so you replace ps, netstat, ls, top, password.
431120	433400	These kinds of files, you replace those
433400	436280	with malicious files that hide your activities.
436280	438320	Hide files, hide network connections,
438320	439480	these kinds of things.
439840	441500	And so when you replace those files,
441500	444520	they get loaded into your processes,
444520	446060	the green bubbles up there.
447020	449300	So that is pretty much the user level rootkit.
449320	450680	It's pretty easy to detect.
450680	453280	You just run tripwire, check your system
453280	454840	against your known good state,
454840	456660	and it's not too difficult.
456660	457900	We know how to do that.
458480	460280	Definitely tripwire has its issues,
460280	463900	but there's a way to deal with those.
464480	466000	Now kernel level rootkit attacks,
466000	468720	they modify the running kernel code
468720	470500	and the running data structures,
470500	472800	which is this block shown here in red.
473280	475480	So anything in there is suspect
475480	478180	to being attacked by a kernel level rootkit.
478520	481100	And all a kernel is, is a running program
481100	482820	on your computer.
482860	484620	So in essence, these kernel level rootkits
484620	488000	are modifying code on the fly
488000	491320	and redirecting that code to malicious code.
491820	494480	In particular, the system calls
495060	498920	is the gateway from user space to kernel,
498920	500200	and that's a good target.
500200	502500	And I'll go over those two examples.
503600	506040	So first I want to go over a system call
506040	511720	and why that is the most popular attack target
511720	513240	for kernel level rootkits.
513380	516040	So it's important to understand how a system call works
516460	519940	in order to A, detect that the system call
519940	523020	has been tampered with, and B, recover from it.
523600	527120	So what happens, what do you use a system call for?
527120	528440	Okay, say you're a user process
528440	531300	and you want to read files from a hard disk.
531440	533320	Then you can't do that directly
533320	535260	because you don't have access to the hardware.
535260	538340	So you issue a system call to the kernel
538920	541440	to open, read the contents of those files,
541440	542660	and so on and so forth.
543240	546120	So for instance, let's say we have a sys read system call.
546120	547080	What happens?
547260	548400	Well, the first thing that happens
548400	554660	is your user space process issues an int 0x80 instruction,
554660	556980	which says a software interrupt,
556980	560420	which indexes into 0x80th entry
560420	562800	of the interrupt descriptor table.
563380	564860	And that's shown right here.
565100	567540	So as soon as you issue that interrupt,
567540	569020	you go over to the kernel,
569020	571860	the kernel looks up where the IDT is in memory,
571860	573840	looks up that 0x80th entry,
573840	577320	and executes the code pointed to by that entry.
577760	579360	The code pointed to by that entry
579360	581660	is the system call handler.
582680	585100	And the system call handler is responsible
585100	588620	for setting up parameters of your system call,
588620	590600	generic parameters, it works,
590600	593380	that's the first thing that's called for any system call.
593680	595420	And then it calls the system call
595420	597520	you specifically requested.
597960	600500	So you see this pointer coming out of the code
600500	602340	in the system call handler,
602340	604660	which points to the system call table.
605020	608920	So it references, let's say for sys read,
608920	611040	you look up this entry number three
611040	613720	in the system call table over here.
614380	615940	And that redirects you down here
615940	617900	to the sys read system call.
618480	620980	And the sys read then takes the parameters
620980	622620	given to it by a system call handler
622620	624960	and executes your request.
628890	631070	So what's the attack points here?
631110	634310	Anything in this chain is an attack point.
634690	637110	You could redirect the IDT entry,
637110	639070	you could redirect the system call handler
639070	641030	reference to the system call table,
641030	643910	you could redirect individual system calls,
643910	645630	you could overwrite the system call
645630	648850	with a jump instruction to go somewhere else.
648850	650890	All these are susceptible.
659310	663290	So, how do you recover from this system call attack?
663470	664690	Well here's the algorithm,
664690	668950	it's basically installing a new system call table
668950	671290	into the running kernel.
671290	673910	This is exactly what a rootkit will do, in fact.
673910	675790	But we're gonna use a good system call table
675790	678450	that has known good state.
679070	682290	So the best place to get that is to keep a copy
682290	685410	of your kernel on another disk on safe storage
685810	687530	and you can rip out these system calls
687530	691650	using what I did was modify GDB to get that code out.
692250	694890	And so you, it's pretty simple, you just,
694890	697770	well, it's somewhat simple, it is kernel stuff,
697770	702850	but basically you copy each system call into kernel memory
702850	705630	and then you create a new system call table
705630	707130	pointing to all those system calls
707550	709270	and then you can set the handler
709270	711570	to point to that system call table.
712330	714270	And there's, you can go full blown,
714270	716950	you can, if we go back to this picture,
716950	721210	you can set this pointer right here
721210	723630	which is on the left for you guys
725190	727690	and you can point that to a new system call handler
727690	729390	if you want and that way you'll know
729390	731310	the whole chain is correct.
735360	737440	Okay, so it's a little bit,
737440	739180	just want to give you guys some details on,
739180	741980	it's not quite that simple, you can't just copy stuff over.
742080	744340	When you copy code around in memory,
744340	746760	x86 code has these call instructions
746760	748820	with relative offset parameters,
748820	750520	so you have to adjust them,
750520	752640	basically relink them into the kernel.
753180	754880	So you could recompile the code
755400	756720	if you know where it's gonna be loaded,
756720	760800	but I chose just to recompute those relative offsets
760800	764820	as I was inserting each system call into memory.
765300	767880	And you adjust the relative offset
767880	770500	based on where it's placed in memory
770500	772860	because you allocate dynamic memory for it
772860	775860	and you compare that to where it was originally in memory
775860	777940	and you just subtract the difference.
778880	780680	Of course, it's a little bit more confusing
780680	783320	with the way the Intel architecture works,
783320	785140	but that's the gist of it.
786800	791080	So another thing is there's multiple ways into the kernel.
791440	792620	I'll just give you some background.
792620	795220	This is another tidbit of kernel-level rootkit stuff
795220	798960	is you can insert a kernel module into the kernel
798960	801060	and muck with the system call table.
801300	803760	And that's one way to penetrate the kernel.
804480	806340	Another way you can get into the kernel
806340	809260	is through the dev.kmem.device file.
809580	814680	This device file gives you access to the kernel memory
815440	816900	as a file.
817400	818880	So if you're a user space process,
818880	821540	you can open that dev.kmem like it's a regular file.
821660	825000	You can seek to it and you pass it a kernel memory address
825000	826500	and it seeks that memory
826500	829440	and then you can read that data or write to it.
831140	834540	Is anybody familiar with the SuckIt rootkit
834540	836960	from those people that have had installations
836960	838220	on their computers?
839040	841120	We got some people, all right.
842460	843760	So there's a few more.
843760	846780	Okay, so if you want to install your rootkit
846780	849480	from dev.kmem without doing a kernel module,
849480	851260	there's a couple of things that are tricky.
852300	854500	First, how do you find the system call table?
854640	855960	You don't have the symbols.
856400	859520	And two, how do you allocate memory
859520	862160	to insert new code into the kernel?
866470	868270	All right, so first I'll just go over
868270	870830	how you find the system call handler right quick.
871490	875090	This is some code pulled out of SuckIt.
875090	881190	First thing you do is you pop the IDT register into memory.
881890	885530	And what that is, is that tells you the address.
885530	887610	Let's go back a few slides real quick.
887610	890670	That tells you where this table is in memory.
894210	896730	All right, so now you know where that table is.
896790	901070	So then you read the 0x80th entry of that table
902670	906730	and you can compute where the system call handler is
906730	908870	in memory.
908870	910390	And then you can parse the system call handler
910390	912870	to find out where the system call table is.
915980	920460	All right, so how do you get dynamically allocated memory
920460	924460	from the kernel from user space?
924460	927880	If you write a kernel module, you just use kmalloc,
927880	931040	but you don't have access to that code from user space.
931460	935460	Well, the way SuckIt does it is sets up kmalloc
936000	937820	as a system call.
938480	940460	So there's a number of unused system calls
940460	942120	in the system call tabler.
942980	944660	SuckIt takes over one of those system calls
944660	947420	and points it to kmalloc.
947420	951320	So now you can issue system call 180 or something like that
951320	954660	and pass it a size, memory allocation size
954660	957400	and you'll get kernel memory returns.
961140	964020	Okay, so now I wanna do my next demo.
984770	988070	Okay, so the scenario here is
988710	991430	I've already got root access to this machine,
991430	994690	so I'm wanting to install my rootkit to retain access
994690	996390	and to hide some files.
996650	998310	In this folder right here,
1000090	1003270	I have some bank accounts I wanna store on this computer
1004990	1007170	and don't worry, these are not legit.
1009990	1011270	At least I hope not.
1013230	1015270	Okay, so we've got this data
1015270	1016790	that I don't wanna store on my own computer,
1016790	1018690	but I wanna store it on this machine
1018690	1021230	that I've compromised so I can trade it with somebody else,
1021230	1022710	something like that.
1026140	1028300	So then I've already downloaded
1028300	1030480	my SuckIt rootkit onto the system
1032180	1037360	and I'm going to install it and it's done.
1037800	1042240	So now that directory that I was just showing you up here,
1042240	1046320	this hidden info.sk12 is now hidden.
1046700	1051220	The way this works is anything that ends in .sk12
1051220	1052440	will be hidden.
1052440	1057520	For instance, if I touch a file called hide.me,
1058880	1060580	you can see that it's there.
1060640	1066720	If I move hide.me to hide.me.sk12, it's gone.
1071840	1074960	So now I'm the administrator of this computer
1075520	1078720	and I believe I may have a rootkit on my system.
1079360	1082100	So what I'm going to do is try
1082100	1084040	and install a new system call table
1084040	1087280	to see if there's any differences in the file system.
1090120	1092280	Okay, so this takes a little bit of time
1092280	1093860	because it's not optimized.
1094100	1095100	It's good for demo though
1095100	1097160	because I can explain a few things.
1097520	1100380	So what you see here is each little block of code,
1100380	1104100	it's copying a system call into kernel memory.
1105500	1108360	It issues a kmalloc for each one of these,
1108360	1109800	copies it in, and then you see these
1110500	1113780	asterisks, asterisks, asterisks, found, dot, dot, dot.
1113780	1115860	It's finding these call instructions
1115860	1120320	and it's recomputing where they need to be relinked to
1120320	1121880	and setting that.
1123960	1127020	So right now we're at about 130 system calls
1127020	1128740	that have been copied into memory.
1128740	1133440	Turns out Linux has 255-ish system calls.
1134400	1137640	And so we'll be through this here in a second.
1152400	1154500	Does anybody have any questions so far?
1154500	1155900	We've got a few more minutes.
1169980	1171420	From what I've found, I mean,
1171420	1174100	that's a possibility that they have absolute calls,
1174100	1176680	but you could relink those in as well.
1176780	1180060	From what I've found, they don't have absolute calls.
1190470	1191870	Excellent, excellent question.
1191870	1193730	I will get to that very shortly.
1196050	1202050	All right, so the new system call table has been installed.
1202050	1204890	Now notice these hidden files come back up.
1205810	1207390	So as you can see, all Sucket was doing
1207390	1209050	was redirecting some system calls.
1209050	1211630	So we install a known good system call table into memory.
1211710	1213990	All of a sudden, these files come back up.
1224140	1225820	Does anybody have any other questions
1225820	1228320	while we got a stopping point in the presentation?
1243830	1245330	How does it catch it?
1248680	1250480	Right, let's go back to that figure.
1253860	1259200	All right, so you're saying this code right here
1259200	1261840	is being overwritten or something like that.
1262440	1265520	Okay, so first off, the tools I was just showing you
1265520	1267820	do not do rootkit detection.
1267820	1269060	Well, some of them do,
1269060	1271780	but the recover rootkit itself does not.
1272240	1274940	I do have the ability to read any system calls,
1274940	1280440	or I could dump this code for sysread to a file
1280440	1282740	and see if it's been overwritten.
1282740	1284620	For instance, to answer your question,
1284620	1285400	that would be the way to do it.
1285480	1286860	It's changing memory.
1289740	1294280	So the way the recovery tools work is,
1294280	1297700	right now it actually just replaces this pointer
1297700	1299340	to a new system call table.
1300100	1303200	And so that's gonna shoot over here into memory somewhere.
1303520	1305060	You got a new system call table over here,
1305060	1306800	you got a new sysread over here.
1306940	1309780	So even if this sysread right here was overwritten,
1309780	1312420	that's not a problem because we aren't depending on that.
1312780	1313800	Good question.
1319250	1323830	Okay, so back to our gentleman's over here's question.
1324330	1328730	Okay, so it turns out if you use devkmem
1329550	1334870	to modify the kernel, as I do with my recovery tools,
1335210	1339370	or even if you use a kernel module to do the recovery,
1339370	1343950	either one of these approaches relies on system calls
1343950	1345370	to do the recovery.
1345490	1347410	So there's an obvious problem here.
1347410	1351550	If you've installed a rootkit that's redirected system calls
1352410	1354430	and you're depending on those system calls
1354430	1359450	that's redirected, then you may be depending on code
1360010	1364030	that's going to prevent your recovery tools from working.
1365110	1366730	Does that make sense to everybody?
1366730	1368030	It's a little bit confusing.
1368430	1375910	Okay, so how do we deal with this?
1376710	1383110	Well, I propose we need a new system architecture.
1383310	1387870	And let me take a minute to explain the vision I have here,
1387870	1389770	which goes much beyond rootkits
1389770	1393290	and much beyond anything like that.
1393290	1398010	I've got this vision of intrusion recovery system.
1398670	1400270	So this is like, you know,
1400270	1402130	you've got your intrusion detection system,
1402130	1404310	you've got your intrusion prevention system,
1404870	1408790	but bottom line is we still have compromises every day.
1408790	1410950	It's still a problem for the foreseeable future.
1411190	1414730	So we need to think about ways
1414730	1417370	to more quickly recover from compromises
1417370	1419090	given that they're going to be a problem.
1419090	1420790	Systems are so complex.
1421510	1424130	So that's why I've come up with this notion
1424130	1426270	of an intrusion recovery system,
1426270	1429050	which has a new system architecture
1429510	1432690	that's not currently used in widely available OSs.
1432690	1435690	And it's capable of verifying
1435690	1437390	the integrity of the running system
1437970	1442030	and repairing that state if it has some problems.
1442690	1444170	And it has, you know,
1444170	1447790	obviously there's got to be some kind of,
1447790	1451370	this has got to be the top most secure piece of your system
1451370	1455230	because you rely on it for, you know,
1455230	1456570	your system running good.
1456750	1459350	So you have to have some kind of way
1459350	1461930	to store known good state for your system.
1462430	1464510	Because if you store the known good state in your system
1465010	1468250	that is accessible by root, then that can be changed.
1468310	1472370	So this new architecture supports these kinds of things.
1472450	1474550	It supports what I call a state hold,
1474550	1475990	which is kind of like a strong hold,
1475990	1477770	but it stores your state instead.
1478710	1480490	And it does these other things.
1480490	1483890	And I'll go over, this is my research right now.
1483890	1485350	So it's certainly in development.
1485470	1487970	And I'm looking for any kind of feedback you guys have.
1487970	1489710	It's probably got some problems,
1489710	1491110	but I'll show you what I've got.
1491110	1493710	And we'll see what you say.
1494630	1497990	So back to the beginning, I showed you,
1497990	1500050	you've got the monolithic operating systems
1500050	1503370	and then you've got these microkernel operating systems.
1504230	1505030	Well, I'm gonna go back
1505030	1507070	to this microkernel operating system.
1507490	1510990	Turns out this looks really good for security applications.
1511630	1513630	If you look at the microkernel,
1513630	1519050	it has about 20,000 lines of code that run the kernel.
1519670	1521610	Compare that to the Linux kernel,
1521610	1523530	which has on the order of 4 million.
1523950	1527310	So we can hopefully better guess
1527310	1530370	or better rely on the microkernel for correctness.
1530470	1533770	Matter of fact, there's some research microkernels out there
1533770	1538050	that try and formally prove that the microkernel is correct.
1540980	1543360	The system calls to the microkernel,
1543360	1547240	there's only 14 or so, just depends on the implementation.
1547440	1549460	Maybe on the order of 10.
1549460	1551720	So you've got a small number of system calls
1551720	1552980	that do basic stuff.
1552980	1557960	You do IPCs, you do inter-process communication,
1557960	1559540	you do thread management, that kind of thing.
1559540	1560800	That's it, actually.
1560880	1562680	All the hardware access,
1562680	1564760	these kinds of things are pushed to user level.
1569140	1572520	So based on this microkernel design,
1573460	1576060	I've laid out this spine architecture
1576060	1578580	for the intrusion recovery system.
1580340	1584100	At the base of the architecture you have the microkernel,
1584100	1587500	which I'm using L4 Fiasco implementation,
1587500	1591360	which is developed by a university in Dresden, Germany.
1593060	1597100	And on top of that runs the guest kernel,
1597100	1600040	the L4 Linux implementation runs on top of that.
1600040	1601940	So you can run a full-blown version of Linux
1601940	1603920	on top of the microkernel.
1604660	1606820	So you're probably more familiar
1606820	1609980	with the term virtual machine than you are microkernel.
1609980	1613480	Turns out these are very highly related topics.
1613900	1616440	Essentially the microkernel does the same thing for us.
1616660	1618820	And so we have this guest kernel,
1618820	1621900	which is L4 Linux running on top of it.
1622580	1626500	At the next level you've got your user processes,
1626500	1628760	and those run just like they do on Linux.
1628760	1630180	You don't even have to modify them.
1631480	1634900	And then over here on the first,
1634900	1637440	only Fiasco runs in kernel mode.
1637440	1641480	So only Fiasco runs in that ring zero,
1641480	1644020	and everything else runs in ring three.
1644460	1647600	That means even if you have root access
1647600	1650240	on the kernel machine,
1650240	1653080	you're not guaranteed access to all bits
1653080	1655060	in the computer system.
1659310	1662870	So on the right here I have at each level
1663750	1666470	a component of the intrusion recovery system.
1666470	1669470	I call them L0, L1, L2, L3.
1669930	1671550	And L0 is just the hardware.
1671550	1673290	There's really no support for that right now,
1673290	1675850	just except the ring stuff.
1676390	1680050	Turns out Intel and IBM, these kinds of companies,
1680050	1682670	are very interested in hardware support
1682670	1684010	for virtual machines.
1684010	1686710	So in the future this will definitely be huge.
1688050	1691530	L1 is a component I have running at the microkernel.
1691890	1693950	The importance of this component
1694310	1697790	is it's able to verify that the guest kernel
1697790	1700810	and the L2 component are operating correctly.
1701550	1704190	And similarly for L2 to L3.
1704270	1710190	And why do I have these various levels in the system?
1710190	1711710	Well it turns out if you're looking at
1711710	1718790	the entire Linux operating system from L1,
1718790	1720730	you're gonna have a hard time interpreting
1720730	1722010	all the data structures,
1722010	1723930	interpreting what's good, what's bad.
1723930	1728750	So it's much easier to run components in each level
1729970	1733670	in order to understand the semantics of that level.
1734770	1739010	And the vertical hierarchy is a way of guaranteeing
1739010	1742410	that those components are not trojaned or stopped
1742410	1744410	or bypassed, these kinds of things.
1747250	1749150	So there's a lot more details here.
1749150	1750470	I just wanna give you a few.
1750470	1752310	I'll just show you the memory real quick.
1752310	1754530	How does the memory work for instance?
1754890	1756470	So down here at the bottom,
1756470	1762190	you have the microkernel L1 which owns all the memory.
1764510	1768190	And it can allocate some of the physical,
1768190	1770050	by memory I mean the RAM.
1770050	1772850	It can allocate some of the RAM to the guest kernel
1772850	1774710	which is shown in red here.
1775030	1777210	And you can see that portions of the memory
1777210	1778790	are still owned by the microkernel
1778790	1782090	and the Linux guest kernel cannot touch that memory.
1782750	1785930	And then in turn, the guest kernel,
1785930	1788670	the Linux kernel can map some of its memory
1788670	1790710	to user space processes.
1793050	1796050	All right, so this is the system.
1796050	1797290	How do we attack it?
1797290	1800090	So you can attack any of these things in user space.
1800090	1801950	If you have root access, you have access
1801950	1805370	to all these components highlighted in red here.
1806070	1808810	So again, the L2 and L3 components
1809180	1813950	of the intrusion recovery system are suspect to attack.
1814070	1815890	And that's why we need L1 to verify
1815890	1817630	that they're operating correctly.
1818950	1822830	So right now, I'm still working on algorithms
1823380	1826350	to determine when L2 and L3 are operating correctly.
1826350	1830510	So far, I only have monitoring the PC instruction counter
1830510	1835430	and verifying the hash of the code at L2
1835430	1838330	to verify and check that the program counter
1838330	1840230	runs in that code periodically.
1841130	1844310	If anybody's got some ideas on other ways to verify,
1844310	1845970	I'd definitely like to talk to you.
1847630	1850330	Okay, so now I wanna look at another
1850330	1852650	kernel-level rootkit target.
1853490	1856510	So it turns out these same kernel-level rootkits
1856510	1861110	will work on this new spine architecture.
1861310	1862670	They will attack the guest kernel
1862670	1864790	instead of the host kernel.
1865410	1867730	So I wanna go through another target
1868250	1869690	to give you guys some more background
1869690	1871890	on how kernel-level rootkits work.
1872510	1875870	This target is the virtual file system.
1876350	1878050	Now, the virtual file system in Linux
1878690	1883650	is a wrapper that gives you access
1883650	1886090	to all file systems in Linux.
1886090	1888790	And so you can insert your own virtual file systems.
1888790	1892150	If you have an ext3 formatted partition,
1892150	1894470	then you insert that in the VFS
1894470	1898310	and you don't have to readjust your system calls
1898310	1899270	to point to that.
1899270	1901570	Everything goes through the virtual file system.
1902130	1903670	Let me show you how it works.
1905070	1909210	So first off, a system call is issued.
1909210	1913450	Let's say I'll go over the proc file system in this example.
1913770	1915610	Let me back up a minute.
1916110	1919070	So you have lots of different file systems in Linux.
1919070	1922550	You have your file system for your hard disk.
1922550	1927990	You have remote disk storage stored on another network drive.
1927990	1930110	You have the proc file system,
1930110	1932830	which is a file system built by the kernel
1932830	1934950	and gives you information from the kernel,
1934950	1940590	such as task IDs, and so on and so forth.
1941510	1943850	So if you want to, remember,
1943850	1945590	if you wanna get access to the file system,
1945590	1948230	any file system, you have to issue a system call.
1949210	1950730	So in this example,
1950730	1953930	I want to read the contents of the proc directory
1953930	1957110	to see what processes are running on my system.
1957790	1961670	So first, my program will issue a sys read dir.
1962750	1967130	That sys read dir indexes into the virtual file system,
1967130	1970590	which then, and you've told it to open up this proc,
1970590	1971990	some directory in proc.
1972570	1974650	So the virtual file system knows,
1974650	1976530	based on the path you gave it,
1976530	1979430	where it needs to go to service your request.
1979590	1981810	For proc, that's a special file system.
1981810	1984730	It indexes into its root structure.
1985570	1989650	And there's a lot of pointers in that root structure.
1989810	1994170	The F underscore op stands for file operations, I believe.
1994710	1997790	And so for the proc, you look up
1997790	2002390	what are the file operations for that file system.
2002850	2005790	And so there's a F op structure, which is standard.
2005790	2008110	And for each file system,
2008110	2010630	you have to implement a number of function pointers.
2010630	2014430	In this case, read dir is the one I'm going to highlight.
2014930	2017950	So you've indexed all the way in here to read dir.
2018050	2022310	And finally, you get to the proc read dir code.
2023150	2025250	And so that'll then return information
2025250	2026450	back to your system call,
2026450	2029830	and then return that information back to your user program.
2033530	2036370	Okay, so what's the attack points here?
2036370	2039870	Again, it's the same basic idea.
2039950	2041690	Anytime you've got a function pointer,
2041690	2043210	anytime you've got a reference,
2043210	2046230	any code along the path can be redirected.
2051760	2055840	All right, so what's the recovery algorithm for this?
2055840	2057840	Well, now's when we sort of step back
2057840	2059620	and make it more general.
2059860	2061780	So generally, the recovery methods
2061780	2065140	for kernel-level rootkits is consistency checking
2065140	2068700	on the data structures in the kernel and the code running.
2068700	2071580	And you can store a copy of this,
2071580	2072700	what it should look like
2072700	2074720	in your protected spine architecture.
2075500	2078000	And you can use that to check and see
2078000	2082540	if it's been modified in a manner
2082540	2084280	that's against your policy.
2084600	2089320	And if so, then you repair it back to its known good state.
2090840	2093800	And the IRS can do this automatically.
2093800	2098460	And that's sort of the vision,
2098460	2101160	is you have this system that's constantly monitoring
2101160	2105800	your computer for malicious rootkit installations.
2105800	2109960	If that happens, it undoes the damage from it.
2109960	2113760	And furthermore, have longer-term goals of,
2113760	2116200	okay, so yeah, you've got a rootkit installed.
2116200	2117620	You undo this damage.
2117620	2119740	The attacker still got in your system somehow.
2120300	2122400	You also have to figure out how he got out,
2122400	2124320	kick him out, change passwords.
2124320	2126620	It's more than just repairing the system.
2126620	2127860	It's a lot more complicated.
2129420	2131560	All right, so let's go for another demo.
2152660	2155920	Now, for the purposes of this demo,
2155920	2159400	I'm not using the automated repair of the system
2160240	2162920	because you wouldn't be able to see that anything happened.
2165490	2167650	But one thing I wanna show you real quick
2167650	2173450	is I am, in fact, running the spine architecture now.
2176380	2177640	And you can see that I'm running
2177640	2184020	the Linux 2.6.11-L4 kernel,
2184020	2187400	which is, the way it works for the Linux kernel
2187400	2191240	is you port the Linux kernel to the L4 architecture
2191240	2195480	as opposed to the I386, the alpha, so on and so forth.
2197100	2198960	So, in fact, we can go in here
2198960	2201060	and check out our getcpl again
2201700	2204980	to see if our privilege levels have changed.
2205960	2209400	And so, the user processes still run at ring three,
2209400	2210520	which is expected.
2211680	2215220	And let's see what the kernel is now running at.
2220100	2222860	And so, can everybody see this in the back?
2222860	2224420	Or should I call it out for you guys?
2225640	2226740	Move it up?
2229600	2230920	Sorry about that.
2233320	2234520	Is that better?
2235980	2236860	Thanks.
2237400	2238980	Okay, so what I've just done,
2238980	2240620	let me scroll back up for you guys then.
2242000	2246700	Um, so right here I just did the getcpl
2247300	2250580	and it returned ring three, running in ring three.
2251620	2256400	And I've just inserted the getcpl into the running kernel.
2256660	2260660	And you can tell the var log, sys log,
2261340	2262760	and see that it was printed out
2262760	2264500	as running in ring three now.
2264500	2267100	So now the kernel is running in ring three.
2267100	2270000	If anybody out there is familiar with user mode Linux,
2270000	2271940	it's a very similar concept to that,
2271940	2273600	but it's much, much faster.
2275360	2278440	In terms of performance, I'll take a slight venture.
2278560	2281160	Just in case you guys are wondering,
2281160	2283460	you figure about a 10% performance penalty
2283460	2285760	for running in this architecture.
2286360	2290340	So it runs about 90% the speed of Linux
2290340	2291900	running directly on your hardware.
2298780	2302340	Okay, so for the second demo,
2302340	2308000	I'm going to install the Adore Next Generation rootkit.
2308000	2311760	And this rootkit works on the Linux 2.6 kernel.
2314620	2316920	And what this rootkit does is exactly
2316920	2320860	what I was just showing you with the virtual file system.
2320860	2322880	It redirects the virtual file system
2323260	2331020	to malicious structures so it can hide files and processes.
2337710	2342950	Okay, so I've just loaded the rootkit.
2344170	2348430	Notice first off that my Adore NG directory
2348430	2350990	that I was just in is now hidden.
2350990	2352450	That's part of the configuration.
2352450	2355550	It hides whatever your rootkit directory is.
2356090	2361410	And then I'm going to launch this rootme binary,
2361410	2363990	which doesn't really do anything, but it runs.
2364310	2366130	And you can see right here in the process list
2366130	2368330	that rootme is running.
2369430	2370870	Now I've got to scroll back up here
2370870	2372750	and see what my directory was.
2374150	2377910	So I'm going to go back into the Adore NG directory.
2377910	2381530	I'm tabbing over right now, and that's another system call.
2381530	2385410	It doesn't find that there's an Adore NG directory,
2385410	2387310	so I have to type the full path.
2388470	2390630	And there's a user-level utility
2390630	2392950	to go with this Adore NG rootkit,
2392950	2396010	which can hide processes for you.
2396590	2400210	So I want to hide this process 644.
2409250	2410970	So now rootme's gone.
2412490	2416010	All right, so now I'm going to put on
2416010	2418130	my system administrator hat again,
2418130	2422690	and I suspect that a rootkit's been installed.
2423330	2424550	This could be done automatically
2424550	2426790	with the intrusion recovery system,
2426790	2428850	but again, for the purposes of this demo,
2428850	2430270	I will do it manually.
2432830	2436830	And so what I'm going to do is a similar algorithm
2436830	2440250	to the system call table repair.
2440590	2444170	I am going to, but this time I made it a little bit simpler.
2444170	2445850	I just fixed the pointers back
2445850	2447070	to where they're supposed to be.
2452560	2456060	Okay, so I've just repaired the proc file system,
2456640	2460660	and now you can see the rootme file, our process is back.
2462680	2466360	And you can see the adore-ng directory is back.
2466820	2468480	So in fact, we've been able to recover
2468480	2470380	from these kernel-level rootkits.
2475210	2478610	Okay, let's go back to wrap up things here.
2491600	2494920	All right, so I've shown you the ability to recover
2494920	2497120	from some kernel-level rootkits,
2497120	2498600	and presented you with an architecture
2498600	2501400	that's perhaps more robust,
2501400	2504300	and you can somewhat rely on for this recovery.
2505160	2507380	So, I mean, definitely there's some limitations
2507380	2509980	to this system, I'm still developing it now,
2509980	2513100	so any feedback you guys have would be great.
2513680	2516580	Some of the limitations, you know, first off,
2516580	2518120	how can you trust this microkernel?
2518120	2521060	What if the attacker installs a rootkit
2521060	2522340	into the microkernel?
2522340	2524760	Well, you know, that's a hard question,
2524760	2528680	but it's relying on the smallness of the microkernel
2528680	2532360	to be correct to prevent that capability.
2533020	2535560	You know, one of the things that some of you guys
2535560	2537220	are probably thinking about already is,
2537220	2539500	what about direct memory access,
2539500	2541040	where you program a controller
2541040	2543920	to overwrite the microkernel?
2543920	2546440	Well, that's definitely a problem right now,
2547200	2548880	that's a limitation.
2549020	2552620	In future, Intel architectures that support
2553860	2558760	better isolation, that hopefully will not be a problem.
2559260	2561180	So, and finally, you know,
2561180	2563400	just like everything else with security,
2563400	2566120	there's no be-all, end-all solution.
2566320	2570120	However, I believe this IRS can make your systems
2570120	2574720	more reliable and save us a lot more time and trouble.
2575960	2578400	So thanks to a lot of people that have helped me out,
2578400	2580000	you know, there's lots more people on here
2580000	2581800	than I have listed.
2582380	2585000	These people in particular have been helpful.
2586140	2587500	I got some links for you guys,
2587500	2588800	if you wanna find out some more information
2588800	2590280	about what I've been talking about.
2590600	2593380	Various architectures, system projects here,
2593380	2595900	you know, check rootkit, our research.
2597200	2600100	And at this time, we got a few starter questions,
2600100	2601420	if anybody wants to comment on,
2601420	2603920	and if not, if you got your own questions, that's fine.
2603920	2606280	We got about five minutes or so.
2606480	2608160	And also after the talk,
2608160	2610500	I will be heading out that door over there.
2610500	2612180	So if you guys wanna catch me,
2612180	2614720	definitely link up with me outside.
2615560	2619360	So first off, let me just ask these three questions,
2619360	2621820	and I'll take either answer these comments
2621820	2623880	to these questions or your own questions.
2624240	2625840	So I've already asked this question,
2625840	2627020	how many people have personally dealt
2627020	2628280	with the recovery of rootkit?
2628280	2630220	If anybody has a testimony,
2630220	2631880	we might can share that in a minute.
2631960	2632980	Let me read all three of these
2632980	2634660	and then I'll start calling on people.
2635260	2638100	Secondly is, I would definitely be interested to see
2638100	2641980	if anybody's seen any rootkits that use DMA,
2641980	2642900	direct memory access.
2642900	2644320	I've seen a lot of talk about it.
2644320	2648300	Maybe I just have not seen the public talk about it
2648300	2650480	or public implementation.
2652020	2655640	And finally, if anybody has not followed
2655640	2659120	the conventional wisdom of wiping their system clean
2659520	2662260	and reinstalling, I'd be interested to hear that.
2662260	2665260	So this time I'll open it up for questions and comments.
2668320	2669540	Over there.
2676430	2678610	Okay, so the question was with the L4 architecture,
2678610	2681170	can you run multiple instances of your kernel?
2681170	2682770	And the answer is yes.
2682770	2684490	The L4 architecture is in fact
2685530	2687610	pretty much virtual machine architecture.
2687610	2690210	So you can run multiple instances of Linux.
2694510	2696130	System pipes and log files?
2696130	2697910	I have not addressed that yet.
2698650	2700070	Good question.
2707100	2709080	Certainly, but I mean,
2712320	2715300	so it's suspicious, but that's,
2715300	2718180	it's kind of like running a virtual machine, you know.
2718180	2720240	You can tell when you're running on VMware.
2720240	2722540	But, you know, legitimate systems run on there.
2722540	2724840	So that definitely would be able to tell
2724840	2726420	something that's not a normal system.
2726420	2727240	Absolutely.
2743210	2743850	Right.
2743850	2745730	Actually, a lot of the tools that I've written
2746130	2747770	for the system call stuff,
2748110	2749970	it gives you all kinds of information
2749970	2751490	on the system call table.
2751490	2753570	So for instance, you can check and,
2753570	2755390	you can check out all the,
2755390	2757250	each individual system call with these tools.
2757250	2759330	And that is much more surgical.
2759730	2760770	Definitely.
2761350	2762850	Good, good comment.
2763570	2764730	Question here.
2787920	2788940	Hmm.
2788940	2790720	So the question was,
2790720	2794220	one, this system would be useful just for detection,
2794220	2795040	correct?
2795220	2796600	And absolutely.
2796880	2799920	Why am I doing intrusion recovery system as well?
2799920	2801280	Because I'm a research student
2801280	2803820	and we gotta do new and exciting things.
2805420	2806540	So absolutely.
2806540	2807620	And lots of people have talked about
2807620	2810020	using similar architectures for intrusion detection.
2810020	2811120	That's an excellent idea.
2811120	2813620	That'll be the way it works 10 years from now.
2813920	2815420	Got guys in the back?
2815520	2816540	People over here?
2821920	2823420	Oh yeah, absolutely.
2823660	2825440	Matter of fact, I was gonna do a demo on that
2825440	2828800	for this presentation, but didn't have enough time.
2829160	2830900	Recovery from user level rootkits,
2830900	2832200	I've done some work on that.
2832300	2835620	It's pretty much tying a tripwire or aid kind of thing
2835620	2838620	to a recovery program,
2838620	2841000	which just checks your file system periodically
2841000	2843040	and replaces the binaries back to normal.
2843040	2844680	That's absolutely a part of the system.
2844800	2846600	Cause you need the full system.
2846860	2848320	We got a question way back there in the back
2848320	2849560	and then I'll come back up here.
2855700	2857240	That's an excellent question.
2857240	2860860	So Xen is another very similar architecture.
2860860	2862920	In fact, I got a link to that in the slides.
2863040	2864840	Xen is very hot right now.
2864840	2869340	It's a virtual machine architecture, open source.
2869380	2871800	I believe it's England people are doing that.
2871820	2873460	And it's very fast.
2873460	2876320	Matter of fact, so Xen and L4 compete.
2876580	2879280	I am going to compare Xen to L4 in my thesis
2879280	2881760	to see which one would be better.
2882560	2884140	That's just an implementation difference.
2884140	2885760	Either one is certainly suitable.
2885760	2887420	I just chose L4.
2887760	2888620	We had a question up here
2888620	2891500	and then I'll quit after this guy.
2899820	2901280	Okay, so the question is,
2901280	2903280	what's more background on this microkernel?
2903500	2906840	And the reason I chose L4 fiasco implementation
2906840	2913120	is basically it's one of the more mature L4 implementations
2913120	2915240	developed by a university at Dresden.
2915520	2919080	And the team there has been really good at helping me out.
2919080	2921060	You know, any kind of questions I've got,
2921060	2923540	big team there, lots of questions,
2923540	2925240	you know, they've got the mailing list and everything.
2926680	2927960	Comparing it to other,
2927960	2930700	there's also two or three other implementations
2930700	2931560	I could have used.
2931680	2933880	I happen to know the guys a little bit at Dresden,
2933880	2935860	so that's really the only reason.
2935940	2936720	It's a good question.
2936860	2938260	And okay, so I'm going to wrap up
2938260	2939880	and let the next speaker get in.
2939880	2941260	I'll be out here in the hall
2941260	2942560	if you guys got any more questions.
2942980	2943240	Thank you.