Hello and welcome to the side. Very secure coding course my name miss anywhere, and this is sans Top 25 category. Risky resource management.
Now, as we review the Sands, Top 25
realized that all 25 issues air actually grouped into three main categories. Category one. Insecure interaction between components category. Too risky Resource management and Category three Porous defenses.
This module focuses on that risky resource management. You see the rankings listed in this category below 3 13 14 16 18 2023 24
Now several of these items we have already covered in the Buffer Overflows module. If you take a look at this chart, you can see that Rankings 3 18 2023 24 have already been addressed. So please go back to Module 11
if you need to review any of that information.
So that just leaves us with three areas to cover in this module
rank 13 which is C W E. 22. Improper limitation of a path name to a restricted directory.
Ranking number 14 C W e. 494 Download of code without integrity check
and ranking 16 to C W E 8 29 Inclusion of functionality from untrusted controls fear so first and overall definition for this category. The risky resource management category identifies weaknesses
related to improper handling of system. Resource is
by software. Such handling includes creation, usage, transfer or destruction. When you think of system resource is concrete. Lee. You can think in terms of a directory, for example, or file system.
So first, let's go into our ranking number 13. See W 22 Paths Reversal
Realize it's called many things. It's called directory Divers A ll, also called the dot dot slash attack.
Basically, what we have here is a manipulation of the euro
to execute either to execute an arbitrary
a file that's been uploaded or to execute
but or could be done to reveal or access the contents of files, directories or any other information that may be available on the Web server.
An explanation for ranking 14 c W e 4 94 Download of code without integrity check.
This is where we don't have any kind of validation being done or verification, if you will, of a particular class or jar file or d allow that we're using inside of our program. That's generally that verification is generally done with some sort of check some because you're not
performing this level of validation or very
to ensure that this class is loaded by the authority or by the source that you believe it to be. It's going to allow for the loading of attacker control classes, order files or deal l's instead,
in the code that you see there, you can see that we're actually really creating a new U R L
based on a file that we get out of a subdirectory
and, of course, loading that up through the class loader.
Now. Possible attacks in this category in this module can include malware payload delivery, as we just saw by not doing any kind of check some or any kind of verification of your source that can allow for the opportunity for malware too easily be
loaded into a program.
Another possible attack is path manipulation. This can come in the form of file system manipulation,
where we don't canonical eyes our paths prior to doing validation against them. Also, it can relate to Web server directory paths, and we'll see that in the demo
now the combination of these can lead to information, disclosure, information leakage, and we'll see that as well. Mainly, This is the viewing of information by unauthorized access.
And then finally, denial of service in this through the exhaustion of system Resource is now our case study is on the Department of Homeland Security. That actually fell victim to a path reversal attack. What happened was wth e
d. H s site was using WordPress
and wordpress has a lot of plug ins and the WordPress. It has been susceptible to a lot of vulnerabilities over the years because of these plug ins.
In this particular case, the path reversal attack allowed hackers to obtain the contents of the main configuration file that used for WordPress. Now, inside of that file, they have, of course, their table names, their database connection, user name and password so
as well as some other damaging information.
Now, because th s didn't want other companies or other users to fall victim to the same attack,
they for educational purposes actually published all of this information on the Web site that I give at the bottom of the slide.
But you can actually see the line where the vulnerability takes place. If you look at the vulnerability line
at the very end, you see the download dot PHP. Question mark file equals. We're going to see this in the demo also. So all you have to do is on the next line, do your dot, dot, slash and go back up to the WordPress config.
So there's a wordpress config dot PHP that was then able to be viewed.
And so you're going to see as well in the demo how this type of attack can actually be exploited.