Monthly Archives: January 2018

Using a custom root CA with Burp for inspecting Android N traffic

TL;DR: Follow these steps to intercept traffic using Burp with a self made root CA on Android (or any browser)

The problem

In a previous blogpost, we presented a Magisk module that easily integrates user certificates into the system CA store in order to bypass Android N’s new hardened security model. For instrumenting applications, this works pretty well, and it has become a standard module on our pentest devices. The flow is really easy:

  1. Set up your WIFI to use Burp as your proxy
  2. Go to http://burp
  3. Download & install the certificate
  4. Reboot

However, if we now open Chrome on the Android device, we get the following error: NET::ERR_CERT_VALIDITY_TOO_LONG.

If we take a look at the specifics of the certificate, we see that the certificate expires on Jan 11, 2023. A quick google search tells us that Google has chosen only to allow leaf certificates that expire within 39 months. This seems like a reasonable requirement, and after searching Portswigger’s site, the recommendation was to reissue the Burp CA certificate. Unfortunately, the problem persisted after doing so.

Burp also allows us to import a self made certificate + private key to be used instead of the automatically generated one. This sounds like an easy solution, as we can decrease the lifetime of the root CA, so it’s the next obvious step. In practice, it turns out to be a lot more difficult to get the configuration right than you would think. The goal of this blog post isn’t about all my failed attempts and why they failed, but about sparing you the trouble and giving you a working step-by-step guide to get this to work.

As a side note, this problem does not occur with the normal setup, where Burp’s root CA is added as a trusted user certificate. Chrome is only picky about “real” CA, which are evidently installed in the system root CA store. However, as I would like to have one certificate setup to rule them all, I searched for a solution…

The solution – Creating custom CA and importing it into Burp suite

I order to successfully install our custom root CA in both Burp and Android, we need to create a CA that has the v3_ca extension. The following steps are executed on a clean 14.04 Ubuntu installation. Granted, there are only a few steps to the processes, but that’s only because I’m not listing all my failed attempts.

# Keep it clean
> mkdir certificates && cd certificates

# Install openssl
> sudo apt-get install openssl

# Borrow the default openssl.cnf (location may differ, see note)
> cp /usr/lib/ssl/openssl.cnf ./

# Create a private key. 
# It's important to have the v3_ca extension and to supply the openssl.cnf file
> openssl req -x509 -days 730 -nodes -newkey rsa:2048 -outform der -keyout server.key -out ca.der -extensions v3_ca -config openssl.cnf
Generating a 2048 bit RSA private key
writing new private key to 'server.key'
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:BE
State or Province Name (full name) [Some-State]:NVISO CA
Locality Name (eg, city) []:NVISO CA
Organization Name (eg, company) [Internet Widgits Pty Ltd]:NVISO CA
Organizational Unit Name (eg, section) []:NVISO CA
Common Name (e.g. server FQDN or YOUR name) []:NVISO CA
Email Address []:NVISO CA

# Convert to der format
> openssl rsa -in server.key -inform pem -out server.key.der -outform der
writing RSA key

# Convert key to pkcs8 format
> openssl pkcs8 -topk8 -in server.key.der -inform der -out server.key.pkcs8.der -outform der -nocrypt

Note: The openssl.cnf may be in a different place. Alternatively, you can download the default config from the openssl website.

Let’s take a quick look at the generated certificate:

> openssl x509 -in ca.der -inform der -noout -text
 Version: 3 (0x2)
 Serial Number: 17570736880079538514 (0xf3d7cc1942ff0952)
 Signature Algorithm: sha256WithRSAEncryption
 Not Before: Jan 11 16:23:19 2018 GMT
 Not After : Jan 11 16:23:19 2020 GMT
 Subject Public Key Info:
 Public Key Algorithm: rsaEncryption
 Public-Key: (2048 bit)
 Exponent: 65537 (0x10001)
 X509v3 extensions:
 X509v3 Subject Key Identifier: 
 X509v3 Authority Key Identifier: 

X509v3 Basic Constraints: 
 Signature Algorithm: sha256WithRSAEncryption

The generated certificate has the v3_ca extension enabled, so we can import it into Android. Using our magisk module, you can install this certificate through the normal certificate installation flow, and after rebooting your device, the CA should be listed in the system CA store.


The next step is importing these files into Burp. Go to the proxy settings page and choose “Import / Export CA Certificate” -> “Import” -> “Certificate and priate key in DER format”. The correct files to choose are `ca.der` and server.key.pkcs8.der:


After installing the certificate, restart Burp just to be sure.

If everything worked, you’ll now have your custom root CA as a system certificate, and you can intercept all chrome traffic.

It took quite some time to figure out the correct procedure, so I hope I’ve at least saved someone else from spending hours trying to figure it out.

And, in order to help anyone searching for the correct answer, here’s a short overview of the problems I encountered:

  • NET::ERR_CERT_VALIDITY_TOO_LONG (-> Make sure your certificate’s validity is not longer than 39 months)
  • Custom root CA won’t install correctly on Android (-> Make sure it has the v3_ca extension)
  • Burp import errors (-> Follow the steps above for correct setup)
    • Failed to import certificate: signed fields invalid
    • Failed to import certificate: Unable to initialize, extra data given to DerValue constructor
  • OS X / MacOS openssl: Error Loading extension section v3_ca (-> Copy the openssl.cnf file and manually add it as an argument with -config )


About the author

Jeroen Beckers is a mobile security expert working in the NVISO Cyber Resilience team. He also loves to program, both on high and low level stuff, and deep diving into the Android internals doesn’t scare him. You can find Jeroen on LinkedIn.

Windows Credential Guard & Mimikatz

Here at NVISO, we are proud to have contributed to the new SANS course “SEC599: Defeating Advanced Adversaries – Implementing Kill Chain Defenses”.

This six-day training focuses on implementing effective security controls to prevent, detect and respond to cyber attacks.

One of the defenses covered in SEC599 is Credential Guard. Obtaining and using credentials and hashes from memory (for example with Mimikatz) is still a decisive tool in the arsenal of attackers, one that is not easy to defend against.
With Windows 10 and Windows Server 2016, Microsoft introduced a feature to mitigate attacks to obtain credentials and hashes: Credential Guard. With Credential Guard, secrets are stored in a hardened and isolated section of your computer, inaccessible from the normal operating system.

Credential Guard relies on a new technology introduced with Windows 10 and Windows Server 2016: Virtual Secure Mode (VSM). VSM is based on the virtualization features of modern CPUs to provide a separate memory space where secrets can be stored. This separate memory space is protected (via hardware) from read and write attempts from processes in the normal operating system’s memory space.

When Credential Guard is enabled, the Local Security Authority Subsystem Service (LSASS) consists of 2 processes: the normal LSA process and the isolated LSA process (which runs in VSM).

Credential Guard

SANS SEC599 day 4: Credential Guard

Tools that recover secrets from LSA, like Mimikatz, are not able to access the isolated LSA process. They cannot extract passwords or inject hashes for pass-the-hash attacks, for example. Hence, Credential Guard is an effective tool to protect credentials stored on Windows machines.

Despite Credential Guard, users with administrative access can still find ways to steal credentials entered on Windows machines. This can be done, for example, with Mimikatz own Security Support Provider. SSPs are packages that participate in the authentication of users: for example, installed SSPs will be called when a user logs on, and will receive the credentials of said user. Windows comes with several SSPs , and custom SSPs can be installed (of course, this requires administrative permissions).

Mimikatz memssp command (available since September 2014) installs a custom SSP in memory (so no DLL is written to disk), that will log all credentials it receives in a text file.

To achieve this, Mimikatz needs to be executed with administrative rights on the target machine and the debug privilege needs to be enabled to allow the LSA processes to be opened and patched:


Next, Mimikatz’s SSP is injected with the misc::memssp command:


Now the SSP is installed, Mimikatz can be closed. This SSP will remain in memory as long as Windows is not rebooted.

After a user has performed a log on, Mimikatz’s SSP log C:\Windows\System32\mimilsa.og file can be examined to retrieve the credentials processed by Mimikatz’s SSP:



Mimikatz can not extract credentials protected by Credential Guard, but it can intercept credentials entered in a Windows machine at log on time, for example. Although Credential Guard will protect credentials in isolated memory, credentials still need to be provided to a Windows machine (like for an interactive logon).

When these credentials are typed, they can still be intercepted and stolen, e.g. with a key logger or with with a custom SSP, as illustrated here. This is however only one of the steps in the attack chain, as this requires administrative rights, it is crucial to restrict and monitor administrative access to your Windows machines.

New year, new vulnerabilities: Spectre & Meltdown

Two new vulnerabilities “Spectre” and “Meltdown” were recently discovered, affecting millions of systems worldwide. Please find our security advisory below.

spectre                                                     meltdown 

Spectre and Meltdown are hardware vulnerabilities in the microprocessors (CPUs) that, when exploited, allow an attacker to read the content of memory he/she is not allowed to access. Some key things to know about these vulnerabilities:

  • Proof of concept code for Meltdown demonstrates that a low privilege user process can read all kernel memory from major operating systems on Intel CPUs;
  • Proof of concept code for Spectre demonstrates that a low privilege user process can read memory from other processes on all major operating systems on CPUs from all major vendors;
  • Spectre and Meltdown attacks can be used to break through security boundaries implemented by operating systems to steal confidential data, including passwords and secret keys;
  • Patches are already available for the mitigation of Meltdown;
  • Long-term solution will consist of redesigning the CPU infrastructure by the vendors.

How does it work?
Both vulnerabilities rely on exploiting side-effects of “out-of-order execution” and “speculative execution”.

  • Out-of-order execution is a performance feature of CPUs that allows for non-sequential execution of machine instructions. Instead of executing machine instructions step by step in the order specified by the program (like old fashioned CPUs do), CPUs nowadays speed up execution of programs by simultaneously executing several machine instructions of the program, but not necessarily in the order specified by the program (this is called out-of-order execution).
  • Speculative-execution takes this concept further, and executes instructions that may actually not have to be executed. The instructions are executed before it is known that they have to be executed (this is done to maximize the utilization of the CPU). The implication is that machine instructions are being executed that ultimately should not have been executed, for example because a conditional branch is taken. The results of these “unnecessary” machine instructions are discarded.

