start	end	text
2460	11980	Hi everyone, thanks for attending. My name is Jonathan and the topic of my talk is going to be
11980	16980	about the dark side of Winsock, which is essentially all the under-the-hood functionality that you
16980	23340	have inside Winsock, inside the Windows TCPIP stack, which unfortunately, even though it's
23340	30000	there and it's publicly available, it is somewhat undocumented and the only people to really
30000	35900	use it are the bad guys, namely people who want to do rootkits, who want to do spyware, etc.
36500	43600	Now I find myself somewhat inclined to start with a preamble here. This is not some type of
43600	49560	vulnerability issue or not some type of any zero-day exploit, so if any of you are expecting
49560	54420	that, it's probably not the right place to be. What this is, however, is a discussion on
54420	61580	functionality, which, like I said, is in there and is mostly... well, mostly the only really
61580	66740	good uses, as you'll see, are the insidious ones, namely the ones that aren't really designed
66740	74140	to happen. Things such as usurping connections, rerouting connections, connection monitoring,
74140	81760	etc, etc. Now it is assumed that you guys have had some experience with Winsock before.
81760	89480	How many of you have actually coded in Windows for Winsock? Okay, well, okay, so as I was,
89480	93520	you know, I kind of suspected that, so we'll start with a brief intro that kind of has the
93520	97960	nomenclature and kind of has like the basic terminology, so those of you who are fairly new
97960	103460	to this will be able to sort of like keep afloat, and then we'll get into the code. Now the
103460	107700	code itself that I'll be demonstrating is all fully annotated, you've got that on the CD.
107700	115020	On the CD you have a PDF of my talk, which, contrary to other PDFs, it's not just the slides,
115020	119620	it's also the notes pages, so you'll be able to have the full source code, everything is there.
119900	125760	Furthermore, my demo, which I'm going to run shortly, is based on a public demo, which is
125760	130860	Intel's and Microsoft's code, so it's like fully open source and nothing too new there.
131160	136340	So, we start with the introduction, and some of you may already know this, and I'm actually
136340	141840	hoping most of you know this, but it's just sort of like the basic terms we'll be using.
142040	147500	So, as you all know, IP communications are usually based over what's known as sockets.
147520	154460	Sockets were something that essentially are meant to abstract sort of like what you'd have
154460	158720	with file descriptors, only in this case it would be network descriptors. The idea is fairly
158720	164120	simple, the application would open a socket and would just send and receive data as it would
164120	169100	with any other file descriptor. This could be using receive, send calls, etc, etc. And there
169100	175300	you'd also have some other APIs, which are essentially get peer and get adder info and so
175300	180700	forth, which are meant to be socket specific and to enhance these descriptors so as to
180700	186720	accommodate all types of TCP and UDP based needs. Now, the application itself is somewhat
186720	191280	agnostic in the sense that for it, it's just another file descriptor. Those of you who may
191280	195880	have some Unix background know that sockets and file descriptors in Unix are one and the same
195880	200580	pretty much. So you can, you know, you have the very same API. In Windows, what happens is
200580	205900	that you have the Winsock, which I'll be describing shortly, which takes the sockets just a
205900	210140	bit further and gets you a lot of added functionality. Now the important thing to
210140	215020	emphasize is that the application would read and write just with any other file descriptor,
215020	220040	so what would happen essentially is that all the fragmentation, encapsulation, and getting
220040	224440	the IP header and the TCP header or UDP, whatever it is, is basically handled
224440	228520	transparently by the OS, which is really good news for a lot of application developers
228520	234880	because they just work transparently and just don't care about whatever IP issues or TCP
234880	239400	and so forth issues that might arise. Now what I'm going to demonstrate to you works with
239400	245680	pretty much all sockets of all types. It works with TCP, UDP, raw sockets as well, in
245680	250220	case Microsoft hasn't crippled them completely in service pack 2, and also IPv6
250220	255800	sockets, which is really nifty. Now, the way it works is that Microsoft took the BSD
255800	261660	model, which is your average libc type socket with all the rich API, and adapted it into
261660	266720	something known as Winsock, which is basically Windows sockets. This went through several
266720	272100	versions and revisions. We started with Winsock 1.x, which you're not going to see anyway
272100	277780	because it's mostly like for Windows 3.11 and so forth. And Winsock 2 is basically your
278300	284660	baseline today. That is to say it's present in Windows NT, it's present in Windows 2K,
284660	292600	2003, etc. And of course your XP. Now the major important issue with Winsock is that the
292600	297720	migration from 1.x to 2.x added a host of new features. We're not going to be discussing
297720	302400	those new features in length, but some of you may know that it provides for asynchronous
302400	307540	calls and various function callbacks, which is really good if you're working in a multi-threaded
307540	313500	environment and so forth. It works with overlapped IO, namely getting more than one process to
313500	319260	listen on the same socket. And, this is going to be the topic of our talk here, it provides
319260	324720	something known as an LSP architecture, which is the layered service provider. This is going
324720	330580	to be a very key and instrumental term for us, as this is essentially the core of the talk.
330580	338760	This service provider interface is essentially giving you the architecture to hook any Winsock
338760	344500	call by any process, aside from certain system processes which bypass Winsock, we'll get
344500	349840	into that in a second. But essentially any Winsock functionality you wish, it can be
349840	355720	anything from get host by name, through of course sending and receiving in sockets and so
355720	360800	forth, everything is pretty much hijackable, in the sense that this is pretty much the
360800	366420	equivalent of set windows hook, that you'd have for general Windows API functions, only
366420	372260	specific for the Windows platforms. Now this is really, really useful, and we're going to be
372260	376720	talking about some of the legitimate uses, which as you'll see, there are quite a few
376720	382680	legitimate uses, however we'll also see that the really important uses are those that are, so
382680	388040	to speak, less useful for the good guys, and mostly sort of like the covert or the black hat
388040	393340	oriented uses. Now it's also important to say that, like I said, this has been out there for
393340	400140	about 7 years now pretty much, my first encounter with that was like 1998 or so, and it's
400140	405100	really frightening to see that all this functionality is there, it's under the hood, so
405100	410880	your applications are fully agnostic, they have no idea that this functionality is there, and
410880	415960	yet spyware developers and other such application developers can pretty much inject
415960	421760	whatever functionality they want, and the application is none the wiser. So, getting into
421760	426720	detail here, this little illustration here shows you pretty much what the Windows
426720	431680	networking architecture is all about. Some of you may find this a bit familiar, for those of
431680	437240	you who aren't, I'll just run a brief sort of like, uh, review of this. So, looking at this
437240	442340	from several levels of abstraction here, oops, wait a sec, that's Microsoft PowerPoint
442340	447660	running wild on me. So, looking at this from several layers of abstraction, we can see the
447660	453300	hardware down below. Now, no matter what hardware type you're using, whether you're using a
453300	458960	wireless network, or a wired ethernet, or even a modem, pretty much all your Windsock
458960	463940	calls will eventually be rerouted over the hardware in a sort of, uh, device independent
463940	469920	manner. The miracle that does this is something called the Ndisk driver, which is the network
469920	474880	driver interface specification. That's sort of like an abstract driver for any type of
474880	480080	interface, uh, in Unix terms, some of you may be, uh, aware of the ifconfig and the interface
480080	485320	configuration, so it's pretty much a port of the same idea in Windows terms. And the
485320	490120	Ndisk is essentially an abstract driver that works with pretty much all types of
490120	495980	communication, uh, devices. These can be modems, these can be, uh, ethernet cards, et cetera,
495980	501180	et cetera. Following that, we have the TDI, which is a transport driver interface. That
501180	506100	acts somewhat of a, uh, somewhat like a bridge, in the sense that you have calls from user
506100	512220	space going into kernel space through this TDI layer. Now, in user space, you mostly have
512220	518880	either Winsock2, for 99% of the applications, or something known as NetBT, which is the
518880	523360	NetBios over TCPIP transport. Some of you who might be familiar with the backslash,
523360	528840	backslash server, the SMB or CIFS notation, that's pretty much it. So, aside from the
528840	533860	workstation and server service, which are core components of Windows, pretty much any
533860	538000	other application would go through Winsock. And that's, that of course is what makes this
538000	542860	all the more attractive to us. Now, as the applications go through Winsock, they are
542860	547620	pretty much, uh, you know, they all work over the same API, which is the application
547620	554000	programming interface. And that is the API that you link with Winsock, or WS2 underscore
554000	559520	32 dot DLL, and it gets you the functionality of the send, receive, and as well as a host
559520	566900	of WSA calls. Namely, uh, WSA async select and others, to name a few. Okay, so, you have
566900	572680	all types of, uh, applications. They can be your browser, your FTP, naturally your IMs,
572680	578280	probably go over that as well, uh, IRC, et cetera, et cetera. Now, this is sort of like the
578280	584200	application type view that most programmers are familiar with. However, as it turns out,
584200	589900	this is only half the picture. So if, as, if we try and look deeper, we see that we have
589900	596000	this Winsock API layer, which is, again, the top interface, but we also see that we have a
596000	602120	Winsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as
602120	607760	service providers. Now, the term service provider, like I said, is a key term here, because
607760	613260	service providers are essentially either hardware types, namely, uh, you know, your network
613260	618920	cards, et cetera, et cetera, or they could be software types, as in software type drivers,
618920	623640	which are mostly user mode drivers. Now, this is really important since it gives you the
623640	629840	full functionality of packet inspection and whatever you want, but at the socket level. So
629840	634340	essentially, from an OSI model perspective, we're working at layer five, which is really
634340	639140	quite the improvement over other types of, uh, sniffers and rootkits, which generally
639140	644460	operate at a lower level and thus confine you to a packet view. So here you can actually
644460	649920	hijack a socket and not really wonder as to whatever the breakdown of the packets is,
649920	654500	because it doesn't really matter. Now, uh, essentially these providers are one of two
654500	660420	classes. You have the transport providers, which, as the name would imply, work with the
660420	665920	data transport itself, namely the TCP and UDP transfers, et cetera. And you have the
665920	671760	namespace providers, which work with all the, you know, get host by name, et cetera. Namely,
671760	677260	if you want to look up any type of address, that address can be a NetBIOS name, it can be
677260	682360	an SMB name, a CIFS name, et cetera. And this would imply, of course, that you need a
682360	686480	mechanism to abstract that. And this is exactly what the namespace providers are all
686480	691180	about. I'm gonna focus on the transport providers because they are, of course, the, the
691180	696140	sexier ones, in the sense that they actually get you to see some real data. Now, as the
696140	701740	illustration also shows, all the providers would share the same API, the same top API,
701740	706240	which is what I see here, what I mark here, as a transport SPI, that is the transport
706240	710960	service provider interface. So whatever provider you're using, essentially all these
710960	717780	providers must work pretty much the same way. Now, Winsock, uh, providers cannot normally
717780	722400	be listed by applications, or at least they can be, but only if the application is actually
722400	727760	aware of it. Microsoft has, as part of the platform SDK, which is part of the Visual Studio
727760	734140	Distributions, uh, they have something known as an SPOrder.exe, uh, which is a small
734140	740400	executable, meant to show you the service provider, um, order, of course, and also it
740400	747460	comes with a small DLL called SPOrder.dll. SPOrder.dll is a DLL we'll, we'll discuss
747460	752780	shortly, it actually has the ability to not only show you the service providers, but
752780	757700	actually shuffle them around as you see fit. And this type of shuffling around is exactly
757700	762440	the hooking functionality. So going on to see a slight demo of what the service
762440	778630	providers are like. Okay, so, autocomplete is not cooperating. So you have the SPOrder.exe
778630	784270	which shows you all the available service providers here. Now, my display is, um,
784270	789210	particularly cluttered due to the fact that I have VMware here, which, uh, is pretty much
789210	793950	all those global unique identifiers that you can see here, as well as another VPN solution
793950	800130	which opens up a, a, a, sort of like a virtual interface. But the core providers that you're
800130	805370	likely to see are the ones you see here. There's one for the infrared, which is IRDA, there's
805370	813230	one for basic TCPIP, there's one for UDPIP, there's one for raw sockets, and there's, uh,
813230	819390	two of them for RSVP. RSVP is a quality of service protocol which is generally supported
819390	825450	but never really used by Windows. Now going into one of these, you can see that they
825450	831470	essentially give you the complete information on the service provider, namely which DLL is
831470	836690	actually the one that provides the functionality, as well as a bunch of service flags, provider
836690	842110	ID, which is a global unique identifier, et cetera, et cetera. The important stuff here that
842110	847190	some of you programmers might recognize are the address family, the hex value 2, meaning
847190	854170	AFINET, uh, there's also the socket type, which is SOCKSTREAM, and there's a protocol number
854170	862190	which is 6, 6 of course for TCP. And naturally you'd have 17 or hex 11 for UDP. And so the way
862190	868410	that works is that any time an application would request a type of socket to be created,
868410	874490	which would be a SOCKSTREAM, rather an AFINET, SOCKSTREAM, and a TCP essentially, a TCP
874490	880970	socket, what would happen here is that this call would be redirected over to MSWSOCK.DLL,
880970	887690	where WINSOCK, or the WS232 DLL, is actually acting like a multiplexer. That is to say that
887690	893530	it is one main interface under which you can have all types of various providers. Now again,
893530	898430	this would normally be the case with your average Windows, and the more interfaces you have
898430	903030	and the more applications you have, the more of those providers you're likely to see. As for
903030	908750	the name resolution providers, these are the namespace providers. You have your basic TCPIP,
908750	914530	which is an interface to the DNS client service. You have NTDS, which is of course Active
914530	919730	Directory. And you have Network Location Awareness, which is something that again,
919730	926270	Microsoft supports but never really works. So you have all those. And now comes the
926270	932150	important part. The important part is that you can have over these service providers, you can
932150	938530	have a functionality that enables you to chain your own providers. That is to say, not just
938530	943030	add a provider, and by doing so you're going to have to essentially make the application
943030	948030	aware of that provider, but you can pretty much hook your providers and install something
948030	954570	known as a provider chain, which is really an amazing idea. Now the original plan behind
954570	961190	that was to support all types of NICE uses. NICE such as transparent encryption, such as
961190	966410	quality of service, etc, etc. But the way that works is that most applications don't really
966410	972850	use that functionality, and so it's just left there, but not really used in everyday terms.
972850	978750	Now, the beauty of it is that you can chain any number of providers, and you can chain them
978750	984170	in pretty much any order you want. That is to say that if you want to provide some
984730	990510	encryption functionality, for example, or reroute everything, all types of data
990510	995370	transparently over SSL or SSH or whatever other tunnel you want, you can pretty much
995370	1001270	install your provider, and then bump it to the top of the stack. So any other application
1001270	1006690	using the stack would essentially get directed to your provider first, and your provider
1006690	1011730	would do whatever, and then follow down the chain, essentially progressing the API calls
1011730	1020490	down the chain. Any questions thus far? Okay. So, the way it works is that your Winsock,
1020510	1027350	the DLL itself, has several functions which are exported. I'm going to try this, the
1027350	1033630	dump-in demo, a bit clearer here, so you'll be able to see the font back there. So, just
1033630	1045860	looking through that... Okay, so what I'm doing now is I'm setting up the Visual Studio
1045860	1051260	command line environment, so I can show you the dump-in command. And the way dump-in works
1051260	1056360	is, as some of you may know, it gives you the DLL and shows you all the exported functions
1056360	1060120	or the imported functions and so forth. So what I'm going to do now is essentially look
1060120	1067240	for an exported function list of Winsock and focus on the specific service provider interface.
1067240	1077780	To do that, what we'll do is just do dump-in slash exports, get the name of the WS232,
1077780	1086340	and since essentially Winsock exports on average about a hundred and something functions, I'm
1086340	1092060	going to isolate only those important ones for our discussion. So, looking at that, you can
1092060	1098240	see that you have these particular WSC functions. Now again, those of you who might be working
1098240	1103400	with Winsock on a daily basis know that Winsock usually exports the WSAs, which is for the
1103400	1109240	Winsock API. The WSCs you see here are essentially all about the service provider interface and
1109240	1115020	so forth. Now, the, the, probably there's too many functions here to actually go over, but
1115020	1120780	the ones of interest are essentially install provider and deinstall provider, which enables
1120780	1128480	you to, of course, set your own LSP or remove your LSP, as well as install namespace, and for some
1128480	1134960	weird reason, it's uninstall namespace, hinting that maybe this API was not really meant to be
1134960	1139740	used, because it's not really standardized in that sense, as in uninstall and not deinstall.
1139740	1145000	Now, all of these are also fully documented as part of the MSDN, but it's the kind of
1145640	1150120	MSDN documentation that resides on like the fourth CD that nobody ever gets to, because it's
1150120	1156880	like so obscure in the back. Okay, now, as it so happens, okay, these functions are readily
1156880	1163000	exportable, and you can use them to do your own type of work, as I'll show briefly in a
1163000	1170660	demo. Now, this SP order DLL is an additional DLL that, as I said, works for rewriting the
1170660	1174580	service provider order. And as the example here shows, this is a dump bin of the SP order
1174580	1180080	DLL, and you have write namespace provider, sorry, write provider order and write namespace
1180080	1185200	order, which essentially enable you to shuffle around, as I've stated, and put your provider
1185200	1192400	just in its right location. Now, a lot of spyware-aware applications, like AdAware and all
1192400	1199400	types of anti-spyware, essentially look for that DLL, and if that DLL is present on your
1199400	1204180	operating system, then it's bad news. Then they normally flag it as spyware and so forth.
1204180	1209860	And probably the best example of that was, uh, Kasa, the file sharing utility that has SP
1209860	1215880	order dot DLL bundled in. So when you install Kasa, you have this DLL somewhere on your
1215880	1222820	system. Another, uh, interesting application to use this type of DLL is Google Desktop. I
1222820	1227220	don't know how many of you use Google Desktop, but Google Desktop has, uh, probably its
1227220	1232260	niftiest feature is that after you install it, whenever you go into google.com, you
1232260	1237100	suddenly get your own desktop there. You have, like, the ability to search Google or to
1237100	1240980	search your own desktop from the very same webpage. Now, obviously, that kind of
1240980	1247060	functionality would imply that Google has a mechanism in your machine that can intercept
1247060	1253820	the calls to google.com and re- sort of like rewrite the page content on the fly. And that
1253820	1257860	is exactly the functionality that I'm describing here. Namely, by installing their own
1257860	1262860	provider and putting it in your machine, they can, uh, intercept the go- the calls to
1262860	1266540	Google, but they can, of course, do whatever they want. That is to say that if they're not
1266540	1270840	really playing by the rules, they can do a lot of other stuff as well with your machine. But
1270840	1274760	then, I'm happy to see that not too many people use Google Desktop here, because that's
1274760	1281820	kind of, like, shady. Anyways, so going over that, uh, pro- probably the most interesting
1281820	1289680	API call would be the WC enum protocols, which would be the API call that one would use as a
1289680	1296640	setup to install their own provider. This, much like all the other WS, uh, enum functions,
1296640	1302400	will enable you to sort of, like, go over the protocols that are already in place and
1302400	1307140	provide for an enumeration of them. An enumeration, in our case, would be a pointer to an
1307140	1313840	array of protocol infrastructures. Now, uh, you have a fully annotated example on the PDF, uh,
1313840	1318620	in the PDF, so I won't really go into that. But the idea is fairly simple. Anybody can call
1318620	1324740	this function and see what service providers are already there. And in many ways, this is
1324740	1329360	pretty much the only mitigation against this type of attack. However, most applications
1329360	1334220	don't really use that, and if anything, they would use the counterpart of this call, which
1334220	1340080	would be the WSA enum protocols. And the difference between the A and the C is that the C
1340080	1345580	can get all the protocols, whereas the A gets only the top layer ones. So if you're using
1345580	1350880	yours in a chain, essentially you can remain hidden, which is of course bad news. So, going
1350880	1356060	over that, we have the enum protocols just to see which protocols are there, and we
1356060	1360460	naturally want to build our own service provider. Now, building a service provider is
1360460	1364920	really fun. It's really easy, too. Because as a baseline, you have the Microsoft supply
1364920	1369740	demo. So, I happen to have this demo right here, and I'm going to work with the actual
1369740	1375180	Microsoft code. Due to copyright restrictions, I haven't really bundled it or, you know, put
1375180	1380360	it in a targeasy for you guys to use, but it's fairly simple to just get this code from the
1380360	1385880	MSDN and just work and do the same modifications that I did right here. So, looking through
1385880	1393890	that code, let's start... I think the DLL main would be a good point to start. So, launching
1393890	1401350	Visual Studio just so we can see this type of DLL, then our service provider is just going to
1401350	1405310	be another DLL. So, essentially it has to follow the very same conventions. That is to say
1405310	1410530	it has to start with the DLL main, and the DLL main would work as pretty much all DLL
1410530	1416930	mains work. That is, whenever an application would hook to us and would call us, we would
1416930	1424070	get the DLL process attached at the DW reason. And so, the way that works is whenever a
1424070	1430350	process attaches, I add this little addition here, which essentially doesn't do much. What it
1430350	1436910	does is it just opens up a filename. Okay, it readies a filename here with an S printf,
1437490	1444210	composed of sockdebug as a prefix, and the current process ID embedded in there. The reason I
1444210	1448670	do that is because once I'll do that and, of course, run my applications, you'll see that
1448670	1454070	each application, as it uses Winsock, will generate this type of file on the root of the
1454070	1459150	C drive. Okay, and what it does here is that it just opens the files and pops a message box,
1459150	1463850	and you will be able to see that message box. That message box and any type of code that I
1463850	1469450	run here is run in the context of the calling process. So, while this is a somewhat innocuous
1469450	1473550	example, and just, you know, only for demonstration purposes, I'll print out a lot of
1473550	1477950	stuff, if I really wanted to, I could do whatever I wanted here. Essentially, I could load
1477950	1483910	additional DLLs, as the comment says. I could decide that this particular process should not
1483910	1490370	access a stack, and so forth. Now, to make matters even easier for the spyware people, this
1490370	1497150	type of functionality can also be injected in the WSP startup call. The WSP startup, which is
1497150	1503770	shown right here in the slide. So, WSP startup is essentially the counterpart to WSA startup.
1503770	1509170	Those of you who may have been working with Windows know that each Windows application, as
1509170	1514370	it starts, as it launches its Winsock functionality, has to start off by calling this
1514370	1520270	function, the WSA startup. And what it does is that it requests a certain Winsock version, and
1520270	1525610	requests certain capabilities. Now, the beauty of it is that, you know, most programmers just
1525610	1530810	call WSA startup, check the return value, and naturally everything is just okay. However,
1530810	1535830	these programmers are unaware that this essentially would call the WSP startup, which is our
1535830	1541630	code. So, in RLSP, what we're gonna do is essentially implement a WSP startup, which will
1541630	1547130	have our very own code in there. Now, looking at WSP startup, you can see that it has five
1547130	1552090	parameters, as opposed to WSA, which has, of course, fewer parameters. The parameters of
1552090	1559450	interest here are specifically the three last ones. We have the in-parameter LP protocol
1559450	1565490	info, which states what type of functionality the application expects. Namely, are we
1565490	1571810	expected to perform TCP, or UDP, or any type of other service. We further have something
1571810	1578370	known as the up-call table, which is by far the most useful parameter here, which will
1578370	1584890	enable us to have an array of, essentially it's a pointer to an array of, uh, functions. And
1584890	1589790	these functions are the, uh, already installed providers. So that means that if I wanna
1589790	1594670	hook, for example, send or receive, I don't really have to think about how I would
1594670	1599050	implement send or receive, but rather I would implement them my own in sort of like a
1599050	1603630	stub function, and later on just go on to call the up-call table. And the example will
1603630	1607730	demonstrate that shortly. Finally, we have the only out parameter here of interest, the
1607730	1612630	other one's really not interesting. The LP WSP data is really not interesting. But the
1612630	1618550	LP proc table here is our procedure call table, and that is essentially a pointer to all
1618550	1623950	our functions. So whatever functions you choose to implement, you can pretty much set
1623950	1631730	in this big structure there, and just call WSP startup and returning from the call, you
1631730	1636190	would pretty much produce your procedure table, and you'd be guaranteed that your
1636190	1641330	applications, your, uh, rather, sorry, procedures would be called. Now those of you who
1641330	1645670	may have been working in the Unix and Linux environment would know that in order to
1645670	1650530	achieve that in Linux, you'd pretty much need to have any type of, uh, a kernel module
1650530	1655670	inside, uh, inside the Linux kernel, for example, or any type of streams interface in
1655670	1659630	Solaris, which would of course be a lot of hassle. But when it comes to Windows, all this
1659630	1666090	is pretty much transparent to you. So, looking over the SPI CPP, which is the main
1666190	1674370	file that has all the functions, let's just go over WSP startups briefly, and you'll see
1674370	1681170	that what Intel and Microsoft do here, this is, uh, again, their demo, is that they simply
1681690	1687410	implement this WSP startup call, uh, the important thing here would be, after initializing
1687410	1694630	their own internal structure, would be, number one, to save the Winsock2 up call table, that
1694630	1699270	is to say, save the actual implementations that are already out there, because we're gonna
1699270	1704830	need to call them as sort of a pass through, and once that's done, they do a lot of other
1704830	1711210	startup code and so forth, and they get to the important portion of populating the procedure
1711210	1716990	table. So, the procedure table is a structure, and it's as simple as it can get, because
1716990	1721570	you'd have a structure of function pointers, and all you have to do is just hook your function
1721570	1726290	pointer to the corresponding functionality that you want. And so once that's done, you
1726290	1731210	can essentially hook all those calls. Now, just looking at one of those calls, say for
1731210	1738810	example WSP receive, which would be the counterpart of the, uh, WSA receive and so forth, okay,
1738810	1745530	so looking through that, at some point we'll get there, uh, yeah, okay, there it is. So,
1745530	1751710	this is the WSP receive function, which is again guaranteed to be called prior to the
1751710	1756610	application actually getting any data. So, if Google, for example, wants to rewrite the
1756610	1761310	content, this is exactly the function they'll hook. Now, again, I won't go over the numerous
1761310	1768350	parameters here, the parameters of interest are obviously the socket in question, and a
1768350	1772590	long pointer to the buffers. This would be an array of input buffers, and since we're
1772590	1777390	passing an array by reference, we also have to piggyback the third parameter, which is the
1777390	1782290	count of buffers, namely what is the size of said array. And so what I do in my little
1782290	1791090	demo here, is do a fairly simple, uh, function here, which, hold on, which would just go
1791090	1796970	on and write to the debug file that it, it's intercepted a receive, and would simply go
1796970	1801810	over the buffer, it's going over the entire array there, and simply printing out the
1801810	1806290	buffers. Now, as far as a demo is concerned, this is really not the type of graphical
1806290	1811650	pyrotechnic demo you'd, uh, imagine, because it also will, will intercept a lot of binary
1811650	1816730	data. However, it does illustrate the point that the data can be intercepted and can be, of
1816730	1822970	course, modified. If you want to, you can pretty much have any type of modification of
1822970	1828230	those LP buffers, and you can inject your own buffers, you can, you know, put your data,
1828230	1833530	you can, uh, log the data, and so forth. I, of course, chose just to log the data. Now,
1833530	1838270	naturally, you, you do the same thing for WSP send, and a host of other functions, but that
1838270	1844330	goes without saying. So, we have our DLL, and now the next place would be, the next step,
1844330	1850430	sorry, would be to, uh, insert it. Okay, somehow get Winsock to recognize our service
1850430	1855950	provider as a valid service provider. Now, bear in mind that this is something that has to
1855950	1861990	be done outside the DLL, because your DLL can only intercept certain functions, but it cannot
1861990	1867310	install itself. However, in order to install it, we have another call, which is a WSP
1867310	1874230	install provider. This is a fairly simple call, where all you have to do is provide a
1874230	1878930	global unique identifier, which is, of course, um, easy to, uh, just whip up to, for
1878930	1884770	yourself, and you'd set up your own DLL path, and the type of protocols you support. That's
1884770	1890390	all it takes. Now, uh, your example should have, actually, I'll go to my source code here,
1890390	1895990	just to demonstrate how simple it is. So, all you have to do is have a small executable
1895990	1902470	file, like, say, this instLSP, which, again, is, uh, a verbatim copy of the Intel one. I
1902470	1906390	didn't really do anything here, because this is the same generic code that would work with
1906390	1912510	any service provider. And so, what it does here is that it has a little function called
1912510	1919450	install my provider, wherein I populate the provider info, like so, I populate a lot of
1919450	1924970	stuff. You'll also notice, uh, a nice little flag here called PFL hidden, which is this
1924970	1929810	flag right here. Which is a really nice flag, because this actually tells Winsock, if
1929810	1935250	anybody wants to enumerate this provider from the API level, keep it hidden. Which, you
1935250	1939670	know, I don't really get the actual intended use of that, but whatever. Now, there's also
1939670	1944990	another, there's also another interesting, uh, copy here, which is, uh, security scheme.
1945150	1949770	Which enables you to have your own type of security for your provider, blah, blah, blah,
1949770	1955070	most of the time you just do protocol none. So, essentially, I populate this provider, and
1955070	1962290	I, of course, register it as a protocol provider for TCP, and once that's done, is, uh, all I
1962290	1968630	have to do is just call this WSP, sorry, WC install provider, and provide the name of
1968630	1974450	LSP DLL. This is assumed to be a Windows system, which would be a problem if you're not an
1974450	1979270	admin, but then again, you're gonna have to be an admin to run this anyway. But you can also
1979270	1984970	specify a full path here if you really want to. And so, I load the protocol info through the
1984970	1991210	pointer, and once that's done, I, I pretty much guaranteed that my, uh, provider will be
1991210	1997110	installed there. Now, let's go ahead and try and install that provider, and see exactly what
1997110	2002630	happens. Now, you'll notice that I already, uh, took the liberty of placing that little DLL
2002630	2010350	here. That DLL is as compact as 81K. Actually, it's 80K or so. And, uh, the thing is, once
2010350	2016570	that DLL is in place, all I have to do is call the inst LSP executable to do the rest. Now,
2016570	2022030	before I do that, I want to fire up RegMon. RegMon is a tool by Sysinternals, which I'm sure
2022030	2027990	most of you know, and that enables us to, uh, hook all types of registry calls. And the
2027990	2033130	important thing here is that all the, this type of functionality of installing providers, or
2033130	2038790	deinstalling providers, is essentially all registry based. So, if you really want to bypass
2038790	2044130	this type of DLL with enumerating the provider order and so forth, or installing your own
2044130	2049050	providers, all you have to do is directly access the registry, which is, of course, fairly
2049050	2054210	simple. So, what I'm going to do now is I'm going to launch RegMon, and naturally all is
2054210	2060150	silent, because my process hasn't started yet. And now I'm going to run this inst LSP, and
2060150	2065110	as I do, you can see that it's scanning the installed providers, and then going on to
2065110	2070670	install my provider on top of all the rest. Now, again, since, since this is a rather crude
2070670	2075590	demo, I didn't really go to any, you know, uh, pains of just looking for the right
2075590	2079750	providers. I just said, go ahead and install it over all the providers. But it's fairly
2079750	2085130	simple to just decide that you want a very specific provider. Now, you can also see that
2085130	2090050	there's a lot of registry action here, and specifically, all the registry action is
2090050	2097950	focused on one specific branch, which is HKEY-LOCAL-MACHINE-SYSTEM, CURRENT-CONTROL-SET-SERVICES,
2097950	2105450	and WINSOC2. So, firing up RegEdit, just to see what it's like there, you'll see, and it's a
2105450	2110330	already in my favorites, you'll see that WINSOC2 parameters has the namespace catalog, which
2110330	2114690	is for the namespace providers, and the protocol catalog, which is for the transport
2114690	2119830	providers. Now, again, Microsoft is inconsistent. They don't really call things by the same
2119830	2125410	name all the time, but that's, you know, beside the point here. So, under the namespaces, you
2125410	2130410	have all types of catalog entries, and as you can see, you have the same catalog entries
2130410	2136750	that we could have seen under the SP order executable, namely the NTDS, the plain TCPIP, and
2136750	2142430	so forth. And, when it comes to the protocol catalog here, everything gets really messy,
2142430	2148330	because one would think that you'd get these nice type of keys and values, but here you only
2148330	2154490	have a packed catalog item, which is a blob of binary data, that if you go into, you'll
2154490	2159230	actually see makes a lot of sense. This is a protocol info structure that has been
2159230	2165570	overlaying into the registry as raw binary data. Now, you'll also note that once I put in
2165570	2170590	my layered service provider, the number of providers here has risen from the 30-something
2170590	2176430	that it should be, to around 57, because that's where mine is hooking. So, with all that in
2176430	2181070	mind, the stage is set, and I can now run any application of my choice, as I'll shortly do,
2181070	2185970	and you'll see that, as the applications run, I'll get a nice little message box, and I'll
2185970	2209630	get a full log of whatever. Any questions thus far? Yeah? Mm-hmm. Well, no, that would go
2209630	2213310	with the namespace provider with the TCPIP one, which I'm not really discussing how to
2213310	2219410	hook that. If you really wanted to, you could also hook the loopback address as well, so
2219410	2224790	as people would, you know, go ahead and try to resolve and get the 127.0.1, because it's
2224790	2230130	in your host file, but then the application would get that first. So you'd be able to
2230130	2235990	actually rewrite the result of the NS lookup, or whatever DNS packet should have been
2235990	2240790	there, and you'd be able to just put in any address of your own, which is, of course, you
2240790	2246270	know, very nice for our purposes. Furthermore, the Google desktop would then have to
2246270	2251790	connect to the loopback interface, and that would be a transport type action, and you'd be
2251790	2257330	able to, to get the connect. You'd be able to hook the connect call, and see a connect to
2257330	2263690	127.0.1, to whatever port Google is using, and, of course, redirect it. So simply, you
2263690	2268130	know, simply providing your workaround wouldn't really work, because this functionality is
2268130	2279090	actually stronger than that. Any other questions? Yeah, back there. Say what? Oh, you
2279090	2283850	can't. The beauty of it, okay, so the question is, say I want to put in my own provider. How
2283850	2289110	can I ensure that my provider is the topmost? Uh, in, you know, in two words, you can't.
2289170	2295030	Because any provider that gets installed after you, can pretty much re-route, re-write,
2295030	2300130	sorry, the, the stack as they see fit. So you'd have the protocol chain, you'd think you're
2300130	2304930	there first, but the whole beauty of this mechanism is that it's so transparent, that at
2304930	2309970	any other point in time, somebody can get ahead, sort of like bump in front of you, and hook
2309970	2314070	you as well. So that's, of course, you know, good news or bad news, depending on your
2314070	2320410	perspective here. Yeah, but that's not to guarantee that somebody else, some other
2320410	2324770	application starting up after you, they could enumerate the order as well, and they could
2324770	2329330	re-write the order as they see fit. So essentially, this is somewhat of a limbo, in the
2329330	2333830	sense that you have a given order, but the enum protocols will only provide you with a
2333830	2339190	snapshot of the current order, and no guarantee of any other application coming after you.
2339190	2344790	You cannot decide you want to be the topmost protocol in the chain, and that's it. Further,
2344790	2350210	when any other protocol gets bumped in, you wouldn't know, you have no indication whatsoever
2350210	2357910	as to your position. Yeah, you'd still be, well, again, okay, so, right, okay, so the
2357910	2362830	question is, would I still be hooked? And the answer is yes and no, because yes, I would be
2362830	2366610	hooked in the sense that I'd have my own place in the protocol chain. I don't mind the
2366610	2372130	fish. So I'll have, I'll have my own place in the protocol chain, yes, but if any other
2372130	2378270	topmost provider would want to hold that call in the chain and not propagate it, not play by
2378270	2383110	the rules, they'd be able to intercept it and essentially block it. So as I place my own
2383110	2389250	provider, I can either choose to go ahead and forward the call, or I can say no, I want to
2389250	2403920	handle the call, and I don't want to propagate it further. You can change the providers at
2403920	2409720	any time, okay? Using the provider order, the WSPRite provider and so forth, you can pretty
2409720	2415620	much redo the whole ordering as you wish, because all it, essentially all it changes is
2415620	2423720	some internal structure in Winsock, so... Oh yeah, of course, of course, but then again,
2423720	2427920	there's no guarantee that you will be called again, because again, let's assume for a sake
2427920	2432880	that I have my own custom provider, and I want to make sure that nobody gets on top of me.
2432900	2438820	So, assuming whoever gets on top of me does forward the call further, yes, I will be called.
2438820	2444100	But if that somebody takes the express route and just, you know, decides to bypass whatever
2444100	2449580	other calls, then essentially my provider would still be there, but would never be called.
2451380	2456720	Yeah, the order is in the registry, and of course, in enum protocols would work as well. You
2456720	2460860	could enum the protocol so as to get it in a nice little array, but the order is right here.
2461080	2465060	Okay, this is pretty much the order, I mean, you can pretty much see that the key names are
2465060	2475840	the ordinals, so it doesn't get too complex. The route by sysinternals, I'm not familiar
2475840	2480300	with the specific one, but I can tell you that a lot of other route kit detectors don't
2480300	2486260	really go that far. Now it's important to just define the terms here. This is perfect user
2486260	2491220	mode action. This is not a route kit in the sense of like a, a kernel mode route kit,
2491220	2496660	because that would be hijacking TCPIP.sys itself. And that, you know, that, that, there's
2496660	2501520	nothing that can be done against that. But the beauty of it is that this is full user mode,
2501520	2506100	and in that sense it's a lot easier, and not to mention, you can code sloppy and not risk a
2506100	2510440	blue screen of death, which is of course a nice little added benefit there. Okay, so since
2510440	2516800	I'm getting the noose, I'll just run a few applications here. So let's just start, you know,
2516800	2522240	let's just run Firefox and a bunch of others. Oh, and as you can see, Firefox is loading, and
2522240	2527980	already I have a sock debug of 1148, which is of course the process ID of Firefox. So Firefox
2527980	2532520	is running, and this is the Mozilla start page, and I can do all sorts of, you know, other
2532520	2539460	whatever. And see, I can get any types of pages I want, and everything is really nice and dandy.
2539480	2547520	But behind the scenes, I have this little, uh, sock debug 1148. And of course I could also fire
2547520	2554020	up my messenger, or my Yahoo, or whatever, and I'll do that just briefly here. Uh, so as, as I
2554020	2559120	fire up Yahoo, I should be getting the message box sometime soon. Uh, yeah, just, you know,
2559120	2563400	Yahoo's a bit slow. Okay? Now you'll notice this is a really nice, uh, effect, that I get the
2563400	2568700	message box in the context of the Yahoo process, so I get their window class, which is a nice,
2568700	2574700	uh, not really nice, but purple whatever. Okay? And so, this is connecting and everything is
2574700	2580900	cool and nice. You can also see that it's hooking another call, and, uh, whatever, they'll just
2580900	2588060	let it run, and, you know, ditto for messenger. So if I'll just run here, run messenger, uh,
2588060	2593080	yeah, whatever, yeah, yeah, you can, okay, whatever. That's a student of mine, disregard that.
2593100	2598940	Okay? So, uh, again, so I can run that with messenger and so forth, and all these SOG debug
2598940	2605300	files are right here. So let's just go over the 1148 one, and you'll be able to see that, again,
2605300	2612320	this is very crude, so I get a lot of seemingly junk looking data. This junk looking data is, is
2612320	2619060	all types of either gzip compressed HTTP data, or, uh, all sorts of binary data such as images
2619060	2625580	and, and so forth. If I scroll down, I should be able to see some HTTP requests right here.
2625680	2630640	Okay? So this is the get of header tab dot gif, and naturally, you get all types of this, this
2630640	2635360	for example is a PNG. You can pretty much see the header here, that's a dead giveaway. Uh, as
2635360	2640680	well as a bunch of others, et cetera, et cetera, the HTTP replies and so forth. Now again, I
2640680	2646720	want to emphasize one thing. This, again as a demo, is not as half as fancy as it can be.
2646860	2651980	Because with a little if there, I could have simply rerouted Mozilla to some other site, or I
2651980	2656960	could have modified whatever Mozilla was displaying. Now another disclaimer here, is that
2656960	2661800	HTTPS type connections are unaffected by that. Fortunately, there are other ways to hook
2661800	2666960	HTTPS, which are beyond my scope here. But, I'm just saying that if you do use HTTPS, you're
2666960	2672760	fine. However, when it comes to all types of other functionality, messenger, um, email,
2672760	2682440	whatever, everything is pretty much in the clear. Okay? Any questions? Yeah. Yeah, with
2682440	2689140	NetBT you can, although it's, well, again, let's define NetBT. If the process that runs the
2689140	2695580	NetBT request has launched after you have put in your provider, then yes, you can. And if you
2695580	2701260	get your provider into the Windows startup, then yes, you can. Okay? However, some
2701260	2707220	functionality you still won't get. Namely the, uh, the Winsock bypass functionality, that
2707220	2711520	sometimes the server service does. Okay? In order to, to gain efficiency, it doesn't go
2711520	2715800	through a user mode DLL, because it doesn't make sense, you know? Okay? So, you can hijack
2715800	2723700	some of the functionality, although not all. Any other questions? Yeah. Uh, no. Zone
2723700	2727880	alarm, actually, as far as I know, go into the TDI. This is what McAfee does, though.
2727920	2733360	McAfee, the personal firewall, uh, does do, uh, they do do that. So, but again, this is kind
2733360	2738040	of like, uh, kind of like, uh, a paradox in the sense that, you know, it's absurd, because if
2738040	2744320	McAfee uses that, and I can pretty much intercept their calls and get on top, or, or
2744320	2749660	reroute them to the bottom, then it's really useless. Any further questions? Because I'm
2749660	2765250	getting the, sort of like Neustein. So, yeah. Right there. Okay, the question is, if I'm
2766430	2771230	intercepting a WSP receive, if I'm intercepting an SSL socket, would it be encrypted or not?
2771230	2775490	And yes, it would be encrypted, because I'm essentially getting it as it came on the
2775490	2781610	network. So, this enables you to play middleman, but only middleman, you know, post SSL, or
2781610	2786690	post encryption. Which is, as I've stated, the proper workaround, the proper mitigation to
2786690	2791430	that, would be to always use SSL and so forth. However, bear in mind, that nothing is
2791430	2796350	preventing the, uh, application from also, you know, trying to forge certificates and do any
2796350	2801530	type of de-sniff type man in the middle, which would work here. Okay? So, just to conclude,
2801530	2807590	before I'm, uh, kicked out violently. Okay? So, that was the demo. The lesson to be learned,
2807590	2812370	the thing you need to carry home from this, is that no matter what you do, no matter how you
2812370	2817530	code your application, the beauty of Winsock is in transparency. However, this is a double
2817530	2823730	edged sword, because obviously, as transparent as it is, it enables attackers to subvert either
2823730	2829550	client sockets, server sockets, whatever. Now, it's also important to emphasize that this
2829550	2836110	was originally intended for good uses. Namely, implementing an application type firewall,
2836110	2842510	application layer firewall. We mentioned McAfee, and, of course, we saw where that got.
2842690	2847790	Um, transparently add encryption. This was well before the days of IPsec. We're talking about
2847790	2853750	98, before IPsec was a fully robust protocol, as it is now. And nowadays, IPsec is handled, of
2853750	2859850	course, in the kernel level. Uh, enforce quality of service. Yeah, right. Uh, support new
2859850	2865210	protocols. This is also another nifty functionality. You can essentially support IPv6 by
2865210	2869790	it, although it's supported already. You can support IPv9, you can support pretty much any
2869790	2876190	other custom protocol over a raw socket. And patch content on the fly, which, like I said,
2876190	2881410	Google Desktop actually do. Whether it's a legitimate use or an illegitimate use remains to
2881410	2887670	be seen. However, the much better chaotic uses would be to patch content on the fly in the
2887670	2894010	illegitimate sense. And again, we're talking about rewriting webpages, rewriting IMs, uh,
2894010	2898370	doing a lot of other nifty stuff, which I will not disclose here. Um, obtain connection
2898370	2903570	statistics, URLs, etc, etc. Most of the spyware applications do exactly that. They put
2903570	2909170	themselves in so as to gather your statistics. This was what the CASA spyware did. Eavesdropping
2909170	2915590	on any type of connection, but again, non-SSL ones. And, uh, rerouting connections, that is
2915590	2920370	just hijacking the sockets, which is really an amazing thing. Because an application opens a
2920370	2925730	socket and calls connect. And once it does that, then, you know, the worst that can happen
2925730	2930610	it'll, it's gonna call get peer adder. But you can reroute connect and you can also reroute
2930610	2935090	get peer adder. So, you know, whatever the application thinks it's doing, whatever,
2935090	2940250	wherever it's, it's actually thinking that it's connecting to, it has no real significance
2940250	2945190	here because you can do whatever you want with it. So, uh, all that in mind, the demo, like
2945190	2951150	I said, is part of the platform SDK. Uh, you're welcome to drop a line to, uh, this address
2951150	2957350	right here and if you need, you know, the demo with the actual, uh, explanation on what I did,
2957350	2964990	where I did and so forth, then it will be supplied, of course. Any further questions? Okay, peace.