I'd have liked to see where they pointed the finger in terms of who they think sent these off, but in case you're too lazy to read: a .watchface file sent over iMessage was used to hoist up enough power to delete all records of the iMessage and open two-way encrypted communications with a local binary.
Figuring that out led to (I think?) four zero-day reports to Apple, and a substantial homegrown MITM proxy poisoner designed specifcally to compromise the encryption used to protect the exploit server's comms channel with the devices.
Just because you're paranoid doesn't mean they aren't out to get you if you're Kaspersky, I guess.
Really wish everyone would stop using iMessage forever and Appl would just drop it. It really is garbage and its so clearly multitasking in its true actual purpose that its starting to get ridiculous. I nominally feel the same about forcing WebKit and various other similar internal standards that constantly result in zero-days and that also happen to be enforced as defaults upon sign in
>Despite many ups and downs, we eventually managed to obtain all the stages used in this attack, including four zero-day exploits reported to Apple, two validators, an implant and its modules.
Looks like NSA still hasn't forgiven Kaspersky for exposing STUXNET [1]. It seems that this latest attack on Kaspersky was expensive. Losing 4 zerodays must have been painful. It's also possible that Israel and Unit 8200 [2] was behind this but my money's on the NSA.
no way in hell the NSA forcibly tries to reinfect targets over and over, that's not their modus operandi. Instead they would have spend money to find a persistence on the infected device.
The fact that the attacker has almost a full-chain but no persistence screams to me "second fiddle", probably a nation state that have access to 0-days brokers but no in-house engineering.
I agree with you on that, but the USA (and probably China) is the nation state least likely to skimp on iOS persistence when targeting Russian AV analysts :D
I can only guess at motivations but I would think that when targeting security researchers you’d aim to not have persistence since that would make require leaving evidence of infection on the device.
I wasn't expecting this. I was expecting just a simple post about some errant process or something. What I ended up reading was a digital version of a sherlock holmes novel. Complete with the mouse trap. The use of mitmproxy to intercept and unpack https requests like a russian doll is the most russian solution, and it worked like a charm. Thanks for including the juicy bits that make these discoveries actually worth reading. Also scary that once hoisted, the binary is just transmitting all your data to them.
> Unfortunately, this method did not allow us to intercept HTTPS traffic of Apple services (including iMessage), as iOS implements SSL pinning for this. Thus, we were not able to decrypt iMessage traffic that came through the VPN.
When security helps attackers... that's a bit ironic.
Anyway, this article is exactly why I don't want to work in computer security, you constantly have to look behind you, and government A/government B/black hats etc will always try funny things, because they belong to side A or B or whatever, and I bet a lot of security people got either threatened or even had targets on their backs or just assassinated.
I don't really know if some of them got assassinated, because that might not make the news, but that's not a really a domain I would like to work in.
I guess it attracts people who like competition, but I don't really see the value of working in security, for the same reason I don't see the point of joining an army to learn how to fight.
It's not failing. I know that's a trope (1000 filaments that don't work)...but it really is the difference in you and them. Their mindset is not that they have failed, at any point. They are poking and probing and analyzing and incrementally finding things out. At no point were they failing. They probably didn't consider that they could fail.
In terms of prevention strategies, it seems that given that the initial vector was a malicious iMessage attachment, Lockdown Mode would have prevented this attack? (As it disables iMessage attachments).
> Unfortunately for us, all the communications with the servers in question happened over HTTPS, so we could not recover any additional details from the traffic.
This is why your corporate network should MitM all TLS connections by default.
A bit further down in the same article:
"Unfortunately, this method did not allow us to intercept HTTPS traffic of Apple services (including iMessage), as iOS implements SSL pinning for this"
Only partially. As an employee I would resign from a company that insisted on MitM'ing my connections. But from the position of the article, it clearly would have been valuable to have request captures from the start rather than having to try to reproduce the malware a second time.
Is this risk analysis real? I don't believe in companies that think this is a risk at all if their box is implemented properly. If it's even possible to compromise then you have bigger problems (like your intranet not being properly secured, or the MitM setup not being sandboxed properly, or .....)
I'd have liked to see where they pointed the finger in terms of who they think sent these off, but in case you're too lazy to read: a .watchface file sent over iMessage was used to hoist up enough power to delete all records of the iMessage and open two-way encrypted communications with a local binary.
Figuring that out led to (I think?) four zero-day reports to Apple, and a substantial homegrown MITM proxy poisoner designed specifcally to compromise the encryption used to protect the exploit server's comms channel with the devices.
Just because you're paranoid doesn't mean they aren't out to get you if you're Kaspersky, I guess.