December 17, 2018

Why IAST should mean Instrumented Application Security Testing

Interactive Application Security testing (IAST) first emerged as a concept in the early 2010s as application security companies looked to improve on static (SAST) and dynamic (DAST) testing by either combining results together, or looking for some kind of best-of-both-worlds approach.

Since that time, IAST has grown to about 20% of the AST market and is predicted to gain a larger share of this rapidly growing market in the coming years. However, in my opinion, the way IAST is understood and deployed today means that the acronym needs a tweak.

Originally, when the category was new, the word ‘Interactive’ in IAST was used to mean one of several things: either an interaction between dynamic and static testing; or an interaction between a human tester and an instrumented, running application under test; or the interaction between a dynamic test-case generator and the signals from an instrumented application.

However, with the imperative for security testing to “shift left”, i.e. integrate earlier in the development lifecycle and provide immediate security feedback to developers, users of IAST are frequently opting for another paradigm: instrument an application in a development build and execute automated test cases provided by developers or security analysts. This is carried out automatically and integrated into the CI pipeline without any interaction at all.

At Cryptosense we see our Analyzer IAST tool for cryptography deployed more and more in this way, something it’s well adapted to as our instrumentation is deliberately lightweight to avoid performance or stability issues (to understand why IAST is particularly good for testing crypto, see this recent article). Other IAST vendors seem to be seeing the same thing.

Since the essential added value to automatic testing comes from the instrumentation and subsequent analysis, and we’re actually trying to minimise the need for interaction, maybe it’s time to rename IAST as Instrumented Application Security Testing?

December 7, 2018

Auditing AWS S3 Crypto Use

Amazon Simple Storage Service (S3) is one of the most widely-used cloud services. Most users of the service know it’s wise to encrypt sensitive data before storing it in S3. In this post we’ll look at how to do that securely using the AWS Java SDK, and how Cryptosense Analyzer will help you spot if you’ve done it wrong.

Note that in this post we’re talking about client-side encryption where the sensitive data must be encrypted locally before it’s sent to AWS S3 servers. There are also options for server-side encryption managed via the S3 console. These only treat the data while at rest, it will still be in clear inside AWS servers (at least briefly) each time it’s accessed.

There are several different client-side encryption modes for S3 offered by the Java S3 SDK. First you need to decide whether you want to manage your master keys yourself, or have AWS manage your master keys in their key management service (KMS).

Master keys will not be used directly to encrypt the data you send to S3. Instead, they will be used to encrypt the data keys that will do the encryption. So, if you manage your master keys yourself, you have to take care of key management, but the key values never leave your perimeter. If you use master keys in AWS KMS, the master keys stay in AWS. Each time you need to encrypt or decrypt, you send a request to the KMS to either create a new data key and send it back (both in clear and encrypted under the master key, for encryption operations), or to decrypt an encrypted data key and send it the key to the client (for decryption operations). The diagram below illustrates the difference.

Client managed keys vs AWS KMS managed keys in S3 encryption SDK

The next important detail is the encryption mode. Choosing the encryption mode affects two security-critical points: the algorithm used to protect the encrypted data key, and the algorithm used to encrypt the data itself.

Early versions of S3 encryption supported only an unauthenticated encryption mode for encrypting the data (AES-CBC with PKCS5 padding). This is dangerous, first because these modes don’t guarantee that the ciphertext has not been tampered with, and further they can often lead to padding oracle attacks on the underlying plaintext if the application is not extremely careful about treating decryption errors.

In 2014, authenticated encryption using AES-GCM was added. When authenticated encryption was introduced, the algorithms for encrypting the data key under the master key were also updated: if the master key is a symmetric key, AES Keywrap is used, and if it is an RSA key, RSA-OAEP is used. It’s hard to find documentation for what algorithm was being used before, but we can discover this easily simply by downloading the SDK, making an encryption using the old mode and using Cryptosense Analyzer to see what happens.

Result from Cryptosense Analyzer running on the AWS S3 SDK

What this reveals is that the data key is encrypted under AES-ECB mode. This is not good practice: ECB mode has very few security properties, it is deterministic and unauthenticated. Using this wrap mode is now marked as “not recommended” on the AWS SDK crypto page.

If you opted to manage your encryption keys on AWS KMS instead of client-side, then the encryption of the data key by the master key will be carried out using AES-GCM. This is because encrypting the data key is treated just the same as any other KMS encryption operation.

At a Later Date

If you select one of the newer authenticated encryption modes you have another choice: you can either enforce its use (so trying to decrypt any unauthenticated data will fail), or accept old unauthenticated data and decrypt it anyway, or just use plain unauthenticated AES-CBC for everything. Why might you want to use AES-CBC? Well, AES-GCM has a size limit based on fundamental limitations of its construction (you can’t encrypt more than 2^32 blocks before the counter wraps around), so you are limited to roughly 64 GB.

But you don’t have to settle for lousy unauthenticated encryption just because you have a lot of data to encrypt and want to put it on AWS S3. You could use the AWS Encryption SDK instead, for example – we’ll cover that in a future post.

Insight

