iOS security breach

Hi there, I read about the following major iOS security breach today.

https://www.vice.com/en_us/article/bjwne5/malicious-websites-hacked-iphones-for-years

I wonder if this exploit could also potentially have gained access to passwords in 1password?

The implant also has access to the user's keychain, which contains passwords, as well as the databases of various end-to-end encrypted messaging apps, such as Telegram, WhatsApp, and iMessage, Beer's post continues. End-to-end encryption can protect messages from being read if they're intercepted, but less so if a hacker has compromised the end device itself.


1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Comments

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    I wonder if this exploit could also potentially have gained access to passwords in 1password?

    Potentially, yes. From what little I understand of this so far, the implant was not crafted to attack 1Password data, but the nature of the pretty much total compromise of the devices means that the creators of it certainly could have specifically attacked 1Password if they'd wanted to. Attacking 1Password might have required a couple of additional steps, as your data is encrypted locally; but given the technical sophistication of the full chain in the attack along with the local power that the attacker gains, there is little doubt that the they would have been capable of doing so. But probably, they wouldn't even have bothered, and would just acquire passwords as the victim used them.

    Don't burn your 0days until you have crossed them

    Everything that is publicly known about this points to this being run by some government or a very powerful organization. And as these involved exploiting unknown vulnerabilities (zero days, or "0days") there is ever reason for the attackers to not let the existence of these attacks being discovered. What we've seen with other state actors using 0days is that they try to target very narrowly to avoid discovery.

    Things like Flame and Stuxnet were discovered (and therefore rendered useless) only because systems beyond the intended targets were impacted (and that by accident). So unless you are a high risk target (say a journalist investigating corruption in a repressive regime) then no one is going to try to get your device compromised (as each attempt increases the risk of discovery).

    There was an excellent (and frightening) talk at Usenix Security by people from Citizen Lab about how such targets are attacked. They are extremely carefully and well-crafted attacks on the specific individuals. After all, the targets know that they are targets and so will be extremely cautious in their behavior and who they communicate with. Yet some of these attacks are successful. (And again, attack failures should not reveal too much about the capabilities of the attacker.) So this is a frightening thing. But it also means that if you are at risk from any of these, you already know that and don't need to read about it here.

    People who are at risk of such things already know that software and operating systems are not enough to protect them. They need extreme operational security, a burden that the rest of us wouldn't undertake. Edward Snowden might put a towel over his head, hands, and keyboard when typing in a password, but that isn't the kind of thing that the rest of us are going to do (or need to do).

    So the bad news is that it appears that the attackers managed to keep this stuff hidden and in operation for years before discovery. The good news is that nobody reading this will have been a target.

    Lessons for us (Improving input validation)

    There are steeply diminishing returns in trying to defend user secrets against very powerful local compromises. But that doesn't mean that there aren't things we can learn from this in ways that do improve your security. Almost all of the iOS vulnerabilities that were exploited in these attacks were listed as being fixed through "Improved input validation". These sorts of bugs are plentiful in a huge range of software. Most of them are really hard to exploit. And unless you spend your days figuring out how to exploit such things, it is very hard to imagine how any particular one might be exploited when less-than-perfect input validation is pointed out.

    Preventative security

    So what we have been improving input validation. Note that input means not only user input or things coming in over the network, but also reading files. We are doing so even where we can't image what an exploit would be or how an attacker could inject malicious input. This is an on-going process that internally we have called part of "preventative security". It is part of taking the time to work on things that might never turn out to lead to security bugs, but potentially could. In our design process we try to specify things to avoid ambiguities in our expectations of what data might look like. This makes it easier to have provably correct input handling.

    This is a process. We aren't there yet with absolutely every bit of input. But we are continuing to improve input validation (and make it easier for us to do so). We don't even know whether the work we've done over the years with this has actually prevented any attacks that otherwise would have happened. Again this is because we can't usually look at an instance of improper input validation and say "ah, this can be exploited by doing X." We might not see a plausible attack on some instance of improper input validation, and perhaps there isn't one. But it is better to validate the input properly instead of giving an attacker the opportunity to prove that such an attack does exist.

  • The good news is that nobody reading this will have been a target.

    Can you explain how you can know that?

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member
    edited August 2019

    Excellent question @sunjunkie. Of course I can't know with certainty that nobody reading this would be a target of such an attack, but I am presuming that very high risk users will be looking (with great deal of caution) at other resources for trying to determine whether they were subject to such an attack. They will be relying on things that are more reliable than our support forums.

    It's like when I see questions on, say, Quora, of "will using X protect me from a concerted effort by the NSA to find out Y about me?" The answer is if you are being specifically and intensely targeted by something like the NSA, then in addition to using the right tools you need substantial operational security, and it is really unlikely that you would be asking on Quora. Or if you are someone who is specifically targeted for such sophisticated attacks and you are looking for answers here or on Quora then you are looking in the wrong places.

    Using the right tools, like 1Password, will substantially raise the cost of any attacker. And I do believe that 1Password's cryptography is not breakable by the NSA; but an entity with that power would go around the cryptography instead of through it. Indeed, the iOS attacks described didn't break the cryptography of things like iMessage or WhatsApp, which they were targeting; instead they went around it.

    If, say, the FBI was willing to spend $100,000 to learn my secrets, that money would get them no where if spent on trying to break 1Password's cryptography or my Master Password. But for that money they could break into my house and tamper with my computers, or install a camera that watches me type my Master Password. And if I were looking for advice on how to defend against such attacks, I would be hiring specialists to train me. I wouldn't be looking on our forums.

  • Hi
    Is it possible for those guys to steal login tokens from 1Password.com service, as they apparently did with Google and other services? Would this be enough to compromise passwords and such?

    Thanks.

  • jpgoldbergjpgoldberg Agile Customer Care

    Team Member

    Hi @lengotengo. In a narrow and technical sense the answer is “no”. But that is because 1Password doesn’t have login tokens in the same way that Google does, and if it did, those wouldn’t provide the keys to the kingdom.

    But that doesn’t mean that an attacker with such extensive control of the local device wouldn’t have been able acquire 1Password data. They just would have needed to take a couple of additional steps that would be in their power.

    Quoting myself from above

    the nature of the pretty much total compromise of the devices means that the creators of it certainly could have specifically attacked 1Password if they'd wanted to. Attacking 1Password might have required a couple of additional steps, as your data is encrypted locally; but given the technical sophistication of the full chain in the attack along with the local power that the attacker gains, there is little doubt that the they would have been capable of doing so. But probably, they wouldn't even have bothered, and would just acquire passwords as the victim used them.

  • Thank you, @jpgoldberg

    I am happy to know that additional steps are required to access 1Password data, even in a very sophisticated attack like the one on the news.

    I understand that a compromised device is open to pretty much everything, but it is good to know that some of my keys would be safe(r) even in a terrible scenario like that. Props to you guys.

  • DanielPDanielP 1Password Alumni

    On behalf of jpgoldberg, you are welcome. And thank you for your understanding and the kind words :)

This discussion has been closed.