AutoCAD malware

Recently I have paid some attention to AutoCAD and similar software. Not that I use them or that know much about them, but it definitively striked me both the complexity and the amazing features that some of these applications have. But with complexity, large number of features and dimension of code, come also vulnerabilities, even security vulnerabilities.

A few days ago I noticed this article (here a less technical summary) about AutoCAD malware, which has been around for more than 10 years. The purpose of this malware can be twofold: just another malware infecting channel, or more likely, a very targeted attack channel. Indeed CAD software is used for designing buildings, bridges, tunnels, roads etc., and some blueprints can be worth millions. Companies have taken notice of this, and security features have been introduced in the applications.

But the issue which does not seem to be appreciated enough (I have no statistics though, so I can be wrong on this) is the patching process (and this is not limited to CAD software but applies to other specialised software as for example digital audio or gaming). It seems to me that some of these applications are seldom updated (one needs to download/buy a new version) or that security patches are bundled together with new functionalities which can come at a cost, at least after the initial few years of support.

In my opinion, in an ideal world security patches should be provided for free to anyone until the program is supported. Obviously this can have economical impacts on the company producing the software and could require changes in the way software is built, sold and distributed (costs again).

On SHA1, Software Development and Security

It is a few years that it is known that the SHA1 Cryptographic Hash Algorithm is weak, and from 2012 NIST has suggested to substitute it with SHA256 or other secure hash algorithms. Just a few days ago it has been announced the first example of this weakness, the first computed SHA1 “collision”.

Since many years have passed from the discovery of SHA1 weaknesses and some substitutes without known weaknesses are available, one would expect that almost no software is using SHA1 nowadays.

Unfortunately reality is quite the opposite: many applications depend on SHA1 in critical ways, to the point of crashing badly if they encounter a SHA1 collision. The first to fall to this has been the WebKit browser engine source code repository due to the reliance of Apache SVN on SHA1 (see eg. here).  But also Git depends on SHA1 and one of the most famous adopters of Git is the Linux kernel repository (actually Linus Torvalds created Git to manage the Linux kernel source code).

For some applications to substitute SHA1 with another Hash algorithm requires to rewrite extensively large parts of the source code. This requires time, expertise and money (probably not in this order) and does not add any new features to the application! So unless it is really necessary or no way to keep using SHA1 and avoid the “collisions” is found, nobody really considers to do the substitution. (By the way, it seems that there are easy ways of adding controls to avoid the above mentioned “collisions”, so “sticking plasters” are currently applied to applications adopting SHA1).

But if we think about this issue from a “secure software development” point of view, there should not be any problem in substituting SHA1 with another Hash algorithm. Indeed designing software in a modular way and keeping in mind that cryptographic algorithms have a limited time life expectancy, it should be planned from the beginning of the software development cycle how to proceed to substitute one cryptographic algorithm with another of the same class but “safer” (whatever that means in each case).

Obviously this is not yet the case for many applications, which means that we have still to learn quite a bit on how to design and write “secure” software.

How Secure are the Products of the IT Security Industry?

In the last months quite a long list of critical vulnerabilities in security products have been made public, for example in products by  FireEye, Kaspersky Lab, McAfee, Sophos, Symantec, Trend Micro etc. Wired just published this article with further information and some comments. These incidents make me think if writing secure code is just too difficult for anyone, or if there is something fundamentally wrong in how the IT industry in general and the IT Security industry in particular, is setup.