Urgent CF security update released March 1 2019, for CF11/2016/2018, Part 1

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.

All CF shops are urged to install this update immediately, to implement new protections against a known attack happening in the wild. It's identified in the associated Adobe Product Security Bulletin, APSB19-14, as a priority 1 critical vulnerability.

I will add that I can vouch personally for the significance of the vulnerability, as I reported it to the Adobe Product Security Incident Response Team (PSIRT), and I proposed the fix which was implemented. (I also know what was done specifically to perpetrate the attack, and the very negative consequences of what happened once the server of a client of mine was attacked. You don't want this to happen to you.) I plan to share much more in a part 2 post (now posted, but do see below for the context it builds upon).

(In the meantime, I have tweaked this part 1 since originally posting it, to share more here.)

You can see the new update available immediately in your CF Admin "server updates" page (again in CF11/2016/2018). The technotes (linked to there, and above here) discuss more about what has been changed to address the vulnerability, including new admin defaults and app-level overrides you can make.

(Update: I added the 3 of the 4 following sections after my initial post, to help people with more info before I would get part 2 done: "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?")

A brief introduction to the vulnerability and the fix

Briefly, the concern is that:

• if you have any code that allows file uploads in CFML, such as using the CFFILE tag with an ACTION="upload" (or "uploadall", or if you use the script statements FileUpload or FileUploadAll), as part of a process to receive uploaded files
• and if you allow that to save the uploaded files to a web-accessible folder (always something to fear)
• then further if you have not protected those uploads by checking that the file extension to ensure it is NOT a server-executable file extension (like .cfm, .cfml, .cfc, .aspx, and others)
• and even if you may have added an ACCEPT attribute/argument allowing only certain mime-types (and are relying on CF's default of STRICT=true for such uploads)
• and especially if you may have added a list of whitelisted file extensions in the ACCEPT attribute/argument, expecting that to block uploads of anything but those extensions and/or mime types (not realizing that the extensions were ignored if Strict was set or defaults to true))
• then it is possible for a hacker to upload a file (let's say, an image) that may well BE of that mime type and LOOK like that mime type (passing the "strict" test on mime type) and yet HAVE a server-executable file extension. That would open the exploit. I won't say more than that, for concern of giving away the "keys to the kingdom".

Primarily, this update implements protections in CF that will by default prevent processing of such trojan file uploads (by CFFILE and its script equivalents). It does this by implementing a blacklist of extensions in the CF admin, which you can override at the application level. See the technote(s) above for more detail, and which I will elaborate on in part 2. It also now honors any listed whitelisted extensions in the ACCEPT attribute/argument, even if strict=true.

Should you be worried?

Some may argue that this is not an issue that is so urgent for them. Or they may argue that it's been long known that it's dangerous to allow uploads (at all) to web accessible folders (and they'd be right). And they may feel that "everyone knows" you should check your file extensions to only allow what you want to allow. And that is indeed more classic security wisdom.

The problem is that many folks may not implement such protections. Or again they may be relying on the STRICT feature (added in CF10) to protect them, figuring it would "make sure that an image is indeed an image". The problem is that it does not. Or they may have added whitelisted extensions to the ACCEPT, but it's being ignored is STRICT=true. That's why this new protection is important.

And even if you feel confident that you do not have code doing the above, or feel that you have such protections (checking file extension) already in place, just beware that you might know every line of every template, to say that you don't possibly have code allowing such uploads, to a web accessible folder, and without checking for expected file extensions. I will discuss finding such code in Part 2. The point of this update is that now, if you DO have such code, it is protected from this exploit by default (uploads of files with server-executable file extensions are now blocked by CF unless you tell it to allow them)

I would also point out that you should not take consolation in such a file upload process being "behind a login", as if that reduces the need to worry about checking for/disallowing such server-executable file extensions. Consider first a site that lets users create an account, then on doing that and logging them in, allows them to to edit their "profile" for the site, such as to add a picture or avatar. If THAT code doesn't have a check to block server-executable extensions, it could be exploited. And of course, any site login could be compromised through social engineering, etc., such that that site could be vulnerable if not protected this way. Again the point is that ALL processes to allow file uploads should check to prevent server-executable extensions. The update now does that for you, if you don't think to.

I will add finally that for some folks, this problem may well be mitigated in that you may have a web application firewall (WAF) that is already protecting against such file uploads with server-executable file extensions. FuseGuard does that, for instance. In that case, the feature implemented in this CF update will simply be there as a fail-safe protection

A 3rd update in 3 weeks?

And yes, this is frustrating to some to see that this is the 3rd CF update in 3 weeks, at least for CF 11 and 2016.

They and CF2018 were updated on Feb 12th and because of some unexpected issues, the updates for CF11 and 2016 were removed and replaced with new ones last week, Feb 25.

Sadly, I reported this vuln to Adobe literally on the 25th, just hours after the updates that day had been released. It took them just a couple of days to verify things, concur on the resolution, and implement it. Some will deride this as "a clown show".

I instead applaud Adobe for getting this update out, even though it meant "yet another update" in just a couple of weeks.

More to come

Again, I plan to create a part 2 post tomorrow with much more, though perhaps it may end up being more than 2 parts, as there's a lot to share and which may be of value beyond this one exploit:

• more detail about the vulnerability and what was "fixed"
• how to add further protection from it (especially if you may be unable to implement the update immediately for some reason)
• how to prevent execution of the files used in the attack, if they may already be on your server
• how to find such files, and removing them
• how to find possible shell scripts that may have been implemented
• how to find evidence of calls to such, per web server logs
• how to detect possibly modified code, edited once the attacker was in
• longer term mitigation considerations to protect from such vulnerabilities

What if you can't apply the update immediately, and can't wait for part 2?

If you are seeing this before that part 2 is posted and you can't apply the update immediately (or if you are still on CF10 or earlier, which are no longer updated), I will say that what you want to do, in brief, is:

• first find if you have any CF pages (*.cf*) which execute the CFFILE tag with an ACTION="upload" (or "uploadall", or use the script statements FileUpload or FileUploadAll), as part of a process to receive uploaded files
• then in any such pages, ensure that it checks (or you add code to check) that the file uploaded is NOT allowed to have a server-executable extension

And by server-executable extensions, I mean such as AS, ASP, ASPX, BIN, CFC, CFM, CFML, CFR, CFSWF, DMG, EXE, HBXML, JSP, JSPX, JWS, MXML, PHP, SWC, or SWS, which is the list of extensions that the new update blocks. You may not recognize all of these, and you may not realize why you need to prevent them being uploaded. I will explain more tomorrow.

I will also provide specific code to add to do that check, again if you cannot add the update. (Again, if you DO add the update, that will ensure that uploads of files with such extensions are blocked by default). And as I said above, I will also explain many other facets of dealing with this vulnerability, before or after you may have been attacked.

Conclusion

For now, I need to get to bed. It's been a long day and week. But I fear it may be long days ahead for many, as hackers exploit this on as-yet-unprotected servers, or as people discover they may have been attacked already.

As always, if you need help with all this, I'm available to assist, remotely and hopefully without needing much time (and with satisfaction guaranteed).

Another update since posting this: I have now posted part 2.

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed