Brian__
Explorer
Brian__
Explorer
Activity
‎Dec 24, 2024
11:14 AM
Thank you Satyam! A high compliment!
... View more
‎Dec 23, 2024
08:12 PM
1 Upvote
As others have already mentioned, there's a lot of good information in the Tech Notes/FAQ. I've written up some initial thoughts and analysis on the vulnerability, along with additional recommendations and potential controls - https://www.hoyahaxa.com/2024/12/an-initial-analysis-of-cve-2024-53961.html
... View more
‎Sep 30, 2024
08:46 PM
1 Upvote
I'll add one more vote for the recommendations and comments from @BKBK @Charlie Arehart and @dwaynek27338072 that this probably an issue for Tenable Support. Tenable is now commercial closed source, but I have a hunch that the host-baed ColdFusion-related checks haven't changed much since the open source Nessus days, if at all. After looking at some old Nessus code, it appears that this may be an issue with expected extra zeros used as padding for the ColdFusion version numbers and patch numbers. This also appears to be likely since the real CHF is chf20210016.jar and the "missing file" is chf2021000006.jar. Some relevant Nessus code related to expected filenames is also preceeded by the following comment 🙂 : # this is all undocumented and, at best, an educated guess
... View more
‎Jul 28, 2024
07:27 PM
+1 to Charlie and BKBK's comments that the effort to move to a supported platform is going to be worth it for the security benefits alone. That's the best path forward. With that said ... Some of the original technical analysis of CVE-2023-26360 mentions the NeoTranslator compiler as being a component used during exploitation. And at least one source mentions disabling the NeoTranslator compiler as an alternate workaround if you're unable to patch -- without giving specific details -- but does offer the caveat that "it will also prevent you from using some features of ColdFusion." The NeoTranslator compiler is used to convert CFML source into Java classes -- which is a pretty core part of the ColdFusion engine functionality. I'm unaware of any supported/official way to "disable the NeoTranslator compiler". There could be some hacky ways to do it (I have no idea what would work or if it would be effective security control) -- but then you'd also need to find a way to convert your legitimate CFML source into Java classes. Maybe you could pre-compile your code, but it just all seems like a convoluted path. If your host is vulnerable to CVE-2023-26360, it's also vulnerable to Critical vulnerability CVE-2023-26359 (and subsequent variants CVE-2023-29300, CVE-2023-38203, CVE-2023-38204, and CVE-2023-44353) -- as well as other ColdFusion security patches that have only been released for CF2021 and 2023 (but also mpact <= CF2018). There are a number of things you can do to lockdown a ColdFusion system if you're really unable to patch, but that choice will come with a significant amount of accepted risk. I will say that blocking remote HTTP/HTTPS access to *.cfc files (which will break/block access to all remote CFC components) will break exploitation of many recent critical ColdFusion vulnerabilities.
... View more
‎Jun 13, 2024
06:57 AM
Haha - thanks Charlie, but I can't take credit for the CFMX_COMPAT change. That one wasn't me. 😄
... View more
‎Jun 11, 2024
01:07 PM
1 Upvote
@Charlie Arehart As far as I know, none of the encrypted passwords in CFAdmin use CFMX_COMPAT. I can say with certainty admin login and RDS do not. And - acknowledging the work to find and refactor impacted code – I’d applaud breaking changes with the end goal of a more secure default environment as a good thing (albeit a painful process). Vulnerable legacy code that runs on a fully-patched platform is still vulnerable code. On the CFMX_COMPAT change specfically -- The new default algorithm of AES/CBC/PKCS5Padding is probably the best choice, but it’s now also very important for developers to check the integrity of any user-controlled ciphertext (for example, if it’s passed in a cookie or a URL parameter) with an HMAC or similar technique to avoid padding oracle vulnerabilities. Pardon the shameless self-linking 🙂 , but I’ve written about padding oracles and CFML previously for those who may want a little more detail - https://www.hoyahaxa.com/2023/07/on-coldfusion-aes-and-padding-oracle.html
... View more
‎May 07, 2024
06:18 PM
Depending on your ColdFusion stack and development environment, ColdFusion Security Analyzer may be included (but not technically free) if you're using ColdFusion Builder. And Foundeo Fixinator is relatively inexpensive, depending on your needs/volume. I've done a little bit of work on some simple grep-based SAST for ColdFusion/CFML described here -- https://www.hoyahaxa.com/2021/06/two-one-liners-for-quick-coldfusion.html. It's admittedly more a "collection of sharp objects" rather than a fully-functional tool -- and it's noisy/prone to false positives (to be sorted by human review) by design. I haven't released anything than the few snippets in that article. It's possible (but unplanned at this time) I may release a real tool in the future, although I've alternately considered working on better support for CFML via semgrep instead. Re: SBOM, I have not used Syft or Grype before, but I have used commercial container and image scanners that have flagged vulnerable packages in ColdFusion and Lucee.
... View more
‎Dec 06, 2023
09:38 AM
Thanks for the mention, James, and +1 to your comment about iedit.cfc and anything else used as a filemanager/means to upload files. (Pete Freitag's CVE-2018-15961 is an example of the underlying risk here.) And the general risk for remote access to .cfc files extends beyond CVE-2017-11286. Many of the recent recent ColdFusion vulnerabilities related to cfclient, WDDX and deserialization -- including CVE-2023-26360, CVE-2023-29300, and several in APSB23-52 -- just require remote HTTP access to _any_ .cfc file. The public exploits for CVE-2023-26360 and used iedit.cfc because it was a publicly-accessible CFC file, but that could also be swapped out for any other .cfc. Avoiding remote CFC methods and blocking remote access to .cfc files goes a long way toward preventing access to codepaths with a history of vulnerabilities.
... View more
‎Oct 19, 2023
12:49 PM
@cat_zilla13 Thanks and those are all great questions. Maybe someone from Adobe will chime in with definitive answers versus what I've been able to figure out by feeling around in the dark. > While it is true that wsconfig now creates backups of the modified files when creating a new connector, > doesn't reverting to an older connector sort of defeat the purpose of upgrading Tomcat? I believe that you should be able to upgrade ColdFusion (which will upgarde Tomcat) and just not re-create the connector. Or revert back to the old connector library and config if you do re-create it and then want to go back. AFAIK, this won't revert to the older version of Tomcat. (You won't get the added security of the new connector, but it also won't block /CFIDE access.) > You state that URIs beginning with /CFIDE are blocked in the new connector. Is that inherently built in > to the new library? Or is it a config setting somewhere that can be disabled? Yes, this is compiled into the newest versions of mod_jk.so and isapi_redirect.dll. I'm unaware of any ways to bypass these checks built into the new connectors.
... View more
‎Oct 18, 2023
01:56 PM
@neowire and Charlie - I've observed the same the new connector behavior you both mention. The release notes don't say much about the new connectors, but they do state "Wsconfig update now creates a backup of the modified files." I haven't gone through a ColdFusion upgrade to either new release, but I can say that running a "wsocnifg -update ..." on a new CF2021U11 server will back up the connector config files and library. So reverting to these backed-up files might be the best way to revert if needed. (@neowire it sounds like you went that route in restoring the previous DLL...) However - for those that don't need remote access through a connector to CFAdmin, this is a considerable security improvement. I've shared some more thoughts on that here - https://hoyahaxa.blogspot.com/2023/10/coldfusion-connectors-and-cfadmin.html
... View more
‎Oct 06, 2023
01:07 PM
If you trust the download file and want to allow execution anyway, there are instructions on how to bypass that check here - https://support.apple.com/guide/mac-help/apple-cant-check-app-for-malicious-software-mchleab3a043/mac
... View more
‎Oct 06, 2023
09:30 AM
I see that the CF2023U5 release notes has the Mandatory IP restrictions item, but this item is absent from the CF2021U11 release notes (and bug CF-4219181 is offline or inaccessible). Does this change only apply to CF2023R5 and not to CF2021U11? I have some more thoughts on this, but I'll just say for now that this is a great config tweak and one that everyone should make to all ColdFusion environments, even manually if you have to do it.
... View more
‎Sep 13, 2023
08:02 PM
Bump to an old thread. 🙂 I've added a note to the Bug ID in Tracker too, but this is not a bug. This is how CFMX_COMPAT works (and why it's insecure). The key/seed used for encryption is only 32 bytes (4 characters) and is derived from the user-supplied key. See https://www.synacktiv.com/en/publications/coldfusion-cfmx_compat-lolcryption.html and https://hoyahaxa.blogspot.com/2023/05/why-you-dont-want-to-use-cfmxcompat.html for more details. Using a stronger algorithm (such as AES-CBC + validating the integrity of the ciphertext with an HMAC prior to decryption) is a better way to go.
... View more
‎Aug 17, 2023
02:38 PM
Yup. Thank you, Charlie, for explicitly calling that out, in case my original comment was unclear. My thoughts on this relate only to inbound HTTP requests directly to CFCs (and are not related to calling functions in CFCs internally, from within other CFML code.)
But I'd also go as far as to say if you *are* using direct HTTP access to CFCs today for incoming APIs, AJAX calls, etc., the longterm security benefits of moving to a different approach may very well be worth the effort required to do so. (And if you're really unable to do that, inbound requests should be strictly validated to ensure the format is *exactly* what you are expecting / have verified is "good" traffic, in addition to the ColdFusion server security controls that are available.)
... View more
‎Aug 17, 2023
01:38 PM
Ever since CVE-2023-26360 in APSB23-25, I've spent *a lot* of time looking at how CFCs work from a security point-of-view. The attack surface (all of the different points where an attacker could breach a system; and the entry points, sources, and sinks for user-controlled data) for CFCs is significant. While the new controls here are an improvement that will provide significant protection, my gut recommednation is to prevent untrusted access to *all* CFCs -- which would apply to any CFCs that are web-accessible even if they provide no remote methods. Extreme? Maybe. Uninformed in terms of "...but that's necessary part of xyz crucial CF innerworkings" ? Maybe too. But I'd bet that approach is very likely to provide automatic, immediate defense against the next (unknown) future attack path related to CFCs.
... View more
‎Nov 09, 2022
02:01 PM
I haven't seen all of the XML-related secuirty updates and new options that are available to ColdFusion functions after APSB22-44 pulled together and documented anywhere, so I wound up do just that in a blog post -- https://hoyahaxa.blogspot.com/2022/11/on-coldfusion-xxe-and-other-xml-attacks.html You can now add protection against XXE (XML eXternal Enities) attacks in xmlSearch() and xmlTransform() in ACF, but need to do so with a minor code change. isXML() and xmlParse() already supported this, but not all of the Adobe function documentation has been updated yet. With some details on XSLT/xmlTransform() errors and Lucee info too!
... View more
‎Oct 21, 2022
11:43 AM
Hi Eric, I'm the external person who reported this vulnerability to Adobe and can provide a little more information. I believe this item ("Unable to process the XML string as it could probably contain file paths") is being tracked as CVE-2022-42340. (They're both similar, but the other one -- CVE-2022-42341 -- is a straightforward lack of protection for XXE. I may blog more about that one in the future.) As far as I'm aware, CVE-2022-42340 is limited to an XLST injection against XMLTransform(). You are correct that the current patch appears to break/return that error for / or \ characters anywhere in an XSL stylesheet, including your example of the closing </xsl:stylesheet> tag. I've brought this to Adobe's attention and mentioned it here: https://twitter.com/hoyahaxa/status/1581261198187958272 I don't want to speak or provide guidance in terms of absolute security, but if your application calls to XMLTransform() are not consuming XSL stylesheets that can be provided by/controlled by the user or other untrusted sources, exploitation of this vulnerability may be unlikely or impractical. And it goes without saying that any additional context, insights, or support from Adobe on this supersedes the above. 🙂 Brian
... View more