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.


A remote unauthenticated directory traversal vulnerability was identified affecting the exposed web interfaces of IND780 Advanced Weighing Terminal Operation Technology (OT) Systems.

This vulnerability could allow a remote unauthenticated adversary to access files on the affected system and perform further enumeration to identify the systems in use, which in turn could be abused to launch further attacks in future.

Affected Operation Technology (OT) System:

Mettler Toledo is a multinational manufacturer of scales and analytical instruments. According to their web description:

“It is the largest provider of weighing instruments for use in laboratory, industrial, and food retailing applications.”

The affected Operation Technology (OT) system identified was the Mettler Toledo’s IND780 Advanced Weighing Terminal. According to Mettler Toledo’s web description:

“The IND780 is a highly flexible terminal capable of supporting simple to complex, stand-alone to integrated weighing and control applications. A wide range of communications interfaces are available, including serial, Ethernet, USB and a variety of fieldbuses.”

IND780 Advanced Weighing Terminal
Figure 1: IND780 Advanced Weighing Terminal OT System

Vulnerability Details:

A remote, unauthenticated, directory traversal vulnerability was identified within the web interface used by IND780 Advanced Weighing Terminals. It was possible to traverse the folders of the affected host by providing a traversal path to the ‘webpage’ parameter as shown on the example below:


Following Google search dorks reveal multiple OT instances that are accessible over the internet that appear vulnerable to this issue.

  • “excalweb.dll”
  • inurl:excalweb.dll

The following screenshot displays a proof-of-concept example of this vulnerability on one of the affected OT hosts:

Figure 2: Proof-of-Concept Directory Traversal on an Affected IND780 OT System

Affected OT Systems:

This vulnerability was originally identified via the web interfaces used by the following versions of IND780 Advanced Weighing Terminals:

  •  IND780 Advanced Weighing Terminal (Build 8.0.07 March 19, 2018) (SS Label “IND780_8.0.07”)
Figure 3: IND780 (Build 8.0.07 March 19, 2018)
  • IND780 Advanced Weighing Terminal (Version 7.2.10  June 18, 2012) (SS Label ‘IND780_7.2.10’)
Figure 4: IND780 (Version 7.2.10  June 18, 2012)

However, given the evidence it is quite possible that other versions of IND780 Advanced Weighing Terminals could also be affected by this vulnerability.

Possible Impact:

This vulnerability could allow a remote unauthenticated adversary to access files on the affected system. This could also allow the adversary to perform further enumeration against the affected host to identify the versions of the systems in use, to launch further attacks in future.

Remediation Suggestions:

  • Perform input validation of the ‘webpage’ parameter shown on the vulnerable URL highlighted above. The input validation should deny any path traversal attempts and serve files from a whitelisted folder location such as the current folder where accessible files should be stored.
  • Check for the same vulnerability in other versions (including previous) of the web interfaces used by the Advanced Weighing Terminals OT devices. Use the above remediation option for any similarly web interfaces on affected OT devices.

CVE Assignment:

This vulnerability has now been reserved the CVE ID of: CVE-2021-40661.

Update 31/10/2022 – CVE-2021-40661 has now been officially accepted and listed by MITRE and NIST: