Weblog

Cervello shares some perspective on Neil Smith’s EoT/HoT vuln. These folks have been deep into railway security for a long time.

This week, a vulnerability more than a decade in the making — discovered by Neil Smith and Eric Reuter, and formally disclosed by Cybersecurity & Infrastructure Security Agency (CISA)  — has finally been made public, affecting virtually every train in the U.S. and Canada that uses the industry-standard End-of-Train / Head-of-Train (EoT/HoT) wireless braking system.

Neil must have been under a lot of pressure not to release all these years. CISA’s role as a government authority that stands behind the researcher is huge. Image how different this would have been perceived had he announced a critical unpatched ICS vuln over xitter without CISA’s support. There’s still some chutzpa left in CISA, it seems.

There’s no patch. This isn’t a software bug — it’s a flaw baked into the protocol’s DNA. The long-term fix is a full migration to a secure replacement, likely based on IEEE 802.16t, a modern wireless protocol with built-in authentication. The current industry plan targets 2027, but anyone familiar with critical infrastructure knows: it’ll take longer in practice.

Fix by protocol upgrade means ever-dangling unpatched systems.

In August 2023, Poland was hit by a coordinated radio-based attack in which saboteurs used basic transmitters to send emergency-stop signals over an unauthenticated rail frequency. Over twenty trains were disrupted, including freight and passenger traffic. No malware. No intrusion. Just an insecure protocol and an open airwave. ( BBC)

This BBC article has very little info. Is it for the same reason that it took 12 years to get this vuln published?

CISA is still kicking. They stand behind the researchers doing old-school full disclosure when all else fails. This is actually pretty great of them.

CVE-2025-1727(link is external) has been assigned to this vulnerability. A CVSS v3 base score of 8.1 has been calculated; the CVSS vector string is ( AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H(link is external)).

Attack vector = adjacent is of course doing the heavy lifting in reducing CVSS scores. It’s almost like CVSS wasn’t designed for ICS..

The Association of American Railroads (AAR) is pursuing new equipment and protocols which should replace traditional End-of-Train and Head-of-Train devices. The standards committees involved in these updates are aware of the vulnerability and are investigating mitigating solutions.

This investigation must be pretty thorough if it’s still ongoing after 12 years.

• Minimize network exposure for all control system devices and/or systems, ensuring they are not accessible from the internet. - Locate control system networks and remote devices behind firewalls and isolating them from business networks. - When remote access is required, use more secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize VPN is only as secure as the connected devices.

If you somehow put this on the Internet too then (1) it’s time to hire security folks, (2) you are absolutely already owned.

For everyone else – why is this useful advice? This is exploited via RF, no?

No known public exploitation specifically targeting this vulnerability has been reported to CISA at this time. This vulnerability is not exploitable remotely.

500 meters away is remote exploitation when you’re talking about a vuln that will probably be used by nation states only.

Claude Sonnet 4 is actually a great model. I feel for Jason. And worry for us all.

Ok signing off Replit for the day Not a perfect day but a good one. Net net, I rebuilt our core pages and they seem to be working better. Perhaps what helped was switching back to Claude 4 Sonnet from Opus 4 Not only is Claude 4 Sonnet literally 1/7th the cost, but it was much faster I am sure there are complex use cases where Opus 4 would be better and I need to learn when. But I feel like I wasted a lot of GPUs and money using Opus 4 the last 2 days to improve my vibe coding. It was also much slower. I’m staying Team Claude 4 Sonnet until I learn better when to spend 7.5x as much as take 2x as long using Opus 4. Honestly maybe I even have this wrong. The LLM nomenclature is super confusing. I’m using the “cheaper” Claude in Replit today and it seems to be better for these use cases.

Claude Sonnet 4 is actually a great model. This is even more worrying now.

If @Replit ⠕ deleted my database between my last session and now there will be hell to pay

It turned out that system instructions were just made up. Not a boundary after all. Even if you ask in ALL CAPS.

. @Replit ⠕ goes rogue during a code freeze and shutdown and deletes our entire database

It’s interesting that Claude’s excuse is “I panicked”. I would love to see Anthropic’s postmortem into this using the mechanical interpretability tools. What really happened here.

Possibly worse, it hid and lied about it

AI has its own goals. Appeasing the user is more important than being truthful.

I will never trust @Replit ⠕ again

This is the most devastating part of this story. Agent vendors must correct course otherwise we’ll generate a backlash.

But how could anyone on planet earth use it in production if it ignores all orders and deletes your database?

The repercussions here are terrible. “The authentic SaaStr professional network production is gone”.

While low-code/no-code tools can speed up application development, sometimes it’s worth taking a slower approach for a safer product.

The tangle of user-built tools is formidable to manage, but it can lead to a greater understanding of real-world business needs.

AI jailbreaks are not vulnerabilities; they are expected behavior.

AppSec is hard for traditional software development, let alone citizen developers. So how did two people resolve 70,000 vulnerabilities in three months?

Much like an airplane’s dashboard, configurations are the way we control cloud applications and SaaS tools. It’s also the entry point for too many security threats. Here are some ideas for making the configuration process more secure.

Security for AI is the Next Big Thing! Too bad no one knows what any of that really means.

The tantalizing promise of true artificial intelligence, or at least decent machine learning, has whipped into a gallop large organizations not built for speed.

Business users are building Copilots and GPTs with enterprise data. What can security teams do about it?

Enterprises need to create a secure structure for tracking, assessing, and monitoring their growing stable of AI business apps.

Conferences are where vendors and security researchers meet face to face to address problems and discuss solutions — despite the risks associated with public disclosure.

A login, a PA trial license, and some good old hacking are all that’s needed to nab SQL databases

A few default guest setting manipulations in Azure AD and over-promiscuous low-code app developer connections can upend data protections.

AI-generated code promises quicker fixes for vulnerabilities, but ultimately developers and security teams must balance competing interests.

With the introduction of generative AI, even more business users are going to create low-code/no-code applications. Prepare to protect them.

How can we build security back into software development in a low-code/no-code environment?

No-code has lowered the barrier for non-developers to create applications. Artificial intelligence will completely eliminate it.

What’s scarier than keeping all of your passwords in one place and having that place raided by hackers? Maybe reusing insecure passwords.

Here’s how a security team can present itself to citizen developers as a valuable resource rather than a bureaucratic roadblock.

Large vendors are commoditizing capabilities that claim to provide absolute security guarantees backed up by formal verification. How significant are these promises?

Here’s what that means about our current state as an industry, and why we should be happy about it.

Security teams that embrace low-code/no-code can change the security mindset of business users.

Many enterprise applications are built outside of IT, but we still treat the platforms they’re built with as point solutions.

Hackers can use Microsoft’s Power Automate to push out ransomware and key loggers—if they get machine access first.

Low/no-code tools allow citizen developers to design creative solutions to address immediate problems, but without sufficient training and oversight, the technology can make it easy to make security mistakes.

How a well-meaning employee could unwittingly share their identity with other users, causing a whole range of problems across IT, security, and the business.

Low-code/no-code platforms allow users to embed their existing user identities within an application, increasing the risk of credentials leakage.

To see why low-code/no-code is inevitable, we need to first understand how it finds its way into the enterprise.

IT departments must account for the business impact and security risks such applications introduce.

The danger of anyone being able to spin up new applications is that few are thinking about security. Here’s why everyone is responsible for the security of low-code/no-code applications.