The Spectre and Meltdown vulnerabilities leverage these discarded results.

The Spectre vulnerability (CVE-2017-5715 and CVE-2017-5753) is actually a class of vulnerabilities in CPUs that implement speculative-execution, and more precisely branch-prediction (Meltdown is considered to be a particular case of Spectre). Branch-prediction is implemented by the CPU circuits that try to predict which branch of a conditional execution will be executed. The branch with the highest probability of execution is executed via out-of-order execution. Exploiting Spectre relies on the fact that the branch-prediction circuitry can be manipulated (by exploit code) to assign a higher probability on a chosen branch. Spectre exploits will search for branches that access memory that is outside of the security context of the running exploit (hence not allowed to be read), and then manipulate the branch-prediction algorithms to execute these branches out-of-order. But because the results of these instructions are discarded (the branches would not have been executed in a sequential execution), Spectre exploits have to use side-channels attacks to recover the discarded results. A side effect of out-of-order execution is that memory content is loaded into cache-lines. The side-channel attack relies on the timing of instructions to determine what data was loaded into the cache-lines: an instruction will execute faster if the data it requires is already in the cache-line.

The exploitation of the Meltdown vulnerability (CVE-2017-5754) relies on a privilege escalation vulnerability in Intel CPUs (this privilege escalation vulnerability exists in most Intel CPUs since 1995). An exploit for the Meltdown vulnerability will execute an instruction that causes a trap. Because of this trap, the results of instructions that were executed out-of-order are discarded. Next, the exploit will use an Intel privilege escalation vulnerability to access the results of the discarded instructions. In proof of concepts, the discarded instructions are used to read kernel memory. This should not be allowed by code running inside a user-land process, but this security decision is only taken after the out-of-order execution. Consequently, the combination of a trap and privilege escalation can be used to read memory that is normally not accessible to the code.

What is the impact?
Meltdown impacts workstations, laptops, servers (also cloud servers) running Linux, Windows or macOS.

Spectre impacts workstations, laptops, servers (also cloud servers), smartphones, tablets,… Virtually any device that runs on vulnerable CPUs from Intel, AMD and ARM.

What should we do?
At the time of writing this advisory, there are no patches available to mitigate the Spectre vulnerability.

Patches have been released for Windows, Linux and MacOS to mitigate the Meltdown vulnerability in Intel CPUs. These are patches for the kernel that implement Kernel Page-Table Isolation (KPTI, also known as KAISER). KPTI mitigates the Meltdown vulnerability by completely separating user-space and kernel-space page tables. Before this patch, user-space and kernel-space page tables were not separated for performance reasons. Reports exists that KPTI impacts performance, some speculating up to 30% loss in CPU performance.

We recommend to execute performance tests with these patches on high-load machines before deploying these patches in production.

NOTE: Microsoft published information that some anti-virus products are not compatible with their patches, and may cause a BSOD (Blue Screen Of Death). So before installing updates, check with your AV vendor first. (

Exploiting the Spectre and Meltdown vulnerabilities requires code execution on vulnerable CPUs. Until these vulnerabilities have been completely addressed, strict control of code execution (like application whitelisting) can help mitigate attacks for these vulnerabilities. Be aware that proof of concepts are already available for Spectre and Meltdown, written in JavaScript. Control of code execution must not only address binary executables, but also scripting.

Ultimately, the Spectre and Meltdown vulnerabilities have to be addressed by redesigning CPU architectures. As a typical CPU release cycle takes 18 months, this implies that it will take several years before new CPUs are produced and widely deployed.

Update 05/01/2018:

There are now 2 tools available to check Windows systems for these vulnerabilities. Microsoft has released a PowerShell script (SpeculationControl) and Alex Ionescu has released a Windows executable (SpecuCheck).

Here is the output of Get-SpeculationControlSettings on an unpatched machine:

Here is the output of Get-SpeculationControlSettings on an patched machine (Windows patches):

As you can see, mitigation for the Meltdown vulnerability (CVE-2017-5754) is present in the OS and activated, and (partial) mitigation of the Spectre vulnerability (CVE-2017-5715) is present in the OS but not activated. It can only be activated when a required firmware updated has been installed. You will need to get this firmware update from your OEM (provided they plan to release a firmware update for your machines).

Update 09/01/2018:

Microsoft did not release microcode updates (to update your CPU) with their monthly patches. You will have to do this with a firmware update from your OEM (several OEMs have already released new firmware). Red Hat did release a microcode update for CVE-2017-5715.

More information?
NVISO analysts are still working on additional research and will update this blogpost with any results.

Should you require additional support, please don’t hesitate to contact our 24/7 hotline on +32 (0)2 588 43 80 or

If you are interested in receiving our advisories via our mailing list, you can subscribe by sending us an e-mail at

Other references: