nanog mailing list archives

[NANOG] Re: JunOS and MX trojan and malware


From: Saku Ytti via NANOG <nanog () lists nanog org>
Date: Sat, 15 Mar 2025 20:14:01 +0200

I think the idea that stick would improve this is interesting, and I
cannot refute it. I certainly don't believe the C suite is entitled to
magnitude multiples to mean compensation, since we can't measure their
performance and unlike factory workers they carry no risk or downside.
After you are far along the food chain you get rewarded on the
downside and upside. Downside is a market problem, upside is your
achievement, this encourages bad risk taking.

If we consider personal safety as a more critical analog of infosec.
Secret service has a budget of 3B, attacker with a budget of a hundred
dollars can take a shot at the president. This is not a serious threat
actor, this is the absolute least concern, and still 3B is not enough
to stop it. Attacker leverage is extremely hard to cover.
I am not alive, because I live in a society that has mechanisms that
ensure that I cannot be hurt. I am alive, because literally no one is
motivated to kill me. I think this is where the best ROI for safety
is, ensuring that there is increasingly less and less motivation to
perform attacks. And to me it is easy to see what policies are
productive and what policies are counter-productive towards this, we
can't solve it 100%, but if we are serious about safety, we should be
able to improve it by focusing on the motivation part.




On Sat, 15 Mar 2025 at 16:18, Mike Simpson <mikie.simpson () gmail com> wrote:

Apologies for continuing the top posting.

I totally agree but you’re just describing late stage capitalism combined with the underlying attitude that’s 
pervaded IT forever.

It seems that everytime a company gets breached its share price always return to the same or higher value within a 6 
month period.
Accordingly, as public companies are entirely beholden to their shareholders, the only “proper” way of operating is 
to ignore all security considerations if they add any extra cost or friction of any kind.

The recent hilarity of the last few years of enterprises being repeatedly owned by terribad “security” appliances is 
one obvious example. The other being *every* telco in countries of potential interest being multiply owned for 
decades is another. Or just the SS7 protocol…

And yes. A motivated individual or team can potentially own anything (eg Qualys’s work on OpenSSH or the amazing work 
that the North Koreans are doing in the cryptocurrency space) but until there is an actual financial penalty that can 
significantly impact on a company to the point where the company becomes non-viable or a criminal penalty so that 
C-level execs get to go to jail for a bit we are doomed to being owned in completely trivial ways.

A good operator can minimise the risk to the point where only national states can routinely waltz in with ease until 
the poc for the 0day pre-auth RCE that *all* your kit *definitely* contains appears but until the vendors are made to 
care, even the best among us are going to be helplessly and endlessly playing whack-a-mole.

The main point is that the majority of the criminals causing havoc in our bailiwick aren’t hackers and don’t have 
technical talent. They are just criminals doing crimes with computers because it pays really well and they can do it 
with ease mainly because of the shoddy state of the industry. That’s all of our faults and it’s always been this way.

I remember people being all excited about TEMPEST four decades ago when cisco/cisco was all you needed to be in 90% 
of routers you came across or folk illegally accessing bank mainframes with just the correct phone number and a 4 
digit, brute-forceable PIN until surprisingly late in the 80’s
-I do wonder if any of those 1200/1200 modems are still connected…

I had hoped that the SEC might have been allowed to jail the solarwinds board member who submitted the usual “oh 
yeah, we totally care about security” boilerplate statement to their shareholders pour encourager les autres but alas 
it wasn’t to be.

/mike


On 15 Mar 2025, at 08:28, Saku Ytti via NANOG <nanog () lists nanog org> wrote:

I'm skeptical. Companies with massive financial incentive to deliver
secure devices, who control hardware and software and have infinite
budgets fail, and produce devices hobbyists own to show their skills.

Router vendors are significantly worse positioned. We accidentally
regularly find crashing bugs while receiving BGP updates or just
packet-of-death which crashes the NPU ucode, which probably could be
developed into a remote attack.

It would be reasonable to assume that any motivated attacker can own
any network device, regardless of the operator's care. And operator
care is trivial, I've not seen one properly written lo0 filter, much
less ddos-policer config, while Juniper is arguably the best vendor
here, most others don't even have a way to protect control-plane.

Yet, realised risks out of worst outcomes are trivial costs,
especially to the providers. We have a lot of anecdotes of massive
infosec failures, and it rarely has any significant financial impact.
Heck, when crowstrike had a mistake (fair mistake, impossible to
deliver a solution like that for infinite time without making a
mistake like that once and a while) I knew it's going to be great for
their business, and it was, it not only recovered in share price, but
outperformed the market. Because there was a lot of media attention,
and infosec leaders who weren't aware of end-point-security were
rushing to procure one, since all the big names seemed to be running
one, on account of being down.

We have a strategic problem in infosec, and we keep treating it as a
tactical problem, that one more fix and it's solved. It is not
working, and investing specifically to infosec is bad investment.
Sure, do things safely and right when it doesn't add cost and is
generally best practice.
I don't know if the strategic problem can be solved or how to even
improve the situation, but what we are doing is new age/faith work,
it's not working, and hasn't been working. And it might be, if not
fundamentally, commercially impossible to do anything secure, due to
the massive leverage the attacker has over the defender.

On Sat, 15 Mar 2025 at 02:44, Justin Streiner via NANOG
<nanog () lists nanog org> wrote:

This underscores the importance of proper security around out-of-band
management/console networks and proper security of console ports to the
extent that devices offer it.

Thank you
jms

On Thu, Mar 13, 2025 at 1:29 PM Bryan Fields via NANOG <
nanog () lists nanog org> wrote:

On 3/13/25 12:22 PM, Eric Kuhnke via NANOG wrote:

PDF file:

https://supportportal.juniper.net/sfc/servlet.shepherd/document/download/069Dp00000FzdmIIAR?operationContext=S1

From reading this there was no known remote exploit, they needed user level
shell access to exploit another local vulnerability which got them root and
then installed this exploit.  While this isn't great, if someone has
unaudited
login user level access to your routers, you've already lost.  Basic ACL's
go
a long way to filtering this from outside a logged network too.  Security
is
best when it's a multilayered approach.

This said, I've been greeted with a login prompt telnetting to carrier's
upstream router in the last 6 months.  They seemed outright confused why I
cared about it and closed the ticket.  🤦‍♂️

--
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
_______________________________________________
NANOG mailing list

https://lists.nanog.org/archives/list/nanog () lists nanog org/message/2UEVTAIT5YF3V75PKHMZG4IMUYKNQ6GE/
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/YM3RDKBIFRCDHERC6IQ3HYILHQC7W7BH/



--
 ++ytti
_______________________________________________
NANOG mailing list
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/OPCWW5EDODGAV4EFRHTIF46WEQYVBI6G/



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/XOKMEXAAPBKWDKHHS25FBQ6SFZI3NIIK/

Current thread: