Slides available on

Alok Menghragani already presented the initial keynote of the conference. This time, he presented us a personal project, not linked in any ways to his current employer. Started in 2008, OPA is an open-source framework designed for being used by companies. Instead of having to learn different technologies for different platforms, all in OPA is in JavaScript, for both the front and the backend systems. On the backend, OPA will rely on node.js while on the client side it will generate HTML and JavaScript for the browser. The most interesting part of the framework is the slicing feature, where OPA detects at compilation time if the code needs to be run on the server side, or on the client, and this without further manual intervention needed. The presentation went along with several examples of this functional language and shows the beauty of it, where no operations such as string concatenation are required.

Update: Alok’s presence at the conference and in Switzerland generated media coverage in the French part of Switzerland, e.g.:

ASFWS – Mimikatz

Slides available on

Benjamin Delpy, aka GentilKiwi, presented us the sekurLSA and crypto part of his trendy and increasingly famous tool called Mimikatz. If you haven’t heard of it yet, I’m convinced that once you read this article and the slides, you’ll certainly want to try out this great tool immediately on a Windows machine and experiment with its astonishing features. The tool itself is available in two modes, either a standalone executable or combined with a DLL which does the work.

We started the presentation with several attacks available against Windows operating systems, and how we often focus on dumping hashes and the SAM. This data is than usually used for pass-the-hash or pass-the-ticket attacks, or misused to increase the carbon footprint of your computing cluster in an attempt to crack the password hashes. But Windows offers several credential authentication providers, which keep your account details in memory:

  • TsPkg is used for Terminal Server authentication
  • msv1_0 for NTLM
  • Wdigest for a proprietary Outlook Web Access authentication
  • LiveSSP (for Hotmail – especially useful for Windows 8)
  • etc.

When run with local administrator rights (or with debug privileges), Mimikatz will search the whole memory to find all used credential providers and extract data from them. For a few credential providers, APIs are provided by Microsoft to retrieve them if you know their Local User ID (LUDI), information which can be gathered by tools such as Sysinternals PsLoggedOn. The password, at this stage, isn’t in clear text but protected by the LSA “Protect Memory” function – which you can use as SYSTEM of your own to decrypt the credentials! We now have clear text passwords of all the users who are logged into this machine (or think “Citrix server”).

This is not the end of the story, but just the start of the fun. Credential Provider TsPkg gets populated not only when a logged in user connects the first time to a terminal server, but as soon as the user logs into the machine. Furthermore, Mimikatz doesn’t limit itself to user credentials, but you can also extract all the details of the machine account (each joined machine to a domain having a dedicated set of credentials).

Mimikatz doesn’t only offer nice listings of all possible credentials found on the system, but will also spawn new processes under the desired identity. It is therefore trivial to start a new process under a stolen identity, without having to bother about getting adequate and dedicated tools for exploitation on the tested box.

One obvious credential provider for Windows we haven’t talked about yet is Kerberos. Benjamin Delpy’s findings regarding this are – again ? – disturbing: while the Kerberos tickets can (almost obviously – now that we see all possibilities of the tool) be recovered from memory using the same techniques, the same applies for the Kerberos password, aka domain password. Why that? A supposition of Benjamin Delpy is that the password is used to get a new set of tickets, when all previously issued tickets expired and an issue (e.g. offline) prevented them to be renewed. This remains an assumption though, as Microsoft did not comment on this point nor explain its move.

A corollary of this Kerberos issue is that even if you own a 100% Windows 2008 domain and disable all credential providers (operation by the way unsupported by Microsoft) but Kerberos, an attacker will still be able to gather valid domain passwords on a compromised machine he was able to root.

What about SmartCard authentication? As already known, the usage of SmartCard doesn’t disable the NTLM mechanism and when you log in, you’ll always get a NTLM hash back from the server. This can then be used for a more traditional pass-the-hash attack.

Up to this point, we covered only features of sekurLSA – but Mimikatz has several other options, the second and last presented today being the crypto part.

The main idea is to have a look how certificates, especially private keys, are stored and protected in Windows. The goal of an attacker would typically be to export all private certificates of a victim, despite the “not exportable” feature of the operating system. Is this possible (well, you guess it is now…) and how?

