Arlecho's ScreenConnect 6 releases

[Arlecho]

Wouldn't count on anything but making your life harder.

---

I am using Windows Server 2019 Standard (v1809).

Installed a server 2019 standard in a vm, updated windows, performed a clean install using v23.9.10.8817 and patched it with 3.4.1, works just fine.

There must be some something different about your environment, are you by any chance running an external virus scanner?

[Tosa_Puppy]

2X Windows Server Success:

Windows 2012_R2 >>> 21.4.2 --> 22.4 --> 22.9 --> 23.7 --> 23.9.10.8817
Windows 2022_ >>> 21.10 --> 22.4 --> 22.9 --> 23.7 --> 23.9.10.8817

With each upgrade I patched the installer, did only step 2 (not 2a). One install was a custom directory (on the D drive).

Immediately (2 minutes) after I opened up the ACL I saw a ton of malicious attempts. I'm posting them here https://farwestbox.com:510/shares/folder/FmD8igHu32m/
in case some are interested. There's way too many to blacklist them all there are way too many. This is just a few pages from one of my servers. There's no doubt at least a hundred screenshots I could take from each server.

[gr3p]

If prevent an administrator from editing the User XML file, this can help from hack?

Moving the SetupWizard.aspx file elsewhere would work in theory as well.  This whole issue surrounds the specific way SetupWizard.aspx file is accessed.

Even if you've already setup ScreenConnect (on an affected version), you can still visit https://yourserver/SetupWizard.aspx/test and it will run the Setup Wizard again, overwriting the Users.xml file in App_Data\.  If you just visit https://yourserver/SetupWizard.aspx (without trailing slash), it will redirect back to the login screen / admin console as normal.  This is the flaw.

[whitewidow]

Wouldn't count on anything but making your life harder.

---

I am using Windows Server 2019 Standard (v1809).

Installed a server 2019 standard in a vm, updated windows, performed a clean install using v23.9.10.8817 and patched it with 3.4.1, works just fine.

There must be some something different about your environment, are you by any chance running an external virus scanner?

Same. Windows Server 2019 Standard (v1809) fully updated. No AV. Hyper-V installed and a couple VM's running.

I was able to install/patch and start services on every version listed on ScreenConnect's release site from 21.5.3025.7772→23.2.10.8811 with 3.4.1 versions of the patch .  When I install and patch any version 23.3.19.8811→23.9.10.8817  ScreenConnect Security Manager  service fails to start.

Currently blocking all connection on version 23.2.10.8811 with my configuration. I believe I tried a clean install and patch on 23.9.8.8811 and it failed to start services. Im running a backup so after I will try another clean install.

Side note ScreenConnect's release site is a mess. They removed all 23.9.x versions and release dates on old versions are from yesterday.

[Grievouse]

If prevent an administrator from editing the User XML file, this can help from hack?

Moving the SetupWizard.aspx file elsewhere would work in theory as well.  This whole issue surrounds the specific way SetupWizard.aspx file is accessed.

Even if you've already setup ScreenConnect (on an affected version), you can still visit https://yourserver/SetupWizard.aspx/test and it will run the Setup Wizard again, overwriting the Users.xml file in App_Data\.  If you just visit https://yourserver/SetupWizard.aspx (without trailing slash), it will redirect back to the login screen / admin console as normal.  This is the flaw.

Where i can find SetupWizard.aspx?

[gr3p]

If prevent an administrator from editing the User XML file, this can help from hack?

Moving the SetupWizard.aspx file elsewhere would work in theory as well.  This whole issue surrounds the specific way SetupWizard.aspx file is accessed.

Even if you've already setup ScreenConnect (on an affected version), you can still visit https://yourserver/SetupWizard.aspx/test and it will run the Setup Wizard again, overwriting the Users.xml file in App_Data\.  If you just visit https://yourserver/SetupWizard.aspx (without trailing slash), it will redirect back to the login screen / admin console as normal.  This is the flaw.

Where i can find SetupWizard.aspx?

In your application folder, usually C:\Program Files (x86)\ScreenConnect\SetupWizard.aspx

[whitewidow]

If prevent an administrator from editing the User XML file, this can help from hack?

Moving the SetupWizard.aspx file elsewhere would work in theory as well.  This whole issue surrounds the specific way SetupWizard.aspx file is accessed.

Even if you've already setup ScreenConnect (on an affected version), you can still visit https://yourserver/SetupWizard.aspx/test and it will run the Setup Wizard again, overwriting the Users.xml file in App_Data\.  If you just visit https://yourserver/SetupWizard.aspx (without trailing slash), it will redirect back to the login screen / admin console as normal.  This is the flaw.

Where i can find SetupWizard.aspx?

In your application folder, usually C:\Program Files (x86)\ScreenConnect\SetupWizard.aspx

I believe Arlecho's patch will remove it when it is ran.

[gr3p]

If prevent an administrator from editing the User XML file, this can help from hack?

Moving the SetupWizard.aspx file elsewhere would work in theory as well.  This whole issue surrounds the specific way SetupWizard.aspx file is accessed.

Even if you've already setup ScreenConnect (on an affected version), you can still visit https://yourserver/SetupWizard.aspx/test and it will run the Setup Wizard again, overwriting the Users.xml file in App_Data\.  If you just visit https://yourserver/SetupWizard.aspx (without trailing slash), it will redirect back to the login screen / admin console as normal.  This is the flaw.

Where i can find SetupWizard.aspx?

In your application folder, usually C:\Program Files (x86)\ScreenConnect\SetupWizard.aspx

I believe Arlecho's patch will remove it when it is ran.

It should.  I think 3.4.1 did anyway, and one of the 3.4.x version just prompted to remove after patching.  For those that are struggling to upgrade, this would be considered a workaround until they have time to work out the kinks for the instance of ScreenConnect they're upgrading.

[point99trash2011]

Side note ScreenConnect's release site is a mess. They removed all 23.9.x versions and release dates on old versions are from yesterday.

You can manually download the ScreenConnect_22.8.10013.8329_Release.msi they took down the links, but the file versions are still up there if you edit their URL from their download page itself on a currently shown release. I was able to go from 22.1 to 22.8 (that version), and everything generally worked. But when upgrading to 23.3.19.8811 I could not log in in any way. I even edited the web.config as recommended in the thread and dealt with the license.xml

Code:

<add name="SessionDatabase" providerName="SQLite" connectionString="Data Source=|DataDirectory|/Session.db; DateTimeKind=Utc; Foreign Keys=true; Page Size=4096; Journal Mode=WAL; BaseSchemaName=; Cache Size=1000; Memory Mapped Size=10000000000; DateTimeFormat=Ticks" />

I thought it was extensions enabled, so rolled back to 22.8, disabled all extensions, and still would not let me login on 23.3. But took the plunge to apply the other update right after, the 23.9.10.8817, in spite of not being able to log in, and it worked fine, and loads everything normally.

[Ophiuchus]

After updating to latest, modifying my web.config and reimporting my users.xml, everything seems good for me now.
I was able to find a python script that could perform the attack on github and tested hitting myself before (successfully) patching and after (unsuccessful), so the vulnerability appears patched.
SetupWizard.aspx no longer exists in my install folder.

I also configured IP Blocking since I was being dictionary attacked, and haven't seen any attempted sign-ins since 9:45pm EST yesterday (besides my own).
Configuring SSO actually saved me here, otherwise I would've been locked out yesterday.