The DHL Packstation is a great thing. Think of it as a vending machine. But instead of sweets and soda, this one dispenses precious DHL parcels. And instead of quarters and dimes it takes a swipe card and a one-time-password (“mTAN”) that comes via text message to your cell phone. Okay, a let’s call it a vending machine with multi-factor authentication. But, why is so much security necessary? Packstation sign-up requires the applicants to have their ID verified in a DHL shop which inconvenient and risky for criminals. As a result, criminals immediately profit from the compromise of already existing accounts as it allows them to receive parcels anonymously. This includes goods that were ordered through credit card fraud to anything the dark net has to offer such as firearms or drugs.
Packstation Authentication
A closer look at the swipe card reveals that the magstripe simply contains the account number (“Postnummer”) and this number is not a secret at all. It is more like a username encoded on a physical card. This number is well-known to the user as it must be provided as part of the postal address every time the user wants to receive a parcel through a Packstation. Cards with arbitrary account numbers can be created with any magstripe writer. In total, the swipe card is a pseudo first factor.
The Packstation account can be managed through a web interface. To do so, a password must be provided together with the account number. Alternatively, the email address attached to the account may be used instead of the account number. Therefore, Packstation account number/email address and password make up a perfect target for phishing and malware. To mitigate this fraudulent usage, “mTAN” was introduced. However, the mobile number used for “mTAN” may be modified through the web interface. An attacker with access to the account number and password may reset the mobile number to an attacker-controlled mobile number and is therefore able to retrieve the mTAN. The downside using this procedure is that the Packstation web application informs the old mobile number of the change and it sends a confirmation link to the email address registered with the account. Additionally, the attacker must obtain a SIM card anonymously.
Recent Transition in mTAN Security
On June 5, DHL announced that their mobile app is now capable of retrieving the mTAN as well. However, all the DHL mobile app expects for authentication is the account number together with the password of the web interface. Just by this high-level analysis, it becomes clear that the newly introduced “feature” renders the mTAN factor completely ineffective: Anyone who is in possession of the account number and password is capable to retrieve the mTAN. Access to the mobile number (or the email address) stored with DHL is not required anymore.
A bit of reversing and a couple LoC later I had cobbled together a Python script that interfaces the DHL mTAN API just as the regular app does:
$ ./mtan.py hanno.heinrichs@[...].de DummyPass17
{"mTan":"2342"}
Sweet. I just collected my own mTAN. Likewise, an attacker who compromised my online credentials would be in possession of all information that is needed to retrieve my parcel. Thanks to heise Security, DHL has been informed on these findings.
Thoughts on Mitigation and Hardening
In order for the mTAN delivery by app to act as a true second factor, simplest a shared secret could be used. Such a secret could be a QR code that comes via personal registered mail and is scanned by the app once. This would allow transferred mTANs to be encrypted for a particular installation of the app. Attackers without access to the shared secret would not be able to decrypt the mTAN. Additionally, the shared secret should be exempt from mobile phone backups that are stored within the cloud or on a local computer. Even if your Apple ID or your computer were compromised, chances would be increased that the shared secret remains a secret. The security of mTAN delivery by text message could be improved if a mobile number change required physical ID verification just as initial sign-up does.
To make Packstation account phishing (i.e. account number and web interface password) pointless in general, the magstripe of the swipe card should be seeded with random data which uniquely identifies a user (e.g. a token that is linked to the user’s account). That data must be unknown to the user (to prevent phishing attacks) and may not be accessible to attackers by means other than dumping the magstripe of the targeted user. Thus, the swipe card would be elevated from a pseudo-first-factor-username-on-a-plastic-card to a true first factor and attackers without access to the swipe card data of the legitimate user could not authenticate towards a physical Packstation — even if they managed to obtain the currently valid mTAN.
Comments are closed.