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 TCPIP 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, etc.
Now I find myself somewhat inclined to start with a preamble here. This is not some type of
vulnerability issue or not some type of any 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,
etc, etc. 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 the
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's 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, etc, etc. And there
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, it's just another file descriptor. Those of you who may
have some Unix background know that sockets and file descriptors in 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, encapsulation, and getting
the IP header and the TCP header or 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 pack 2, 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,
2003, 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 in 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 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 are 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 7 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 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, uh, review of this. So, looking at this
from several levels of abstraction here, oops, wait a sec, that's Microsoft PowerPoint
running wild 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 Windsock
calls will eventually be rerouted over the hardware in a sort of, uh, device independent
manner. The miracle that does this is something called the Ndisk driver, which is the network
driver interface specification. That's sort of like an abstract driver for any type of
interface, uh, in Unix terms, some of you may be, uh, aware of the ifconfig and the interface
configuration, so it's pretty much a port of the same idea in Windows terms. And the
Ndisk is essentially an abstract driver that works with pretty much all types of
communication, uh, devices. These can be modems, these can be, uh, ethernet cards, et cetera,
et cetera. Following that, we have the TDI, which is a transport driver interface. That
acts somewhat of a, uh, 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 Winsock2, for 99% of the applications, or something known as NetBT, which is the
NetBios over TCPIP transport. Some of you who might be familiar with the backslash,
backslash server, the SMB 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's, that of course is what makes this
all the more attractive to us. Now, as the applications go through Winsock, they are
pretty much, uh, 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 dot DLL, and it gets you the functionality of the send, receive, and as well as a host
of WSA calls. Namely, uh, WSA async select and others, to name a few. Okay, so, you have
all types of, uh, applications. They can be your browser, your FTP, naturally your IMs,
probably go over that as well, uh, IRC, et cetera, et cetera. 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, as, 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 term here, because
service providers are essentially either hardware types, namely, uh, you know, your network
cards, et cetera, et cetera, 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 five, which is really
quite the improvement over other types of, uh, sniffers and rootkits, 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, uh, 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, et cetera. And you have the
namespace providers, which work with all the, you know, get host by name, et cetera. 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, et cetera. 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 gonna focus on the transport providers because they are, of course, the, the
sexier 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, uh, 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, uh, they have something known as an SPOrder.exe, uh, which is a small
executable, meant to show you the service provider, um, order, of course, and also it
comes with a small DLL called SPOrder.dll. SPOrder.dll is a DLL we'll, 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. Okay, so, autocomplete is not cooperating. So you have the SPOrder.exe
which shows you all the available service providers here. Now, my display is, um,
particularly cluttered due to the fact that I have VMware here, which, uh, is pretty much
all those global unique identifiers that you can see here, as well as another VPN solution
which opens up a, a, 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 IRDA, there's
one for basic TCPIP, there's one for UDPIP, there's one for raw sockets, and there's, uh,
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 global unique identifier, et cetera, et cetera. The important stuff here that
some of you programmers might recognize are the address family, the hex value 2, meaning
AFINET, uh, there's also the socket type, which is SOCKSTREAM, 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 that any time an application would request a type of socket to be created,
which would be a SOCKSTREAM, rather an AFINET, SOCKSTREAM, and a TCP essentially, a TCP
socket, what would happen here is that this call would be redirected over to MSWSOCK.DLL,
where WINSOCK, 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, 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, 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 you'll be able to see the font back there. So, just
looking through that... Okay, so what I'm doing now is I'm setting up the Visual Studio
command line 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 exports, get the name of the WS232,
and since essentially Winsock exports on average about a hundred and something functions, I'm
going to isolate only those important ones for our discussion. 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 the WSAs, which is for the
Winsock API. The WSCs you see here are essentially all about the service provider interface and
so forth. Now, the, the, probably 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 in 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. Okay, now, as it so happens, okay, 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 dump bin of the SP order
DLL, and you have write namespace provider, sorry, write provider order and write 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 AdAware 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.
And probably the best example of that was, uh, Kasa, the file sharing utility that has SP
order dot DLL bundled in. So when you install Kasa, you have this DLL somewhere on your
system. Another, uh, 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, uh, 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 webpage. 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 re- sort of like rewrite the page content on the fly. And that
is exactly the functionality that I'm describing here. Namely, by installing their own
provider and putting it in your machine, they can, uh, intercept the go- 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, uh, pro- probably the most interesting
API call would be the WC 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 WS, uh, 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, uh, you have a fully annotated example on the PDF, uh,
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. And 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 counterpart 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, building 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, you know, put
it in a targeasy 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, let's start... I think 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 at the DW reason. And 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 filename. Okay, it readies a filename here with an S printf,
composed of sockdebug 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 Winsock, will generate this type of file on the root of the
C drive. Okay, 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 Winsock functionality, has to start off by calling this
function, the WSA startup. And what it does is that it requests a certain Winsock version, and
requests certain capabilities. Now, the beauty of it is that, you know, 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 gonna 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 LP 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, uh, functions. And
these functions are the, uh, already installed providers. So that means that if I wanna
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 in 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 LP WSP 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, uh, 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, uh, a kernel module
inside, uh, 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 startups briefly, and you'll see
that what Intel and Microsoft do here, this is, uh, again, their demo, is that they simply
implement this WSP startup call, uh, the important thing here would be, after initializing
their own internal structure, would be, number one, to save the Winsock2 up call table, that
is to say, save the actual implementations that are already out there, because we're gonna
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 essentially hook all those calls. Now, just looking at one of those calls, say for
example WSP receive, which would be the counterpart of the, uh, WSA receive and so forth, okay,
so looking through that, at some point we'll get there, uh, 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 here, is do a fairly simple, uh, function here, which, hold on, which would just go
on and write to the debug file that it, 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, uh, imagine, because it also will, will intercept 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, you know, put your data,
you can, uh, log the data, and so forth. I, of course, chose just to log the data. Now,
naturally, you, you do the same thing for WSP send, and a host of other functions, but that
goes without saying. So, we have our DLL, and now the next place would be, the next step,
sorry, would be to, uh, 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 a WSP
install provider. This is a fairly simple call, where all you have to do is provide a
global unique identifier, which is, of course, um, easy to, uh, just whip up to, for
yourself, and you'd set up your own DLL path, and the type of protocols you support. That's
all it takes. Now, uh, 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 instLSP, which, again, is, uh, 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, uh, 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, there's also another interesting, uh, copy here, which is, uh, 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, uh, all I
have to do is just call this WSP, sorry, WC install provider, and provide the name of
LSP DLL. This is assumed to be a Windows system, which would be a problem if you're not an
admin, but then again, you're gonna have to be an 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, I pretty much guaranteed that my, uh, 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, uh, took the liberty of placing that little DLL
here. That DLL is as compact as 81K. Actually, it's 80K or so. And, uh, 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, uh, hook all types of registry calls. And the
important thing here is that all the, this type of functionality of installing providers, or
deinstalling 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 installed providers, and then going on to
install my provider on top of all the rest. Now, again, since, since this is a rather crude
demo, I didn't really go to any, you know, uh, 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 WINSOC2. So, firing up RegEdit, just to see what it's like there, you'll see, and it's a
already in my favorites, you'll see that WINSOC2 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 things by the same
name all the time, but that's, you know, 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
overlaying 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 mine 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? Mm-hmm. Well, no, that would go
with the namespace 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 loopback address as well, so
as people would, you know, go ahead and try to resolve and get the 127.0.1, 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 NS lookup, 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, you
know, very nice for our purposes. Furthermore, the Google desktop would then have to
connect to the loopback 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.0.1, to whatever port Google is using, and, of course, redirect it. So simply, you
know, simply providing your workaround wouldn't really work, because this functionality is
actually stronger than that. Any other questions? Yeah, back there. Say what? Oh, you
can't. The beauty of it, okay, so the question is, say I want to put in my own provider. How
can I ensure that my provider is the topmost? Uh, in, you know, in two words, you can't.
Because any provider that gets installed after you, can pretty much re-route, re-write,
sorry, the, the stack as they see fit. So you'd have the protocol chain, you'd 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, sort of like bump in front of you, and hook
you as well. So that's, of course, you know, 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
re-write 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 topmost 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. So I'll have, I'll have my own place in the protocol chain, yes, but if any other
topmost 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 provider order, the WSPRite provider and so forth, you can pretty
much redo the whole ordering as you wish, because all it, essentially 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, in 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 the key names are
the ordinals, so it doesn't get too complex. The route by sysinternals, I'm not familiar
with the specific one, but I can tell you that a lot of other route 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 route kit in the sense of like a, a kernel mode route kit,
because that would be hijacking TCPIP.sys itself. And that, you know, that, 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, and 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 noose, I'll just run a few applications here. So let's just start, you know,
let's just run Firefox and a bunch of others. Oh, and as you can see, Firefox is loading, and
already I have a sock debug of 1148, which is of course the process ID of Firefox. So Firefox
is running, and this is the Mozilla start page, and I can do all sorts of, you know, other
whatever. 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, uh, 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. Uh, so as, as I
fire up Yahoo, I should be getting the message box sometime soon. Uh, yeah, just, you know,
Yahoo's a bit slow. Okay? Now you'll notice this is a really nice, uh, effect, that I get the
message box in the context of the Yahoo process, so I get their window class, which is a nice,
uh, 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, uh, whatever, they'll just
let it run, and, you know, ditto for messenger. So if I'll just run here, run messenger, uh,
yeah, whatever, yeah, yeah, you can, okay, whatever. That's a student of mine, disregard that.
Okay? So, uh, again, so I can run that with messenger and so forth, and all these SOG debug
files are right here. So let's just go over the 1148 one, and you'll be able to see that, again,
this is very crude, so I get a lot of seemingly junk looking data. This junk looking data is, is
all types of either gzip compressed HTTP data, or, uh, all sorts of binary data such as images
and, and so forth. If I scroll down, I should be able to see some HTTP requests right here.
Okay? So this is the get of header tab dot gif, and naturally, you get all types of this, this
for example is a PNG. You can pretty much see the header here, that's a dead giveaway. Uh, as
well as a bunch of others, et cetera, et cetera, 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, um, email,
whatever, everything is pretty much in the clear. Okay? Any questions? Yeah. Yeah, with
NetBT you can, although it's, well, again, 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, uh, the Winsock bypass functionality, that
sometimes the server service does. Okay? In order to, 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. Uh, no. Zone
alarm, actually, as far as I know, go into the TDI. This is what McAfee does, though.
McAfee, the personal firewall, uh, does do, uh, they do do that. So, but again, this is kind
of like, uh, kind of like, uh, 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, or
reroute them to the bottom, then it's really useless. Any further questions? Because I'm
getting the, sort of like Neustein. 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 workaround, the proper mitigation to
that, would be to always use SSL and so forth. However, bear in mind, that nothing is
preventing the, uh, application from also, you know, trying to forge certificates and do any
type of de-sniff type man in the middle, which would work here. Okay? So, just to conclude,
before I'm, uh, 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 Winsock 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, 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, in the kernel level. Uh, enforce quality of service. Yeah, right. Uh, 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 a 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, uh,
doing a lot of other nifty stuff, which I will not disclose here. Um, obtain 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, rerouting 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'll, 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, 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. Uh, you're welcome to drop a line to, uh, this address
right here and if you need, you know, the demo with the actual, uh, explanation on what I did,
where I did and so forth, then it will be supplied, of course. Any further questions? Okay, peace.