Seems the only way to trust the companies in such situations is to exploit the vulnerabilities from multiple, unconnectable devices and locations, over as long a period as possible. If the company cannot list all of the attacks, you know they're bullshitting.

I wonder if compromising your own account can be seen as unlawful. It's much like teenagers being found to break the law by making nude photos of themselves: they are found in possession of prohibited materials, even though they obtained them in a lawful way. Cracking your own account in a lawful way could possibly be done by a court order, but otherwise your actions are prohibited by law, even.though there cannot be a malicious intention.

Totally not a lawyer here, but my impression of laws like CFAA is that it revolves around unauthorized access of resources. If the only resources you access are those for which you have authorization, you might be all right.

After edit: "you might be all right." was a poor choice of words. If you piss off the wrong people, you won't be all right.

Aaron Swartz would likely beg to differ.

Added an after edit. I don't mean to say "you'll be fine, go ahead." But Swartz's case was a bit different that the hypothetical described above.

I think the flaw in this plan is "your own account". AFAIK, like credit cards, the company maintains that they own the account and can do whatever they want with it, just deigning to give you the right to access it as they see fit.

Luckily we don't all live under US law.

The one case (and about the only case) I can think of where they can claim above is:

If they have a log of all JWTs issued that records which user requested and which email in JWT, then they can retroactively check if they issued any (user, email) pair that they shouldn't have. Then they can assert that there was no misuse, if they only found this researcher's attempt.

How could you prove the user was the correct user in any given case?

I can think of two possible "root causes" with this vulnerability.

One is where the API ("2nd step" mentioned in the doc, POST with a desired email address to get a JWT) is an authenticated API, meaning it requires a valid credential, but Apple's implementation of this API made a mistake of not checking if the user-requested email belongs to the user or not. In this case, the log can give enough information for the forensic analysis to determine misuse. I presumed this was the case.

The other possibility is if they implemented that API as unauthenticated. I presumed this was not the case - as this is a more difficult mistake to make, and given that they claimed some knowledge of no misuse - but I have no way to know for sure this isn't the case here. The end result would be the same. If the root cause was this case, indeed it's difficult to know if no misuse has happened.

Assume they have two log entries.

  request 678: request from user bananas
  request 678: issued token for bananas

That looks good.

  request 987: request from user <blank>
  request 987: issues token for carrots

That doesn't look good.

They very like have a complete log of the action performed; I'd guess, they'd perform some kind of replay/playback after the bug was fixed, and see what failed to pass. Assuming their changes immediately flag things like the researcher's initial attempts and discovery, it'd probably be pretty safe to say that no one was affected if no other instances are flagged.

How does that answer the question? So what if you can replay logs of all attempts? How can you prove for any specific log that it was the “real” user making the request, and not someone using their email maliciously to make an identical request?

It doesn't. That's also the downside of most login/identity providers that implement some form of "Impersonation."

Without really smart and well-considered limitations and logging, it's impossible to tell the User from the User* without digging through audit trails, etc.. and if the developers/architects involved didn't consider the limitations and logging in the first place, odds are they didn't consider the audit trails either.

