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 – calculation.py).


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 hacking-lab.com [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 http://www.skynews.com.au/tech/article.aspx?id=960593
[1] Online factor DB at http://www.factordb.com/
[2] CryptTool http://www.cryptool.org/en/download-ct1-en
[3] Extended Euclidean Algorithm Snippet http://en.wikibooks.org/wiki/Algorithm_Implementation/Mathematics/Extended_Euclidean_algorithm
[4] Hacking-Lab http://www.hacking-lab.com/

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, http://technet.microsoft.com/en-us/library/dn342829.aspx, last visited 20.02.2014

[2] Security Framework for Lync Server 2013, http://technet.microsoft.com/en-us/library/dn481316.aspx, last visited 20.02.2014

[3] Lync – Top 5 Security Issues, http://blog.csnc.ch/2014/01/lync-top-5-security-issues/, last visited 20.02.2014

[4] Lync – Privacy Configuration, http://blog.csnc.ch/2014/01/lync-privacy-configuration/, last visited 20.02.2014

[5] Planning for and Deploying Two-factor Authentication, http://technet.microsoft.com/en-us/library/dn308563.aspx, 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, http://office.microsoft.com/en-us/lync-help/privacy-supplement-for-microsoft-lync-2013-HA102762444.aspx, last visited 26.01.2014
[2] Configuring Enhanced Presence Privacy Mode, http://technet.microsoft.com/en-us/library/gg399028.aspx, last visited 26.01.2014
[3] Set-CsAccessEdgeConfiguration, http://technet.microsoft.com/en-us/library/gg413017.aspx, 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] http://blogs.technet.com/b/nexthop/archive/2012/02/15/how-to-decrypt-lync-2010-tls-traffic-using-microsoft-network-monitor.aspx, last visit on 15.01.2014
[2] http://www.expta.com/2011/03/disabling-user-in-ad-does-not-disable.html, 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, http://www.microsoft.com/en-us/download/details.aspx?id=39968, last visit on 15.01.2014
[5] Overview of External User Access, http://technet.microsoft.com/en-us/library/gg398775.aspx, last visit on 15.01.2014
[6] Lync Server 2013, http://office.microsoft.com/de-ch/lync/, 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:


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. session_redirect=https:%2F%2Fwww.csnc.ch) 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 //www.csnc.ch? 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 //www.csnc.ch as being http(s)://[victim]//www.csnc.ch, but in fact as a redirection to http(s)://www.csnc.ch. 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) https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

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
Referer: https://www.linkedin.com/uas/login?session_redirect=%2F%2Ftest%2Fphishing.html

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.

Compass SSL/TLS recommendations

Mozilla created an extensive page [7] concerning the best current choice of SSL/TLS cipher suites, primarily for web servers. Compass Security agrees broadly with the article, but recommends some additional restrictions in order to provide the most resistance against active and passive attacks versus TLS secured connections:

  • Use 3DES cipher instead of RC4
  • Disable SSLv3 support

Compass Security recommends against using RC4, and favors 3DES for a transitional period. 3DES only provides 112 bit keys (and may therefore be more prone to brute force attacks on the key), but is otherwise regarded as not (yet) broken. RC4, on the other hand, is considered not secure anymore:

  • A “nearly practical” attack exists, as the first bytes of the stream cipher are biased (not perfectly random)[4]
  • Microsoft recommends to disable it, and warns developers to not use it anymore [1]
  • The NSA is suspected to be able to decrypt it in real-time [2][3]
  • RC4 was primarily used to thwart BEAST and Lucky13 attacks. But BEAST is fixed on current browsers. Exploiting Lucky13 is currently not practically feasible [6]

For additional security, it is possible to remove SSLv3 support altogether, as it contains several weaknesses:

  • Weaker key derivation process than TLS
  • Cannot be validated under FIPS 140-2
  • There have been various attacks on SSLv3 implementations
  • Vulnerable to certain protocol downgrade attacks

TLSv1.0, which was released in 1999, contains several additional security features in comparison to SSLv3. For example, it uses both SHA-1 and MD5 at the same time, making it less vulnerable if one of these hash functions becomes insecure.

All browsers, except IE6 on Windows XP (in its default configuration) support at least TLSv1.0. The default IE8 browser on an up-to-date Windows XP, happily connects to TLS-only web servers. Nevertheless, other software may not be compatible with such an restricted configuration yet.

Furthermore it is recommended to turn off TLS compression. This will fix the CRIME attack on TLS connections, even if vulnerable OpenSSL implementation on the server is being used, while an obsolete browsers which do not have this issue fixed is connected. If the server uses current OpenSSL library, and/or the client has the CRIME fix implemented, this attack is not feasiable anyway. Turning off TLS compression will not mitigate the BREACH attack, as it uses the compression feature of HTTP, not TLS. See [12] for further information about this issue.

