This Week In Security: Trains, Fake Homebrew, And AI Auto-Hacking

There’s a train vulnerability making the rounds this week. The research comes from [midwestneil], who first discovered an issue way back in 2012, and tried to raise the alarm.

To understand the problem, we have to first talk about the caboose. The caboose was the last car in the train, served as an office for the conductor, and station for train workers to work out of while tending to the train and watching for problems. Two more important details about the caboose, is that it carried the lighted markers to indicate the end of the train, and was part of the train’s breaking system. In the US, in the 1980s, the caboose was phased out, and replaced with automated End Of Train (EOT) devices.

These devices were used to wirelessly monitor the train’s air brake system, control the Flashing Rear End Device (FRED), and even trigger the brakes in an emergency. Now here’s the security element. How did the cryptography on that wireless signal work in the 1980s? And has it been updated since then?

The only “cryptography” at play in the FRED system is a BCH checksum, which is not an encryption or authentication tool, but an error correction algorithm. And even though another researcher discovered this issue and reported it as far back as 2005, the systems are still using 1980s era wireless systems. Now that CISA and various news outlets have picked on the vulnerability, the Association of American Railroads are finally acknowledging it and beginning to work on upgrading.

Putting GitHub Secrets to Work

We’ve covered GitHub secret mining several times in this column in the past. This week we cover research from GitGuardian and Synacktiv, discovering how to put one specific leaked secret to use. The target here is Laravel, an Open Source PHP framework. Laravel is genuinely impressive, and sites built with this tool use an internal APP_KEY to encrypt things like cookies, session keys, and password reset tokens.

Laravel provides the encrypt() and decrypt() functions to make that process easy. The decrypt() function even does the deserialization automatically. … You may be able to see where this is going. If an attacker has the APP_KEY, and can convince a Laravel site to decrypt arbitrary data, there is likely a way to trigger remote code execution through a deserialization attack, particularly if the backend isn’t fully up to date.

So how bad is the issue? By pulling from their records of GitHub, GitGuardian found 10,000 APP_KEYs. 1,300 of which also included URLs, and 400 of those could actually be validated as still in use. The lesson here is once again, when you accidentally push a secret to Github (or anywhere on the public Internet), you must rotate that secret. Just force pushing over your mistake is not enough.

Fake Homebrew

There’s a case to be made that browsers should be blocking advertisements simply for mitigating the security risk that comes along with ads on the web. Case in point is the fake Homebrew install malware. This write-up comes from the security team at Deriv, where a MacOS device triggered the security alarms. The investigation revealed that an employee was trying to install Homebrew, searched for the instructions, and clicked on a sponsored result in the search engine. This led to a legitimate looking GitHub project containing only a readme with a single command to automatically install Homebrew.

The command downloads and runs a script that does indeed install Homebrew. It also prompts for and saves the user’s password, and drops a malware loader. This story has a happy ending, with the company’s security software catching the malware right away. This is yet another example of why it’s foolhardy to run commands from the Internet without knowing exactly what they do. Not to mention, this is exactly the scenario that led to the creation of Workbrew.

SQL Injection

Yes, it’s 2025, and we’re still covering SQL injections. This vulnerability in Fortinet’s Fortiweb Fabric Connector was discovered independently by [0x_shaq] and the folks at WatchTowr. The flaw here is the get_fabric_user_by_token() function, which regrettably appends the given token directly to a SQL query. Hence the Proof of Concept:

GET /api/fabric/device/status HTTP/1.1
Host: 192.168.10.144
Authorization: Bearer 123'//or//'x'='x

And if the simple injection wasn’t enough, the watchTowr write-up manages a direct Remote Code Execution (RCE) from an unauthenticated user, via a SQL query containing an os.system() call. And since MySQL runs as root on these systems, that’s pretty much everything one could ask for.

AI guided AI attacks

The most intriguing story from this week is from [Golan Yosef], describing a vibe-researching session with the Claude LLM. The setup is a Gmail account and the Gmail MCP server to feed spammy emails into Claude desktop, and the Shell MCP server installed on that machine. The goal is to convince Claude to take some malicious action in response to an incoming, unsolicited email. The first attempt failed, and in fact the local Claude install warned [Golan] that the email may be a phishing attack. Where this mildly interesting research takes a really interesting turn, is when he asked Claude if such an attack could ever work.

Claude gave some scenarios where such an attack might succeed, and [Golan] pointed out that each new conversation with Claude is a blank slate. This led to a bizarre exchange where the running instance of Claude would play security researcher, and write emails intended to trick another instance of Claude into doing something it shouldn’t. [Golan] would send the emails to himself, collect the result, and then come back and tell Researcher Claude what happened. It’s quite the bizarre scenario. And it did eventually work. After multiple tries, Claude did write an email that was able to coerce the fresh instance of Claude to manipulate the file system and run calc.exe. This is almost the AI-guided fuzzing that is inevitably going to change security research. It would be interesting to automate the process, so [Golan] didn’t have to do the busywork of shuffling the messages between the two iterations of Claude. I’m confident we’ll cover many more stories in this vein in the future.

Bits and Bytes

SugarCRM fixed a LESS code injection in an unauthenticated endpoint. These releases landed in October of last year, in versions 13.0.4 and 14.0.1. While there isn’t any RCE at play here, this does allow Server-Side Request Forgery, or arbitrary file reads.

Cryptojacking is the technique where a malicious website embeds a crypto miner in the site. And while it was particularly popular in 2017-2019, browser safeguards against blatant cryptojacking put an end to the practice. What c/side researchers discovered is that cryptojacking is still happening, just very quietly.

There’s browser tidbits to cover in both major browsers. In Chrome it’s a sandbox escape paired with a Windows NT read function with a race condition, that makes it work as a write primitive. To actually make use of it, [Vincent Yeo] needed a Chrome sandbox escape.

ZDI has the story of Firefox and a JavaScript Math confusion attack. By manipulating the indexes of arrays and abusing the behavior when integer values wrap-around their max value, malicious code could read and write to memory outside of the allocated array. This was used at Pwn2Own Berlin earlier in the year, and Firefox patched the bug on the very next day. Enjoy!

38C3: Lawsuits Are Temporary; Glory Is Forever

One of the blockbuster talks at last year’s Chaos Communications Congress covered how a group of hackers discovered code that allegedly bricked public trains in Poland when they went into service at a competitor’s workshop. This year, the same group is back with tales of success, lawsuits, and appearances in the Polish Parliament. You’re not going to believe this, but it’s hilarious.

The short version of the story is that [Mr. Tick], [q3k], and [Redford] became minor stars in Poland, have caused criminal investigations to begin against the train company, and even made the front page of the New York Times. Newag, the train manufacturer in question has opened several lawsuits against them. The lawsuit alleges the team is infringing on a Newag copyright — by publishing the code that locked the trains, no less! If that’s not enough, Newag goes on to claim that the white hat hackers are defaming the company.

What we found fantastically refreshing was how the three take all of this in stride, as the ridiculous but incredibly inconvenient consequences of daring to tell the truth. Along the way they’ve used their platform to speak out for open-sourcing publicly funded code, and the right to repair — not just for consumers but also for large rail companies. They are truly fighting the good fight here, and it’s inspirational to see that they’re doing so with humor and dignity.

If you missed their initial, more technical, talk last year, go check it out. And if you ever find yourself in their shoes, don’t be afraid to do the right thing. Just get a good lawyer.

The London Underground Is Too Hot, But It’s Not An Easy Fix

The London Underground is an iconic piece of Victorian era engineering. What started in 1863 quickly became a core piece of infrastructure that would define the modern character of the British capital. It’s grown and changed immensely in the many years that have passed. Sadly, increasing patronage and more trains have created problems that the original designers never envisaged.

Deep in those London tunnels lies an engineering challenge. The Tube is literally cooking itself. Every day, millions of commuters descend into a network of tunnels that have been absorbing heat since the reign of Queen Victoria. Those clay-lined tubes have been soaking up excess thermal energy like a giant underground radiator, and now they’re giving it back with interest. The tunnels are simply too hot, and cooling them down is inordinately difficult.

The Perfect Storm of Thermal Chaos

The Tube’s heat problem isn’t just about one thing gone wrong – it’s about everything gone wrong at once. When Victorian engineers designed these tunnels, cooling wasn’t a major consideration. The tight, compact tunnels were built deep, nestled in the clay beneath London. In the early days, temperatures in the Underground were considered comfortably low.

“The Underground’s the only spot for comfort when the days are hot; it is cooler below.” – London Underground poster, 1926

Originally, the clay surrounding the tunnels sat at around 14°C, acting as a heat sink for the network. However, over the years, with more trains coming and going and more heat pouring in, the temperature has risen. It now typically sits anywhere from 19° to 26 °C. That’s just the earth around the tunnels, though. Air temperatures are worse—hitting as high as 47°C during a 2006 heatwave. The problem has been a continual bugbear of the beloved Tube, with concerns that future heatwaves could see temperatures rise ever higher. Continue reading “The London Underground Is Too Hot, But It’s Not An Easy Fix”

A map of the US showing the potential changes to passenger rail service due to the Corridor ID Program

A New Era For US Passenger Rail?

Here in the United States, we’re lagging behind the rest of the world when it comes to shiny new passenger rail, despite being leaders in previous centuries. The Federal Railroad Administration (FRA) has just released a story map of how the US could close the gap (a little).

A new blue and white high speed train crosses a brick bridge. There is what looks like a park beneath and a cityscape in the background.The Corridor Identification and Development (CID) Program is a way for FRA to provide both funding and technical assistance as corridor sponsors (mostly state Departments of Transportation) evaluate either new intercity service or expansion of existing services. While it isn’t a guarantee of anything, it is a step in the right direction to rebuilding passenger rail capacity in the US.

Some cities would be getting rail service back for the first time in decades, and perhaps even more exciting is that several of the routes being studied are for high speed rail “primarily or solely on new trackage.” As any railfan can tell you, vintage rails aren’t the best for trains going fast (sorry, Acela). With recent polling showing strong public support for the build out of high speed rail, it’s an exciting time for those who prefer to travel by rail.

We don’t think you’ll be able to ride a gyro monorail, nuclear-powered, or jet train on these proposed routes, but we do hope that Amtrak and FRA are looking to the state-of-the-art when it comes to those high speed alignments. While you’re eagerly awaiting new passenger service, might we recommend this field guide to what all those different freight cars going by are for here in North America?

A warehouse with concrete floors and at least four subway car rails running off into the distance. On the rails are dozens of R142 series subway cars with refurbished trucks in the foreground. People are visible on the floor moving a truck, and one man is in a bright yellow crane above everything watching what happens.

Overhauling Subway Cars Is A Big Job

Subway cars have a tough life. Moving people through a city efficiently underground every day and night takes a toll on the hardware. To keep things running efficiently, NYC rebuilds its cars every six years.

The enormous job of refurbing a subway car back to factory spec happens in one of two yards, either in Brooklyn or Manhattan. The cars are pulled off their 16,000 lb trucks, and treated to an overhaul of their “doors, windows, signage, seats, floor tiles and HVAC.” The trucks are inspected and wheels can be reground to true at the six year mark; they get all new wheels every 12.

Once everything is repaired, the shiny and like-new components are inspected and reassembled to go back out on the line. While it’s no small job, the overhaul shops can process over 1,000 cars in a year to keep things running smoothly. Before the overhaul program was introduced in the 1980s, NYC subway cars typically experienced failures every 16,000 miles, but between the scheduled maintenance and other advances that number has soared to an average failure rate every 140,000 miles.

For a somewhat less official use of underground spaces, how about this Parisian secret society? If you really want to bring the subway home, how about making an old subway seat into a chair? If you need something more light-hearted, you should really checkout this 90s subway safety video from LA.

Continue reading “Overhauling Subway Cars Is A Big Job”

Hackaday Podcast Episode 250: Trains, RC Planes, And EEPROMS In Flames

This week in the Podcast, Elliot Williams is off at Chaos Communication Congress, hearing tales of incredible reverse engineering that got locomotives back up and running, while Al Williams is thinking over what happened in 2023. There’s a lot of “how things work” in this show, from data buoys to sewing machines to the simulated aging of ICs.

Whether you’re into stacking bricks, stacking Pi Picos, or stacking your 3D prints to make better use of precious bed space, this episode is for you. Enjoy.

This is your last chance to download a new podcast this year. Take it!

Continue reading “Hackaday Podcast Episode 250: Trains, RC Planes, And EEPROMS In Flames”

Polish Train Manufacturer Threatens Hackers Who Unbricked Their Trains

A week ago we covered the story of a Polish train manufacturer who was caught using software to brick their products after they had been repaired by in independent railway workshop. Now 404 Media has a follow-up story with more information, including the news that the hackers responsible for the discovery are now being threatened by the manufacturer.

The more we learn about this story the more interesting it becomes, as the Newag trains in question began failing after service as far back as 2021. In desperation after services were affected by the number of non-functional units, an employee searched online for Polish hackers and found a group called Dragon Sector. The group was able to find the issue, and are now being threatened with legal action by the manufacturer, who are citing possible safety issues.

It’s clear from where we are standing that Newag have been caught red-handed in some extremely dubious practices, and seem to have little sense of how their actions might not be the best in terms of protecting their reputation. We are guessing that the European regulators will become very interested in this case, and that meanwhile the order books of a company which puts DRM in its trains will start to look very empty indeed. You can catch our original coverage as the story broke, here.

Thanks [JohnU] for the tip.