Can a D.O.S attack "fix" a production issue?

Opinions expressed are solely my own and do not represent the views or opinions of my employer or clients.

For those unfamiliar with a D.O.S. (Denial of Service) attack, it is a type of cyberattack that makes a server unavailable to its clients. Typically executed by "botnets," such attacks can have significant financial and social repercussions.

You might wonder how an attack could "fix" a production issue. In this context, "fix" is used very loosely. It's more of a workaround.

Over the past 20 years, I have dedicated a substantial portion of my career to the EMV integration field. During this time, one of my previous employers secured a contract to upgrade Outdoor Payment Terminals (OPTs). As part of this project, we retained the OEM EMV terminal. Now that the terminal is obsolete and the brand no longer exists, I can discuss the details more freely.

The equipment was an HYPERCOM OEM terminal,

At the time, the equipment was already old and nearing the end of its life. However, since it was expensive (several thousand euros) and each dispenser required two, the equipment was used for as long as possible.

During the initial months of the refresh project, an issue was discovered: after a few days or X number of transactions, the terminal would malfunction and require a full power cycle to function again.

To fully frame the issue: one of the most critical peripherals in the field needed to be rebooted when it failed. The client's estate was extensive, with hundreds of sites using dozens of terminals each. There was no API available to initiate a reboot, and the power supply was also not programmable.

Various ideas were considered, including adding a TCP/IP relay in series with the power supply for remote power cycling. This solution was deemed unfeasible due to the high cost of new equipment and the even more problematic cost of rolling it out to the entire client estate. There was no budget for that.

At the time, the company that developed the EMV application indicated that the terminal model was at the end of its life and fixing the issue would be very complex and difficult. Moreover, any change to the application code would require at least a partial recertification by the acquirer.

An unorthodox approach was needed to address this problem. I began by opening the controller box (the black box on the right) and examining the boards. For security reasons, I will be vague. The CPU was weak, and the design seemed to be a natural progression from a previous model, with the addition of Ethernet probably being the "new feature."

Considering the size of the flash and RAM chips, I assumed the terminal used a very basic system, likely a bare-bones RTOS with TCP/IP support as an additional software module. This led me to wonder: in such software architectures, there is typically a periodic call to a function that updates the TCP/IP stack state machine and handles communication with the Ethernet PHY chip. Given the slow processor and limited RAM, what would happen if I sent a large ping request with a big payload? Even more... given the low CPU power and probably the higher priority of the task called updating the TCP/IP stack status...hummm.

After several attempts to determine the maximum payload size the terminal's TCP/IP stack could handle, I initiated a ping flood test. Within seconds, the terminal failed to return the ping packets and rebooted!!

Why did it reboot? I'm not entirely sure. Given the duration of the ping flood, the terminal was likely too overwhelmed to run other tasks, including the one that kicks the watchdog timer.

Nevertheless, this was exactly what we needed! After conducting additional tests to ensure the method was reproducible and robust, we had a way to remotely reboot the terminals.

By "remotely," I mean within the same Ethernet network, as doing so over the internet was not possible.

Thus, by using a D.O.S. attack (ping flood), the project succeeded and remained in production for many years until the next refresh.

For those who consider this a hack—and an inelegant one at that, which should never be used to solve an issue—my response is: welcome to the real world. ?

Under pressure, there are no ugly solutions, only successful or failed projects!