We know that IoTs are really critical for IT Security, and recently researchers at Check Point (see here, here and here for more details) have shown how to take over a WiFi network by exploiting remotely a vulnerability in some light-bulbs.
Tag Archives: Vulnerabilities
Another Nail in the Coffin of SHA1
A few days ago, a new attack has been made public which makes it easier to forge hash (or “message digests”) computed with SHA1 (see for example this article for more details).
This new collision attack makes it faster and less expensive to create two documents with the same digital signature using SHA1 or, having a digitally signed document where the digital signature uses SHA1 as hash algorithm, to create a different second document which has the same digital signature.
It has been known since a few years that SHA1 is broken and that it should not be used for digital signatures and in general for security purposes (actually NIST suggested to stop using SHA1 already in 2012). But as usual, in the real world there are still many, too many legacy applications which today continue to use SHA1, one example being legacy PGP keys and old PGP digital signatures.
This new result should be at least a useful reminder to all of us to check if we are still using SHA1 in some applications and in case finally update it.
Patching timing is getting tight
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.
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).
WannaCry …
Is this the wakeup call for everybody, companies and people alike, to give the right consideration to IT security? (In this case it would have meant just to patch in time.)
I doubt so.
Hardware Vulnerabilities (Again), Cloud and Mobile Security
Have a very Happy New Year!
… and to start 2017 on a great note, I write again about Hardware Vulnerabilities with comments on Cloud and Mobile Security.
The opportunity for this blog entry has been provided to me by the talk “What could possibly go wrong with <insert x86 instruction here>? Side effects include side-channel attacks and bypassing kernel ASLR” by Clémentine Maurice and Moritz Lipp at Chaos Computer Club 2016 which I suggest to watch (it lasts 50 minutes and it is not really technical despite its title).
A super-short summary of the talk is that it is possible to mount very effective side- (in particular time-) channel attacks on practically any modern Operating System which allow to extrafiliate data, open communication channel and spy on activities like keyboards inputs. All of this using only lecit commands and OS facilities, but in some innovative ways.
The reason for which these attacks are possibile is that the hardware does not prevent them, actually some hardware features, added to improve performances, make these attacks easier or even possible (see also my previous post on Hardware Vulnerabilities about this). So from the Security point of view these Hardware features should be considered as Vulnerabilities.
What is it possible to do with these techniques? Considering Cloud, it is possible to monitor the activities of another Virtual Machine running on the same hardware, extract secrect cryptography keys (but this depends on how the algorithm and protocols are implemented), establish hidden communication channels etc.
Similarly for Mobile, it is possible to have a totally lecit App to monitor the keyboard activity, or 2 Apps to establish a hidden communication so that one reads some data and the other sends it to a remote destination, all without violating any security rule (actually each one having very limited privilegies and restricted setups).
Morevoer it seeems easy to embed this kind of attacks in lecit applications and current anti-virus seem to lack the capabilities needed to intercept them. Indeed the activites performed to implement these attacks look almost identical to the ones performed by any program and it seems that only a particular performance monitoring could discover them.
On Denial of Service attacks and Hardware vulnerabilities
Denial of Service attacks are growning and getting the attention of the news: some of the latest incidents are krebonsecurity , OVH and Dyn. The economics behind these attacks are helping the attackers: today it costs little to mount a devastating DDoS attack able to block even a sizable part of Internet, thanks to all the botnets of unsafe machines, from PCs to routers and IoTs. Defence can be much more expensive than attack, and in some cases even than the ransom.
How did we get in this mess? This trend is not good at all, these attacks could threaten Internet itself, even if this would not be in the interest of the attackers (not considering State sponsored ones).
Fixing the current situation will be extremely expensive, many devices cannot be “fixed” but need just to be replaced. But before doing that, we need to build “secure” devices and design networks and protocols that support them and are somehow interoperable with the current ones. How? And When?
At the same time, a new trend is emerging: security vulnerabilities in Hardware.
The Rowhammer bug and its recent implementations in Virtual machines and Adroid phones (DRAMMER) or the ASLR vulnerability can open new scenarios. Hardware must provide the foundation of the security of all IT processing: data should be protected, accesses should be controlled etc. But we are discovering that the Hardware that we have been relying upon for the development of IT in the last 20 years, could have reached its limits. New security features are needed (see for example this) and vulnerabilities are discovered that must be managed, and not always it will be possible to fix them in software.
On the Security of Modern Cryptography
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?
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.
Implementing Cryptography right is hard
The security researcher Gal Beniamini has just published here the results of his investigation on the security of Android’s Full Disk Encrytion and found a way to get around it on smartphones and tablets based on the Qualcomm Snapdragon chipset.
The cryptography is ok but some a priori minor implementation details give the possibility to resourceful attackers (like state / nation agencies or well funded organized crime groups) of extracting the secret keys which should be protected in hardware. The knowledge of these keys would allow to decrypt the data in the file systems, the very issue which has been at the basis of the famous Apple vs. FBI case a few months ago.
Software patches have been released by Google and Qualcomm but, as usual with smartphones and tablets, it is not clear how many afflicted devices have received the update or will ever receive it.
In a few words, the problem lies in the interface between the Qualcomm’s hardware module, called the KeyMaster module, which generates, manages and protects the secret keys and the Android Operating System that needs to indirectly access the keys in this case to encrypt and decrypt the file-system. Some KeyMaster’s functions used by Android can be abused to make them reveal the secret keys.
This is another case which proves how it is difficult to implement cryptography right.
Andrea Pasquinucci 