Another example of how difficult is to securely implement cryptography: a study (read here a summary) shows that Mega’s encryption scheme had (patches have already been applied) some faults which in some situation allowed a skilled attacker to access user data in clear.
Tag Archives: Vulnerabilities
Cryptography is still Difficult to Implement
This is a recurring theme (see eg. this older post), how difficult it is to implement Cryptography in the “right” way. It requires a lot of knowledge and expertise in Cryptography, programming skills are not enough.
Recently I read this article “PRACTICAL BRUTEFORCE OF AES-1024 MILITARY GRADE ENCRYPTION” by Kudelski Security Research, in which they show how it was possible to brute force what was called “AES-1024 military grade encryption“. AES is not broken (and “AES-1024” does not really stand for AES with 1024-bit keys) but the main problem was the custom procedure adopted to transform a user chosen password into an AES encrypting key.
Which again shows how it is difficult to implement Cryptography to attain the expected security goals.
CISA Catalogue of Known and Exploited Vulnerabilities
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.
Risks of Cryptography
Cryptography is too often considered as the “final” solution for IT security. In reality cryptography is often useful, rarely easy to use and brings its own risks, including an “all-in or all-out” scenario.
Indeed suppose that your long-lived master key is exposed, then all possible security provided by cryptography is immediately lost, which it seems to be what happened in this case.
Hardware Vulnerability of Some FIDO U2F Keys
Hardware Security Keys, like Google Titan Key or Yubico YubiKey, implementing the FIDO U2F protocol, provide what is consider possibly the most secure 2nd Factor Authentication (2FA) measure. Indeed the private key is protected in Hardware and should be impossible to copy, so that only the physical possession of the hardware token provides the authentication.
But a recent research (see here for the research paper, and here and here for some comments) shows that a class of chip (the NXP A700X) is vulnerable (CVE-2021-3011) to a physical hardware attack which allows to extract the private key from the chip itself, and then to clone the security key. To fully succeed, the attack requires to know the credential of the service(s) for which the security key works as 2FA and the physical availability of key itself for at least 10 hours. Then the security key is dismounted and the secret key is obtained by measuring the electromagnetic radiations emitted by the key during ECDSA signatures. Finally a new security key can be cloned with the stolen secret key.
From a theoretical point of view, this vulnerability violates the fundamental requirement of an hardware security key, that is that the private key cannot be extracted from the hardware in any way. But it should also be noted that the FIDO U2F protocol has some countermeasures which can be useful to mitigate this vulnerability, like the presence of a counter of the authentications done between a security key and a server so that a server can check if the security key is sending the correct next sequence number which would be different from the one provided by the cloned security key.
On practical terms, it all depends on the risks associated with the use of the security key and the possibility that someone will borrow your security key for at least 10 hours without anybody noticing it. If this constitutes a real risk, then check if your security key is impacted by this vulnerability and in case it is, change it. Otherwise if this attack scenario is not a major threat, it should be reasonably safe to continue to use even vulnerable security keys for a little while, while keeping up to date with possible new developments or information from the security keys manufacturers. Even in this case, vulnerable security keys should anyway be changed as soon as convenient.
Patch now or …
Nothing!
It seems that we (as IT practitioners all together) are not getting it. Have a look at this National Security Agency Cybersecurity Advisory and check the listed CVEs which are scanned for vulnerability and/or exploited: some go back to 2018, 2017, 2015 and patches exist.
Another Example of how Implementing Cryptography is Tricky (and a Score 10 CVE)
It has recently been published the description of Zerologon, CVE-2020-1472 (see here for a summary and here for the technical paper), and do not worry since the bug has already been patched by Microsoft in August (see here).
The bug allows anyone who can connect in TCP/RPC/Netlogon to an unpatched Active Directory domain controller to become a domain administrator, nothing else needed. The cause of this bug is a minor glitch in the implementation of the cryptographic algorithm AES-CFB8: the Initialisation Vector has been kept fixed at zero instead to be unique and randomly generated (more details are provided in the technical paper mentioned above).
Always about Security Patching and Updates
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.
On the Latest Bluetooth Impersonation Attack
Details on a new attack on Bluetooth have just been released (see here for its website). From what I understand it is based on two weaknesses of the protocol itself.
A quick description seems to be the following (correct me if I have misunderstood something).
When two Bluetooth devices (Alice and Bob) pair, they establish a common secret key mutually authenticating each other. The secret common key is kept by both Alice and Bob to authenticate each other in all future connections. Up to here all is ok.
Now it is important to notice the following points when Alice and Bob establish a new connection after pairing:
- the connection can be established using a “Legacy Secure Connection” (LSC, less secure) or a “Secure Connection” (SC, secure), and either Alice or Bob can request to use LSC;
- one of the devices acts as Master and the other as Slave, a connection can be closed and restarted and either Alice or Bob can request to act as Master;
- in a “Legacy Secure Connection” the Slave must prove to the Master that it has the common secret key, but it is not requested that the Master proves to the Slave that it also has the common secret key (Authentication weakness);
- in a “Secure Connection” either Alice or Bob can close the connection and restart it as a “Legacy Secure Connection” (Downgrade weakness).
Now Charlie wants to intercept the Bluetooth connection between Alice and Bob: first he listens to their connection and learns their Bluetooth addresses (which are public). Then Charlie jams the connection between Alice and Bob and connects as a Master to Alice using LSC and Bob’s Bluetooth address, and connects as a Master to Bob using LSC and Alice’s Bluetooth address. Since Charlie is Master both with respect to Alice and to Bob and since he can always downgrade the connection to LSC, he does not have to prove to neither Alice or Bob that he knows their common secret key. In this way Charlie is able to perform a MitM attack on the Bluetooth connection between Alice and Bob (obviously this description is very high level, I sketched just an idea of what is going on).
The bad point about this is that it is a weakness of the protocol, so all existing Bluetooth implementations are subject to it. The good point is that the fix should not be too difficult, except for the fact that many (too many) devices cannot be patched! Fortunately this attack seems not to apply to Bluetooth LE, but still I expect that most Bluetooth devices subject to this attack will never be patched.
But we should also consider the real impact of this attack: to perform it, the attacker Charlie should be physically near enough to the two devices (Alice and Bob) with a dedicate hardware (even if not so expensive), so this limits the possible implementations. Moreover this attack can have important consequences if Bluetooth is used to transfer very sensitive information or for critical applications (for example in the health sector). In other words, I would not worry when using Bluetooth to listen to music from my smartphone but I would worry if Bluetooth is used in some mission critical applications.
Whats’s happening in Cyber/IT Security?
Comparing current reported cyber/IT security threats, attacks and incidents to what happened a few years ago, it seems to me that something has surely changed (I must warn that these conclusions are not based on statistics but on reading everyday bulletins and news).
On one side, security surely has improved: vulnerabilities are reported and fixed, patches are applied (at least more often), security policies, standards and practices are making a difference. Still managing password and properly configuring systems and services exposed on Internet remain very difficult tasks too often performed without the required depth.
But security has improved, which also means that attackers have been moving to easier and more lucrative approaches which have to do mostly with the “human interface”. In other words: fraud.
The first example is ransomware, that is the attacker is able to access the victim system, copy vast amount of data, then encrypt it or remove it and finally ask a ransom not only to return the data but also to avoid making it public on Internet. Since everybody is getting better in making backups, here the important point is the “making it public on Internet” so that the ransom is asked more to prevent sensitive data to be published than to restore the systems.
The second example is Targeted Phishing attacks, Business Email Compromise and similar scams in which the attacker impersonate a well known or important person by writing emails, letters, making phone calls etc. to convince typically a clerk but in some cases also a manager, to send a large amount of money to the wrong bank account.
Neither of these two types of attacks is new, but now they are filling the news daily. Even if cyber/IT security can still improve tremendously, there have been and there are notable security improvements which makes it that attacks are aimed more often to the weakest link: the human user.
Andrea Pasquinucci 