Compass Mitarbeiter erneut ausgezeichnet

Nachdem am 25. Mai 2014 bereits Alexandre Herzog, CTO bei Compass Security, mit dem 1337-Award durch die SGRP, einer Alumni-Organisation für MAS Information Security[1] Absolventen der Hochschule Luzern, ausgezeichnet [2] wurde, ist es erneut einem Compass Mitarbeiter gelungen, die Fachjury von seinem ausserordentlichen Wissen und Können zu überzeugen.

Lukas Reschke hat im Rahmen seines Praktikums bei der Compass Security eine Abschlussarbeit zur Analyse von Advanced Persistent Threat (APT) geschrieben. Die Arbeit beschreibt APT generell, gibt Einblicke in forensische Vorgehensweise, zeigt Erkennungsmuster auf und gibt Tips und Tricks für die Analyse von bösartigem Netzwerkverkehr mittels Splunk .

Im Rahmen der Abschlussfeier vom 3. Juli 2014 in der Tonhalle St. Gallen wurde Lukas Reschke in zweierlei Hinsicht für seine Leistungen an der Kantonschule am Brühl in St. Gallen geehrt.

Zum einen wurde er für den Aufbau des Tech-Mentorship geehrt, welches er im Alleingang ins Leben gerufen und aufgebaut hat. Das Tech-Mentorship, hat zum Ziel, dass Schüler mit herausragenden IT-Kenntnissen ihren Kammeraden den Umgang mit der Technik während dem Studium erleichtern und auch als Anlaufstelle für IT Probleme zur Verfügung stehen. Für diese ausserordentliche Leistung wurde er vom Ehemaligenverein der Kantonsschule am Brühl mit einem Preisgeld von 500 Franken ausgezeichnet. Zum anderen wurde Lukas für die beste Abschlussarbeit des Studiengangs WMI mit einer Note von 5,9 gewürdigt.

Lukas, die Compass Crew gratuliert dir auf diesem Weg nochmals ganz herzlich!

Grosse Teile der Erkenntnisse aus seiner Arbeit sind bereits in das neue Hands-on Seminar “Network Analysis & Advanced Persistent Threat” eingeflossen und ist somit den besten Experten im europäischen Raum zugänglich. Unsere Leser dürfen sich zudem auf die Publikation des entstandenen Whitepapers per Anfang September freuen.

Nächste Kurse
– 11. und 12. September 2014 in Bern, iPhone und iPad Security
– 11. und 12. November 2014 in Bern, Network Analysis & Advanced Persistent Threat

[1] HSLU MAS Information Security 
[2] SGRP Auszeichnung Alexandre Herzog für ” Crypto-based security mechanisms in Windows and .NET ” 



iPhone & iPad Security Kurs in Bern

Mobile Geräte sind ein wesentlicher Teil unseres Lebens, sowohl im Privaten als auch im Unternehmensumfeld. Diesen September führt Compass Security das erste Mal in Bern den iPhone & iPad Security Kurs durch.

  • Was sind die Sicherheitskonzepte bei iOS-Geräten?
  • Wie können iOS-Devices ins Unternehmensumfeld eingebunden werden?
  • Welches sind die gängigen Angriffe und wie kann man sich dagegen schützen?

Sind Sie an den Antworten interessiert? Dann ist dieser Kurs genau richtig für Sie!

Der Kurs bietet u.a. verschiedene Praxisübungen, um die neuen Kenntnisse zu festigen. Diese Praxisübungen stehen Ihnen auch nach der Schulung zur Verfügung. Anmeldungen sind bis Mitte August 2014 möglich.

Weitere Security Trainings bei Compass

Release of Smart Meter Security Controls Whitepaper at Hack in Paris 2014

This article was published when I just flipped through the final slides talking at “Hack in Paris” on smart meter wireless protocol issues. The combo of trainings, conference and the “nuit du hack” is held at the Disney Land Resort Paris for the 4th edition.


Yes, Disney Land. When I arrived at the hotel I ran into a crowd of kids gathering around Goofy. Their parents ready to capture to moment of joy. When I entered my room, a Pluto greeting card spread a warm welcome from the small desk. A Bambi painting decorates the wall and the body wash has Mickey Mouse ears at its cap.

Well, as unusual it sounds, isn’t it imagination, creativity and an urge to play what the venue and hackers share? We are definitely not the average visitor and this got immediately confirmed when I showed up at breakfast where the waiter somewhat puzzled asked me: “Combien ?”. Still watching at the corner, expecting kids and wife would turn up in a second. “No, je suis tout seul”, I answered with a smile :)

For Comic fans definitely a must see and must stay. The venue’s magic is what really matters in life: fun and family. So do hackers love to have fun and to share knowledge with equal minded.

While we are at sharing stuff. For those who have ever looked for a security checklist for smart meters. Here it is: compass_security_smart_meter_controls_whitepaper_v1.0

That checklist built the foundation of all my research. The full paper features a lengthy introduction and analysis based on the OCTAVE Allegro Risk Assessment method in order to identify suitable controls for smart meters. For the quick reader: Skip to chapter 3.3 for the total list of 43 smart meter controls. Your feedback is highly appreciated!

And here are the links to the HIP 2014 slides, the git repos and other related work

- Presentation Slides HIP 2014
- Whitepaper Blackhat 2013
- Google Go Sniffer & MUC (credits
- Python Sniffer „Scambus“
- GNU Radio wM-Bus (credits
- Clipart credits go to

For those interested in solving puzzles and hands-on security training sign-up for a free remote account and get knee deep into our virtual pwnable lab. Hacking-lab features a wide variety of information security, penetration testing, security assessment and forensics hands-on training exercises to educate students and information security professionals. Give it a try.


Compass Area 41 attendance

Area41 (@a41con) is a security conference held in Switzerland. Its the successor of the highly successful Hashdays. Several Compass Security Switzerland employees volunteered to help organizing this event. Some say, we completely infiltrated Area41!

The compound of Komplex 457 was pretty awesome. There was enough space in the main hall for to accommodate all viewers, and an additional second floor (balcony) with great view of the main stage (and also was close to several couches, the bar, the catering and most importantly the coffee machine). The second room was located underground in a former strip club, featuring red walls, which made the talks a lot more dirty ;-). A big outside terrace completed the temporary hacker epicenter.
Banashide (@banasidhe) organized the still tired group of volunteers, as we arrived on Monday morning. Biggest problem was the complete lack of coffee (Rumor had it that the four coffee machines were involved in an accident on the motorway). Fortunately, a big stash of Club Mate helped bridging this rough patch.

Between my shifts, I had the chance to attend several interesting talks.

In the Keynote (Slides), Halvar Flake (@halvarflake) showed that we are not able to check the integrity of software on our computer systems on any level (Userspace, Kernelspace, BIOS, …). So the only valid option after a compromise of a machine is to re-install it from a trusted medium. But there’s anyway little hope, as with Intel ME, we have component on our mainboard with full network- and memory access. Also we can’t check for BIOS backdoors, for example issued by the NSA. Additionally, the process of deploying and managing signatures creates a big amount of problems by itself.
For me, the request for integrity checks for the complete machine is bold, but necessary. I hope in maybe 30 or 50 years, we will be able to do so.

Rob Fuller (@mubix) gave an entertaining talk about free defenses (slides, from shmoocon), with many practical examples and penetration testing stories. For example, he told us about honeypots with port 23 open, or domain admin user with the password in the user comments, both immediately triggering an alarm if accessed.
In my opinion, those simple honeypots and triggers are immensely useful for any company to deploy, as they are cheap and with nearly no false positives.

Marc Ruef (@mruef) talked about his “baby”, the SCIP VulDB (slides). He showed us the weaknesses and faults of other vulnerability databases. Seemingly simple things like disclosure dates and version information (e.g. does “version up to 11″ include 11, or not? What does 2.x mean?) are handled differently and sometimes inconsistently by the various vulnerability DB’s.
As penetration tester, I depend on accurate information of vulnerabilities in vulnerability databases. It is necessary to correctly assert risks of installed software versions. The talk opened my eyes to the massive deficiencies currently prevalent in the reporting and management of security advisories.

Overall it has been an interesting and successful day. I intend to attend again next year!

OWASP Switzerland – SSL/TLS Talk

On this Wednesday (09.04.2014) I gave a presentation at OWASP Switzerland chapter. Initially I choose to present an overview of SSL/TLS, which is based on our previous blog article Compass SSL/TLS recommandations. Accidently, the timing with the OpenSSL heartbleed bug was perfect, so the presentation was updated in time with several slides about this current vulnerability.

I want to thank Sven Vetsch for the awesome organization of this event, and all attendees for their attention and interesting discussions. With 30+ people the room was fully booked, which is quite impressive :-)

