Schneier on Security

Clive Robinson • January 27, 2025 4:45 PM

@ ALL,

On the face of it as given this is just an upgrade of “knock codes”.

Back before electronic communications people would knock on closed and defended doors in a way that gave a crude method of identification by the “rat-a-tat-tat” which developed into an “Identification Friend or Foe”(IFF) with another knock code response. As such a joke version is the “shave and a haircut”,

https://en.m.wikipedia.org/wiki/Shave_and_a_Haircut

This idea became the notion behind “port knocking” as a way to start a service on an IP based network. A series of effectively “null packets” would be sent in a time based pattern. If the pattern was approximately right the service behind a given port would be enabled for a short while (sometimes only to the originating address of the “knocker”). Thus in effect from 20,000ft a two stage process,

1, Identify and verify
2, Enable service.

Here we see an identification stage made rather more complex, but essentially the process is the same.

The use of PubKey to do this sort of thing is not new, and it’s been discussed on this blog before in a more secure form.

Crudely for understanding only, the authentication step is,

The service “Requester” sends a “nonce+ID” and it’s PubKey to the service “Provider” under the service “provider” “covert PubKey” (in effect a “shared secret”). The service “Provider” returns “a modified version of the “Requester” nonce and a symmetric encryption key” that is encrypted under the “requester” PubKey (or similar). From that point on much more efficient symetric encryption can be used.

The fact this has now been “seen in the wild” a decade later is curious, and thus sparks the question,

“Why Now?”

Or more involved,

“What has changed in the attack domain to warrant the extra effort?”

I’m thinking that,

“… they want to make sure all their hard work can’t be leveraged by competing groups or detected by defenders.”

Is not only “too pat” an explanation it’s also incorrect. Defenders will see such “in bound packets” from the external communications network, if they are even half way competent.

The fact they might not be able to do anything with it, does not mean they cannot see it and act on it.

Think on it in the same way you would the difference between “cryptanalysis” and “Traffic Analysis”…

Hence the comment,

“After receiving a magic packet hidden in the normal flow of TCP traffic, it relays a challenge to the device that sent it.”

But “hidden in the normal flow” is actually insufficient if the defenders are actually instrumenting correctly.

Which is where I suspect,

‘[T]he researchers wrote. “The combination of targeting Junos OS routers that serve as a VPN gateway and deploying a passive listening in-memory only agent, makes this an interesting confluence of tradecraft worthy of further observation.”‘

It’s not said, but there is a reason the “routers” are being targeted only. Put simply few defenders instrument the external side of their “Gateway Router”, for various reasons it’s not that easy to do.

It has a similar advantage to the NSA occupying the “first upstream router” from the target. In that in nearly all cases the “target” “can not see the wire” thus “instrument the communications” there.

However there is another reason the NSA went for the “upstream router”, and you can see why with,

“The lightweight backdoor is also notable because it resided only in memory, a trait that makes detection harder for defenders.”

Yes and no… PubKey encryption is CPU cycle heavy and thus produces a fairly visible “Power Spectrum” that can be spotted by fairly simple techniques and correlated with incoming data.

Which is probably why the first stages of the authentication are effectively “pattern matching” that need next to know CPU cycles thus have a very minimal extra power signature or time based signature as seen by the “one of five”,

“The passive agent is deployed to quietly observe all TCP traffic sent to the device. It discreetly analyzes the incoming packets and watches for one of five specific sets of data contained in them.”

The people behind this malware have above average experience or insight of the problem domain. Hence the researchers are interested.

There are a couple of other things I would do to make things more “covert” if I were an attacker developing such a port portal. Not least of which is to stop time and other “correlation” by rather more experienced defenders.

But the really important point to note is that it was a

“Held in RAM” attack on what is a “closed source OS”.

This highlights one of the reasons why “closed source” is problematic at best. Put simply the OS needs tools the defenders can use to look inside the device and it’s functioning to prevent this kind of attack. Almost by definition those who develop closed source systems view such tools as a “threat”. They will give you what are effectively “spurious reasons” but the reality is two fold,

1, They do not want you “reverse engineering” thus finding what they see as “trade secrets”.
2, They do not want you developing your own tools to run on their OS in what they all to often see as “competition” to them.

In effect both reasons boil down to illicit “Profit Protection” by “monopolistic practices”.

Something that has been pointed out about the likes of John Deere, HP printers, Apple, Google, Microsoft, etc, etc, etc.

Clive Robinson • January 29, 2025 6:18 AM

@ Bruce, ALL,

Speaking of “potential backdoors”, anyone remember the 2018 “Xmas Gift that keeps giving” called “Spectr” (and Meltdown) in Intel and AMD x86 CISC CPU’s?

Well it looks like it’s dropped another couple of eggs for people to have fun with, SLAP and FLOP,

SLAP – https://predictors.fail/files/SLAP.pdf
FLOP – https://predictors.fail/files/FLOP.pdf

However they are both on Apple Mx CPU’s based on a high-end ARM core. As such the Apple designs are supposed to be “clean sheet” that is not forced to support previous implementations quirks and deficiencies.

The two papers average 19 pages each so I’ve only “skim read” them so far.

But as the next thread up is about the current POTUS gutting USG “security” people should also be aware of this basic insane suggestion,

Whilst speaking at a Conference of the House Republicans, he is reputedly threatening hi-tech pharmacutical and semiconductor manufacturers with,

“In the very near future, we are going to be placing tariffs on foreign production of computer chips, semiconductors, and pharmaceuticals to return production of these essential goods to the United States of America.

The incentive is going to be they’re not going to want to pay a 25, 50, or even a 100 percent tax.”

First off there is “no return production” these products were never made in the US and for very good reasons.

The US have legislation like the War Act that arbitrarily allows the USG to just take the companies and their IP without any kind of compensation any time the US starts “A war on XXX” that politicos say has a “National Security” aspect.

On such company in the cross hairs is “Taiwan Semiconductor Manufacturing Corp”(TSMC) that has very much always been based in “Taiwan” just off of the Chinese coast.

Other companies are likewise close in against China including India, South Korea, Japan. Along with other nations in the West Pacific / South China Seas, that China is very much acting as an aggressor.

China will see this as confirmation that the current President has absolutely no intention of coming to the assistance of these nations contrary to many agreements and treaties.

For those that have been keeping an eye on such things, this is not at all surprising.

In fact one of the reasons the Taiwanese Government and TSMC have kept very much out of USG controlled territory is because they saw this coming quite a few decades ago back in the 1950’s if not earlier.

Having the USG and US MilComp “dependent” on their products means that the USG protecting “Taiwan” was in the US “National Security Interest”. The previous “executive” tried bribing TSMC and the Taiwanese Government with significant grants etc. But mindful of the War Act and similar basically said “no” to stuff the USG, MilComp, and Telco’s most want because they could see what the likely result would be come any hostility from China.

Yes TSMC product is a vital strategic national security issue for the USG and has got that way by “political stupidity” many have been making significant warning noises about since US Corps started “out sourcing” and “off shoring” to places like Russia and China.

If I was the Taiwanese Gov and TSMC I would carry on making “interested noises” towards the USG but “not closing a deal”.

But even if TSMC did agree to “build plant” in the US green/brown field, it’s not likely to go into actual production for over four years, then there is the issue of “training staff”. The nations around China are very mindful of how their “technology” ends up being made in China as “knock offs”. South Korea has some of the harshest “anti industrial legislation” in the world and they pursue it fairly rigourously (as Israel has found out).

Thus I can see these nations saying “NO” or more likely dragging things out interminably and finding reasons to keep “the good stuff” off of US soil untill either the current Executive and it’s policies are gone, or War has broken out and the USG in it’s own self interest has to face off with China.

As can be seen with both South Korea and Japan they are assuming “War is inevitable” and the USG will not support, hence their build up of military production capability.

However they can not keep up with what China is doing in terms of aircraft, carriers and support warships. It’s known that Japan, South Korea, and Taiwan are going all out on not just air based “Un Maned Vehicles/platforms”(UMVs) but long term subsea UMVs. As for India, well they appear to be upping missile and space based systems as well as warships and land based warfare systems including UMVs

All such UMVs need “non emissive” modes of operation and nuclear power sources. Which in part means technology that is still very much in the research phase, but for those that are in production means very high end DSP based sensor systems feeding into autonomous AI target identification and response systems.

There is no way these National Governments who see war as inevitable in the short to medium term, are going to move such sensitive to their survival technology exclusively to the US, just because the current executive is being run by someone who says they must. Especially as he is not going to be there long enough to get what he wants unless he finds a way to not only go “full term at full power” but considerably beyond.

Clive Robinson • February 5, 2025 5:31 PM

@ ResearcherZero, ALL,

And you think having a “crack through libsshd.so” is really bad news?

Well yes it is, but how about two more that are potentially much worse?

Firstly though a “heads up flag” that is so overdue it should have been drumed into peoples heads before the Internet “happened”,

“[T]his week a whole host of national security and cybersecurity agencies in the US, UK, Canada, Australia, Czechia, Japan, and more, issued or co-signed guidance on securing edge devices.

Edge devices, if exploited, can be used by attackers to gain a foothold in victim networks. Gizmos like wireless APs and routers are included among these, as are VPN gateways, firewalls, NAS appliances, internet-connected smart home cameras, and the like.
“

Longterm readers will know I’ve banged on about this for years, including describing the “Garden Path” method of looking for and finding some such attacks.

