Recently we started playing around with Cisco’s virtual router, the CSR 1000V, while doing some protocol analysis. We found Cisco offering an BIN file for download (alternatively there is an ISO file which contains a GRUB boot loader and the BIN file, or an OVA file which contains a virtual machine description and the ISO file) and file(1) identifies it as DOS executable:
$ file csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin
csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin: DOS executable (COM)
We didn’t manage to get the file running, neither in a (Free-)DOS environment, nor in a wine virtual DOS environment, except using the boot loader from the ISO file. So we became curious as for the structure and ingredients of the file.
We’re currently involved in a number of IPv6 activities in different organizations and one of the questions we are still facing – even in cases where there’s already a (in most cases networking team driven/originated) “project” (incl. budget, project sponsor, milestones etc.) – is along the lines of “How to sell IPv6 to our management?”.
In the following I will shortly lay out the line of reasoning and the terminology we usually employ for the task. Furthermore I’ve anonymized a presentation which we recently prepared as “input” for the network team of an enterprise organization; it can be found here. In case you want to get this as a PPT (for recyling purposes) pls send me a direct email (in exchange, we might ask you for a small donation of your will to the Troopers charity project… ).
Some weeks ago, at RIPE 68 in Warsaw, Sander Steffann gave a presentation about revising RIPE 554 which, in his own words, “is a template guideline for procurement of stuff that should do IPv6” (here’s the steganography transcript of the IPv6 working group session). Some of you will probably know RIPE 554 as a quite helpful document for identifying reasonable real-world requirements for IPv6 capable network devices (in particular at times when vendors quite willingly put an “IPv6 ready” sticker on all their gear…).
Past month we (which is me and a group of other ERNW students, supported by some of the “old” guys — I hope my team lead won’t yell at me for this 😉 ) attended the Haxpo and Hack in the Box in Amsterdam. Starting from 28. May, we had three days at this great conference (HITB) and exposition (Haxpo). The two events took place in the former building of the stock exchange in Amsterdam, called: “Beurs van Berlage”. Upon entering the building for the first time we were given details on where our booth was and where the talks would take place — setting up our booth and planning the shifts was just another thing to do before exploring the Haxpo area:
From left to right: Sebastian, Burak and Heinrich at the ERNW booth
regularly we get requests from customers where the idea of using Skype as a VoIP solution in their corporate environment is brought up. There are a lot of eavesdropping and more conceptual concerns (e.g. refer to this or this, and of course the legendary “Silver Needle in the Skype” paper from Black Hat EU 2006), but those won’t be covered in this post (just to say this: at ERNW the use of Skype is strictly prohibited at by policy).
However, we worked on an interesting request that focused on Skype’s security impact on end devices, mainly concerning Windows clients. Skype has many features e.g. file sharing between users, the ability to set the port on which Skype listens, or clients becoming supernodes, which in turn can be relevant for the overall security impact on network or clients. The interesting part from a corporate perspective is the ability to configure those Skype settings via GPO, for which Skype even used to provide an ADM file. However, the settings in this file were quite outdated, which made us decide to put together a file for the settings of the most recent version of Skype. Relevant resources for this are the Skype IT Administrators Guide and a corresponding TechNet article on ADMX files (Managing Group Policy ADMX Files Step-by-Step Guide).
Our Skype ADMX files can be found here for download.
Besides the concerns of Skype usage in corporate environments in general (as mentioned above, this post does not discuss those), we want to outline some of the settings that can be relevant to protect clients and network:
Disable File Transfer: Disable file transfer to achieve that any user can’t send any internal data trough Skype.
Disable Contact Import: This setting prevents any user to import contacts trough the application itself, importing contacts can be realized over Skype-Manager tool.
Disable Web Status: If you disable this setting any user can’t publish their online status.
Disable API: Prevents usage of Skype API for third party applications.
Disable Version Check: This setting prevents Skype to perform an initially version check.
Memory Only: This setting makes it possible to run Skype without storing data on the local disk.
Listen Port: Skype normally listens on a default Port, this setting restricts the port to your settings.
Disable Supernode: This setting prevents a random user to become a supernode which makes it possible for this user to intercept traffic.
Proxy Type: HTTPS or SOCKS5. This also enables the use of the proxy in general
Proxy Address: “hostname:port” e.g. “socks5.mydomain.com:5050”.
Proxy Username: “username” e.g. “socks5user”.
Proxy Password: “password” e.g. “socks5pass”.
Despite our critical opinion on Skype, we hope that the files might help the secure operation of Skype in environments where it has to be used for some reasons.
Best,
Sebastian & Matthias
PS: We tested the files in our environment and did not experience any problems. We’re happy about bug reports, however it might take time to deploy changes and we cannot provide any support/warranty on the files.