For the standard crypto API, it’s very easy. Mimikatz just overwrites 4 octets in memory where the “not exportable” flag is set and you’re already done. Note that the standard crypto API in Windows runs in user land, meaning that for this specific attack you do NOT need to be local administrator of the machine – every user can export its own private keys despite the famous checkbox option! If you test this yourself, rely on the certutil command line tool rather than the MMC snap-in, the latter being buggy and disallowing you saving the private keys even when they were genuinely marked as exportable.

What about cryptoNG (alias Crypto New Generation), a newer implementation of Microsoft? The whole process now runs in LSASS now, so a standard user can’t mess with it anymore. But again, local administrators are free to poke around and overwriting 1 octet in the memory of LSASS is enough to export the private key this time. A concerning finding is that not only active certificates can be exported, but it turned out that left overs of presumed deleted certificates were also found on such a machine. In clear text, this means that once a private key has been imported on a machine, you need to restage it to ensure that the private key isn’t accessible to an attacker on it – just “deleting” the certificate is not enough. This also means that people handling certificates daily (e.g. a PKI admin or PKI officer) gets suddenly a very interesting target as they are likely to install and delete such entries on a daily basis.

Finally we were getting to the end of this talk, but before this the author of Mimikatz was to remind that there are other features in its tool, such as for example an AppLocker bypass. Time for questions now: asked about the position of Microsoft about all his findings, Benjamin Delpy replies that Microsoft stated this was all normal, even the storage of the password within the Kerberos credential provider. At the question how all the information was gathered, the author referred to several slides of its presentation (especially the usage of the Microsoft symbol servers and MSDN, where most of the structures are documented). At runtime, Mimikatz does lots of pattern matching in memory to identify the relevant structures. These patterns can obviously be found in the source code of the tool, available online.

ASFWS – Obfuscator, ou comment durcir un code source ou un binaire contre le reverse-engineering

Slides available on

Both presenters, Pascal Junod and Jean-Roland Schuler work for the HES-SO – the University of Applied Science Western Switzerland. This talk is the follow-up of last year’s presentation, including the improvements done since. While Pascal Junod, from the HES-SO HEIVd (Yverdon-les-Bains) focused on obfuscating binaries based on their source code, Jean-Roland Schuler of the HES-SO EIA of Fribourg applied other obfuscation techniques based directly on ELF binaries, where no source code was available anymore.

The first part was an introduction about obfuscation and why this was different from standard protection techniques. The main idea is that usually you protect yourself against security threats. But confronted to an attacker, who got a copy of your software, you can’t as the attacker can isolate himself for reverse engineering the product, without you being able to detect this ongoing analysis. Combined with the rise of features available within the cloud (e.g. AWS used to perform some brute force), software copy protections and DRMs have less and less chances of being kept unbroken. The HES-SO project about code obfuscation started based on the fact that there are lots of obfuscation products available, but mostly on high-level languages. For C / C++, only a few options were available and none of them was open source.

Let’s dive into the source code obfuscation part done by Pascal Junod: it is based on the LLVM compiler which produces an “intermediate language”, close to a kind of ASM pseudo-code. Why use LLVM and not the famous GCC? According to them and their research, GCC is a beast in complexity and badly documented. On the other hand, LLVM is more modular and offers clearly documented APIs at various steps of the compilation process. The project was born in 2000 and pushed – for license reasons – by Apple since 2005. Apple supports the project by employing the core developers. The obfuscation process takes – obviously – place after the compiler optimization process and bases itself on various techniques such as operator substitution or code flattening. The results, tested on several libraries such as libtomcrypt or Image Magic. Libtomcrypt is a good candidate, as the project provides good test cases and errors introduced by the optimization process will almost certainly alter the result at the end of the process. An impressive image of the code flattening feature was shown for Image Magic, where a single clause got flattened into 3000 cases.

Inserting obfuscation into an existing ELF binary is much trickier, as first you need to find places where to insert the additional code. Several techniques were presented, as well as their limitations. The best identified way is to rely on junk code and opaque predicates in such cases, which may get handy for software watermarking.

