Web Shell Upload via Content-Type Restriction Bypass - Sottotitoli bilingue per YouTube

Web Shell Upload via Content-Type Restriction Bypass - Sottotitoli bilingue

In this video, we're going to take a look at one of the file upload vulnerability labs on Port Sugo's Web Security Academy.

The lab is called,

web shell upload via content type,

restriction bypass, and we'll start off by having a quick recap of file uploaded vulnerabilities before we dive into the practical lab.

I'm over in the learning material section now on the web security academy in the file uploaded vulnerabilities section,

and I'll try not to spend too much time here because we have done some videos already on file uploaded vulnerabilities,

so the video with the first lab will have covered some of this theory already.

So what are file upload vulnerabilities?

They occur when a web server allows users to upload files without sufficiently validating things like the name, the the contents, or the size.

Failants properly enforce restrictions could mean that a basic image upload function could be used to upload arbitrary and potentially dangerous files instead.

This even include server-side script files that allow remote codec security.

In some cases,

the active upload in the file itself is enough to cause damage,

other attacks may involve a follow-up HTTP request for the file to trigger the execution by

the So there are generally two key factors to consider when assessing the impact of file upload vulnerabilities.

The first is the aspect of the file that the website fails to validate, so is it the size, the type, or the contents?

And the second are the restrictions that are imposed on the file once it's been uploaded.

So our worst case scenario is the file type not being validated properly.

This might mean that we can upload some malicious code,

so for example, if you have an image upload on a website, perhaps you can upload an avatar or something.

You could have uploaded an image,

but it doesn't actually make sure that the file you're uploading ends with.jpg or .png,

and instead you're able to upload a PHP file,

and if the server is able to execute PHP,

then whenever you try to view the avatar,

rather than print it to the screen as an image, it will execute the code that's in the file.

So this could allow the attacker to gain control of it.

The second example is the file name.

So if this isn't validated properly, you could potentially use a directory traversal vulnerability.

So we could potentially set the name as like dot dot slash dot dot slash dot slash etc password.

And then whenever you try to view that file,

let's say again,

it's an avatar,

it's going to go and look at dot dot slash dot slash dot slash etc password for the file and hopefully print that to the screen.

And then the final example is the file size.

So by failing to limit the file size,

attackers could potentially upload very large files to the system,

which might crash the server just in trying to do the transfer, or might fill up the available disk space.

So these file upload vulnerabilities arise when validation is inherently flawed or easily bypassable.

For example, developers might use blacklists to prohibit dangerous file types.

So they say you cannot upload a .php file extension to the web server.

But the problem is there are so many different file types that it's hard to find them all.

Generally, it's better to use an allow list and say rather than prohibit in specific file extension, to say which file extensions are safe.

So example, you're only allowed to upload .png or .jpg.

And to give you an example of that, let me just open up the PHP file extensions list.

So here's an example of a list from payloads, all the things.

So even if you say that dot PHP isn't allowed, you would also need to account for these other extensions as well.

And it's just a lot safer to say will only allow dot PNG or dot JPEG or whatever file type you're in.

expected.

Another example of an inherently flawed approach is reliant on client-side validation as a security measure.

So if you have a client-side script which is just making sure that the file a user uploads is a .png file,

all an attacker has to do is upload a .png file, intercept a request in burp, and then change that to .php.

They could also just simply disable the client-side validation or make some changes to the JavaScript.

Unfortunately, even if you do have strong validation measures, so you've got a good allow list and you are validating everything on the

may be discrepancies across interconnected systems which can lead to file upload vulnerabilities.

So, how do web servers handle requests for static files?

If the file type is non-executable, it'll generally just send the contents of the file as the HTTP response.

If it's executable, for example, a PHP file and the servers configured to execute that file, it should execute the script, basically.

But if it is executable and the servers not configured to execute files of this type,

or is not able to, for example, a PHP file on a JSP server or vice versa, then it'll generally respond with an error.

or with text.

So it responds with the source code of the file, then you could potentially use that to leak code and other sensitive information.

We're going to skip the next section because this was the first challenge that we uploaded on file upload vulnerabilities,

which is just exploiting an unrestricted file upload to deploy a web shell.

So you can go back and check that video if you want her more.

What we are interested in is the exploiting a flawed validation of file uploads,

and specifically the flawed file type validation which is related to the lab that we're going to be looking at today.

So this section starts by telling us how the browser deals with submitting HTML forms,

so it will send the data in a post request with a content type of form URL.

And that's fine for simple data,

but for sending large files, so large amounts of binary data, the preferred approach is to use this multi-part form data.

So consider a form containing fields for uploading image, providing a description and entering the username.

It might look something like this.

And we've got an example of a post request then.

So this is going through to the images endpoint on normal website.

And we can see we have this form data.

And the first part of it is the name, which is image, and the file name.

And then we actually have the content of that image with the content typeset as well.

And then the second part of that form is the description of the image.

So then we've got the text for that.

And also the username as well, where we've got the username.

So the message separate parts,

and each part has this content disposition header,

and can also have its own content type header as well, which a server the MIME type of the data.

So one way that websites may validate the file uploads is by checking this content type header and making sure it's the expected MIME type.

So if the service expects an image files, it might only allow image slash JPEG or image slash PNG.

But problems arise when the value of this header is implicitly trusted by the server and no further validation is performed

to check whether the contents of the file or the file extension actually match the supposed MIME type.

So this can easily be bypassed using tools like Okay,

