Hello and welcome to another penetration testing execution Standard discussion Today we're going to talk about example avenues of attack within the exploitation section of the Pee test standard.
Now quick disclaimer Pee Test videos do cover tools and techniques that could be used for system hacking, so any tools discuss or demonstrated should be researched and understood by the user.
Please research your laws and regulations, and you're given area to ensure that you're not violating any regulations through the use of such tools or techniques. While we're having fun, we don't want to get into any trouble with the law. So what are the overall objectives of today's discussion?
We're simply going to go through and describes him different types of attacks. And so we're gonna look at Web application,
USB drive deployment, memory based exploits, and we're going to look a C V E for GPU cracking. And so
again, these are just four of many different types of attack vectors. We're just going to go through some common ones
now. Web application attacks are common, and they're probably one of the better ways to get into systems where organizations have Web facing. Resource is and so cross site scripting is typically not sophisticated and can be executed with tools or scripts,
and it involves getting the site to execute arbitrary or malicious script code.
Did an attacker up loads? And so this is one of the OSS top 10
SQL injection most common form of SQL injection of crows. When an attacker enters malicious SQL code into a field on a Web page and the server side code submits it to the database without properly sanitizing it first,
also very common within the WASP testing methodology, SQL injection and cross site scripting or some core ways that Attackers commonly
bypassed things like Pharrell's and just get straight into the back end servers and are able to pull database tables and things of that nature
and then expose sensitive information
paths traverse A LL. Is the ability to access unauthorized files or directories outside of the Web root holder. This could lead to credential exposure and other forms of data exposure. So with Lennox space systems and things of that nature, we've got directories that we don't wanna have exposed to the world. Local file inclusion is when an attacker uses directory reversal
or a similar mechanism to induce the Web application executed file residing elsewhere on the server.
So all of these are common Web application attack types. Now, remember when were talking about denial of service and distributed mile of service attacks
we can use in this case multiple systems to overload the server or resource. In some cases, there are exploits out there that, when acted upon, they will cause a denial of service type, symptom or response from the server.
We always wanna have explicit permission before doing these types of tests, or if we're going to discuss on do denial of service test, and we may want to replicate the environment and do testing against that, too. Then validate a proof of concept or an exploit as being able to
induced denial of service conditions. And so always keep that in mind when, when thinking about this and reference your rules of engagement and your scope of work
now use B and flash drive. Deployment is great for social engineering type attacks, and so malicious code is the first area here where the attack provides that USB drive that is full of juicy information, and it's got documents on him. But it contains malicious code or directions to download malicious code from a remote site.
Now social engineering, unlike malicious code. In this case, we may try to get the user to go to a fake site
and ask them to provide credentials to then steal those credentials. Now,
if that exposure is is approved and you're able to take that type of information or attempt to get that type of information, this is a great way to do it. Human interface devices spoofing or hid spoofing is when we
take a device, and we tricked the computer into thinking that, like a USB devices a keyboard and then injects keystrokes that provides the attacker with remote access. And so,
ah, lot of systems. Now, if you attempt to get it to essentially plug in and execute
particular code like a batch file or run something like that, it will generally be blocked. Eso This device essentially mimics a keyboard, which is normally a trusted device on the system, and it will again mimic keystrokes and allow for access to the system.
Now memory based exploits we've talked about,
I think, in two different discussions already. But buffer overflows are essentially where improper coating Take me Captain's. This usually occurs in a program where right stated to a buffer and then overruns. The buffer boundary begins to overwrite portions of memory, but there are protections in place to to try and prevent that in those systems.
But those protections in themselves can be
so convenient with some debugging sth over right. We've already talked about as well, where we run into structured exception handlers that begin to grace for close the application. And then the attacker manipulates that to gain control of the application. So those air some core memory based exploit methods as well,
now ran across graphics processing unit cracking in a C. V. E. Here from 2016 thought that this was very interesting. So essentially, in this case,
um, this is on android based systems and it mishandled some flags, and it allows the attacker to essentially gain privilege our privileges by leveraging accidental read, write mapping a k Qualcomm Internal bug. So this is referencing a specific but
read a really good proof of concept on this, where the person essentially mapped
some areas of memory to this particular driver and was able to get the GPU to essentially execute commands that they were passing through to it. So
again, the limitations of the tester are really bound by their imagination and capability.
And so this is just a potential attack vector in the many, many different ways that we could get into a target system really were kind of bound by time and scope of work and rules of engagement restrictions in most cases.
And so let's go ahead and jump into our summary. So we described Web application attacks,
USB flash drive deployment type attacks, memory based exploits and GPU cranking, and the way that that looked as well
again. Each of these attack vectors and types is going to be bound to your scope of work and your particular rules of engagement. Always take those into account before doing anything and get client approval if you think that a system they crash in the process and ensure that it's covered in your scope of working rules of engagement.
So with that in mind, I want to thank you for your time today,
and I look forward to seeing you again soon