Okay, so in this module, we're going to talk about risk assessment.
So let's get into the weeds here and talk about, again, that risk
assessment as there are a few things that need to be considered
for any company running this product.
So Bri, let's start with the CVSS scores.
‑Yeah, so we have two CVEs here, CVE‑2024‑1709, which is rated at a 10.
This is the highest critical level that you can be rated.
This is the worst that it gets.
This is not anything to mess with.
This is serious.
High criticality, easy to reproduce.
The second one is CVE‑2024‑1708, and it's rated at 8.4.
Still high.
Still critical.
Still a serious concern.
‑Yeah, for sure.
When you've got anything that's above 8.5 and going up to 10,
really need to focus on what's going on here.
Now, Aaron,
I know we've talked a little bit about this being
an internet‑facing application, but is it really just that,
is there anything more to it?
‑There is.
So yes,
in general we're concerned about is if you're exposing the
service to the internet and it can be exploitable,
that's going to be bad because you're going to get caught up on
the list of opportunistic threat actors just scanning the
internet looking to see what they can grab.
And as soon as that's done,
because this is so easy to reproduce and there's
already proof of concept out there,
they'll be able to rapidly exploit that and then change tactics so that
you're now part of a group of compromises. Separately, this is also a
way for threat actors once already in an environment or gaining access
to your environment through MSSP or something like that to then
laterally move and/or elevate their privileges by exploiting the
service internally.
So even if you're not exposing this to the internet,
it's still now a very high target internally for threat
actors to gain access to new servers or authentication
that they didn't previously have.
‑Yeah, that makes sense. It's not just exposed devices on the internet, but yeah,
I I totally understand what you're saying about we can
have this exposure internally, too.
So now, Bri, when we're talking about this, is there an active proof of concept,
I guess?
‑Yeah,
so we mentioned the Huntress report a couple times. That security
firm did establish a POC the same day the advisory was released
as the date February 19th, and they have released that in their
further analysis report.
And then I do want to just mention again the report that you
brought up the advisories from CISA that were issued back in
January of 2023 regarding the RMM software.
So this is not a new kind of threat.
This is not a surprise.
As Aaron mentioned, the term opportunistic, that's kind of what
these attackers and threat actors are looking for.
‑Yeah, I like that call‑out on those advisories.
And I like, again,
Aaron's distinction on those older advisories versus what this is right now.
Now we already know that this can be executed in anyone's environment, right?
And what about different indicators of compromise?
I read on ConnectWise's website for the for this very advisory,
I mean,
basically they're IoC, so were three random IP addresses, and that was about it.
So Aaron,
can you kind of dive into that a little bit deeper because I'm sure
there's more to it than just those three IP addresses? ‑IP addresses
end up being like a really easy way to say,
hey,
we saw some exploitation that had to come from these IP
addresses, but as we've said before,
it's really simple, trivial, if you will, for a threat actor to change
their IP address and/or to use thousands at the same time.
So these aren't necessarily going to be useful moving forward,
although it is something to look for. Now,
separately, and I'll kind of like dig into that PoC code a little
bit, what this ends up being is a web application attack. And so
not to dig too much into the weeds here, but what they end up doing
is building a post message,
which is essentially just browsing and sending data to a
URL that goes to SetupWizard.aspx.
And so that is the first set of information with an exploit
inside the VIEWSTATE generator that allows you to create a
new username and password.
So that's the authentication bypass.
And so in those web blogs,
whether it be IIS or Apache or Elastic Load Balancer or Azure Cloud Solution,
you should be able to see requests to SetupWizard.aspx and then inspect those
to understand is this something that's being used uh to exploit that bypass
capability? Separately, the execution code after that leveraging that
authentication is then going to create a new app extension and then add the
plugin ID, as well as the payload after that.
And so that is something that you can also search for in those
logs to see if you've already been compromised or use as a filter
for looking for setting up rules to block it with something like a
web application firewall.
So those two things are there. The last piece of this is now past the execution,
you're going to see the ScreenWise service executing that code that's been
provided in the remote code execution exploit on the system.
And so that is another thing that you look for is in the logs on
generally speaking a Windows server, in this case,
you're going to see the ConnectWise service executing cme.exe and
executing whatever codes that threat actor is doing.
And as you look through MITRE ATT&CK,
what you'll see is that for an attack chain like this,
as soon as I gain execution,
the very next thing I want to do is then kind of move away from that service,
execute something like Cobalt Strike or my own sort of command and
control capability that reaches back out often over HTTPS,
often over port 443, so I can maintain that connection outside of that remote
code execution vulnerability. Because as soon as you patch it,
that path is gone.
‑So if I am understanding this correctly,
if ConnectService is running cmd​.exe with stuff after that,
that's bad. ‑That is bad.
Yeah.
And even if you see execution of that service and then
some system running that as well, that's an issue. ‑Yeah,
I love all that stuff.
I mean, especially, I mean,
you're already talking about mitigation factors and how we can go after
this and hunt for this, so all really good things.
Now, Bri, what is this application's priority level?
I mean, should we be concerned if we see this? ‑You should be concerned.
We've talked about the level of criticality.
It's a 10. We've talked about the level of impact, it's incredibly high.
This is all hands on deck scenario.
You need to respond, you need to look for this,
these IoCs you need to look for this software in your environment.
And even as Aaron mentioned, even if it's not internet‑facing,
it gives attackers that tool in their tool belt to
increase privileges inside of your network.
‑Yeah, that makes a lot of sense.
I mean, if you see ScreenConnect anywhere in your environment,
especially if you don't have it, probably a red flag.
Now, as we move forward, Aaron,
I know we've talked about we have to patch, all right, we got that.
And what else besides patching to the latest
release should we be concerned with?
‑You really need to be looking at getting ahead of this in general. So you
need to put in web application firewall rules that protect any sort of
public‑facing web application service. This is included.
And then at the same time, if you do see compromise,
you're going to want to look further into your environment.
Like if there is a compromise that you identified,
you now need to see like are those connections reaching out?
And if so, where else have they been connected to internally, or have I had
compromise for my Active Directory environment as well?
So that's something you want to be concerned with. ‑Oh,
also, and one good thing to know that as part of this release,
ConnectWise has removed the license restrictions for the
partners that are no longer under maintenance,
which is really cool, and it's a really good move on the part of
ConnectWise. Now, speaking of moving forward. Now,
if we're looking at following actions or like a
postmortem report or something like that,
what are some security general best practices that our security team
can actually look at or think about, Bri? ‑Yeah,
we always like to give some good generic security practices
and ways to kind of benefit your team.
And so the best way to kind of evaluate here is review your team's response to
these kinds of vulnerabilities and see how prepared you are.
Were you prepared to deal with them?
Do you feel like you had enough information to make a decision?
Do you have playbooks?
Do you have the tools that you are needed? And how did your response go?
Right, as Aaron mentioned, even if you find the IoCs,
were you able to find the follow‑on actions?
Were you able to find all the pieces that you need to
and remediate as quickly as possible?
Now, if you were not compromised in this,
what did not affect you,
I will always use the suggestion of emulation to make that scenario and test,
right?
We can't always just be reactive to when these vulnerabilities break, but we
want to move to a more proactive maturity and security posture.
So test this in your system and test this in your environment and test your
teams to see how well you can increase the security controls and your response
to this type of scenario. ‑And really good stuff here,
you two.
And it's extremely important for those who are
impacted by these vulnerabilities.
Now,
that puts a wrap on this very important episode of What
You Should Know with the vulnerabilities surrounding
ConnectWise's ScreenConnect app.
Now be sure to check out the Resources module and exercise files
with more information and informational links we've talked about
here. Now, as always, stay safe out there, and we'll see you
back here at Pluralsight!