Remember Dieselgate, the scandal where certain diesel vehicles would detect an emissions test, and run cleaner for it, “cheating” the test? Traingate may just put that one into perspective. We’ll tell the story from the beginning, but buckle up for a wild and astonishing ride. It all starts with Polish trains getting a maintenance overhaul. These trains were built by Newag, who bid on the maintenance contract, but the contract was won by another company, SPS. This sort of overhaul involves breaking each train into its components, inspecting, lubricating, etc, and putting it all back together again. The first train went through this process, was fully reassembled, and then refused to move. After exhausting all of the conventional troubleshooting measures, SPS brought in the hackers.

Dragon Sector is a Polish research group, who gained some worldwide attention for work on Toshiba laptop BIOS security. And it turns out that these were the perfect group for the job. From cobbling together hardware to improving Ghidra’s support for Infineon TriCore architecture, there was a lot of work done to even get a toehold into the train’s systems. But finally they could do memory dumps, and compare the broken train with working ones. There was a set of configuration flags that seemed to hold the key. But this particular train was badly needed in service. So Newag, the original manufacturer, was finally contacted to complete the maintenance and get the train running again. Hackers are nothing, however, if not persistent. After pulling an all-nighter, and with literal minutes to spare, Dragon Sector was able to overwrite the memory of the broken train with a valid configuration, and it once again came to life.

So far, nothing here seems suspicious. Startup checks after maintenance could easily go awry, leading to this sort of situation. But Dragon Sector kept digging, refining their tools, and teasing more secrets out of the train firmware. And what they found was astonishing. Up first was GPS coordinates, corresponding to every train yard in Poland capable of doing this sort of maintenance overhaul. If a train was parked inside any maintenance yard but Newag’s for over 10 days, the flag would trigger and the train would be disabled. It’s hard to see that “feature” as anything but a blatant attempt to brick any train that didn’t come back to Newag for maintenance. But wait, there’s more.

Replacing certain components would lead to similar breakage, until an undocumented cheat code was tapped in to the main computer console on the train. In another case, a train would break after hitting a million kilometers. Yet another train was scheduled to break down with a bad compressor on a given date — and a programming error delayed that breakdown until a year later. All told, Dragon Sector looked at 29 trains across Poland, and found these wonderful little surprises in 24 of them. Through Poland’s CERT Polska, law enforcement agencies have been notified about this case.

In response, Newag has accused Dragon Sector of slander and computer crimes, as well as being threats to railway safety. All we can say is that we hope a thorough investigation will establish the truth of the case, and hold the true criminals to account.

It’s Always DNS

Ever wondered how a DNS server gets updates about DNS names? It turns out there are a couple ways. One is for clients to send updates directly, advertising their DNS name and IP address. DNS Dynamic updates are supported in multiple DNS servers, including Active Directory (AD), and in pretty much every implementation this has a reasonable security implementation. On the other hand, there is also DNS updates sent as part of a DHCP request. And those… have problems.

This write-up is very Active Directory focused, but it wouldn’t surprise us to find a similar problem in other DHCP servers. Namely, the DNS update isn’t authenticated. Any device that is given an IP address can request a DNS name at the same time. The way this works in a Microsoft server environment is the DNS service uses its own credentials to forward the DNS update to the DNS server. If those are two separate servers, and the name is already registered directly by another host, the update will fail. But an unclaimed name, or even the DHCP server’s name itself are up for grabs. And in the case of the DNS and DHCP services running on the same server, pretty much any DNS name is in play. And in an AD environment, that allows for all sorts of further attacks on authentication.

These issues have been reported to Microsoft, who consider them to be known issues, not quite worthy of a security fix. They are worth knowing about when building an AD network. To help keep us out of trouble, Akamai has written Invoke-DHCPCheckup as a powershell tool to check for issues.

Do the JMP Slide

There’s a technique used when writing exploits, the NOP slide. It’s a series of No Operation commands followed by the target shellcode. The idea is that a vulnerability will jump somewhere into this attacker-controlled memory area, but the exact destination can vary. This is used so often that blocks of 0x90 in data is one of the tells that it may be malicious. there is a problem with the NOP slide, in that it can take longer than you want to make it through all the NOP instructions to get to the juicy shellcode. And that’s where the JMP slide comes into play.

The basis is that we know how many bytes are left in the slide, so we can use JMP instructions to go right to the payload. That’s great, except for alignment. Namely, the x86 machine code freely mixes instructions and arguments. If you don’t know exactly where instruction will land in your buffer, how do you know if you’re about to execute a jmp, or execute the offset as an instruction? There are a couple obvious ways to approach this, like using 0x90 values as argument to JMP, followed by a much smaller NOP slide zone to catch the JMP.

That one is a bit of a challenge, too, because the JMP command is based on offsets that can be positive or negative, and 0x90 happens to be a negative offset. That can work, but the entire shellcode payload has to be constructed backwards to manage it. There is one other option, the conditional jump JCC opcodes. These are 0x70-0x7F in machine code, which manages to be positive offsets. The only problem there is that these jumps are conditional upon a register value, which is unknown. The final solution is to use the Jump if Greater opcode twice, followed by the Jump if Less or Equal opcode twice. Both are positive offsets, and both make steady progress though the JMP slide to eventually land in a small NOP slide to finally run shellcode. Clever!

Bits and Bytes

After getting fired, it may be tempting to burn your bridges on the way out. If that includes wiping code repositories, deleting log files, taking home proprietary code, stealing a work laptop, and impersonating colleagues… maybe don’t. A software engineer from First Republic Bank just couldn’t resist the temptation, and will serve two years in prison, three years of probation, and pay $529,000 in restitution for damages. Definitely not worth it.

And for a stark reminder why not everything needs to be connected to the network or Internet, see the fallout from a cyberattack on Kyivstar in Ukraine. This phone and Internet provider was taken down on Tuesday, in what appears to be a devastating data wiping attack. Banks and stores are closed due to payment processing being down, and at least one city had to manually disconnect their street lights from the power grid, because the software controller was disabled as a byproduct of the attack. Maybe the old mechanical timers were better after all.