Skype Greeting API Crash

It seem like the following code crashes latest version of Skype:


The interfaces look like this:


The crash log looks something like this:


This issue can however only be triggered from a post-authorized state ie. your client must be authorized by the Skype client to use Skype API.

Security Impact of this issue is currently unknown due to uncertainty of exploitation possibility. Even if exploitation is possible (although looks unlikely) the impact will be lower due to local and post-authorized nature of the affected functionality.

Web API Callback and Programming Model Attacks

In the land of Web Service where multiple applications communicate among themselves to fulfill a larger service delivery objective, Web API callbacks are probably the most correct and intuitive choice for implementing events and event handlers - something which is very basic to scalable design principles.

A conventional B2B transaction is normally implemented as below, where two or more services interact via Web Service calls:

In most of the cases, the communication between different services are executed via API Callback redirection in the browser, typical example being interaction between a Payment Gateway and a Merchant Site. However in certain cases, it might be required for a given application to internally communicate with 3rd party services.

We recently came across such an application where a certain service request requires an extended time window for processing. In order to maintain asynchronous nature of API calls, the application creates background job that handles the actual service request. As a part of its functional requirement, the background job created corresponding to a service request fetches information using a Callback URL specified by the client during request submission.

We were able to create a Denial of Service condition in the application back end, specifically we were able to create an extensive bottleneck in the background tasks while fetching information via the Callback URL specified in service request call by serving HTTP response corresponding to the Callback URL request very very slowly. The issue we exploited is very similar to Slowloris and has been discussed to some extent in Programming Model Attacks section of Apache Security however we did it in a different context - instead of attacking the server, we used similar logic to attack the client.

A custom HTTP Callback URL Handler was developed which serves any HTTP request very slowly thus effectively blocking the client in the HTTP Transaction phase. When multiple service requests were submitted to the target application, all the worker processes responsible for handling and processing the service request were blocked in HTTP Transaction state for a very long time effectively resulting into a Denial of Service Condition. The proof of concept code that we developed for  implementing the HTTP Callback Service is available here.

Although there cannot be any completely accurate fix for these kind of issues as the functional requirement of the application or service depends on interaction with 3rd party services however there can be practical workarounds like defining constraints on Callback URLs and defining timeouts for various operation that involves interaction with 3rd party network or application.

Skype API ... and Security

For sometime, we have been working on techniques to record Skype voice calls in a reliable and non-intrusive manner. Previously there had been known techniques and public proof-of-concept codes that demonstrate Skype voice call recording via DLL Injection and hooking certain Sound API inside Skype process, however such techniques evidently will be far from being non-intrusive.

It turns out, since quite some time Skype is actually developer friendly. Among various SDKs which are not available freely and only available to partners, Skype provides a OLE COM interface freely through which it is possible to interact with the active Skype process via a valid and documented interface.

The OLE interface thus makes it trivial to setup OLE Event Handlers for notification on Voice Call initiation and termination along with setting up appropriate recording channels.

Using Skype4COM, scripting up a Skype Recorder is actually quite trivial:



All great so far, however such trivial Automation API does come with a risk of malware misuse. In order to avoid malwares misusing Skype OLE Automation Interface, Skype has implemented API Access Authorization by the user which basically pops up or displays a message to the user for authorizing a given application to use Skype API. The authorization process is actually a bit complex than simply asking for user authorization and is more or less discussed here.

As already discussed and proved here, such Access Control or Authorization is definitely not enough as it is not very difficult to simulate mouse events. With some effort we were able to develop a proof of concept code that can automate the API authorization process using FindWindow, mouse_event and SendMessage Win32 APIs. Apart from that, authorizing applications to use API based on executable hash only is probably not a good idea as it _might_ be possible to force a trusted application to perform malicious activities by using it as a shuttle for malicious code.

The Entropy Entropy

Recently while conducting a Web Application Penetration Test for a client, among usual vulnerabilities like SQL Injection, XSS etc we found rather a very interesting issue related to session cookie management and session cookie prediction.

The session cookie looked something like this:

010239E505D30CE1CE08FE39FF76EB0EE1CE08000A750073006500720000012F00FF

Initially we assumed the string to be of some encoded form of user data however upon analyzing a set of such samples we discovered a pattern in the string and were able to align multiple sets of such samples to discover related blocks.

010|239E505D30CE1CE08FE39FF76EB0E|E1CE08000A|7500730065007200|00012F00FF

Later upon analysis we found each component to be as below:

c1: 010: [Constant]
c2: 239E505D30CE1CE08FE39FF76EB0E: [Hash of Temporal Data perhaps]
c3: E1CE08000A: [UserId or some Serial Data]
c4: 7500730065007200 [hex encoded user name]
c5: 00012F00FF: [Constant]

Upon further investigation and some trial and error we found it was possible to re-use the c2 component of one user for another user which effectively means there is hardly any entropy or randomness in the session identifier other than predicting the user id (c3) and user name (c4). Since the user-id in turn is serial in nature it will be trivial for one user to log in as another user based on the target user's username and some brute force of the user id.