Understanding Security Misconfigurations

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
3 hours 30 minutes
Difficulty
Intermediate
CEU/CPE
4
Video Transcription
00:00
>> Understanding security misconfigurations,
00:00
our learning objectives are to describe
00:00
the various types of security misconfigurations,
00:00
demonstrated a test, of
00:00
various types of security misconfigurations.
00:00
We're going to go back to the web security
00:00
testing guide and then
00:00
explain how to remediate security misconfigurations.
00:00
Let's look at the different types
00:00
of security misconfigurations.
00:00
We took a look at the CWEs that made up
00:00
this category but let's dive in a little bit more.
00:00
Missing appropriate security hardening and
00:00
cross any part of the application stack,
00:00
improperly configured permissions on
00:00
Cloud services. This is a big one.
00:00
S3 bucket is misconfigured is a huge issue.
00:00
You'll see here a security group.
00:00
If you've done any work with AWS cloud services,
00:00
you'll know that this is
00:00
a security group here on the right.
00:00
What happens is by default,
00:00
you may have these ports open to the world.
00:00
That's if you look at 1, 2,
00:00
3, 4, 5th column,
00:00
you can say here was 0 dot 0 dot 0, whack 0.
00:00
That means that anybody can access these ports,
00:00
port 22, port 80, port 443.
00:00
If you've deployed an EC2 instance with SSH open,
00:00
if you've ever looked at your logs,
00:00
you can see a whole lot of people who have
00:00
tried to log in to SSH,
00:00
tried to brute force SSH,
00:00
because you've made it globally accessible to the world.
00:00
That's something attackers look for is SSH,
00:00
because if they can log in to SSH on your server,
00:00
they have full access now to your server.
00:00
AWS, even in their documentation,
00:00
you can see I've provided the link,
00:00
tells you that's a bad idea to leave
00:00
SSH open to the world.
00:00
Also, unnecessary features are enabled or installed.
00:00
Default accounts or their passwords.
00:00
Let's say you've misconfigured
00:00
your EC2 instance will go back to
00:00
AWS and you have Hue running.
00:00
You can see Hue on the right here hue
00:00
is running on this and port 8080.
00:00
Well, all your ports are accessible now
00:00
and Hue should probably something
00:00
only accessible internally,
00:00
but now it's accessible externally because you've
00:00
misconfigured it to be globally accessible.
00:00
You can see here, the first time you log into Hue,
00:00
you set the person's username
00:00
and password for the superuser.
00:00
That is a configuration
00:00
setting that a developer or someone who's deploying,
00:00
Hue should know that they need to
00:00
quickly enable or use
00:00
a username and password to create their account.
00:00
Otherwise, anybody who accesses it will have
00:00
access and superuser access to that console.
00:00
If you know anything about Hue,
00:00
you can actually run commands
00:00
and achieve remote code execution within the Hue console.
00:00
Be aware of that also that that's true with
00:00
default usernames and passwords.
00:00
If someone has a default username
00:00
or password or weak username or password.
00:00
For these middleware consoles,
00:00
for things like Tomcat or you can
00:00
deploy things into the application.
00:00
You can achieve remote code execution,
00:00
gain access to the server,
00:00
and do a whole bunch of malicious things.
00:00
I talked about stack traces in the previous lesson,
00:00
but these stack traces,
00:00
error messages can reveal a whole lot
00:00
of information about the configuration of the stack.
00:00
Possibly reveal usernames, possibly reveal passwords.
00:00
There's examples of that out there are
00:00
overly verbose stack traces
00:00
reveal very sensitive information.
00:00
For upgraded systems,
00:00
latest security features are disabled
00:00
or not configured securely.
00:00
Again that's why it's important to know
00:00
whatever software you're deploying,
00:00
knowing about the appropriate configuration settings,
00:00
and making things highly configurable.
00:00
Most people don't know what to do and
00:00
most people will just rely on the default configuration.
00:00
We saw Hue in the previous slide.
00:00
The default configuration is
00:00
for the first person to access.
00:00
It has superuser accounts to create their own account.
00:00
Also, we can lump
00:00
in out-of-date or vulnerable components,
00:00
which is a six of OWASP Top 102021.
00:00
That's another concern as well.
00:00
If you're deploying software that's outdated,
00:00
it could potentially be vulnerable.
00:00
That's another thing, know.
00:00
In addition to knowing your software,
00:00
know whether you're deploying
00:00
the most recent version that software,
00:00
or whether there's any known exploits
00:00
out there for the software you're
00:00
deploying or the version of software,
00:00
I should say as well.
00:00
We'll see that in the demo.
00:00
Let's go to the web security testing guide,
00:00
configuration deployment management testing.
00:00
We want to test our network infrastructure configuration.
00:00
That's things like in Cloud,
00:00
knowing our security groups,
00:00
knowing who can access our EC2 or S3 buckets.
00:00
S3 bucket is being vulnerable.
00:00
It's been huge in the past few years with
00:00
open S3 buckets with sensitive information in them.
00:00
Test file extensions,
00:00
sensitive information backup files,
00:00
that's a big one too.
00:00
I was talking in the previous lesson
00:00
about I wasn't really aware of
00:00
configurations and Chmoding or
00:00
allowing things to be globally readable.
00:00
Some of these backup files
00:00
contain configuration information,
00:00
are talking about things like WordPress.
00:00
If you make that globally readable
00:00
or readable to people on the open Internet,
00:00
they can enumerate a whole lot of
00:00
information about your configuration,
00:00
maybe usernames and passwords,
00:00
settings like that from
00:00
backup files that are misconfigured to be readable.
00:00
Testing HTTP methods.
00:00
Again I talked about things being misconfigured,
00:00
being able to write if you have the put method allowed.
00:00
If you can write to files or modify files on a server,
00:00
you can, again, achieve
00:00
remote code execution and gain access that server.
00:00
Be aware of what methods are enabled on your server.
00:00
Test HTTP Strict Transport and
00:00
make sure you're using HTTPS.
00:00
Testing file permissions.
00:00
I've spoken about that at length,
00:00
about knowing what your file permissions are,
00:00
ensuring that your file permissions are
00:00
correctly allowed or disallowed
00:00
depending on what you're trying to do.
00:00
Here is to testing cloud storage.
00:00
That, that goes back to our S3 buckets.
00:00
Again, I encourage you if you just type
00:00
in Google S3 misconfigurations,
00:00
you'll see a lot of issues surrounding open S3 buckets.
00:00
Of course, AWS has tried to secure
00:00
S3 buckets over the past few years just because of how
00:00
many misconfigurations or how many people have not
00:00
configured S3 buckets correctly
00:00
and allowed sensitive data to be accessed.
00:00
They've done a lot, but it's
00:00
the human element and people
00:00
not really understanding what they're doing.
00:00
Subdomain takeover, that's a big one.
00:00
Test for content security policy if
00:00
there is a content security policy.
00:00
Also testing for error handling.
00:00
These are our stack traces.
00:00
Testing for improper error handling,
00:00
testing for stack traces here.
00:00
Trying to get those error messages,
00:00
trying to see if the error message or overly
00:00
verbose if they do reveal any sensitive information.
00:00
I can tell you in the bug bounty world,
00:00
I've seen some interesting things where stack traces can
00:00
reveal a whole lot of information about databases,
00:00
about the information that's
00:00
in databases about the version,
00:00
about usernames, and things like that.
00:00
Stack traces,
00:00
verbose errors are treasure trove for us as attackers.
00:00
How do we prevent this?
00:00
We want to have
00:00
an automated repeatable hardening process.
00:00
We want to make sure we're hardening
00:00
whatever we're deploying out
00:00
there and minimal platform
00:00
without any unnecessary features.
00:00
Again, it's really knowing what you're deploying,
00:00
what applications you're deploying,
00:00
what software you're deploying out there,
00:00
and understanding what you're doing.
00:00
Have a patch management process
00:00
that's true for outdated and vulnerable components,
00:00
is ensuring that we have the latest patches
00:00
and deploying that into our applications.
00:00
Of course, a lot of people are
00:00
concerned about patch management because it
00:00
might break the application but
00:00
if we have vulnerable applications out there,
00:00
the damage can be pretty severe.
00:00
We'll see that in the demo.
00:00
A segmented application architecture,
00:00
making sure things are segmented from each
00:00
other to try to prevent
00:00
attackers from getting into
00:00
another area and other areas of the application,
00:00
another area of the server
00:00
that could be least privileges.
00:00
If the server is not running as root,
00:00
then you've segmented that whatever user is
00:00
running that application can
00:00
access other parts of the server.
00:00
If they are able to get RCE on
00:00
the server by ensuring that whatever the server is
00:00
running as doesn't have permissions or I should
00:00
say elevated permissions or
00:00
admin permissions or root permissions.
00:00
An automated process to verify
00:00
the effectiveness of the configurations and settings.
00:00
We could talk about dynamic that application
00:00
security testing and things like that.
00:00
Ensuring that we have something out there,
00:00
pen testers to ensure
00:00
that our configuration settings are correct.
00:00
Then attacker can't gain access
00:00
to things based on misconfigurations.
00:00
In summary, we've discussed how to describe
00:00
security misconfigurations, what some of those are,
00:00
how to test for security misconfigurations,
00:00
and ways to prevent security misconfigurations.
Up Next
Scenario: Misconfigured Jenkins Servers
10m
Lab: Misconfigured Jenkins Servers
45m