Sinking container ships by hacking load plan software
pentestpartners.com
pentestpartners.com
Currently we are expanding one of our products for a large container ship owner so we can import these loading condition files into the product for both long-term analysis and also short-term alerting. Once this project is complete, a fleet superintendent will be able to set up alerts so that they get a push notification when we calculate that a load is risky or unbalanced. Hopefully this sort of thing will add an extra layer of validation before a ship sails from port.
Fortunately, for our customer, they build quite robust ships and do not skimp on cost. But due to the economics of shipping right now, a number of owners in the world cut costs wherever they can. This includes reducing the amount of steel used in critical support beams which could increase the risk of a vessel breaking in half [1]. Sadly this makes a hack like this even more risky, because the combination of marginal errors, bad weather and a frail ship could be more than enough to cause a big problem.
I have seen a picture of broken bulk carrier in the Rotterdam harbor when loadmaster made an error.
http://www.iefimerida.gr/news/229327/nayagio-toy-eurobulker-...
“The little boat flipped over.”
https://getyarn.io/yarn-clip/552a53c2-894a-4b79-bcf1-e9eadfb...
Pentest companies like to put up bogeymen to scare people into using their services.
The article also talks about more subtle things like changing the position of containers; wouldn't cause safety issues, would be hard to detect (gotta trust the software), but would cause delays and (by extension) costs.
The article talks about USB/floppy disks and suggests they are 1) used 2) insecure 3) easily can be attacked. This without ever explaining how. They also suggest that the someone on the vessel themselves creates this stowage plan. This is utterly strange. Stowage plans aren't normally made by people on the vessel for the companies I know.
Loads of details in this article make no sense at all. That said, container shipping should be hugely improved is true :-P The main bit is true as well: if you mess up the stowage plan you'd easily cause a lot of damage: yeah. Plus there's probably enough ways to do this.
PS: It's not a CSV file.
These systems aren't cheap and it requires more skill closer to IT than your typical stevedore. So it can take years to recoup any savings in labor. Recouping time costs are almost immediate.
[0] http://www.konecranes.com/equipment/container-handling-equip...
The same acceleration rates can be used for the automated clamps which lock onto the corners of the containers for movement.
Assuming a dockside + ship is 100 yards wide, a one second lock/unlock time for clamps, that should work out at 14 seconds per container. Assume we have a grid of cranes over the ship, able to pick up every container on top at once.
Assume the worst-case complete unload of the whole ships capacity (10,000 40 ft containers on the largest vessels), and reload of another complete load.
That comes out as 8 minutes!
Current loading times are multiple hours for even a partial unload of a much smaller ship. That tells me that there isn't enough $$$ involved to get serious engineering efforts to make it quicker.
That's not true at all. The container ships are getting bigger, but port productivity hasn't kept up at all. You can put more cranes on the vessel if it's longer, but lately it's often getting wider, not longer (=which would allow additional cranes to be used).
Containers ships are often in a port for a really long time, can be days.
That said, containers toppling over has happened in the past, including capsized feeders (small container vessels).
Example 1: http://maritimeaccident.org/2010/01/husky-racer-toppled-boxe...
Example 2: http://shipsmonthly.com/news/ship-accident-container-ship-ca... (they noticed a problem, tried to prevent it from capsizing, it took 2 days and still capsized!)
Often the cause is not hackers, just wrong data given by shippers. Basically saying that a container is heavy while it is light weight and vice versa. That's why every container loaded now needs their weight to be certified. http://www.imo.org/en/MediaCentre/HotTopics/container/Pages/...
Interestingly enough, up to that new requirement loads of containers could get on a container vessel without ever really knowing what their real weight was.
> The MAIB preliminary examination of the accident found that the inaccurate container weights were on the loading plan because of a system shortcoming which did not update the operations department when the shipper provided more accurate contents details to the carrier.
> The Deputy Chief Inspector of Marine Accidents has written to Maersk Line advising that its operations department should use the most accurate container weights and ship stability data available. [1]
[1] https://www.gov.uk/maib-reports/collapse-of-containers-on-co...
Not at all. It's better to ignore that bit out of the article.
You actually have loads of parties giving a weight of a container. E.g. when the booking is made, then when they give the shipping instructions, then later maybe from a trucker when it's delivered to the terminal, lastly possibly given by the terminal itself (though most don't have it).
What might have occurred that instead of having a sane design whereby you just update a weight of a container it works by having multiple different fields for these things. This as not always you can trust some input. E.g. weight given by a trucker in Germany might be ok, but it might be utter xxx in another country.
I find it interesting that it was just an advice though. I'd prefer if they would have more ability to force changes and also across companies.
However, the loading crew might not even notice a modest list. The EL FARO, while loading before its fatal trip into a hurricane, had a bit of a list. The loading crew didn’t notice, but someone else at the port took a photo[1], emailed it to the relevant people, and got it fixed.
[1] http://3kbo302xo3lg2i1rj8450xje.wpengine.netdna-cdn.com/wp-c...
Plus there must be a checklist when departing, ship balance info, etc.
It can be detected with empirical tests however. Almost every ship should right itself from a roll within ten seconds or so, so anyone with a stopwatch can detect misloading. There are monitors that measure this continuously as well.
At one point I was thinking of making a phone app for this, so that ferry passengers could check stability themselves.
https://en.wikipedia.org/wiki/Metacentric_height#GM_and_roll...
Also, there's random motion that may look like roll when it's the sea surface that's showing the motion, so there are methods to filter that out and extract the actual rolling period.
Given the height, width and depth of every product and the package dimensions available?
> A team assigned to investigate the problem discovered an astounding number of errors. Product dimensions would be in inches, not centimetres or entered in the wrong order: width by height by length, instead of, say, length by width by height. Sometimes the wrong currency was used. Item descriptions were vague. Important information was missing. There were myriad typos. “You name it, it was wrong,” says a former employee. “It was a disaster.”
> Getting the details from suppliers largely fell on the young merchandising assistants. In the industry, information from vendors is notoriously unreliable, but merchandising assistants were often not experienced enough to challenge vendors on the accuracy of the product information they provided.
> The investigative team estimated information in the system was accurate about 30% of the time.
[0] Source: http://www.macleans.ca/economy/business/what-really-happened...
Better understanding of the nature of data -> better data -> more useful systems -> better business decisions -> better business performance. I see too many people get frustrated and make poor decisions because they are unable to comprehend the nature of data. Productivity would soar if people understood how to model and take care of data. It's only one aspect of a complex issue, of course. Good UI, system uptime reliability, and so many other things also matter for whether an organization gets everything it really needs from a system.
But the problem described is closer to two- or three-dimensional bin packing (or scheduling in general) than to the knapsack problem. See eg http://www.research.ibm.com/people/n/nikhil/papers/Bansal-pa...
Another thing to look at is the "Cutting stock" problem (https://en.wikipedia.org/wiki/Cutting_stock_problem).
1. https://www.candyjapan.com/behind-the-scenes/algorithmic-fit... 2. https://github.com/hudora/pyShipping/blob/master/pyshipping/...
(disclosure: I work for that company)
I spoke to a specialist developer that had been in the game longer than myself and she said 'nope, it can't be done that easily in real world situations' and proceeded to go all computer-science on me. If you are in ecommerce you might know of Karen from WebShopApps. If anyone can get you a best solution it is her team.
Filling the ships up is done with heavy consultation from the ships captain and often isn't as obvious and simple as one (layman) might expect.
Hacking the process is definitely a concern. something we care about quite seriously.