Recent cybersecurity incidents involving The Iconic, an Australian online fashion and sports retailer, and Inspiring Vacations, a Melbourne-based travel agency, have brought to light crucial cybersecurity lessons. These cases emphasize the importance of regular security assessments and robust cyber defenses.

The Iconic’s Account Fraud:

1. Two-Factor Authentication (2FA) is Crucial:

   – Customers reported unauthorized access and purchases, highlighting the necessity of 2FA.

   – Example: A customer’s account was used to make a $700 purchase without authorization.

2. Rapid Response and Customer Support:

   – The Iconic’s commitment to refunding affected customers demonstrates the importance of quick response mechanisms.

3. Regular Password Changes:

   – The company’s advice to regularly change passwords underscores a basic yet vital security practice.

4. Vigilance Against Increased Fraudulent Activity:

   – The noted increase in fraudulent login attempts serves as a reminder for continuous monitoring.

Inspiring Vacations Data Breach:

1. Database Security and Configuration:

   – The breach, caused by misconfigured cloud storage, exposed over 112,000 personal records, illustrating the criticality of proper database security.

2. Potential Consequences of Data Exposure:

   – The exposure of sensitive data, such as passport details, can lead to severe issues like identity theft.

3. Legal Compliance and Reporting:

   – Compliance with legal obligations, such as reporting breaches, is essential.

General Lessons and Recommendations:

1. Implement Robust Cybersecurity Measures:

   – Use comprehensive security tools, including firewalls and intrusion detection systems.

2. Educate Employees and Customers:

   – Regular training and awareness campaigns are key to reducing breach risks.

3. Regular Security Assessments:

   – Proactive vulnerability assessments can prevent potential breaches.

4. Plan for Incident Response:

   – An effective incident response plan is critical for quick recovery.

5. Stay Informed About Latest Threats:

   – Keeping abreast of new cyber threats helps in preemptive defense.


The incidents at The Iconic and Inspiring Vacations highlight the relentless nature of cyber threats in the digital age. Businesses must prioritize regular security assessments, comprehensive cybersecurity strategies, and ongoing education to safeguard against these risks.

If you would like to know how SidSecure can help assess the digital security of your assets, then please get in touch with us today.

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: