Blog: Maritime Cyber Security
Stealing container ship cargo through LOC messaging
In a previous post post I looked at hacking and manipulating EDIFACT messages to destabilise a ship. However, criminals will be far more interested in using these techniques to re-route containers and steal their contents.
Similar techniques appear to have been used to steal containers in the past. There’s a really interesting legal case here between Glencore international and MSC Mediterranean Shipping around a case of two missing containers containing ~$1M of cobalt. Read section 70 onwards covering Ground 5 of the case.
At ~$200/kg, a forty foot equivalent (FEU) shipping container could hold >$500,000 of the metal cobalt involved in the above case, so very valuable cargo!
Here I’m going to look at the techniques that could have been used. Details in the legal judgement above indicate that a phishing scam was attempted first, which appears not to have been effective. Instead, it appears that physical network implant was then placed in an office, potentially allowing extraction of container release codes.
But what about hacking the back end messaging systems to achieve the same and more?
Interesting attacks could include:
- Sending a container with valuable goods to a rogue address
- Identifying containers with valuable cargo, so pirates can steal from whilst on board
- Shipping narcotics and obscuring their actual destination to avoid detection
- Releasing containers to the wrong (rogue) parties
This isn’t fanciful – targeted piracy has already happened using the same techniques. Several reports have been made where a ship is boarded by pirates, but instead of holding the ship to ransom, only contents of a few containers are taken. High value items, obviously.
I’m going to look at different EDIFACT message features that could be manipulated to achieve this. Read my earlier BAPLIE messaging blog for a primer.
EDIFACT is the messaging system that deals with who/what/where/when in relation to a container. Without EDIFACT, containers don’t move
Let’s say you want to identify a container with valuable cargo and re-route it somewhere
You’ll need to understand quite a few different message formats, but the whole process is easily automated:
COSTOR: for a packing or unpacking facility to stuff (pack) a shipping container with goods
COPARN: an order to release, to make available, to accept, to call down containers or to announce the impending arrival of containers
COREOR: to release import/export containers.
COARRI: discharge (unload) or load containers from a ship
CODECO: reporting containers arriving at or leaving a container terminal (‘gate in’ / ‘gate out’)
There are plenty of other messages that deal with other parts of the shipping process, such as MOVINS, but the interesting part of all the above messages is the LOC or ‘location’ segment.
If you can change this, you change where the container goes!
Changing cargo destination
The LOC location code is used in many places in EDIFACT messaging. Here’s the specification:
0200 LOC Place/location identification
A segment to identify a location or country related to the equipment, such as: – stowage cell – (final) place/port of discharge – transhipment place – place of delivery – country of origin/destination.
If you read a sample message, you’ll find LOC used for stating for example:
- The location of where a message was sent from (the physical office/factory address, not the EDI terminal address)
- A location where customs might be required
- Where a container was hired from and where it was off-hired
- Transport destinations for calculating freight charges.
- Place of registry, e.g. for the source of bank payments
For the purpose of theft, one might attempt the following:
- Send a COPRAR message to have the container discharged (offloaded) at the wrong port.
- Send a COPINO message to alert the container terminal that a land based carrier (truck!) will be arriving at a certain time to collect the container.
- Wait for the CODECO message from the terminal to state that the stolen container has left the port.
In each case, the LOC code can modified to suit the rogue destination. I believe the relevant codes in a COPRAR message are in segment 0270:
In the COPINO message, it’s likely to be segment 0120 that needs to be modified.
Although the entire message system is so complicated that you’ll need to inspect each message to be certain of the correct code to modify.
Finally, the shipping destination message may need to have its NAD (name and address) field modified also.
One factor authentication
In most larger ports, there is a system of PIN codes that the truck driver needs to present in order for the cargo to be released. This is often managed using a mobile app to which the truck driver has access.
This was the crux of the legal case above: somehow someone had accessed the PINs and had presented the correct one.
However, if not appropriately secured, any electronic system that deals with the release codes could be compromised.
Message brokers: a mitigating factor?
Many organisations in the transport sector have developed their own ‘flavours’ of EDI messaging. As a result, it can be very complex customising your EDI message to suit each 3rd party.
Hence, numerous message brokers exist who specialise in converting your message in to one that your clients systems can understand.
This offers a layer of complexity, but not necessarily a layer of security. The hacker is still just changing your message, which is then converted by the broker.
It does however make it more difficult to intercept and modify messages once they’ve been sent to the broker service.
I don’t often say this, but there may be a case in this scenario for implementing a blockchain on a small scale to deal with container release.
That offers assured release and may reduce data processing overhead. That said, a well written and secured database could achieve similar without the need for blockchain.
The Port of Antwerp is already trialling a blockchain based release system. I’m very interested to see whether it delivers the promised cost savings and assurance, also to see if it delivers more than a regular app could do.
Any user of EDI messaging for anything financial, maritime or not, should check that their systems are secured from message manipulation and related fraud through container theft.
Ensure that two factor authentication using a PIN or other shared secret is operating effectively. Make sure that those PINs can’t be intercepted using the very system you use to share them.
Don’t just assume that your systems are secure; turn your thought processes upside down: think how you could use your knowledge to misroute or steal goods. Bring in experts to help you make very sure it can’t be done.
Ports particularly should be on high alert for container theft, containers being used to transport illegal goods and manifests being intercepted by pirates.