But back to the first of the two attack notices, which is on Netgear routers. And Netgear are being “Oh so very coy” about it. In fact in such a way some think they have something “so dire” that,

“Netgear is advising customers to upgrade their firmware after it patched two critical vulnerabilities affecting multiple routers.

The networking biz didn’t reveal too much in the way of details for either vulnerability, including whether they had been exploited or not, but warned that if customers didn’t follow the recommended steps their products would remain vulnerable.

Netgear didn’t release CVE identifiers for the vulnerabilities, opting instead for its own product security vulnerability (PSV) IDs: 2024-0117 and 2023-0039.”

https://www.theregister.com/2025/02/05/netgear_fixes_critical_bugs_while/

What makes me more than curious, is that they are also providing patches for equipment that has been previously “End of Life”(EOL) support terminated by Netgear…

What the NatSec SigInt agencies have finally warned about so prominently, is not exactly new, and is much like the E2EE advisory they issued just a couple of weeks back having “fought it for decades”. So “Take note”.

Oh and as I say from time to time “It’s one of the first questions I tend to ask” on visiting is,

“How and Why is this computer connected to external communications?”

Or similar.

The simple fact is contrary to “mantra” and the pushing of Silicon Valley “Big Tech” like Microsoft, most workplace or personal information based ICT equipment does not need to be connected to the Internet or other external communications,

“Why?”

Because the base rule of thumb going back into the 1960’s if not earlier is,

“If an external attacker can reach it they can breach it, and they will do so at some point.”

It’s inevitable for externally connected systems, not a maybe that can be ignored.

Properly isolating systems is the least expensive method of providing security against “Unknown Unknowns” and “Unknown Knowns”, and other “Zero Day Attacks” and similar that are not patched” and may never be so, which is all to often the way things are these days (hence the joke of “Security is the ‘S’ in IoT”).

But moving on from what feels like dry theory to the icy dread of the cry of “incoming”. Of the second much more “fun” attack…

Aside from “Segregation and isolation” mitigations security especially Communications Security” ultimately relies on “Shared Secrets” and the like that are “generated” by “True Random Number Generators”(TRNGs).

Back last century TRNGs were special pieces of hardware that cost a lot and why other methods of “generating entropy” as it was called were used (most of which had problems). Around 2005 TRNGs in your CPU chip started becoming the norm and people started forgetting about the importance of continuous testing (or testing at all…).

But most who are a little longer in the tooth, should remember “The Xmas Present that kept giving” of “Spectre and Meltdown” and how the “attack surface” was now inside the CPU chip hardware at a fundamental level way down the “Computing Stack” and could not be solved by the CPU manufacturers. Well there have been several more since then, with SLOP and friend being just a few days back.

Well often these attacks are quite difficult to exploit as tens of thousands of operations over quite some time have to be used to “pull the signal from the noise” via “side channel” leakage etc.

But how about an attack that uses the CPU manufacturer’s own CPU update/patch process of the internal “Microcode”?

Well that is what Google has apparently discovered about AMD Zen CPU chips,

https://www.theregister.com/2025/02/04/google_amd_microcode/

And as a demonstrator they have a “Proof of Concept”(POC) around the old joke of,

“Four is a random Number”.

That is Google have made a microcode patch that makes the apparent TRNG output from the AMD Zen CPU TRNG access only give “4” as the output number…

“[T]his ability to change the [CPU chip] microcode not only allows Google and others to customize the operation of their AMD chips, for good and non-good reasons, but it also smashes the Epyc maker’s secure encrypted virtualization and root-of-trust security features.”

So one of those “Ouch Moments” because this is about as serious as it can get when an attacker gets access.

For those who are a little younger, back when TRNGs were external devices on the likes of “serial cables” and cost eye watering amounts from the like of HP and IBM. It was assumed they would fail in some way, thus software measures were put in place to check the quality of the “generated entropy”.

Now that CPU TRNGs are basically and illogically “trusted” few do such checks any more…

So this is one of those “Wakey Wakey moments”…

In the past going back many years I’ve repeatedly warned of on chip TRNG vulnerabilities and the fact you could not properly test them.

As the first “on chip TRNG’s” produced by Intel could not be trusted. Is probably why Intel hid them behind Cryptographic Algorithms, which made “testing” near impossible.

One of “Linus ‘Mr Linux’s'” more famous online tirades was about this very issue. And after he had time to think about it, he changed his public viewpoint and said sorry.

Well now for everybody else who said and still say,

“Ain’t ever gonna happen”

Or similar about such on CPU attacks… Guess what “it’s happened” and you can not say you were not warned, especially now it’s happened and will continue to do so.

Which means,

“No fix, only mitigation as a security option”

So yeah I’m banging on about it yet again 😉