 Hi everyone, thanks for attending. My name is Jonathan and the topic of my talk is going to be about the dark side of Winsock, which is essentially all the under the hood functionality that you have inside Winsock, inside the Windows TCP AP stack, which unfortunately, even though it's there and it's publicly available, it is somewhat undocumented and the only people to really use it are the bad guys, namely people who want to do rootkits, who want to do spyware, et cetera, et cetera. Now I find myself somewhat inclined to start with the preamble here. This is not some type of vulnerability issue or not some type of any, you know, zero day exploit, so if any of you are expecting that, it's probably not the right place to be. What this is, however, is a discussion on functionality which, like I said, is in there and is mostly, well mostly the only really good uses as you'll see are the insidious ones, namely the ones that aren't really designed to happen, things such as usurping connections, rerouting connections, connection monitoring, et cetera, et cetera. Now it is assumed that you guys have had some experience with Winsock before. How many of you have actually coded in Windows for Winsock? Okay, well, okay, so as I was, you know, I kind of suspected that, so we'll start with a brief intro that kind of has a nomenclature and kind of has like the basic terminology, so those of you who are fairly new to this will be able to sort of like keep afloat and then we'll get into the code. Now the code itself that I'll be demonstrating is all fully annotated, you've got that on the CD. On the CD you have a PDF of my talk which, contrary to other PDFs, it's not just the slides, it's also the notes pages. So you'll be able to have the full source code, everything is there. Furthermore, my demo which I'm going to run shortly is based on a public demo which is Intel's and Microsoft code, so it's like fully open source and nothing too new there. So we start with the introduction and some of you may already know this and I'm actually hoping most of you know this, but it's just sort of like the basic terms we'll be using. So as you all know, IP communications are usually based over what's known as sockets. Sockets were something that essentially are meant to abstract sort of like what you'd have with file descriptors, only in this case it would be network descriptors. The idea is fairly simple, the application would open a socket and would just send and receive data as it would with any other file descriptor. This could be using receive, send calls, et cetera, et cetera. And you'd also have some other APIs which are essentially get peer and get adder info and so forth which are meant to be socket specific and to enhance these descriptors so as to accommodate all types of TCP and UDP based needs. Now the application itself is somewhat agnostic in the sense that for it is just another file descriptor. Those of you who may have some UNIX background know that sockets and file descriptors and UNIX are one and the same pretty much. So you can, you know, you have the very same API. In Windows what happens is that you have the Winsock which I'll be describing shortly which takes the sockets just a bit further and gets you a lot of added functionality. Now the important thing to emphasize is that the application would read and write just with any other file descriptor. So what would happen essentially is that all the fragmentation and capsulation and getting the IP header and the TCP header UDP whatever it is is basically handled transparently by the OS which is really good news for a lot of application developers because they just work transparently and just don't care about whatever IP issues or TCP and so forth issues that might arise. Now what I'm going to demonstrate to you works with pretty much all sockets of all types. It works with TCP UDP raw sockets as well in case Microsoft hasn't crippled them completely in service back to and also IPv6 sockets which is really nifty. Now the way it works is that Microsoft took the BSD model which is your average libc type socket with all the rich API and adapted it into something known as Winsock which is basically Windows sockets. This went through several versions and revisions. We started with Winsock 1.x which you're not going to see anyway because it's mostly like for Windows 3.11 and so forth. And Winsock 2 is basically your baseline today. That is to say it's present in Windows NT, it's present in Windows 2K, 20.03, etc. and of course your XP. Now the major important issue with Winsock is that the migration from 1.x to 2.x added a host of new features. We're not going to be discussing those new features length but some of you may know that it provides for asynchronous calls and various function callbacks which is really good if you're working in a multi-threaded environment and so forth. It works with overlapped IO namely getting more than one process to listen on the same socket and this is going to be the topic of our talk here. It provides something known as an LSP architecture which is the layered service provider. This is going to be a very key and instrumental term for us as this is essentially the core of the talk. This service provider interface is essentially giving you the architecture to hook any Winsock call by any process aside from certain system processes which bypass Winsock. We'll get into that in a second. But essentially any Winsock functionality you wish, it can be anything from a get host by name through of course sending and receiving in sockets and so forth. Everything is pretty much hijackable in the sense that this is pretty much the equivalent of set Windows hook that you'd have for general Windows API functions only specific for the Windows platforms. Now this is really, really useful and we're going to be talking about some of the legitimate uses which as you'll see there's quite a few legitimate uses. However, we'll also see that the really important uses are those that are so to speak less useful for the good guys and mostly sort of like the covert or the black hat oriented uses. Now it's also important to say that like I said this has been out there for about seven years now pretty much. My first encounter with that was like 1998 or so and it's really frightening to see that all this functionality is there. It's under the hood so your applications are fully agnostic. They have no idea that this functionality is there and yet some of the spyware developers and other such application developers can pretty much inject whatever functionality they want and the application is none the wiser. So getting into detail here, this little illustration here shows you pretty much what the Windows networking architecture is all about. Some of you may find this a bit familiar for those of you who aren't. I'll just run a brief sort of like review of this. So looking at this from several levels of abstraction here, oops wait a sec that's Microsoft PowerPoint running balled on me. So looking at this from several layers of abstraction, we can see the hardware down below. Now no matter what hardware type you're using, whether you're using a wireless network or a wired ethernet or even a modem, pretty much all your Winsau calls will eventually be rerouted over the hardware in a sort of device independent manner. The miracle that does this is something called the end disk driver which is the network driver interface specification. That's sort of like an abstract driver for any type of interface. In Unix terms some of you may be aware of the if config and the interface configuration. So it's pretty much a port of the same idea in Windows terms. And the end disk is essentially an abstract driver that works with pretty much all types of communication devices. These can be modems, these can be ethernet cards, etc. Following that we have the TDI which is a transport driver interface. That acts somewhat like a bridge in the sense that you have calls from user space going into kernel space through this TDI layer. Now in user space you mostly have either Winsock 2 for 99% of the applications or something known as NetBT which is the NetBios over TCPAP transport. Some of you who might be familiar with a backslash backslash server, the SMV or CIFS notation, that's pretty much it. So aside from the workstation and server service, which are core components of Windows, pretty much any other application would go through Winsock. And that of course is what makes this all the more attractive to us. Now as the applications go through Winsock they are pretty much, you know, they all work over the same API which is the application programming interface. And that is the API that you link with Winsock or WS2 underscore 32.dll and it gets you the functionality of the send receive and as well as a host of WSA calls, namely WSA AsyncSelect and others to name a few. So you have all types of applications. They can be your browser, your FTP, naturally your IMs probably go over that as well, IRC, etc. Now this is sort of like the application type view that most programmers are familiar with. However, as it turns out, this is only half the picture. So if we try and look deeper, we see that we have this Winsock API layer, which is again the top interface, but we also see that we have a Winsock SPI layer, which is a bottom interface that is meant for what Microsoft defines as service providers. Now the term service provider like I said is a key idea because service providers are essentially either hardware types, namely, you know, your network cards, etc, etc. Or they could be software types as in software type drivers, which are mostly user mode drivers. Now this is really important since it gives you the full functionality of packet inspection and whatever you want, but at the socket level. So essentially from an OSI model perspective, we're working at layer 5, which is really quite the improvement over other types of sniffers and root kits, which generally operate at a lower level and thus confine you to a packet view. So here you can actually hijack a socket and not really wonder as to whatever the breakdown of the packets is because it doesn't really matter. Now essentially these providers are one of two classes. You have the transport providers, which as the name would imply, work with the data transport itself, namely the TCP and UDP transfers, etc. And you have the namespace providers which work with all the, you know, get host by name, etc. Namely if you want to look up any type of address, that address can be a NetBIOS name. It can be an SMB name, a CIFS name, etc. And this would imply of course that you need a mechanism to abstract that. And this is exactly what the namespace providers are all about. I'm going to focus on the transport providers because they are of course the next year ones in the sense that they actually get you to see some real data. Now as the illustration also shows, all the providers would share the same API, the same top API, which is what I see here what I mark here as a transport SPI, that is the Transport Service Provider Interface. So whatever provider you're using, essentially all these providers must work pretty much the same way. Now Winsock providers cannot normally be listed by applications, or at least they can be, but only if the application is actually aware of it. Microsoft has as part of the platform SDK, which is part of the Visual Studio Distributions, they have something known as an sporder.exe, which is a small executable meant to show you the service provider order of course, and also it comes with a small DLL called sporder.dll. Sporder.dll is a DLL that we'll discuss shortly. It actually has the ability to not only show you the service providers, but actually shuffle them around as you see fit. And this type of shuffling around is exactly the hooking functionality. So going on to see a slight demo of what the service providers are like, so auto-complete is not cooperating. So you have the sporder.exe, which shows you all the available service providers here. Now my display is particularly cluttered due to the fact that I have VMware here, which is pretty much all those globally unique identifiers that you can see here, as well as another VPN solution which opens up a sort of like a virtual interface. But the core providers that you're likely to see are the ones you see here. There's one for the infrared which is ERDA, there's one for basic TCPIP, there's one for UDPIP, there's one for raw sockets, and there's two of them for RSVP. RSVP is a quality of service protocol which is generally supported but never really used by Windows. Now going into one of these you can see that they essentially give you the complete information on the service provider, namely which DLL is actually the one that provides the functionality, as well as a bunch of service flags, provider ID which is a globally unique identifier, etc. The important stuff here that some of you programmers might recognize are the address family, the hex value too, meaning AFI net, there's also the socket type which is a SOC stream, and there's a protocol number which is 6, 6 of course for TCP, and naturally you'd have 17 or hex 11 for UDP. And so the way that works is at any time an application would request a type of socket to be created which would be a SOC stream, rather an AFI net SOC stream and a TCP essentially, a TCP socket. What would happen here is that this call would be redirected over to MSWSOC.DLL where WinSOC or the WS232 DLL is actually acting like a multiplexer. That is to say that it is one main interface under which you can have all types of various providers. Now again, this would normally be the case with your average Windows and the more interfaces you have and the more applications you have, the more of those providers you're likely to see. As for the name resolution providers, these are the namespace providers, you have your basic TCPIP which is an interface to the DNS client service, you have NTDS which is of course Active Directory and you have network location awareness which is something that again Microsoft supports but never really works. So you have all those and now comes the important part. The important part is that you can have over these service providers you can have a functionality that enables you to chain your own providers. That is to say not just add a provider and by doing so you're going to have to essentially make the application aware of that provider but you can pretty much hook your providers and install something known as a provider chain which is really an amazing idea. Now the original plan behind that was to support all types of nice uses. Nice such as transparent encryption, such as quality of service, etc. But the way that works is that most applications don't really use that functionality and so it's just left there but not really used in everyday terms. Now the beauty of it is that you can chain any number of providers and you can chain them in pretty much any order you want. That is to say that if you want to provide some encryption functionality for example or reroute everything, all types of data transparently over SSL or SSH or whatever other tunnel you want, you can pretty much install your provider and then bump it to the top of the stack. So any other application using the stack would essentially get directed to your provider first and your provider would do whatever you want and then follow down the chain, essentially progressing the API calls down the chain. Any questions thus far? Okay. So the way it works is that your Winsock, the DLL itself, has several functions which are exported. I'm going to try this the dump in demo a bit clearer here so we'll be able to see the... So what I'm doing now is I'm setting up the visual studio command in my environment so I can show you the dump in command and the way dump in works is, as some of you may know, it gives you the DLL and shows you all the exported functions or the imported functions and so forth. So what I'm going to do now is essentially look for an exported function list of Winsock and focus on the specific service provider interface. To do that what we'll do is just do dump in slash export, get the name WS232 and since essentially Winsock exports like on average about 100 and something functions, I'm going to use the command line utility of grep to isolate only those important ones. So looking at that you can see that you have these particular WSC functions. Now again those of you who might be working with Winsock on a daily basis know that Winsock usually exports to WSAs which are for the Winsock API. WSCs you see here are essentially all about the service provider interface and so forth. Now there's too many functions here to actually go over but the ones of interest are essentially install provider and deinstall provider which enables you to of course set your own LSP or remove your LSP as well as install namespace and for some weird reason it's uninstall namespace. Hinting that maybe this API was not really meant to be used because it's not really standardized in that sense as an uninstall and not deinstall. Now all of these are also fully documented as part of the MSDN but it's the kind of MSDN documentation that resides on like the fourth CD that nobody ever gets to because it's like so obscure in the back. Now as it so happens these functions are readily exportable and you can use them to do your own type of work as I'll show briefly in a demo. Now this SP order DLL is an additional DLL that as I said works for rewriting the service provider order and as the example here shows this is a dumb bin of the SP order DLL and you have right namespace provider, sorry right provider order and right namespace order which essentially enable you to shuffle around as I've stated and put your provider just in its right location. Now a lot of spyware aware applications like adware and all types of anti spyware essentially look for that DLL and if that DLL is present on your operating system then it's bad news. Then they normally flag it as spyware and so forth. Probably the best example of that was CASA the file sharing utility that has SP order.dll bundled in. So when you install CASA you have this DLL somewhere on your system. Another interesting application to use this type of DLL is Google desktop. I don't know how many of you use Google desktop but Google desktop has probably its niftiest feature is that after you install it whenever you go into Google.com you suddenly get your own desktop there. You have like the ability to search Google or to search your own desktop from the very same web page. Now obviously that kind of functionality would imply that Google has a mechanism in your machine that can intercept the calls to Google.com and sort of like rewrite the page content on the fly. That is exactly the functionality that I'm describing here. Namely by installing their own provider and putting it in your machine they can intercept the calls to Google but they can of course do whatever they want. That is to say that if they're not really playing by the rules they can do a lot of other stuff as well with your machine. But then I'm happy to see that not too many people use Google desktop here because that's kind of like shady. Anyways, so going over that probably the most interesting API call would be the WSC enum protocols which would be the API call that one would use as a setup to install their own provider. This much like all the other WSC enum functions will enable you to sort of like go over the protocols that are already in place and provide for an enumeration of them. An enumeration in our case would be a pointer to an array of protocol infrastructures. Now you have a fully annotated example on the PDF in the PDF so I won't really go into that. But the idea is fairly simple. Anybody can call this function and see what service providers are already there. In many ways this is pretty much the only mitigation against this type of attack. However most applications don't really use that and if anything they would use the counter part of this call which would be the WSA enum protocols. And the difference between the A and the C is that the C can get all the protocols whereas the A gets only the top layer ones. So if you're using yours in a chain essentially you can remain hidden which is of course bad news. So going over that we have the enum protocols just to see which protocols are there and we naturally want to build our own service provider. Now using a service provider is really fun. It's really easy too because as a baseline you have the Microsoft supply demo. So I happen to have this demo right here and I'm going to work with the actual Microsoft code. Due to copyright restrictions I haven't really bundled it or put it in a targe easy for you guys to use but it's fairly simple to just get this code from the MSDN and just work and do the same modifications that I did right here. So looking through that code the DLL main would be a good point to start. So launching visual studio just so we can see this type of DLL then our service provider is just going to be another DLL. So essentially it has to follow the very same conventions that is to say it has to start with the DLL main and the DLL main would work as pretty much all DLL mains work that is whenever an application would hook to us and would call us we would get the DLL process attached as the DW reason. So the way that works is whenever a process attaches I add this little addition here which essentially doesn't do much. What it does is it just opens up a file name. It readies a file name here with an S print F composed of SOC debug as a prefix and the current process ID embedded in there. The reason I do that is because once I'll do that and of course run my applications you'll see that each application as it uses WinSOC will generate this type of file on the root of the C drive and what it does here is that it just opens the files and pops a message box and you will be able to see that message box. That message box and any type of code that I run here is run in the context of the calling process. So while this is a somewhat innocuous example and just you know only for demonstration purposes I'll print out a lot of stuff. If I really wanted to I could do whatever I wanted here. Essentially I could load additional DLLs as the comment says. I could decide that this particular process should not access a stack and so forth. Now to make matters even easier for the spyware people this type of functionality can also be injected in the WSP startup call. The WSP startup which is shown right here in the slide so WSP startup is essentially the counterpart to WSA startup. Those of you who may have been working with Windows know that each Windows application as it starts as it launches its WinSOC functionality has to start off by calling this function the WSA startup and what it does is that it requests a certain WinSOC version and request certain capabilities. Now the beauty of it is that most programmers just call WSA startup check the return value and naturally everything is just okay. However these programmers are unaware that this essentially would call the WSP startup which is our code. So in RLSP what we're going to do is essentially implement a WSP startup which will have our very own code in there. Now looking at WSP startup you can see that it has five parameters as opposed to WSA which has of course fewer parameters. The parameters of interest here are specifically the three last ones. We have the in parameter protocol info which states what type of functionality the application expects namely are we expected to perform TCP or UDP or any type of other service. We further have something known as the up call table which is by far the most useful parameter here which will enable us to have an array of essentially it's a pointer to an array of functions and these functions are the already installed providers. So that means that if I want to hook for example send or receive I don't really have to think about how I would implement send or receive but rather I would implement them my own and sort of like a stub function and later on just go on to call the up call table. And the example will demonstrate that shortly. Finally we have the only out parameter here of interest the other one's really not interesting the LPWSP data is really not interesting but the LP PROC table here is our procedure call table and that is essentially a pointer to all our functions. So whatever functions you choose to implement you can pretty much set in this big structure there and just call WSP startup and returning from the call you would pretty much produce your procedure table and you'd be guaranteed that your applications your rather sorry procedures would be called. Now those of you who may have been working in the UNIX and Linux environment would know that in order to achieve that in Linux you'd pretty much need to have any type of a kernel module inside the Linux kernel for example or any type of streams interface in Solaris which would of course be a lot of hassle but when it comes to Windows all this is pretty much transparent to you. So looking over the SPI CPP which is the main file that has all the functions let's just go over WSP startup briefly and you'll see that what Intel and Microsoft do here this is again their demo is that they simply implement this WSP startup call. The important thing here would be after initializing their own internal structure would be number one to save the WinSoc 2 upcall table that is to say save the actual implementations that are already out there because we're going to need to call them as sort of a pass through and once that's done they do a lot of other startup code and so forth and they get to the important portion of populating the procedure table. So the procedure table is a structure and it's as simple as it can get because you'd have a structure of function pointers and all you have to do is just hook your function pointer to the corresponding functionality that you want and so once that's done you can hook all those calls. Now just looking at one of those calls say for example WSP receive which would be the counter part of the WSA receive and so forth. Okay so looking through that at some point we'll get there. Yeah okay there it is. So this is the WSP receive function which is again guaranteed to be called prior to the application actually getting any data. So if Google for example wants to rewrite the content this is exactly the function they'll hook. Now again I won't go over the numerous parameters here. The parameters of interest are obviously the socket in question and a long pointer to the buffers. This would be an array of input buffers and since we're passing an array by reference we also have to piggyback the third parameter which is the count of buffers namely what is the size of said array and so what I do in my little demo is do a fairly simple function here which would just go on and write to the debug file that it's intercepted a receive and would simply go over the buffer. It's going over the entire array there and simply printing out the buffers. Now as far as a demo is concerned this is really not the type of graphical pyrotechnic demo you'd imagine because it also will accept a lot of binary data. However it does illustrate the point that the data can be intercepted and can be of course modified. If you want to you can pretty much have any type of modification of those LP buffers and you can inject your own buffers you can put your data you can log the data and so forth. I of course chose just to log the data. Now naturally you do the same thing for WSP send and a host of other functions but that goes without anything. So we have our DLL and now the next place would be the next step sorry would be to insert it. Okay somehow get Winsock to recognize our service provider as a valid service provider. Now bear in mind that this is something that has to be done outside the DLL because your DLL can only intercept certain functions but it cannot install itself. However in order to install it we have another call which is how you see install provider. This is a fairly simple call where all you have to do is provide a globally unique identifier which is of course easy to just whip up for yourself. And you'd set up your own DLL path and the type of protocols you support that's all it takes. Now your example should have actually I'll go to my source code here just to demonstrate how simple it is. So all you have to do is have a small executable file like say this inst lsp which again is a verbatim copy of the Intel one. I didn't really do anything here because this is the same generic code that would work with any service provider and so what it does here is that it has a little function called install my provider wherein I populate the provider info like so I populate a lot of stuff. You'll also notice a nice little flag here called PFL hidden which is this flag right here which is a really nice flag because this actually tells Winsock if anybody wants to enumerate this provider from the API level keep it hidden. Which you know I don't really get the actual intended use of that but whatever. Now there's also another interesting copy here which is security scheme which enables you to have your own type of security for your provider blah blah blah most of the time you just do protocol none. So essentially I populate this provider and I of course register it as a protocol provider for TCP and once that's done is all I have to do is just call this WC install provider and provide the name of LSP DLL. This is assumed to be in Windows system which would be a problem if you're not in admin but then again you're gonna have to be in admin to run this anyway. But you can also specify a full path here if you really want to and so I load the protocol info through the pointer and once that's done I pretty much guaranteed that my provider will be installed there. Now let's go ahead and try and install that provider and see exactly what happens. Now you'll notice that I already took the liberty of placing that little DLL here that DLL is as compact as 81K. Actually 80K or so. And the thing is once that DLL is in place all I have to do is call the INST LSP executable to do the rest. Now before I do that I want to fire up Regmon. Regmon is a tool by SysInternals which I'm sure most of you know and that enables us to hook all types of registry calls and the important thing here is that all this type of functionality of installing providers or de-installing providers is essentially all registry based. So if you really want to bypass this type of DLL with enumerating the provider order and so forth or installing your own providers all you have to do is directly access the registry which is of course fairly simple. So what I'm going to do now is I'm going to launch Regmon and naturally all is silent because my process hasn't started yet. And now I'm going to run this INST LSP and as I do you can see that it's scanning the all providers and then going on to install my provider on top of all the rest. Now again since this is a rather crew demo I didn't really go to any pains of just looking for the right providers. I just said go ahead and install it over all the providers but it's fairly simple to just decide that you want a very specific provider. Now you can also see that there's a lot of registry action here and specifically all the registry action is focused on one specific branch which is HKEY local machine system, current control set services and Winsock 2. So firing up RegEdit just to see what you'll see and so already in my favorites you'll see that Winsock 2 parameters has the namespace catalog which is for the namespace providers and the protocol catalog which is for the transport providers. Now again Microsoft is inconsistent. They don't really call the things by the same name all the time but that's beside the point here. So under the namespaces you have all types of catalog entries and as you can see you have the same catalog entries that we could have seen under the SP order executable, namely the NTDS, the plain TCPIP and so forth. And when it comes to the protocol catalog here everything gets really messy because one would think that you'd get these nice type of keys and values but here you only have a packed catalog item which is a blob of binary data that if you go into you'll actually see makes a lot of sense. This is a protocol info structure that has been overlaid into the registry as raw binary data. Now you'll also note that once I put in my layered service provider the number of providers here has risen from the 30 something that it should be to around 57 because that's where my mind is hooking. So with all that in mind the stage is set and I can now run any application of my choice as I'll shortly do and you'll see that as the applications run I'll get a nice little message box and I'll get a full log of whatever. Any questions thus far? Yeah. Well no that would go with the namespaces provider with the TCPIP one which I'm not really discussing how to hook that. If you really wanted to you could also hook the loop back address as well so as people would go ahead and try to resolve and get the 127.001 because it's in your host file but then the application would get that first. So you'd be able to actually rewrite the result of the NSLOOKUP or whatever DNS packet should have been there and you'd be able to just put in any address of your own which is of course very nice for our purposes. Furthermore the Google desktop would then have to connect to the loop back interface and that would be a transport type action and you'd be able to to get the connect. You'd be able to hook the connect call and see a connect to 127.001 to whatever port Google is using and of course redirect it. So simply providing your workaround wouldn't really work because this functionality is actually stronger than that. Any other questions? Yeah. Say what? Oh you can't. So the question is say I want to put in my own provider. How can I ensure that my provider is the top most? In two words you can't because any provider that gets installed after you can pretty much rewrite the stack as they see fit. So you'd have the protocol chain. You think you're there first but the whole beauty of this mechanism is that it's so transparent that at any other point in time somebody can get ahead and jump in front of you and hook you as well. So that's of course good news or bad news depending on your perspective here. Yeah but that's not to guarantee that somebody else some other application starting up after you they could enumerate the order as well and they could rewrite the order as they see fit. So essentially this is somewhat of a limbo in the sense that you have a given order but the enum protocols will only provide you with a snapshot of the current order and no guarantee of any other application coming after you. You cannot decide you want to be the top most protocol in the chain and that's it. Further when any other protocol gets bumped in you wouldn't know. You have no indication whatsoever as to your position. Yeah you'd still be, well again okay so right okay so the question is would I still be hooked and the answer is yes and no because yes I would be hooked in the sense that I'd have my own place in the protocol chain. I don't mind the fish. I'll have my own place in the protocol chain yes but if any other top most provider would want to hold that call in the chain and not propagate it not play by the rules they'd be able to intercept it and essentially block it. So as I place my own provider I can either choose to go ahead and forward the call or I can say no I want to handle the call and I don't want to propagate it further. You can change the providers at any time okay using the order order the WSP right provider and so forth you can pretty much redo the whole ordering as you wish because all it changes is some internal structure in Winsock so oh yeah of course of course but then again there's no guarantee that you will be called again because again let's assume for a sake that I have my own custom provider and I want to make sure that nobody gets on top of me so assuming whoever gets on top of me does forward the call further yes I will be called but if that somebody takes the express route and just you know decides to bypass whatever other calls then essentially my provider would still be there but would never be called. Yeah the order is in the registry and of course an enum protocols would work as well. You could enum the protocol so as to get it in a nice little array but the order is right here okay this is pretty much the order I mean you can pretty much see that that the key names are the ordinals so it doesn't get to the root by sis internals I'm not familiar with the specific one but I can tell you that a lot of other root kit detectors don't really go that far. Now it's important to just define the terms here. This is perfect user mode action this is not a root kit in the sense of like a kernel mode root kit because that would be hijacking tcpip.sis itself and that you know that there's nothing that can be done against that but the beauty of it is that this is full user mode and in that sense it's a lot easier not to mention you can code sloppy and not risk a blue screen of death which is of course a nice little added benefit there. Okay so since I'm getting the news I'll just run a few applications here so let's just run Firefox and a bunch of others and as you can see Firefox is loading and already I have a sock debug of 1148 which is of course a process idea of Firefox so Firefox is running and this is the Mozilla start page and I can do all sorts of and see I can get any types of pages I want and everything is really nice and dandy but behind the scenes I have this little sock debug 1148 and of course I could also fire up my messenger or my yahoo or whatever and I'll do that just briefly here so as I fire up yahoo I should be getting the message box sometime soon. Yeah just you know yahoo's a bit slow. Okay now you'll notice this is a really nice effect that I get the message box in the context of the yahoo process so I get their window class which is a nice not really nice but purple whatever okay and so this is connecting and everything is cool and nice you can also see that it's hooking another call and whatever they'll just let it run and you know ditto for messenger so if I'll just run here run messenger yahoo whatever yahoo you can whatever that's a student of mine just regard that okay so again so I can run that with messenger and so forth and all these sock debug files are right here so let's just go over the 1148 one that again this is very crude so I get a lot of seemingly junk looking data this junk looking data is all types of either GZ compressed HTTP data or all sorts of binary data such as images and so forth if I scroll down I should be able to see some HTTP request right here okay so this is the get of header tab.gif and naturally you get all types of this for example is a PNG you can pretty much see the header here that's a dead giveaway as well as a bunch of others etc etc the HTTP replies and so forth now again I want to emphasize one thing this again as a demo is not as half as fancy as it can be because with a little if there I could have simply rerouted Mozilla to some other site or I could have modified whatever Mozilla was displaying now another disclaimer here is that HTTPS type connections are unaffected by that fortunately there are other ways to hook HTTPS which are beyond my scope here but I'm just saying that if you do use HTTPS you're fine however when it comes to all types of other functionality messenger email whatever everything is pretty much in the clear okay any questions yeah yeah with NetBT you can although it's well again that let's define NetBT if the process that runs the NetBT request has launched after you have put in your provider then yes you can and if you get your provider into the Windows startup then yes you can okay however some functionality you still won't get namely the WinSoc bypass functionality that sometimes a server service does okay in order to gain efficiency it doesn't go through a user mode DLL because it doesn't make sense you know okay so you can hijack some of the functionality although not all any other questions yeah no zone alarm actually as far as I know go into the TDI this is what McAfee does though McAfee the personal firewall does do they do do that so but again this is kind of like a kind of like a paradox in the sense that you know it's absurd because if McAfee uses that and I can pretty much intercept their calls and get on top or reroute them to the bottom then it's really useless any further questions because I'm getting the sort of like new style so yeah right there okay the question is if I'm intercepting a WSP receive if I'm intercepting an SSL socket would it be encrypted or not and yes it would be encrypted because I'm essentially getting it as it came on the network so this enables you to play middleman but only middleman you know post SSL or post encryption which is as I've stated the proper worker on the proper mitigation to that would be to always use SSL and so forth however bear in mind that nothing is preventing the application from also you know trying to forge certificates and do any type of D sniff type man in the middle which would work here okay so just to conclude before I'm kicked out violently okay so that was the demo the lesson to be learned the thing you need to carry home from this is that no matter what you do no matter how you code your application the beauty of windsock is in transparency however this is a double-edged sword because obviously as transparent as it is it enables attackers to subvert either client sockets, server sockets or whatever now it's also important to emphasize that this was originally intended for good uses namely implementing an application type firewall application layer firewall we mentioned McAfee and of course we saw where that got um transparently add encryption this was well before the days of IPsec we're talking about 98 before IPsec was a fully robust protocol as it is now and nowadays IPsec is handled of course at the current level, enforced quality of service support new protocols this is also another nifty functionality you can essentially support IPv6 by it although it's supported already you can support IPv9 you can support pretty much any other custom protocol over raw socket and patch content on the fly which like I said Google desktop actually do whether it's a legitimate use or an illegitimate use remains to be seen however the much better chaotic uses would be to patch content on the fly in the illegitimate sense and again we're talking about rewriting webpages rewriting IMs doing a lot of other nifty stuff which I will not disclose here um obtained connection statistics URLs etc etc most of the spyware applications do exactly that they put themselves in so as to gather your statistics this was what the CASA spyware did eavesdropping on any type of connection but again non SSL ones and uh rewriting connections that is just hijacking the sockets which is really an amazing thing because an application opens a socket and calls connect and once it does that then you know the worst that can happen it's gonna call get peer adder but you can reroute connect and you can also reroute get peer adder so you know whatever the application thinks it's doing whatever wherever it's actually thinking that it's connecting to it has no real significance here because you can do whatever you want with it so uh all that in mind the demo like I said is part of the platform SDK you're welcome to drop a line to this address right here and if you need you know the demo with the actual explanation on what I did where I did and so forth then it will be supplied of course any further questions okay