[AusNOG] Optus Hack

Scott Howard scott at doc.net.au
Tue Sep 27 16:10:56 AEST 2022


Official penalties helps make security top of mind, but realistically it
should already be there anyway.  Optus has to know (or have known) that
when something like this happens it has a serious impact on the companies
credibility and costs them serious money in lost customers/future business.

However the simply fact is that most companies likely have something
similar to this floating around somewhere on the website - no latter what
controls they have in place. Possibly not as big as this one, but whilst
ever humans are involved with the process, bug will exist. Serious effort
should be put into minimizing those bugs, limiting their impact, and
quickly detecting and fixing them, but odds are some will still get
through.  It's one of the classic cases where the development/security
process needs to get it right 100% of the time - 99.99% isn't good enough,
and perfection is hard to achieve.

I've got a bit of experience here.  As well as previously working for
companies that were involved in detecting/blocking attacks like this, over
the years I've found similar vulnerability in dozens of websites.  Only a
few weeks ago I found a similar vulnerability to the Optus one in the Dish
Networks/Boost Mobile (4th largest mobile provider in the US) - details
available here <https://blog.docbert.org/boost-mobile-vulnerability/>. In
that case it was an authorization issue rather than an authentication
issue, and the scope was less due to US providers not having the need to ID
customers as is required in Australia, but the fundamental issue is similar.

What seems to be the pervasive mentality is more akin to "it will never
> happen to us".
>

Exactly.  The correct mentality is that it WILL happen to you. If you're
lucky, the person that finds it will be on the side of right, and will
notify you and you can fix it with minimal impact.  But if the wrong person
finds it...


> I'd suggest in the wake of this whole mess, it might be a good idea to go
> have a talk to the relevant people inside your various businesses and start
> thinking about how to run tabletop exercises on what would happen should a
> breach occur, and how it might happen.
>

Not just should a breach occur, but multiple variations of what could
occur. If someone contacts you can let you know of a vulnerability, how
should you communicate with them. I've had too many companies simply fail
to talk to me when I'm trying to report an issue (the Dish/Boost one
mentioned above is a perfect example - to their credit we're now
communicating on multiple levels and they recognize the flaws in how they
handled it). If the notification is from a white-hat, do you have the
tools/logging in place to make sure that nobody else has accessed the same
vulnerability.  If it's a black-hat, can you tell what they access (if they
technically had access to 1 million records, but your logs show they only
accessed 3 then you're in a much better spot than if you don't know!)

Most importantly, have a path for people to report issues to you.  That
could be via a formalized bug bounty program (eg, BugCrowd, HackerOne), but
at a minimum a you need to have a path to reaches the right people quickly
and efficiently.

  Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ausnog.net/pipermail/ausnog/attachments/20220927/57aed203/attachment.htm>


More information about the AusNOG mailing list