[Looking for Charlie's main web site?]

CF security update (March 1 2019), part 2: further details, prevention, and more

Note: This blog post is from 2019. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
This is my part 2 post which follows onto the Part 1, released the night of March 1, when the new CF updates were released as an emergency update. If you've not yet read that, do that first, to get some basic info and needed context for what follows.

And if you HAVE already read part 1, if it was before Saturday morning, do go back and reread it. I had added some important info that I thought shouldn't wait to Part 2, which I knew could take me a while. See especially the sections there, "A brief introduction to the vulnerability and the fix", "Should you be worried?", and "What if you can't apply the update immediately, and can't wait for part 2?".

And my apologies for the delay in getting part 2 out. For various reasons, including related to additional research work I'm doing on this exploit beyond CF, I was unable to post this then. Better late than never, I hope. Indeed, I had listed quite a lot in Part 1 that I hoped to cover in a part 2. I don't want to delay getting this out any later, so I will get done today what I can and post that, and carry over into a part 3 (or beyond) whatever remains. There are some natural breaks, fortunately. Thanks for your patience.

Following are what I cover here in Part 2:

  • More detail about the vulnerability and what was "fixed"
  • Wouldn't an antivirus package on the server detect this sort of trojan?
  • How to add further protection from it (especially if you may be unable to implement the update for some reason)
  • Considering running a security scan of your CFML code
  • Consider implementing a web application firewall
  • How to prevent execution of the files used in the attack, if they may already be on your server
  • Another benefit of applying the latest updates
  • What about Lucee?

[....Continue Reading....]

Comments
Hello Charlie. Do you know if Lucee has an equivalent admin setting for limiting the file extensions?
# Posted By Andrew Myers | 3/4/19 9:28 PM
Andrew, see what I wrote above, "What about Lucee?"
Thanks Charlie. I skimmed it and didn't realise that the "Blocked file extensions for CFFile uploads" was a new option in the Mar 1 patch.
# Posted By Andrew Myers | 3/4/19 10:01 PM
Hi Charlie,

The recent CF 11 Patch 18 has broken our production website. Would you happen to know if the new patch does any inspection of the URL string or URL variables and sanitizes or removes them if they look suspicious?

We have a process which encrypts the URL variables, combines the URL string, creates the encrypted target URL, redirects there, and then decrypts the URL on the subsequent page load for processing by ColdFusion. However, on some URLs which worked before the update certain URL variables are now missing, causing our application to fail. I'd greatly appreciate your thoughts on this matter.
# Posted By James Fullerton | 5/9/19 9:50 PM
CF11 update 18 would not have. It was very limited in what it changed.

But CF11 updates 17/16 changed many things, and yes, I am aware of an issue that sounds like yours: https://tracker.adob...

Sadly, there is no fix offered, and it's even closed by Adobe, though people are pleading there to re-open it. There is code provided that shows what's not working, and you can test it to see if you experience it--then see if what it discusses might relate to the kind of error you are having.

BTW, you say you went to "the latest", but it would help to know what update you came "from". You can look at the cfusion/hf-updates folder to see folders which indicate the numbers of previous updates attempted. (There may be jar's there which reflect updates that were downloaded but may not have been attempted.)
Hi Charlie, thanks for getting back to me.

That link you posted is pretty much what we encountered. One of our guys found the article as well and was the impetus for our fix. The solution was to switch from URLencodedFormat to the EncodeForURL function on all of our web pages.

We did come from CF11 Patch 16, then Patch 17, but did not catch the issue in our testing. This was likely due to our PreProd and Testing environments having a smaller sub-set of data compared to our Production system. In Production, there were only certain URLs that caused the issue. They likely had a % character in them, or something similar, causing the issue. Those records did not exist in PreProd or Test so it slipped by.
# Posted By James Fullerton | 5/13/19 11:13 AM
Did you ever get around to writing Part 3? I tried searching but don't see it.
I don't think so. Time passed and it seemed less pressing. Let me know if something seems helpful now even nearly 4 yrs on.
I mean, let me know if something seems helpful to FOLLOW UP on, of course. I might then consider a part 3, or just perhaps a bit more here.

And if anyone getting notifications about these is no longer interested, not there's a link in the email to unsubscribe from the notifications about this post.
I think all the "how to" bullets at the end of the article would be interesting to read even now. And even though this vulnerability is patched, there might still be other way that a hacker could get malicious code onto a server. An article on how to identify such files would be an interesting read.
Fair enough. I'd think each could be their own part, which is why I'd not done it. Maybe fodder for some videos I'm planning for the new year. Hope to point to them here if I do them.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting