Do Not Name Vulnerabilities After Common Apps
In This Issue:
- NetCAT’s claws
- Blame-dodgers, trolls, finger-pointers…
- Routing report card
NetCAT’s Claws
A weakness in Intel chips lets researchers steal encrypted SSH keystrokes. Sort of. If you assume that typing cadence analysis can actually be used to determine anything you would type into SSH. For another take, see The NetCAT is out of the bag: Intel chipset exploited to sniff SSH passwords as they're typed over the network.
NetCAT was discovered by the Systems and Network Security Group at VU Amsterdam. The researchers disclosing the bug claim that NetCAT stands for “Network Cache ATtack.” We here at The Countermeasure are less than impressed with this backronym.
The problem is that netcat is a critical network administration and security tool. It’s used to read and write TCP and UDP streams. The researchers says that NetCAT is supposed to be a play on being able to read from the network without the other party being aware. To our eyes, all they've done is make searching for netcat usage examples miserable and filled with garbage search results for the next 20 years.
NetCAT relies on Intel's Data-Direct I/O (DIDO) in order to work. Turning off DIDO thwarts NetCAT, but can be a significant performance hit for any applications that rely on DIDO.
Countermeasure:
We're supposed to tell you here that you should turn off DIDO. And, if you are in a highly-secure environment, you probably should. In the real world, however, the NetCAT attack is difficult to implement, and unreliable. For now, you're probably safe.
This is, however, the first of the major DIDO vulnerabilities to be disclosed. It won't be the last. Keep an eye out for other side channel attacks against DIDO that are more capable. In the meantime, take NetCAT as an early warning that you need to characterise what turning off DIDO will mean for your workloads—because the day will come soon when you must.
Blame-dodgers, Trolls, Finger-pointers…
Tenable wants to see the end of the 'nation-state attacked us' excuse. Counterproductive victim-blaming? Motivational kick in the pants? CEO Amit Yoran is definitely trying to provoke e a reaction. Bring popcorn.
The key Yoran quote, lifted from the above article, is this: "Nation-state adversaries, even the sophisticated hackers, aren't using all these super scary hyped-up, zero day pieces of original exploit code or malware, it's just the basics that we aren't doing well that they're taking advantage of." And he's right.
Let's be clear about this: unless you're refining fissionable materials into something approximating weapons-grade, nation-states don't burn zero days to compromise your network. Nation-states burn zero days to compromise hundreds of millions of devices, and usually only when those zero days are inexpensive, and there are specific targets they feel they absolutely need to find. (Usually when they're hunting human rights activists and/or journalists.)
Yoran continues by basically telling everyone to stop blaming breaches on super-capable boogeymen, and start owning up to the fact that we’re all regularly getting wrecked by our own blatant incompetence. If you're reading The Countermeasure, you know he's telling the truth. Every single one of you reading this newsletter can think of at least a dozen things you should be doing to better defend your own systems, but aren't.
Now, those tempted to defend their own organizational prowess will likely pick a compromise event and wave it about loudly, exclaiming about the reality of state-sponsored attacks. What about last week's revelation that a nation-state had successfully hacked thousands of phones using a heap of zero-day vulnerabilities? Massive iPhone Hack Targets Uyghurs. Doesn't that contradict the entire premise of our rant?
No. Oh, don't get us wrong, infosec Twitter is achirp with the back-and-forth, but we feel it reinforces our point of view: nation-states burn zero days when they are either so cheap as to be irrelevant; they need to go after large groups; or both. It's not that state-sponsored attackers aren't a threat, it's that they aren't getting into our networks with secret voodoo against which we have no defense.
For those looking for additional drama this week, we’ll point you at Apple. Apple takes flak for disputing iOS security bombshell dropped by Google and Apple Disputes Google’s Claims of a Devastating iPhone Hack both have the topic covered.
Countermeasure:
Buried under the combative language, Yoran's point is a good one. Take responsibility for your stuff. Defend it as best you can, and be thorough. It doesn't matter who started it; you're still the one stuck shoveling manure in the aftermath, and your ability to throw your hands up in the air, claim "it was the nation-states with the zero days, in the library" and then get an insurance payout are coming to an end.
The cyberinsurance industry is getting wise to this. They're increasingly refusing to insure anyone for a reasonable amount of money unless you can prove that the basics were covered, and were still covered at the time of attack. The era of easy excuses is coming to an end. What's needed now is automated network discovery, inventory, and baselining. Perpetual monitoring, alerting for deviations from baseline, and automated random audits are also going to be part of the "must haves" for the next decade. Best to get ahead of the curve on this. Your cyberinsurance payments will soon depend on it.
Routing Report Card
On the list of projects that we here at The Countermeasure can get behind, MANRS ranks pretty high. See A project aims to help ISPs mind their routing security manners for full details.
Last month, the MANRS initiative launched the MANRS Observatory. The MANRS Observatory is website that grades networks on how well they comply with routing security standards. Basically: who is responsible for breaking Border Gateway Protocol (BGP), either because they're deliberately compromising the system in as part of an attack, or because they're incompetent?
It's. About. Time.
We here at The Countermeasure have long been of the opinion that BGP is a dumpster fire. Not because it doesn't do the job, but because it's from an era where security just wasn't a consideration. Like similar dated protocols (DNS springs to mind), it’s become a significant global vulnerability.
Sadly, the only thing harder to come by than consensus on how to address the problems posed by BGP has been actual effort at a global scale to solve the problem. Even DNS has seen more action toward security, and DNSSec is still nowhere close to universally deployed.
We would like to point out that DNSSec is now 20-some years old, with viable and easy-to-deploy implementations being at least a decade old. The "name and shame" approach of MANRS, while disputed by some, seems like a necessary approach.
Countermeasure:
Check your ISP(s) out on the MANRS Observatory. If they get a bad report card, raise a fuss. Report them to your national regulator. The MANRS Observatory only works if we collectively hold our providers' feet to the fire, and we should all do just exactly that.
That Rare Glimmer of Hope
Some infosec news that won't damage your calm.
- Suspected Commonwealth Games DDoS was only a Fortnite update
- Massachusetts city tells ransomware scumbags to RYUK off, our IT staff will handle this easily
That Hope, Extinguished
How not to react to a breach, episode # 5,216
- D-Link, Comba network gear leave passwords open for potentially whole world to see. Fellow humans, do not do this. No. Nope. No. And if you do make some sort of security blunder, do not react like this: "Manufacturers seem not to care – some routers still awaiting patches."
- 600,000 GPS trackers for people and pets are using 123456 as a password. Also do not react like this: "The researchers said they privately notified the vendor of the T8 Mini GPS tracker of the vulnerabilities on June 24 and never got a response. Attempts by Ars to reach company representatives were unsuccessful."
- Job-Seeker Data Exposed in Monster File Leak. Probably don't do this either: "The job website says it cannot notify users since the exposure occurred on a third-party organization's servers."
- Press Release: Open Privacy discovers unencrypted patient medical information broadcast across Vancouver - Sarah Jamie Lewis. Neither shalt thou do this: 'In a hypothetical scenario wherein multiple malicious actors accessed every patient record ever broadcast, it would thus remain the case that VCH has “no information to suggest that patient information has been compromised or used for a malicious purpose.”'
Thread of the Week
Bug bounties also violate labor laws, as I have warned for years. "Gig-type work has been under the spotlight for years as companies like Uber... have grown into behemoths even as the contractors they relied on did not receive the benefits or minimum pay guaranteed to employees" – Katie Moussouris - @k8emo
Resource of the Week
Podcast of the Week
Quick Links
- 6 Ways Airlines and Hotels Can Keep Their Networks Secure
- Most Android flashlight apps request an absurd number of permissions
- Hundreds of millions of Facebook users’ phone numbers found lying around on the internet
- Mozilla increases browser privacy with encrypted DNS