Azure Storage is one of the most widely used services in the Microsoft Azure cloud, and is the Azure equivalent of the AWS S3 service. Most users of the service know that it is wise to encrypt sensitive data before storing it in the cloud. In this post, we will look at how that can be done using the Azure Java SDK, and will use the Cryptosense Analyzer Platform to gain insight into how the Azure SDK encrypts your data.
Containers are often designed to be stateless. That means all state changes made by the application happen in the database, or some external storage. They don’t happen on the container filesystem.
Previously, this made using Cryptosense Analyzer difficult. That’s because our IAST cryptography analysis tool works by tracing the calls an application makes to its cryptography libraries, and writing them to a trace file for later upload to Analyzer.
Continue reading →
A recent success story for Cryptosense is our roll-out with a large global player in the ATM (cash machine) network.
Since this firm is considered a Service Provider in the PCI regulations, they have regular audits to pass which contain a lot of requirements on cryptography: full cartography of applications, compliance with NIST standards etc.
This used to take our customer a lot of time and resources, but since our Analyzer platform doesn’t just report cryptographic issues but correct, compliant use of cryptography, it’s the ideal tool to take over this job and free up resources for more productive tasks. The reports produced by the Analyzer are produced automatically thanks to our integration with Maven in CI, and contain coverage information to validate the testing. We worked with 3key Company to deliver the install.
Read more about this case study here (1 page PDF).
A recent NIST paper recommending which steps to take to prepare for the advent of quantum computers proposes that users of cryptography look to achieve ‘crypto agility’ as soon as possible. The idea was further expanded by Gartner in a recent research note, and now crops up regularly. It’s sometimes described as ‘crypto-agnosticism’, but what does it mean, and how does one achieve it?
Designers of cryptographic protocols have talked for a long time about the idea of algorithm agility. The principle is simple: that a protocol will be designed in such a way that its function is, to some extent, independent of the choice of cryptographic algorithm used, therefore allowing you to switch algorithm. You might even have a set of recommended cipher suites that can be negotiated in each protocol exchange – this is how TLS works for example. There are now whole RFCs dedicated to the topic.
Crypto agility extends this idea from network protocols to all of the cryptography in use in an organisation. This means that an organisation can only become crypto-agile when the security team knows all of the algorithms, keylengths, crypto libraries and protocols in use in their applications and infrastructure, and has a plan that would allow them to change if necessary.
As well as supplying Cryptosense Analyzer to our customers so they can test their applications, we frequently apply the tool ourselves to widely-used open source software including the Java JDK. The Oracle Critical Patch Update (CPU) of 17th October contained patches for two CVEs discovered at Cryptosense in collaboration with our partners at University of Venice Ca’ Foscari.
One task our users often want to perform with application crypto audit reports produced by Cryptosense Analyzer is to export certain results in detail for adding to an issue tracker. We’ve now made this easier by adding stars to instances of our analysis rules. Clicking on a star marks an instance for export. You can then export all the starred instances along with full stacktrace information indicating where in the code the issue comes from.
Our Java Crypto Analyzer tool works by tracing calls to the cryptographic library from all parts of the application under test, including libraries, framework components and dependencies.
We recently tested the Analyzer on a large web application which uses a whole host of different libraries including PrimeFaces, a popular open-source library for graphics and UI elements in web applications. One result in particular came from stacktraces leading to that library. It seemed that PrimeFaces was encrypting strings in URLs using a custom scheme based around a password that is set in the configuration file.
The Analyzer flagged up multiple problems:
- Fixed salt in password-based key derivation
- Low iteration count (19) in password-based key derivation
- Weak key derivation algorithm: PBEWithMD5
- Weak encryption algorithm: DES
- Short symmetric key (56 bit)
- Unauthenticated encryption with PKCS5 padding (possible padding oracle)
The upshot of this is an encryption scheme that could be attacked in multiple ways. The default password (“primefaces”) is likely unchanged in many installations. Even if changed, with the weak password-based key derivation function and fixed salt, a dictionary attack could be mounted. The padding oracle could reveal individual plaintexts. Finally, if all else fails, since the key is fixed for an individual server, it could even be worth brute-force guessing the 56 bit DES key (specialist FPGA hardware can do this in a few hours).
What would be the consequences of breaking this encryption in a graphics library? While following up on this issue, we discovered that it was partially fixed in February 2016 after being reported by Minded Security. They used the PadBuster tool from our friends at Gotham Digital Science to exploit the padding oracle and break the URL encryption. This allowed them to submit fake URLs which, it turns out, are interpreted as Expression Language by the server, leading potentially to remote code execution. PrimeFaces was patched to switch the encrypted URLs for pseudo-random IDs at the price of maintaining a little more state on the server.
However, our Analyzer results showed the weak encryption scheme was still being used. Its second usage is to protect the values of QR codes and barcodes encoded in URLs. We reported this to PrimeTek, and they promptly fixed it in version 6.0.6.
We would advise anyone using to PrimeFaces to ensure they have upgraded at least to version 5.2.21, 5.3.8 or 6.0 (which patches the remote code execution flaw), and preferably to version 6.0.6 (which fixes the QR code and barcode protection issue by removing the weak encryption completely).
Find crypto bugs
PrimeKey Solutions develops and supports the most downloaded open source enterprise public-key infrastructure (PKI) software available, EJBCA. You can find out why they use Cryptosense Analyzer for Java in a case study we’re releasing today.
We already use a variety of tools to ensure software quality, but we see security as an area of continuous improvement, and Cryptosense tools give us a cryptography-focused view that other tools can’t provide. A strong statement in itself, given the fact that PrimeKey’s teams of engineers work day in and day out with cryptography.
Tomas Gustavsson, CTO PrimeKey
PrimeKey Case Study