Local Service Provider (LSP/SPI)

This section represents the ways in which malware can damage Winsock and the basic theory of malicious programming.

Winsock 2 has two “mirror sides”: Winsock API and Winsock SPI. Winsock API implements the Windows Open Systems Architecture (WOSA), which possesses standard API interfaces between Winsock and applications using it. SPI is an interface between Winsock and Winsock service providers.

•

Namespace provider (NSP). The task of the namespace service provider is protocol-independent name resolution, that is, conversion of a friendly name into a protocol-dependent address. A classic example is DNS, which converts a user-friendly name www.z-oleg.com into the IP address of the server hosting this website.

•

Transport service provider (TSP). TSPs are services providing such functions as establishing connections, transmitting data, managing the stream, processing errors, and the like. There are two kinds of transport service providers: base and layered. Base providers handle specific elements of the network transport protocol (such as TCP/IP), including basic network protocol functions, such as sending and receiving data over a network. Layered providers carry out only high-level communication functions and need a base provider for actual network exchange.

As shown in the figure, there can be multiple NSP and TSP providers (an unlimited number, to be more precise). What is even more interesting, the list of LSPs and TSPs used is stored in a special database (located in the registry). Moreover, Winsock API has functions that enable the application to both receive lists of LSP and TSP providers and to register their own providers.

In terms of physical implementation, an SPI provider is an ordinary DLL developed according to a certain standard: In particular, this DLL must export a number of functions used for interaction with Winsock.

On the one hand, storing the list of providers and their parameters in the database and providing a function for controlling this database is a very smart move: Any application can install its own SPI providers, thereby expanding Winsock capabilities. In doing so, the application does not necessarily have to know which SPI providers provide name resolution and exchange over the network and how exactly they do this. This results in an all-purpose system, and many applications use these capabilities. AVZ can be used to examine SPI settings and see which providers are registered there: The list of providers includes firewalls, anti-virus applications, various anti-spy applications, anti-adware utilities, traffic metering utilities, and so forth.

Now let us have a look at SPI through the eyes of virus and spyware/adware developers. This means that installing 2-3 providers is enough to take over control of all computer exchanges with the network. Using its own namespace service provider, a malicious program can track name resolution requests (for spying purposes) and interfere in this process. Put simply, when you send a request to the www.yandex.ru website, an “alien” NSP will instead issue the IP address for www.unknown-search-engine.com. Similar tricks are possible at the TSP level. Spyware programs most often install their own Layered Service Providers (LSPs). It turns out that the openness and versatility of SPI Winsock becomes its vulnerability: Malware developers know this and actively exploit this vulnerability. There are many examples: Spy.NewDotNet (not-a-virus:AdWare.NewDotNet), Spy.SAHAgent, Spy.WebHancer, Trojan.Riler, Adware.SpywareNuker, Backdoor.Kika . Besides interfering with the operation of Winsock, running a backdoor component in the form of SPI offers many “advantages” — hidden startup, absence of a visible process.

The possibility of malware installing as an SPI provider is only part of the problem. It turns out that Winsock has one more unpleasant characteristic: Any corruption of the registry database with the description of SPI providers causes failures in Winsock operation. (The specific kind of failure depends on the nature of corruption; however, all errors normally have two outcomes for the user—the computer loses Internet access and problems arise during access to the local area network; if you analyze the schematic at the top of this section, such errors become obvious and understandable). There are multiple causes of SPI settings corruption, the most common of them being:

•	Deletion of a DLL that is an SPI provider without terminating its registration in the SPI providers database (a DLL can be removed manually, by an anti-virus scanner, an anti-spyware application, or the native uninstaller—the method of deletion does not matter);

• Corruption of the registry database in the process of SPI providers installation / removal or as a result of a manual registry “cleanup”.

Upon detecting an error, Winsock in particular and the entire Windows system in general do not take any steps to eliminate it and do not issue any diagnostic messages. It is worth noting that reinstalling the system on top of the existing system does not fix the SPI settings.