4 ms·

Jesus, that prebaked password on the Jive platform was really bad. Especially as one could ultimately access nearly the entirety of Apple's internal network fro

Jesus, that prebaked password on the Jive platform was really bad. Especially as one could ultimately access nearly the entirety of Apple's internal network from that. Makes me wonder, if these guys could do it, how many Chinese industrial espionage units have?

blakesterz 6y ago
> Makes me wonder, if these guys could do it, how many Chinese industrial espionage units have? And Russia, and Iran, and so on... It seems safe to assume someone else out there found at least one of these and got in to the Apple internal network and has been quietly doing their job, whatever it may be.
- possiblelion 6y ago
  "Our proof of concept for this report was demonstrating we could read and access Apple’s internal maven repository which contained the source code for what appeared to be hundreds of different applications, iOS, and macOS." This itself is massive. How many 0-days could emerge from something like that?!
  - yokaze 6y ago
    Great, hard-shell/soft-centre. If anyone asks, why you should go to all the effort to secure the software in your internal-network, that's why.
    - jeffbee 6y ago
      If you are unable to secure your perimeter, what would lead you to believe that you had better security of your interior?
      - smichel17 6y ago
        Less surface area?
      - yokaze 6y ago
        The point is, at a certain scale you _are_ unable to secure your perimeter. Are you surprised that a handful of likely thousands external facing application can be hacked? Especially, if most of your colleagues never have to bother with security, because they think, they are safe behind the perimeter, how can you expect a secure perimeter? With so many applications, there is bound to be one to have a hole. The argument is more on the meta-level. Most of the shown ones are implementation issues. Hundreds of people have their hands in here. But being able to gain more privileges because you have managed to compromise a service, that is one of design. And here, only few should have a say in. Expect failure, limit the impact.
        jeffbee 6y ago
        That's certainly one view of things. The other view is taken by the beyondcorp/zero-trust model. But the lesson I take from this article (and my own experience) is that if you allow commercial off-the-shelf and open-source software into your network the end result will always be an insecure mess. If you absolutely must adopt off-the-shelf software the only safe way to do it is to put a proxy in front of it that's completely integrated with your authn/authz systems such that the native protocol of the third-party system is completely hidden and inaccessible. The Google model is frequently derided on HN as "not invented here" but at least you can say that they aren't getting rooted via some kind of toxic waste like Jive forums.
        saagarjha 6y ago
        If I understand correctly, Google’s model is to basically roll their own authentication frontend to any service they run. Now, this is likely better than what some off-the-shelf open source library might be using (which might actually have been fine if you had configured it correctly) and I have nothing against running further authentication before giving access to your things, but calling this the “only safe way” to do something is not really true at all. There’s a number of companies that run without this model that do fairly well, and Google endpoints are occasionally are hit by researchers. So it’s good on Google that they have a policy up for this and it mostly seems to work for them, but it’s not the only solution like you’re suggesting.
    - dyingkneepad 6y ago
      I work on a giant famous multi-billion dollar company where all the internal stuff is full of permission requirements, training requirements, etc. It is absolutely HORRIBLE to be productive here. Every single kind of information you need to be able to work is hidden behind someone's wall. I often lose entire weeks of productivity just trying to find who owns a certain information or knows which permission I need to request in order to read a link. There was a time I literally had to wait a whole month before the person was on vacation and their manager didn't know how to authorize me into the system. All I needed was a binary file they provided. Even worse: every team thinks the thing they do is absolutely the most important thing in the world so they hide it even more. They create empires around the information they control and explicitly force you out of it. So instead of just reading their freaking source code or documentation you have to get permission to open a ticket in their system, then you open it, then one person will triage your ticket, another will forward it, another will create an internal Jira about them, a PM will prioritize it, then a dev will gather the information and pass to the Senior Information Proxy employee who will instruct the intern to finally reply it in your ticket. And of course your original message was misunderstood so the thing they gave you is useless. All you needed was access to the damn thing, but they built an empire around it and now you have to fight a war of improductivity.
      - sulam 6y ago
        It's funny, because the received wisdom in the industry is that Apple behaves exactly this way. I guess not in their production environment!
      - philsnow 6y ago
        To add insult to injury, your account of the state of things gives me no reason to think that their internal systems aren't rife with similar vulnerabilities, so rather like DRM only making life hard for paying customers, I suspect that these measures only make access difficult for honest employees.
- ISL 6y ago
  And sends a request to an external C&C server... once a year-ish, just in case the ingress route is closed.
- vsareto 6y ago
  Any of those countries could just get someone hired at Apple for that
  - arkitaip 6y ago
    Why not both so as to protect your assets.
- maxbaines 6y ago
  And the US and the UK and the EU...
ArtWomb 6y ago
I had the same thought. Really basic front end web vulnerabilities right in HTML response. One can only speculate on the state of Apple's web hosts' ip filtering, rate limiting, ddos protection, etc.
intricatedetail 6y ago
I wonder how many agents they pissed by blocking their access through exposing the holes...
crossroadsguy 6y ago
As an iPhone user (and Mac for work), of late I've often wondered whether Apple is really just all about the pretty looking things and overhyped launches and marketing campaigns, giving specific (usually trademarked) names to features that have been common place on other platforms for years. And a large portion of their user-base also being their staunch fans. Do they just glue things together under the hood this way and that?
- Aeolun 6y ago
  > Do they just glue things together In my experience all enterprises I have experience with do this. There’s just something about the whole process that makes everyone worry about security later.

