|
mllaneza posted:There is no VHDL PDFs
|
#
?
Dec 17, 2021 20:19
|
|
big enough, that's an amazing hack. 
|
|
| # ? Jun 12, 2024 03:40 |
|
|
Laughing at our HR blasting out “get ready for the holidays, today is a surprise half day, enjoy everyone!!” to the entire company while half of it is going to continue working through the weekend
|
|
#
?
Dec 17, 2021 20:24
|
|
|
Martytoof posted:Laughing at our HR blasting out “get ready for the holidays, today is a surprise half day, enjoy everyone!!” to the entire company while half of it is going to continue working through the weekend Just forward it to your boss with the message "I'm turning my phone off"
|
|
#
?
Dec 17, 2021 20:25
|
|
|
Martytoof posted:Laughing at our HR blasting out “get ready for the holidays, today is a surprise half day, enjoy everyone!!” to the entire company while half of it is going to continue working through the weekend Yup... My boss now wants us to scan every desktop in the environment for any potential apps running log4j. I've tried to explain that if the attacker is actually able to get onto a desktop and input malicious code to an app running on the desktop than its already game over. Not saying its not worthwhile to document these apps and to work on getting them patched as necessary, just that it shouldnt be a work over the weekend priority. I am tired.
|
|
#
?
Dec 17, 2021 21:04
|
|
|
Anyone seen much about this? https://www.blumira.com/analysis-log4shell-local-trigger/
|
|
#
?
Dec 17, 2021 21:15
|
|
|
Martytoof posted:Laughing at our HR blasting out “get ready for the holidays, today is a surprise half day, enjoy everyone!!” to the entire company while half of it is going to continue working through the weekend is surprise half day code for 'a bunch of people sent us positive civic tests and we don't wanna admit it so we'll send you home and hope it doesn't spread'?
|
|
#
?
Dec 17, 2021 21:16
|
|
|
text editor posted:is surprise half day code for 'a bunch of people sent us positive civic tests and we don't wanna admit it so we'll send you home and hope it doesn't spread'? Once you test positive for Civic you're stuck with it for at least 250k miles 
|
|
#
?
Dec 17, 2021 21:21
|
|
|
rafikki posted:Anyone seen much about this? https://www.blumira.com/analysis-log4shell-local-trigger/  This still reads like a user needs to get directed to a malicious site AND have software running a vulnerable version of log4j. So it definitely sucks a bunch, but isnt quite the all week waking nightmare that this week has been. BaseballPCHiker fucked around with this message at 21:26 on Dec 17, 2021 |
|
#
?
Dec 17, 2021 21:24
|
|
|
Right? That seems like kind of a big deal and I haven't seen chatter about it in my usual haunts.
|
|
#
?
Dec 17, 2021 21:25
|
|
|
Ah my edit came in after your quote. BaseballPCHiker posted:This still reads like a user needs to get directed to a malicious site AND have software running a vulnerable version of log4j. So it definitely sucks a bunch, but isnt quite the all week waking nightmare that this week has been.
|
|
#
?
Dec 17, 2021 21:27
|
|
|
BaseballPCHiker posted:Ah my edit came in after your quote. Oh, yeah but still I wonder about things like advertising networks and their code being spread all over the internet.
|
|
#
?
Dec 17, 2021 21:30
|
|
|
It's a good thing users never click phishing links.
|
|
#
?
Dec 17, 2021 21:34
|
|
|
BaseballPCHiker posted:Yup... If you're a Defender shop, they just added Log4j support. We found one hit in our environment.
|
|
#
?
Dec 17, 2021 22:04
|
|
|
BaseballPCHiker posted:Yup... Having a RCE vector on your machine is something that should be closed ASAP
|
|
#
?
Dec 17, 2021 22:51
|
|
|
BaseballPCHiker posted:Yup... This is wrong, actually. Inputting malicious code could be as simple as sending an email with an attachment that has the jndi string in a metadata field of a file that gets opened by the user. You don't have to be able to already be executing some kind of code, or be able to send arbitrary network messages. It really depends on the application what the attack surface really is. fake edit: i had part of the log4j string in my post, and cloudflare blocked it, lol
|
|
#
?
Dec 17, 2021 22:55
|
|
|
BaseballPCHiker posted:This still reads like a user needs to get directed to a malicious site AND have software running a vulnerable version of log4j. So it definitely sucks a bunch, but isnt quite the all week waking nightmare that this week has been. if a user has something like dev work on a java app or a vulnerable thing running on localhost: yes you can spray requests containing the jndi string to localhost:everyport. there are already malicious ads that load this type of script. there is a ublock origin filterlist that is under 'privacy' for blocking localhost access from third party origins. fwiw: this type of sweep against localhost is actually used actively by many major sites as part of trying to stop scrapers and break anonymity, lol
|
|
#
?
Dec 17, 2021 23:57
|
|
|
Fart Amplifier posted:Having a RCE vector on your machine is something that should be closed ASAP I agree. I just don't want to work over the weekend and I don't think it's as bad as log4j on some web facing server. spankmeister posted:This is wrong, actually. Inputting malicious code could be as simple as sending an email with an attachment that has the jndi string in a metadata field of a file that gets opened by the user. I will admit that my 4 month old has kept me up all week and that I may not be firing on all cylinders but are we talking about the same webhooks exploit? My read was that a user would have to be directed to a malicious site and be running a vulnerable version of log4j. Biowarfare posted:if a user has something like dev work on a java app or a vulnerable thing running on localhost: yes you can spray requests containing the jndi string to localhost:everyport. there are already malicious ads that load this type of script. Ok but again they need to be directed to a site containing malicious code though right? I think I need to just take a break and get a nap in.
|
|
#
?
Dec 18, 2021 00:04
|
|
|
If you go to a website that's showing a punch the monkey ad, even if you never click on the ad, you're running code from the site that created and placed the ad. If you're wanting to block access to sites that could run malicious code, you're talking about blocking just about the entire internet because all of them run ads and most of them aren't exactly selective about where they get them from
|
|
#
?
Dec 18, 2021 01:06
|
|
|
So for log4j v1, the "solution" is to "audit your log4j.properties or log4j.xml files" to make sure JMSAppender isn't configured insecurely. Should be easy enough to run a script to find and search log4j config files for JMSAppender config lines.... anyone got a script or do I need to try my pathetic PowerShell script skills.
|
|
#
?
Dec 18, 2021 20:09
|
|
|
Jabor posted:If you're wanting to block access to sites that could run malicious code, you're talking about blocking just about [...] all [...] ads Way ahead of you 
|
|
#
?
Dec 18, 2021 20:15
|
|
|
is there going to be a 2.18 before christmas
|
|
#
?
Dec 18, 2021 20:19
|
|
|
CVE-2021-4104 - reading the CVE at https://access.redhat.com/security/cve/CVE-2021-4104 and the bugzilla page https://bugzilla.redhat.com/show_bug.cgi?id=2031667 , it reads to me like version 1 is not really a remote exploit at all? A commenter on bugzilla points out it requires that JMSAppnder be enabled in log4j.config, but also that remote exploits require that additional settings in the file be set locally to point to an attacker's site: pre:"you can execute a command only by putting it in the properties TopicBindingName or TopicConnectionFactoryBindingName. For example: log4j.appender.jms=org.apache.log4j.net.JMSAppender log4j.appender.jms.InitialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory log4j.appender.jms.ProviderURL=tcp://localhost:61616 >>>log4j.appender.jms.TopicBindingName=ldap://host:port/a >>>log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://host:port/a" Lastly the script should make the config file read-only by *anyone* including the application. I'm sure someone's already figured this out a long time ago but I am home with a sore arm since I got my booster yesterday. Does this hold together? Did I gently caress up somewhere?
|
|
#
?
Dec 18, 2021 20:52
|
|
|
The issue at https://issues.apache.org/jira/browse/LOG4J2-3230 now has a CVE (CVE-2021-45105). From the log4j security page: quote:Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack. Probably a good idea to upgrade, again. Unless you are using context lookups, it can probably wait until regular business hours though. Esran fucked around with this message at 22:32 on Dec 18, 2021 |
|
#
?
Dec 18, 2021 22:27
|
|
|
I'm so tired of this and even more tired of trying to learn enough java to parse our java codebase to understand if we're using context lookups to understand the actual applicability of this.
|
|
#
?
Dec 18, 2021 22:55
|
|
|
I think it's referring to the first item on this page https://logging.apache.org/log4j/2.x/manual/lookups.html So you might be able to just scan your log4j2 config for "ctx". Hopefully you don't have to read too much of your Java codebase to find the logging config.
|
|
#
?
Dec 18, 2021 23:05
|
|
|
Thanks! I have our devs on a new bridge checking. I think of everything, I'm tired of being the bad guy slash messenger here.
|
|
#
?
Dec 18, 2021 23:30
|
|
|
Does deleting the jndi class file not cause an error/crash when the function is called?
|
|
#
?
Dec 19, 2021 17:36
|
|
|
Bob Morales posted:Does deleting the jndi class file not cause an error/crash when the function is called? in general you can expect that no, given that it is remediation advice in specific, i expect that transformers are all loaded and then run on each input string. if the class for making jndi strings do stupid poo poo doesn't load, that means the strings don't do stupid poo poo. remember how this works: nobody's calling "look up external poo poo to load please." they're just logging a string, and that string is searched for format strings to be replaced recursively. one of those format strings is the problematic jndi type. since no variable is provided for interpolation for this type of transformer, there's no change in number of arguments either the above could be 100% wrong, but that's what i've gathered from generally knowing how this sort of software works. i don't know that it _actually_ works this way though
|
|
#
?
Dec 19, 2021 17:53
|
|
|
Achmed Jones posted:and that string is searched for format strings to be replaced recursively. This is the problem right here and it blows my mind nobody thought this was a terrible idea.
|
|
#
?
Dec 19, 2021 17:57
|
|
|
Bob Morales posted:Does deleting the jndi class file not cause an error/crash when the function is called? Based on these it sounds non-issue. https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 https://github.com/apache/logging-log4j2/commit/3203d3eab6bdd12fdad7ded1860db16a89468c3f
|
|
#
?
Dec 19, 2021 18:22
|
|
|
lovely Log4j v1 scannerpre:$Drives = Get-PSDrive -PSProvider 'FileSystem'
foreach($Drive in $drives) {
gci -Path $Drive.root -rec -force -include log4j.config,log4j.xml -ea 0 | foreach {select-string "log4j.appender.jms" $_} | select-object -Property Path, LineNumber, Line | ft -HideTableHeaders
}
pre:N:\log4j.config 1 log4j.appender.jms=org.apache.log4j.net.JMSAppender N:\log4j.config 2 log4j.appender.jms.InitialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialCont... N:\log4j.config 3 log4j.appender.jms.ProviderURL=tcp://localhost:61616 N:\log4j.config 4 log4j.appender.jms.TopicBindingName=ldap://host:port/a N:\log4j.config 5 log4j.appender.jms.TopicConnectionFactoryBindingName=ldap://host:port/a Rust Martialis fucked around with this message at 21:00 on Dec 19, 2021 |
|
#
?
Dec 19, 2021 20:57
|
|
|
We ran the script that peeks inside jar files for JNDILookup.class and yeah, some apps repackage class files. Thought you could just look for log4j-core-2.x.jar? Nope!pre:C:\Program Files\Commvault\ContentStore\Base\DbJars\DbArchiveEngine.jar C:\Program Files\Hewlett-Packard\CSArobocopy\Tools\lib\CLI-lib.jar D:\apps\elk\7.4.0\logstash\vendor\bundle\jruby\2.5.0\gems\logstash-input-tcp-6.0.3-java\vendor\jar-dependencies\org\logstash\inputs\logstash-input-tcp\6.0.3\logstash-input-tcp-6.0.3.jar
|
|
#
?
Dec 19, 2021 21:05
|
|
|
Amusingly enough, a Palo Alto with a threat prevention license and running decryption will prevent this page of this thread from loading, just off the example snippets present.
|
|
#
?
Dec 19, 2021 21:57
|
|
|
The myriad ways of obfuscating the attack would get past your ngFW but would also be unreadable
|
|
#
?
Dec 19, 2021 22:04
|
|
|
Rust Martialis posted:The myriad ways of obfuscating the attack would get past your ngFW but would also be unreadable But enough about my posts
|
|
#
?
Dec 19, 2021 23:39
|
|
|
Martytoof posted:Laughing at our HR blasting out “get ready for the holidays, today is a surprise half day, enjoy everyone!!” to the entire company while half of it is going to continue working through the weekend Rust Martialis posted:We ran the script that peeks inside jar files for JNDILookup.class and yeah, some apps repackage class files. Thought you could just look for log4j-core-2.x.jar? Nope! evil_bunnY fucked around with this message at 00:49 on Dec 20, 2021 |
|
#
?
Dec 20, 2021 00:46
|
|
|
I’m still trying to understand how I am somehow at the centre of our incident response despite not being remotely involved in secops or incident response in like three years. I mean I’m happy to pitch in and I’ve got extensive historical info on this place, but I guess a lot more handoff needs to happen.
|
|
#
?
Dec 20, 2021 02:18
|
|
|
Martytoof posted:I’m still trying to understand how I am somehow at the centre of our incident response despite not being remotely involved in secops or incident response in like three years. Everybody else said "not it!" first. 
|
|
#
?
Dec 20, 2021 02:20
|
|
|
Absurd Alhazred posted:Everybody else said "not it!" first. I have a lot of things I can’t say due to NDA but this one gets a lol out of me
|
|
#
?
Dec 20, 2021 02:21
|
|
|
|
| # ? Jun 12, 2024 03:40 |
|
|
Martytoof posted:I have a lot of things I can’t say due to NDA but this one gets a lol out of me Glad I could bring a shred of levity to what I'm sure is a stressful time!
|
|
#
?
Dec 20, 2021 02:22
|
|