13 ms·
Zero-day in Sign in with Apple
- homakov 6y agoDoes it rely on a service to log you in with same email that you provide? Because normally services don’t do that. They suggest you to attach new apple account to old account with that email, but allowing outright logging in would be very bad practice.
- deleted 6y ago[deleted]
- fortran77 6y agoWhat's amazing is that Apple gets away with claiming their computers are "secure by design." https://www.apple.com/business/docs/site/AAW_Platform_Security.pdf https://www.apple.com/business/docs/site/AAW_Platform_Securi... There's nothing inherent in their design that guarantees security.
- lotsofpulp 6y agoBut for some reason I have never had to remove malware from my parents’ iOS or macOS devices.
- Lammy 6y agoDon't assume that malware will make itself visible. This isn't 2003. iOS vulnerabilities have been used to facilitate genocide: https://blog.trendmicro.com/trendlabs-security-intelligence/operation-poisoned-news-hong-kong-users-targeted-with-mobile-malware-via-local-news-links/ https://blog.trendmicro.com/trendlabs-security-intelligence/... e: Hello CCP downvote brigade :)
- dang 6y agoPlease read and follow the site guidelines. You broke at least two of them there. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- duskwuff 6y agoThis software security issue in Sign In With Apple was unrelated to the security of Apple's hardware platform.
- fermienrico 6y agoLiterally every system in the world has flaws, no matter how secure. We just don't know about these bugs yet.
- resfirestar 6y ago"Every system in the world has flaws" and "it's a serious problem that one of the world's most important software vendors, that markets itself as the most secure, keeps releasing products with flaws that would have been discovered in a very basic audit" are not incompatible statements..
- fermienrico 6y agoEven then there will be more flaws. I don't think it is possible to build a 100% secure system in the modern age of 22 abstraction layers between the atom to the data center. Perhaps you do not understand the staggering complexity that lies behind watching a cat video on your iPhone. There are almost uncountable ways to break into the system. This is why there is a bug bounty program from every company - from Stripe (you could argue as a major software company in payment systems) to Microsoft, from Apple to Gitlab, every company has a bug bounty program. Why do you think they give out $1m for a serious bug? If they were not serious about it, that sounds like a big waste of time. This kind of entitlement attitude is usually from people who've never developed a complex piece of software such as an operating system.
- jagged-chisel 6y ago> This bug could have resulted in a full account takeover of user accounts on that third party application irrespective of a victim having a valid Apple ID or not. The headline makes me think the entire problem lies with Apple, when that’s not the case.
- saagarjha 6y agoThis seems very much like Apple’s bug, to the extent that they paid out a $100k bug bounty?
- jagged-chisel 6y agoReally? > ...affected third-party applications which were using it and didn’t implement their own additional security measures.
- Kikawala 6y agoIs everyone in this thread only going to read the first two paragraphs of the article and skip the rest of it? > I found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple’s public key, they showed as valid. This means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim’s account.
- dwaite 6y agoTo be honest, I think the author is misrepresenting this, just as they falsely said that this was a "zero-day".
- detaro 6y agoThat there were ways of mitigating it (I'd assume verifying email addresses out of band?) doesn't mean it's not Apple's problem when their authentication system can be tricked to confirm false identities, when its entire purpose is confirming identities.
- 6y ago
- rvz 6y ago> I found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple’s public key, they showed as valid. This means an attacker could forge a JWT by linking any Email ID to it and gaining access to the victim’s account. Great writeup there. Looks like a Apple JWT bug and the verification went through despite it being 'signed' and 'tamperproof'. Clearly its footguns allowed this to happen, thus JWTs is the gift that keeps on giving to researchers. What did I just outline days before? [0]. Just don't use JWTs, there are already secure alternatives available. [0] https://news.ycombinator.com/item?id=23315026 https://news.ycombinator.com/item?id=23315026
- arkadiyt 6y agoNo one should be using JWT but it's unfair to blame JWT here. Apple wasn't verifying the supplied email address belonged to the signed in user - that's completely outside of the token format they chose.
- switz 6y ago> No one should be using JWT I've heard criticisms of JWT -- mostly around the lack of ability to revoke a JWT. One could then introduce a refresh token with a longer ttl, which can be revoked on the server. But of course then you lose some of the statelessness that JWT benefits from. But still, it seems like a reasonable approach to authentication to me. I can authenticate with several services if need be, and I can check locally if my token is 'likely' valid. Care to expand why you think one shouldn't use JWT tokens?
- nick-garfield 6y ago> No one should be using JWT What??
- blntechie 6y agoIn the apps I write for my org integrating with the org SSO provider, I treat the JWT tokens mostly like a non-JWT token. Verify the token with the IDP, map the token to a specific user and never relying on the JWT payload user info for the resource auth. It takes additional 0.25s during the login process but has never let me down. As the SSO provider was issuing non-JWT tokens few years back, this was the way we went about making sure the user is who they are saying they are and just stuck with the same approach when they moved to JWT tokens.
- awinter-py 6y agomy brain mis-parsed as: (sign in) with (apple zero day) which is kind of appealing
- Retr0spectrum 6y agoFor anyone else wondering, the correct parse seems to be (Sign in with Apple) (Zero Day)
- saagarjha 6y agoI did that too and wondered if they were finally offering a real bug bounty platform…
- big_youth 6y agoThey have a bug bounty program: https://developer.apple.com/security-bounty/ https://developer.apple.com/security-bounty/ I actually think they have a good approach. Rewarding major finds with good payouts and avoiding the flood of info and low level web app ‘bugs’.
- saagarjha 6y agoI am well aware of the bug bounty program. I think it needs work.
- jtbayly 6y agoI’m not a security researcher, but this guy got paid $100k. Seems to be working?
- saagarjha 6y agoOne example of a bug being fixed and a researcher being paid does not mean it works, generally.
- 1f60c 6y agoMe too! For me it was because I've usually seen "zero day" written as "0day".
- tusharsoni 6y agoExcellent writeup! About 4 months ago, I wrote a comment[0] on HN telling folks how Apple simply omitted the server-side validations from their WWDC videos. And given the lack of good documentation at the time, WWDC videos were what most developers were following. Even then, the only "security" that developers had was that the attacker wouldn't know the victim's Apple userId easily. With this zero-day attack, it would have been trivial for many apps to get taken over. [0] https://news.ycombinator.com/item?id=22172952 https://news.ycombinator.com/item?id=22172952
- zemnmez 6y agoyour original post has several replies explaining why this is not a security issue. the token you ultimately get is a signed concatenation of 3 base64 encoded fields, and unless you decided to manually separate and decode these without verification (instead of doing the easy thing, just using a standard OIDC library) you would not have any user data that could ultimately result in a security issue
- oauea 6y agoWow, I'm so glad that apple forced me to implement this broken garbage into my apps! For those not aware, some time ago apple decided it would be a good idea to develop their own sing in system, and then force all apps on their store (that already support e.g. Google Account login) to implement it. So they brought a huge amount of additional complexity in a large amount of apps, and then they fucked up security. Thank you apple!
- toomuchtodo 6y agoI still trust Apple over a rando site or SaaS app. No system is flawless.
- oauea 6y agoFortunately some rando site or SaaS app doesn't have the leverage to force me to implement additional garbage! Apple does, and did. I'm still surprised that this didn't trigger an antitrust investigation like when Microsoft abused their monopoly to push internet explorer. This is exactly the same thing, if not worse.
- deleted 6y ago[deleted]
- cdubzzz 6y agoI agree that the requirement from Apple here is kind of dumb, but I don’t see how it would not be in the best interest of a user of an app on an iOS device to have the option to sign in with an Apple ID. It also seems silly to consider it “garbage” when you already using a Google Account solution that is essentially the same thing.
- oauea 6y agoIt's garbage because it was forced into already functioning apps with the threat of removal, and because it evidently has gaping security holes.
- 6y ago
- phamilton 6y ago> The Sign in with Apple works similarly to OAuth 2.0. > similarly I understand why they wanted to modify OAuth 2.0, but departing from a spec is a very risky move. > $100,000 That was a good bounty. Appropriate given scope and impact. But it would have been a lot cheaper to offer a pre-release bounty program. We (Remind) occasionally add unreleased features to our bounty program with some extra incentive to explore (e.g. "Any submissions related to new feature X will automatically be considered High severity for the next two weeks"). Getting some eyeballs on it while we're wrapping up QA means we're better prepared for public launch. This particular bug is fairly run-of-the-mill for an experienced researcher to find. The vast majority of bug bounty submissions I see are simple "replay requests but change IDs/emails/etc". This absolutely would have been caught in a pre-release bounty program.
- saagarjha 6y agoApple supposedly marks certain beta builds with a bounty multiplier. I say supposedly because like their "research iPhones" they mentioned it in a presentation once and I never heard about it again.
- snazz 6y agoI'm guessing that the research iPhones were given to a very select group of security researchers with track records of reporting important vulnerabilities under some kind of NDA.
- NicoJuicy 6y agoPerhaps slightly related that finding Apple zero days was less bounty award than finding Android zero days. I think we can wrap up the security and anonymous part that Apple has been claiming for their overpriced devices.
- saagarjha 6y agoWrong exploit target.
- matchbok 6y agoOverpriced? The average android phones cost the same as iPhone. That argument is tried and not relevant anymore. Plus, iPhones actually work longer than a year.
- NicoJuicy 6y agoAnd what is the root cause of a minority of Android phones raising their prices every year :) Plus I have my Android phone for 3 years now. The one before that was for 4 years old and priced at 345 €. At least use a counter argument that is correct.
- tpush 6y ago> The average android phones cost the same as iPhone. They don't.
- gruez 6y agoIs it me or is this writeup low on details? There are a couple of commenters saying that this is a great writeup, but all it amounts to is: 1. what sign in with apple is 2. sign in with apple is like oauth2 3. there's some bug (not explained) that allows JWTs to be generated for arbitrary emails 4. this bug is bad because you can impersonate anyone with it 5. I got paid $100k for it
- cheez 6y agoit's literally that simple.
- ahupp 6y agoIt seems low on details because the exploit was incredibly simple. AFAICT you didn't have to do anything special to get the signed token, they just gave it out. > Here on passing any email, Apple generated a valid JWT (id_token) for that particular Email ID.
- antoncohen 6y agoI think the write up is so short because the bug is so simple. Send a POST to appleid.apple.com with an email address of your choice, and get back an auth token for that user. Use the auth token to log-in as that user. It's that simple.
- snazz 6y agoDid it show what URL you had to send the request to? It looked to me like that was redacted. I'm guessing that that URL would have been in the developer documentation.
- adrianmonk 6y agoThe URL has "X"s in it. I don't know if that means it is redacted or is variable. Note that when they give the POST request, they say "Sample Request (2nd step)". But what is step 2? The diagram above shows step 2 as a response, not a request. At least that's how I interpret an arrow pointing back toward the user. So the write-up conflicts with the diagram. How do you resolve that conflict? One guess is that "Sample Request (2nd step)" should say "1st step" instead. Another guess is that the arrow directions don't necessarily always indicate whether a step is a request or a response, so that step 1 could be a request and response, and step 2 could be another request and response that POSTs to a secret URL that was learned about in step 1. (This guess could make sense because the request is a JSON message with just the email field. There must be credentials somewhere, so either it's redacted or some kind of credentials were given another way, like in step 1.) If this second guess is right, then a follow-on guess is that the crux of the bug is that in step 1, you sign in with a particular email, then Apple says "OK, now here's a secret URL to call to get a JWT token", and then in step 2, you change email, and it doesn't notice/care that you changed emails between step 1 and 2.
- 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.
- 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.
- 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.
- deathgrips 6y agoYeah, doesn't this just mean they didn't detect misuse?
- thephyber 6y ago
- moralestapia 6y ago$100,000 (!) Props to Apple for raising the bar on bounties!
- calimac 6y agoIs the dev team that wrote that line of code fired?
- sparker72678 6y agoAny word on what the fix was?
- neop1x 6y agoAssigning generated emails to the creator accounts and not allowing their re-use? What else, really...
- xyst 6y agoGlad we have people willing to disclose these vulnerabilities rather than just selling it on the black market.
- cfors 6y agoWow. That's almost inexcusable, especially due to the requirement of forcing iOS apps to implement this. If they didn't extend the window (from originally April 2020 -> July 2020) so many more apps would have been totally exploitable from this. After this, they should remove the requirement of Apple Sign in. How do you require an app to implement this with such a ridiculous zero day?
- thephyber 6y agoI’m of the mind that just about any security bug is “excusable” if it passed a good faith effort by a qualified security audit team and the development process is in place to minimize such incidents. The problem I have is that I can’t tell what their processes are beyond the generic wording on this page[1] [1] support.apple.com/guide/security/introduction-seccd5016d31/web
- resfirestar 6y agoEven if there was clear evidence that this system underwent a proper security audit, with a failure this basic you would have to ask why it didn't work. What is going on inside Apple that brought them to the point of releasing a lock that simply opens with any key, despite the efforts of their state of the art lock design process and qualified lock auditors?
- Areading314 6y agoWriting some test cases for "can anyone generate a valid token" or "does an invalid token allow access" should be the first thing to do when writing an auth system.
- thephyber 6y agoYour test cases make sense, but they ignore an obvious hypothetical possibility: The OIDC implementation was a well-tested core feature (with the tests that you mention), but the email proxy feature was a bolt on that was somehow not considered risky (so it could easily have bypassed a full, renewed security audit). Also, it's not sufficient to "have a test case". The intent and the implementation must be coherent.
- broooder 6y agoYou didn’t make enough money.
- yalogin 6y agoWow that’s a really simple bug. Kudos to the OP to even try that. Most people would just look elsewhere thinking Apple of all companies would get such a basic thing right.
- Yajirobe 6y agoWhat do you mean simple? The result/exploit is simple, but what is the reason the bug is there? Surely the Apple code base is not that simple.
- beamatronic 6y agoI’m thankful for all the smart, diligent people working hard to keep us all safe.
- tyrion 6y agoHow is this something that can happen? I mean, the only responsibility of an "authentication" endpoint is to release a JWT authenticating the current user. At least from the writeup, the bug seems so simple that it is unbelievable that it could have passes a code review and testing. I suspect things were maybe not as simple as explained here, otherwise this is at the same incompetence level as storing passwords in plaintext :O.
- enitihas 6y agoApple has had more simple "unbelievable" bugs, e.g https://news.ycombinator.com/item?id=15800676 https://news.ycombinator.com/item?id=15800676 (Anyone can login as root without any technical effort required) And to top it off (https://news.ycombinator.com/item?id=15828767 https://news.ycombinator.com/item?id=15828767) Apple keeps having all sorts of very simple "unbelievable" bugs.
- saagarjha 6y agoMore recent example of Apple "undoing" patches: https://www.synacktiv.com/posts/exploit/return-of-the-ios-sandbox-escape-lightspeeds-back-in-the-race.html https://www.synacktiv.com/posts/exploit/return-of-the-ios-sa...
- fishywang 6y agoLast year (or maybe 2018?) my employer hired an external consultant to give engineers security trainings (all are optional, they provide a few sessions on different topics, and engineers can sign up for interested ones). In one of the sessions I signed up, during the pre-session chat (while waiting for everyone signed up show up in the conference room), the external trainer "casually" chatted about "if you have an Android phone, you should throw it out of the window right now and buy an iPhone instead". That's the point I lost all my respect to them. (The session itself was ok-ish. It was some trainings about xsrf, nothing special either) (That incident also triggered me to purchase a sheet of [citation needed] stickers from xkcd to put on my laptop, so the next time this kind of thing happens I can just point to the sticker on my laptop. But I didn't got a chance to do that yet since received the stickers)
- outime 6y agoWow, I'm in shock. How could Apple let this one slip in? When I was a junior fullstack I had to design a very similar system and this was one of the very basic checks that I had in mind back then. I don't know how could anyone excuse this very basic bug in such critical service.
- enitihas 6y agoApple has let all sorts of things slip in which seem unbelievable. e.g https://news.ycombinator.com/item?id=15800676 https://news.ycombinator.com/item?id=15800676 and https://news.ycombinator.com/item?id=15828767 https://news.ycombinator.com/item?id=15828767 So I don't get shocked anymore seeing Apple security issues.
- nick-garfield 6y agoAm I understanding the article right: the endpoint would accept any email address and generate a valid JWT without verifying the caller owned the email address? If so, what extra validation did Apple add to patch the bug?
- mormegil 6y agoWith all those high-profile third parties using Apple ID, what would happen if somebody stole/deleted/damaged my data/assets on Dropbox/Spotify/Airbnb/...? Would I sue the provider who would sue Apple? But does Apple provide any guarantees to the relying parties? And if not and the only way is to depend on the reputation when choosing the ID providers you want to support, how would anyone want to support Apple ID after this? And could they not use it if Apple forces them to...?
- foobarbazetc 6y agoThe ToS of every service has a liability waiver.
- Dahoon 6y agoWhich doesn't hold in court in most of the civilized world.
- ksec 6y agoI am hoping WWDC 2020 will have some great news and events that let us forget all the mistake they made in Catalina and incidents like this. I am not sure if I am understanding the blog post correctly, because its simplicity is beyond ridiculous.
- jasoneckert 6y agoSince this was an extremely simple exploit, I can't help but wonder if it was a purposeful one on Apple's part. Apple has been spending a lot of money on a security-focused marketing campaign these past few years, and encouraging a high-price payout of $100k is sage marketing.
- will_raw 6y agoSome people commenting this to be overpriced, but I don't think so even if they are considering the INR value. The bug is quite critical considering how large the mac and iOS ecosystem is.
- Stierlitz 6y ago“I found I could request JWTs for any Email ID from Apple and when the signature of these tokens was verified using Apple’s public key, they showed as valid.” What are they teaching them in computer school these days. How can you write a security function and not test it for these kind of bugs. Unless all there accidental backdoors have a more nefarious purpose <shoosh>
- cmauniada 6y agoEasiest $100k ever made?
- YetAnotherNick 6y agoAnd the 'Won $100000 from apple's bug bounty program' in CV is enough to raise the salary by $100000
- cmauniada 6y agoI would wear that distinction with pride! Kudos to him.
- zucker42 6y agoIsn't this not a "zero-day"? Zero-day refers to when the company has no notice of an exploit.
- tly_alex 6y agoThe write-up is not very clear in my opinion. The graph seems to show that there're 3 API calls (maybe there're more API calls in reality?). And if I understand this correctly, the issue is in the first API call, where the server does not validate whether the requester owns the Email address in the request. What confuses me are where're the "decoded JWT’s payload" comes from. Is it coming from a different API call or it's somewhere in the response?
- tly_alex 6y agoAnd the choice of black arrow on top of an almost black background... I am not a designer but that's just killing my eyes here.
- spartak 6y agowhere is the ptacek rant about JWT?!
- mazeltovvv 6y agoThis is an amazing bug, I am indeed surprised this happened in such a critical protocol. My guess is that nobody must have clearly specified the protocol, and anyone would have been able to catch that in an abstracted english spec. If this is not the issue, then the implementation might be too complex for people to compare it with the spec (gap between the theory and the practice). I would be extremely interested in a post mortem from Apple. I have a few follow up questions. 1. seeing how simple the first JWT request is, how can Apple actually authenticate the user at this point? 2. If Apple does not authenticate the user for the first request, how can they check that this bug wasn’t exploited? 3. Anybody can explain what this payload is? { "iss": "https://appleid.apple.com" https://appleid.apple.com", "aud": "com.XXXX.weblogin", "exp": 158XXXXXXX, "iat": 158XXXXXXX, "sub": "XXXX.XXXXX.XXXX", "c_hash": "FJXwx9EHQqXXXXXXXX", "email": "contact@bhavukjain.com", // or "XXXXX@privaterelay.appleid.com" "email_verified": "true", "auth_time": 158XXXXXXX, "nonce_supported": true } My guess is that c_hash is the hash of the whole payload and it is kept server side.
- arcdigital 6y agoFor #3 it's part of the JWT ID Token. Take a look at https://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken https://openid.net/specs/openid-connect-core-1_0.html#Hybrid...
- guessmyname 6y agoAll your questions can be answered by reading “Sign in with Apple REST API” [1][2]: 1. User clicks or touches the “Sign in with Apple” button 2. App or website redirects the user to Apple’s authentication service with some information in the URL including the application ID (aka. OAuth Client ID), Redirect URL, scopes (aka. permissions) and an optional state parameter 3. User types their username and password and if correct Apple redirects them back to the “Redirect URL” with an identity token, authorization code, and user identifier to your app 4. The identity token is a JSON Web Token (JWT) and contains the following claims: • iss: The issuer-registered claim key, which has the value https://appleid.apple.com https://appleid.apple.com. • sub: The unique identifier for the user. • aud: Your client_id in your Apple Developer account. • exp: The expiry time for the token. This value is typically set to five minutes. • iat: The time the token was issued. • nonce: A String value used to associate a client session and an ID token. This value is used to mitigate replay attacks and is present only if passed during the authorization request. • nonce_supported: A Boolean value that indicates whether the transaction is on a nonce-supported platform. If you sent a nonce in the authorization request but do not see the nonce claim in the ID token, check this claim to determine how to proceed. If this claim returns true you should treat nonce as mandatory and fail the transaction; otherwise, you can proceed treating the nonce as optional. • email: The user's email address. • email_verified: A Boolean value that indicates whether the service has verified the email. The value of this claim is always true because the servers only return verified email addresses. • c_hash: Required when using the Hybrid Flow. Code hash value is the base64url encoding of the left-most half of the hash of the octets of the ASCII representation of the code value, where the hash algorithm used is the hash algorithm used in the alg Header Parameter of the ID Token's JOSE Header. For instance, if the alg is HS512, hash the code value with SHA-512, then take the left-most 256 bits and base64url encode them. The c_hash value is a case sensitive string [1] https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api https://developer.apple.com/documentation/sign_in_with_apple... [2] https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple https://developer.apple.com/documentation/sign_in_with_apple...
- danans 6y agoThis is why it's good to run fuzzers against any public API (especially an auth API), to verify its behavior on novel inputs. https://en.m.wikipedia.org/wiki/Fuzzing https://en.m.wikipedia.org/wiki/Fuzzing
- capableweb 6y agoIn general I agree with you that it's good to run fuzzers against any endpoints, public or internal (as you never know if someone can wrangle data to go from public -> internal somehow), but in this particular case, you'd only find a issue if the fuzzer somehow randomly used the ID of another user that was already created, and verified that it couldn't access it. In that case, you'd catch it way before even implementing the fuzzer. So in this case, I don't think a fuzzer would have helped. Some E2E tests written by humans should have caught this though.
- danans 6y agoThere's no reason that a fuzzer couldn't draw sample email addresses from a large pool of test valid email addresses to add as input. That would just require a fuzzer that allowed you to provide the sample population for a particular data type.
- capableweb 6y agoMy point still stands. If the one setting up the fuzzer is thinking about the condition that A) you're using a valid email that B) already existing in the system and C) cannot be used to authenticate with another system, you can easily check the code for this directly. The fuzzer won't add anything over a simple integration/E2E test here.
- danans 6y agoFair point! The question I have then is whether it's possible to create a tool that automatically detects bugs like this without needing to write an integration test for this specific cases.
- planetjones 6y agoAbsolutely astonishing. The internal controls at Apple seem to be borderline non existent.
- tpmx 6y agoThe average IQ and experience of their software developers has dropped remarkably over the past decade, as they have expanded. I've had multiple occasions of "Seriously, Apple hired person X? lol" over the past five years or so.
- alfalfasprout 6y agofrankly that's true of any silicon valley giant at this point.
- playpause 6y agoIf the bug is as simple as everyone is saying, why hasn’t it been discovered until now?
- playpause 6y agoTo the downvoters, this was an honest question from someone who wants to understand the situation better.
- Ronnie76er 6y agoJust want to mention something about the id_token provided. I'm on my phone, so I don't have apples implementation handy, but in OIDC, the relying party (Spotify for example) is supposed to use the id_token to verify the user that is authenticated, specifically the sub claim in the jwt id_token. https://openid.net/specs/openid-connect-core-1_0-final.html#StandardClaims https://openid.net/specs/openid-connect-core-1_0-final.html#... It's likely (although like others have noted, this is scant on details), that this value was correct and represented the authenticated user. A relying party should not use the email value to authenticate the user. Not contesting that this is a bug that should be fixed and a potential security issue, but perhaps not as bad. Anyone else? Am I reading this right?
- homakov 6y agotrue, email shouldnt be used when you can identify by unique id. I doubt the bug was even exploitable with most apps. Apple just paid magnitudes more than its severity.
- deleted 6y ago[deleted]
- cfors 6y agoSo the way I believe that it works is that the vulnerability was that a valid email is used to generate an Apple signed JWT. The server side validation would be unable to tell that the token wasn’t issued in behalf of the user since Apple actually signed it.
- dwaite 6y agothe SiwA identification is based on "sub", email address is an important address but you aren't supposed to link accounts based on it since the user can change the email address or revoke email proxy at any time.
- m_herrlich 6y agoThe apple endpoint returned an apple-signed jwt with an email of the attacker's choice in the sub field. It didn't even have to be an email associated with an apple id. Relying parties verify the id_token against Apple's cert and that is Apple's guarantee that the email is correct.
- dandigangi 6y agoI always have a minute of nervousness while I read these security posts hoping that the bottom will say it's already been fixed with XYZ security team. Glad it's fixed w/ Apple already. The "they still haven't fixed it" or "still haven't responded" ones are scary.
- alexashka 6y agoWhat level of incompetence will it take for the government to step in and create some laws surrounding companies exposing user's private data because 'oops, we don't want to pay security experts what they're actually worth, even though we have billons sitting in bank accounts doing nothing'.
- hank_z 6y agoWow, this bug is incredibly simple but severe. I’m wondering how did Bhavuk Jain find it
- alfalfasprout 6y agohonestly I'm not surprised people didn't run into it during testing... you make a test email account and get a signin token for it. And then realize wait... how does apple know I own that email??
- afrcnc 6y agoReplace "zero-day" with "privately reported security bug for which I got $100k" That's not how zero-day works
- saagarjha 6y agoIt was a zero day up until the first report was made.
- jedberg 6y agoThat's always true though. 0-day implies it was discovered being actively exploited or that it was released on the 0th day it was discovered.
- saagarjha 6y agoI believe “0 day” actually refers to the number of days that the vendor has had to fix the issue, not how many days it’s been since it’s discovered. For example, there might be a substantial delay between bug discovery and actual disclosure to the vendor–I usually take a couple days to write up a nice explanation and PoC. If I had found something and then published it publicly the next day without disclosing it, it’d still be a zero day.
- jedberg 6y agoYou're right I should have said 0 days since it was disclosed to the vendor. That would be more accurate. Regardless, this bug is definitely not 0 day given that it was disclosed to the vendor last month.
- afrcnc 6y agoIt doesn't matter what you "believe" That's not what that word means. Zero-day refers to actively exploited bugs. Stop hijacking words just to overhype your research.
- 6y ago
- earth2mars 6y ago"A lot of developers have integrated Sign in with Apple since it is mandatory for applications that support other social logins" -- How pathetic Apple is to force their own service on developers!!
- wmichelin 6y agoWhy are you surprised? They force you to use the App Store. They force you to process payments through their systems. They force you to comply with many things. How is this any different?
- PunksATawnyFill 6y agoWTF is a "zero-day?"
- deleted 6y ago[deleted]
- XCSme 6y ago(Unrelated to the Apple bug) Is there any bug bounty program for small businesses/apps? I only found hackerone but it seems to be only for enterprise. Is there any recommended platform for small businesses to create their own public bounty program?
- jedberg 6y agoWhat a click-bait title. 0-day implies it was found already being exploited in the wild. The author even says that Apple found no evidence of it being exploited. By definition when this blog post was published it was not the 0th day.
- ljm 6y ago> For this vulnerability, I was paid $100,000 by Apple under their Apple Security Bounty program. Fucking hell. Even after tax, that's a substantial pay-out.
- totalZero 6y agoThat was my first thought too. No wonder he's a full-time bug bounty hunter.
- kag0 6y agoTo me this seems like a poor protocol design that created an opportunity for an implementation error, and that opportunity was seized. In the initial authorization request rather than passing a string with an email address, the caller could pass a boolean `usePrivateRelay`. If true generate a custom address for the third party, if false use the email address on file. With that one change the implementer no longer has the opportunity to forget to validate the provided email address, and the vuln is impossible.
- m_herrlich 6y agoYou misunderstand the bug, the exploit allows an attacker to generate an apple-signed JWT with an email address of the attacker's choice.
- catlifeonmars 6y agoIt’s unclear to me exactly where the vulnerability is given the authors description in “technical details”. Does this occur in the implicit flow as well as the code flow? Is the token request unauthenticated? This seems highly unlikely. Or does Sign In With Apple deviate from the Open ID specification in a way that I’m unfamiliar with?
- gouggoug 6y agoThe author found out that the HTTP endpoint used to generate a JWT token would accept any email and respond with a valid JWT token for that email address. He could literally send a POST request to that endpoint with arbitrary email addresses and get a valid JWT. This is clearly explained under the "BUG" section.
- catlifeonmars 6y agoThat part I understand. It’s unclear to me in which auth endpoint(s) and auth flow(s) are affected. Is it the token endpoint, or auth endpoint? Or is it somewhere in the login flow before the user agent is redirected to the token endpoint?
- zelphirkalt 6y agoAgain something with sign in / log in in Apple products? Didn't we have the ridiculous empty password thingy a while back already? Who is implementing that stuff?
- a4wtaw4tawtawt 6y agobwut my appwel dewvice is PEREFECT
- blacklight 6y agoWhy haven't they just implemented OAuth 2.0, like everyone else has done? They've tried to reinvent the wheel with their own implementation of a three-legged user authentication that doesn't add anything to what OAuth does and, surprise, they've exposed themselves to a critical vulnerability that could have been completely avoided.
- summerlight 6y agoAfter observing its endless flow of security and reliability bugs, I begin to think that the recent decline of Apple's overall software quality over the several years is probably a more of systematic problem. https://www.bloomberg.com/news/articles/2019-11-21/apple-ios-14-features-changes-testing-after-ios-13-bugs https://www.bloomberg.com/news/articles/2019-11-21/apple-ios... Looks like Federighi agrees with this diagnosis and tries to improve the overall development process but not sure if it can be really improved without changing the famous secretive corporate culture. At the level of Apple's software complexity, you cannot really design and write a quality software without involving many experts' eyes. And I have been complained by my friends at Apple about how hard to get high level contexts of their works and do a cross-team collaboration. And IMO, this systematic degradation of the software quality coincides with Bertrand's leaving, who had allowed relatively open culture at least within Apple's software division. I'm not an insider, so this is just a pure guess though.
- NightlyDev 6y ago"At the level of Apple's software complexity" This defenitly wasn't complex in any shape or form. This was very basic.
- teknopaul 6y agoI find it crazy that Apple can force devs to support apple id if they support a competing service. The US has gone soft on Monopoly abuse. People have got so used to it they dont notice. Gaping holes in security is only one of the consequences.
- NightlyDev 6y agoI'm still dreaming about a world where OpenID is the norm. Just think if Apple forced all apps to use that instead, that would be a great move for privacy and security. But no. Instead they make more proprietary shit without having the basic skills to do so. Then they force that shit on their users.
- geekit 6y agoThere are few other issues with how websites implemented it. For example, at work, appleid or few apple domains are banned (they wanted to ban iTunes streaming etc.) when I tried to login into Pocket (Read It Later) [Web Version], due to this blocking, the whole login form get hidden once page load complete, and I cannot even login with my username and password.