ER is a powerful tool with access to most AOT objects, making it theoretically unsafe if the origin of the ER is unknown. Data transformation, along with data insertion or retrieval from the database, occurs in the mapping, potentially making it the most dangerous node. Additionally, because a mapping can be directly created within the model, the model itself is equally unsafe. However, the format also permits the use of AOT objects. While data insertion into the database through the ER Format is restricted, and not all methods can be used—for example, those that return void—it remains potentially unsafe.
I wanted to answer the following question: If an unknown and malicious party were to share an ER XML format on a D365FO community or a social network, for example, a new tax return, a bank statement import, or simply a well-designed invoice format, could they steal data from the company?
Before addressing that question, it’s important to issue a warning: I’m not going to share any malicious code, both out of etiquette and to avoid problems. Furthermore, I haven’t discovered any vulnerability; if that were the case, I would report it to Microsoft instead of writing about it.
In my own server, I created a simple GET API, which utilizes the same protocol we use to browse websites. When this API is called, either from a web browser, Postman, or any other program, a file in a subfolder is created containing the content of the parameters. For example, accessing www.test.kz/api.php?param=THISDATA results in the creation of a file with ‘THISDATA‘ as its content (bad practices are totally acceptable when hacking).
Then, I created an ER format that, upon execution, utilizes AOT objects to read info from the database and send the data from my Contoso environment (containing dummy data) to the API I control. In this example, it sends only the ID of the first customer listed in the CustTable.
While this example is quite simple, it proves that data can be sent to third parties with virtually no limitations.
Protecting Your Organization
I would start by limiting access to the ER workspace via security roles to only those users who truly need it and are security-aware.
From there, I would treat any ER XML file as I would any piece of code that doesn’t come from inside the organization or a trustworthy third party; it must be thoroughly read and understood before use. For ER, this means meticulously reviewing each line of the XML. Importing it into a sandbox environment wouldn’t be advisable, as malicious code can be concealed and might be virtually impossible to detect via the UI. Moreover, the provider configuration can be disregarded because it’s easy to modify an XML to make it appear as if it’s from Microsoft or another reputable source.
If you already have an ER format whose origin you cannot verify, I recommend immediately ceasing its use and verifying its safety by exporting the XML and examining each line.
Disclaimer: All information, examples, and analyses presented in this publication are based solely on my personal research and experiments conducted in a controlled, private environment. They do not reflect the practices, policies, or positions of my employer or any associated entities. This content is provided for informational purposes only, with the intention of enhancing understanding and awareness around security practices and is not intended for malicious use.
Leave a Reply