Malicious attachments through support tickets

[Jordan]

This past week I've a person (the IP i managed to catch today was from 83.xxx.xx.14 (sorry I don't feel that the IP needs to be protected that much, considering what it was used for. I'm leaving the first and last.) to send in a fake support ticket, and attach a "s.php" file, which whmcs then outputs it as a "s.php.gif" file. This person then executed the file on my server, which was.. well, not pretty to say the least.

 

What can I do with the current (non beta) version of whmcs to make sure that files that aren't gif/png are NOT uploaded through the attachment option?

 

I can't risk this happening again, because it's really causing some major problems right now

[DataHosts]

****Edited to protect IP posted in message****

[Matt]

To stop any attachments being uploaded, remove the 777 permissions from the attachments folder. Please open a ticket about the issue you've had so it can be investigated. One thing puzzling me, how would the user be able to execute the file with an extension ".php.gif" as a PHP file on your server? Wouldn't it just display a broken image symbol when accessed?

 

Matt

[Jordan]

I honestly have no idea, but whatever s/he did, it definitely executed because the server ended up having background processes running after it was accessed.

 

I'll go ahead and open up a ticket about it, and include the activity of what happened.

 

Thanks Matt.

[generic]

what i see happening now in my beta v3 beta 2 is that you can upload ANY file no matter what the extension is, whmcs is just stripping off the extension if it is not allowed, but the file is still uploaded.

 

 

so...

if its an allowed extension it uploads correct and you can see the file and extension in your admin area.

 

if its an non allowed extension, the file is still uploaded but the extensionis stripped fromthe file name.

[Matt]

if its an allowed extension it uploads correct and you can see the file and extension in your admin area.

 

if its an non allowed extension, the file is still uploaded but the extensionis stripped fromthe file name.

No, that's not how it works. If the extension is not in the list it doesn't get uploaded, if it is, it does. ".php.gif" with ".gif" being in the allowed list would be uploaded.

[MACscr]

if its an allowed extension it uploads correct and you can see the file and extension in your admin area.

 

if its an non allowed extension, the file is still uploaded but the extensionis stripped fromthe file name.

No, that's not how it works. If the extension is not in the list it doesn't get uploaded, if it is, it does. ".php.gif" with ".gif" being in the allowed list would be uploaded.

 

Matt, how about it looking for files with double periods in the filename. My mailserver already filters this, but it would be nice to have this for people that upload at the support desk as well.

[Matt]

Yep, could do that. So more than one period and the attachment is blocked.

 

Also, it should be possible to remove execute permissions from the attachments directory so no files in there could be executed - even though I'm still not sure how a .php.gif could be.

 

And for the V3 release, I'll make it so you can specify where the attachments folder is thereby making it possible to put it outside of the publically accessible folder tree.

 

Matt

[MACscr]

Yep, could do that. So more than one period and the attachment is blocked.

 

Also, it should be possible to remove execute permissions from the attachments directory so no files in there could be executed - even though I'm still not sure how a .php.gif could be.

 

And for the V3 release, I'll make it so you can specify where the attachments folder is thereby making it possible to put it outside of the publically accessible folder tree.

 

Matt

 

All great ideas. Now we just have to be insecure for a few days until v3 is out. LOL, jk =P

[tbenoit]

Yep, could do that. So more than one period and the attachment is blocked.

 

Careful with this. There are valid file names with more than 1 period:

 

filename.tar.gz

filename.tar.Z

filename.tar.UU

filename.tar.bz

 

Probably more out there, but those are the 4 I can think of right off the top of my head.

[generic]

if its an allowed extension it uploads correct and you can see the file and extension in your admin area.

 

if its an non allowed extension, the file is still uploaded but the extensionis stripped fromthe file name.

No, that's not how it works. If the extension is not in the list it doesn't get uploaded, if it is, it does. ".php.gif" with ".gif" being in the allowed list would be uploaded.

 

I understand thats how it is supposed to work, what I am saying is that no matter what type of file i upload, it puts a file or link to a file in the ticket.

 

for example when trying to upload a file named launch.ica (and this is not in my allowed extensions) it does not toss an error and the ticket gets submitted. then in the end users ticket i see a link like:

(folder picture) Attachment: /tmp/phpzBH5Hm

 

and in the admin area:

Attachment: /tmp/phpzBH5Hm remove

 