blakesterz 6y ago

> Makes me wonder, if these guys could do it, how many Chinese industrial espionage units have? And Russia, and Iran, and so on... It seems safe to assume someone else out there found at least one of these and got in to the Apple internal network and has been quietly doing their job, whatever it may be.

possiblelion 6y ago
"Our proof of concept for this report was demonstrating we could read and access Apple’s internal maven repository which contained the source code for what appeared to be hundreds of different applications, iOS, and macOS." This itself is massive. How many 0-days could emerge from something like that?!
- yokaze 6y ago
  Great, hard-shell/soft-centre. If anyone asks, why you should go to all the effort to secure the software in your internal-network, that's why.
  - jeffbee 6y ago
    If you are unable to secure your perimeter, what would lead you to believe that you had better security of your interior?
    - smichel17 6y ago
      Less surface area?
    - yokaze 6y ago
      The point is, at a certain scale you _are_ unable to secure your perimeter. Are you surprised that a handful of likely thousands external facing application can be hacked? Especially, if most of your colleagues never have to bother with security, because they think, they are safe behind the perimeter, how can you expect a secure perimeter? With so many applications, there is bound to be one to have a hole. The argument is more on the meta-level. Most of the shown ones are implementation issues. Hundreds of people have their hands in here. But being able to gain more privileges because you have managed to compromise a service, that is one of design. And here, only few should have a say in. Expect failure, limit the impact.
      - jeffbee 6y ago
        That's certainly one view of things. The other view is taken by the beyondcorp/zero-trust model. But the lesson I take from this article (and my own experience) is that if you allow commercial off-the-shelf and open-source software into your network the end result will always be an insecure mess. If you absolutely must adopt off-the-shelf software the only safe way to do it is to put a proxy in front of it that's completely integrated with your authn/authz systems such that the native protocol of the third-party system is completely hidden and inaccessible. The Google model is frequently derided on HN as "not invented here" but at least you can say that they aren't getting rooted via some kind of toxic waste like Jive forums.
        saagarjha 6y ago
        If I understand correctly, Google’s model is to basically roll their own authentication frontend to any service they run. Now, this is likely better than what some off-the-shelf open source library might be using (which might actually have been fine if you had configured it correctly) and I have nothing against running further authentication before giving access to your things, but calling this the “only safe way” to do something is not really true at all. There’s a number of companies that run without this model that do fairly well, and Google endpoints are occasionally are hit by researchers. So it’s good on Google that they have a policy up for this and it mostly seems to work for them, but it’s not the only solution like you’re suggesting.
  - dyingkneepad 6y ago
    I work on a giant famous multi-billion dollar company where all the internal stuff is full of permission requirements, training requirements, etc. It is absolutely HORRIBLE to be productive here. Every single kind of information you need to be able to work is hidden behind someone's wall. I often lose entire weeks of productivity just trying to find who owns a certain information or knows which permission I need to request in order to read a link. There was a time I literally had to wait a whole month before the person was on vacation and their manager didn't know how to authorize me into the system. All I needed was a binary file they provided. Even worse: every team thinks the thing they do is absolutely the most important thing in the world so they hide it even more. They create empires around the information they control and explicitly force you out of it. So instead of just reading their freaking source code or documentation you have to get permission to open a ticket in their system, then you open it, then one person will triage your ticket, another will forward it, another will create an internal Jira about them, a PM will prioritize it, then a dev will gather the information and pass to the Senior Information Proxy employee who will instruct the intern to finally reply it in your ticket. And of course your original message was misunderstood so the thing they gave you is useless. All you needed was access to the damn thing, but they built an empire around it and now you have to fight a war of improductivity.
    - sulam 6y ago
      It's funny, because the received wisdom in the industry is that Apple behaves exactly this way. I guess not in their production environment!
    - philsnow 6y ago
      To add insult to injury, your account of the state of things gives me no reason to think that their internal systems aren't rife with similar vulnerabilities, so rather like DRM only making life hard for paying customers, I suspect that these measures only make access difficult for honest employees.
ISL 6y ago
And sends a request to an external C&C server... once a year-ish, just in case the ingress route is closed.
vsareto 6y ago
Any of those countries could just get someone hired at Apple for that
- arkitaip 6y ago
  Why not both so as to protect your assets.
maxbaines 6y ago
And the US and the UK and the EU...

ArtWomb 6y ago

I had the same thought. Really basic front end web vulnerabilities right in HTML response. One can only speculate on the state of Apple's web hosts' ip filtering, rate limiting, ddos protection, etc.

intricatedetail 6y ago

I wonder how many agents they pissed by blocking their access through exposing the holes...

crossroadsguy 6y ago

As an iPhone user (and Mac for work), of late I've often wondered whether Apple is really just all about the pretty looking things and overhyped launches and marketing campaigns, giving specific (usually trademarked) names to features that have been common place on other platforms for years. And a large portion of their user-base also being their staunch fans. Do they just glue things together under the hood this way and that?

Aeolun 6y ago
> Do they just glue things together In my experience all enterprises I have experience with do this. There’s just something about the whole process that makes everyone worry about security later.