Presentation download link:

Calculating RSA private keys from its public counterpart

Compass crew members just got back to work from a fun weekend/night at Insomni’hack (Geneva) where hackers met [0] to solve puzzles and enjoying the hacker community. On the way back home was sufficient time to clean-up systems and to reflect on some of the challenges.

There was a variety of brain teasing puzzles relating to application, network and computer security, digital forensics, reversing or steganography. During the contest the team gets more challenging puzzles unlocked by the time they hand in solutions. The solutions was always some sort of special formattet string a.k.a. token or nugget.

I decided to write-up one of the puzzles to have it documented of course and to provide you with an idea how such a puzzles looks like. So, let’s dig into it.

Challenge: “An ancient device is sending beacons. Let’s see whether we can derive information from it.”

The beacons received were


Interestingly, the number of beacons matches the number of characters required for submition to the nugget verification application of that hacking challenge and for some reason we also have a copy of a public key.

-----END PUBLIC KEY-----

As we all know, we can’t use that key to get any plaintext from information protected with an asymmetric cryptographic algorithm. However, let’s have a quick look on the parameters of the key:

$ openssl rsa -pubin -in pubkey.txt -modulus -text
Public-Key: (388 bit)
Exponent: 65537 (0x10001)

Usually, for sufficiently large and properly chosen keys, the derivation of the private key from its public coutnerpart is not possible. In this case, the key size is obviously not that large and as we have no other information so far, let’s try to bluntly factorize the modulus N.

You could either try to do so online [1] or use CryptTool [2].rsa_public_key_cracking

The result clearly shows that an unfortunate combination of primes was chosen as the base of the key material.


So let’s see whether we can calculate the RSA private key from the parameters we have already.

The private key d can be calculate from e and phi whereby

e which is the exponent (see public key dump)
phi(N) which is based on the factorized primes and calculates as (p-1)(q-1)

Hint: Depending on your code, you might want to put e in decimal rather than in hex 0×10001 to avoid spending to much time on debugging :)

Finally you will need to compute d = e^-1 mod phi(N) in order to get the private key.

Hint by M. «If you’re already using CrypTool anyway, you could also use it to calculate d from p,q,e without having to code anything on your own: Indiv. Procedures > RSA Cryptosystem > RSA Demonstration.»

If your prefer to solve it in python it’s far more challenging. I have not been very successfull in finding a python RSA library that allows for that specific calculation. Luckily there are lot’s of websites actually providing hints on how to calculate the modular inverse based on the extended euclidean algorithm. Thus I went for a copycat approach [3].

def egcd(a, b):
	x,y, u,v = 0,1, 1,0
	while a != 0:
		q, r = b//a, b%a
		m, n = x-u*q, y-v*q
		b,a, x,y, u,v = a,r, u,v, m,n
	return b, x, y

def modinv(a, m):
	g, x, y = egcd(a, m)
	if g != 1:
		return None
		return x % m

Finally, we will need to try whether the generated private key yields some resonable results on the beacons. The plaintext pt calculates as follows:

pt = beacon^d mod N

In python this is pow(beacon,d,n) rather than (beacon**d) mod n. Mathematically, both python statements should return the same result. However, pow is optimized to handle large factors whereas (beacon**d) mod n will take forever for RSA like calculations.

