5 ms·

A code execution vulnerability isn't enough. To work on truly any website, they need: - A remote code execution vulnerability. There are almost certainly multi

A code execution vulnerability isn't enough. To work on truly any website, they need: - 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.

titanomachy 6y ago
A huge amount of effort went into developing this hack. Then the company NSO productized the hack and sold it to governments.
- Biganon 6y ago
  And as soon as Apple fixes it, they're out of business? I really don't understand how any of that works.
  - ObsoleteNerd 6y ago
    They make enough money in between selling the tool and Apple patching the exploit to make it worthy, not to mention the amount of people who don’t do updates meaning the tool is still effective some of the time. Then the find/buy a new exploit and do it again.
  - ChuckNorris89 6y ago
    Fixes it? 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.
  - Closi 6y ago
    I think the assumption is that if they have the capability to create this exploit chain, they also likely have the capability to develop others (and possibly have others waiting to deploy if these are discovered and patched). It's the same with any of these hacking technology companies, they have to keep moving at the very edge of what is possible.
  - deleted 6y ago
    [deleted]
afuchs 6y ago
From my understanding, it is easy enough to bypass HTTPS encryption if you need to intercept traffic for an attack like this. You only need to intercept and modify the traffic for a website, not a specific website. 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 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.
- c22 6y ago
  Not to mention if DNS isn't encrypted and you control the network you can just redirect requests wherever you want.
  - ec109685 6y ago
    Not to a non-https website if the user is visiting a secure site. Apple should disable javascript for non https sites.
    - aeternum 6y ago
      Ability to disable javascript for non-https would be a great security setting. Aligns well with Apple's goal for privacy and security as many wireless hotspots and even ISPs abuse HTTP javascript injection.
      - tjoff 6y ago
        Ironically, in response when people realize how good the non-javascript web is they will demand all sites be http.
    - yonixw 6y ago
      Location header still can redirect you to well-crafted HTTPs site, so it won't really help
coronadisaster 6y ago
> The amount of effort that went into this hack is, frankly, terrifying. 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...
lazyjones 6y ago
But "any website" here seems to be "any non-https website", so this is more likely: a) router or baseband-processor hack plus b) malicious JS injection into unencrypted HTML plus c) browser vulnerability via JS. No need to bypass encryption.
ringshall 6y ago
> "There are almost certainly multiple vulnerabilities at play here, since long gone are the days where a single vuln gave arbitrary code execution" 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?
- stepstop 6y ago
  Yes you’re correct about the chains. For examples, look at Stuxnet or some of the more expensive Chrome bug bounties over the past few years.
- CGamesPlay 6y ago
  Yes. For example, webpages viewed in Safari are sandboxed. You can't run arbitrary code to affect parts other webpages. So they had to break out of that. 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.
- roblabla 6y ago
  For the most part, yes, it's much harder to get ACE today than it was 20 years ago, and even then ACE doesn't actually grant you any fancy capabilities on a modern phone. 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/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/master/docs... [1]: https://chromium.googlesource.com/chromium/src.git/+/master/docs/linux/sandboxing.md https://chromium.googlesource.com/chromium/src.git/+/master/... [2]: https://www.chromium.org/developers/testing/control-flow-integrity https://www.chromium.org/developers/testing/control-flow-int...
hn_throwaway_99 6y ago
Glad you fixed your comment with your edit, but this really isn't that hard to imagine at all: a privilege escalation in Safari is exactly how one of the original jailbreaks worked: https://en.wikipedia.org/wiki/JailbreakMe https://en.wikipedia.org/wiki/JailbreakMe. 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.
- StavrosK 6y ago
  Sure, but we've come a long way from the original jailbreak, and what this hack is is essentially another full jailbreak from another Safari vulnerability, which is pretty scary.
metafunctor 6y ago
”only works on non-encrypted websites”. Hmm, might make me think twice now about going to http://neverssl.com/ http://neverssl.com/ in a dubious location.

titanomachy 6y ago

A huge amount of effort went into developing this hack. Then the company NSO productized the hack and sold it to governments.

Biganon 6y ago
And as soon as Apple fixes it, they're out of business? I really don't understand how any of that works.
- ObsoleteNerd 6y ago
  They make enough money in between selling the tool and Apple patching the exploit to make it worthy, not to mention the amount of people who don’t do updates meaning the tool is still effective some of the time. Then the find/buy a new exploit and do it again.
- ChuckNorris89 6y ago
  Fixes it? 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.
- Closi 6y ago
  I think the assumption is that if they have the capability to create this exploit chain, they also likely have the capability to develop others (and possibly have others waiting to deploy if these are discovered and patched). It's the same with any of these hacking technology companies, they have to keep moving at the very edge of what is possible.
- deleted 6y ago
  [deleted]

afuchs 6y ago

From my understanding, it is easy enough to bypass HTTPS encryption if you need to intercept traffic for an attack like this. You only need to intercept and modify the traffic for a website, not a specific website. 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 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.

c22 6y ago
Not to mention if DNS isn't encrypted and you control the network you can just redirect requests wherever you want.
- ec109685 6y ago
  Not to a non-https website if the user is visiting a secure site. Apple should disable javascript for non https sites.
  - aeternum 6y ago
    Ability to disable javascript for non-https would be a great security setting. Aligns well with Apple's goal for privacy and security as many wireless hotspots and even ISPs abuse HTTP javascript injection.
    - tjoff 6y ago
      Ironically, in response when people realize how good the non-javascript web is they will demand all sites be http.
  - yonixw 6y ago
    Location header still can redirect you to well-crafted HTTPs site, so it won't really help

coronadisaster 6y ago

> The amount of effort that went into this hack is, frankly, terrifying. 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...

lazyjones 6y ago

But "any website" here seems to be "any non-https website", so this is more likely: a) router or baseband-processor hack plus b) malicious JS injection into unencrypted HTML plus c) browser vulnerability via JS. No need to bypass encryption.

ringshall 6y ago

> "There are almost certainly multiple vulnerabilities at play here, since long gone are the days where a single vuln gave arbitrary code execution" 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?

stepstop 6y ago
Yes you’re correct about the chains. For examples, look at Stuxnet or some of the more expensive Chrome bug bounties over the past few years.
CGamesPlay 6y ago
Yes. For example, webpages viewed in Safari are sandboxed. You can't run arbitrary code to affect parts other webpages. So they had to break out of that. 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.
roblabla 6y ago
For the most part, yes, it's much harder to get ACE today than it was 20 years ago, and even then ACE doesn't actually grant you any fancy capabilities on a modern phone. 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/design/sandbox.md https://chromium.googlesource.com/chromium/src/+/master/docs... [1]: https://chromium.googlesource.com/chromium/src.git/+/master/docs/linux/sandboxing.md https://chromium.googlesource.com/chromium/src.git/+/master/... [2]: https://www.chromium.org/developers/testing/control-flow-integrity https://www.chromium.org/developers/testing/control-flow-int...

hn_throwaway_99 6y ago

Glad you fixed your comment with your edit, but this really isn't that hard to imagine at all: a privilege escalation in Safari is exactly how one of the original jailbreaks worked: https://en.wikipedia.org/wiki/JailbreakMe https://en.wikipedia.org/wiki/JailbreakMe. 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.

StavrosK 6y ago
Sure, but we've come a long way from the original jailbreak, and what this hack is is essentially another full jailbreak from another Safari vulnerability, which is pretty scary.

metafunctor 6y ago

”only works on non-encrypted websites”. Hmm, might make me think twice now about going to http://neverssl.com/ http://neverssl.com/ in a dubious location.