There are still websites that don't use HTTPS.
For websites that do use HTTPS, if they haven't configured something like HSTS, HPKP or Expect-CT, typing example.com into a web browser will make it will send an unencrypted HTTP request to http://example.com. If the website's content is served only HTTPS, the server will most likely respond with something that redirects the web browser to the HTTPS version of the website (most likely a HTTP 301 or 302 status code). The initial unencrypted HTTP request can be intercepted and modified.
Apple should disable javascript for non https sites.
However, you only need 1 http website to pull off the attack, so its not really a problem that hsts is great at addressing since its opt i per server. The easy way to do this attack is control the local wifi, and make the login landing page malicious.
If bad guys can make a certificate dated February 2018 and valid until May 2021 that certificate will be accepted in Chrome despite not having any SCTs. A real one from that date probably does have SCTs but Chrome only required them in April 2018. Setting Expect-CT now might make Chrome reject that certificate for lacking SCTs if it was shown on a subsequent visit.
A year from the now the window is closed, Chrome will reject a certificate that says it was issued more recently and lacks SCTs, and it will also reject a certificate that says it was issued longer ago, because that violates Baseline Requirements on validity periods. But for now a February 2018 certificate could be valid yet not require SCTs.
All Google-owned TLDs are HSTS-pre-loaded, so if you use a domain in a Google TLD (e.g. example.app) then browsers always use HTTPS anyway. Unfortunately it's unlikely that many older, popular TLDs will pre-load HSTS so most users will be unprotected for the foreseeable future.
Then the find/buy a new exploit and do it again.
It's the same with any of these hacking technology companies, they have to keep moving at the very edge of what is possible.
Apple could indeed fix some CVEs that they know about but every new OS/app/library release has the potential to introduce new CVEs that hackers can exploit.
It's a moving target indeed but due to the increased complexity and questionable quality of modern software there's no way they're going out of business, quite the contrary.
and if a government did it, it would not be much harder for them to do it to everyone in the world at the same time before any exploits get fixed...
All you then have to do is network-inject on a user who visits a non-HSTS site by entering it in their address bar.
No need to bypass encryption.
Could you go into this in a little more detail?
I'm inferring that chains of vulnerabilities are needed to go from some starting point to arbitrary code execution. Is that correct?
Have efforts to secure computer systems over the past ~2 decades succeeded, at least in that much more effort needs to be invested in order to get to the point of arbitrary code execution?
To get ACE, you will generally need a couple of primitives, such as an ArbR/ArbW coupled with an infoleak to get ROP. This will allow you to execute arbitrary code, but you're still stuck within the confines of the current process' privileges. Phone apps are generally heavily sandboxed, and the web browsers tend to be sandboxed even harder. Having ACE in some arbitrary process won't give you the ability to do anything: filesystem will still be out of reach, most of the time you won't even be able to see other processes or even make network requests. So you'll need to break the sandbox.
Breaking the sandbox tend to involve looking for an RCE in a process outside the sandbox that you can communicating with over an IPC channel. And you'll likely need to do this twice: once to break free of the browser sandbox, and once to break the "App" sandbox. If we take a look at chrome for instance (which is very well documented[0][1]), they have sandboxing mechanisms built-in to disallow access to most resources (like the filesystem) to most of its processes, and to prevent access to most of the kernel API surface. And then Android further sandboxes all apps to disallow them from accessing each-other's data. So again you'd have to find another bug somewhere to bypass this.
There are tons of mitigations techniques being developed to make bugs harder to exploit, from Pointer Authentication (making it much harder to exploit ArbR/ArbW bugs) to Control Flow Integrity (making it much harder to create a ROP chain). Of course, not all apps actually have those mitigations in place, but the web browsers tend to enable most, for instance chrome has CFI enabled[2].
[0]: https://chromium.googlesource.com/chromium/src/+/master/docs...
[1]: https://chromium.googlesource.com/chromium/src.git/+/master/...
[2]: https://www.chromium.org/developers/testing/control-flow-int...
RCE: Remote Code Execution. It's fairly straightforward, but basically any vulnerability that allows you to run (native) code without physical access to the phone (e.g. when a user visits a website).
ACE: Arbitrary Code Execution. Basically any technique that allows taking control of the execution to execute your own arbitrary code.
ArbR/ArbW/ArbCall: Arbitrary Read, Arbitrary Write, Arbitrary Call primitives. They tend to be the "basic unit" which you can weave together to further poke at things once you've gained ROP.
ROP: Return Oriented Programming, a technique used to take control of execution when you have the ability to overwrite the Return Pointer of the current stack frame (for instance, from a stack buffer overflow). ROP is used because nowadays, most processes adhere to W^X (Write Xor Execute, basically a memory page is never both writable and executable at the same time), meaning we can't just inject shellcode and jump to it anymore. You can find a small tutorial on ROP at [1].
ROP This can then be used to generate various primitives (ArbW can be achieved by weaving together a "ROP Chain" that calls memcpy with the right registers, for instance).
IPC: Inter-Process Communication. Imagine a Unix Pipe, where two processes communicate with each-other over stdin/stdout. This is an example of an IPC. There are other IPC mechanisms (D-Bus, Unix Sockets, localhost...). When a process is sandboxed, it will sometimes need access to things beyond its sandbox (like accessing the filesystem to access a cached image or something). To do so, it will talk to another process over an IPC mechanism, with a well-defined protocol.
RCE remote code execution
ROP return-oriented programming, which I understand to be using code already on the target and manipulating code flow in order to piece together the boots of programme to execute a routine of the attackers choosing (like cutting letters out of a newspaper to make a ransom note!), https://en.m.wikipedia.org/wiki/Return-oriented_programming
All apps, including Safari, are sandboxed. Apps can't run arbitrary code to affect other apps. So they had to break out of that.
The system itself is sandboxed. Restarting the phone resets it, in many ways, to a "known" state. So they had to install something that would persist across rebooting the phone.
Hmm, might make me think twice now about going to http://neverssl.com/ in a dubious location.
- A remote code execution vulnerability. There are almost certainly multiple vulnerabilities at play here, since long gone are the days where a single vuln gave arbitrary code execution.
- a way to bypass the encryption/https, unless the remote code execution was on a layer before encryption (which seems unlikely). EDIT: Apparently the hack only works on non-encrypted websites.
- Once remote code is achieved, they most certainly need a way to elevate privileges in order to make the hack more persistent and tap into other apps.
There are most likely several CVEs at play here. The amount of effort that went into this hack is, frankly, terrifying.