Want to know if your Java applications are using crypto securely, in AWS SDKs and anywhere else, at scale? Try a free trial of Cryptosense Analyzer.

November 13, 2018

Why Cryptosense is an IAST Tool

There are several kinds of tool for testing applications for security vulnerabilities: Static Analysis Security Testing (SAST) looks at source code or compiled binaries and searches for patterns that suggest an issue. Dynamic Application Security Testing (DAST) tools test running code by sending inputs (typically to endpoints in a web application) and observing evidence of vulnerabilities.

At Cryptosense, we wanted to build a tool that would effectively identify and help fix vulnerabilities related to cryptography – something no other tool makes a good job of. We quickly realised that we would have to be able to test both code written by our users (to check the way it calls cryptographic libraries), the cryptographic libraries themselves (to look for known issues), framework components and dependencies (that are often using cryptography in insecure ways) and some kinds of behaviour that can only be observed at run-time (like key values loaded from keystores, passwords in configuration files, random number generators..).

Neither SAST nor DAST allow you to do all this – SAST does not see run-time aspects and DAST only sees the cryptography from the exterior of the application.

That’s why we built an IAST (Interactive Application Security Testing) tool, i.e. we instrument an application while it’s running to see all the cryptographic operations, and analyse these to detect crypto vulnerabilities.

Some IAST tools are very heavy to deploy and typically only get used once the application is in late testing, in the SIT or UAT stage. Finding a crypto security issue at this stage is a big headache, so we designed Cryptosense Analyzer to be deployable much earlier in the development lifecycle, as soon as you have some running code.

We worked hard on our instrumentation to minimise performance impact by simply recording a log of cryptographic details while the application runs. This trace is then uploaded to our Analyzer server, either using our Rest API, a CI plugin for e.g. Maven, Gradle or Jenkins, or interactively using our web interface. Because the instrumentation is so light and efficient, there are no stability issues. The Analyzer can be deployed in integration tests or even in unit testing to catch errors as early as possible.

Most of our users combine Cryptosense Analyzer with analysis from several tools including SAST and tools to test code quality or the presence of vulnerable open-source components. This kind of combination is made easy by our Rest API.

You can try Cryptosense Analyzer yourself on any application using our free trial.

October 17, 2018

Cryptosense Analyzer finds Crypto Flaw in Java EE

Yesterday’s Oracle Critical Patch Update contains a credit to Cryptosense for CVE-2018-3210, a flaw found by one of our users while they were testing a Java application with our Analyzer software.

The bug involves a repeating IV in AES-CTR mode, a crypto mistake that can be hard to spot in code review. Our run-time testing approach detects it more easily. It’s also rather easy to exploit (see e.g. the Many-time Pad tool).

The result was reported to us by one of our customers, who asked us if we’d like to investigate since the issue didn’t appear to come from their own code. We decided to ask the security group at Università Ca’ Foscari, with whom we have a long-standing collaboration, if they could take a look. Leonardo Veronese carried out the work, and he takes up the story:

Java Server Faces is a Framework for programming web application in the Java language and it’s part of JavaEE (EnterpriseEdition). Through the Oracle JavaEE page it is possible to find and download the specification.

The Oracle implementation of the specification is called mojarra and the source code is available on GitHub. The Project is part of EE4J initiative and it’s being migrated to Eclipse Foundation.

I looked at the source code of the classes that appeared on the stack trace sent to me by Cryptosense to find out what was the feature that they implemented and where the issue about AES-CTR was present.

Inspecting the source code the class com.sun.faces.util.ByteArrayGuardAESCTR is used in the class com.sun.faces.context.flash.ELFlash which implements the interface javax.faces.context.Flash. From the docs:

The Flash concept is taken from Ruby on Rails and provides a way to pass temporary objects between the user views generated by the faces lifecycle. As in Rails, anything one places in the flash will be exposed to the next view encountered by the same user session and then cleared out. It is important to note that “next view” may have the same view id as the previous view.

So in short the flash is a way to store temporary data without using the session scope.

ByteArrayGuardAESCTR.java

This class is responsible for encryption and decryption. The method setupKeyAndCharset is called by the constructor and it is used to initialize objects. By default the key is generated through javax.crypto.KeyGenerator and the IV is generated with java.security.SecureRandom. The key and IV generated are stored in the object state.

The first thing that can be considered as a vulnerability is the “non standard” initialization performed in the setupKeyAndCharset: if the FlashSecretKey property is specified, the key contained in there is used instead and, if this happens the IV is not randomly generated but is just equal to the key:

String encodedKeyArray = (String) context.lookup("java:comp/env/jsf/FlashSecretKey");
if (null != encodedKeyArray) {
   byte[] keyArray = DatatypeConverter.parseBase64Binary(encodedKeyArray);
   if (keyArray.length < 16) {
     throw new FacesException("key must be at least 16 bytes long.");
   }
   sk = new SecretKeySpec(keyArray, KEY_ALGORITHM);
   byte[] iv = new byte[16];
   System.arraycopy(keyArray, 0, iv, 0, 16);
   ivspec = new IvParameterSpec(iv);
}

ELFlash.java

