Hi all, I was wondering if any of you have a system in place to mitigate rouge uploads to Lucee? We have an issue where a spammer is uploading a PHP-shell script to our webserver via any Lucee-page it can find. So the file is uploaded to the Lucee temp-folder, but as there is no process doing anything with it, the file just stays there until the virus scanner on the server screams "bloody hell, get that thing outta here" and deletes it. But this sometimes goes wrong, and then the virus scanner shuts off all network traffic and a reboot is required. So do you have any suggestions on how we can proceed from this? I've understood that this is just how the web and the servlet world works, thnx 4 this info from Brad Wood @bdw429s and Dan Switzer @dswitzer. Logging has not yielded any useable information, neither from IIS, Tomcat or Windows. But our ISP does not agree and asks us to do something about it...

How are they doing that upload exactly? Lucee doesn't inherently have a mechanism to upload arbitrary files, and "any Lucee-page" doesn't either.

To quote a colleague: So you can test this behavior using cURL: https://medium.com/@petehouston/upload-files-with-curl-93064dcccc76 Try pushing a multi-part form to your home page (or some page that you know does not do uploads). You should see the file get uploaded to your Lucee temp folder. As for it being a security risk, the one way it could be an issue, is if there is a path transversal bug in your code. Then a user could upload the file and potentially trigger execution of it.

Dave: This was recently discussed in September, basically by default most web servers will automatically download any file sent via a 'submitted form' and drop it into a temp upload directory. Then the web server passes the results to Lucee/ColdFusion/PHP whatever for continued processing. Most likely some sort of firewall rules would need to be added to try to cut down on accepting the files before it gets processed.

Yes, what Patrick S. says. After explaining to the ISP what happens in the servlet / web world, they still want to look for a better solution than we have now, that the virus scanner sanitizes the upload if it is dangerous. as they cannot pin down the IP-address (or it changes all the time). Hence my question if this issue is something you've encountered and found or implemented a solution for.

Interesting, wasn't aware of that. Creepy. Watching...

That was my experience and feeling as well, done this work for 20+ years, never realized it worked this way...

Does ColdFusion do this too?

You should be able to block uploads through your front-end web server (IIS/Apache/etc), since it is handling the traffic

AFAIK it is universal for any servlet based system.

I use Traefik for a lot of my sites. Uploads are blocked by default, except for a few REST endpoints I allow.

FYI, Here's the prior conversation link: https://cfml.slack.com/archives/C06TA0A9W/p1727275980585619

Well TIL. One key point being that you can't allow direct web access to the temp directory, which we knew, but good reminder.

As far as I understand it, this process does not give direct access to the temp directory, as it is the servlet that does the action here. So therefore it is not directly a threat as it is being played out on our servers, but very annoying.

This process itself doesn't provide web access, but you need to make sure no mappings, redirects, etc inadvertently let a site visitor access anything in that temp directory.

Just tossing out an untested idea here. Could you put in a check in you Application.cfc file, onrequest (start/end?) function to see if there is a form element and, if so, check if there's an attached upload file and then just abort the process/send them to an error page if the file matches whatever criteria you want?

I could give that a try sometime, see if I can narrow each request down to being a form request with an upload. Might work in situations where it is not wanted, but would hinder sites where an upload is allowed.

maybe whitelist those targetpages in a conditional statement?

@Jim Frankowski No, because by the time your first line of CF code runs, the servlet has already processed the incoming request and written the uploaded files (if any) to a temp folder. You could delete them at that point if you wanted to, but I doubt it will keep the overactive anti-virus from complaining.

OK, thnx 4 chiming in again! Will take a look at the IIS-rules to block multi-part POST's to websites, along the lines of the Apache-suggestion. We have some already in place to rewrite and block access to Lucee-folders.

It won't prevent bad actors from uploading malicious files to a real file upload form on your site, but it will prevent them from just spraying every page on your site with upload tomfoolery

Right, 'cause that's what's happening now. Adding the IIS-rules will also help us to pinpoint what the entry point is now, which website, 'cause logging cannot see that now. Adding rules one site at a a time we'll have a check in place when the regular uploads actually stop.

BTW, a good WAF should help with this as well. You are all using a WAF for your production sites, right? 😉

For now we are going with a logging feature of our virus scanner, so we can pinpoint exactly what requests are coming in when the rogue uploads are being executed. This helps us hopefully in getting more info on the unwanted upload-attempts. At least we will be able to see the entire request from start to finish and define where to intervene (if possible).

Typically you would think knowing where they are coming from would matter. But most of the time with these sort of shotgun attacks they are attempted by bot nets and they will change each time. Typically they are trying discover secrets on your system as well as trying whatever they can to bring you into their fold.