The cloud computing skies have been somewhat stormy of late for Microsoft, which has found itself in the crosshairs of not only an attacker who abused authentication but also the firm Tenable, which pointed out that the cloud services giant has a general problem with authentication. A post by Microsoft and a write-up by Tenable both highlighted the issue of cloud authentication and illuminated some of its weaknesses.
In the Tenable post, Microsoft was taken to task for its lack of transparency in cloud security. As described by Tenable CEO Amit Yoran, the issue concerned “occurred as a result of insufficient access control to Azure Function hosts, which are launched as part of the creation and operation of custom connectors in Microsoft’s Power Platform (Power Apps, Power Automation).”
If you guessed at an Azure URL, you could obtain access even without authentication. As Yoran wrote, “It was therefore possible for an attacker who determined the hostname of the Azure Function associated with the custom connector to interact with the function, as defined by the custom connector code, without authentication. With one such hostname, an attacker could determine the hostnames for Azure Functions associated with other customers’ custom connectors, as they differed only by an integer.”
For its part, Microsoft indicated in a technical note that it had mitigated the Power Platform Custom Code information disclosure vulnerability and had notified affected customers about this issue via Microsoft 365 Admin Center (MC665159) starting on August 2023 — if you didn’t receive the notification, no action is required.
APIs are at the heart of the cloud security concerns
Application programming interfaces (API), which offer a service or connection between other pieces of software without requiring a human login, are at the center of the issue. With APIs, it’s often difficult to access the security until something happens.
Organizations often need to hire specialized consultants to review the software and ensure there are no obvious vulnerabilities. From open-source to proprietary software, unless it’s reviewed by specialists, vendor review alone is typically not good enough to find any issues.
The OWASP API security Top 10 lists the typical top issues that you should look for when dealing with APIs. Ranging from broken object-level authorization to the unsafe consumption of APIs, it points out that too often with APIs we simply trust their use too much. We also tend to rarely limit the use of APIs because we are offering a service that may be used by the wider public. If your use of APIs won’t be used by the wider public, consider using additional technologies currently in beta that may be able to additionally protect and defend.
IP Firewall helps to mitigate threats in real time
Some of these solutions, however, are not yet in widespread use and still are in public preview. A case in point is Microsoft’s IP Firewall solution currently in preview in Power Platform environments. As noted in the Microsoft documentation, it helps mitigate insider threats such as data exfiltration in real time. “A malicious user who tries to download data from Dataverse using a client tool, such as Excel or Power BI, is blocked from downloading the data based on the IP location.”
IP Firewall also helps stop token replay attacks from outside configured IP ranges. “If a user steals a token and tries to use it to access Dataverse from outside configured IP ranges, the access is denied by Dataverse in real time,” IP Firewall works for both interactive and non-interactive scenarios, is available for managed environments, and is supported for any Power Platform environment that includes Dataverse.
Look to the basics when dealing with API security issues
Often with APIs the security issues come down to the basics:
Permissions. Don’t overlook the basics of API permissions and don’t allow them to be too permissive on cloud services. As in user access, the basics of permissions can often lead to exposure or attacks. Limit the use of access to the minimum required.
Don’t overlook the basics of patching. Software of any kind needs to be updated and cloud implementations are no different. Ensure that you are aware of how newer software needs to be deployed: traditional patching techniques may work for some, but others may require redeployment. Review the options with your vendor.
Enable only what you need. For the purposes of limiting costs as well as access, only enable the features that are critical for your implementation. If you have enabled a feature and then later realize you don’t need it, ensure that you disable the settings.
Be vigilant about requests. Review incoming requests and log files and review for any discrepancies in how the requests are made.
Enforce secure transmission. Ensure the basics of secure transmission are followed, including that transport layer security (TLS) is enabled.
Monitor cache control. Security or cache control directives, instructions that control how browsers and other intermediaries cache and validate web resources, need to be set for clients.
Police your policies. Look for improperly set or missing policies for cross-origin resource sharing.
What are error messages communicating? Error messages should be reviewed for their potential to expose sensitive information.
Managing potential API vulnerabilities can prevent a host of concerns
Of course, APIs can also be vulnerable to what nearly everything else in technology is vulnerable to: weak passwords that can be abused. Thus, APIs need to be coded so they don’t allow for weak passwords and are not exposed to credential stuffing. Furthermore, weakly hashed passwords should be blocked.
You should review your application for all the authentication flows that may be used ranging from desktop applications to mobile to single-sign-on implementations. Set up a review schedule on a regular basis to ensure that you are reviewing various mechanisms. Ensure that if sensitive information is accessed that there is an additional authentication mandated. So access to changing account information should have a mandate of additional authentication.
Finally, ensure that you have implementation for two-factor authentication and keep reviewing how it is implemented. If you are merely offering SMS as a two-factor methodology, that’s not good enough for future needs. While any two-factor implementation is better than none, always keep an eye on improving authentication techniques.
That includes pushing your vendors to do better and provide you with more timely information. Clearly, Microsoft needs to do better — are the rest of your vendors also providing you with the information you need? My guess is that all need to do better.