Back to Basics
Because some cybersecurity problems aren’t best solved by technology. (With humor and good grace throughout!)
If the media player above doesn’t work in your browser,
try clicking here to listen in a new browser tab.
Find TALES FROM THE SOC on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app. Or download this episode as an MP3 file and listen offline in any audio or video player.
[FX: PHONE DIALS]
[FX: PHONE RINGS, PICKS UP]
ETHEREAL VOICE. Hello, caller.
Get ready for TALES FROM THE SOC.
[FX: DRAMATIC CHORD]
DUCK. Welcome back, everybody, to TALES FROM THE SOC.
I’m Paul Ducklin, joined by David Emerson, CTO and Head of Operations at SolCyber.
Welcome back, David.
DAVID. Hey there.
DUCK. David, “B2B.”
But not in the sense that most of our listeners probably think of it.
By B2B, I mean Back to Basics.
And I want to look at three problems that keep coming up in the news, and that we keep warning people about.
DAVID. Sounds exciting!
DUCK. Let us start with topic one, which is ClickFix.
Basically, what it means is where criminals, cybercriminals, used to send you an email saying, “Hey, phone this toll-free number,” these days, they make it sound much more simple, so you don’t have to talk to anyone.
They say, “Hey, to fix your problem, copy-and-paste this command into a terminal window.”
And of course, it’s a Bash script, or it’s a PowerShell program, encoded so it’s not obvious.
To an innocent user, it looks really clever, but of course, it’s just some giant sea of malware you’re inviting in.
Now, how do we stop people getting suckered by that kind of trick, “Copy-and-paste this script”?
Mainstream software – and examples that I’ve experienced myself include the mathematical language Julia, and the much-vaunted Rust․․․
․․․their official installation instructions say, “Copy-and-paste this into a terminal window.”
And it’s curl THISURL | sh. [A Unix command to download a shell script into memory and run it “filelessly,” so it never shows up on disk.]
So, legitimate tools are doing this.
Why should people therefore naturally know that this is not good to do all of the time?
DAVID. Well, it’s effective because the user themselves is the attack vector.
So, there’s no file download.
It’s going to bypass most anti-viruses, most filtering.
You’re bypassing a lot of things, because the shell is a trusted context.
DUCK. And you’re bypassing the, “Hey, there’s this person that I don’t understand well, on a phone number that I don’t quite trust, who’s telling me to do this.”
DAVID. Yes.
DUCK. You’re doing it for yourself.
DAVID. We have to recognize the social element of this kind of attack.
The uncomfortable reality is that there are many legitimate developer-facing tools that do this, and there are many legitimate reasons to actually run shell scripts.
So we can’t really say, “Never run another shell script.”
DUCK. Exactly.
DAVID. I think it’s user education, and I think it’s user education in a couple of ways.
One of them is, “Be mindful.”
Copy-and-paste is everywhere, but that doesn’t mean you need to use it indiscriminately.
And then the other is, “Be paranoid.”
Even if you do use copy-and-paste; even if you are going to run that script that was given to you by somebody else․․․
․․․you can inspect it, or you can use methods and pipelines to get that script to yourself that are verifiable.
If there’s a checksum that comes with the script, and you do trust the developer, make sure you check that checksum.
It just takes you another moment, and you’ll have assurance that at least whomever wrote that, whom you ostensibly trust enough to run their script, did in fact deliver to you the script that they meant to deliver to you, and that you’re not running some pirated version, or some kind of version that wasn’t released by the official developer.
There’s not going to be a lot of detectability for this sort of thing, because the scope is just so broad.
I can say, “OK, nobody can run a Rust install this way,” but they’ll just run Julia that way, and it’ll be the same vulnerability.
So I don’t really see this as being a technical fix.
DUCK. And in any case, for software that doesn’t do an installer that way, the instructions are usually, “Download this executable and run it.”
DAVID. Yes!
Who knows what that executable is? [LAUGHS]
DUCK. Which is exactly what we’ve been telling people not to do with malware, since the CHRISTMAS EXEC worm in 1987!
DAVID. Yes, and even if you say, OK, use apt․․․ [the built-in auto-updating tool in Debian-based Linux distros]
․․․apt get rust, let’s say, and you’re using GPG keys, so it’s validated?
This is not to say that there has never been a vulnerability inapt.
There have been packages maliciously distributed through established, legitimate, mature package managers.
DUCK. The XZ Utils hack comes to mind, doesn’t it?
DAVID. Uh-huh.
DUCK. The compression library was tainted, so that it would taint some systemd components, so that it would taint Debian’s version of openssh, so that it would open a zombie network on trusted servers.
Wow, quite a chain!
DAVID. Yes, there’s nothing new under the sun.
There’s also no way to fix everything holistically in a technical sense.
Defense in depth; educate your users; get a little paranoia into the system.
I think that’s how we fix this ultimately.
DUCK. User education can get people on top of that, for all that people diss it quite a lot, can’t it?
DAVID. Yes, it really can.
And the acknowledgement that many of these attacks are social in nature.
I consider this social.
It’s not necessarily a single technical method here.
DUCK. Exactly.
Just going, “Hey, well, we’ll turn on all the tools and features and blockers in our EDR software”․․․
That might actually end up getting in your way.
And then people will just find a way around protections that should be on, because you maybe turned on things that you hadn’t really thought through properly?
DAVID. Yes.
If I run one of these commands – I spend a lot of the time in a shell, so it wouldn’t look anything weird to my security team.
It would be executed as me in a shell.
Cut-and-paste all day long – that’s what I do; that’s part of my job.
It really wouldn’t be unusual, and that’s also why this works.
DUCK. So, it is a cultural thing to fix, not a technological one?
DAVID. I believe so, primarily, yes.
DUCK. Right, David.
Let’s move on to another issue that’s been in and out of the news lately.
The first one was from CISA in the US, and actually applies as a regulation that federal government teams have to comply with; the other is a warning from the FBI.
And this issue is replacing end-of-life edge devices, like routers.
In the FBI’s latest warning, what they’re saying is that if you have any of these, you really need to replace them.
Because they contain bugs that will never be fixed.
They are being routinely, repeatedly, regularly exploited by criminals for what are known as “residential proxies.”
They let other people borrow your router, and your connection, and rent it out to other crooks, or to state-sponsored actors, or whomever they want.
Not only are you putting other people at risk, but if law enforcement come looking, the finger’s pointing at you.
And if your ISP won’t replace them, you kind of have to go and find another ISP, right, if you can’t bring your own router to the party?
DAVID. Yes, if you have that ability.
A lot of people, at least in the United States, really do not find themselves in markets that are competitive.
They may have two options.
Maybe.
Some people have only one option for an ISP.
DUCK. Yes.
DAVID. And so you’re really not always in a situation where you can just chuck out your router and go grab another one.
Obviously, there’s also the context of resources – some people may not have the resources just to buy another router.
I will say that I have a little bit less empathy here, given the specific examples that the FBI and CISA raised, because those are ancient pieces of equipment!
DUCK. Yes.
DAVID. They are very, very old by the standards of Internet routers.
DUCK. Yes.
It’s not like three or four years old, like where you think, “Why can’t I use my iPhone from 2019?”
DAVID. Right, right. [LAUGHS]
DUCK. Some of these things are 10, 12 years old?
DAVID. Oh, easily, yes.
To me, that’s unfortunately part of the consumptive game of technology, sometimes.
Which is, “Don’t get in the game if you’re not ready to update your stuff every now and then.”
A lot of companies, and even a lot of individuals, do not understand that.
And then they wonder why their inkjet printer from 1998 doesn’t work anymore, or, in this case, why their router from 2005 is no longer useful as a router in a secure sense.
I do think that there has to be an expectation, not so much that people enter this treadmill, but that there is an education of the infrastructure owners.
The ISPs, the ISP customers, and enterprises are especially guilty of this.
That if you enter the game of technology, if you enter the game of infrastructure, that is a commitment, now and in the future, when it becomes untenable to run that infrastructure for reasons that may not be its suitability for routing Internet traffic.
Someone, probably, somewhere, is saying, “Well, my E1200 router works just fine – I have a 100 megabit/sec connection to my ISP, and it’s been running that since 2005.”
But, actually, that’s not the only criterion here.
They need to understand that functionality may not be defined by its ability to route – it may be defined in the future by its ability to remain secure.
It’s a sticky situation.
I understand the problem, but you really do have to replace stuff that is that old.
You just do.
DUCK. CISA is saying that federal government departments, federal government offices․․․ I think they have three months to come up with a list of so-called edge devices, and they’re just starting with the edge devices.
“You need to tell us what you’ve got within three months, so that we know you know how to find them.”
And then, even if they’re still supported for a year-less-one-day, you have one year to replace them all.
That sounds quite dramatic, doesn’t it?
But we should be there already, shouldn’t we?
DAVID. It’s not a bold change.
Most of the organizations to which that CISA Binding Operational Directive would apply are already obligated to not run end-of-life equipment; to not run end-of-life software; and to patch regularly any critical vulnerabilities in their infrastructure.
They’re obligated by CMMC; they’re obligated by any kind of DoD contract terms; they’re obligated, sometimes, by their own controls under which they are audited by a third party.
So the point is, really, that there are probably very few organizations subject to that Binding Operational Directive which didn’t already need to do this.
DUCK. I’m trying not to start chuckling, David, because that isn’t funny, is it?
Yet it sort of is․․․
DAVID. It’s just how it is!
If you’re running something for the government, there are standards; they’re not new.
And these routers?
They weren’t called out in CMMC – of course they weren’t.
You can’t call out the entirety of the world in a regulation.
But the regulation says, “You’re not going to run end-of-life stuff; and if you do have a critical vulnerability, you’re going to patch it.”
And the patch interval is not 12 months!
The point being, you needed to do this anyway, and an old E1200 router is not something that has any business being run in any government network, anywhere in the world, really.
Replace it.
CISA is writing a Binding Operational Directive in order to make a point, but you probably already needed to do this for another reason anyway.
DUCK. So this is not a question of the government banging some big drum to prove how clever it is?
DAVID. No.
DUCK. It’s not a question of, “Oh, we need fewer regulations because, hey, we’re a free-market economy.”
This is simpler than simple common sense, for a federal government department?
DAVID. Yes.
DUCK. I’m not saying that for everyone at home.
Maybe there the responsibility lies somewhere else, like with the ISP who gave them the router?
DAVID. In the context of the FBI warning, in particular – to the extent that it’s being interpreted by ISPs for civilians, and by civilians themselves – it’s still, “Replace your stuff, that’s just too old,” but they aren’t obligated.
A Binding Operational Directive to federal agencies?
That’s crazy.
For the same reasons that they shouldn’t be running Windows 98 at this point, they shouldn’t be running an E1200.
DUCK. [LOUD LAUGHTER]
Yes.
This is not a “Windows 7” or a “Windows 10” problem, is it?
DAVID. No.
DUCK. This really is “Windows 98.”
DAVID. [LAUGHS] Well, maybe Vista or something.
DUCK. Yes.
So, what about the warnings that we’re seeing from the FBI, where they’re saying, “Look, we can’t force you to do this, but come on, folks – this is really, really bad.”
Like you said, there may be some people in some parts of the US where they don’t have a choice.
They could use their mobile phone network, but it would be too expensive, because maybe they don’t have uncapped data plans.
Or they can use a fiber or a cable ISP, but there’s only one ISP they can choose, and there’s only one router they get.
Do those ISPs need to be brought to task if they’re not prepared to do this themselves?
DAVID. That’s a long tail there, but I think that it’s probably․․․
“Yes,” I think is the answer.
Frankly, I think this might be a good place to put in regulatory safeguards for the free market.
It’s really crazy to me that there are markets in the United States – and some of them are urban markets; I’m not talking about Gravelswitch, Kentucky, I’m talking about downtown Chicago, Illinois, a gigantic city․․․
In some neighborhoods, your options are, say, “AT&T, or no internet at all.”
And that makes no sense at all.
DUCK. [LAUGHING] Yes, that sounds like 1979, before the Bell break-up, doesn’t it?
DAVID. [LAUGHS] Yes, exactly.
It’s not even reflective of reality, right?
In the sewer outside of your condo in Chicago, there are probably seven ISPs on your street.
It’s a matter of running them into your building; it’s a matter of allowing the monopoly to be broken.
I actually think, in this case, this is not the FBI’s remit.
They’re just trying to get their job done, which is warn people.
DUCK. Yes, because their job is not to fix the routers.
Their job is to prevent the cybercrime that happens because of the routers.
DAVID. Right, exactly.
So this is not the FBI’s problem.
But I think, in the context of this sort of private-market concern, what needs to happen is that the customers need to have choice.
The consumer needs to have a choice.
And that can take a couple of forms.
In Gravelswitch, Kentucky, it might be true there are not a lot of ISPs – there’s just one ISP, and the one enterprising group that has run the fiber down the road is your choice, or no internet at all.
I think the regulation should be, “You can own your own equipment.”
It would be as simple as allow the user to bring their own equipment.
Maybe there would be some support constraints around that, or whatever, but then you don’t have the situation where you could potentially have no choice, and no ability to get a better router.
That would be acceptable in a market where there truly is constrained choice because of physical constraints.
Then, I think the bigger problem – and this is more Americans than that first example – is that in these urban markets where there is actually a lot of choice in infrastructure, there is still not a lot of choice in terms of which ISP you’re on-boarded with.
And that needs to be broken up.
I should have, in Washington DC, six ISPs available to me.
There’s no reason that infrastructure is not available close to my house.
So if Verizon Fios tells me I can’t run my own router and I need to run an E1200, well, OK, I guess I’m going to a competitor like Cogent today.
And I think that that’s something that is probably regulatory in nature, in both cases.
Either offer the choice in routers, or offer the choice in ISPs.
DUCK. That might be something along the lines of the EU’s Cyber Resilience Act.
Among its many provisions is a section that says, “When somebody provides you with a service or a product, they have to commit in advance to support it for a minimum period of time with security fixes.”
And they have to tell you how long that is going to be.
The idea there, as I understand it, is to try to stop vendors from using security upgrades as a way to squeeze you for a sale, as in, “Hey, you must take the new features, because that’s the only way to get the security update.”
They have to make it clear to you when that moment would arrive, so you can decide whether you want to sign up for their service or not.
Do you think that sounds reasonable?
DAVID. It can work.
It would not be my preferred solution, because I see some technical issues with that, and I also see the ability to push back on that as maybe an overstep in the free market.
I don’t necessarily want to compel vendors to support something for longer than could become practical, and I don’t necessarily want to compel consumers to buy things for ten years.
And I also think that both of those compulsions could potentially be unsustainable.
You might not know what ten years from now looks like, and now you’ve committed to ten years from now supporting this device.
Personally, I prefer offering choice through regulation, rather than offering further constrained specification through regulation.
DUCK. So you make it easy to switch.?
DAVID. Yes.
DUCK. Rather than perhaps giving the consumer the right to force a vendor to behave in a certain way for a long time?
DAVID. Precisely.
What I’m really saying is, “I don’t blame Linksys for the E1200 and the E2500, which were perfectly fine routers 15 years ago.”
I don’t blame them for that in 2026, when these are not secure and should not be run.
DUCK. [LAUGHING] I don’t blame them for the WRT54 either.
DAVID. [MORE LAUGHTER] Hey, that was a good router.
DUCK. Particularly the Linux version! [The WRT54GL version.]
DAVID. Yes.
DUCK. It was some kind of GPL violation, wasn’t it, some kind of open source licensing dilemma, and eventually they just said, you know what․․․
DAVID. OpenWRT! [A long-running, Linux-based, open source router distro.]
DUCK. ․․․instead of fighting it [the GPL violation], let’s actually get everyone on side by saying, “OK, we’ll make a version of this router that you can do what you want with.”
Suddenly they were heroes instead of villains.
DAVID. Oh, it was fantastic.
The fix there is to support choice, at least in America, where we specifically have this issue with ISPs locking people in.
DUCK. Right.
DAVID. By the way, I’m a Verizon Fios customer.
I’m actually very happy in this regard.
I don’t have much choice, because of the sort of stupid American problem that I live in DC, but I only have one ISP I could get from.
But I’m a perfectly happy customer because Verizon Fios lets me run whatever router I want.
They won’t support it, and they won’t help me if it goes wrong, but all I have to do is tell them I swapped my router out and they let it happen.
That to me is all I really need.
I’m perfectly happy at this point.
DUCK. Excellent.
So what about government intervention when there might be some suspicion that devices that have flooded onto the market may have been, how can I put this kindly, tampered with by foreign powers who do not have your best interests at heart?
DAVID. Yes, TP-Link, to back up a little bit.
This is a situation where the supply chain for a very large vendor of network infrastructure was essentially middled by the People’s Republic of China.
And they were inserting some kind of malicious code to the devices that were going to certain locations that they wanted telemetry on – military commissaries and so on.
DUCK. So they were saying, “Here’s some stuff that you need to melt into the middle of this, put it on the router?”
DAVID. I don’t know that we’ve proven how.
It could have happened after manufacture; it could have happened during.
I don’t know that that’s been proven.
DUCK. Right.
DAVID. But the devices that went to certain customers were demonstrably not the same as the devices that went to other customers.
DUCK. This is like those Selectric typewriters that were sent in the diplomatic bag?
DAVID. Yes!
DUCK. From the United States to the Soviet Union.
But when they arrived at the embassy, they had an extra coil added․․․
DAVID. Yes!
DUCK. ․․․that could monitor the letters that you typed?
[LAUGHS]
[A fascinating tale of cryptographic derring-do from the 1970s, now known as Operation GUNMAN.]
DAVID. It’s exactly that!
It may have been IBM’s fault; it may not have been.
But something happened, and here it is!
DUCK. Yes.
DAVID. When that happens, now you are solidly in the realm of government intervention.
There is, at that point, a liability.
If the vendor, for example, and TP-Link in this case is the one that’s going to be held liable, well, I would say that they’re liable now for replacing those devices.
If we decide that this is actually the PRC versus the United States, it sounds to me like it’s a little greyer than you might just have US federal support to assist the consumer in the replacement of the devices.
The number of solutions that I personally support in that situation are much greater, and also much heavier on the government side.
But in the case of CISA?
Sorry, government contractors!
You all had controls that you should have been making good on, and I guess you weren’t.
And now CISA is just giving you a particular category of things that you need to replace, rather than a general one.
DUCK. Yes.
We told you once; we told you twice; we told you three times – now we’re telling you for a fourth time!
So, David, the last topic is the perennial problem of speed versus safety.
I read an intriguing article today saying, “Hey, Google Android is going to get this fantastic new feature where WebGPU access․․․”
(That’s the ability for JavaScript to actually run code that directly calls into your graphics processing unit.)
“․․․may actually be constrained, because sometimes using this can reduce security.”
It sort-of reminds me of the problem that we had when Spectre and Meltdown, and all those attacks, first became a thing on processors.
OpenBSD famously said, “You know what? We’re going to take a one-time performance hit – we’re going to turn hyperthreading off. There’s something we never have to worry about again.”
Do you think we need more of that?
Because sometimes that extra performance is just for show?
DAVID. [LAUGHS] Do we need more of discretion?
[MOCK INCREDULITY] Is that what you’re asking?
Yes, yes we do!
[LAUGHTER]
DUCK. [CONTRITE TONE] I didn’t mean it to sound like a leading question․․․
DAVID. I do think we need more discretion.
I think that OpenBSD․․․
I love that project, by the way.
I can’t run it as my daily workstation because it just doesn’t work for my life, but I give them money every time they release a new version.
I really do like them!
DUCK. I’ve met Theo [de Raadt, founder of OpenBSD], and he’s very determined, shall we say.
[LAUGHTER]
DAVID. Absolutely.
They have their principles; they stick to them; and the principles are not actually unreasonable – OpenBSD is not a system that is unreasonably broken.
At the end of the day, though, their approach was correct.
Nobody needs hyperthreading.
OK, I’m not going to say nobody – the market at large does not require hyperthreading, and whether I have 16 cores or 14 cores, in terms of the performance differential [with and without hyperthreading], is not going to make or break any process I run.
DUCK. [JOKING TONE] That nearly sounded like a Dirty Harry quote.
DAVID. [PERPLEXED] Why?
DUCK. [FAUX CLINT EASTWOOD] “In all the excitement, I forgot whether I had 16 cores, or only 14.”
DAVID. Oh, right, yes. [LAUGHTER]
It just isn’t relevant in my daily life, and so OpenBSD had the right approach.
What it’s called is, “Discretion,” and people could use more of it!
You don’t always need more everything.
Sometimes more-and-better everything is a maintenance burden; is a vigilance burden.
DUCK. Yes.
DAVID. And more-and-better everything turns into more maintenance for everything.
This is really a topic that is on this podcast about every third time – intentional design and discretion go a long way toward building something that you can tolerate maintaining, including in your own life.
DUCK. Yes!
David, why don’t you take us out by giving three simple B2B tips, as in Back to Basics?
DAVID. Culture change.
For ClickFix: security awareness training; ensuring that people understand they shouldn’t just copy-and-paste everything.
DUCK. So, it’s a principle of operation?
DAVID. Yes, cultural.
DUCK. A culture of operation, not a checklist?
DAVID. Absolutely.
For IT teams, maybe think about disabling or alerting on PowerShell execution․․․
DUCK. Right.
DAVID. ․․․for some users who don’t do that normally.
But all that’s really hard – the cultural stuff, that’s the core of it.
When we have the forever-day stuff [bugs that will never be fixed], the forever-day network routers and whatnot?
Audit your network edge.
You know what, not even your network edge!
Audit every damn thing in your network for end-of-life gear.
Not “this quarter” – do it now.
There is no reason to have end-of-life anything in your network.
If you’re finding that burdensome, you should have thought about that when you deployed so much stuff and then managed not to patch it!
But, at the end of the day, everything end-of-life should be gone.
Assume it has been, or will be, compromised, and if you’re a government contractor, you should have been doing that years ago.
If you’re an individual, I understand how this happens, and you just need to fix it.
DUCK. And speed versus safety?
DAVID. Discretion goes a long way.
Discretion and intentional design.
If you didn’t need hyperthreading, don’t enable hyperthreading.
If you didn’t need [WebGPU] hardware offload to run your animated cat GIFs, you might just consider doing without, because that’s one less thing that has a huge compromise interface to maintain.
DUCK. So, at the risk of doing one of my famous cliches again, in all of these cases, “Less is often a lot more.”
DAVID. Yes!
DUCK. David, thank you so much.
You were very passionate today, with a very wide range of opinions, and thoughtful opinions at that.
So I really do appreciate that.
Thanks to everybody who tuned in and listened.
If you enjoyed this podcast, please don’t forget to subscribe, so you know when each new episode drops.
Please like and share us on social media – that means an awful lot to us.
And don’t forget to visit https://solcyber.com/blog – this is community advice, not sales schpiel.
And just to finish off․․․
Until next time, stay secure.
DAVID. There you go!
[FX: CALL ENDS]
Catch up now, or subscribe to find out about new episodes as soon as they come out. Find us on Apple Podcasts, Audible, Spotify, Podbean, or via our RSS feed if you use your own audio app.
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
