Suggestions (in order of preference)

Do not run these terminals under “Local Administrator” accounts — this finding alone has the potential to open these terminals up to a myriad of other attacks/back-doors etc Disable the built-in administrator account, create a new account (eg PL-LocalAdmin) and add it to the Administrators group, only if required. Also easily achievable via Group Policy. Do not allow the locally logged in user to have SQL Login rights (ie, do not allow the logged in user of the terminal the ability to login the SQL Management Studio!) Use Group Policy/Login Scripts to heavily lock down the Windows UI / Start Menu for these terminals Review or create hardening guides for these terminals. Do some basic hardening before they are deployed. The 3 suggestions above would be a good start and are fairly easy to implement as part of an automated deployment. There is no way to report Security issues on the AusPost website, only email fraud etc. You should —

a — Setup a means to be able to report Security Incidents that go to the right team immediately for triage and investigation. This should be for all AusPost offerings.

b- Improve your incident handling processes internally. This should not have taken so long to make it into the correct department and have them contact me. Take Security issues seriously, despite multiple follow ups, I never even got to talk to someone technical to explain this until after I was about to give up and publish the article. Follow ups to support did not help for over a month.

Not reaching out to people who are trying to disclose things appropriately will win you no fans.

Disclosure Timeline

I was extremely dissapointed with AusPost’s handling of this issue, as you can see below, I had to continually chase them to recognise and action this incident. I’ve touched on ways I think they could fix this above.

17/10 /17— Date of incident

18/10 /17— Initial support ticket logged — included my personal email so they could reach out quickly if required.

20/10/17 —

“Hi David,

Thanks for taking the time to contact us about your concerns with our Parcel Lockers.

David, I have passed your email on the Parcel Locker Support Team, they will be in contact ASAP.”

24/10 /17— Follow up (support portal)

27/10/17–2nd Follow up (support portal)

30/10/17 — Phone call to support for an update, as I was still yet to actually speak to anyone or have the ticket updated at all. My goal was to speak to someone from the Parcel Locker, Security or Risk departments ASAP.

I was told — “Provide details to call centre to pass on” — I then provided a summary of the findings, was put on hold and then told — “Risk and compliance have been notified and will be in touch”

31/10 /17— This write up is largely complete and ready to be published

8/11/17-Follow up on Initial Support Ticket via support portal-

“Support, I am still waiting for someone to reach out to me on this issue to discuss.

My disclosure article is complete and waiting to be published. I am trying to do the right thing here but the lack of communication is making this very difficult.

Can someone advise me when I’ll hear from Risk & Compliance as advised on my follow up call on 30th October? Thanks.”

13/11 /17— Called support to chase up the status, as still yet to hear anything on phone/email/portal.

Was advised over the phone — “I have raised with my manager who I am emailing with the details so it can be sent to the correct department ASAP.”

Advised this article was complete and was trying to disclose this in the correct manner but was becoming frustrated at the lack of contact. Would follow up again via phone in 1 week if I hadn’t heard anything.

20/11 /17— Zero contact still, follow up via phone call to support

This time around, while the support person (who does not “work” for AusPost but passes along the info) said that “we are a large bureaucracy” “things take time”

While not confirmed, the discussion also seemed to indicate that they may outsource the operation of these Parcel Lockers, this would complicate things on their end, but isn’t an excuse to not deal with it the right way.

I ended the call stating that I’ve done everything in my power here to disclose responsibly, if no update before before November 30th, I will publish this article. I then updated this in the ticket so that they can view this write up (private draft link before publication) to hopefully get someone to reach out to discuss in more detail.

Frustrating experience…

21/11/17- I received an email update for my case -



Hi David

I Apologise in the delay to getting back to you.

I can confirm that I have escalated your case to the relevant teams and they will be in touch with you over then next few days.

22/11/17-

Finally, some solid progress, I spoke to a AusPost employee who works in escalated complaints, they advised me that this had “Come to their attention today”

“Sorry no one has called you prior”

They have since “Pulled out all the stops to understand why it hasn’t been addressed immediatley”

“Something has broken down in process. — IT/Security also not happy.”

“They are now looking at it.”

They believe that this is an “Isolated incident.”

Wanted to confirm the date of the incident, by looking at the pickup date of the item, we agreed this was the 17th of October 2017 — They confirmed date of incident. Date they have is 17th also. Indicating that potentially some logging or alerting evidence on their end?

I thanked them for finally contacting me with something concrete to work with. I then advised I will not publish the article until further notice. They advised me that “Our Media team are involved too” and that “I’m likely to hear from them too.” and that AusPost “Will contact me again soon.”

23/11/17 — More good news, Aus Post called and I spoke to Head of Collection Services who manages the parcel locker network.

Again, “Apologise and find out why took so long”

There are now “A few people now trying to rectify/investigate it”

“They cant replicate the issue”

And are “trying to get logs from the machine” to better understand why the start menu was exposed.

This is important — They don’t store the original perceived scope of PII on the lockers. They only store — Name, Parcel ID, Mob #. The ‘addresses’ table that I saw, while part of the DB, is blank. Client addresses are not stored on these devices.

All sensitive client info, is stored in “AusPost internal network”, minimal amount only required to pickup parcels are stored in Locker DBs.

This affected locker is part of an “older fleet” and that a “new locker vendor” has rolled out to new locations and will eventually “Update the whole platform”.

“They will take a few of my recommendations (1,2 and 3) and implement them.” Awesome, this was worth the effort, I’m actually making a difference here. /feelsgood

They re-iterate, they are “not taking the risk, will implement my first 3 recommendations” at minimum.

I re-iterate my recommendation to improve your Security Incident Repsonse. Agreement again, “Major Incident team has picked this up” to analyse further why it took so long.

I also receive an email from this contact, lines of communication with the correct contacts are now finally open. =]

11/12/17 — Case now “closed” on their end with the following update, key points are -

They couldn’t reproduce the Start Button visible issue, good news.

Are implementing some of the suggestions I passed along, also good.

Agreement that I can post this article in the New Year once reviewed by AusPost.

Final update and actions to be taken

9/1/18 — Article published after review and approval from AusPost

The views expressed on this blog are my own and do not reflect the views of my employer.