Hacking Satellites

Not a feat for everybody, but hacking satellites either connecting directly to them or by intrusion on the ground computers that manage them, could have dire consequences: from shutting them down, to burning them in space, spiralling them to ground or turning them into ballistic weapons.

Even if news have not been really confirmed and details are sketchy, it seems that some incidents already happened, starting from 1998, see the ROSAT satellite history, and more recent events as described here, here, here and here for a recent review.

Independently from the confirmation of the incidents, controlling by remote satellites, in particular small ones built also with off-the-shelves / commodity components, coupled with the difficulty (if not impossibility) of applying security patches, can make their “Cybersecurity” risks quite relevant, and effective counter-measures quite difficult. On the other side, due to the costs of building and sending a satellite in space, it is likely that these “Cybersecurity” risks are considered and effectively managed in the planning and developing phases of a satellite life-cycle, or at least so we hope.

CacheOut: another speculative execution attack to CPUs

It was 2 years ago that we learned about Spectre and Meltdown, the first speculative attacks to CPUs which exploit hardware “bugs” and in particular the speculative and out-of-order execution features in modern CPUs. In the last 2 years a long list of attacks followed these initial two, and CacheOut is the last one.

CacheOut, here its own website and here an article about it, builds and improves over previous attacks and countermeasures like microcode updates provided by the CPUs makers, and Operating System patches. The CacheOut attack allows, in Intel CPUs, to read data from other processes including secret encryption keys, data from other Virtual Machines and the contents of the Intel’s secured SGX enclave.

Besides the effective consequences of this attack and the availability and effectiveness of  software countermeasures, it is important to remember that the only final solution to this class of attacks is the development and adoption of new and redesigned hardware CPUs. This will probably take still a few years and in the meantime we should adopt countermeasures based on risks’ evaluation so to isolate critical data and processes to dedicated CPUs or entire computers.

Trust on online information, Fake News and the Information Operations Kill Chain

Can we trust the information we find online?

The general answer is NO, but we all behave as if it was YES.

Personally I see example of it even when I look online for simple information like train schedules or traffic jam conditions. Ever happened to be warned of a major traffic jam ahead and find no traffic whatsoever? Did everybody hear the news and auto-magically disappear from the road?

At a very high level, we can consider two ways in which untrustable (misleading or plainly wrong) news are posted online:

  1. non-intentional or unwilling mistakes due to careleness, untrustable sources, even technical errors in collecting the data;
  2. intentional fake information, eg. “Fake News”, distributed for a purpose usually not moral or legal and at someone particular advantage.

The first goes in the “mistakes” category that hopefully sooner or later will be fixed, but the second goes in the “intentional attacks” category. Unfortunately misusing people trust and conditioning their opinions and actions with “Fake News” is becoming more and more common (just read the news themselves!), to the point that some of these techniques seem to have leaked also to everyday advertising and political campaigning.

Thinking about this, it came back to my mind the “Information Operations Kill Chain” which I read some time ago in Bruce Schneier’s blog here and which I suggest to read and consider.

PS. I am not aware of further developments on this, but if there are, please point them out.

Cloud, Network Security and SASE

We know very well that years ago we lost the concept of (security) network perimeter. Still too often we approach network security with the underlying idea of perimeter defenses: inside the permiter all is ok, and the “firewall” protects us from the outside world.

But in the current world of increasing Cloud / Software as a Service (SaaS) services and Software Defined Networking (SDN), it becomes increasingly impossible to manage IT security from the center of the traditional network and to deploy the protections on the edges. We need to manage the security of traditional and legacy applications, cloud applications, internal and mobile users, all at the same time and with a single approach.

From the networking security point of view this should require to look at our network as a (software defined) mesh of connections composed underneath by different backbones, trunks, local networks and VPNs. Security, access and privileges should be identity-driven and globally distributed on the network. This should imply that the preferred architecture to implement and govern such a security network should be cloud-based if not cloud-native.

