Tag Archives: Patch management

Fixing Cryptography is not Always Easy

Posted on by

The latest version of the Zloader banking malware is (also) exploiting a Microsoft Signature Verification bug (CVE-2013-3900) for which the bugfix exists since 2013 (see for example here for more details). In this case the security issue is not due to users not updating their systems with the mandatory security patches but to the fact that the patch is optional and should be installed manually.

The problem is that the stricter signature verification implemented by the Microsoft Authenticode patch which fixes this bug, has an extremely high risk of false positives in many situations, for example some installers can be identified as having an invalid signature. So Microsoft decided to let the user decide if the patch would create more problems than solving some.

The Zloader malware uses this “bug” to be able to run some modified (and then unsigned) libraries. But this requires that the malware is already on the system, so applying this patch does not prevent a system from being infested by this malware.

The issue that, again, this event points out, is how difficult it is to balance strict security, in particular if cryptography is involved, and usability / availability of systems and services.

CISA Catalogue of Known and Exploited Vulnerabilities

Posted on by

The Cybersecurity & Infrastructure Security Agency (CISA) has recently published the “Binding Operational Directive 22-01” which has the purpose of identifying the known and exploited vulnerabilities and address their resolution so to reduce the associated risks. 

In other words, CISA has identified the most risky and exploited vulnerabilities creating a catalogue (here) which can be used by everybody to identify the vulnerabilities which must be patched first. Indeed running a vulnerability scanner (or performing a penetration test) too often produces an extremely long list of vulnerabilities, classified by severity typically according to the CVSS-v3 standard: but which ones are really important / risky / even scary? A catalogue of vulnerabilities actually exploited by attackers can help to select the ones which really matter and that should be patched as-soon-as-possible.

Always about Security Patching and Updates

Posted on by

These days I keep coming back to the “security patching and updates” issue. So I am going to add another couple of comments.

The first is about Ripple 20 (here the official link but the news is already wide spread) which carries an impressive number of “CVSS v3 base score 10.0” vulnerabilities. The question is again:

how can we secure all of these Million/Billion vulnerable devices since it seems very likely that security patching is not an option for most of them?

The second one is very hypothetical, that is in the “food for thought” class.

Assume, as some says, that in 2030 Quantum Computers will be powerful enough to break RSA and other asymmetrical cryptographic algorithms, and that at the same time (or just before) Post Quantum Cryptography will deliver us new secure algorithms to substitute RSA and friends. At first sight all looks ok: we will have just to do a lot of security patching/updating of servers, clients, applications, CA certificates, credit cards (hardware), telephone SIMs (hardware), security keys (hardware), Hardware Security Modules (HSM) and so on and on… But what about all those micro/embedded/IoT devices in which the current cryptographic algorithms are baked into? And all of those large devices (like aircrafts but also cars) which have been designed with cryptographic algorithms baked into them (no change possible)? We will probably have to choose between living dangerously or buy a new one. Or we could be forced to buy a new one, if the device will not be able to work anymore since its old algorithm will not be accepted by the rest of the world.

PS. Concerning Quantum Computers,  as far as I know nobody claims that a full Quantum Computer will be functioning by 2030, this is only the earliest possible estimate of arrival, but it could take much much longer, or even never!

PS. I deliberately do not want to consider the scenario in which full Quantum Computers are available and Post Quantum Cryptography is not.

Patching, Updating (again) and CA certificates

Posted on by

Well, it is not the first time I write a comment about the need of security patching and updating all software, or the problem of not doing so. This is even more problematic for IoT and embedded software.

I just read this article on The Register which describes a real trouble which starts to show itself. In a few words, it is approximately 20 years that we massively use CA certificates to establish encrypted (SSL/TLS) connections. Clients software authenticates servers by trusting server certificates signed by a list of known Certification Authorities. Each client software has installed, usually in libraries, the public root certificates of the CA.

Now what happens if the root certificate of a CA expires?

This is not a problem for servers, their certificates are renewed periodically and more recent server certificates are signed by the new root CA.

Clients have some time, typically a few years, to acquire the new CA root certificates, this because root certificates last many years, usually 20. But what if  IoT or embedded devices never get an update? Think about cameras, smart-televisions, refrigerators, light bulbs and any other kind of gadget which connects to an Internet service. As the old root CA certificate expires, they cannot connect to the server and they can just stop working. The only possible way out is to manually update the software, if a software update is available and if an update procedure is possible. Otherwise, it remains only to buy a new device!

Patching timing is getting tight

Posted on by

The US Cybersecurity and Infrastructure Security Agency (CISA) has recently reviewed the guidelines (actually a Binding Operational Directive for US Federal Agencies) on patching (see the Directive here and a comment here).

Now vulnerabilities rated “critical” (according to CVSS version 2) must be remediated within 15 days (previously it was 30 days) and “high” vulnerabilities within 30 days from the date of initial detection by CISA weekly scanning.

Due to the short time between detection and remediation of vulnerabilities, applying patches in time is going to be difficult, due to the possibily missing availability of patches by the vendors and the time needed anyway to test them in each IT environment.

This implies that there must be in place processes to design, test and deploy temporary countermeasures to minimize to an acceptable level the risks due to these vulnerabilities. And these processes must be fast, they should take at most a few days.

On the Security of Modern Cryptography

Posted on by

The security of modern cryptography is based on number-theoretic computations so hard that the problems are practically impossible for attackers to solve. In practice this means that approaches and algorithms to crack the cryptographic algorithms are known but with the current best technologies it would take too many years to complete an attack.

But what if a shortcut is found at least in some particular cases?

This is exactly what some researches [article, arstechnica] have just found for the Diffie-Hellman (DH) algorithm with 1024bit keys, algorithm which is one of the pillars of the security of Web transactions among many other uses. The researchers have shown that for DH with 1024bit keys there exist some parameters (prime modulus) that allow with current technologies to compute the secret encryption keys in short time. In other words, some parameters adopted in DH-1024 can contain invisible trapdoors. The only ways to securely use DH today seem to be:

  • to know how the parameters have been generated and to be sure that they do not allow for any “trapdoor”
  • or to use DH with 2048bit or larger keys.

What does this teach us about the security that cryptography provides to everyday IT?

How should we implement and manage cryptography within IT security?

Is cryptography joining the “zero days => vulnerabilities => patch management” life-cycle which has become one of the landmarks of current IT security?