How Secure are Plugins from the Autodesk App Store?
We All Use Revit Plugins
Plugins, the spice of life in the Revit/CAD world! These little nuggets of digital genius promise to turn mundane tasks into a walk in the park or even a dance in a disco! But remember our eye-opening blog post about Dynamo nodes security? As a continuation of that post, today we’re diving into the shady alleys and dimly lit corners of security plugin use. We’re not just here to make you afraid but to ensure you can work very securely. So grab your Revit add-ins, and let’s get started!
First Things First
To explain what a malicious Revit plugin can cause, we need to take a real example. For this, we have chosen a plugin that the company Mugatu Inc., created by Jacobim Mugatu (yes, crazy Zoolander fan, it seems the lousy guy earns his days as a Revit API developer).
If you download Quick Finder, you can enjoy an add-in that searches any element in the current view by its Family name and Type.
But underneath the hood, it takes all kinds of information from the user’s computer. A lot of fun stuff, like IP address, MAC, address, Chrome history, Temp Files, programs installed in your computer, and looks for pictures with specific names (Ehem…)
A construction technology solution may be ideal if it can improve efficiency, scalability, accuracy or provide other tangible benefits. At times, conducting a feasibility study or pilot project can be beneficial to evaluate potential success.
This Can Happen to You
So the first question, besides how Mr Mugatu learned how to code, is, how did a malicious add-in like this end up on the Autodesk app store?
- First, when you upload a file, Autodesk makes you sign that there will not be malicious actions against users. Someone could lie and do it anyway.
- Secondly, you need to clarify what type of data you are taking from the user’s computer, but then again, a developer could lie.
- Thirdly, Autodesk could check what data is coming from the user’s computer, but any developer could encrypt it, and then it would be almost impossible to read. From what they know, it could be internal metrics or part of the normal process of the add-in.
A file encrypted with RSA 3072 could take years or centuries to be decrypted with the current commercial computer power available. However, let’s say Autodesk owned a quantum computer to decrypt the obtained data. In that case, a developer could add a timestamp that starts stealing the user’s data after the add-in is successfully published on the Autodesk App Store.
It Is Not the Autodesk App Store Fault
We know that only a few actions can be taken from the Autodesk App Store because this is a problem with how Windows was developed. Windows should work like Android / iOS, which works with scopes and virtual machines, confining applications to the minimal permissions to execute, protecting the user from exposure. So, these operative systems ask you for permission whenever someone tries to get sensitive data from your computer. For example, if you are installing a new add-in and it tries to access, let’s say, your IP, you should get the message that this program is trying to access your location, asking if you’ll allow it.
This Is Just a Dummy
So, can Mr. Mugatu be sued for stealing users’ data? Not really.
Let’s explain what he did. First, he added an endpoint that will only steal data from a user’s computer if the Mac address from the user’s computer is the same hardcoded on the endpoint, so the only way to steal data is if the user gives the MAC address to Mr. Mugatu. Also, a True and False value was added to the code to turn on and off this feature after it was published.
This is how the Lambda code looks:
import json
def lambda_handler(event, context):
return {
"statusCode": 200,
"body": json.dumps({
"message": True,
"mac":"721AB8AF82DB"
})
}
Also, on the add-in, the validation looks something like this:
using (HttpClient client = new HttpClient())
{
try
{
// Making a GET request to the specified URI
HttpResponseMessage response = await client.GetAsync("https://LambdaEndpoint/");
// Ensure we get a successful response back
response.EnsureSuccessStatusCode();
// Read and output the content as a string
string content = await response.Content.ReadAsStringAsync();
// Parse the top-level object
JObject topLevelObject = JObject.Parse(content);
int statusCode = topLevelObject.Value<int>("statusCode");
string body = topLevelObject.Value<string>("body");
// Parse the nested object within the 'body' field
JObject nestedObject = JObject.Parse(body);
bool message = nestedObject.Value<bool>("message");
string macAdd = nestedObject.Value<string>("mac");
if (message & macAdd == macAddress)
{
await getUsersData();
}
}
catch (HttpRequestException e)
{
// Handle any errors that occur during the request
Console.WriteLine($"Request error: {e.Message}");
}
}
Someone could argue that Mr. Mugatu lied and infringed the policies of the Autodesk App Store, but he never used this on any user unaware of it. It was only during the testing phase never to steal information on users who downloaded the app, and it will never be. So please be a good boy and be like Mr. Mugatu, don’t cause harm to others or infringe the Autodesk App Store policy.
What Can Be Improved Around Plugins?
I guess one suggestion to the store would be to enforce developers that are going to get data from the user`s computer to provide an endpoint where they show the users all the historical data they have taken from them, like some sites that allow you get what Google or Facebook knows about you.
This will not guarantee that some bad people can steal data without letting you know, but it will add more transparency to the game. Sometimes, it is hard to understand what data a platform is taking out of your computer only by reading long pages written by some lawyer in a complex language.
A good practice that Apple does when you are about to develop an app is ask for some sort of identification, that way no one can publish an app on the store anonymously.
There should also be a rating of the users, not only of the apps. That way, people can check the reputation of the developers. Again, exactly like Android does, by doing this, you can get more info if this is a well-trusted developer, with comments, reviews, etc., or some anonymous developer with no credentials that can validate his work.
Ask Questions
I like the analogy of app policies compared to nutritional facts and ingredient lists on food products. Just as most people wouldn’t willingly consume unhealthy food, they also don’t want to compromise their data. However, just like a few people meticulously examine nutrition labels, only a few scrutinize the policies of every app they install.
Reading through ingredients or app policies can be a time-consuming task. For example, I was surprised to learn that the commonly used red colorant, Red Dye 40, is derived from petroleum. It makes you think twice before indulging in snacks like Doritos or M&Ms. Dissecting a privacy policy can be daunting. It’s not just about reading the text but also about understanding each clause’s implications. Nonetheless, it’s a task that at least one person in a company should undertake to ensure that the apps being used meet security and privacy standards.
You can even go beyond the app policies and check if an app takes information from your computer by checking uncommon WAN connections, using software like Glasswire to track outgoing calls. Most likely, you will not be able to see what data is going out, but at least you can contact the developer to provide some answers.
What Else Can I Do to Make Sure Nothing Happens to You
- Don’t run add-ins on admin users
- Freeze your computer using a program like Deep Freeze so any malicious or accidental change will be reversed upon restarting.
- Don’t save any value on your computer. Use key/password managers.
- Only download signed DLLs. It doesn’t guarantee anything, but at least it is something.
- Search who the developer is and make sure it is a responsible company/human being.
And if you find a plugin doing this kind of harm, we would love to know so we can help take countermeasures!
Do Not Fear. We Still Need to Have Faith in Most People
In conclusion, Revit, AutoCAD, and Navisworks plugins aren’t the enemy; they’re essential allies in our quest for smoother workflows and unparalleled project execution. However, it’s crucial to remember that, much like any tool, they’re only as safe as the hands that wield them.
While most developers and users in our community are knights in shining armor, looking to elevate the industry, a few outliers and digital miscreants revel in chaos.
The aim of this post wasn’t to instill fear but to arm you with the necessary know-how to protect your digital kingdom. After all, the best way to enjoy the vibrant tapestry of plugin possibilities is to walk through it with both eyes open, fully aware but not paralyzed by potential risks.
So go forth, fearless architects and engineers, and build those digital empires—but build them securely because the world is overwhelmingly filled with people who want to see it grow, not burn.