If I understand correctly, this is, at least in part, the idea of the most recent approach to Network Security proposed by Gartner and called “Secure Access Service Edge – SASE” (see here and here for more infos).

A Red Cross Report on Cyber Attacks

The International Committee of the Red Cross (ICRC) has published an interesting report on humanitarian consequences of cyber attacks, it can be downloaded here (PDF) and a short summary can be found here.

It is really difficult to realize how pervasive Information Technology (IT) and Internet are today, and what the consequences of cyber attacks can be on everyday life.

Another nail in the coffin of SHA1

This recent paper “From Collisions to Chosen-Prefix Collisions – Application to Full SHA-1” by G. Leurent and T. Peyrin puts another nail in the coffin of SHA1. The authors present a chosen-prefix collisions attack to SHA1 which allows client impersonation in TLS 1.2 and peer impersonation in IKEv2 with an expected cost between 1.2 and 7 Million US$. The authors expect that soon it will be possible to bring down the cost to 100.000 US$ per collision.

For what concerns CA certificates, the attack allows, at the same cost, to create a rogue CA and fake certificates in which the signature includes the use of SHA1 hash, but only if the true CA does not randomize the serial number field in the certificates.

It is almost 15 years that it is known that SHA1 is not secure: NIST deprecated it in 2011, it should not have been used from 2013 and substituted with SHA2 or SHA3. By 2017 all browsers should have removed support for SHA1, but the problem is always with legacy applications that still use it: how many of them are still out there?

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.

The evolution of DNS

DNS, that is the Domain Name System protocol and services, is a fundamental pillar of Internet since it allows to resolve domain names in IP addresses. Recently the number and severity of attacks to the DNS infrastructure have increased noticeably (see for example this US-CERT Alert). At the same time, the discussion on who should manage and how this global infrastructure should be managed, keeps expanding.

Alternative proposals to the ICANN overseen global DNS infrastructure have appeared, starting from the “.onion” hidden TOR domains to, among others, the more recent OpenNIC project and the Blockchain-based BDNS system.

The security and privacy of Internet access and navigation depend crucially on the resolution of domain names to IP addresses. Even if the deployment of DNSSEC will help to improve security and privacy, it is badly needed to give more consideration DNS and help designing a forward path for it as a global service which must be able to guarantee access, privacy, security, integrity, fairness etc. It is a lot to ask, but we will really need it.

On Firefox “Send”

Mozilla has just released a new service, Firefox Send,  to share files with a higher level of security. Firefox Send is quite easy to use, just access the web-page and upload a file (up to 1GB, one needs to register to upload files up to 2,5GB). The service then returns a link to download the file which the user can choose to be valid up to 1 week and to 100 downloads. For an extra layer of security, the user can also add a Password which is then requested before the download.

Under the hood, the file is encrypted and decrypted in the browser of the user using the Web Crypto API and 128-bit AES-GCM. A short description of how encryption is implemented is provided in this page. The secret encryption key is generated by the browser and appended to the link returned by the server for the download, as in (this is not a valid URL)

h[…]s://send.firefox.com/download/b86[…]c92/#jRBroPSur7e8t_wI6-E67w

where the last part of the URL is the secret key.

This is very nice and simple, but to achieve a higher level of security the user has to find a secure way to share with her parties the download link, and sending it by email is not a good idea.

Obviously the use of a Password which can be communicated in other ways (eg. by telephone) makes it more secure. Still the Password is used to create a signing key (with HMAC SHA-256) and uploaded to the server. Then the server checks that a user requesting the file knows the Password by making her sign a nonce. So the Password is not used to encrypt the file but only for an authentication exchange.

I have not found a full security and threat scenario description for this service (some information can be found here and here), but it would be nice to know which are the use-cases that Mozilla has considered for it. Moreover, from a very quick look at the available documentation, it is not very clear to me which are the information that the server can access during the full life-cycle of an uploaded encrypted file.

In any case, Firefox Send seems to be a new and possibly very interesting competitor in the arena of online file sharing services together with Dropbox, Google Drive etc.