2 ms·

Twitter link to a case of the vulnerability being exploited: https://twitter.com/th3_protoCOL/status/1433414685299142660 https://twitter.com/th3_protoCOL/status

Twitter link to a case of the vulnerability being exploited: https://twitter.com/th3_protoCOL/status/1433414685299142660 https://twitter.com/th3_protoCOL/status/1433414685299142660 NIST Link to issue: https://nvd.nist.gov/vuln/detail/CVE-2021-26084 https://nvd.nist.gov/vuln/detail/CVE-2021-26084 Tweet from USCYBERCOM urging users to patch: https://twitter.com/CNMF_CyberAlert/status/1433787671785185283 https://twitter.com/CNMF_CyberAlert/status/14337876717851852... Tweet from BadPackets showing where the bad actors are originating from: https://twitter.com/bad_packets/status/1433157632370511873 https://twitter.com/bad_packets/status/1433157632370511873

macksd 5y ago
Nit: I wouldn't say "originating". That's where this specific exploit is coming from "most recently". But it would seem to not be script kiddies and they're listing like 8 countries. I would assume the bad actors could be anywhere, proxying traffic through any number of other places.
SV_BubbleTime 5y ago
Helpful links, looks like failure to sanitize input. Classic. But on the “attacks coming from”, I’ve never understood putting stock in these. Aren’t these all going to be proxies and botnets?
- hn_throwaway_99 5y ago
  Failure to sanitize input is one thing, but the bigger issue to me is that, with so many of these Java server installations, that a simple injection can immediately lead to "game over" from a server takeover perspective. For the bug in question, I bet the vast majority of webservers never need the ability to call unrestricted Runtime.exec(), yet access to that is just one unsanitized input away from complete control over your server. OS vendors have made leaps and bounds in the past decade making it much harder for code vulnerabilities to lead to system takeover. I'd argue it's time for server code and language runtimes to make it easier to write secure code.
  - SV_BubbleTime 5y ago
    That’s fair. But there needs to be a point somewhere that you just get work done. I absolutely agree that runtimes, frameworks, and server code should do a better job at trust and sanitization, but you will always get to a point where if you want to get something done, you need to do the work. I guess I’m skeptical that eval() or runtime.exe could or even should take in lists and configs of what the code is allowed to do and monitor for it during execution. It seems like doing that would add countless issues and complexity, but more so just kick the can down the code to another layer with the same eventual issue.

macksd 5y ago

Nit: I wouldn't say "originating". That's where this specific exploit is coming from "most recently". But it would seem to not be script kiddies and they're listing like 8 countries. I would assume the bad actors could be anywhere, proxying traffic through any number of other places.

SV_BubbleTime 5y ago

Helpful links, looks like failure to sanitize input. Classic. But on the “attacks coming from”, I’ve never understood putting stock in these. Aren’t these all going to be proxies and botnets?

hn_throwaway_99 5y ago
Failure to sanitize input is one thing, but the bigger issue to me is that, with so many of these Java server installations, that a simple injection can immediately lead to "game over" from a server takeover perspective. For the bug in question, I bet the vast majority of webservers never need the ability to call unrestricted Runtime.exec(), yet access to that is just one unsanitized input away from complete control over your server. OS vendors have made leaps and bounds in the past decade making it much harder for code vulnerabilities to lead to system takeover. I'd argue it's time for server code and language runtimes to make it easier to write secure code.
- SV_BubbleTime 5y ago
  That’s fair. But there needs to be a point somewhere that you just get work done. I absolutely agree that runtimes, frameworks, and server code should do a better job at trust and sanitization, but you will always get to a point where if you want to get something done, you need to do the work. I guess I’m skeptical that eval() or runtime.exe could or even should take in lists and configs of what the code is allowed to do and monitor for it during execution. It seems like doing that would add countless issues and complexity, but more so just kick the can down the code to another layer with the same eventual issue.