Hacker News Reader

Comment by walterbell | Hacker News Reader

Usually a generic cloud provider, not unique, identifying or stable.

So how did you identify this as a breach? I'm struggling to find this credible, and you've yet to provide specifics.

Right now it comes across as "just enough knowledge to be dangerous"-levels, meaning: you've seen things, don't understand those things, and draw an unfounded conclusion.

Feel free to provide specifics, like log entry lines, that show this breach.

Please feel free to ignore this sub-thread. I'm merely happy that Apple finally shipped an iPad that would last (for me! no claims about anyone else!) more than a few weeks without falling over.

To learn iOS forensics, try Corellium iPhone emulated VMs that are available to security researchers, the open-source QEMU emulation of iPhone 11 [1] where iOS behavior can be observed directly, paid training [2] on iOS forensics, or enter keywords from that course outline into web search/LLM for a crash course.

[1] https://news.ycombinator.com/item?id=44258670

[2] https://ringzer0.training/countermeasure25-apple-ios-forensi...

I worked at Corellium tracking sophisticated threats. Nothing you’ve posted is indicative of a compromise. If you’re convinced I’d be happy to go through your IOCs and try to explain them to you.

Thanks. In this thread, I was trying to share a positive story about the recent iPad Pro _NOT_ exhibiting the many issues I observed over 5 years and multiple generations of iPhones and iPad Pros. If any new issues surface, I'll archive immutable logs for others to review.

I think this just further highlights my credibility point.

With the link I provided, a hacker can use iOS emulated in QEMU for:

  • Restore / Boot
  • Software rendering
  • Kernel and userspace debugging
  • Pairing with the host
  • Serial / SSH access
  • Multitouch
  • Network
  • Install and run any arbitrary IPA

Unlike a locked-down physical Apple device. It's a good starting point.

I'm much more convinced that you're competent in the field of forensics. But I still don't think suspicious network traffic can be categorically defined as a 'device breach.'

For all you know, the traffic you've observed and deem malicious could just as well have been destined for Apple servers.

Apple traffic goes to 17.0.0.0/8 + CDNs aliased to .apple.com, which my egress router blocks except for Apple-documented endpoints for notifications and software update, https://support.apple.com/en-us/101555

appldnld.apple.com configuration.apple.com gdmf.apple.com gg.apple.com gs.apple.com ig.apple.com mesu.apple.com mesu.apple.com ns.itunes.apple.com oscdn.apple.com osrecovery.apple.com skl.apple.com swcdn.apple.com swdist.apple.com swdownload.apple.com swscan.apple.com updates.cdn-apple.com updates-http.cdn-apple.com xp.apple.com

There was no overlap between unexpected traffic and Apple CDN vendors.

'Apple-documented' being operative here.

True, perhaps OVH in Germany (one anomaly example) is an Apple vendor. No way to know.

They said upthread that they had blocked 17.0.0.0/8 ("Apple"), but maybe there are teams inside Apple that are somehow operating services outside of Apple's /8 in the name of Velocity? I kind of doubt it, though, because they don't seem like the kind of company that would allow for that kind of cowboying.

I don't doubt it in the slightest. Every corporate surveillance firm—I mean, third-party CDN in existence ostensibly operates in the name of 'velocity'.

Apple has used AWS and Cloudflare in the past, too, so it’s not like seeing that traffic is a reliable indicator of compromise.

Reply on news.ycombinator.com