clicking on the link produces a file with no extension and nothing in it.

So as you indicate....apparently the actual file is not uploaded, but a link to a "non-existant" file is still there in the ticket.

[bodhisattva]

One thing puzzling me, how would the user be able to execute the file with an extension ".php.gif" as a PHP file on your server? Wouldn't it just display a broken image symbol when accessed?

 

Matt

we dealt with this on some of our sites a few months back.

 

doesn't seem like it should output the code, but php will read it and execute it.

 

on one of the sites we cleaned up they were using some cookie stealing scripts that they embedded in avatar uploads. but really, they can just upload any of the readily available shell scripts and take total control if they can find a way to get it executed, maybe by calling upon it within their own area of the support panel. i'm not positive exactly how the ins and outs of it being executed in WHMCS, but i've seen it done with other scripts, and its very possible.

 

there needs to be more scanning of the files, maybe for certain preg matches, things like <? or <?php, etc.. can also use AJAX for all this. but essentially any site that allows image uploads that doesn't scan or scour the file is prone to being attacked this way if its all within a php environment.

 

granted they don't have other mod_security rules blocking this, but thats only a backup, its not a solution to wide open exploits.

 

btw not saying WHMCS is vulnerable. i haven't tested this.

[Dominic]

Not using chmod 777 won't work, since PHP scripts aren't 'executed' in most circumstances - that'd only stop CGIs and so forth.

 

Yep, could do that. So more than one period and the attachment is blocked.

 

Careful with this. There are valid file names with more than 1 period:

 

filename.tar.gz

filename.tar.Z

filename.tar.UU

filename.tar.bz

 

Probably more out there, but those are the 4 I can think of right off the top of my head.

Each of which can be renamed to have only one period

 

The double-extension thing is an Apache mod_mime 'feature' whereby it'll grab whatever extension it can, and since PHP is added as a mime type to Apache's configuration, and the evilUploadedScript would have a mime type of application/x-httpd-php, mod_mime will pass it to PHP

 

In summary...throw out double-period files (perhaps with a whitelist for examples like the above), and check mime types *and* file extensions

 

IE is also naughty in that it can ignore file extensions and go purely on headers/mime types, which is where that infamous CD-drive-opening .JPG comes from. So checking the validity of the file might also be worth it - there's algorithms out there to check a JPG really *is* a JPG, etc

 

Lastly, every good server should have ClamAV installed so it might be possible to invoke that, though most exploits probably wouldn't be caught I'd expect.

[bodhisattva]

Not using chmod 777 won't work, since PHP scripts aren't 'executed' in most circumstances - that'd only stop CGIs and so forth.

yes, but if you remove upload permissions with chmod it'll stop any attachment from being uploaded. so if they can't get it on the server, they can't execute.

[Dominic]

Not using chmod 777 won't work, since PHP scripts aren't 'executed' in most circumstances - that'd only stop CGIs and so forth.

yes, but if you remove upload permissions in chmod it'll stop any attachment from being uploaded. so if they can't get it on the server, they can't execute.

But what if you want stuff to be uploaded

 

Alternatively a .htaccess file with RemoveType might also work, to disable PHP/etc handling in the directory (just thought of that one now - /goes to add it to upload site )

[bodhisattva]

Not using chmod 777 won't work, since PHP scripts aren't 'executed' in most circumstances - that'd only stop CGIs and so forth.

yes, but if you remove upload permissions in chmod it'll stop any attachment from being uploaded. so if they can't get it on the server, they can't execute.

But what if you want stuff to be uploaded

 

Alternatively a .htaccess file with RemoveType might also work, to disable PHP/etc handling in the directory (just thought of that one now - /goes to add it to upload site )

than by all means do something else, like you've suggested. lol

 

btw, if you test and that works, post the fix for everyone.

[Dominic]

RemoveType  .phtml .php ,php4 .php3 .phps .php5 .cgi .pl

Save that in a file called '.htaccess' and upload it to the downloads directory, and it'll stop PHP execution.

 

Example / proof:

 

http://www....com/nice/ - has the above .htaccess file in. Both scripts should give you a plain text '<?php echo 'Hello World!'; ?>'.

 

http://www.....com/evil/ - no .htaccess file. Both scripts should give you a 'Hello world!'

[bodhisattva]

thanks for sharing.

[bodhisattva]

