While fairytales often start with “Once upon a time…”, our blogposts often start with “During a recent security assessment…” — and so does this one. This time we were able to spend some time on VMware’s vCenter Operations Manager (herein short: VCOPS). VCOPS is a monitoring solution for load and health of your vSphere environment. In order to provide this service, two virtual machines (analytics engine and Web-based UI) must be deployed (as a so-called vApp) that are configured on startup by various scripts (mainly /usr/lib/vmware-vcops/user/conf/install/firstbootcommon.sh) to match the actual environment and communicate via an OpenVPN tunnel that is established directly between the two machines. To gather the monitoring data, read-only access to the vCenter is required.
Last week we had the opportunity and pleasure to present some of our research results at BlackHat US 2014 (besides of meeting a lot of old friends and having a great researchers’ dinner).
Enno and Antonios gave their presentation on IDPS evasion by IPv6 Extension Headers, described here.
The material can be found here: Slides, tools (the main tool used was Chiron, authored by Antonios) & whitepaper.
Ayhan and me presented our results of the security analysis of Cisco’s EnergyWise protocol. The protocol enables network-wide power monitoring and control (ie turning servers off or on, putting phones to standby — basically controlling the power state of all EnergyWise-enabled or PoE devices). The main problem (besides a DoS vulnerability we found in IOS, see official Cisco advisory) is its PSK-based authentication model, which enables an attacker to cause large-scale blackouts in data centers if the deployment is lacking certain controls (for example our good old favorite, segmentation…). There will be a longer blogpost/newsletter on this topic soon.
The material can be found here: Slides & tools
In the “A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices” blogpost I described a way to evade a high-end commercial IDPS device, the Tipping Point IDPS (TOS Tipping Point, Package 3.6.1.4036 and vaccine 3.2.0.8530 digital), by abusing a minor detail at the IPv6 specification. As I promised at the end of that blogpost, this is not the end. In this blogpost I am going to describe several new and different ways of evading another popular IDPS, an open-source one this time, Suricata.
In the light of the recent release of version 5.0 of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than appropriate to talk a bit about the new features and some general things to take into account when using EMET (for the new certificate pinning feature of EMET 4.0, see Friedwart’s comment). For all of you who don’t know EMET, in short, it’s a free mitigation tool for Windows developed by Microsoft, helping the user by preventing vulnerabilities in software from being successfully exploited. The tool works by protecting applications via a number of security mitigation technologies, vastly extending Windows operating system mitigation capabilities as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
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.
As we continue our research in the 3GPP protocol world, there is a new tool for you to play with. It is called s1ap_enum and thats also what it does 😉
The tool itself is written in erlang, as i found no other free ASN.1 parser that is able to parse those fancy 3GPP protocol specs. It connects to an MME on sctp/36412 and tries to initiate a S1AP session by sending an S1SetupRequest PDU. To establish a S1AP session with an MME the right MCC and MNC are needed in the PLMNIdentity. The tool tries to guess the right MCC/MNC combinations. It comes with a preset of known MCC/MNC pairs from mcc-mnc.com, but can try all other combinations as well.
