How to catch a wild triangle | Hacker News Reader

How to catch a wild triangle

securelist.com

142 pointsmmastrac43 comments

Ooh, I really enjoyed this devlog.

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.

[1] https://eugene.kaspersky.com/2011/11/02/the-man-who-found-st...

[2] https://www.washingtonpost.com/world/national-security/israe...

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.

Persistence on iOS is really, really hard.

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.

It wasn't clear to me from reading the blogpost that persistence _wasn't_ achieved?

They mentioned that the suspicious traffic stopped after a restart.

I'm not seeing that mentioned in this blogpost, was it mentioned in one of the other ones?

https://securelist.com/operation-triangulation/109842/

They talk about it here, under "what we know so far"

FTA: "Once the device rebooted, all the suspicious activity stopped."

This is not the first time the NSA infiltrated Kaspersky. Avoiding persistence was one of the desired requirements of the attack.

> but my money's on the NSA

Why is your money on the NSA?

because it is the only boogeyman he knows how to blame with no evidence

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.

Use of mitmproxy is very fragile. Cert Pinning is increasing common.

> 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.

Computer security person here! I have yet to be assassinated :)

Well… you would think that, wouldn’t you?

If I stop posting to Hacker News please contact my family.

You may just be a gpt bot impersonating yourself. We can never be sure.

I'd be glad to be dead at that point

Survivorship bias

And that was the last time anybody ever heard from the real saagarjha.

Depends on what sort of security you work, but companies who work for state or military related security might be easy targets.

Security means money and can mean violence.

There are computer security people who work for intel agencies, those are the people I am talking about.

Even people who work for securing data of companies, those people might also be targets.

I don't know. It sounds like you liked the article.

I've always felt that security/exploit devs are just different.

This kind of constant striving and failing until finally succeeding would be such an incredibly frustrating experience for me.

Kudos to them though, it's serious perseverance.

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.

It's a mindset/perspective difference.

Fascinating reading.

Would love to see a subsequent post in this series about attribution. Are there any code or other TTP similarities to APTs from known actors?

What did the watchface exploit actually do?

Presumably send all device data, use the sensors to spy on the phone's surroundings, and be ready for further instructions.

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.

Then you have other problems.

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"

It would have allowed them to intercept those bogus malware domains though.

It did.

Without having to redo their setup when their network was not intercepting connections by default, which it could have been doing.

(This is sarcasm, right?)

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.

The risk of getting your MitM box compromised is too high IMO

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 .....)

Reply on news.ycombinator.com