so with that out of the way, let's take a at this practical lab, which web shell upload via content type restriction bypass.

And it tells us that there's a vulnerable image upload function which attempts to prevent users from uploading unexpected file types,

but relies on checking user controllable input to verify this.

To solve the lab, we need to upload a basic PHP web shell.

and use it to exfiltrate the contents of the secret file in the Carlos directory.

Submit this using the button provided in the banner.

So we've got a username and a password, Wiener and Peter, so we'll go and log in with those first of all.

Okay, so we'll go to my account and we'll log in.

Oh, we'll try.

there we go login we can update our email we can upload an avatar so let's go and

do the second one since this is the file upload vulnerability I'm gonna upload a

web shell here just have this default PHP web shell which let me just actually

go and print that out shell.php

very simple web shells with literally just the PHP script which is going to

call system and then it's going to use the get parameter CMD as the input to system.

So if we provide CMD equals LS this is going to replace this bit with LS and then call system LS which is going to do exactly that.

So let's try it let's And we get this message saying sorry the file type is not allowed only image JPEG and image PNG are allowed

Okay, cool.

Let's take this to the burp suite intruder not intruder repeater So I'm going right-click the request that we just sent off and I'm going to send that to

repeater or control and R.

We go through here and we've got this form just like we saw in that example and notice at the moment the content type is set to application x-php which is not one

of these allowed content types.

So we'll change this to image slash jpeg and hit send.

I notice it says it's been uploaded,

so I'm going to go back to the account and I'm going to right click it and say open a new tab.

And it's got this dot PHP extension,

which is always good to see from an attacker's point of view, not so good from a defender's point of view.

And we're going to set the get parameter to command equals, and then let's say LS.

There we go, it's showing shell dot PHP.

We could also take this through to the repeater if we just want to get a nicer interface to work with.

So we can send that there.

We get shell dot PHP, which is awesome.

So we can do now cats.

And I'll do a plus to make sure that you are encoded, and then it was home, call us.

send.

There we go, we get the secret, we go back to submit the solution and we've solved the lab.

up.

So looking at our file upload vulnerability here, really, there's a few things that should have been done.

First of all, the file name is ending with dot PHP.

So there should have been some validation in place to make sure that the file extension here matches an image file extension.

So if this is image slash JPEG, why doesn't this end with dot JPEG?

Another thing that could have been done is checking the actual content type of the file.

So although the content type header is specified here,

you could have something which is checking for the magic bytes,

so the signature of the file, the header of the signature should and should start and end with specific values.

depending on the type of image it is,

you can also do other things like checking exif data as well,

although all of those do have bypasses, but each of these checks will add another layer of security.

The other thing which is important is not telling users whether file has been uploaded to.

So even if this was vulnerable as it is now where we cannot load a malicious shell,

if we don't know where that shell is located,

for example,

if it's in a directory that we don't have access to,

or if the file name has been randomized, something like that, maybe the MD5 hash.

Which is using a salt so we don't actually know what the file name is in that case

There's no way for us to directly access the file and make the server execute up anyway

That's gonna wrap it up for this challenge challenge,

I'm going to recommend that you check out the Integrity Academy where we have done some documentation on some of these vulnerabilities and also links the videos for

the Portsmouth River Web Security Academy.

So we've already got three file upload vulnerability videos.

This will be the fourth.

I'll try and get this category wrapped up and then we'll move on to another one.

I'm thinking maybe JWTs.

But if you have any specific recommendations,

if there's any web security academy labs that you'd really like to see solved, or if there's any of the video types.

let us know and I hope you've enjoyed this video.

If have any questions or comments, leave them down below.

Thanks.

Lingua di traduzione

Seleziona la lingua di traduzione

Sommario video Esporta sottotitoli Valutazione orale

Sblocca altre funzionalità

Installa l'estensione Trancy per sbloccare altre funzionalità, tra cui sottotitoli AI, definizioni di parole AI, analisi grammaticale AI, parlato AI, ecc.

Compatibile con le principali piattaforme video

Trancy non fornisce solo supporto per sottotitoli bilingue su piattaforme come YouTube, Netflix, Udemy, Disney+, TED, edX, Kehan, Coursera, ma offre anche traduzione di parole/frasi AI, traduzione immersiva a tutto testo e altre funzionalità per pagine web regolari. È un vero assistente per l'apprendimento delle lingue tutto in uno.

Tutti i browser delle piattaforme

Trancy supporta tutti i browser delle piattaforme, inclusa l'estensione per il browser iOS Safari.

Modalità di visualizzazione multiple

Supporta modalità teatro, lettura, mista e altre modalità di visualizzazione per un'esperienza bilingue completa.

Modalità di pratica multiple

Supporta dettatura di frasi, valutazione orale, scelta multipla, dettatura e altre modalità di pratica.

Sommario video AI

Utilizza OpenAI per riassumere i video e comprendere rapidamente i contenuti chiave.

Sottotitoli AI

Genera sottotitoli AI precisi e veloci per YouTube in soli 3-5 minuti.

Definizioni di parole AI

Tocca le parole nei sottotitoli per cercarne le definizioni, con definizioni alimentate da AI.

Analisi grammaticale AI

Analizza la grammatica delle frasi per comprendere rapidamente il significato delle frasi e padroneggiare punti grammaticali difficili.

Altre funzionalità web

Oltre ai sottotitoli video bilingue, Trancy fornisce anche traduzione di parole e traduzione a tutto testo per pagine web.