Optus API Hack
By now the Optus data breach via a vulnerable API (Application Programming Interface) is a widely known topic, across Australia as well as abroad. In cyber security it at times appear far convenient to point the blame, which seems natural human nature and perhaps a way of coping.
However, as security professionals it’s our duty to have a view that can benefit everyone in the long run. Understanding the important security lessons to be learned from possible mistakes that were made, is an important stage of this process. This helps us shift our mindset from “who’s to blame?” to a possibly far more useful “what practical lessons can we learn from this for future?”.
With this in mind, SidSecure cyber security professionals are always in the lookout to understand how we can serve our clients and the Australian security industry better. If the adversaries are ready to up their antics, then as security professionals, we should definitely do at least the same and more. This could mean refining our current views and approaches to security.
The Optus hack is a good example of the security threats to API interfaces. In the case of the affected API endpoint, several security misconfigurations become clear:
1. The API endpoint appears to have been using shadow-IT systems
2. The API endpoint was not implementing proper authentication or authorisation checks
3. A test API endpoint was public facing and using real customer data sets
What’s a better approach to implementing API interfaces?
Ensure the API interface is available to a whitelisted set of sources during the dev/test/UAT phases
This means the API during its development and test stages (prior to public release) should have limited inbound access. If possible, the API endpoints should be restricted to internal networks, and if public access is required, it should be restricted to a whitelisted set of IP addresses via Firewall rules & ACL (Access Control List) controls. Public release should go through change control to ensure proper testing including security penetration testing has been carried out prior to release.
Only use company authorised systems to host test environments and data
Developers are naturally given a lot of freedom. Perhaps, educating developers about the looming security threats with example from the recent hacking attacks, is as important as having policies around how to host test environments. We believe that if the people who have authority to handle such systems and data, which includes developers, are not properly motivated for the requirement for security, they will always try and find ways to work around security controls.
Be extremely careful when handling customer data
There are a lot of ways in which test-data can be generated for development and test activities. However, it is understandable that developers wanting to work with “real” customer data to ensure the systems they are developing can handle their flows correctly. Therefore, a better approach could be to use a subset of scrubbed customer data (where personal information is updated to random values, e.g. date of birth replaced with a random, but valid date) during testing. When the system is finally ready to fully test with customer data, any system that handles (stores, processes and transmits) customer data should be considered equivalent to production systems in security requirements, and should enforce proper security controls (including white listed access) when they are deployed.
API Security testing is one of the common types penetration testing activities carried out by our SidSecure team. When performing API security assessments, in non-production-ready environments (such as dev/UAT environments), SidSecure specifically request whitelisted (or similarly controlled) access to the API interfaces to ensure that we get to test them thoroughly and provide correct security feedback, BEFORE they are exposed to the wider public.
If you are a company that can benefit from our expertise in API testing, then please get in touch with us today.