This concludes the discussion about most of the currently known SSL/TLS attacks, and their mitigation.

Apache Configuration

The following chapter provides an Apache configuration example, which incorporates the discussion above. It is based on  https://wiki.mozilla.org/Security/Server_Side_TLS#RC4_weaknesses

The implemented cipher prioritization logic is as follows:

  1. Most secure TLS 1.2 ciphers first: AES-GCM
  2. AES with PFS: ECDHE (Elliptic Curves)
  3. AES with PFS: DHE (Traditional RSA)
  4. AES128
  5. AES256
  6. 3DES

The cipher prioritization list:


Virtual host SSL configuration:

<VirtualHost *:443>
    SSLProtocol             All -SSLv2 –SSLv3
    SSLCipherSuite          <recommended ciphersuite from above>
    SSLHonorCipherOrder     on
    SSLCompression          off # default off, except in 2.4.3 and 2.2.24 to 2.2.25
    SSLInsecureRenegotiation off # default

This TLS- and AES/3DES-only configuration was successfully tested with current versions of IE8, Chrome and Firefox on Windows XP.

Windows IIS

Example configuration settings for Windows. This should act as a basic configuration skeleton. Before deployment, the configuration needs to be actively tested in an production environment. The cipher list has been extracted on a Windows 7, but is identical to that of a Windows 2012 Server.

Disabling SSLv2 and SSLv3:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server] 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server] 

Cipher list:

  10. RSA AES
  11. RSA 3DES

Configure Schannel according to the recommendations above and these pages:

Further Recommendations

This renewal in favor of more secure SSL ciphers can be a good opportunity to kick-off further clarifications and investigations about SSL related topics in your company, e.g.:

  • Is all your web infrastructure (proxies, WAFs, web servers, …) ready to support TLSv1.1 and TLSv1.2?
  • Are the clients you manage use an adequate configuration for setting up SSL communication (e.g. Prioritizing Schannel Cipher Suites for Windows clients)
  • Have your SSL certificates a 2048 bit private key?
  • Have your CA SSL certificates a 4096 bit private key?
  • Does your internal PKI enforce best practices and is moving to SHA2 and ECC? [10][11]
  • Are you using the most current version of the webserver?
  • Are you using the most current version of OpenSSL?


  1. Microsoft recommends disabling RC4
  2. Article about suspicious that NSA is able to decrypt RC4
  3. Article about suspicious that NSA is able to decrypt RC4, german
  4. Bruce Schneier about attack on RC4 from spring 2013
  5. Discussion “RC4 is kind of broken in TLS”
  6. Qualys Discussion about retiring RC4
  7. Mozilla Article about SSL ciphers
  8. Qualys SSL Test
  9. Web Browser Support Matrix
  10. MS SHA1 deprecation policy
  11. Windows Root Certificate Program – Technical Requirements version 2.0
  12. Nginx SSL Module
  13. Qualys – Defending against the BREACH Attack

Thanks to Alexandre Herzog for research, review and discussions concerning this matter.

SuisseID-basierte Authentisierung mit Apple OS X

Apple veröffentliche 2006 ein Setup-Guide für die Benutzung von OS X mit Smartcards. Die Anleitung basiert auf der Version 10.4 ist somit nicht mehr aktuell. Die Prinzipien sind allerdings nach wie vor anwendbar und benötigen nur ein paar wenige Anpassungen, wie das folgende Proof-of-Concept zeigt. Es existieren drei Möglichkeiten unter OS X die Smartcard mit einem Verzeichnisdienst (lokal oder entfernt) zu assoziieren:

  • PubKeyHash
  • Attribute Matching

Im Folgenden wird das Standardvorgehen beschrieben, um eine lokale Smartcard-Authentisierung mittels PubKeyHash zu konfigurieren. Bei dieser Methode wird ein öffentlicher Schlüssel der Smartcard mit einem Benutzerkonto verknüpft. Möchte sich dieser Benutzer anmelden, dann steckt er die Smartcard ins System und gibt den korrekten PIN ein. Eine Nachricht wird dann digital mit dem Privatschlüssel signiert und mit dem öffentlichen, im System gespeicherten verifiziert. Dadurch kann, analog zur Authentisierung via SSH, die eindeutige Zuordnung vom Inhaber der SuisseID zum Benutzerkonto sichergestellt werden.

Zunächst werden die Hashes der öffentlichen Schlüssel auf der SuisseID gelistet. Dies geschieht mit dem Kommando ‘sc_auth’.