funny, someone just uploaded something to my site.

 

method used to upload, looks like its some sort've way to get all the valid support dept urls to use?:

 

xx.xx.xx.xx - - [28/Jan/2007:16:45:23 -0500] "GET /submitticket.php HTTP/1.1" 200 2296 "http://www.google.com/search?q=allinurl:submitticket.php&hl=sq&lr=&newwindow=1&start=80&sa=N" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

 

than they attempt to execute by going directly to that folder (not that this is a huge prob, but might be nice to allow us to make the attachment folder any name we want):

 

xx.xx.xx.xx - - [28/Jan/2007:16:50:36 -0500] "GET /attachments/2.php.gif HTTP/1.1" 404 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

[tbenoit]

 

Yep, could do that. So more than one period and the attachment is blocked.

 

Careful with this. There are valid file names with more than 1 period:

 

filename.tar.gz

filename.tar.Z

filename.tar.UU

filename.tar.bz

 

Probably more out there, but those are the 4 I can think of right off the top of my head.

 

Each of which can be renamed to have only one period

 

Well, of course but it's generally difficult to get clients to provide diagnostic information and when they do you want the path they provide that data to be the least resistant possible. Having to name files in a "special way" will not only frustrate the clients but also support staff because if the client doesn't state what the true file name is they Support will have to ask (and wait, frustrating the client) or guess until they get it right (adding to the frustration).

 

 

In summary...throw out double-period files (perhaps with a whitelist for examples like the above), and check mime types *and* file extensions

 

Instead of simply throwing out all double period files, why not simply have a "valid extension" variable (I don't yet use WHMCS, but this may already exist) and have it only allow files that end in those extensions (testing for multiple extensions so things like .php.jpg don't slip through unless specifically on the "valid extension" list).

 

Or maybe even better.....Have every file automatically compressed (.zip or .gz) by the system so it can't be executed.

[Dominic]

bodhisattva - Looks like they've noticed that WHMCS installations are commonly setup incorrectly (I'm assuming there's a whitelist of allowed extensions or something somewhere - haven't got to that part of the configuration yet.)

 

 

Yep, could do that. So more than one period and the attachment is blocked.

 

Careful with this. There are valid file names with more than 1 period:

 

filename.tar.gz

filename.tar.Z

filename.tar.UU

filename.tar.bz

 

Probably more out there, but those are the 4 I can think of right off the top of my head.

 

Each of which can be renamed to have only one period

 

Well, of course but it's generally difficult to get clients to provide diagnostic information and when they do you want the path they provide that data to be the least resistant possible. Having to name files in a "special way" will not only frustrate the clients but also support staff because if the client doesn't state what the true file name is they Support will have to ask (and wait, frustrating the client) or guess until they get it right (adding to the frustration).

 

 

In summary...throw out double-period files (perhaps with a whitelist for examples like the above), and check mime types *and* file extensions

 

Instead of simply throwing out all double period files, why not simply have a "valid extension" variable (I don't yet use WHMCS, but this may already exist) and have it only allow files that end in those extensions (testing for multiple extensions so things like .php.jpg don't slip through unless specifically on the "valid extension" list).

That's what I'd do - specifically, disallow .php[and variants].[anything]

[Matt]

Instead of simply throwing out all double period files, why not simply have a "valid extension" variable (I don't yet use WHMCS, but this may already exist) and have it only allow files that end in those extensions (testing for multiple extensions so things like .php.jpg don't slip through unless specifically on the "valid extension" list).

Yep, this is already done. The problem is ".gif" is in people's allowed list so the file is being allowed to be uploaded.

 

Not that this is a huge prob, but might be nice to allow us to make the attachment folder any name we want

This is a new feature in V3 which will be released very soon. It will also block any files containing the following terms in the filename ".php,.cgi,.pl" as suggested by a user in this thread.

[jdwalte3]

Just wanted to chime in here. My server was compromised this weekend through the helpdesk upload feature...I am running whmcs v.2.5.8. I have disabled the ability for people to upload files through the helpdesk.

 

Matt - I will open a ticket to give you more infomation.

 

Jon

[Matt]

Ok, thanks. Looks like there may be a user targetting the WHMCS attachment system so the V3 update in the next few days will have improved security for this. Thanks to all those who have submitted suggestions and ideas.

[Dominic]

Happy to help - image/file uploading is something I 'do'