start	end	text
3420	12940	Hi everyone, thanks for attending. My name is Jonathan and the topic of my talk is going to be
12940	17940	about the dark side of Winsock, which is essentially all the under-the-hood functionality that you
17940	24300	have inside Winsock, inside the Windows TCPIP stack, which unfortunately, even though it's
24300	30960	there and it's publicly available, it is somewhat undocumented and the only people to really
30960	36900	use it are the bad guys, namely people who want to do rootkits, who want to do spyware, etc.
37440	44560	Now I find myself somewhat inclined to start with the preamble here. This is not some type of
44560	50520	vulnerability issue or not some type of any zero-day exploit, so if any of you are expecting
50520	55400	that, it's probably not the right place to be. What this is, however, is a discussion on
55400	62540	functionality which, like I said, is in there and it's mostly... well, mostly the only really
62540	67700	good uses, as you'll see, are the insidious ones, namely the ones that aren't really designed
67700	75100	to happen. Things such as usurping connections, rerouting connections, connection monitoring,
75100	82740	etc, etc. Now it is assumed that you guys have had some experience with Winsock before.
82740	90460	How many of you have actually coded in Windows for Winsock? Okay, well, okay, so as I was,
90460	94480	you know, I kind of suspected that, so we'll start with a brief intro that kind of has the
94480	98920	nomenclature and kind of has like the basic terminology, so those of you who are fairly new
98920	104420	to this will be able to sort of like keep afloat. And then we'll get into the code. Now the
104420	108680	code itself that I'll be demonstrating is all fully annotated, you've got that on the CD.
108680	115980	On the CD you have a PDF of my talk, which, contrary to other PDFs, it's not just the slides,
115980	120580	it's also the notes pages. So you'll be able to have the full source code, everything is there.
120860	126740	Furthermore, my demo, which I'm going to run shortly, is based on a public demo, which is
126740	131820	Intel's and Microsoft's code, so it's like fully open source and nothing too new there.
132120	137300	So, we start with the introduction, and some of you may already know this, and I'm actually
137300	142820	hoping most of you know this, but it's just sort of like the basic terms we'll be using.
143000	148460	So, as you all know, IP communications are usually based over what's known as sockets.
148480	155420	Sockets were something that essentially are meant to abstract sort of like what you'd have
155420	159680	with file descriptors, only in this case it would be network descriptors. The idea is fairly
159680	165080	simple, the application would open a socket and would just send and receive data as it would
165080	170060	with any other file descriptor. This could be using receive, send calls, etc, etc. And there
170060	176260	you'd also have some other APIs, which are essentially get peer and get adder info and so
176260	181680	forth, which are meant to be socket specific and to enhance these descriptors so as to
181680	187680	accommodate all types of TCP and UDP based needs. Now, the application itself is somewhat
187680	192240	agnostic in the sense that for it, it's just another file descriptor. Those of you who may
192240	196640	have some Unix background know that sockets and file descriptors in Unix are one and the
196640	200920	same, pretty much. So you can, you know, you have the very same API. In Windows, what
200920	205640	happens is that you have the Winsock, which I'll be describing shortly, which takes the
205640	210380	sockets just a bit further and gets you a lot of added functionality. Now the important
210380	214460	thing to emphasize is that the application would read and write just with any other file
214460	219680	descriptor, so what would happen essentially is that all the fragmentation and
219680	224920	encapsulation and getting the IP header and the TCP header, UDP, whatever it is, is basically
224920	229000	handled transparently by the OS, which is really good news for a lot of application
229000	235340	developers because they just work transparently and just don't care about whatever IP issues
235340	240100	or TCP and so forth issues that might arise. Now what I'm going to demonstrate to you works
240100	246660	with pretty much all sockets of all types. It works with TCP, UDP, raw sockets as well, in
246660	251620	case Microsoft hasn't crippled them completely in Service Pack 2, and also IPv6 sockets,
251620	257600	which is really nifty. Now, the way it works is that Microsoft took the BSD model, which is
257600	263340	your average libc type socket with all the rich API, and adapted it into something known as
263340	268480	Winsock, which is basically Windows sockets. This went through several versions and
268480	273880	revisions. We started with Winsock 1.x, which you're not going to see anyway because it's
273880	280180	mostly like for Windows 3.11 and so forth. And Winsock 2 is basically your baseline today.
280180	287640	That is to say it's present in Windows NT, it's present in Windows 2K, 2003, etc. And of
287640	295660	course your XP. Now the major important issue with Winsock is that the migration from 1.x to 2.x
295660	300400	added a host of new features. We're not going to be discussing those new features in length,
300400	305380	but some of you may know that it provides for asynchronous calls and various function
305380	309960	callbacks, which is really good if you're working in a multi-threaded environment and so forth.
310080	315380	It works with overlapped IO, namely getting more than one process to listen on the same
315380	321880	socket. And this is going to be the topic of our talk here, it provides something known as an
321880	326860	LSP architecture, which is the layered service provider. This is going to be a very key and
326860	332460	instrumental term for us, as this is essentially the core of the talk. This service provider
332460	341820	interface is essentially giving you the architecture to hook any Winsock call by any process
341820	346800	aside from certain system processes which bypass Winsock, we'll get into that in a second.
346800	352840	But essentially any Winsock functionality you wish, well it can be anything from a get host
352840	358400	by name, through of course sending and receiving in sockets and so forth, everything is pretty
358400	363760	much hijackable in the sense that this is pretty much the equivalent of set windows hook that
363760	369840	you'd have for general Windows API functions, only specific for the Windows platforms. Now
369840	375120	this is really, really useful and we're going to be talking about some of the legitimate uses
375120	380600	which as you'll see, there's quite a few legitimate uses, however we'll also see that the
380600	386780	really important uses are those that are, so to speak, less useful for the good guys and mostly
386780	392300	sort of like the covert or the black hat oriented uses. Now it's also important to say that
392300	396480	like I said, this has been out there for about seven years now pretty much, my first
396480	403580	encounter with that was like 1998 or so and it's really frightening to see that all this
403580	408900	functionality is there, it's under the hood so your applications are fully agnostic, they have
408900	414080	no idea that this functionality is there and yet spyware developers and other such
414080	419480	application developers can pretty much inject whatever functionality they want and the
419480	425440	application is none the wiser. So, getting into detail here, this little illustration here
425440	430820	shows you pretty much what the Windows networking architecture is all about. Some of you
430820	435040	may find this a bit familiar, for those of you who aren't, I'll just run a brief sort of
435040	440840	like, uh, review of this. So, looking at this from several levels of abstraction here, oops,
440840	446140	wait a second, that's Microsoft PowerPoint running bald on me. So, looking at this from
446140	451760	several layers of abstraction, we can see the hardware down below. Now, no matter what
451760	457140	hardware type you're using, whether you're using a wireless network or a wired Ethernet or
457140	462140	even a modem, pretty much all your Windsock calls will eventually be rerouted over the
462140	468060	hardware in a sort of, uh, device independent manner. The miracle that does this is
468060	472720	something called the NDIS driver, which is the network driver interface specification.
472720	478460	That's sort of like an abstract driver for any type of interface. Uh, in Unix terms, some of
478460	483000	you may be, uh, aware of the ifconfig and the interface configuration. So, it's pretty much a
483000	488480	port of the same idea in Windows terms. And the NDIS is essentially an abstract driver
488480	493900	that works with pretty much all types of communication, uh, devices. These can be
493900	499860	modems, these can be, uh, Ethernet cards, etc, etc. Following that, we have the TDI, which
499860	504780	is a transport driver interface. That acts somewhat of a, uh, somewhat like a bridge in the
504780	510960	sense that you have calls from user space going into kernel space through this TDI layer.
510960	517600	Now, in user space, you mostly have either Windsock 2 for 99% of the applications or
517600	523020	something known as NetBT, which is the NetBios over TCPIP transport. Some of you who might be
523020	528920	familiar with a backslash backslash server, the SMB or CIFS notation, that's pretty much it.
528920	534020	So, aside from the workstation and server service, which are core components of Windows,
534020	538420	pretty much any other application would go through Windsock. And that's, that of course is
538420	542440	what makes this all the more attractive to us. Now, as the applications go through
542440	548040	Windsock, they are pretty much, uh, you know, they all work over the same API, which is the
548040	554300	application programming interface. And that is the API that you link with Windsock or WS2
554300	560500	underscore 32 dot DLL and it gets you the functionality of the send receive and as well as a
560500	567880	host of WSA calls. Namely, uh, WSA async select and others to name a few. Okay, so, you have
567880	573560	all types of, uh, applications. They can be your browser, your FTP, naturally your IMs,
573560	579260	probably go over that as well, uh, IRC, et cetera, et cetera. Now, this is sort of like the
579260	585380	application type view that most programmers are familiar with. However, as it turns out, this
585380	591140	is only half the picture. So if, as, if we try and look deeper, we see that we have this
591140	596960	Windsock API layer, which is, again, the top interface, but we also see that we have a
596960	603100	Windsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as
603100	608700	service providers. Now, the term service provider, like I said, is a key term here because
608700	614240	service providers are essentially either hardware types, namely, uh, you know, your network
614240	619840	cards, et cetera, et cetera, or they could be software types as in software type drivers,
619840	624860	which are mostly user mode drivers. Now, this is really important since it gives you the full
624860	630800	functionality of packet inspection and whatever you want, but at the socket level. So
630800	635780	essentially, from an OSI model perspective, we're working at layer 5, which is really quite
635780	641080	the improvement over other types of, uh, sniffers and rootkits, which generally operate at a
641080	646580	lower level and thus confine you to a packet view. So here you can actually hijack a
646580	651160	socket and not really wonder as to whatever the breakdown of the packets is, because it
651160	656720	doesn't really matter. Now, uh, essentially these providers are one of two classes. You have
656720	663220	the transport providers, which as the name would imply, work with the data transport itself,
663220	668660	namely the TCP and UDP transfers, et cetera. And you have the namespace providers, which
668660	674260	work with all the, you know, get host by name, et cetera. Namely, if you want to look up any
674260	679960	type of address, that address can be a NetBIOS name, it can be an SMB name, a CIFS name,
679960	685040	et cetera. And this would imply, of course, that you need a mechanism to abstract that. And
685040	689120	this is exactly what the namespace providers are all about. I'm gonna focus on the
689120	693300	transport providers, because they are, of course, the, the sexier ones, in the sense that
693300	698340	they actually get you to see some real data. Now, as the illustration also shows, all the
698340	704520	providers would share the same API, the same top API, which is what I see here, what I
704520	709240	marked here, as a transport SPI, that is the transport service provider interface. So
709240	713920	whatever provider you're using, essentially all these providers must work pretty much the
713920	720820	same way. Now, Winsock providers cannot normally be listed by applications, or at least
720820	726040	they can be, but only if the application is actually aware of it. Microsoft has, as part of
726040	731240	the platform SDK, which is part of the Visual Studio distributions, they have something
731240	737860	known as an SPOrder.exe, which is a small executable, meant to show you the service
737860	745060	provider, um, order, of course, and also it comes with a small DLL called SPOrder.dll.
745260	751540	SPOrder.dll is a DLL we'll, we'll discuss shortly, it actually has the ability to not only
751540	756600	show you the service providers, but actually shuffle them around as you see fit. And this
756600	762290	type of shuffling around is exactly the hooking functionality. So going on to see a
762290	777840	demo of what the service providers are like. Okay, so, autocomplete is not cooperating. So
777840	783100	you have the SPOrder.exe, which shows you all the available service providers here. Now,
783100	789300	my display is, um, particularly cluttered due to the fact that I have VMware here, which,
789300	793660	uh, is pretty much all those global unique identifiers that you can see here, as well as
793660	799180	another VPN solution, which opens up a, a, a, sort of like a virtual interface. But the
799180	804100	core providers that you're likely to see are the ones you see here. There's one for the
804100	811540	infrared, which is IRDA, there's one for basic TCPIP, there's one for UDPIP, there's one for
811540	818080	raw sockets, and there's, uh, two of them for RSVP. RSVP is a quality of service
818080	823580	protocol, which is generally supported, but never really used by Windows. Now, going
823580	829140	into one of these, you can see that they essentially give you the complete information on
829140	835700	the service provider, namely, which DLL is actually the one that provides the functionality, as
835700	840640	well as a bunch of service flags, provider ID, which is a global unique identifier, et cetera,
840640	845600	et cetera. The important stuff here that some of you programmers might recognize are the
845600	852440	address family, the hex value 2, meaning AFINET, uh, there's also the socket type, which
852440	858080	is, uh, SOCKSTREAM, and there's a protocol number, which is 6. 6, of course, for TCP. And
858080	864460	naturally you'd have, uh, 17, or hex 11, for UDP. And so the way that works is that any
864460	871120	time an application would request a type of socket to be created, which would be a SOCKSTREAM,
871120	876860	and rather an AFINET, SOCKSTREAM, and a TCP, essentially, a TCP socket, what would happen
876860	885000	here is that this call would be redirected over to MSWSOCK.DLL, where WINSOCK, or the WS232
885000	890520	DLL, is actually acting like a multiplexer. That is to say that it is one main interface under
890520	895480	which you can have all types of various providers. Now, again, this would normally be the
895480	900320	case with your average Windows, and the more interfaces you have and the more applications
900320	904780	you have, the more of those providers you're likely to see. As for the name resolution
904780	910180	providers, these are the namespace providers. You have your basic TCPIP, which is an
910180	916460	interface to the DNS client service. You have NTDS, which is, of course, Active Directory.
916560	921040	And you have, uh, network location awareness, which is something that, again, Microsoft
921040	928340	supports, but never really works. So, you have all those. And, now comes the important part.
928340	933640	The important part is that you can have, over these service providers, you can have a
933640	940580	functionality that enables you to chain your own providers. That is to say, not just add a
940580	944640	provider, and by doing so, you're going to have to essentially make the application aware
944640	949600	of that provider, but you can pretty much hook your providers and install something known
949820	956320	as a provider chain, which is really an amazing idea. Now, the original plan behind that
956320	962160	was to support all types of NICE uses. NICE such as transparent encryption, such as
962160	967120	quality of service, et cetera, et cetera. But the way that works is that most applications don't
967120	972860	really use that functionality, and so it's just left there, but not really used in everyday
972860	979140	terms. Now, the beauty of it is that you can chain any number of providers, and you can
979140	984140	chain them in pretty much any order you want. That is to say that if you want to provide
984700	990840	some, uh, encryption functionality, for example, or reroute everything, all types of, uh,
990840	996340	data transparently over SSL or SSH or whatever other tunnel you want, you can pretty much
996340	1002240	install your provider, and then bump it to the top of the stack. So, any other application
1002240	1007660	using the stack would essentially get directed to your provider first, and your provider
1007660	1012700	would do whatever, and then follow down the chain, essentially progressing the API calls
1012700	1020820	down the chain. Any questions thus far? Okay. So, the way it works is that your provider
1020840	1027640	Winsock, the DLL itself, has several functions which are exported. Uh, I'm going to try this,
1027640	1034420	the dump-in demo a bit clearer here, so you'll be able to see the font back there. So, uh,
1034420	1046210	just looking through that... Okay, so what I'm doing now is I'm setting up the visual,
1046210	1051290	uh, studio command line, uh, environment, so I can show you the dump-in command. And the
1051290	1056170	way dump-in works is, as some of you may know, it gives you the DLL and shows you all the
1056170	1060390	exported functions, or the imported functions, and so forth. So, what I'm going to do now is
1060390	1066170	essentially look for an exported function list of Winsock, and focus on the specific
1066170	1073350	service provider interface. To do that, what we'll do is just do dump-in slash exports, get the
1073350	1082510	name of the, um, of the WS232, and since, essentially, Winsock exports, like, on average
1082510	1087050	about 100 and something functions, I'm going to use the command line utility of grep to
1087050	1093210	isolate only those important ones for our discussion. So, looking at that, you can see
1093210	1099210	that you have these particular WSC functions. Now, again, those of you who might be working
1099210	1104390	with Winsock on a daily basis know that Winsock usually exports the WSAs, which is for the
1104390	1109550	Winsock API. The WSCs you see here are essentially all about the service provider
1109550	1114510	interface and so forth. Now, the, they're probably, there's too many functions here to, to
1114510	1119690	actually go over, but the ones of interest are essentially install provider and
1119690	1126210	deinstall provider, which enables you to, of course, set your own LSP or remove your LSP, as
1126210	1132990	well as install namespace, and for some weird reason, it's uninstall namespace, hinting that
1132990	1138270	maybe this API was not really meant to be used, because it's not really standardized in that
1138270	1144270	sense, as in uninstall and not deinstall. Now, all of these are also fully documented as part
1144270	1149770	of the MSDN, but it's the kind of MSDN documentation that resides on, like, the fourth CD that
1149770	1155670	nobody ever gets to, because it's, like, so obscure in the back. Okay, now, as it so
1155670	1160770	happens, okay, these functions are readily exportable, and you can use them to do, uh, your
1160770	1166990	own type of work, as I'll show, um, briefly in a demo. Now, this SP order DLL is an
1166990	1173190	additional DLL that, as I said, works for, uh, rewriting the service provider order. And as the
1173190	1177950	example here shows, this is a dump bin of the SP order DLL, and you have write namespace
1177950	1182290	provider, uh, sorry, write provider order and write namespace order, which essentially
1182290	1187490	enable you to shuffle around, as I've stated, and put your provider just in its right
1187490	1194310	location. Now, a lot of spyware aware applications, uh, like AdAware and all types of, um,
1194310	1200750	anti-spyware, essentially look for that DLL, and if that DLL is present on your operating
1200750	1205770	system, then it's bad news. Then they normally flag it as spyware and so forth. Probably the
1205770	1211770	best example of that was, uh, Kaza, the file sharing utility, that has SP order dot DLL
1211770	1218870	bundled in. So when you install Kaza, you have this DLL somewhere on your system. Another,
1218870	1224210	uh, interesting application to use this type of DLL is Google desktop. Uh, I don't know how
1224210	1229170	many of you use Google desktop, but Google desktop has, uh, probably its niftiest feature is
1229170	1234170	that after you install it, whenever you go into Google dot com, you suddenly get your own
1234170	1238890	desktop there. You have, like, the ability to search Google, or to search your own desktop
1238890	1243770	from the very same webpage. Now, obviously, that kind of functionality would imply that
1243770	1250230	Google has a mechanism in your machine that can intercept the calls to Google dot com,
1250230	1255450	and re- sort of, like, rewrite the page content on the fly. And that is exactly the
1255450	1259890	functionality that I'm describing here. Namely, by installing their own provider and putting
1259890	1265010	it in your machine, they can, uh, intercept the go- the calls to Google, but they can, of
1265010	1268470	course, do whatever they want. That is to say that if they're not really playing by the
1268470	1273130	rules, they can do a lot of other stuff as well with your machine. But then, I'm happy to
1273130	1277110	see that not too many people use Google desktop here, because that's kind of, like, shady.
1277110	1284010	Anyways, so going over that, uh, pro- probably the most interesting API call would be the
1284010	1291470	WSCEnum protocols, which would be the API call that one would use as a setup to install
1291470	1298130	their own provider. This, much like all the other WS, uh, enum functions, will enable you
1298130	1303730	to, sort of, like, go over the protocols that are already in place, and provide for an
1303730	1308610	enumeration of them. An enumeration, in our case, would be a pointer to an array of
1308610	1314950	protocol infrastructures. Now, uh, you have a fully annotated example on the PDF, uh, in
1314950	1319590	the PDF, so I won't really go into that. But the idea is fairly simple. Anybody can call
1319590	1325710	this function and see what service providers are already there. And in many ways, this is
1325710	1330310	pretty much the only mitigation against this type of attack. However, most applications
1330310	1335190	don't really use that, and if anything, they would use the counterpart of this call, which
1335190	1341070	would be the WSA enum protocols. And the difference between the A and the C is that the C
1341070	1346550	can get all the protocols, whereas the A gets only the top layer ones. So if you're using
1346550	1351510	yours in a chain, essentially you can remain hidden, which is, of course, bad news. So,
1351510	1357030	going over that, we have the enum protocols just to see which protocols are there, and we
1357030	1361690	naturally want to build our own service provider. Now, building a service provider is really
1361690	1367510	fun. It's really easy, too, because as a baseline, you have the Microsoft Supply demo. So, I
1367510	1372530	happen to have this demo right here, and I'm going to work with the actual Microsoft code. Uh,
1372530	1376750	due to copyright restrictions, I haven't really bundled it or, you know, put it in a
1376750	1381850	charge easy for you guys to use, but it's fairly simple to just get this code from, uh, the
1381850	1386870	MSDN and just work and do the same modifications that I did right here. So, looking through
1386870	1394720	that code, uh, let's start with, probably the DLL main would be a good point to start. So,
1394720	1401780	launching Visual Studio just so we, we can see this type of DLL, then our service provider is
1401780	1404960	just, just going to be another DLL. So, essentially, it has to follow the very same
1404960	1410180	conventions. That is to say, it has to start with a DLL main, and the DLL main would work as
1410180	1415920	pretty much all DLL mains work. That is, whenever an application would hook to us and would
1415920	1423480	call us, uh, we would get the DLL process attached at the, uh, DW reason. And so, the way that
1423480	1429540	works is, whenever a process attaches, I add this little addition here, which essentially
1429540	1435600	doesn't do much. What it does is it just opens up a file name, okay? It readies a file name
1435600	1442900	here with a, with an S print F, composed of sock debug as a prefix, and the current process
1442900	1448220	ID embedded in there. The reason I do that is because, once I'll do that and, of course, run my
1448220	1453620	applications, you'll see that each application, as it uses Winsock, will generate this type of
1453620	1458840	file on the root of the C drive. Okay, and what it does here is that it just opens the files
1458840	1463500	and pops a message box, and you will be able to see that message box. That message box, and
1463500	1469300	any type of code that I run here, is run in the context of the calling process. So, while this
1469300	1473660	is a somewhat innocuous example, and just, you know, only for demonstration purposes, I'll
1473660	1478080	print out a lot of stuff, if I really wanted to, I could do whatever I wanted here.
1478080	1483180	Essentially, I could load additional DLLs, as the comment says. I could decide that this
1483180	1488600	particular process should not access the stack, and so forth. Now, to make matters even
1488600	1494600	easier for the spyware people, this type of functionality can also be injected in the WSP
1494600	1501680	startup call. The WSP startup, which is shown right here in the slide. So, WSP startup is
1501680	1506620	essentially the counterpart to WSA startup. Those of you who may have been working with
1506620	1512800	Windows know that each Windows application, as it starts, as it launches its Winsock
1512800	1518180	functionality, has to start off by calling this function, the WSA startup. And what it does is
1518180	1523420	that it requests a certain Winsock version, and requests certain capabilities. Now, the
1523420	1529060	beauty of it is that, you know, most programmers just call WSA startup, check the return value,
1529060	1533660	and naturally everything is just okay. However, these programmers are unaware that this
1533660	1539040	essentially would call the WSP startup, which is our code. So, in our LSP, what we're
1539040	1544480	gonna do is essentially implement a WSP startup, which will have our very own code in
1544480	1549540	there. Now, looking at WSP startup, you can see that it has five parameters, as opposed to
1549540	1554480	WSA, which has, of course, fewer parameters. The parameters of interest here are
1554480	1562140	specifically the three last ones. We have the in-parameter LP protocol info, which states
1562140	1568340	what type of functionality the application expects. Namely, are we expected to perform TCP
1568340	1574820	or UDP or any type of other service? We further have something known as the up-call table,
1574820	1581900	which is, by far, the most useful parameter here, which will enable us to have an array of,
1581900	1588060	essentially, it's a pointer to an array of functions, and these functions are the already
1588060	1593460	installed providers. So that means that if I want to hook, for example, send or receive, I don't
1593460	1598440	really have to think about how I would implement send or receive, but rather I would implement
1598440	1602880	them my own in sort of like a stub function, and later on just go on to call the up-call
1602880	1607700	table. And the example will demonstrate that shortly. Finally, we have the only out parameter
1607700	1612560	here of interest. The other one's really not interesting. The LP WSP data is really not
1612560	1619040	interesting. But the LP PROC table here is our procedure call table, and that is essentially a
1619040	1624260	pointer to all our functions. So whatever functions you choose to implement, you can pretty
1624260	1632420	much set in this big structure there, and just call WSP startup, and returning from the call,
1632420	1637160	you would pretty much produce your procedure table, and you'd be guaranteed that your
1637160	1642900	applications, your rather, sorry, procedures would be called. Now those of you who may have
1642900	1647360	been working in the Unix and Linux environment would know that in order to achieve that in
1647360	1653920	Linux, you'd pretty much need to have any type of a kernel module inside the Linux kernel,
1653920	1658380	for example, or any type of streams interface in Solaris, which would of course be a lot of
1658380	1663180	hassle. But when it comes to Windows, all this is pretty much transparent to you. So, looking
1663180	1672440	over the SPI CPP, which is the main file that has all the functions, let's just go over WSP
1672440	1681180	startup. And you'll see that what Intel and Microsoft do here, this is again their demo, is
1681180	1687660	that they simply implement this WSP startup call. The important thing here would be after
1687660	1694620	initializing their own internal structure, would be, number one, to save the Winsock2 up
1694620	1699660	call table. That is to say, save the actual implementations that are already out there,
1699660	1705140	because we're going to need to call them as sort of a pass through. And once that's done, they
1705140	1710380	do a lot of other startup code and so forth, and they get to the important portion of
1710380	1717140	populating the procedure table. So, the procedure table is a structure, and it's as simple as
1717140	1721880	it can get, because you'd have a structure of function pointers, and all you have to do is just
1721880	1726100	hook your function pointer to the corresponding functionality that you want. And so once
1726100	1731300	that's done, you can essentially hook all those calls. Now, just looking at one of those
1731300	1738380	calls, say for example, WSP receive, which would be the counterpart of the WSA receive and
1738380	1744660	so forth. Okay, so looking through that, at some point we'll get there. Yeah, okay, there
1744660	1752520	it is. So, this is the WSP receive function, which is again, guaranteed to be called prior to
1752520	1757580	the application actually getting any data. So, if Google, for example, wants to rewrite the
1757580	1762280	content, this is exactly the function they'll hook. Now, again, I won't go over the numerous
1762280	1769320	parameters here. The parameters of interest are obviously the socket in question, and a
1769320	1773560	long pointer to the buffers. This would be an array of input buffers, and since we're
1773560	1778360	passing an array by reference, we also have to piggyback the third parameter, which is the
1778360	1783520	count of buffers, namely what is the size of said array. And so what I do in my little demo
1783520	1793920	here is do a fairly simple function here, which would just go on and write to the debug
1793920	1799940	file that it's intercepted a receive, and would simply go over the buffer, it's going over
1799940	1804920	the entire array there, and simply printing out the buffers. Now, as far as a demo is
1804920	1810280	concerned, this is really not the type of graphical pyrotechnic demo you'd imagine, because
1810280	1815600	it also will intercept a lot of binary data. However, it does illustrate the point that the
1815600	1821160	data can be intercepted and can be, of course, modified. If you want to, you can pretty
1821160	1827380	much have any type of modification of those LP buffers, and you can inject your own
1827380	1832960	buffers, you can put your data, you can log the data, and so forth. I, of course, chose just
1832960	1838260	to log the data. Now, naturally, you do the same thing for WSP send, and a host of other
1838260	1844140	functions, but that goes without saying. So, we have our DLL, and now the next place would
1844140	1851100	be, the next step, sorry, would be to insert it. Okay, somehow get Winsock to recognize our
1851100	1856580	service provider as a valid service provider. Now, bear in mind that this is something that
1856580	1862760	has to be done outside the DLL, because your DLL can only intercept certain functions, but it
1862760	1868300	cannot install itself. However, in order to install it, we have another call, which is a WSP
1868300	1875200	install provider. This is a fairly simple call, where all you have to do is provide a
1875200	1881240	global unique identifier, which is, of course, easy to just whip up for yourself, and you'd
1881240	1887260	set up your own DLL path, and the type of protocols you support. That's all it takes. Now,
1887260	1892240	your example should have, actually, I'll go to my source code here, just to demonstrate how
1892240	1898140	simple it is. So, all you'd have to do is have a small executable file, like, say, this
1898140	1904400	inst.lsp, which, again, is a verbatim copy of the Intel one. I didn't really do anything
1904400	1909100	here, because this is the same generic code that would work with any service provider. And
1909100	1915740	so, what it does here is that it has a little function called install my provider, wherein I
1915740	1922860	populate the provider info, like so. I populate a lot of stuff. You'll also notice a nice
1922860	1928100	little flag here called PFL hidden, which is this flag right here. Which is a really nice
1928100	1933200	flag, because this actually tells Winsock, if anybody wants to enumerate this provider from
1933200	1938960	the API level, keep it hidden. Which, you know, I don't really get the actual intended use of
1938960	1945160	that, but whatever. Now, there's also another interesting copy here, which is security
1945160	1950560	scheme, which enables you to have your own type of security for your provider, blah, blah,
1950560	1955280	blah. Most of the time, you just do protocol none. So, essentially, I populate this
1955280	1961160	provider, and I, of course, register it as a protocol provider for TCP. And once that's
1961160	1968940	done, all I have to do is just call this WSP, sorry, WC install provider, and provide
1968960	1975000	the name of LSP DLL. This is assumed to be a Windows system, which would be a problem if
1975000	1979300	you're not an admin, but then again, you're going to have to be an admin to run this anyway.
1979320	1984780	But you can also specify a full path here if you really want to. And so, I load the protocol
1984780	1991740	info through the pointer, and once that's done, I pretty much guaranteed that my provider
1991740	1997540	will be installed there. Now, let's go ahead and try and install that provider and see
1997540	2003000	exactly what happens. Now, you'll notice that I already took the liberty of placing that
2003000	2011140	little DLL here. That DLL is as compact as 81K. Actually, it's 80K or so. And the thing is,
2011140	2017240	once that DLL is in place, all I have to do is call the inst LSP executable to do the rest.
2017240	2022660	Now, before I do that, I want to fire up RegMon. RegMon is a tool by Sysinternals, which
2022660	2028960	I'm sure most of you know, and that enables us to hook all types of registry calls. And the
2028960	2034100	important thing here is that all this type of functionality of installing providers or
2034320	2039380	de-installing providers is essentially all registry-based. So, if you really want to
2039380	2044980	bypass this type of DLL with enumerating the provider order and so forth or installing your
2044980	2049700	own providers, all you have to do is directly access the registry, which is, of course,
2049700	2054900	fairly simple. So, what I'm going to do now is I'm going to launch RegMon. And, naturally,
2054900	2060540	all is silent because my process hasn't started yet. And now I'm going to run this inst LSP.
2060620	2066100	And as I do, you can see that it's scanning the installed providers and then going on to
2066100	2072520	install my provider on top of all the rest. Now, again, since this is a rather crude demo, I
2072520	2077700	didn't really go to any, you know, pains of just looking for the right providers. I just
2077700	2081980	said, go ahead and install it over all the providers. But it's fairly simple to just decide
2081980	2087220	that you want a very specific provider. Now, you can also see that there's a lot of registry
2087220	2093820	action here. And, specifically, all the registry action is focused on one specific branch,
2093820	2101060	which is HKEY-LOCAL-MACHINE-SYSTEM, CURRENT-CONTROL-SET-SERVICES, and WINSOC2. So,
2101060	2107000	firing up RegEdit, just to see what it's like there, you'll see, and it's already in my
2107000	2111720	favorites, you'll see that WINSOC2 parameters has the namespace catalog, which is for the
2111720	2116500	namespace providers, and the protocol catalog, which is for the transport providers. Now,
2116500	2121280	again, Microsoft is inconsistent. They don't really call the things by the same name all the
2121280	2127120	time, but that's, you know, beside the point here. So, under the namespaces, you have all
2127120	2131820	types of catalog entries. And, as you can see, you have the same catalog entries that we
2131820	2138820	could have seen under the SP order executable, namely the NTDS, the plain TCPIP, and so forth.
2138820	2144280	And, when it comes to the protocol catalog here, everything gets really messy, because one
2144280	2150160	would think that you'd get these nice type of keys and values, but here you only have a
2150160	2156260	packed catalog item, which is a blob of binary data that if you go into, you'll actually see
2156380	2161760	makes a lot of sense. This is a protocol info structure that has been overlaying into the
2161760	2167260	registry as raw binary data. Now, you'll also note that once I put in my layered service
2167260	2172340	provider, the number of providers here has risen from the 30-something that it should be
2172340	2178080	to around 57, because that's where my mine is hooking. So, with all that in mind, the stage
2178080	2182900	is set, and I can now run any application of my choice, as I'll shortly do, and you'll see
2182900	2188480	that as the applications run, I'll get a nice little message box, and I'll get a full log of
2188480	2211740	whatever. Any questions thus far? Yeah? Well, no, that would go with the namesake provider
2211740	2216400	with the TCPIP one, which I'm not really discussing how to hook that. If you really wanted
2216400	2222560	to, you could also hook the loopback address as well, so as people would, you know, go ahead
2222560	2228460	and try to resolve, and get the 127.0.0.1, because it's in your host file, but then the
2228460	2233960	application would get that first. So you'd be able to actually re-write the result of the
2233960	2239120	NS lookup, or whatever DNS packet should have been there, and you'd be able to just put in
2239120	2243480	any address of your own, which is of course, you know, very nice for our purposes.
2243500	2249280	Furthermore, the Google desktop would then have to connect to the loopback interface, and
2249280	2255100	that would be a transport type action, and you'd be able to get the connect. You'd be able
2255100	2261820	to hook the connect call, and see a connect to 127.0.0.1, to whatever port Google is using,
2261820	2267000	and of course redirect it. So simply, you know, simply providing your workaround wouldn't
2267000	2271180	really work, because this functionality is actually stronger than that. Any other
2271180	2281700	questions? Yeah, back there. Say what? Oh, you can't. The beauty of it, okay, so the
2281700	2286240	question is, say I want to put in my own provider, how can I ensure that my provider is
2286240	2292420	the topmost? Uh, in, you know, in two words, you can't. Because any provider that gets
2292420	2298620	installed after you, can pretty much re-route, re-write, sorry, the stack as they see fit.
2298620	2303280	So you'd have the protocol chain, you'd think you're there first, but the whole beauty of
2303280	2307680	this mechanism is that it's so transparent, that at any other point in time, somebody can
2307680	2313380	get ahead, sort of like bump in front of you, and hook you as well. So that's of course, you
2313380	2319760	know, good news or bad news, depending on your perspective here. Yeah, but that's not to
2319760	2324060	guarantee that somebody else, some other application starting up after you, they could
2324060	2328140	enumerate the order as well, and they could re-write the order as they see fit. So
2328140	2332640	essentially, this is somewhat of a limbo, in the sense that you have a given order, but
2332640	2337380	the enum protocols will only provide you with a snapshot of the current order, and no
2337380	2341920	guarantee of any other application coming after you. You cannot decide you want to be the
2341920	2347940	topmost protocol in the chain, and that's it. Further, when any other protocol gets bumped
2347940	2355160	in, you wouldn't know, you have no indication whatsoever as to your position. Yeah, you'd
2355160	2360820	still be, well, again, okay, so, right, okay, so the question is, would I still be hooked?
2360820	2365100	And the answer is yes and no, because yes, I would be hooked in the sense that I'd have my
2365100	2370580	own place in the protocol chain. I don't mind the fish. So I'll have my own place in the
2370580	2377440	protocol chain, yes, but if any other topmost provider would want to hold that call in the
2377440	2381360	chain and not propagate it, not play by the rules, they'd be able to intercept it and
2381360	2387900	essentially block it. So as I place my own provider, I can either choose to go ahead and
2387900	2391940	forward the call, or I can say no, I want to handle the call, and I don't want to propagate
2391940	2408470	it further. You can change the providers at any time, okay? Using the provider order, the
2408470	2414010	WSPRite provider and so forth, you can pretty much redo the whole ordering as you wish,
2414010	2423290	because essentially all it changes is some internal structure in Winsock. Oh yeah, of
2423290	2427090	course, of course, but then again, there's no guarantee that you will be called again,
2427090	2431350	because again, let's assume for a sake that I have my own custom provider, and I want to
2431350	2436430	make sure that nobody gets on top of me. So, assuming whoever gets on top of me does
2436430	2442430	forward the call further, yes, I will be called. But if that somebody takes the express
2442430	2447610	route and just, you know, decides to bypass whatever other calls, then essentially my
2447610	2453950	provider would still be there, but would never be called. Yeah, the order is in the
2453950	2458230	registry, and of course, in enum protocols would work as well. You could enum the
2458230	2462450	protocol so as to get it in a nice little array, but the order is right here. Okay, this is
2462450	2466810	pretty much the order, I mean, you can pretty much see that the key names are the ordinals,
2466810	2477090	so it doesn't get too complex than that. The route by sysinternals, I'm not familiar with
2477090	2481710	the specific one, but I can tell you that a lot of other rootkit detectors don't really go
2481710	2487550	that far. Now it's important to just define the terms here. This is perfect user mode
2487550	2492770	action. This is not a rootkit in the sense of like a, a kernel mode rootkit, because that
2492770	2498030	would be hijacking TCPIP.sys itself. And that, you know, that, that, there's nothing that
2498030	2503270	can be done against that. But the beauty of it is that this is full user mode, and in that
2503270	2507550	sense it's a lot easier, not to mention you can code sloppy and not risk a blue screen of
2507550	2511910	death, which is of course a nice little added benefit there. Okay, so, uh, since I'm getting
2511910	2517790	the, uh, noose, I'll just, uh, run a few applications here. So let's just start, you know,
2517790	2523230	let's just run Firefox and a bunch of others. Oh, and as you can see, Firefox is loading, and
2523230	2528650	already I have a sock debug of 1148, which is of course the process ID of Firefox. So
2528650	2533070	Firefox is running, and this is the Mozilla start page, and I can do all sorts of, you know,
2533070	2539490	other, whatever. And see, I can get any types of pages I want, and everything is really nice
2539490	2547830	and dandy. But behind the scenes, I have this little, uh, sock debug, 1148. And of course I
2547830	2552650	could also fire up my messenger, or my Yahoo, or whatever, and I'll do that just briefly
2552650	2559130	here. Uh, so as, as I fire up Yahoo, I should be getting the message box sometime soon. Uh,
2559130	2562870	yeah, just, you know, Yahoo's a bit slow. Okay, now you'll notice this is a really
2562870	2567830	nice, uh, effect, that I get the message box in the context of the Yahoo process, so I get
2567830	2573590	their window class, which is a nice, uh, not really nice, but, purple, whatever. Okay? And
2573590	2577950	so, this is connecting, and everything is cool and nice. You can also see that it's hooking
2577950	2584750	another call, and, uh, whatever, they'll just let it run. And, you know, ditto for messenger.
2584750	2591650	So if I'll just run here, run messenger, uh, yeah, whatever, yeah, yeah, you can, okay,
2591650	2596610	whatever, that's a student of mine, disregard that. Okay? So, uh, again, so I can run that
2596610	2601610	with messenger and so forth, and all these SOG debug files are right here, so let's just go
2601610	2609450	over the 1148 one, and we'll be able to see that, again, this is very crude, so I get a lot
2609450	2615090	of seemingly junk-looking data. This junk-looking data is, is all types of either gzip
2615090	2621430	compressed HTTP data, or, uh, all sorts of binary data, such as images and, and so forth.
2621430	2627510	If I scroll down, I should be able to see some HTTP requests right here. Okay, so this is the
2627510	2632650	get of header tab dot gif, and naturally, you get all types of this, this, for example, is a
2632650	2637490	PNG, you can pretty much see the header here, that's a dead giveaway, uh, as well as a bunch
2637490	2642630	of others, et cetera, et cetera, the HTTP replies and so forth. Now, again, I want to
2642630	2647990	emphasize one thing, this, again, as a demo, is not as half as fancy as it can be, because
2647990	2653070	with a little if there, I could have simply rerouted Mozilla to some other site, or I could
2653070	2658770	have modified whatever Mozilla was displaying. Now, another disclaimer here, is that HTTPS
2658770	2663530	type connections are unaffected by that. Fortunately, there are other ways to hook HTTPS,
2663530	2668650	which are beyond my scope here, but I'm just saying that if you do use HTTPS, you're fine.
2668650	2673730	However, when it comes to all types of other functionality, messenger, um, email,
2673730	2683430	whatever, everything is pretty much in the clear. Okay? Any questions? Yeah. Yeah, with
2683430	2689510	NetBT you can, although it's, well, again, that, let's define NetBT. If the process that
2689510	2695850	runs the NetBT request has launched after you have put in your provider, then yes, you
2695850	2701230	can. And if you get your provider into the Windows startup, then yes, you can. Okay?
2701230	2706770	However, some functionality you still won't get, namely the, uh, the Winsock bypass
2706770	2712090	functionality that sometimes a server service does. Okay? In order to, to gain efficiency, it
2712090	2715950	doesn't go through a user mode DLL, because it doesn't make sense, you know? Okay, so you
2715950	2724490	can hijack some of the functionality, although not all. Any other questions? Yeah. Uh, no,
2724490	2728850	zone alarm actually, as far as I know, go into the TDI. This is what McAfee does, though.
2728850	2734150	McAfee, the personal firewall, uh, does do, uh, they do do that. So, but again, this is
2734150	2738310	kind of like, uh, kind of like, uh, a paradox in the sense that, you know, it's absurd,
2738310	2744450	because if McAfee uses that, and I can pretty much intercept their calls and get on top,
2744450	2750310	or, or reroute them to the bottom, then it's really useless. Any further questions?
2750310	2764630	Because I'm getting the, sort of like, news time. So, yeah, right there. Okay, the
2764630	2771350	question is, if I'm intercepting a WSP receive, if I'm intercepting an SSL socket, would it be
2771350	2775710	encrypted or not? And yes, it would be encrypted, because I'm essentially getting it as it
2775710	2781450	came on the network. So, this enables you to play middleman, but only middleman, you know,
2781450	2786930	post-SSL or post-encryption, which is, as I've stated, the proper workaround, the proper
2786930	2791830	mitigation to that would be to always use SSL and so forth. However, bear in mind that
2791830	2796670	nothing is preventing the, uh, application from also, you know, trying to forge certificates
2796670	2801910	and do any type of de-SNF type man-in-the-middle, which would work here. Okay? So, just to
2801910	2808030	conclude, before I'm, uh, kicked out violently, okay? So, that was the demo. The lesson to be
2808030	2812850	learned, the, the thing you need to carry home from this, is that no matter what you do, no
2812850	2818010	matter how you code your application, the beauty of Winsock is in transparency. However, this
2818010	2823790	is a double-edged sword, because obviously, as transparent as it is, it enables attackers to
2823790	2829190	subvert either client sockets, server sockets, whatever. Now, it's also important to
2829190	2835410	emphasize that this was originally intended for good uses. Namely, implementing an
2835410	2841130	application type firewall, application layer firewall. We mentioned McAfee, and, ah, of
2841130	2846630	course, we, we saw where that got. Um, transparently add encryption. This was well before
2846630	2851970	the days of IPsec. We're talking about 98, before IPsec was a fully robust protocol, as it is
2851970	2857610	now. And nowadays, IPsec is handled, of course, in the kernel level. Uh, enforce quality of
2857610	2864070	service. Yeah, right. Uh, support new protocols. This is also another nifty functionality. You
2864070	2869570	can essentially support IPv6 by it, although it's supported already. You can support IPv9,
2869570	2875310	you can support pretty much any other custom protocol over a raw socket. And patch content
2875310	2880550	on the fly, which, like I said, Google Desktop actually do. Whether it's a legitimate use or an
2880550	2887070	illegitimate use remains to be seen. However, the much better chaotic uses would be to patch
2887070	2891870	content on the fly in the illegitimate sense. And again, we're talking about rewriting web
2891870	2897870	pages, rewriting IMs, uh, doing a lot of other nifty stuff, which I will not disclose here.
2897990	2902230	Um, obtain connection statistics, URLs, et cetera, et cetera. Most of the spyware
2902230	2907070	applications do exactly that. They put themselves in so as to gather your statistics. This was
2907070	2913750	what the CASA spyware did. Eavesdropping on any type of connection, but again, non-SSL ones.
2913750	2918710	And, uh, rerouting connections, that is just hijacking the sockets, which is really an
2918710	2924510	amazing thing. Because an application opens a socket and calls connect. And once it does
2924510	2929630	that, then, you know, the worst that can happen, it'll, it's gonna call get peer adder. But
2929630	2933590	you can reroute connect and you can also reroute get peer adders. So, you know, whatever the
2933590	2938370	application thinks it's doing, whatever, wherever it's, it's actually thinking that it's
2938370	2942870	connecting to, it has no real significance here because you can do whatever you want with
2942870	2948670	it. So, uh, all that in mind, the demo, like I said, is part of the platform SDK. Uh, you're
2948670	2955050	welcome to drop a line to, uh, this address right here. And if you need, you know, the demo
2955050	2960510	with the actual, uh, explanation on what I did, where I did, and so forth, then it will be
2960510	2965890	supplied, of course. Any further questions? Okay. Peace.