$ sc_auth hash | grep SwissSign
 AA779E7AD6DBB45AFCA48C64F1118E115DFB5604 SwissSign_nonRep
 B6EFD1C9C5DA0D4B70E18B580BD22757D53D79AA SwissSign_digSig

Anschliessend wird der Hash des Authentisierungsschlüssels dem entsprechenden Benutzer zugewiesen, in diesem Beispiel dem Benutzer namens ‘sc’:

$ sudo sc_auth accept -u sc –h B6EFD1C9C5DA0D4B70E18B580BD22757D53D79AA

Zuletzt muss das OS X-Authentisierungssystem für die Smartcard-Verwendung konfiguriert werden, in der Datei “/etc/authorization”. Am einfachsten geschieht dies mit dem PlistBuddy-Befehl:

$ sudo /usr/libexec/PlistBuddy -c "add rights:system.login.console:mechanisms:0 string builtin:smartcard-sniffer,privileged" /etc/authorization
$ sudo /usr/libexec/PlistBuddy -c "add rules:authenticate:mechanisms:0 string builtin:smartcard-sniffer,privileged" /etc/authorization

Nach den obigen Änderungen kann auf der Anmeldemaske die SuisseID eingesteckt werden. Der Dialog erkennt die Zuordnung zum Benutzer ‘sc’ und ändert das Eingabefeld von ‘Kennwort’ zu ‘PIN’. Allerdings scheitert die erfolgreiche SuisseID-Anmeldung noch. Eine Anfrage auf der entsprechenden Mailing-Liste hat zur Lösung geführt. Dem Betriebssystem muss nämlich zusätzlich die vollständige Zertifikatskette innerhalb des sogenannten System-Schlüsselbunds zur Verfügung stehen. Ein Import der Zertifikate in den Schlüsselbund “Authentisierung” ist nicht ausreichend. Sobald die Zertifikate importiert werden, funktioniert die SuisseID-basierte Authentisierung problemlos:


Abbildung: SwissSign-Zertifikatskette muss im Schlüsselbund System importiert werden

Wichtig ist zudem, dass die OpenSC-Tools nicht installiert sind resp. vorher deinstalliert werden, falls sie noch von etwaigen Tests installiert sein sollten, da sie die System-Treiber für die Smartcard-Authentisierung übersteuern, wie folgende Log-Ausgabe zeigt:

Aug 12 15:34:12 macmini.local com.apple.SecurityServer[15]: reader ACS
 ACR 38U-CCID 00 00 inserted token "SwissSignID "
 (9cde5b4dfbf9110fb3c13803a5498a1635b2e538) subservice 3 using driver com.apple.tokend.opensc

Eine Deinstallation der OpenSC-Tools erfolgt mit dem mitgelieferten Deinstallations-Script:

$ sudo /usr/local/bin/opensc-uninstall

ASFWS slides and OWASP meeting tomorrow

As announced a while ago, I had the chance to organize both a workshop about our hacking-lab.com and present my talk “Advances in secure (ASP).NET development – break the hackers’ spirit” at the AppSec Forum Western Switzerland in Yverdon-les-Bains last week. I hope to soon summarize the conferences I attended in an upcoming blog article.

In the meantime, the Swiss French television RTS was part of the workshop and did a reportage aired during the 12:45 Téléjournal:


As the slides are not yet published by the conference, you can already download them from this blog:

For those interested in seeing my talk live, join us tomorrow evening at 18:00 for the OWASP Zürich meeting. Registration is required and further details are available on http://lists.owasp.org/pipermail/owasp-switzerland/2013-October/000257.html.

Compass Security at ASFWS in Yverdon-les-Bains


Compass Security is proud to be part and sponsor of the Application Security Forum – Western Switzerland (ASFWS), a conference about application, identity and cyber security which will be take place in a week’s time in Yverdon-les-Bains (15-16 October 2013).

I will run the AppSec Lab 1 (featuring the Hacking-Lab), on Wednesday 16 October in the morning. The Lab will feature various different in-depth lab cases, with the primary focus on OWASP top 10. Everybody can join in and hack, either to learn, or to compete against other participants.

In the afternoon, I will also give a talk with the title “Advances in secure (ASP).NET development – break the hackers’ spirit”. The presentation includes a discussion of security features in the cutting edge (ASP).NET 4.5, and key security points of the application lifecycle.

As sponsor, Compass Security is happy to offer 3 tickets for the conferences held Wednesday 16 October from 13:30 on. To participate, be the quickest to send me a short email in French (as the conferences being mainly held in this language) at: alexandre [dot] herzog [at] csnc [dot] ch. Winners will be notified individually via email. Good luck!

I’m looking forward meeting you at this occasion, either during the “Soirée Château” network event, the workshop or the conferences!