The questions focused mainly on performance losses due to obfuscation, which are held reasonably low (between 30 and 50% on libtomcrypt). The future of the project is unclear for the moment, as publishing the project under an open-source license may help good guys, but malware authors may certainly be interested in as well.

Update: on 16.11.2012, Pascal announced the final workshop about Obfuscator taking place on Monday 3rd of December – for further details, see his blog article

ASFWS – Keynote 1 – Gestion opérationnelle de la sécurité logicielle sur la plateforme Facebook

Slides available on

Alok Menghragani graduated in Lausanne with a Master at the EPFL before joining Facebook in 2008, which was back then still a young startup with “only” 100 millions users. He gave us an interesting insight in how Facebook manages over 10 millions of lines of code while keeping “move fast and break things” as motto. This gets translated in the facts by having 2 code releases in production per day, where competitors perform only a code release every couple of weeks or each month. From a technical perspective, all web relevant content is written in PHP, while native mobile languages are used for the respective apps. On the backend systems, there is a mix as C++, Java and Erlang are engaged for example.

No team owns a given set of code, everyone can alter any part of it, but needs to find a competent reviewer before being able to check it in into the internal GIT repository. Some regex based greps are performed as a second quality measure on the committed code and between 1000 and 2000 web driver test cases (ran within a browser) are simulated before the code gets released to production. Most security aspects get covered by dedicated frameworks.

One of the essential frameworks in use is GateKeeper, which allows serving differentiated, personally tailored content. Based on rules such as “is the user an employee or not”, “is the user over 18 years old” etc, the rendered page can be tuned or a specific feature disabled. Such rules are distributed within 1 second world-wide and introduce a latency of only 20ms for the whole framework. It’s therefore a handy feature to be able to quickly restrict content due to a law suit in a given country. From a usability point of view, this is also a great feature to test different layouts and gather vital intelligence on what users appreciate.

Another effective feature is an IPS inserted in the heart of the PHP MVC pages served by the site. Rules can be altered on the fly again and deployed as well within 1 second across the globe. In case of a security flaw, Facebook can write an IPS rule within a few minutes and deploy it across all servers immediately. Focus is then placed into patching the issue in the code (~ 30 minutes, including review) before performing an emergency release (count 40 minutes for deploying a patch to all 200’000 servers). A serious security flaw can so be restrained within a few minutes and patched within a little more than an hour. This IPS feature is also flexible enough to be used to protect users against other threats, such as the recent 0 day in Internet Explorer.

Of interest also are the explanations why data deletion on Facebook takes some time, due to the very decentralized way data is stored. My previous take on this was that Facebook did not delete data, but kept it all. It seems that changes happened in this regard and your data might get deleted now if you decide to leave the social network.

The whitehat program also got covered, which allows you to get USD 1’500 onwards (no upper cap) for a security issue you signal to Facebook. The main drivers are that you need to involve first Facebook’s team before publishing the flaw elsewhere but the bounty will reflect the severity of the bug you reported. An issue, which needed several days of work will therefore likely be rewarded by more than USD 1500. Furthermore, once the security flaw has been confirmed, the researcher will be in direct contact with the engineer tasked to fix the issue. Around 100 bugs have been reported so far according to Alok.

Time for questions of the public:

  • Has the code been completely rewritten lately?
    Yes, the code was completely rewritten in 2009 when XHP (Facebook’s PHP extension) was introduced. On the other hand, there is little code which is currently older than 1 year in the code base!
  • How is the code managed?
    There is one code base, which gets branched on GIT on Sunday and released in production on Tuesday. It’s a very iterative process, as most of the changes first gets sampled on 1% of the user basis (thanks GateKeeper) and constantly monitored.
  • What advice can Facebook give to a small or medium business?
    The best thing in Alok’s opinion is to establish this culture of “everyone owns the code”, and therefore empower everyone to see, review and alter code of the whole company.

After this first keynote, it was time for all participants to have a break before the presentations start.

Day 1 of ASFWS – Introduction

