Security Architecture, Endpoint/Device Security, Endpoint/Device Security, IoT, Network Security, Security Strategy, Plan, Budget, Threat Management, Endpoint/Device Security, Endpoint/Device Security

Many TCP/IP stacks, used across bevy of IoT devices, found vulnerable to decades old attack

Nine major TCP/IP stacks are vulnerable to a decades old attack, and some have yet to be patched.

The so-called Mitnick attack capitalizes on an improperly generated random number, known as an initial sequence number, used to prevent collisions in TCP/IP connections. If hackers can guess the number, they can insert themselves as a man in the middle. It is called a Mitnick attack, because hacker Kevin Mitnick used the technique in 1994 before the TCP/IP started using random numbers.

Forescout tested 11 TCP/IP stacks used in IoT devices — seven open-source, four commercial — to see if any were still vulnerable to a Mitnick attack. They found that nine of the 11 did not properly randomize numbers.

The tested stacks are used across a bevy of internet of things devices, industrial equipment and other networked products.

The problem in part, said Daniel dos Santos, research manager at Forescout, is that developing a stack that can be used on IoT devices can limit the ability to create pseudo-random numbers.

"It's difficult to fix this kind of issue, because IoT devices are resource constrained and generating good, random numbers requires some computation," he said. "Developing for an embedded world, you don't know the architecture of the hardware. For some hardware it's more difficult to generate these numbers right."

Forescout found several stacks didn't use a pseudo-random number generator at all. Nut/Net used numbers from the system timer rather than a pseudo-random number generator. TexasInstruments' NDKTCPIP, uIP and FNET used the same numbers each time.

Others used the LCG number generator, which can be reverse engineered, seeded with predictable values. uC/TCP-IP and PicoTCP used the system timer. Cyclone TCP used a CRC value. Microchip's MPLAB used a static value. Siemens' Nucleus net used MAC addresses.

Six of the stacks have developed or are developing a software patch. CycloneTCP, NDKTCPIP, Nucleus, and MPLAB have all updated the most recent versions with more secure random number generation. Nut/Net is working on a patch. And Pico has removed the default number generator in the most recent version, having the user supply their own.

The other three do have a software patch. uC/TCP-IP is no longer supported and will not be updated (though Micrium, the successor project is not vulnerable to the attack). FNET updated its documentation to warn about potential issues with the default implementation and now suggest that users substitute in a more secure option. uIP did not respond to Forescout's disclosure.

For network defenders, mitigating a vulnerabile TCP/IP stack on a networked device might change based on the role the device plays, said dos Santos.

"Identifying devices is the basis of any sort of response — identifying devices in terms of identifying technical components, whether devices are vulnerable, and their role in the network," he said.

For example, dos Santos compared a farm with locally networked agricutural sensors and an office with vulnerable security cameras connected to the outside world. The former might not be a major priority, but ensuring the later has been secured would definately be.

Also, he noted, encryption would be an effective way to protect from evesdropping.

Forescout tested two stacks that were not vulnerable to the Mitnick attack, ARM's Nanostack and IwIP — one commercial and the other open source.

"We don't see like a correlation between being commercial or open source and being vulnerable," dos Santos said. "But there is a difference in the way that vendors or maintainers tend to respond to security issues if you're dealing with a bigger vendor of a stack, especially one that has a mature development lifecycle and security response team and so on."

Joe Uchill

Joe is a senior reporter at SC Weekly, focused on policy issues. He previously covered cybersecurity for Axios, The Hill and the Christian Science Monitor’s short-lived Passcode website.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.