And yes, I do this for a living.. and have seen bad things from major organizations. :(

They are the issuer. it's trivial.

It depends what the fix was. If the fix was just to add a validation check to the POST endpoint to validate that the logged in user session matched the payload (and session data was comprehensively logged/stored), this may be verifiable.

There are obviously lots hypotheticals for which this might not be verifiable.

It’s no secret that Apple isn’t great at webservices and they have strong initiative not to keep user data. I could imagine a world where they just didn’t have enough logs to properly investigate and validate it.

> they have strong initiative not to keep user data

What makes you say that? Lots of hacks and leaks shows that Apple only see Privacy as a word to sell stuff. It isn't something they code for if not forced by leaks and hacks (laws in the US also is against privacy by design).

Initiative doesn’t mean they follow it, especially for legacy projects.

While I do think that Apple is using privacy mostly for PR, I wouldn’t be too cynical. It’s likely that new projects are built with higher privacy standards. But also, I wouldn’t be too surprised if their PR department is writing checks that their engineering teams cannot fully cash.

I agree, especially given how many developer “eyes” were on this from having to integrate the log in with Apple flow into their apps.

Just as a first-hand anecdote to back this up, a dev at my former company which did a mix of software dev and security consulting found a much more complex security issue with Apple Pay within the first hour of starting to implement the feature for a client and engaging with the relevant docs.

How did no one else notice this? The only thing I can think of is the “hidden in plain sight” thing? Or maybe the redacted URL endpoint here was not obvious?

Yeah, doesn't this just mean they didn't detect misuse?

It's not clear because it's not a direct quote and Apple probably wasn't explicit about the difference. I wouldn't infer one way or the other from this sentence.

I'd also like the exact wording of their claim. "There is no evidence of misuse or account compromise" is what I would expect them to say, as "There was no misuse or account compromise" likely opens them up to legal repercussions if that isn't 100% accurate.

Exactly. Lack of evidence is not evidence of lack.

Well, depending on how hard you look and what the false negative rate is like, bayesian reasoning would like to differ.

You know what I love about the internet? You think something like this, and you just know somebody's looked into it in some details :D - https://cocosci.princeton.edu/papers/absentData.pdf

Inference isn't evidence. Inference is drawn from evidence and is an educated guess. A guess is not evidence. You fell for the clickbait headline of a pdf.

Evidence isn't absolute proof and there are degrees of evidence. See: Weak evidence, strong evidence.

The idiom that I mentioned is still true, whether you discuss circumstantial or direct evidence. Lack of Evidence isn't Evidence of Lack.

Lack of evidence is always weak evidence for evidence of lack, and pretty strong evidence if you've looked hard enough. If you've trawled through loch Ness with a fine toothed comb for decades and haven't seen Nessie, well then that's pretty good evidence for lack of monster.

You're confusing correlation with causation. Regarding your point about searching - Have you ever lost your keys, searched for a long time without finding them, then found them by happenstance at a later point when not looking? Lack of evidence is not evidence of lack.

I am saying your definition of evidence is overly strict and at odds with both how we use the term in common speech and with what is useful. My definition of evidence for A is an observation B such that P(A|B)>P(A), and with this definition, lack of evidence most certainly is evidence of lack.

Yes, I understand what you mean. You are confusing your particular experiences with the common speech of everyone, which is a logical fallacy.

You can read about the cultural and traditional idiom I wrote at the wikipedia page for "Evidence of Absence" where the first paragraph mentions, "Per the traditional aphorism, 'Absence of evidence is not evidence of absence,' positive evidence of this kind is distinct from a lack of evidence or ignorance[1] of that which should have been found already, had it existed."

There is further information in the wikipedia page for "Argument from ignorance" that shows why your use of evidence is also a logical fallacy. You can infer from indirect evidence, but that doesn't prove a fact.

While indirect evidence may lead one to to believe a fact has been proven, that is not what happens. You can read some of the legal ramifications of using indirect, inferential, or circumstantial evidence to convict beyond a reasonable doubt at https://www.legalzoom.com/articles/why-cant-some-juries-conv....

I stand corrected and removing my message now since my scenario wasn’t related to this zeroday bug.

Thank you to everyone who educated me.

This isn’t an information disclosure vulnerability that would allow someone to gain knowledge of new Apple IDs. It also doesn’t affect first-party applications.

I can’t provide an explanation of the behavior you observed without more information, but I can reasonably conclude that the vulnerability here wasn’t the cause.

I find it hard to believe that signing up for an Apple ID caused the start of the phishing emails unless the email account or computer has been compromised. This is not normal when signing up for an Apple ID.

My guess would be that it was just a lucky guess/bot sending to a lot of addresses. I’ve had email addresses get spam before without using them anywhere.

they used this tool grep. look it up. /s