Wednesday 7th of November started early for me as I had to take the train at 6am in Zürich to be in time in Yverdon-les-Bains for the beginning of Application Security Forum – Western Switzerland 2012. This annual security conference, regrouping all actors of the French part of Switzerland during 2 days, invited me to held a workshop regarding our Hacking-Lab. Unfortunately, the workshop planned on Tuesday 6th, had to be cancelled due to an insufficient number of participants.

The social and networking part of the event started for me even before reaching Yverdon-les-Bains, as I met a former colleague in the train in Neuchâtel. It continued before the starting key notes of the conference, while enjoying some coffee and croissants within a hall of the Y-Parc, which was the central gathering place all over the 2 days of the conference.

After a few welcome words from the organization staff, we got some news from the authorities and of the HEIG-VD, a partner University of Applied Science which is established here in Yverdon. Its representative, Jürgen Ehrensberger, presented us quickly the competence center and reminded us that the first graduates with a Bachelor in Information Security will finish their studies in summer 2013.

Slide sets of these introductions:

Over the next couple of weeks, I’ll cover in depth the following presentations, each featured in a dedicated blog article. Stay tuned:

Day 1

Day 2

Blackhat USA 2012

Black Hat USA in Las Vegas is one of the biggest IT security conferences in the world. Every year, thousands of security-interested people attend the conference that is held in the infamous Caesars Palace, the heart of Las Vegas. And as every year, two security analysts of Compass have participated the conference to learn about the latest trends in IT security.

Black Hat easily combines the transfer of the latest top-class security know-how and networking among the attendees with a social frame around the conference. The sponsored Rapid7 Party in the Palms Hotel is just one example, how to combine “work” with pleasure. The Defcon conference takes place right after Black Hat and focuses more on the “geeky” audience.

This paper summarizes some of the most interesting talks we’ve attended during these five days (Black Hat and Defcon). We encourage you not only to read this summary but also to go online and take a closer look at the videos or the slides.

Please download the paper here:

Jailbreak detection – curse or blessing?

“Jailbreak Detection” is a set of checks, mostly performed by Mobile Device Management solutions like MobileIron / Good Technologies or other third party Apps to determine if a device is jailbroken or not. It checks if all security controls of Apple’s iOS are still in place and if we can / should / want “trust” this device.

Such a check could for example search for eye-catching files like the Cydia App Store which can only run on jailbroken devices. Other checks may be:

  • Is the root partition mounted read / writable
  • Is it possible to write outside of the App’s Sandbox
  • Is it possible to fork into another process

If we break this down into a sequence diagram it could look like this (for simplicity reasons I divided the app into two components):

To know if a device is jailbroken is very important as it should never be the case that a jailbroken device can access services from the corporate environment like email or document management systems.

Apple itself introduced a jailbreak detection API ready to use for third party developers, but dropped it quietly with iOS 4.2. The reasons remain a mystery. I think Apple was aware of the fact that such an API can never work by design and dumped it for liability reasons: Software is supervising other software, telling it the device is jailbroken … and software can always be manipulated. In this case by disguise the fact that something has been compromised.

The idea is simple: write a malware that will “Hook” the original code and bypass the detection.

The most difficult part of this approach is to find the correct entry point in the code. (Un)fortunately, Objective-C is a huge help and may let us dump all the header files of the implementation. If the developer was nice enough to call its classes “JailbreakDetector” we should be thankful and send him a nice gift:

#import <Foundation/Foundation.h>

@interface JailbreakDetector : NSObject

+ (BOOL)isDeviceJailbroken;


My Hook could look something like this:

