http://coldfusion.com logo
Join Slack
Powered by
Hi all, anyone know of active hacks or breaches in...
# lucee
s
Hi all, anyone know of active hacks or breaches in Lucee 6? We are seeing intermittent mitigations by our virusscanner for PHP/Webshell.ODS originating in the Lucee Tomcat temp directory, as an upload. None of our sites on that server have an upload functionality, except for MASA CMS. I'll ask there as well, but assumed it would be something in Lucee itself, as the file does not occur in the webcontext of any site.
b
I think any mutlipart form post sent to Lucee will result in the uploaded files written to the temp directory.
✅ 1
So long as the app isn't doing anything with them, it's prolly not a issue
🙏🏼 1
But may be worth reviewing some web server logs to track that down
👍🏼 1
s
Yeah, none of the Tomcat logs show anything being done and IIS either, but I'd like to know how they got there in the first place 😉 All uploads are behind a login, nothing publicly facing, but maybe there is an undertow somewhere allowing unchecked uploads. Searching for answers here - needle and haystack kind of thing. Working with knowledgeable people, hopefully they can help track it down. For now our virus scanner seems to "catch 'em all", but not knowing the source makes be a bit giddy.
b
A hacker doesn't need to hit a page expecting an upload
Any and all form posts to LITERALLY ANY file with a multipart context type will cause the form fields to be processed
👀 1
Cf doesn't wait until you use the cffile tag or file upload BIF to actually transfer the files to the server
They are sent in the bytes if the request body and processed into a temp folder long before your CF code even runs
When you call the cffile tag or file upload BIF that just copies the temp file somewhere
So it doesn't matter if you consider a page of your site to be an "upload" page or not.
Lucee will process any request body to any page that is a post
If you don't do anything with the uploaded files, then they never leave the temp folder and are usually deleted after the request
So the hackers in question are likely just spamming servers hoping your server will place uploads into a web accessible directory or try to pair it with an LFI (local file inclusion) exploit
s
OK, will take a look at code to see if we have any multi-part forms, but as there are login-screens almost everywhere, that qualifies for your information that Lucee will process the file request. But we do not do anything with the data that is uploaded, except for username/password checks, so I assume this will continue to be an annoyance for the time being.
b
No
You don't need the form to exist in your app, lol
That's just what the hacker sends in the request
Anyone can send a post with a multipart content type to any page via postman, or any http client
I could send it to your home page or login page!
s
Learning new stuff here!
🏫 1
b
😁
I'll admit, I used to think file uploads didn't process and transfer to the server until I ran the CF code to accept it. The CF code is just a little smoke and mirrors that hands you the tempnfile already waiting.
📣 1
👍🏼 1
s
So you're saying this is unpreventable and very annoying, but as long as there is no process behind it taking the request and placing it in the webroot, there is no harm no foul. But keep a vigil eye / watch anyway? 🙂
Just leave our virus scanner to it then, it is doing it's job!
b
Basically, yes
But if its one offending IP you could maybe block it
s
Yes, that is a path we're exploring, trying to pin down the source and then block it in the firewall.
b
You could start by logging unexpected post multjpart requests in your onrequeststart to see what shows up
💯 2
d
So you can test this behavior using cURL: https://medium.com/@petehouston/upload-files-with-curl-93064dcccc76 Try pushing an multi-part form to your home page (or some page that you know does not do uploads). You should see the file get upload 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.
👀 1
🙏🏼 1
👍 1
b
Check the request method and request content type header and log the cgi scope and form field names
s
Extra logging is key, that it true, otherwise with the default logs nothing particular shows up on the given times in the virus scanner logs.
b
Your IIS or apache logs would show a POST but that's about it
s
OK, thnx to both of you, this old dog just learned a few new tricks 😄
d
I definitely found it counter intuitive that a multi-part form would get uploaded to the server, even if there is no cffile / to process the upload, but this is really done for resource management. My understanding is the multi-part data is basically streamed to disk so it doesn't eat up memory.
I could be wrong in my understanding...
s
I'd always assumed as well that as long as there is no form to upload, there is no recipient. Boy can one be wrong, but happy to learn something new. Will sure spread this knowledge to fellow developers!
b
I had thought that issue was fixed with https://luceeserver.atlassian.net/browse/LDEV-4047. Looking at the ticket history, it looks like it may have been re-introduced (and/or may be Windows-only)
s
Hi Brian, for us it is not the case that we have orphaned temp-files in the Lucee temp-folder, so what you mention does not apply here. Thnx.
b
If you're using CommandBox, Undertow uses an exchange end listener to remove file uploads. So unless Lucee copies them elsewhere, they won't persist. But it's definitely up to the servlet
> My understanding is the multi-part data is basically streamed to disk so it doesn't eat up memory. Yes, and no. It can be streamed wherever you want-- in memory or on disk. Some libraries let you configure the size of the files before they flow over to disk. The servlet spec doesn't cover how to get file uploads- it simply provides the stream of bytes to read, and it's up to the servlet implementation to decide how they want to do it. In the BoxLang Miniserver, I use Undertow's utilities. In the BoxLang servlet runtime, I use a small Java library called 
commons-fileupload
. I think Lucee and Adobe may have custom implementations of this and I'm fairly sure they write all files to disk just as a matter of course.
This all has little to do with the reason form fields are process prior to the CF portion of the request. In a servlet world, the headers are parsed by the servlet container and made available in the (Http)ServletRequest object, but the request body is left for the servlet application to process when it feels like it. (Well, there is a get parameters method, but it combines the query string and form fields.) In fact, in the typical servlet application, you declare what servlet mappings in your 
web.xml
will even accept a FORM post and kick in form parsing of the request body. If the request body is never read, then most of the bytes are probably buffered somewhere along the way, based on whatever network layers exist in front of it. Generally speaking however, CF • Funnels all traffic through a generic servlet mapping which always allows POST requests • CF always parses URL encoded form fields and multi-part request bodies regardless prior to your CF code running since it doesn't really know what code is going to run • Part of this is so the 
form
scope is available, as the form fields are also stored in the request body in a URL encoded format, so if the request body isn't processed, you can't see any of your form fields! • CF always just does this proactively at the start of the request to keep things simple and ensure all the HTTP data is ready to go before CF even starts running for the request
Streaming to disk is more of a tactic to prevent massive file uploads, or even a large amount of small file uploads from using up available heap.
a
We’ve seen this elsewhere in fact we saw it on lucee download server
Do you have any kind of WAF that you can front your app with Cloudflare is great as it relates to filtering known dodgy traffic
p
Cloudflare has a WAF but you have to pay for the good features.
s
Thnx @bdw429s for the thorough explanation of internal workings of the servlet and upload streams!
5 Views
Open in Slack
PreviousNext
Powered by