All right, so my name is Ken Pyle.
I am a partner and exploit developer at a firm named Cyber.
I do exploit development, offensive work.
I'm a really prolific zero-day hunter.
So this is, we do managed services,
we do managed services, data security, breach response, digital forensics.
I'm primarily, as I tell people, I live on the very red side of purple.
Like, very red side of purple.
I get called in and it's like, has anybody ever seen this?
Have you ever given your view on it?
I'm also a graduate professor of cyber security at Chestnut Hill College.
I teach applied cryptography, advanced exploit development, cyber warfare stuff,
refinement of exploits, what have you.
I have to give you the plug because I'm here, whatever.
But I'm going to be very clear about this.
None of the opinions I'm expressing in this presentation
are representative of either of those institutions.
So you know where this is going.
All right, this is actually my academic research
I've been working on for a really, really long time.
And I'm going to, as I put this presentation together,
it looks very small, but I'm building up from the bottom to something really big.
And it all starts with some very basic concepts.
One of the things I try to tell people is,
I am a really, really prolific exploiter of critical infrastructure.
If you don't know who I am, I'm the person,
if anybody heard about the emergency alert system getting hacked last year,
that was me.
The ruckus Andoriu botnet that got started earlier this year
caused a big problem on the KEV, that's me.
Some other stuff.
And I always tell people this, I love my job, I am super passionate,
I love this, I've been doing this since I was six years old.
I was on a 2400 baud modem doing this.
I do some really serious work, we all do some really serious work,
but it is really important to not take yourself too seriously.
So when I popped the emergency alert system,
and my picture was getting broadcast all over the world,
I made sure to troll goth fans with my favorite New Order CD.
The keys to set off emergency system alerts across the United States
are actually hidden behind that CD.
But the whole point of it is, we do really serious work,
and we get really tied up into it,
and there's this problem we have in the industry
of everybody aiming guns at each other.
I'm an exploiter, I'm a hacker,
and I have to talk to appsec people constantly.
And it's always adversarial.
And it doesn't need to be.
It's also not very difficult.
All the things I'm going to show you here
are literally basic concept things
that I'm sure you read in the first five pages
of anything you ever read.
So if you ask yourself a couple questions
of how do I know some of these things,
or how did I figure some of this out,
my full confession is this,
I used to be an MSP engineer,
I used to be a security and network engineer,
and I know because I'm sitting in a room of appsec people,
I will tell you flat out, it's not always the network.
But this time it kind of is.
But it's your fundamental lack of understanding
of how the network works
that makes what I'm going to show you happen.
And I want the light bulbs to start going off.
So people ask me this, how do you find zero days?
Break out the crayons.
On the engineering side, we hate doing this.
I hate having to explain myself to people.
You have to.
You guys got to be a little bit more cool with us on our side,
and we'll be a little bit better on your side,
but that's causing these problems.
How do you find zero days?
It's as simple as reading the effing manual.
I tell people this all the time.
Understand what you are actually working at.
If you're an appsec person,
your application is transmitted
in some way over a network, correct?
You should probably learn how that road works,
and all the off-ramps and ways to hijack it
through application security.
I always tell people to be eternally cynical, skeptical.
If somebody tells you they did something,
double-check anyway.
The big problem we have with supply chain management software,
stuff like this, is we're all depending
on the person behind us or next to us
to have done their job and actually read the manual.
Turns out, it's the complete opposite.
Don't give up.
If you find something new,
and I'm going to show you something that's brand new,
a new type of HTTP exploit I came up with,
and I knew what I had,
but I had to protect it because people were trying
to actively not let me talk about it.
Not just this situation, it's a bunch of...
And sometimes you just have to, as an engineer,
lower yourself to the pity of explaining
the network to plebs who don't know anything.
That's BS, man.
As a very good friend of mine, an amazing hacker,
John Vandiver, said,
great hacking is just great system administration.
That's living off the land, right?
Living off the land is taking what the defense gives you
to accomplish something you want to do.
So I did it.
So I'm going to break out the crayons a little bit.
Like I said, I'm going to explain through this,
and it's going to look weirdly weird.
I'm going to snap something else on,
and it's all going to click together.
Breaking out the crayons, living off the land,
finding new exploits, is all about one thing.
What is the difference between the way you intended
this application to be working and how it's actually designed?
Right?
I intended for this application to provide a login.
As designed, it allows you to inject things
into the login page and obtain access, right?
That's how it works.
Going back to that, sanitization of input,
if I can tell one other thing to application developers,
is that sanitization of input needs to happen on both sides,
and any time information comes in and leaves.
And there is more implication from that
other than an API call or an HTTP request.
And now this is what I'm saying,
it's kind of about the network,
but it's a fundamental lack of understanding.
The lack of understanding of the OSI model.
And trust me, there is no greater abuse in technology
than the first hundred pages of every book you've ever read
that explains the OSI model for the 900th time.
Right?
But it's actually important,
and you should actually learn it,
because I'm old.
I feel like I'm coming back from the future
to warn everybody about something that happened.
I'm old, and some of the tricks I'm using
are things that I've been using for 30 years.
Because what happened?
They were known about, nobody fixed them,
it's like the last person standing in the room
and everybody forgot that old knowledge,
and when I wonder why that,
it's just forgotten, it goes into the ether.
And the last thing I tell people is
sometimes you actually need to write the manual
to explain it to people.
So, here's the story.
I'll give you the background story,
how it got to this, and how it snaps together.
So, ConnectWise Control and their applications
are set for MSPs and large organizations
to do endpoint management.
Right?
You've had some version, Kaseya, ConnectWise,
there's all these different things
that allow MSPs or large corporations
to manage all their endpoints, jump in, yada, yada, yada.
I began disclosing my work in October 22 to them.
After disclosing it and being responsible,
they started saying it was minimally impactful,
but they still patched it.
In addition to that, several IR firms,
because a lot of people in that side of the world
know me and came out to me and said,
I heard you're on some hot stuff, can you tell me?
I shared it and I always said, like,
as I always say, I'll share what I know,
just do me a favor, don't share it with anybody,
keep it quiet until I talk about it.
Because it's not a fame thing,
this is actually a pretty big deal.
After attempting this and being called overblown,
ridiculous, whatever else, it's not a big deal,
and after all the patching, I finally just said,
I'm done with this.
I'm going to MITRE and I'm just gonna ask for the CVEs.
So after being called overblown, this wasn't a big deal,
my CVEs were classified as a 9.8.
Not only that, on December 1st,
Krebs posted an article about it,
how I publish a blog post around my findings,
and coincidentally, ConnectWise released an advisory
warning about phishing campaigns, client-side exploitation,
and all these other things that bear a lot of similarities
to what I did.
I'm not here to talk about that, but I'll say this,
all you really needed to do all of this
is sitting there on the right-hand corner,
I just never explained it to anybody.
Because it was like, if this is the game
that's gonna get played, I'm just gonna go talk about it
and that's the end of it.
Going a little further, a third-party company
who did some analysis of this,
posted a public analysis and comment on my work
stating it wasn't a big deal.
And I'm not here to talk about them,
it's not the story about them, but I will say,
there are a number of potential emissions and issues
in this analysis.
So instead of going in a fight with them,
I checked their homework.
So, there's your CVEs.
One of the things I'll tell you is that analysis
does not ever mention that those things are actually
a little ridiculous.
But, let's talk with it.
How does living off the land start?
It starts with understanding how things work.
In the top left corner is basically your average,
hey, this is a switching network with a router and firewall,
bottom's the OSI model, the top right,
I'm gonna explain it to you in a minute.
But, living off the land is basically this.
And you can read it.
Taking advantage of things like,
abusing PowerShell, Visual Basic, WMI,
PS Exec, Mimikatz,
all of these things that are allowed,
exploits the functionality of a system
to hijack it for nefarious purposes.
That's living off the land.
Abusing something you're given to do it.
It may include tactics like DLL hijacking,
hiding payloads, process dumping, downloading files,
all these other things.
Code execution, persistence, log evasion.
These are all hallmarks of mega super APT groups, right?
Like, oh, they do live off the land,
they're gonna be detected.
No, it's just knowing how a computer works.
Nobody on my side of the house wants to tell you
it's really as simple as knowing how to launch a command shell.
So, after all of this and everything else,
my work was repeatedly acknowledged
as defeating controls, internally reproducible,
sharing traits with APT groups,
I directly disclosed it prior to any public notification by them,
and it's being actively exploited.
Keep that in mind.
So why don't you ask yourself this,
if I'm gonna build a botnet,
what are the things that I really want?
So, on the left-hand side, I want a port scanner,
C2 beaconing, tunneling, arbitrary request handler,
amazing hosting that doesn't go down,
code signing, trusted execution,
exfiltration, implantation, client-side exploitation.
For me, that's a fully functioning botnet
with all the tooling I need.
On the right-hand side, what would I love to have?
I'd love to be able to bypass everybody's firewall rules,
something has no monitoring, poor user habits.
I would love to get access to somebody else's
trusted SSL and code signing certificates
to sign my malware with.
I want to drop catch domains,
so I can catch people when their instances expire
and I can phish them.
I want to be able to send my phishing emails
to a trusted SMTP source,
like their hosted cloud instance
that enables you to do all of that through a hosted solution.
And this is the thing to think about,
HTTP API protocol fuzzing.
I'll show you how that works,
but think about this in the context of your applications.
With abusing a little trick
with server-side request forgery,
I have a really amazing little thing to show you.
I want to bypass eight controls.
This bypasses AV and EDR controls.
I know it does.
Even better, if all of this can be free to you,
instead of spending thousands of dollars on hosting,
and I really am after is getting code past everything.
There's all those controls in place that make things stop happening.
Now, what's perfect for that?
RMM software.
And I'm not picking on ConnectWise,
because you can go look at my critical CVEs
on all kinds of MSP software.
Because say it happened in 2020, right?
2019, I alerted them to a very similar kind of issue
and said, you've got to fix this.
Why? Why do I go after this piece of software?
It's poorly managed.
People disable controls to make this work.
And I'm going to show you a specific example
for every one of these points.
It provides system access in Windows.
So I'm the colonel, right?
Normal looking.
So if I want to phish people,
and I figure out who your MSP is,
or your company is,
I can just make it look like it came from them.
Gives me access to everything.
And here's the important part.
I can either maintain persistence,
or I can make it temporary
and leave very few, if any, forensic IOCs.
That's what I go after.
I want to be not detected.
And again, all of this is free.
You don't need a dollar to your name
to set all of this up.
Now, let's talk about this.
Many people...
and this is...
I'm talking about specific...
but you've got to think about this
in the context of your application,
how you're designing things.
People disable security controls
because software is either over-designed,
or there's deployment complexities.
And what people try to do,
which we all do,
is design so it works absolutely everywhere,
no matter the infrastructure.
What you're looking at here
is on the left-hand side,
and I'll read it so you can't see it.
It's a posting from a Zscaler forum,
the support forum.
I'm having problem with connectwise
connecting to a direct IP.
At the bottom there it says,
oh, the way we fixed this
was on our SSL inspection.
We accepted and allowed
asterisk.screenconnect.com
but we should have used
screenconnect.com.
So,
think about it this way.
If you asterisk the domain name
for disabling security controls,
as long as I have
a subdomain existing
in there and resolving
what has just happened,
you have disabled
all inspection of SSL
for anything coming from there.
That's really important.
On the right-hand side, you have another one where it says,
I'm having an oddball issue with screenconnect
where the agent can't connect back to screenconnect
so it just keeps retrying.
If I disable, decrypt, and scan,
it'll just work fine.
I've whitelisted screenconnect.com
including all domain names.
And the bottom one is a moderator saying,
please show a picture of the edit of this configuration.
Starting to get it now?
So,
even further,
there is really poor management
of their cloud instances of
registering FQDNs.
What you're looking at is
some company that I dug out of security trails
that has a screenconnect.com
subdomain for their old instance
except it was retired
for a year.
I did some OSINT, I went out,
I registered their domain
to me, started a connectwise
instance, and I now own their FQDN
for it.
So if you didn't go back
and disable all of those changes
that you made to your security
controls for any of this,
what have I just done?
Right through.
And I prove it.
Further complicating
this fact is that every single cloud instance,
even trials, that you
get, issues the
same wildcard SSL
certificate to absolutely every
instance.
Anybody do
cryptography like me?
What is the first rule of public-key
cryptography? Control
of the key and registration
and knowing it. So this is a
really good cert. It's a high-grade cert.
So anybody, whether you're
a corporate customer paying millions of dollars
or whatever, or some idiot like me
with some free time in a basement,
I can go get the same SSL
certificate for you. And remember,
everybody's keying on the wildcard.
And they
don't inspect SSL either, do they?
Awesome.
So, there's another
certificate that exists in all of this.
A code-signing certificate. When you
download their agent for installing
these things, it's
signed. But it's a
click-once installer.
And there is a small little space
in here in which
the code-signing certificate
doesn't apply. It's
an unregulated space
in a signed executable.
You're all AppSec people.
Is that something you're supposed to do?
How much is
that cert now worth?
Zero dollars.
It's worth it. It doesn't do anything.
I can go in there and edit
that space and
it won't break the certificate.
So how are the two ways that EDR and AV work?
Hash-banning
and code-signing.
By changing this space and
injecting whatever I want in here, it changes the
hash of the file. And that changes every
time you start a session.
So you can't hash-ban it.
The only other trust control you can anchor this on,
other than watching behavior, is a
code-signing certificate that
doesn't actually do anything.
See how this
is all starting to snowball a little bit?
To make matters
worse, the
download of that signed executable
that gives you system
access, all these other things, or whatever,
is transmitted via HTTP,
which
is plain text.
So, by
transmitting a
weakly-signed, can't-hash-ban
it executable
over a network via plain text,
I can essentially, without any
social engineering or interaction, back
door that thing when people are downloading.
Not only that, you can
man-in-the-middle-it, proxy it, or just
directly edit the file and download
it from anybody's public instance.
Top right, left corner.
This thing executed that malformed
HTTP request to that IP address
via that signed client that
I manually edited and man-in-the-middle-ed
and it worked.
It executed
an arbitrary HTTP
request to a host
of my designation inside
of a signed executable.
Checkmate, right?
That's the first 10
seconds of this. Because
all of these things violate the CIA triad.
There's no integrity.
You can use this to do some availability
problems. It's in the CV, and it's
definitely not maintaining cryptographic controls.
So, I'm going to rewind a little
bit and go back to third-party analysis.
And I want to read this to you.
Third-party companies are giving out some
pretty flawed advice, and I don't think maybe they
understand exactly how the AppSec or product works.
I'm going to read you an analysis they had on
another case to you,
and I want you to put this together in your head.
This simply means that hackers could register
for trials of control and potentially
serve malicious JavaScript from an
asterisk.screenconnect.com domain.
Theoretically, this could be a
building block for other attack chains,
but it's not worth losing sleep over.
Because
this happens,
and they're wild-carding,
control of any server in their
cloud domain FQDN
DNS zone, whether
inflected or injected,
will allow you to perform client-side
exploitation and bypass
browser controls. Why?
We are allowing
script access from
asterisk.screenconnect.com.
Right?
It's not a theory. In fact,
I'm giving you only one weaponized
example of this. As long
as you can figure out how to get something on
that, it goes nuclear.
Now, think about this in an AppSec
perspective. I'm downloading an executable file,
an agent,
that doesn't have any effective
framing mitigations.
Does anybody know what that does?
Download a file via a frame, and it's
a no-click downloader.
It will just download it
because it's injected in a frame.
So, if I can come up with a malicious
agent, put it
in another instance, and find
a web page that I can inject content
into, I can now
install without a click
an agent on
anybody's computer.
Which gives you access
to everything.
Now that you have this,
you're probably asking yourself, how do I weaponize this?
How do you live off the land?
Well, living off the land is understanding how things work,
right? So, why not
just make it an unauthenticated, signed
exploit factory and delivery method?
It's a signed Windows executable
that you can't hashband,
that's always excluded, but not
only that, it works across
multiple operating systems, signed
or unsigned. It executes
arbitrary requests and other things
that I'm not talking about to targeted endpoints.
Because it's a network
thing that goes back to a DNS
name or an IP address, it
resolves it and creates requests
from it. It's an
arbitrary HTTP
or command
executing application that's
signed with somebody's legitimate
sign, sir. Now, here's where it gets
crazy. You already know about
this, but look at the top right corner.
As long as I have a
cloud instance, an
on-premise instance, I can
sign executables with their
code signing certificate.
Even an unlicensed
on-premise version of it that
has a trial that was never licensed.
Hint, hint.
It works.
So here's a signed exploit factory.
I'm the guy who came up with the
Endorubot one. I'm the one who came up with the Cisco Dell
one that became a big problem. Why do
I make every one of my exploits
that are web-based, I try to get them to get
requests. Because they're client
deliverable. They're not posts.
I just have to craft
a good URL.
So what you can do is
embed my exploits, which give you
remote code execution, complete control
of network infrastructure,
by bouncing it out of an
executable,
somebody downloads it, and because
they're inside somebody's firewall, it
will execute that to wherever I want.
That's how you bypass a firewall.
If you don't believe
me and you want to test this out for yourselves,
and that you can actually inject this,
here's the exploit.
This will compromise
Cisco, Dell, Netgear,
D-Link, Linksys, there's a whole slew
of switches that have this.
And it really is as simple as
pointing to the right IP address, feeding it
about 1,200 characters,
and then putting a
certain character in there, and it reboots
the switch. Which
stops all of your applications from working.
But why would I give you that exploit
as part of that?
Because remember how I said you can
man in the middle of the download?
What do you need to do that?
To roomful AppSec people,
and they don't know this, this is important.
What happens in the first 15 seconds you reboot a switch?
ARP table flushes.
What do you need to do man in the middle?
Control of ARP and Mac.
So if you want to test
out man in the middle in the download,
get a switch, send it that exploit,
and do this, and you can completely
recreate my work in about
10 seconds. Don't believe me?
That's the default IP address for those switches.
So what I do is I control external
domains with internally resolvable IP
addresses, like the default IP addresses for everybody's
switch, or most of them.
Spray them out, and eventually
you're going to get a hit.
Even more to the point,
I'm not just talking about Windows executables,
and this is important. I did a lot of work on this, nobody
read it. I'm one of the leading exploiters
of a format called JNLP, Java Network Launch
Protocol. It actually launches Java
and works across any operating system
that has Java in it. So this injection
problem doesn't just exist in the Windows
executable. Every kind
of agent, EXE,
DBN, Windows,
Linux, they all
suffer from this problem where you can inject
into space like this
to get it to do these things.
All this is, is a downloader.
Like a click once
installer. It just goes out and retrieves
something, but I have control
of what it retrieves.
So, now that you have
all that, how do you
actually exploit this in a meaningful way?
What if I
did have a way to theoretically inject
things into ScreenConnect.com's domain without
them ever knowing?
So put that
aside for a second and look at this.
You have this malicious code factory,
how do I start delivering it? And remember
all those tools I told you I built out? How
do I do it? So here's my moment.
For the past
year, I have been routing,
abusing, using the ConnectWise
cloud service
under their noses.
After informing them of this,
and I've been collecting POC for
C2 beaconing, bypassing firewall
rules, tunneling malicious files,
creating a giant DDOS cannon,
botnet creation, client-side
exploitation, port scanning and API access
to external and internal
hosts at ConnectWise.
Arbitrary
HTTP requests on arbitrary ports
and exfiltration and implantation of malicious
code. How did I do it?
Because of one web page
and how that software
works. Why?
Because software developers don't know
how a network works.
I'm going to explain it, it's going to look all complex
but I did it a really simple way here.
All you really need
are three GET requests.
If you look at this, the top
one is how I made it into a port scanner
and an arbitrary HTTP
and API fuzzer.
The second one is a content brooder
you can use like Durabuster
to scan people's things.
And the last one is a client-side exploitation
method of something I'm going to show you that I've never
showed anybody before.
Or you can just go to my
GitHub and I'll give you the Python
scripts. As you'll see, none of this
requires anything other than a knowledge of the things on the
left-hand side. Doesn't require a credit
card. Actually, I host all
of my stuff in ScreenConnect's own cloud.
I registered for a trial instance anonymously
and I've been hosting
it for a long time.
I'm hosting
everything out of Amazon EC2
for free.
And I'm going to give you the free Python scripts.
In fact, if you take pictures, I have them all up here for you.
So it starts with this web page.
Oh.
My battery's getting cut out.
Hold on.
Ah, there we go. Okay, sorry.
My battery was going out.
This page.
How do you live off the land with ScreenConnect?
If you go to that web page right now,
I'm pretty sure it's still up.
What is this page? Remember the difference between
intended and as designed?
So this is the intended design.
Use our port test tool to determine the external
accessibility of your ScreenConnect instance.
If you have changed ports or are hosting
at a different IP or host name, you'll need
to change those values accordingly.
So ask yourself this.
What happens when I submit this
post request?
I control the DNS record, I control the port.
The answer is this.
I can control the port
the request goes to,
the host it goes to,
and it's not coming
from my IP address.
It's a server-side request forgery.
If you look it up, it's coming
from their IP address.
And I'm doing this over
an anonymous VPN.
So think about what's
happening.
When I submit this request,
the server receives this request from me,
get or post.
The server at 52.202.11.141
processes that record
and performs three to five DNS requests.
It then creates a new HTTP
request
to the user control port
and it's coming from the targeted IP address.
So if you have a firewall
that says asterisk.screenconnect.com
you have whitelisted everything
coming out of this.
Make sense? Follow me so far?
Alright.
The page then returns a status of this.
So the web server one, it just says succeeded.
So if it connected, it got a 200 code
it says succeeded.
It's a blind SSRF, right?
Okay.
As intended,
this is designed to let users of the software
test ports and HTTP access
no matter where they are. It's a diagnostic tool.
Because people change ports
in DNS or they use dynamic DNS
for this, they change it.
So the diagnostic tool has to be able to do that.
It's unauthenticated
and totally public because an MSP
or a large corporate customer might need to test this.
Now put this together in your head.
What do you think the egress
firewall rules on that host are?
If you can scan on
any port going
out, what are
the firewall rules going out?
Okay.
All ports are open.
Got it?
So what's happening is it's creating
a DNS request. Going deep
into this, I don't want to go too deep into it,
but just understand it's three to five
DNS requests and then the HTTP request.
It's also
effectively operating as a proxy
for me. Every server side
request forgery is a proxy.
It's a limited proxy,
but it is indeed proxying traffic.
So working as designed,
this is a port scanner,
a proxy, a firewall bypass,
backdoor access to
people's HTTP and API.
Remember how it's generating five
to seven requests every time and it doesn't
do any sort of rate limiting?
That's a DDoS attack. Just
flood it. Trust me.
You can do C2 beaconing.
You can enumerate content.
You can fish from it. It bypasses AV
because everybody's disabling this stuff.
I have the malicious code signing thing
and I now have access
to ConnectWise's internal network.
Who wants
to call me on that one?
I will explain why in a minute,
but look on the bottom right hand corner.
That's a port scan script I wrote,
abusing that function.
Do you see that lb.corp.xyz?
Here's one of my nefarious things that I never tell developers.
None of you actually likes to go
look at DNS requests, especially externally
injected ones, so I maintain
a bunch of really funny zones.
Corp.xyz is one that a lot of corporations
used to use, but if you query
lb.corp.xyz
it resolves to 127.0.0.1.
Making sense now?
But I'm not going to get there yet.
What I want to get there is this.
Two one-way communication channels
equal one two-way
communication channel.
I got this way, this way,
all I'm really doing is three lights
make a left turn.
I turned this into
an effective C2 exfiltration
DNS and HTTP beacon, similar
to HTTP exfiltration
like staging, or Iodine
C2, which is DNS based.
How did I do it?
I just encoded
in that HTTP
request that gets generated, I added
a base64 payload to the end of it.
Sent it
to an external host
and if you
decrypt it, it says cyber POC.
That's a message encoded
over base64, exfiltrated
through a trusted host
and signaling something to me
in a way they've never found.
Instant win.
What happens when you're requesting that?
It sends that request via user
control port as their IP address.
This is going to get very important.
Not my IP address.
Good luck doing forensics on that.
Good luck doing IR on that.
How I'm creating
an arbitrary HTTP generator
is, at the end
of that web server box, you
can actually put slashes and restful
stuff, but as long as you
put the anchor tag at the end of it,
it snips off all the other
stuff at the end that they add on,
making it a completely arbitrary
HTTP request generator.
Why the anchor tag?
What does it do in a browser?
You guys disregard it because it's an anchor tag
for the browser. Not for that.
They're snipping it off.
So all you need to do is put in that web server host,
the FQDN, whatever the URL is,
and put an
anchor tag at the end, and it's going to forward out
that exact thing.
I told them about this in December of 2022,
and as of July
15th, the day I got the acceptance from
the CFP, I immediately generated
this to prove it was still possible.
AppSecVillage,
a-v-s-v-d-c-31,
and if you decrypt the base64 value
in there, it has a funny little message for you.
Proof of concept. I get the F
out. There it is. I'm
not even done. This is the beginning.
If you see this right here, it says succeeded, right?
It's giving me a message. It definitely connected, right?
So what happens if
I start feeding that form malicious input?
Like the loopback interface.
This is
an external and internal port scanner
because it's
coming from that host.
All you need to do, and there's the Python script
for doing it, is to basically
iterate through every port
for your target host,
parse the return message
it gives you in that page,
and that's a port scanner.
If you have gone
out to your firewall
and disabled controls
or allowed firewall
rules from asterisk.screenconnect.com,
what have you done?
You've given me backdoor
access because it's
coming from somebody else's IP.
Don't believe I'm scanning the inside
of their network? Here you go.
Here's the URL.
If you use lb.corp.xyz
on the relay one, put in
the port box 3389
and click test.
Whatever you put in that teleprompter,
Ron Burgundy is going to read.
It resolves to
127.0.0.1
and it performs a TCP
connection to 3389.
Is that
externally accessible? No, it is
not.
I win.
And it all comes because
nobody understands the OSI
model. This is an
application using the network, but nobody
really thinks of what the network's doing.
Web applications are layer 7.
Network security
and that kind of stuff is
layer 2 and 3.
All of the things that I'm bypassing are
not anything web application developers tend to
think about. So, how
did I do this? How am I scanning behind
people's firewalls, beyond VLANs?
The only connectivity
between those two,
their internal network, me,
other ones, is a layer 7
traffic crafter
that is available on multiple
subnets.
Right?
It's weakly controlled and because I
can inject external IP
addresses in, or internal IP
addresses to external DNS,
if I feed it one of their internal
IP addresses for their cloud instance,
I am now tunneling HTTP
traffic or regular traffic
to stuff inside their firewall.
Does that make
sense? Not difficult, right?
Am I overblown?
I don't think so, right?
I should not be able to do this under
any circumstances. Ever.
Period.
So, there's your Python
script for doing it and that's how I scanned
their internal network with it.
So, you're probably at this point, great, you got a couple tools,
what's the big deal?
This is a blind server side request forgery, right?
Incorrect.
Everything is a proxy if you try hard enough.
Exactly.
Okay.
Well, when the content on the other side isn't
available, it actually
returns the HTTP
status code to you of
what just happened.
So, my arbitrary HTTP
request is now
getting back HTTP
status codes telling me what
happened. Isn't that
Durabuster? Isn't that
a brute force content enumerator?
So, if you want to enumerate
the content of anything,
there's my Python script. If you look
at the bottom, you just need a file with all your
directory names called content.txt
and it'll go through
and you'll get reliable return
codes out of all that. So, it's not so blind anymore,
is it?
Okay, here's the new thing that I
invented. I'm pretty sure I invented it.
Nobody knows. I've looked around about it.
Here's the crazy part, and this is one
of the things I know from 1980-something
or 90-something, sorry, more accurate.
Nobody actually
cares about the content of
HTTP status codes.
Right? How many
of you are actually saving anything
other than the three-digit numerical?
Right?
That's
IIS. That's Apache.
All they ever keep
are the three-digit status
codes. Now, here's the secret.
They
are entirely
attacker controllable.
I saw you look.
I'm going to prove it. Hold on.
Those status codes, the text
200, okay,
400, all those, the text that
appears after it
is not saved. Nobody looks
at it. Nobody wants to keep it.
So, what you can actually do
is inject
payloads into that
message, and if something
returns the text of that message
to you via server-side request
forgery, what have I just
done? I am now
directly injecting into
their web pages
my content hosted somewhere
else. Remember
that agent download? Going to become important.
It leaves
very few IOCs because nobody actually has
that, but think about it this way.
The IOCs that could tell you where that
is are on a third-party
server, and it...
I'm not going to speak...
It doesn't appear that they're monitoring this
because I've been doing it for a year,
and I've never been stopped.
That code,
right? So, I invented my own
HTTP status code called
666.
HTTP status
code 666 did not exist before
this moment, but
I am injecting into, as part
of that code, my
malicious page, or my malicious content.
All the controls that are supposed
to keep you from cross-site scripting and all those
other things immediately disappear. What?
Because this is directly integrated
into that web page's content.
It's not...
It's proxying it, but it's not like sending it directly
through. It's taking it, integrating it into that page
as its own web page code
and going.
Right?
Now, look at the thing at the bottom.
We used asterisk.screenconnect.com,
but we should have used screenconnect.com.
So, all of this is hosted,
or you can inject it through
www.screenconnect.com.
So, is
it a theory that I have a way of injecting malicious
code into anything on their pages?
Absolutely not.
So, all you really need to do is serve
666 as your error code,
put in a cross-site scripting payload,
and that is the world's simplest XSS.
What you need is the
Python listener to do this.
And it's on the left-hand side. That's the code.
So, all I did,
because their post requests can also
be submitted as GET requests,
I now have a client-deliverable
single URL
that will trigger all of this reliably.
Oh, wow, Ken,
you popped a one.
Get a lot more than that.
You can do all of this
just by doing that.
And that's the web page code.
I'm returning 666 via
that code, but if you see here in the input
field at the bottom where I highlighted it,
it's directly integrated into
the web page code.
Your browser thinks
this is legitimate content coming from
a trusted source.
So, how do you enumerate this?
How do you find this cool new way
of doing it?
I'm a big proponent of none of our information
or knowledge should be secret or esoteric
and this isn't all that hard to do
all this stuff, it's a matter of logic.
So, I like using free tools instead of
telling you to pay $15,000 for something.
It's very simple. There is a diagnostic
web page on the internet called
httpstat.us.
Whatever you put in the URL, it will return the error code
for whatever you put in there.
So, if you put 418 at the end of that,
it'll return a 418 code.
How many people know what a 418 code is?
How many people have actually ever used that in the real world?
Okay, you're like the three people I've ever met
that have ever actually used this for anything.
You're not a teapot.
You're a proxy.
Because if your
blind server-side request forgery
returns 418,
that's not something anybody uses.
That immediately tells you they're not sanitizing.
So, if you've got
a blind server-side request forgery like I do,
that's how I do it in Burp. That's exactly how
I do this. Run every status
code from 1 to 699
and if you get any sort
of code that means
anything, it's any kind of HTTP status code,
you're in. Now, here's
where it gets silly.
You have to understand what
this is happening. I call it sanitization depth.
On the right-hand side, you just have
my custom error. But,
the application completely
fails to actually sanitize
any of the data that I'm injecting
via that status code.
Character markup, anything.
So, if you remember my talk from last year,
I talked about how I figured out a way to do DNS
and HTTP exfiltration via this.
Malicious payloads that I want to
transmit over this, because it's a proxy,
I have all these characters
available, so now I can use Base64
and you can encode
anything as a Base64 payload.
So,
what do you do?
Well, if you want to tunnel live HTTP
traffic to bypass a content filter,
or you just want to traffic
files through connectwise port test,
aka proxy chains,
two one-way communication channels
equal one communicate, right?
So, all I'm doing, this Python script,
I inject an arbitrary
URL
in the web server thing,
and then what I'm actually putting at the end
is a Base64 encoded
URL.
My proxy hosted in Amazon
parses that,
goes out and retrieves
the web page I asked for,
and then returns it
inside that status code,
and I wrote a shim on the other side
that picks it up and parses it all.
In
23 lines of Python code.
It's really
that easy.
Now, think about this. I am inheriting
all the firewall rules.
How do I prove that at the only place on
Earth this could have come from was their server?
Well,
you can add to your Amazon EC2 rules
that the only IP address on the entire world
that can connect to that server that I'm serving
is their IP address.
Why did I do that?
Because if you've got third-party IR companies
trying to sniff around your stuff and you don't want them
finding it, putting up firewall
rules that prevent them from ever looking at what your
payloads look like is a pretty good idea.
So, again, I've
whitelisted ScreenConnect.com including domain
names. So now
it's basically an open network
tunnel.
So if you want to build a content filter bypass
or just run a proxy, you can do
the same exact thing. Now, here's
why it's important to inherit
all these firewall rules. If you're in a
highly secure critical infrastructure environment,
many times the only
IP address or network traffic you are allowed to
pass outside the house is to the
remote management software.
Anything else gets dropped. Anybody else run
their stuff like that? A lot of people run that, especially in
high availability environments.
So now that I have this available, I
can now tunnel out to the internet and hence
the world via that status
code. It's the only
IP it can go, so I put something up in my Amazon
instance that picks up the request and does
all the HTTP stuff.
Right? Not a bit
of social engineering so far,
which was their big concern. Oh, you need
social engineering for all of this. No.
So all you really need to do is start
a free EC2 server. I
prefer elastic ones because
they are anywhere and you can sign up anonymously
and don't cost you a dollar.
You just host this scripting
out there, make a firewall rule that says
the only thing it can attach via HTTP
on port 80
is this. Serve that code
and you win.
So I've been serving
malicious POC and assigned executables
to their cloud instance since January
2023. My warning
to you is this. Whatever you do,
and I seriously mean this because I'm not that guy.
I'm an ethical go-by-the-books person.
Do not click that URL
or put it in while you put
the Xs in because if you do, it will install
without clicking a remote install agent
on your computer. And
it's a frame, right? I can inject that via frame
without ever downloading, right?
So let's talk about social engineering. What is social
engineering? Tactic of manipulating,
influencing, deceiving a victim in order to gain control,
steal personal financial information,
it uses psychological
manipulation to trick users into making
security mistakes, right?
So if I can register your old
domain,
send somebody that cross-site
scripting payload, and load it off
of what used to be your FQDN,
that's barely
social engineering.
The agent doesn't have any framing invitations,
right? So why not
start injecting a frame instead?
So my
payload is actually
serving an iframe.
But I use
the hidden tag, right?
You inject the frame,
it automatically downloads, all
of that gets bypassed. That's
literally how you do it. It's barely social engineering
at this point, right?
So what if you have some company sniffing around your
work and you don't want them finding it?
Well, the simple elaboration for Tradecraft is
just to use the hidden tag. So if anybody
actually finds that page, they won't actually see it.
And the psychological trick of all of this
is what? I have total
control of the HTML content in there.
It doesn't check CSRF
any of that to get requests.
So I simply just started rewriting the web page.
At the
bottom of that it says, please wait
while the PortConnect client is downloaded
to your computer. So my trick is
I send it to a port test page and say it's
an installable port testing module.
They download the agent and
it loads on my machine, gives me full system
access to the endpoint.
Don't believe me?
Give this video a watch.
So this
is me grabbing
the URL as if I would send it to somebody,
putting it in here
and literally it's the same thing you're seeing.
See how it says 666? I'm
just showing you what the URL is. There's no tricks up
my sleeve. I'm not playing any games.
Hit enter.
And I'm showing you this.
All of the antivirus is turned
on on this computer. All of the
controls are there.
It just downloaded.
Open it up. I'll refresh
it here just to show you that's how it
downloads. Open it up.
That's the HTTP request
executing. I'm
going to show you the details and you're going to see
that's all the content I put in there. I
injected from my server.
Watch it one more time. Here's the
important part. See this
right here? You'll see it in a second.
I need to
hurry up about six months ago on this.
That's signed by their
controlled thing. Running that
it looks fine.
And now what am I doing?
I'm waiting for my attacker
to connect to the machine.
Because it's calling back to my rogue connect
wise instance in their cloud that I signed up
for anonymously and it's loading
up stuff on their computer.
As system.
That's how it's done.
Like I said,
thank you.
There it is.
And literally from this you now have access to everything.
You load everything up and if you go back and read
the Iranian APTs this is exactly their trampoline
and everything else.
It will either stay once or if on my end I just
click persist.
Maintain a shell. It will do it.
Cool. Thank you for the applause.
That was a moment for me because I worked
really hard on this and it was a really rough time.
I successfully exploited it.
But there's more.
I'm not telling
everything. I'm just going to show you some stuff.
Connect wise
applications even beyond this use
a client application
that is really just a
wrapped web browser.
You can figure
this out by looking at their web page and they
parse what the user agent tags are.
That client is absolutely
exploitable because it's an old browser
but nobody realizes
it's a browser so
there are tons of ways of going
through connect wise, not this, the other parts
of the system to deliver
client side exploits
without user interaction.
That's one thing.
I'm not sharing that yet because it's
cool and it's another cool thing that nobody's ever done before.
Now I want you to think, and this is the
important part, I want you to think about this
as application developers.
Who leaves
debugging symbols on when you compile code?
So the
click once installer that they provided
if you carve through the metadata
software bill of materials, software
supply chain attacks, all that stuff I do
what they've left in here
was the absolute drive path
including username for the profile
source, stream connect work
misc, bootstrapper,
release, click once runner.
The source is where
the source code is stored.
Right? I have
a username of somebody who can
actually get to that and compiles
it. I know what
they're doing and I'm going
to mic drop after the next slide
on this. There is
a lot of metadata embedded
in their software and applications
that will allow you to map their internal
network.
This is the thing I'll come out is
I love attacking developers and I love
exploiting developer weaknesses because
you all have something like this.
So, wrapping up.
Should companies, and this is where
it comes down to, this is all cool, this is new stuff, whatever
it's like, one, should
companies be responsible, and that's the question I get,
responsible for their own disclosure analysis of
vulnerabilities? I don't know.
I can tell you that I shouldn't
have been the person that registered the CVEs and it certainly
wasn't overblown in my eyes.
So here's my trick I'm going to tell you. Learn how
the CVE system reporting works.
So if a company is a
CNA and they won't
give you your CVE, what you can do is
go to MITRE, who's a CNA of last resort,
and they'll issue it to you if you're correct.
Which is why I went to MITRE.
So if you're a bug hunter
or somebody who's doing this and the program
won't give it to you, you can just go to MITRE and say
rectify this for me.
Yes,
you were just certified, yes.
Follow that.
A magic bullet
of this isn't a big deal won't fix anything.
All of you need to start
thinking holistically how the system gets put together.
Because like I said, it's an application
problem, it's the network problem,
but it's really a lack of understanding.
Two last things, I'll get off, give me two
seconds. Bug bounty programs
and responsible disclosure are totally killing employment
in the industry because why would anybody hire
you full time when they can get the milk for free?
Or for a t-shirt and 500 bucks?
If you want more jobs in this
industry, stop taking the quick payday.
Put your CVEs that you register
on your resume and that is money that will
pay off on your salary for the rest of your life.
Trust me,
I've got hundreds. Last thing, I'll
say this, ask yourself
this, I'm not a bad person, I don't turn bad,
but think about it this way as all of you.
If I have to stare these people down,
fly out to Las Vegas, do a press
whatever, just for a few
words of acknowledgement on a website, why
would I ever help them again?
Think about that as an application designer.
Be more open.
Thank you very much guys, that puts everybody else at risk.
Thank you very much, I appreciate it.