[00:03.420 --> 00:12.940] Hi everyone, thanks for attending. My name is Jonathan and the topic of my talk is going to be [00:12.940 --> 00:17.940] about the dark side of Winsock, which is essentially all the under-the-hood functionality that you [00:17.940 --> 00:24.300] have inside Winsock, inside the Windows TCPIP stack, which unfortunately, even though it's [00:24.300 --> 00:30.960] there and it's publicly available, it is somewhat undocumented and the only people to really [00:30.960 --> 00:36.900] use it are the bad guys, namely people who want to do rootkits, who want to do spyware, etc. [00:37.440 --> 00:44.560] Now I find myself somewhat inclined to start with the preamble here. This is not some type of [00:44.560 --> 00:50.520] vulnerability issue or not some type of any zero-day exploit, so if any of you are expecting [00:50.520 --> 00:55.400] that, it's probably not the right place to be. What this is, however, is a discussion on [00:55.400 --> 01:02.540] functionality which, like I said, is in there and it's mostly... well, mostly the only really [01:02.540 --> 01:07.700] good uses, as you'll see, are the insidious ones, namely the ones that aren't really designed [01:07.700 --> 01:15.100] to happen. Things such as usurping connections, rerouting connections, connection monitoring, [01:15.100 --> 01:22.740] etc, etc. Now it is assumed that you guys have had some experience with Winsock before. [01:22.740 --> 01:30.460] How many of you have actually coded in Windows for Winsock? Okay, well, okay, so as I was, [01:30.460 --> 01:34.480] you know, I kind of suspected that, so we'll start with a brief intro that kind of has the [01:34.480 --> 01:38.920] nomenclature and kind of has like the basic terminology, so those of you who are fairly new [01:38.920 --> 01:44.420] to this will be able to sort of like keep afloat. And then we'll get into the code. Now the [01:44.420 --> 01:48.680] code itself that I'll be demonstrating is all fully annotated, you've got that on the CD. [01:48.680 --> 01:55.980] On the CD you have a PDF of my talk, which, contrary to other PDFs, it's not just the slides, [01:55.980 --> 02:00.580] it's also the notes pages. So you'll be able to have the full source code, everything is there. [02:00.860 --> 02:06.740] Furthermore, my demo, which I'm going to run shortly, is based on a public demo, which is [02:06.740 --> 02:11.820] Intel's and Microsoft's code, so it's like fully open source and nothing too new there. [02:12.120 --> 02:17.300] So, we start with the introduction, and some of you may already know this, and I'm actually [02:17.300 --> 02:22.820] hoping most of you know this, but it's just sort of like the basic terms we'll be using. [02:23.000 --> 02:28.460] So, as you all know, IP communications are usually based over what's known as sockets. [02:28.480 --> 02:35.420] Sockets were something that essentially are meant to abstract sort of like what you'd have [02:35.420 --> 02:39.680] with file descriptors, only in this case it would be network descriptors. The idea is fairly [02:39.680 --> 02:45.080] simple, the application would open a socket and would just send and receive data as it would [02:45.080 --> 02:50.060] with any other file descriptor. This could be using receive, send calls, etc, etc. And there [02:50.060 --> 02:56.260] you'd also have some other APIs, which are essentially get peer and get adder info and so [02:56.260 --> 03:01.680] forth, which are meant to be socket specific and to enhance these descriptors so as to [03:01.680 --> 03:07.680] accommodate all types of TCP and UDP based needs. Now, the application itself is somewhat [03:07.680 --> 03:12.240] agnostic in the sense that for it, it's just another file descriptor. Those of you who may [03:12.240 --> 03:16.640] have some Unix background know that sockets and file descriptors in Unix are one and the [03:16.640 --> 03:20.920] same, pretty much. So you can, you know, you have the very same API. In Windows, what [03:20.920 --> 03:25.640] happens is that you have the Winsock, which I'll be describing shortly, which takes the [03:25.640 --> 03:30.380] sockets just a bit further and gets you a lot of added functionality. Now the important [03:30.380 --> 03:34.460] thing to emphasize is that the application would read and write just with any other file [03:34.460 --> 03:39.680] descriptor, so what would happen essentially is that all the fragmentation and [03:39.680 --> 03:44.920] encapsulation and getting the IP header and the TCP header, UDP, whatever it is, is basically [03:44.920 --> 03:49.000] handled transparently by the OS, which is really good news for a lot of application [03:49.000 --> 03:55.340] developers because they just work transparently and just don't care about whatever IP issues [03:55.340 --> 04:00.100] or TCP and so forth issues that might arise. Now what I'm going to demonstrate to you works [04:00.100 --> 04:06.660] with pretty much all sockets of all types. It works with TCP, UDP, raw sockets as well, in [04:06.660 --> 04:11.620] case Microsoft hasn't crippled them completely in Service Pack 2, and also IPv6 sockets, [04:11.620 --> 04:17.600] which is really nifty. Now, the way it works is that Microsoft took the BSD model, which is [04:17.600 --> 04:23.340] your average libc type socket with all the rich API, and adapted it into something known as [04:23.340 --> 04:28.480] Winsock, which is basically Windows sockets. This went through several versions and [04:28.480 --> 04:33.880] revisions. We started with Winsock 1.x, which you're not going to see anyway because it's [04:33.880 --> 04:40.180] mostly like for Windows 3.11 and so forth. And Winsock 2 is basically your baseline today. [04:40.180 --> 04:47.640] That is to say it's present in Windows NT, it's present in Windows 2K, 2003, etc. And of [04:47.640 --> 04:55.660] course your XP. Now the major important issue with Winsock is that the migration from 1.x to 2.x [04:55.660 --> 05:00.400] added a host of new features. We're not going to be discussing those new features in length, [05:00.400 --> 05:05.380] but some of you may know that it provides for asynchronous calls and various function [05:05.380 --> 05:09.960] callbacks, which is really good if you're working in a multi-threaded environment and so forth. [05:10.080 --> 05:15.380] It works with overlapped IO, namely getting more than one process to listen on the same [05:15.380 --> 05:21.880] socket. And this is going to be the topic of our talk here, it provides something known as an [05:21.880 --> 05:26.860] LSP architecture, which is the layered service provider. This is going to be a very key and [05:26.860 --> 05:32.460] instrumental term for us, as this is essentially the core of the talk. This service provider [05:32.460 --> 05:41.820] interface is essentially giving you the architecture to hook any Winsock call by any process [05:41.820 --> 05:46.800] aside from certain system processes which bypass Winsock, we'll get into that in a second. [05:46.800 --> 05:52.840] But essentially any Winsock functionality you wish, well it can be anything from a get host [05:52.840 --> 05:58.400] by name, through of course sending and receiving in sockets and so forth, everything is pretty [05:58.400 --> 06:03.760] much hijackable in the sense that this is pretty much the equivalent of set windows hook that [06:03.760 --> 06:09.840] you'd have for general Windows API functions, only specific for the Windows platforms. Now [06:09.840 --> 06:15.120] this is really, really useful and we're going to be talking about some of the legitimate uses [06:15.120 --> 06:20.600] which as you'll see, there's quite a few legitimate uses, however we'll also see that the [06:20.600 --> 06:26.780] really important uses are those that are, so to speak, less useful for the good guys and mostly [06:26.780 --> 06:32.300] sort of like the covert or the black hat oriented uses. Now it's also important to say that [06:32.300 --> 06:36.480] like I said, this has been out there for about seven years now pretty much, my first [06:36.480 --> 06:43.580] encounter with that was like 1998 or so and it's really frightening to see that all this [06:43.580 --> 06:48.900] functionality is there, it's under the hood so your applications are fully agnostic, they have [06:48.900 --> 06:54.080] no idea that this functionality is there and yet spyware developers and other such [06:54.080 --> 06:59.480] application developers can pretty much inject whatever functionality they want and the [06:59.480 --> 07:05.440] application is none the wiser. So, getting into detail here, this little illustration here [07:05.440 --> 07:10.820] shows you pretty much what the Windows networking architecture is all about. Some of you [07:10.820 --> 07:15.040] may find this a bit familiar, for those of you who aren't, I'll just run a brief sort of [07:15.040 --> 07:20.840] like, uh, review of this. So, looking at this from several levels of abstraction here, oops, [07:20.840 --> 07:26.140] wait a second, that's Microsoft PowerPoint running bald on me. So, looking at this from [07:26.140 --> 07:31.760] several layers of abstraction, we can see the hardware down below. Now, no matter what [07:31.760 --> 07:37.140] hardware type you're using, whether you're using a wireless network or a wired Ethernet or [07:37.140 --> 07:42.140] even a modem, pretty much all your Windsock calls will eventually be rerouted over the [07:42.140 --> 07:48.060] hardware in a sort of, uh, device independent manner. The miracle that does this is [07:48.060 --> 07:52.720] something called the NDIS driver, which is the network driver interface specification. [07:52.720 --> 07:58.460] That's sort of like an abstract driver for any type of interface. Uh, in Unix terms, some of [07:58.460 --> 08:03.000] you may be, uh, aware of the ifconfig and the interface configuration. So, it's pretty much a [08:03.000 --> 08:08.480] port of the same idea in Windows terms. And the NDIS is essentially an abstract driver [08:08.480 --> 08:13.900] that works with pretty much all types of communication, uh, devices. These can be [08:13.900 --> 08:19.860] modems, these can be, uh, Ethernet cards, etc, etc. Following that, we have the TDI, which [08:19.860 --> 08:24.780] is a transport driver interface. That acts somewhat of a, uh, somewhat like a bridge in the [08:24.780 --> 08:30.960] sense that you have calls from user space going into kernel space through this TDI layer. [08:30.960 --> 08:37.600] Now, in user space, you mostly have either Windsock 2 for 99% of the applications or [08:37.600 --> 08:43.020] something known as NetBT, which is the NetBios over TCPIP transport. Some of you who might be [08:43.020 --> 08:48.920] familiar with a backslash backslash server, the SMB or CIFS notation, that's pretty much it. [08:48.920 --> 08:54.020] So, aside from the workstation and server service, which are core components of Windows, [08:54.020 --> 08:58.420] pretty much any other application would go through Windsock. And that's, that of course is [08:58.420 --> 09:02.440] what makes this all the more attractive to us. Now, as the applications go through [09:02.440 --> 09:08.040] Windsock, they are pretty much, uh, you know, they all work over the same API, which is the [09:08.040 --> 09:14.300] application programming interface. And that is the API that you link with Windsock or WS2 [09:14.300 --> 09:20.500] underscore 32 dot DLL and it gets you the functionality of the send receive and as well as a [09:20.500 --> 09:27.880] host of WSA calls. Namely, uh, WSA async select and others to name a few. Okay, so, you have [09:27.880 --> 09:33.560] all types of, uh, applications. They can be your browser, your FTP, naturally your IMs, [09:33.560 --> 09:39.260] probably go over that as well, uh, IRC, et cetera, et cetera. Now, this is sort of like the [09:39.260 --> 09:45.380] application type view that most programmers are familiar with. However, as it turns out, this [09:45.380 --> 09:51.140] is only half the picture. So if, as, if we try and look deeper, we see that we have this [09:51.140 --> 09:56.960] Windsock API layer, which is, again, the top interface, but we also see that we have a [09:56.960 --> 10:03.100] Windsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as [10:03.100 --> 10:08.700] service providers. Now, the term service provider, like I said, is a key term here because [10:08.700 --> 10:14.240] service providers are essentially either hardware types, namely, uh, you know, your network [10:14.240 --> 10:19.840] cards, et cetera, et cetera, or they could be software types as in software type drivers, [10:19.840 --> 10:24.860] which are mostly user mode drivers. Now, this is really important since it gives you the full [10:24.860 --> 10:30.800] functionality of packet inspection and whatever you want, but at the socket level. So [10:30.800 --> 10:35.780] essentially, from an OSI model perspective, we're working at layer 5, which is really quite [10:35.780 --> 10:41.080] the improvement over other types of, uh, sniffers and rootkits, which generally operate at a [10:41.080 --> 10:46.580] lower level and thus confine you to a packet view. So here you can actually hijack a [10:46.580 --> 10:51.160] socket and not really wonder as to whatever the breakdown of the packets is, because it [10:51.160 --> 10:56.720] doesn't really matter. Now, uh, essentially these providers are one of two classes. You have [10:56.720 --> 11:03.220] the transport providers, which as the name would imply, work with the data transport itself, [11:03.220 --> 11:08.660] namely the TCP and UDP transfers, et cetera. And you have the namespace providers, which [11:08.660 --> 11:14.260] work with all the, you know, get host by name, et cetera. Namely, if you want to look up any [11:14.260 --> 11:19.960] type of address, that address can be a NetBIOS name, it can be an SMB name, a CIFS name, [11:19.960 --> 11:25.040] et cetera. And this would imply, of course, that you need a mechanism to abstract that. And [11:25.040 --> 11:29.120] this is exactly what the namespace providers are all about. I'm gonna focus on the [11:29.120 --> 11:33.300] transport providers, because they are, of course, the, the sexier ones, in the sense that [11:33.300 --> 11:38.340] they actually get you to see some real data. Now, as the illustration also shows, all the [11:38.340 --> 11:44.520] providers would share the same API, the same top API, which is what I see here, what I [11:44.520 --> 11:49.240] marked here, as a transport SPI, that is the transport service provider interface. So [11:49.240 --> 11:53.920] whatever provider you're using, essentially all these providers must work pretty much the [11:53.920 --> 12:00.820] same way. Now, Winsock providers cannot normally be listed by applications, or at least [12:00.820 --> 12:06.040] they can be, but only if the application is actually aware of it. Microsoft has, as part of [12:06.040 --> 12:11.240] the platform SDK, which is part of the Visual Studio distributions, they have something [12:11.240 --> 12:17.860] known as an SPOrder.exe, which is a small executable, meant to show you the service [12:17.860 --> 12:25.060] provider, um, order, of course, and also it comes with a small DLL called SPOrder.dll. [12:25.260 --> 12:31.540] SPOrder.dll is a DLL we'll, we'll discuss shortly, it actually has the ability to not only [12:31.540 --> 12:36.600] show you the service providers, but actually shuffle them around as you see fit. And this [12:36.600 --> 12:42.290] type of shuffling around is exactly the hooking functionality. So going on to see a [12:42.290 --> 12:57.840] demo of what the service providers are like. Okay, so, autocomplete is not cooperating. So [12:57.840 --> 13:03.100] you have the SPOrder.exe, which shows you all the available service providers here. Now, [13:03.100 --> 13:09.300] my display is, um, particularly cluttered due to the fact that I have VMware here, which, [13:09.300 --> 13:13.660] uh, is pretty much all those global unique identifiers that you can see here, as well as [13:13.660 --> 13:19.180] another VPN solution, which opens up a, a, a, sort of like a virtual interface. But the [13:19.180 --> 13:24.100] core providers that you're likely to see are the ones you see here. There's one for the [13:24.100 --> 13:31.540] infrared, which is IRDA, there's one for basic TCPIP, there's one for UDPIP, there's one for [13:31.540 --> 13:38.080] raw sockets, and there's, uh, two of them for RSVP. RSVP is a quality of service [13:38.080 --> 13:43.580] protocol, which is generally supported, but never really used by Windows. Now, going [13:43.580 --> 13:49.140] into one of these, you can see that they essentially give you the complete information on [13:49.140 --> 13:55.700] the service provider, namely, which DLL is actually the one that provides the functionality, as [13:55.700 --> 14:00.640] well as a bunch of service flags, provider ID, which is a global unique identifier, et cetera, [14:00.640 --> 14:05.600] et cetera. The important stuff here that some of you programmers might recognize are the [14:05.600 --> 14:12.440] address family, the hex value 2, meaning AFINET, uh, there's also the socket type, which [14:12.440 --> 14:18.080] is, uh, SOCKSTREAM, and there's a protocol number, which is 6. 6, of course, for TCP. And [14:18.080 --> 14:24.460] naturally you'd have, uh, 17, or hex 11, for UDP. And so the way that works is that any [14:24.460 --> 14:31.120] time an application would request a type of socket to be created, which would be a SOCKSTREAM, [14:31.120 --> 14:36.860] and rather an AFINET, SOCKSTREAM, and a TCP, essentially, a TCP socket, what would happen [14:36.860 --> 14:45.000] here is that this call would be redirected over to MSWSOCK.DLL, where WINSOCK, or the WS232 [14:45.000 --> 14:50.520] DLL, is actually acting like a multiplexer. That is to say that it is one main interface under [14:50.520 --> 14:55.480] which you can have all types of various providers. Now, again, this would normally be the [14:55.480 --> 15:00.320] case with your average Windows, and the more interfaces you have and the more applications [15:00.320 --> 15:04.780] you have, the more of those providers you're likely to see. As for the name resolution [15:04.780 --> 15:10.180] providers, these are the namespace providers. You have your basic TCPIP, which is an [15:10.180 --> 15:16.460] interface to the DNS client service. You have NTDS, which is, of course, Active Directory. [15:16.560 --> 15:21.040] And you have, uh, network location awareness, which is something that, again, Microsoft [15:21.040 --> 15:28.340] supports, but never really works. So, you have all those. And, now comes the important part. [15:28.340 --> 15:33.640] The important part is that you can have, over these service providers, you can have a [15:33.640 --> 15:40.580] functionality that enables you to chain your own providers. That is to say, not just add a [15:40.580 --> 15:44.640] provider, and by doing so, you're going to have to essentially make the application aware [15:44.640 --> 15:49.600] of that provider, but you can pretty much hook your providers and install something known [15:49.820 --> 15:56.320] as a provider chain, which is really an amazing idea. Now, the original plan behind that [15:56.320 --> 16:02.160] was to support all types of NICE uses. NICE such as transparent encryption, such as [16:02.160 --> 16:07.120] quality of service, et cetera, et cetera. But the way that works is that most applications don't [16:07.120 --> 16:12.860] really use that functionality, and so it's just left there, but not really used in everyday [16:12.860 --> 16:19.140] terms. Now, the beauty of it is that you can chain any number of providers, and you can [16:19.140 --> 16:24.140] chain them in pretty much any order you want. That is to say that if you want to provide [16:24.700 --> 16:30.840] some, uh, encryption functionality, for example, or reroute everything, all types of, uh, [16:30.840 --> 16:36.340] data transparently over SSL or SSH or whatever other tunnel you want, you can pretty much [16:36.340 --> 16:42.240] install your provider, and then bump it to the top of the stack. So, any other application [16:42.240 --> 16:47.660] using the stack would essentially get directed to your provider first, and your provider [16:47.660 --> 16:52.700] would do whatever, and then follow down the chain, essentially progressing the API calls [16:52.700 --> 17:00.820] down the chain. Any questions thus far? Okay. So, the way it works is that your provider [17:00.840 --> 17:07.640] Winsock, the DLL itself, has several functions which are exported. Uh, I'm going to try this, [17:07.640 --> 17:14.420] the dump-in demo a bit clearer here, so you'll be able to see the font back there. So, uh, [17:14.420 --> 17:26.210] just looking through that... Okay, so what I'm doing now is I'm setting up the visual, [17:26.210 --> 17:31.290] uh, studio command line, uh, environment, so I can show you the dump-in command. And the [17:31.290 --> 17:36.170] way dump-in works is, as some of you may know, it gives you the DLL and shows you all the [17:36.170 --> 17:40.390] exported functions, or the imported functions, and so forth. So, what I'm going to do now is [17:40.390 --> 17:46.170] essentially look for an exported function list of Winsock, and focus on the specific [17:46.170 --> 17:53.350] service provider interface. To do that, what we'll do is just do dump-in slash exports, get the [17:53.350 --> 18:02.510] name of the, um, of the WS232, and since, essentially, Winsock exports, like, on average [18:02.510 --> 18:07.050] about 100 and something functions, I'm going to use the command line utility of grep to [18:07.050 --> 18:13.210] isolate only those important ones for our discussion. So, looking at that, you can see [18:13.210 --> 18:19.210] that you have these particular WSC functions. Now, again, those of you who might be working [18:19.210 --> 18:24.390] with Winsock on a daily basis know that Winsock usually exports the WSAs, which is for the [18:24.390 --> 18:29.550] Winsock API. The WSCs you see here are essentially all about the service provider [18:29.550 --> 18:34.510] interface and so forth. Now, the, they're probably, there's too many functions here to, to [18:34.510 --> 18:39.690] actually go over, but the ones of interest are essentially install provider and [18:39.690 --> 18:46.210] deinstall provider, which enables you to, of course, set your own LSP or remove your LSP, as [18:46.210 --> 18:52.990] well as install namespace, and for some weird reason, it's uninstall namespace, hinting that [18:52.990 --> 18:58.270] maybe this API was not really meant to be used, because it's not really standardized in that [18:58.270 --> 19:04.270] sense, as in uninstall and not deinstall. Now, all of these are also fully documented as part [19:04.270 --> 19:09.770] of the MSDN, but it's the kind of MSDN documentation that resides on, like, the fourth CD that [19:09.770 --> 19:15.670] nobody ever gets to, because it's, like, so obscure in the back. Okay, now, as it so [19:15.670 --> 19:20.770] happens, okay, these functions are readily exportable, and you can use them to do, uh, your [19:20.770 --> 19:26.990] own type of work, as I'll show, um, briefly in a demo. Now, this SP order DLL is an [19:26.990 --> 19:33.190] additional DLL that, as I said, works for, uh, rewriting the service provider order. And as the [19:33.190 --> 19:37.950] example here shows, this is a dump bin of the SP order DLL, and you have write namespace [19:37.950 --> 19:42.290] provider, uh, sorry, write provider order and write namespace order, which essentially [19:42.290 --> 19:47.490] enable you to shuffle around, as I've stated, and put your provider just in its right [19:47.490 --> 19:54.310] location. Now, a lot of spyware aware applications, uh, like AdAware and all types of, um, [19:54.310 --> 20:00.750] anti-spyware, essentially look for that DLL, and if that DLL is present on your operating [20:00.750 --> 20:05.770] system, then it's bad news. Then they normally flag it as spyware and so forth. Probably the [20:05.770 --> 20:11.770] best example of that was, uh, Kaza, the file sharing utility, that has SP order dot DLL [20:11.770 --> 20:18.870] bundled in. So when you install Kaza, you have this DLL somewhere on your system. Another, [20:18.870 --> 20:24.210] uh, interesting application to use this type of DLL is Google desktop. Uh, I don't know how [20:24.210 --> 20:29.170] many of you use Google desktop, but Google desktop has, uh, probably its niftiest feature is [20:29.170 --> 20:34.170] that after you install it, whenever you go into Google dot com, you suddenly get your own [20:34.170 --> 20:38.890] desktop there. You have, like, the ability to search Google, or to search your own desktop [20:38.890 --> 20:43.770] from the very same webpage. Now, obviously, that kind of functionality would imply that [20:43.770 --> 20:50.230] Google has a mechanism in your machine that can intercept the calls to Google dot com, [20:50.230 --> 20:55.450] and re- sort of, like, rewrite the page content on the fly. And that is exactly the [20:55.450 --> 20:59.890] functionality that I'm describing here. Namely, by installing their own provider and putting [20:59.890 --> 21:05.010] it in your machine, they can, uh, intercept the go- the calls to Google, but they can, of [21:05.010 --> 21:08.470] course, do whatever they want. That is to say that if they're not really playing by the [21:08.470 --> 21:13.130] rules, they can do a lot of other stuff as well with your machine. But then, I'm happy to [21:13.130 --> 21:17.110] see that not too many people use Google desktop here, because that's kind of, like, shady. [21:17.110 --> 21:24.010] Anyways, so going over that, uh, pro- probably the most interesting API call would be the [21:24.010 --> 21:31.470] WSCEnum protocols, which would be the API call that one would use as a setup to install [21:31.470 --> 21:38.130] their own provider. This, much like all the other WS, uh, enum functions, will enable you [21:38.130 --> 21:43.730] to, sort of, like, go over the protocols that are already in place, and provide for an [21:43.730 --> 21:48.610] enumeration of them. An enumeration, in our case, would be a pointer to an array of [21:48.610 --> 21:54.950] protocol infrastructures. Now, uh, you have a fully annotated example on the PDF, uh, in [21:54.950 --> 21:59.590] the PDF, so I won't really go into that. But the idea is fairly simple. Anybody can call [21:59.590 --> 22:05.710] this function and see what service providers are already there. And in many ways, this is [22:05.710 --> 22:10.310] pretty much the only mitigation against this type of attack. However, most applications [22:10.310 --> 22:15.190] don't really use that, and if anything, they would use the counterpart of this call, which [22:15.190 --> 22:21.070] would be the WSA enum protocols. And the difference between the A and the C is that the C [22:21.070 --> 22:26.550] can get all the protocols, whereas the A gets only the top layer ones. So if you're using [22:26.550 --> 22:31.510] yours in a chain, essentially you can remain hidden, which is, of course, bad news. So, [22:31.510 --> 22:37.030] going over that, we have the enum protocols just to see which protocols are there, and we [22:37.030 --> 22:41.690] naturally want to build our own service provider. Now, building a service provider is really [22:41.690 --> 22:47.510] fun. It's really easy, too, because as a baseline, you have the Microsoft Supply demo. So, I [22:47.510 --> 22:52.530] happen to have this demo right here, and I'm going to work with the actual Microsoft code. Uh, [22:52.530 --> 22:56.750] due to copyright restrictions, I haven't really bundled it or, you know, put it in a [22:56.750 --> 23:01.850] charge easy for you guys to use, but it's fairly simple to just get this code from, uh, the [23:01.850 --> 23:06.870] MSDN and just work and do the same modifications that I did right here. So, looking through [23:06.870 --> 23:14.720] that code, uh, let's start with, probably the DLL main would be a good point to start. So, [23:14.720 --> 23:21.780] launching Visual Studio just so we, we can see this type of DLL, then our service provider is [23:21.780 --> 23:24.960] just, just going to be another DLL. So, essentially, it has to follow the very same [23:24.960 --> 23:30.180] conventions. That is to say, it has to start with a DLL main, and the DLL main would work as [23:30.180 --> 23:35.920] pretty much all DLL mains work. That is, whenever an application would hook to us and would [23:35.920 --> 23:43.480] call us, uh, we would get the DLL process attached at the, uh, DW reason. And so, the way that [23:43.480 --> 23:49.540] works is, whenever a process attaches, I add this little addition here, which essentially [23:49.540 --> 23:55.600] doesn't do much. What it does is it just opens up a file name, okay? It readies a file name [23:55.600 --> 24:02.900] here with a, with an S print F, composed of sock debug as a prefix, and the current process [24:02.900 --> 24:08.220] ID embedded in there. The reason I do that is because, once I'll do that and, of course, run my [24:08.220 --> 24:13.620] applications, you'll see that each application, as it uses Winsock, will generate this type of [24:13.620 --> 24:18.840] file on the root of the C drive. Okay, and what it does here is that it just opens the files [24:18.840 --> 24:23.500] and pops a message box, and you will be able to see that message box. That message box, and [24:23.500 --> 24:29.300] any type of code that I run here, is run in the context of the calling process. So, while this [24:29.300 --> 24:33.660] is a somewhat innocuous example, and just, you know, only for demonstration purposes, I'll [24:33.660 --> 24:38.080] print out a lot of stuff, if I really wanted to, I could do whatever I wanted here. [24:38.080 --> 24:43.180] Essentially, I could load additional DLLs, as the comment says. I could decide that this [24:43.180 --> 24:48.600] particular process should not access the stack, and so forth. Now, to make matters even [24:48.600 --> 24:54.600] easier for the spyware people, this type of functionality can also be injected in the WSP [24:54.600 --> 25:01.680] startup call. The WSP startup, which is shown right here in the slide. So, WSP startup is [25:01.680 --> 25:06.620] essentially the counterpart to WSA startup. Those of you who may have been working with [25:06.620 --> 25:12.800] Windows know that each Windows application, as it starts, as it launches its Winsock [25:12.800 --> 25:18.180] functionality, has to start off by calling this function, the WSA startup. And what it does is [25:18.180 --> 25:23.420] that it requests a certain Winsock version, and requests certain capabilities. Now, the [25:23.420 --> 25:29.060] beauty of it is that, you know, most programmers just call WSA startup, check the return value, [25:29.060 --> 25:33.660] and naturally everything is just okay. However, these programmers are unaware that this [25:33.660 --> 25:39.040] essentially would call the WSP startup, which is our code. So, in our LSP, what we're [25:39.040 --> 25:44.480] gonna do is essentially implement a WSP startup, which will have our very own code in [25:44.480 --> 25:49.540] there. Now, looking at WSP startup, you can see that it has five parameters, as opposed to [25:49.540 --> 25:54.480] WSA, which has, of course, fewer parameters. The parameters of interest here are [25:54.480 --> 26:02.140] specifically the three last ones. We have the in-parameter LP protocol info, which states [26:02.140 --> 26:08.340] what type of functionality the application expects. Namely, are we expected to perform TCP [26:08.340 --> 26:14.820] or UDP or any type of other service? We further have something known as the up-call table, [26:14.820 --> 26:21.900] which is, by far, the most useful parameter here, which will enable us to have an array of, [26:21.900 --> 26:28.060] essentially, it's a pointer to an array of functions, and these functions are the already [26:28.060 --> 26:33.460] installed providers. So that means that if I want to hook, for example, send or receive, I don't [26:33.460 --> 26:38.440] really have to think about how I would implement send or receive, but rather I would implement [26:38.440 --> 26:42.880] them my own in sort of like a stub function, and later on just go on to call the up-call [26:42.880 --> 26:47.700] table. And the example will demonstrate that shortly. Finally, we have the only out parameter [26:47.700 --> 26:52.560] here of interest. The other one's really not interesting. The LP WSP data is really not [26:52.560 --> 26:59.040] interesting. But the LP PROC table here is our procedure call table, and that is essentially a [26:59.040 --> 27:04.260] pointer to all our functions. So whatever functions you choose to implement, you can pretty [27:04.260 --> 27:12.420] much set in this big structure there, and just call WSP startup, and returning from the call, [27:12.420 --> 27:17.160] you would pretty much produce your procedure table, and you'd be guaranteed that your [27:17.160 --> 27:22.900] applications, your rather, sorry, procedures would be called. Now those of you who may have [27:22.900 --> 27:27.360] been working in the Unix and Linux environment would know that in order to achieve that in [27:27.360 --> 27:33.920] Linux, you'd pretty much need to have any type of a kernel module inside the Linux kernel, [27:33.920 --> 27:38.380] for example, or any type of streams interface in Solaris, which would of course be a lot of [27:38.380 --> 27:43.180] hassle. But when it comes to Windows, all this is pretty much transparent to you. So, looking [27:43.180 --> 27:52.440] over the SPI CPP, which is the main file that has all the functions, let's just go over WSP [27:52.440 --> 28:01.180] startup. And you'll see that what Intel and Microsoft do here, this is again their demo, is [28:01.180 --> 28:07.660] that they simply implement this WSP startup call. The important thing here would be after [28:07.660 --> 28:14.620] initializing their own internal structure, would be, number one, to save the Winsock2 up [28:14.620 --> 28:19.660] call table. That is to say, save the actual implementations that are already out there, [28:19.660 --> 28:25.140] because we're going to need to call them as sort of a pass through. And once that's done, they [28:25.140 --> 28:30.380] do a lot of other startup code and so forth, and they get to the important portion of [28:30.380 --> 28:37.140] populating the procedure table. So, the procedure table is a structure, and it's as simple as [28:37.140 --> 28:41.880] it can get, because you'd have a structure of function pointers, and all you have to do is just [28:41.880 --> 28:46.100] hook your function pointer to the corresponding functionality that you want. And so once [28:46.100 --> 28:51.300] that's done, you can essentially hook all those calls. Now, just looking at one of those [28:51.300 --> 28:58.380] calls, say for example, WSP receive, which would be the counterpart of the WSA receive and [28:58.380 --> 29:04.660] so forth. Okay, so looking through that, at some point we'll get there. Yeah, okay, there [29:04.660 --> 29:12.520] it is. So, this is the WSP receive function, which is again, guaranteed to be called prior to [29:12.520 --> 29:17.580] the application actually getting any data. So, if Google, for example, wants to rewrite the [29:17.580 --> 29:22.280] content, this is exactly the function they'll hook. Now, again, I won't go over the numerous [29:22.280 --> 29:29.320] parameters here. The parameters of interest are obviously the socket in question, and a [29:29.320 --> 29:33.560] long pointer to the buffers. This would be an array of input buffers, and since we're [29:33.560 --> 29:38.360] passing an array by reference, we also have to piggyback the third parameter, which is the [29:38.360 --> 29:43.520] count of buffers, namely what is the size of said array. And so what I do in my little demo [29:43.520 --> 29:53.920] here is do a fairly simple function here, which would just go on and write to the debug [29:53.920 --> 29:59.940] file that it's intercepted a receive, and would simply go over the buffer, it's going over [29:59.940 --> 30:04.920] the entire array there, and simply printing out the buffers. Now, as far as a demo is [30:04.920 --> 30:10.280] concerned, this is really not the type of graphical pyrotechnic demo you'd imagine, because [30:10.280 --> 30:15.600] it also will intercept a lot of binary data. However, it does illustrate the point that the [30:15.600 --> 30:21.160] data can be intercepted and can be, of course, modified. If you want to, you can pretty [30:21.160 --> 30:27.380] much have any type of modification of those LP buffers, and you can inject your own [30:27.380 --> 30:32.960] buffers, you can put your data, you can log the data, and so forth. I, of course, chose just [30:32.960 --> 30:38.260] to log the data. Now, naturally, you do the same thing for WSP send, and a host of other [30:38.260 --> 30:44.140] functions, but that goes without saying. So, we have our DLL, and now the next place would [30:44.140 --> 30:51.100] be, the next step, sorry, would be to insert it. Okay, somehow get Winsock to recognize our [30:51.100 --> 30:56.580] service provider as a valid service provider. Now, bear in mind that this is something that [30:56.580 --> 31:02.760] has to be done outside the DLL, because your DLL can only intercept certain functions, but it [31:02.760 --> 31:08.300] cannot install itself. However, in order to install it, we have another call, which is a WSP [31:08.300 --> 31:15.200] install provider. This is a fairly simple call, where all you have to do is provide a [31:15.200 --> 31:21.240] global unique identifier, which is, of course, easy to just whip up for yourself, and you'd [31:21.240 --> 31:27.260] set up your own DLL path, and the type of protocols you support. That's all it takes. Now, [31:27.260 --> 31:32.240] your example should have, actually, I'll go to my source code here, just to demonstrate how [31:32.240 --> 31:38.140] simple it is. So, all you'd have to do is have a small executable file, like, say, this [31:38.140 --> 31:44.400] inst.lsp, which, again, is a verbatim copy of the Intel one. I didn't really do anything [31:44.400 --> 31:49.100] here, because this is the same generic code that would work with any service provider. And [31:49.100 --> 31:55.740] so, what it does here is that it has a little function called install my provider, wherein I [31:55.740 --> 32:02.860] populate the provider info, like so. I populate a lot of stuff. You'll also notice a nice [32:02.860 --> 32:08.100] little flag here called PFL hidden, which is this flag right here. Which is a really nice [32:08.100 --> 32:13.200] flag, because this actually tells Winsock, if anybody wants to enumerate this provider from [32:13.200 --> 32:18.960] the API level, keep it hidden. Which, you know, I don't really get the actual intended use of [32:18.960 --> 32:25.160] that, but whatever. Now, there's also another interesting copy here, which is security [32:25.160 --> 32:30.560] scheme, which enables you to have your own type of security for your provider, blah, blah, [32:30.560 --> 32:35.280] blah. Most of the time, you just do protocol none. So, essentially, I populate this [32:35.280 --> 32:41.160] provider, and I, of course, register it as a protocol provider for TCP. And once that's [32:41.160 --> 32:48.940] done, all I have to do is just call this WSP, sorry, WC install provider, and provide [32:48.960 --> 32:55.000] the name of LSP DLL. This is assumed to be a Windows system, which would be a problem if [32:55.000 --> 32:59.300] you're not an admin, but then again, you're going to have to be an admin to run this anyway. [32:59.320 --> 33:04.780] But you can also specify a full path here if you really want to. And so, I load the protocol [33:04.780 --> 33:11.740] info through the pointer, and once that's done, I pretty much guaranteed that my provider [33:11.740 --> 33:17.540] will be installed there. Now, let's go ahead and try and install that provider and see [33:17.540 --> 33:23.000] exactly what happens. Now, you'll notice that I already took the liberty of placing that [33:23.000 --> 33:31.140] little DLL here. That DLL is as compact as 81K. Actually, it's 80K or so. And the thing is, [33:31.140 --> 33:37.240] once that DLL is in place, all I have to do is call the inst LSP executable to do the rest. [33:37.240 --> 33:42.660] Now, before I do that, I want to fire up RegMon. RegMon is a tool by Sysinternals, which [33:42.660 --> 33:48.960] I'm sure most of you know, and that enables us to hook all types of registry calls. And the [33:48.960 --> 33:54.100] important thing here is that all this type of functionality of installing providers or [33:54.320 --> 33:59.380] de-installing providers is essentially all registry-based. So, if you really want to [33:59.380 --> 34:04.980] bypass this type of DLL with enumerating the provider order and so forth or installing your [34:04.980 --> 34:09.700] own providers, all you have to do is directly access the registry, which is, of course, [34:09.700 --> 34:14.900] fairly simple. So, what I'm going to do now is I'm going to launch RegMon. And, naturally, [34:14.900 --> 34:20.540] all is silent because my process hasn't started yet. And now I'm going to run this inst LSP. [34:20.620 --> 34:26.100] And as I do, you can see that it's scanning the installed providers and then going on to [34:26.100 --> 34:32.520] install my provider on top of all the rest. Now, again, since this is a rather crude demo, I [34:32.520 --> 34:37.700] didn't really go to any, you know, pains of just looking for the right providers. I just [34:37.700 --> 34:41.980] said, go ahead and install it over all the providers. But it's fairly simple to just decide [34:41.980 --> 34:47.220] that you want a very specific provider. Now, you can also see that there's a lot of registry [34:47.220 --> 34:53.820] action here. And, specifically, all the registry action is focused on one specific branch, [34:53.820 --> 35:01.060] which is HKEY-LOCAL-MACHINE-SYSTEM, CURRENT-CONTROL-SET-SERVICES, and WINSOC2. So, [35:01.060 --> 35:07.000] firing up RegEdit, just to see what it's like there, you'll see, and it's already in my [35:07.000 --> 35:11.720] favorites, you'll see that WINSOC2 parameters has the namespace catalog, which is for the [35:11.720 --> 35:16.500] namespace providers, and the protocol catalog, which is for the transport providers. Now, [35:16.500 --> 35:21.280] again, Microsoft is inconsistent. They don't really call the things by the same name all the [35:21.280 --> 35:27.120] time, but that's, you know, beside the point here. So, under the namespaces, you have all [35:27.120 --> 35:31.820] types of catalog entries. And, as you can see, you have the same catalog entries that we [35:31.820 --> 35:38.820] could have seen under the SP order executable, namely the NTDS, the plain TCPIP, and so forth. [35:38.820 --> 35:44.280] And, when it comes to the protocol catalog here, everything gets really messy, because one [35:44.280 --> 35:50.160] would think that you'd get these nice type of keys and values, but here you only have a [35:50.160 --> 35:56.260] packed catalog item, which is a blob of binary data that if you go into, you'll actually see [35:56.380 --> 36:01.760] makes a lot of sense. This is a protocol info structure that has been overlaying into the [36:01.760 --> 36:07.260] registry as raw binary data. Now, you'll also note that once I put in my layered service [36:07.260 --> 36:12.340] provider, the number of providers here has risen from the 30-something that it should be [36:12.340 --> 36:18.080] to around 57, because that's where my mine is hooking. So, with all that in mind, the stage [36:18.080 --> 36:22.900] is set, and I can now run any application of my choice, as I'll shortly do, and you'll see [36:22.900 --> 36:28.480] that as the applications run, I'll get a nice little message box, and I'll get a full log of [36:28.480 --> 36:51.740] whatever. Any questions thus far? Yeah? Well, no, that would go with the namesake provider [36:51.740 --> 36:56.400] with the TCPIP one, which I'm not really discussing how to hook that. If you really wanted [36:56.400 --> 37:02.560] to, you could also hook the loopback address as well, so as people would, you know, go ahead [37:02.560 --> 37:08.460] and try to resolve, and get the 127.0.0.1, because it's in your host file, but then the [37:08.460 --> 37:13.960] application would get that first. So you'd be able to actually re-write the result of the [37:13.960 --> 37:19.120] NS lookup, or whatever DNS packet should have been there, and you'd be able to just put in [37:19.120 --> 37:23.480] any address of your own, which is of course, you know, very nice for our purposes. [37:23.500 --> 37:29.280] Furthermore, the Google desktop would then have to connect to the loopback interface, and [37:29.280 --> 37:35.100] that would be a transport type action, and you'd be able to get the connect. You'd be able [37:35.100 --> 37:41.820] to hook the connect call, and see a connect to 127.0.0.1, to whatever port Google is using, [37:41.820 --> 37:47.000] and of course redirect it. So simply, you know, simply providing your workaround wouldn't [37:47.000 --> 37:51.180] really work, because this functionality is actually stronger than that. Any other [37:51.180 --> 38:01.700] questions? Yeah, back there. Say what? Oh, you can't. The beauty of it, okay, so the [38:01.700 --> 38:06.240] question is, say I want to put in my own provider, how can I ensure that my provider is [38:06.240 --> 38:12.420] the topmost? Uh, in, you know, in two words, you can't. Because any provider that gets [38:12.420 --> 38:18.620] installed after you, can pretty much re-route, re-write, sorry, the stack as they see fit. [38:18.620 --> 38:23.280] So you'd have the protocol chain, you'd think you're there first, but the whole beauty of [38:23.280 --> 38:27.680] this mechanism is that it's so transparent, that at any other point in time, somebody can [38:27.680 --> 38:33.380] get ahead, sort of like bump in front of you, and hook you as well. So that's of course, you [38:33.380 --> 38:39.760] know, good news or bad news, depending on your perspective here. Yeah, but that's not to [38:39.760 --> 38:44.060] guarantee that somebody else, some other application starting up after you, they could [38:44.060 --> 38:48.140] enumerate the order as well, and they could re-write the order as they see fit. So [38:48.140 --> 38:52.640] essentially, this is somewhat of a limbo, in the sense that you have a given order, but [38:52.640 --> 38:57.380] the enum protocols will only provide you with a snapshot of the current order, and no [38:57.380 --> 39:01.920] guarantee of any other application coming after you. You cannot decide you want to be the [39:01.920 --> 39:07.940] topmost protocol in the chain, and that's it. Further, when any other protocol gets bumped [39:07.940 --> 39:15.160] in, you wouldn't know, you have no indication whatsoever as to your position. Yeah, you'd [39:15.160 --> 39:20.820] still be, well, again, okay, so, right, okay, so the question is, would I still be hooked? [39:20.820 --> 39:25.100] And the answer is yes and no, because yes, I would be hooked in the sense that I'd have my [39:25.100 --> 39:30.580] own place in the protocol chain. I don't mind the fish. So I'll have my own place in the [39:30.580 --> 39:37.440] protocol chain, yes, but if any other topmost provider would want to hold that call in the [39:37.440 --> 39:41.360] chain and not propagate it, not play by the rules, they'd be able to intercept it and [39:41.360 --> 39:47.900] essentially block it. So as I place my own provider, I can either choose to go ahead and [39:47.900 --> 39:51.940] forward the call, or I can say no, I want to handle the call, and I don't want to propagate [39:51.940 --> 40:08.470] it further. You can change the providers at any time, okay? Using the provider order, the [40:08.470 --> 40:14.010] WSPRite provider and so forth, you can pretty much redo the whole ordering as you wish, [40:14.010 --> 40:23.290] because essentially all it changes is some internal structure in Winsock. Oh yeah, of [40:23.290 --> 40:27.090] course, of course, but then again, there's no guarantee that you will be called again, [40:27.090 --> 40:31.350] because again, let's assume for a sake that I have my own custom provider, and I want to [40:31.350 --> 40:36.430] make sure that nobody gets on top of me. So, assuming whoever gets on top of me does [40:36.430 --> 40:42.430] forward the call further, yes, I will be called. But if that somebody takes the express [40:42.430 --> 40:47.610] route and just, you know, decides to bypass whatever other calls, then essentially my [40:47.610 --> 40:53.950] provider would still be there, but would never be called. Yeah, the order is in the [40:53.950 --> 40:58.230] registry, and of course, in enum protocols would work as well. You could enum the [40:58.230 --> 41:02.450] protocol so as to get it in a nice little array, but the order is right here. Okay, this is [41:02.450 --> 41:06.810] pretty much the order, I mean, you can pretty much see that the key names are the ordinals, [41:06.810 --> 41:17.090] so it doesn't get too complex than that. The route by sysinternals, I'm not familiar with [41:17.090 --> 41:21.710] the specific one, but I can tell you that a lot of other rootkit detectors don't really go [41:21.710 --> 41:27.550] that far. Now it's important to just define the terms here. This is perfect user mode [41:27.550 --> 41:32.770] action. This is not a rootkit in the sense of like a, a kernel mode rootkit, because that [41:32.770 --> 41:38.030] would be hijacking TCPIP.sys itself. And that, you know, that, that, there's nothing that [41:38.030 --> 41:43.270] can be done against that. But the beauty of it is that this is full user mode, and in that [41:43.270 --> 41:47.550] sense it's a lot easier, not to mention you can code sloppy and not risk a blue screen of [41:47.550 --> 41:51.910] death, which is of course a nice little added benefit there. Okay, so, uh, since I'm getting [41:51.910 --> 41:57.790] the, uh, noose, I'll just, uh, run a few applications here. So let's just start, you know, [41:57.790 --> 42:03.230] let's just run Firefox and a bunch of others. Oh, and as you can see, Firefox is loading, and [42:03.230 --> 42:08.650] already I have a sock debug of 1148, which is of course the process ID of Firefox. So [42:08.650 --> 42:13.070] Firefox is running, and this is the Mozilla start page, and I can do all sorts of, you know, [42:13.070 --> 42:19.490] other, whatever. And see, I can get any types of pages I want, and everything is really nice [42:19.490 --> 42:27.830] and dandy. But behind the scenes, I have this little, uh, sock debug, 1148. And of course I [42:27.830 --> 42:32.650] could also fire up my messenger, or my Yahoo, or whatever, and I'll do that just briefly [42:32.650 --> 42:39.130] here. Uh, so as, as I fire up Yahoo, I should be getting the message box sometime soon. Uh, [42:39.130 --> 42:42.870] yeah, just, you know, Yahoo's a bit slow. Okay, now you'll notice this is a really [42:42.870 --> 42:47.830] nice, uh, effect, that I get the message box in the context of the Yahoo process, so I get [42:47.830 --> 42:53.590] their window class, which is a nice, uh, not really nice, but, purple, whatever. Okay? And [42:53.590 --> 42:57.950] so, this is connecting, and everything is cool and nice. You can also see that it's hooking [42:57.950 --> 43:04.750] another call, and, uh, whatever, they'll just let it run. And, you know, ditto for messenger. [43:04.750 --> 43:11.650] So if I'll just run here, run messenger, uh, yeah, whatever, yeah, yeah, you can, okay, [43:11.650 --> 43:16.610] whatever, that's a student of mine, disregard that. Okay? So, uh, again, so I can run that [43:16.610 --> 43:21.610] with messenger and so forth, and all these SOG debug files are right here, so let's just go [43:21.610 --> 43:29.450] over the 1148 one, and we'll be able to see that, again, this is very crude, so I get a lot [43:29.450 --> 43:35.090] of seemingly junk-looking data. This junk-looking data is, is all types of either gzip [43:35.090 --> 43:41.430] compressed HTTP data, or, uh, all sorts of binary data, such as images and, and so forth. [43:41.430 --> 43:47.510] If I scroll down, I should be able to see some HTTP requests right here. Okay, so this is the [43:47.510 --> 43:52.650] get of header tab dot gif, and naturally, you get all types of this, this, for example, is a [43:52.650 --> 43:57.490] PNG, you can pretty much see the header here, that's a dead giveaway, uh, as well as a bunch [43:57.490 --> 44:02.630] of others, et cetera, et cetera, the HTTP replies and so forth. Now, again, I want to [44:02.630 --> 44:07.990] emphasize one thing, this, again, as a demo, is not as half as fancy as it can be, because [44:07.990 --> 44:13.070] with a little if there, I could have simply rerouted Mozilla to some other site, or I could [44:13.070 --> 44:18.770] have modified whatever Mozilla was displaying. Now, another disclaimer here, is that HTTPS [44:18.770 --> 44:23.530] type connections are unaffected by that. Fortunately, there are other ways to hook HTTPS, [44:23.530 --> 44:28.650] which are beyond my scope here, but I'm just saying that if you do use HTTPS, you're fine. [44:28.650 --> 44:33.730] However, when it comes to all types of other functionality, messenger, um, email, [44:33.730 --> 44:43.430] whatever, everything is pretty much in the clear. Okay? Any questions? Yeah. Yeah, with [44:43.430 --> 44:49.510] NetBT you can, although it's, well, again, that, let's define NetBT. If the process that [44:49.510 --> 44:55.850] runs the NetBT request has launched after you have put in your provider, then yes, you [44:55.850 --> 45:01.230] can. And if you get your provider into the Windows startup, then yes, you can. Okay? [45:01.230 --> 45:06.770] However, some functionality you still won't get, namely the, uh, the Winsock bypass [45:06.770 --> 45:12.090] functionality that sometimes a server service does. Okay? In order to, to gain efficiency, it [45:12.090 --> 45:15.950] doesn't go through a user mode DLL, because it doesn't make sense, you know? Okay, so you [45:15.950 --> 45:24.490] can hijack some of the functionality, although not all. Any other questions? Yeah. Uh, no, [45:24.490 --> 45:28.850] zone alarm actually, as far as I know, go into the TDI. This is what McAfee does, though. [45:28.850 --> 45:34.150] McAfee, the personal firewall, uh, does do, uh, they do do that. So, but again, this is [45:34.150 --> 45:38.310] kind of like, uh, kind of like, uh, a paradox in the sense that, you know, it's absurd, [45:38.310 --> 45:44.450] because if McAfee uses that, and I can pretty much intercept their calls and get on top, [45:44.450 --> 45:50.310] or, or reroute them to the bottom, then it's really useless. Any further questions? [45:50.310 --> 46:04.630] Because I'm getting the, sort of like, news time. So, yeah, right there. Okay, the [46:04.630 --> 46:11.350] question is, if I'm intercepting a WSP receive, if I'm intercepting an SSL socket, would it be [46:11.350 --> 46:15.710] encrypted or not? And yes, it would be encrypted, because I'm essentially getting it as it [46:15.710 --> 46:21.450] came on the network. So, this enables you to play middleman, but only middleman, you know, [46:21.450 --> 46:26.930] post-SSL or post-encryption, which is, as I've stated, the proper workaround, the proper [46:26.930 --> 46:31.830] mitigation to that would be to always use SSL and so forth. However, bear in mind that [46:31.830 --> 46:36.670] nothing is preventing the, uh, application from also, you know, trying to forge certificates [46:36.670 --> 46:41.910] and do any type of de-SNF type man-in-the-middle, which would work here. Okay? So, just to [46:41.910 --> 46:48.030] conclude, before I'm, uh, kicked out violently, okay? So, that was the demo. The lesson to be [46:48.030 --> 46:52.850] learned, the, the thing you need to carry home from this, is that no matter what you do, no [46:52.850 --> 46:58.010] matter how you code your application, the beauty of Winsock is in transparency. However, this [46:58.010 --> 47:03.790] is a double-edged sword, because obviously, as transparent as it is, it enables attackers to [47:03.790 --> 47:09.190] subvert either client sockets, server sockets, whatever. Now, it's also important to [47:09.190 --> 47:15.410] emphasize that this was originally intended for good uses. Namely, implementing an [47:15.410 --> 47:21.130] application type firewall, application layer firewall. We mentioned McAfee, and, ah, of [47:21.130 --> 47:26.630] course, we, we saw where that got. Um, transparently add encryption. This was well before [47:26.630 --> 47:31.970] the days of IPsec. We're talking about 98, before IPsec was a fully robust protocol, as it is [47:31.970 --> 47:37.610] now. And nowadays, IPsec is handled, of course, in the kernel level. Uh, enforce quality of [47:37.610 --> 47:44.070] service. Yeah, right. Uh, support new protocols. This is also another nifty functionality. You [47:44.070 --> 47:49.570] can essentially support IPv6 by it, although it's supported already. You can support IPv9, [47:49.570 --> 47:55.310] you can support pretty much any other custom protocol over a raw socket. And patch content [47:55.310 --> 48:00.550] on the fly, which, like I said, Google Desktop actually do. Whether it's a legitimate use or an [48:00.550 --> 48:07.070] illegitimate use remains to be seen. However, the much better chaotic uses would be to patch [48:07.070 --> 48:11.870] content on the fly in the illegitimate sense. And again, we're talking about rewriting web [48:11.870 --> 48:17.870] pages, rewriting IMs, uh, doing a lot of other nifty stuff, which I will not disclose here. [48:17.990 --> 48:22.230] Um, obtain connection statistics, URLs, et cetera, et cetera. Most of the spyware [48:22.230 --> 48:27.070] applications do exactly that. They put themselves in so as to gather your statistics. This was [48:27.070 --> 48:33.750] what the CASA spyware did. Eavesdropping on any type of connection, but again, non-SSL ones. [48:33.750 --> 48:38.710] And, uh, rerouting connections, that is just hijacking the sockets, which is really an [48:38.710 --> 48:44.510] amazing thing. Because an application opens a socket and calls connect. And once it does [48:44.510 --> 48:49.630] that, then, you know, the worst that can happen, it'll, it's gonna call get peer adder. But [48:49.630 --> 48:53.590] you can reroute connect and you can also reroute get peer adders. So, you know, whatever the [48:53.590 --> 48:58.370] application thinks it's doing, whatever, wherever it's, it's actually thinking that it's [48:58.370 --> 49:02.870] connecting to, it has no real significance here because you can do whatever you want with [49:02.870 --> 49:08.670] it. So, uh, all that in mind, the demo, like I said, is part of the platform SDK. Uh, you're [49:08.670 --> 49:15.050] welcome to drop a line to, uh, this address right here. And if you need, you know, the demo [49:15.050 --> 49:20.510] with the actual, uh, explanation on what I did, where I did, and so forth, then it will be [49:20.510 --> 49:25.890] supplied, of course. Any further questions? Okay. Peace.