7 ms·
"Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability." Given the simplicity of the
by ani-ani 6y ago
"Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability."
Given the simplicity of the exploit, I really doubt that claim. Seems more likely they just don't have a way of detecting whether it happened.
- joering2 6y agoI stand corrected and removing my message now since my scenario wasn’t related to this zeroday bug. Thank you to everyone who educated me.
- zenexer 6y agoThis 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.
- snazz 6y agoI 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.
- jtbayly 6y agoMy 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.
- deathgrips 6y agoYeah, doesn't this just mean they didn't detect misuse?
- thephyber 6y agoIt'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.
- thephyber 6y agoIt 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.
- drivebycomment 6y agoThe 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.
- mlthoughts2018 6y agoHow could you prove the user was the correct user in any given case?
- rubyn00bie 6y agoThey 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.
- mlthoughts2018 6y agoHow 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?
- caseysoftware 6y agoIt 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. :(
- rantwasp 6y agothey used this tool grep. look it up. /s
- lordofmoria 6y agoI 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?
- phamilton 6y agoI'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.
- IncRnd 6y agoExactly. Lack of evidence is not evidence of lack.
- emn13 6y agoWell, 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 https://cocosci.princeton.edu/papers/absentData.pdf
- IncRnd 6y agoInference 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.
- soonoutoftime 6y agoSeems 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.
- nine_k 6y agoI 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.
- Dahoon 6y agoLuckily we don't all live under US law.
- aptwebapps 6y agoTotally 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.
- ceejayoz 6y agoAaron Swartz would likely beg to differ.
- aptwebapps 6y agoAdded 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.
- deleted 6y ago[deleted]
- justapassenger 6y agoIt’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.
- Dahoon 6y ago> 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).
- justapassenger 6y agoInitiative 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.