DPD package sniffing

TL;DR

An unauthenticated API call was identified in DPD Group’s public API that could allow a user with a valid package ID to, with some basic OSINT, discover the package’s destination postcode and thus obtain all details about the package.

DPD Group were prompt in the triage and resolution of the vulnerability, which was fixed in October 2021.

The vulnerability

As is common with parcel delivery systems, the DPD Group website uses a parcel code and a postcode to authorise whether a visitor is allowed to view details about the parcel and track its discovery.

The DPD Group API call to https://apis.track.dpdlocal.co.uk/v1/map/route when passed a parcel code returns a PNG image which shows an OpenStreetMap extract, with the recipient’s address highlighted.

For example, this call returned the pictured map: https://apis.track.dpdlocal.co.uk/v1/map/route?parcelCode=15505⬛⬛⬛⬛⬛⬛⬛⬛⬛*19609&size=1000*1000&themeEvent=none

It is possible to perform some simple OSINT on the image, using the street names and other identifying features to identify a postcode.

In the above example, a search of “Verney Road” in any mapping site returned a small number of streets with that name in the UK, manually checking each of these, only one had a “Queen Catherine Road” near it. This can be matched to the returned image to obtain a postcode.

Once a postcode has been obtained, this provided enough information to view details about the parcel. DPD Group uses a transparent reCAPTCHA token, so this was easiest to exploit by viewing the parcel in the browser.

This URL was visited and the discovered postcode was entered when prompted: https://track.dpdlocal.co.uk/parcels/15505⬛⬛⬛⬛⬛⬛⬛⬛⬛*19609

This returned the standard information page showing delivery information:

At this point a session token had been granted, which can be used to view the underlaying JSON, which includes a number of pieces of PII including contact and parcel details for the recipient:

There is clearly some personally identifiable information leaking here, which isn’t ideal.

DPD Group responded immediately asking for more information, which was provided once a public address could be identified. The vulnerability was fixed within one week. The disclosure experience was very positive, which made a refreshing change! Vendors: be like DPD, at least on the vulnerability disclosure side.

Although the PTP offices have been used in the example (as it is a public address), several different parcel codes were tested (with prior approval from the recipients) in multiple locations across the UK, all of which were successfully located.

DPD Group’s response

An email was sent to the address included in the security.txt file on DPD Group’s main website.

DPD Group responded immediately asking for more information, which was provided once a public address could be identified. The vulnerability was fixed within three weeks.

DPD Group offered a bug bounty, and also requested a delay in publishing until the new year. This was to ensure that 1) the vulnerability wasn’t being actively exploited and 2) to conduct a full review of the environment to make sure that this was not the only affected call. We were happy to do this in light of how easy they were to deal with.

Disclosure timeline

• 02 September 2021: Initial email to DPD Group
• 03 September 2021: Response from DPD Group asking for a Proof of Concept or guide
• 30 September 2021: Response returned
• 01 October 2021: Confirmation that the vulnerability is valid
• 06 October 2021: Confirmation that the vulnerability was resolved

Conclusion

Working with DPD Group on this disclosure was easy, clear, and unfettered by politics. They have a great vulnerability disclosure  program and fixed things fast. Seriously impressed.