+ (BOOL)isDeviceJailbroken{
   return false;

Lucky us, we are not completely at an attacker’s mercy; creative developers exist and have a proper feature set to deal with such attacks. I like the approach that Jonathan Zdziarski published in his book Hacking and Securing iOS Applications. He writes about pushing the attacker into the wrong direction by implementing a decoy class with an obvious naming.While most attackers will first try to manipulate this code, they will by mistake trigger kill switches that for example invoke tamper responses
to erase data and disable remote resources. Other solutions may be to implement the detection as static inline C code, which is much harder to manipulate.

To summarize this post: Jailbreak detection is valuable and it should definitely be a part of your tool-set to secure integration of mobile devices into the company. However, it should not be trusted blindly.


Windows Phone 8 – An iPhone Alternative for Business?

During our most recent HackLab Day – a quarterly event where Compass analysts research new security topics or solutions – I have investigated Microsoft’s next version of its mobile operating system “Windows Phone 8” (WP8). This update to the previously released Windows Phone 7 version integrates a complete new Kernel (shared with Windows 8 ) and is supposed to have a much stronger focus on the needs of businesses.
One question I have asked myself is, whether this new system has the potential to gain traction in the business environment and possibly, cut a slice of cake from Apple’s iPhone market share. For this to happen, WP8 would need to focus more on the integration into existing MDM solutions and offer more than just plain Exchange ActiveSync support.

Please have a read of my small presentation containing all important updates, changes and additions made for WP8.

Please download the slides at:  compass_security_windows_phone_8_security_v1.0

A few notes about Windows Phone 8

Mobile Device Management –  Microsoft really has taken feedback serious and now allows MDM providers such as Good Technologies, MobileIron and AirWatch to enroll phones to their servers. However, Microsoft’s approach is different compared to how iPhones support MDM: Instead of having an MDM provider write his own application, a ready-to-use MDM client is already built into the WP8 operating system (called “Company Apps”). The user simply enters his credentials (not necessarily his Active Directory ones) and the application communicates with the MDM server.
However, the MDM providers are not yet ready to manage WP8 devices. But it is expected that, by the end of this or start of next year, solutions will be ready.

Updated Chamber System – Windows Phone has always been using so called chambers (details from Nokia), in which an application can run. All applications from the Windows Phone Store were always executed in the least privileged chamber (called Least Privilege Chamber, LPC). Pre-installed applications such as Outlook and OEM apps had additional rights (chamber Standard Rights). Since they weren’t cryptographically signed they have been target for attacks up until now (see MWR’s advisory).  Applications that require to run with even higher rights/capabilities ran in the so called Elevated Rights chambers. These were usually applications like services for listening music or media sharing services. The chamber with the most rights was the Trusted Computing Base (TCB). Here only the Kernel and drivers were allowed to run.
In Windows Phone 8, only two chambers will be available: Trusted Computing Base and Least Privilege Chamber. All applications and even some drivers will run in the LPC and therefore pose little risk to attacks, as a vulnerability in that application would only permit access to the described capabilities.

Enhanced Capabilities – These are descriptions of features of a phone (hardware and software wise). A developer has to explicitly declare what capabilities his application requires. At run- and access-time, those declared capabilities will be compared to the ones requested. If there is no match, the action can not complete.
Due to the updated chamber system, many new capabilities have been added to Windows Phone 8. An overview  can be found on the Microsoft Developer Network.

Side loading of Applications –  A complete new feature in Windows Phone 8 is the ability to side load (installing applications from other places than the Windows Phone Store) applications. This allows companies to deploy custom applications to WP8 users without having to publish them to the entire world. It also permits MDM solutions to install a private app catalog for its employees. Two ways exist to install applications on a mobile phone:

  • Copy an application to the micro SD card. Windows Phone 8 will detect the new app and ask if it should be installed.
  • At enrollment, the process allows the installation of one application. According to Microsoft, an app catalog or app discovery application should be pushed. This app can then be used to install other applications or display company information

No matter how the application gets deployed, it must be signed by a trusted certificate authority. If a company considers deploying custom apps, it has to register at Microsoft to receive the required tools and certificates.

Conclusion: Microsoft really pushes aggressively to achieve further business integration. Two major concerns with Windows Phone 7 have been attacked: The lack of MDM support and missing device encryption. However, with the current possibilities in WP8, Microsoft is still behind iOS with respect to support in the MDM world. Many business features such as VPN configuration, W-LAN configuration or a larger API for MDM solutions have yet to come. But a first step has been made and Microsoft is now ready to build upon this new foundation.

I hope this gives you a short overview of the new security features Windows Phone 8 has to offer. If you have any more questions, please feel free to contact us.