Finally, we get ASCII characters from each beacon which turned out to be the correct format and plaintext to qualify for a solution (python script –


And it did !!

Thanks to the SCRT team who actually built not only this but also other fun and challenging puzzles and thanks to those who were sufficiently patient to discuss twist and turns while battling!

For those interested in solving puzzles and hands-on security training join us for our awsome courses or sign-up for a free remote [4] account and get knee deep into our virtual pwnable lab. Hacking-lab features a wide variety of information security, penetration testing, security assessment and forensics hands-on training exercises to educate students and information security professionals. Give it a try.

[0] European hackers hit Geneva competition
[1] Online factor DB at
[2] CryptTool
[3] Extended Euclidean Algorithm Snippet
[4] Hacking-Lab

Lync – Missing Security Features

Microsoft has published a list of key security features [1] and also their security framework [2] for the Lync Server 2013. Those documents show how deeply MS integrated their SDL in the Lync products. It also indicates that Lync provides a solid security base out of the box:

  • Encryption enforced for all communication between Lync clients by default
  • RBAC approach for administration
  • Certificate-based authentication
  • Edge Server within DMZ as a first end point from outside and with no need for joining the domain
  • Good integration into the whole Windows infrastructure

However while Compass Security was reviewing and implementing Lync infrastructures, a few issues surfaced which aren’t optimal from a security point of view.

We have summarized some of the missing security features in Lync. As with our previous post about this topic(Lync – Top 5 Security issues, [3]), this list is not a finished catalog. But it may be helpful for others in an evaluation phase, or during implementation, to identify potential pitfalls.

Security Settings

One of the first things we got stuck with is the way security options are set (either with PowerShell or with the Lync Control Panel). All the security-relevant options are spread through different configuration “cmdlets”, or within different pages in the control panel. It’s like “where the hell is this option again?”.

There is no single place for these options, and it’s therefore difficult to setup a secure installation without detailed and in-depth know-how. Exchange 2007 and 2010 administrative interfaces are able to show the corresponding PowerShell script for each configuration setting, which can be immensely helpful for administrators. Sadly the Lync control does not have this useful feature.

We wish to see a dedicated “Security Settings” tab, and a more concise and well-arranged configuration UI. It should also enable the administrator to view the underlying PowerShell cmdlet’s.

File transfer

The transfer of files directly between Lync users can only be allowed or disabled for all Lync users at the same time (CsConferencingPolicy). A more granular file transfer approach cannot be achieved within Lync.

We would like to have the possibility to set these settings for specific user groups. It should also be possible to restrict (or completely deny) file transfer between internal and federated users.

Additionally, there is a blacklist for file extensions of transmitted files (CsFileTransferFilterConfiguration). However, a whitelist approach would be the preferred choice. For example the “.jar” extension is not in the blacklist by default in Lync 2013, a grave security vulnerability within enterprise environments (because of the high amount of Java vulnerabilities). It’s not difficult to find more extensions which should be blocked (especially if a generic archive tool like WinZip is installed on every workstation, which allows the user to open a myriad of different archive files, each with different file extension).

Furthermore, a dangerous setting is the “EnableFileTransfer” in the “conferencing options”. This setting is a per-organizer setting. Therefore, it is possible for a conference organizer to enable file sharing for conferences created by him, even if file sharing for conferences is disabled. The file transfer restrictions mentioned above can therefore be circumvented by every user which is able to create a conference.

An option should exist for Lync, which disables the ability for conference organizer to enable file sharing.

Some third party tools are able to solve some of the problems mentioned above by implementing more sophisticated filtering of file transfer on the Edge server.

Federation policies

The current implementation of federations assumes that the federated companies completely trust each other, or have at least a similar security policy. It is not really possible to restrict or confine external users. Some policy settings are described in a previous post about the privacy configuration [4].

As different companies may want to easily communicate, but not completely trust each other, we wish for much more granular permission/restriction policy for federated users. For example, it should be possible to only allow IM from internal users to federated users, but deny other communication channels.

Identification of mobile phones and external devices

Currently, every user which provides valid credentials is able to login into Lync. It is not possible to restrict access to certain devices. For example, Lync cannot deny access for insecure Android mobile phones, or only allow iPhones. Therefore, users are able to use Lync on insecure devices, and on as many devices as they want.

It should be possible to restrict access based on the operating system (a feature which already exists, but does not seem to work, CsClientVersionPolicy).

We’d also like to see Lync restricting logins to mobile devices which are managed by the company MDM solution.

Front-End server certificates

The certificates for the TLS-DSK authentication is implemented using the Lync PKI on the Front-End server. A company with an existing PKI can’t use their own certificates.

We wish to be able to use an existing PKI. The process of deactivating users would also fit better within existing company procedures, so that no additional “Lync-certificate-deactivation-process” must be implemented.

Two-factor authentication

The default authentication is based on AD credentials (username and password). It is not possible to enforce a two factor authentication. It was added with the Cumulative Update for Lync 2013 back in July 2013 (e.g. use of Smartcards) [5]. Unfortunately, this update only applies to Lync 2013 Desktop clients.

End-to-End encryption

As already noted in “Lync – Top 5 Security issues” [3], a complete end-to-end encryption is not available. In some scenarios a complete encryption between the endpoints in p2p conversations is a requirement. This is currently not possible with Lync 2013.


Despite a solid security baseline implemented in Lync, there are multiple issues regarding the administration and security needed in an enterprise environment. Lync is designed to easily communicate with different parties and integrates many different media feature like voice, video and IM. For high-sensitive environments this could be considered as too open for a sensitive-communication environment. To conclude this post, the following issues have been discussed: there is no single place for all security settings, file transfer cannot be restricted as needed with standard tools, there is no option to use end-to-end encryption between the clients, and it’s not possible to enforce a second factor for authentication for all devices.

So, we can summarize our wish list for an upcoming release (X-Mas is already over, but a major update is coming in 2014. And the next Lync release is coming too. Maybe.):

  • More obvious and centralized places for the security settings
  • A better file transfer restriction approach
  • A way to implement a second-factor authentication or an integration of 3th party second-factor tools
  • Better possibilities to identify and restrict Lync client devices


[1] Key Security Features in Lync Server 2013,, last visited 20.02.2014

[2] Security Framework for Lync Server 2013,, last visited 20.02.2014

[3] Lync – Top 5 Security Issues,, last visited 20.02.2014

[4] Lync – Privacy Configuration,, last visited 20.02.2014

[5] Planning for and Deploying Two-factor Authentication,, last visited 20.02.2014

Thanks to Dobin Rutishauser for research, review and discussions concerning this matter.

Lync – Privacy Configuration

We have shortly described the Lync federations in a previous post. With the usage of federations the question comes about the privacy and the security of the user’s information (e.g. presence information). There are scenarios where an employee doesn’t answer the phone but is mentioned as “available” in Lync. This could lead to a misunderstanding and bad mood at the customer’s or a partner’s side because the person “should” be available. Other scenarios involve e.g. stalking a given person using his present / idling status. These are just two practical examples – without mentioning any legal aspect – why there are good reasons to restrict access to this kind of information.

A further restriction could be set to only allow communication request of persons who are already in the contact list. Lync doesn’t offer many options for this. So in this post we try to show you the spot to look at to enhance privacy in Lync.

The following cmdlets are involved depending on your infrastructure:

  • CsPrivacyConfiguration
  • CsAccessEdgeConfiguration
  • CsHostingProvider
  • CsPublicProvider

Lync offers an option to limit access to your presence information to the people you already have in your contact list. Unfortunately, there is no distinction of corporation: you can’t just give access to your presence information to people of your company while restricting access for federated contacts present in your contact list. So either restrict access for all or nobody in your contact list.

Quote from “Configuring Enhanced Presence Privacy Mode” [2]:

“With enhanced presence privacy mode, users can restrict their presence information so that it is visible only to the contacts listed in their Lync 2013 Contacts list. The New-CsPrivacyConfiguration and Set-CsPrivacyConfiguration cmdlets have an EnablePrivacyMode parameter controls this option. When EnablePrivacyMode is set to True, the option to restrict presence information to contacts becomes available in the Lync 2013 Status options. When EnablePrivacyMode is set to False, users can choose either to always allow everyone to see their presence information or to adhere to any future changes the administrator makes to the privacy mode.”

PS> Get-CsPrivacyConfiguration

Identity : Global
EnablePrivacyMode : True
AutoInitiateContacts : False
PublishLocationDataDefault : False
DisplayPublishedPhotoDefault : False

Further quote from [2]:
“[…]Lync 2013 and Lync 2010 privacy settings are not honored by previous versions (Microsoft Office Communicator 2007 R2 or Microsoft Office Communicator 2007). If previous versions of Office Communicator are allowed to sign in, a Lync 2013 user’s status, contact information, or picture could be viewed by someone who has not been authorized to view it […]

In a migration scenario and due to these aforementioned compatibility reasons, enforce the following points before you enable enhanced presence privacy mode:

  • Ensure that every user has Lync 2013 installed.
  • Define a client version policy rule to prevent previous versions of Communicator from signing in.


Lync Server 2013 has public provider configurations for America Online, Windows Live and Yahoo! instant messaging. Each public provider is configured with the provider’s Edge server fully qualified domain name, and the default verification level is set to “Allow users to communicate only with people on their Contacts list who use this provider” (CsHostingProvider and CsPublicProvider). This default setting will limit communication to contacts that you have accepted and are in your contact list.

Selecting “Allow users to communicate with everyone using this provider” removes the restriction. Anyone can now retrieve your presence information, without you received and accepted a contact invite. This setting does not limit who can contact you from the public provider’s network.

A further VerificationLevel property is used to monitor and assess the verification level of incoming messages (CsAccessEdgeConfiguration, [3]). Valid values are:

  • AlwaysVerifiable: All requests received on the default route are marked as verified. If a verification header is not present it will automatically be added to the message.
  • AlwaysUnverifiable: Messages are passed only if the addressee (the user the message is intended for) has configured an Allow ACE (access control entry) for the person who sent the message.
  • UseSourceVerification: Message verification is based on the verification level included with the message. If no verification header is present then the message will be marked as unverified.

We strongly recommend to use “AlwaysUnverifiable” for the VerificationLevel.

There are not many options to limit access to presence information and how the communication is established to federated users, but the few options should be evaluated during the implementation phase. With the privacy setting, the users are able to restrict access to their presence information for those people who are on their contact list.

We recommend to use the privacy mode and to restrict the communication establishment as strictly as possible.

[1] Privacy supplement for Microsoft Lync 2013,, last visited 26.01.2014
[2] Configuring Enhanced Presence Privacy Mode,, last visited 26.01.2014
[3] Set-CsAccessEdgeConfiguration,, last visited 26.01.2014

Lync – Top 5 Security Issues

Microsoft Lync Server (a combination of “link” and “sync”, see [6]) communications software offers instant messaging (IM), presence, conferencing, and telephony solutions. Lync can be integrated with SharePoint or Exchange to extend its functionalities. Users can e.g. search for specific skills within the Lync client when SharePoint integration is enabled. Exchange is used as a unified store of different user specific data, like contact list.

As we are seeing in our daily business, Lync is becoming more and more a widespread collaboration platform within many companies. Therefore, it’s important to know the issues when implementing Lync and especially the hot spots for weaknesses to keep in mind during concept creation. This blog post will describe some of the top issues, without formal priority.

Lync has many security features built-in. Encryption is for example used by default and cannot be turned off since Lync Server 2013. Furthermore, internal user authentication is handled via Kerberos or client-certificates.

On the other hand, some features like the Federations (connection with other companies) highly increase the attack surface. Additionally, external users can authenticate themselves with NTLM. Therefore, attacks against the user accounts are possible. When not using Federations and external access, many security implications could be eliminated if no Edge server is in use. On the other side, the ease of the use of external access is a great advantage in Lync.

A very basic Lync topology is depicted in the following picture to show the weak spots described later in this post. The numbers on the arrows refer to the sections below.
Lync Topology diagramEdge Server allows us to communicate and collaborate with users located outside the firewall. Remote users (internal users working outside the network) or users from other companies (Federations) connect into the network through the Edge server.

Front-End-Server is used for user authentication and handling of all communication features (IM, voice). It’s responsible for registration and routing requests. All Web components, such as Address Book or the Control Panel (administration panel) are located on the Front-End-Server.

The Director role is used as an intermediate stop between the external users and the Front-End-Server. The Director does not host users but, as a member of an Active Directory domain, it has access to Active Directory Domain Services for purposes of authenticating remote users and routing traffic to the appropriate server or Enterprise pool. Directors can authenticate requests before they are passed to the internal servers. DoS attacks ends on the Directors and don’t reach the Front-End-Servers.

External access (remote users and Federations) is the possibility to use the Lync infrastructure from outside the company’s network. Federations give the possibility to communicate between different companies using Microsoft’s unified communication software. Full communication is possible (VoIP, messaging, conferencing). Remote access is also possible with mobile phones.

1. Threats because of Federations
The following policies are used to control federations and external access:

  • CsExternalAccessPolicy
  • CsAccessEdgeConfiguration

To allow federation on the Edge Server use the following PowerShell command (“Import-Module Lync” if the normal PowerShell is used):

Set-CsAccessEdgeConfiguration –AllowFederatedUsers:$True

Read the AccessEdgeConfiguration:


A further step is needed: every user must be covered by a CsExternalAccessPolicy that enables federation for those users.

Set-CsExternalAccessPolicy –Identity <scope> -<Enable*Access>
  • <Enable*Access> can be one of the following, depending on your needs: EnableFederationAccess, EnableOutsideAccess, EnablePublicCloudAccess, EnablePublicCloudAudioVideoAccess, EnableXmppAccess
  • EnablePartnerDiscovery should be set to false, to restrict federation to those domains specified manually. Otherwise, it enables open federation where companies looking to federate will locate each other through the DNS SRV records and connect automatically.
  • Be careful which external access is allowed for which users (federation, remote user, public IM connectivity, see [5] for more details about the different possibilities).

To see which domains are allowed and/or blocked, use the following get-cmdlets:


Inspecting chat traffic and disabling file transfer for only external communication is difficult in Lync. There is no known solution which implements this need. However, traffic monitoring could be applied for specific connections but preventing leakage of a company’s data isn’t available out of the box. This must be considered and kept in mind when using Federations or other external access.

If not used, Federations should be deactivated to mitigate the new possibility to exfiltrate data from the internal network to the outside and therefore bypass possible existing data leakage prevention (DLP) mechanisms.

2. NTLM AD lockouts without proper Edge Server security
The Edge server receives the authentication requests from external users and passes them to the Director resp. to the Front-End-Server. The authentication itself is performed by either one of these two servers inside the network against the Active Directory (AD). NTLM authentication is used when certificates aren’t available.

Therefore, NTLM lockout attacks could be performed against internal users. To mitigate this issue, block NTLM requests from outside and use only certificate based login for external users. This can be enforced by a policy which requires that the initial login request (always NTLM or Kerberos based) is only performed from inside the internal network.

Besides blocking NTLM request, the use of a security filter on the Edge server could be used to prevent the lockout of internal AD user. Such security filters handle failed login attempts on the Edge Server and don’t pass every login request to the Director or Front-End server.

3. The “Certificate-based-login” pitfall
Using certificate authentication has many advantages. One of them is availability: when a domain controller is not reachable, users can still log in because authentication relies solely on the client certificate. However, if the users are disabled in Lync and/or in the AD, they can continue to log in (which was an advantage one sentence earlier). Business processes such as those handling the decommissioning of user accounts must be adapted accordingly to prevent further usage of Lync for a disabled user (see [2][3]).

You can read the certificates used by a user with the following PowerShell command:

Get-CsClientCertificate –Identity <userID>

Revoke these certificates with the following command:

Revoke-CsClientCertificate –Identitiy <userID>

<userID> is the SIP name of the user, e.g. sip:name@lync-domain.tld

You can also use the Control Panel to revoke the certificates by using “Remove user certificate” on the specific user.

Really important side-note: A certificate is generated for each individual client, not each user. So the same user can have many certificates depending on the amount of devices he installed Lync on.

4. No End-To-End Encryption
The IM and web conferencing are encrypted between the different Lync components (e.g. Client and Front-End) but not end-to-end from the Client to the Client. There is no mitigation for this within the Lync environment and must be considered when evaluating it. This has different desired and needed reasons, e.g. archiving, monitoring or troubleshooting. Audio and video can’t be archived and are always encrypted between the endpoints (for federated partners, the Edge server is still in the middle). See [4] for more details about the communication paths.

However, the ability of snooping traffic on the Front-End-Server conflicts with the requirements for privacy and end-to-end encryption. Even Microsoft itself gives detailed instructions how to intercept the traffic, for troubleshooting reasons of course (e.g. [1], could also be done with Wireshark). And don’t forget the Lync archiving mechanisms which record all the data.

5. Role-Based Access Control (RBAC)
Lync introduced RBAC in Lync Server 2010 and enhanced it in Lync Server 2013. With RBAC, administrators can be granted only permissions they really needed for their tasks. An administrator is e.g. granted the rights to run certain PowerShell cmdlets. Cmdlets are used in the PowerShell to perform an action and typically return a Microsoft .NET Framework object to the next command in the pipeline. Besides a nice collection of predefined RBAC roles, custom roles can be created and then used to secure the execution of specific cmdlets.

The really important fact is, that RBAC only takes effect when you are using PowerShell or the Lync Control Panel (which in fact only executes cmdlets) remotely. You can see the cmdlets you are allowed to run by executing the following command:


To see the allowed cmdlets for a specific role, use the following command

Get-CsAdminRole [-Identity <role-name>]

The “Cmdlets” description is limited within this output. With the following command, you can expand this attribute:

Get-CsAdminRole –Identity <role> | Select-Object –ExpandProperty Cmdlets

When using the LSMS (Lync Server Management Shell) or the Control Panel on the Lync Server, the RBAC isn’t used. Instead the administration rights are governed by membership of the Real Time Communications (RTC) named groups.

Check roles and users in the special Lync groups and apply a strict RBAC approach. Follow the least privilege principle and only grant minimal permissions for the required cmdlets.

The most powerful Lync RBAC groups are:

  • CsAdministrator
  • CsServerAdministrator
  • CsUserAdministrator

Interesting fact: although CSAdministrator has the most functionality available in a role, it doesn’t enable you to run all the commands that exist in the Lync PowerShell.

The most powerful Lync RTC groups are:

  • RTCUniversalServerAdmins
  • RTCUniversalUserAdmins

As we just saw, Lync is a versatile solution which affects different components in an existing infrastructure. A default Lync installation has many security features available and enabled. It is important to understand its architecture and features before implementing it. There are different issues which must be kept in mind when using Lync. The above list should give you an overview about different spots to look at. We’ve seen that Federations gives a great new possibility to easily connect companies, but there are privacy issues and the NTLM attack vector which could be opened when not using the correct configuration. Or the new certificate based login approach increases the security of the login procedure but raises the new risk that a disabled user can continue using Lync.

This leads to the conclusion that despite a quit secure default installation of Lync, a proper understanding of all the security features and configuration must be acquired and applied to provide the most secure environment.

Further blog posts regarding Lync security features:

[1], last visit on 15.01.2014
[2], last visit on 15.01.2014
[3] Mastering Lync Server 2013, Keith Hanna, Nathan Winters, 2013, p. 90
[4] Microsoft Lync Server 2013 Protocol Workloads Poster,, last visit on 15.01.2014
[5] Overview of External User Access,, last visit on 15.01.2014
[6] Lync Server 2013,, last visit on 15.01.2014

Advisories regarding Leed and Secure Entry Server (SES)

Today I’m happy to release the following security advisories:

I would take the opportunity to thanks Valentin CARRUESCO aka Idleman for the timely patches he implemented within Leed.

Of further interest is the vulnerability which affected the SES as it was due to a common mistake made when validating URLs. Let’s illustrate the issue with another occurrence of the same flaw, which affected LinkedIn and was reported back in November 2012.

Back then, attempts to visit a page reserved to LinkedIn members only triggered a redirect to the following login page:[original_page]

Variable session_redirect was used to keep track of the initially desired page. Once successfully logged in, the web application would redirect us straight to this page using the following AJAX response:


Attempts to misuse this mechanism and inject a full URL in parameter session_redirect (e.g. would fail, presumably because the developers ensured that the first character of value session_redirect had to be a slash (or its URL-encoded hex value %2F).

But what about partial URL // Based on the aforementioned logic, such an URL would be considered as safe by the code, as it starts with a slash. But modern browsers don’t interpret a redirection to // as being http(s)://[victim]//, but in fact as a redirection to http(s):// This behaviour is RFC conform and commonly used over the Internet to embed resources regardless of the URL scheme (http if the initial page was called over http, https if called over https).

Was it possible to abuse LinkedIn and the SES with such a trick? Yes, here’s an illustration of it:

Attempt to login on LinkedIn using forged URL (note the double slash – %2F%2F)

2013-12-04 12_52_00-Clipboard

Pressing button “Sign In” would submit the entered credentials. An extract of the AJAX response is shown below:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
[removed various Set-Cookies directives]
X-LI-UUID: B[base64_stuff]nsg==
[removed various Set-Cookies directives]
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache
Cache-Control: no-store
Vary: Accept-Encoding
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Date: Sat, 10 Nov 2012 11:45:45 GMT
Age: 1
Connection: keep-alive
Content-Length: 52


The browser would then interpret this redirection as being meant for [scheme]://test/phishing.html and perform the according request as seen below:

GET /phishing.html HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

2013-12-17 11_58_10-Clipboard

The issue was reported to LinkedIn in November 2012 and fixed without further acknowledgement.

As a conclusion, do not assume that a partial URL value starting with a slash will always represent a path on your website. It may as well be a valid URL representation pointing to another domain. Furthermore, always perform redirections using a full qualified domain name and don’t just rely on a partial URL representation.