Demo: Insecure Design

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
1 hour 33 minutes
Difficulty
Intermediate
CEU/CPE
2
Video Transcription
00:01
>> Let's talk about insecure design.
00:01
Obviously, I'm not speaking
00:01
with the developer right now,
00:01
and I don't want to pick on any developers,
00:01
but I basically went on Exploit DB
00:01
and tried to find a vulnerability
00:01
with an unrestricted file upload
00:01
or file upload of a dangerous type,
00:01
which is in insecure design.
00:01
I found this application.
00:01
Now, the purpose of this application
00:01
is to be able to upload files.
00:01
It's a file manager it's built on php.
00:01
As a pen tester,
00:01
I know that php typically is
00:01
something that I like to see because
00:01
it's very easy to exploit
00:01
or find vulnerabilities within php.
00:01
The goal is to upload a file
00:01
that allows me to perform command execution,
00:01
which we talked about a little bit in injection,
00:01
which is Number 3,
00:01
which we just talked about.
00:01
In that vein, I actually found
00:01
a cross-site scripting payload
00:01
in this application in
00:01
addition to the unrestricted file upload.
00:01
If we look at the page source,
00:01
we can see there's a link home to ft2.php.
00:01
What if I put a forward slash?
00:01
I see something changed here,
00:01
which is a pen tester.
00:01
It means something is broken or
00:01
I've done something that might lead to something more.
00:01
I can't see anything yet,
00:01
but I see this h ref tag.
00:01
What I can try to do is close out
00:01
the h ref tag and create my own tag,
00:01
so cross-site scripting image we just
00:01
talked about this source equals x.
00:01
Let's do on error because we have no x image.
00:01
On error equals, I know I hate alert boxes.
00:01
Let's do confirm which isn't
00:01
really no better and close this out,
00:01
confirm one and see if anything happened.
00:01
We can see not,
00:01
and we can see then this is how we test.
00:01
I need to close this thing out here.
00:01
What I can do is close this out and
00:01
we see that I got cross-site scripting to
00:01
fire and we see our image here.
00:01
If we actually look at the source of the page,
00:01
we can say I closed out my h ref,
00:01
closed out this here,
00:01
our link, and then I started
00:01
my cross-site scripting payload here and it worked.
00:01
That's the fun I get to do as a pen tester.
00:01
But let's go back to
00:01
the unrestricted file upload or
00:01
file upload of a dangerous type username, password.
00:01
I bet you can never guess what it is.
00:01
We see that we can upload
00:01
files here in our home directory,
00:01
so if I browse,
00:01
this is a command shell here,
00:01
so I can execute commands on
00:01
the server if I needed to upload it,
00:01
I know that this application is built using php,
00:01
so I'm going to use the same language,
00:01
php then I try to upload it.
00:01
Well, I see the file type is
00:01
not allowed. Well, that's good.
00:01
It's blocking that,
00:01
but I'm a pen tester and
00:01
security folks should be
00:01
integrated as early as possible,
00:01
so let's see what other types of
00:01
files that we can upload.
00:01
I can upload a command zip.
00:01
I bet you can never guess what this is,
00:01
but I've zipped up my php file
00:01
and let's see if I can upload it.
00:01
I'm able to upload my command shell,
00:01
and this is nice function in here to unzip.
00:01
If I unzip, this is my php file.
00:01
Another good security practice is to put this into
00:01
a folder where if I'm doing a black-box test,
00:01
I can't tell where it is,
00:01
but one thing I can try to see and
00:01
guess is maybe it's in the web route,
00:01
so if it's in the web route then I could do command.php.
00:01
As you can see here,
00:01
I have the command parameter print working directory.
00:01
I can see that it looks like I've been able
00:01
to do our CE perform command execution ID,
00:01
and from here I can try to get
00:01
my reverse shell and get on the server itself.
00:01
But let's see how this application was designed.
00:01
If we look at config.php,
00:01
this is more of a white box testing or clear box testing.
00:01
If we look at Line 28,we can
00:01
see what files you're not allowed to upload.
00:01
We know php.
00:01
The developer thought of all the php files possible,
00:01
but they didn't think about the zipped files,
00:01
and what happens if you zip a php file and then unzip it.
00:01
Something, an error or an issue,
00:01
a insecure design practice that
00:01
occurred in developing this application.
00:01
That's to show you that maybe something like
00:01
file scanning is important looking
00:01
for php tags because I can tell
00:01
you if you look
00:01
at this file or if it's scanned,
00:01
even though it's zipped,
00:01
you can see here the php tag,
00:01
and this is the solo command shell.
00:01
This is the hard malicious code right here.
00:01
If the application scan for php tags in zip files,
00:01
it would have found this and blocked it,
00:01
but it doesn't perform any scanning like that.
00:01
This is again where you get
00:01
a developer and you get security folks or a bunch of
00:01
developers and security folks into
00:01
a room and discuss what malicious actions,
00:01
what the application is intended for,
00:01
and then people like me try to poke holes at it and say,
00:01
well, have you thought about X, Y,
00:01
and Z as far as how
00:01
an attacker can exploit this application.
00:01
Again at CWE pertinent
00:01
to insecure design the unrestricted file upload.
00:01
We get to see a little bonus
00:01
there with a cross-site scripting payload
00:01
and a little bit about my methodology
00:01
in pen testing this application.
Up Next
Scenario: Insecure Design
10m