There are three things you don't want to see made– laws, sausages, and threat intelligence.
Frankly, I'm bummed out at the framing of this issue. It adds fuel to the air-quote 'privacy' debate that keeps eating away at our ability to do security research, as in the case of GDPR.
I've played with Augury before. Netflow can be useful. But for the most part it's spotty, incomplete, and inconclusive. You don't turn into a SIGINT agency because you have visibility into a few hops along a path for a sliver of time. Internet routing doesn't work that way.
You're seeing points connecting to other points at a given time. If the connection is routed a different way, if it takes a hop you don't have access to, if any number of factors changes the connective tissue of the internet, you don't see anything.
While I personally don't care much for netflow (net isn't my specialty), I'm dismayed to see it framed as a burning privacy violation. It reminds me of the nonsense surrounding Whois data that landed us with this overblown GDPR fiasco- the 'thoughts and prayers' of privacy.
The internet isn't a monolithic entity. It's made up of many discreet points connecting many different resources hosted by tons of organizations you know nothing about. A VPN is a choice of where to route some of that along the way (that entails *A LOT* of trust in one org)
I'm not telling you that there's no such thing is a privacy. I'm telling you that realistic privacy on the internet has to take into account the fabric of that medium and the intent of its use. It entails trust in any number of orgs. And along the way it involves bad faith actors
In the absence of effective options to strike at bad faith actors, we are instead focusing regulations, legislations, and public outcry on clawing back the very aperture that allows us to identify, track, and impose costs on those bad faith actors and that's worth reconsidering.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
When researching MeteorExpress, I couldn't have guessed the direction the discussion would take. Let's take a minute to evaluate these different claims– Indra, non-state-sponsored, MBC, SEA... (thread)
(1)Let's dispense with the patently brittle claims– just because a ransomware group claims they perpetrated an attack doesn't make a credibly claim... looking at you DarkTracer.
(2)Subsequent claims that it's related to SEA are using a reference so outdated as to be meaningless. Additionally, SEA was a pro-regime group so nothing about this adds up other than a vague Syria connection.
Alright, let's add some substance to this Pegasus discussion. Contrary to what you might read, research into NSO has been going on for years and has involved a lot of great research groups (@citizenlab, @kaspersky, @Lookout, to name a few). It has also included leaks.
Folks are speculating about how we might know about the targets of Pegasus customers. NSO simultaneously claims that they don't know their customers targets but at the same time they know that none of the @AmnestyTech infections are real. Two obviously incompatible statements.
Assuming NSO doesn't have access to their customers targets, a list of targets of interest would have to come from a structural fault in the agent/exploit delivery infrastructure that NSO uses. We have a high-level view of how that system is architected.
Please beware the false parity of 'experts'. Random technical ppl aren't sources on difficult threat intel topics. Open speculation isn't substantiation for denials ('More details plz'). And neither is technical solipsism ('Everything can be faked! I'd do better than this!').
This uncoordinated flailing is being used to substantiate state interests that would rather not have the spotlight shined on them. We'll all do well to display sound judgement.
As to NSO’s blanket denial of having any access to how their customers use their software, that’s not entirely true by design —they manage the exploit delivery infrastructure for their clients. This is a hard-earned lesson from the HackingTeam days—
HT had a lot of woes attempting to idiotproof their payload building and exploit delivery process. The former was characterized by a prompt urging operators NOT to upload to VT (aimed primarily at dim Saudi operators). Exploits were handled more carefully via support portal—
The support portal required a backdoor created with the HT masternode and a lure document of the customer’s choosing. HT would create the exploit-laced file and host it via a one-time link that the operators could deliver in the method of their choosing.
Unbelievable work by @AmnestyTech, done in spite of @Apple’s reticence to provide means to verify the integrity of iOS devices. What’s it going to take for Apple to stop burying its head in the sand?
These remarks on the limitations when inspecting iOS devices should give us pause… there’s a mistaken belief that privacy is protected by limiting checks on system integrity and correlation of anomalies. What privacy is protected in these cases? (@tim_cook@radian)
I love Apple products. Wonderful things are regularly done under the hood to increase the cost of attack. But it’s clearly not enough to tinker with security engineering alone. Plenty of unscrupulous actors are finding it affordable and we can’t even tell how big that iceberg is.
Ok, I have to admit this @Apple vs. @CorelliumHQ business just doesn’t sit right with me. Let me @ @tim_cook and pretend to have some meaningful engagement regarding Apple’s larger security dilemma. #Thread
Everyone knows I’m a huge Apple fanboy. Until the cheese grater Mac Pro came out, I more or less had one of every apple product in my house (with some wiggle room). While I may gripe about missing function keys, there’s no system I’d rather use than MacOS and iOS.
I’ve also, at diverse points in my career, had the privilege to report ongoing APT campaigns directly to Apple alongside colleagues (h/t @craiu) and was treated kindly by folks invested in securing the Apple ecosystem within the means available to them.