In this class the ByteArrayGuardAESCTR is used, in fact a variable guard is defined and initialized in the constructor. Searching on this class for a new expression of ByteArrayGuardAESCTR only returns line 272 in the constructor, which means that the lifetime of the guard is bound to the lifetime of the ELFlash object.

From the docs, it seems that the ELFlash object is created once in the application (and so the inner variables like flashInnerMap and guard). So it seems the IV is fixed for the lifetime of the application.

What's in the cookies?

In the ELFlash class a constant called FLASH_COOKIE_NAME is defined that contains csfcfc: The ciphertext is stored on a cookie. We can make a guess that some information about the flash are stored on a cookie to be retrieved after a redirect.

The method encode creates the string to encrypt, encrypts it and then builds a cookie with it.
From this we discover that the character _ is used as separator for the two encoded objects of the class FlashInfo. Each FlashInfo encoded information has a number, character X as a separator, then two letters that represent Lifetime and the mode.

Looking at the decode method we can see that the cookie value is decrypted then used to restore the state by searching the sequence number on the inner map of the ELFlash instance.

Conclusions

The implementation of the Flash mechanism in Java Server Faces does contain a fixed IV in AES-CTR mode. An attacker could likely decrypt the ciphertexts in the cookies by observing several and applying knowledge of the structure of the plaintext.

It's unlikely any confidential information would be stored in these short-term cookies, but a more interesting attack would be to tamper with the cookies to force the server to restore a different state than the one the user was supposed to go back to, possibly allowing access to states that would not have been available to him, and thereby circumventing security controls.

October 3, 2018

Post-Quantum Crypto: How to Start Preparing

post quantum crypto

UPDATE: Graham recently contributed to this article in The Economist on Post-Quantum Cryptography.

Computers that exploit quantum mechanical properties offer the promise of (supposedly) unbreakable cryptography and other exciting applications, but they will also cause a huge, immediate problem: the day a large, practical quantum computer is developed, all existing widely-used asymmetric cryptography will be broken.

This will have serious consequences: massive amounts of secret information exchanged over the internet under public-key or hybrid cryptography could be revealed. Computers will no longer be able to ensure the updates they are downloading and installing are legitimate, since code signing will be broken. The owner of the first powerful quantum computer (which will probably be a large state organisation, who will keep it a secret) could have the power to take over almost every computer and mobile phone connected to the Internet. Even though nobody knows when this will occur, it makes sense to start preparing.

The solution is not quantum cryptography, but post-quantum cryptography: algorithms that run on classical computers now, and resist attack by future quantum computers. The trouble is, they don’t exist yet, or at least not in a practical form.

NIST has launched a competition to find and standardise practical quantum-resistant algorithms. The first round of the competition closed at a conference this April. Researchers around the world are racing to break and/or improve the submissions. You can see them all here – there is plenty of exotic and infrequently used mathematics being employed, like supersingular isogenies, lattices and quasi-cyclic codes.

In the end, unlike for previous NIST competitions such as that which fixed the standard algorithm for symmetric cryptography (the AES standard), there will be more than one winner. That’s because there are going to be some painful trade-offs around performance, size of key, size of ciphertext or signature, etc. that will mean difficult decisions for future application developers.

Get Ready

Meanwhile, large companies are already starting their post-quantum crypto migration, without waiting for the results. This is because the job is so huge: imagine you’re a big software company with more than 5000 applications. Every one of these applications employs cryptography in multiple ways, in some cases hidden in legacy libraries and components without up-to-date documentation. Finding each use, deciding what to replace it with and making the changes to the application is a huge undertaking. A good first step is to complete your cryptography map, finding out what is used and where, something which Cryptosense Analyzer can help you do.

August 27, 2018

Dangerous Tutorials: How not to learn C# cryptography

Our recent work to add coverage of the Microsoft .NET API to Cryptosense Analyzer has led us into a dark and dangerous part of the internet: C# crypto tutorials.

It’s extremely dangerous to treat a cryptography API like just another interface where all you need to do is figure out how to “make it work”. It is theoretically possible to make, say, encryption and decryption “work” using a cryptography API while leaving a slew of terrible security holes. The C# Crypto API is no exception.

Continue reading →

June 25, 2018

Crypto Audit of the Jenkins CI System

Jenkins is a popular tool for managing continuous integration (CI), i.e. coordinating builds, tests and deployment of a software project in an automated way.

In an enterprise context Jenkins has some security requirements, like ensuring that only users with the right permissions can access certain projects and carry out certain tasks, protecting sensitive data such as tokens for access to APIs, etc.
Continue reading →

April 6, 2018

Integrating Cryptographic Security Testing into CI

Continuous Integration or CI is a more and more widely adopted software engineering practice. A best practice for CI is to make the build self-testing, and recently this has started to include security testing. Cryptosense Analyzer, our tool for testing crypto security in applications, now integrates into CI.

Continue reading →

Try a Free 14-day Trial

Cryptosense Analyzer audits your applications and infrastructure to find vulnerabilities and understand your crypto landscape. Use it to optimise bug-fix resources and demonstrate compliance.

Start free trial