Holes punched in hull of maritime security

Crappy IoT on the high seas: Holes punched in hull of maritime security:

Years-old security issues mostly stamped out in enterprise technology remain in maritime environments, leaving ships vulnerable to hacking, tracking and worse.

A demo at the Infosecurity Europe conference in London by Ken Munro and Iian Lewis of Pen Test Partners (PTP) demonstrated multiple methods to interrupt the shipping industry. Weak default passwords, failure to apply software updates and a lack of encryption enable a variety of attacks.

(Via The Register – Security)

Vulnerable ship systems: Many left exposed to hacking:

 

“Ship security is in its infancy – most of these types of issues were fixed years ago in mainstream IT systems,” Pen Test Partners’ Ken Munro says, and points out that the advent of always-on satellite connections has exposed shipping to hacking attacks.

 

 

(Via Help Net Security)

Maritime navigation hack has potential to wreak havoc in English channel:

 

As reported by the BBC, security researcher Ken Munro from Pen Test Partners has discovered that a ship navigation system called the Electronic Chart Display (Ecdis) can be compromised, potentially to disasterous effect.

 

Ecdis is a system commonly used in the shipping industry by crews to pinpoint their locations through GPS, to set directions, and as a replacement to pen-and-paper charts.

 

The system is also touted as a means to reduce the workload on navigators by automatically dealing with route planning, monitoring, and location updates.

 

However, Munro suggests that a vulnerability in the Ecdis navigation system could cause utter chaos in the English channel should threat actors choose to exploit it.

The vulnerability, when exploited, allows attackers to reconfigure the software to shift the recorded location of a ship’s GPS receiver by up to 300 meters.

 

 

(Via Latest Topic for ZDNet in security)

I’ve been talking with companies in this space about these types of issues. While Munro’s research is telling, this is not shocking.

It does very nicely illustrate the real values in good penetration testing: challenging assumptions, taking nothing for granted, and divorcing motive from threat.

For example, the 300 meter location discrepancy could have nothing to do with the shipping company or the ship itself. It could be used by a crypto mining concern looking to delay the arrival of new GPUs for a rival firm. This type of attack could be part of a larger series of attacks, subtile enough that further investigation would be unlikely (as opposed to the English Channel scenario in the ZDNet article), and could reap substantial benefits for the crypto mining concern.

I believe it to be a war of pretexts, a war in which the true motive is not distinctly avowed, but in which pretenses, after-thoughts, evasions and other methods are employed to put a case before the community which is not the true case.

DANIEL WEBSTER: Speech in Springfield, Mass., Sept. 29, 1847

Securing More Vulnerabilities By Patching Less — Dark Reading

As a penetration tester, Mauricio Velazco frequently looked for information on the latest attacks because corporate information systems were rarely patched against the exploitation of just-reported vulnerabilities.

When he moved over to the other side of the firewall, Velazco — now the head of threat intelligence and vulnerability management at The Blackstone Group, an investment firm — duly implemented a patching process for his company that attempted to keep up with its regulated responsibilities. It quickly became clear, however, that fixing vulnerabilities using the criticality of the bugs to prioritize patching kept the IT staff busy, but it did not make the company much safer.

Thinking back to his time as a penetration tester, Velazco realized that patching the vulnerabilities he chased as an attacker would be a much better use of his time. The strategy paid off: Compromises within the company fell, he says.

via Securing More Vulnerabilities By Patching Less — Dark Reading.

Hmm. This is, to me, a new take on patch management. It oddly falls in with a discussion I had almost two years ago, oddly in that my peers and I came up with the same concept for different but related reasons.

What do you think?