I uploaded the sample files referenced in our IBM i for Hackers document, so anyone can verify and improve on our findings/tools:
https://github.com/silentsignal/SAVF
The repo contains C sources and serialized #IBMi Program Objects. You can use our Ghidra-based tools to dissect the binaries.
Feedback welcome!
Blog posts should always include a first published date and a last edited date.
Was ILOVEYOU worse than CrowdStrike?
https://en.m.wikipedia.org/wiki/ILOVEYOU
Looks like more hosts were affected by ILOVEYOU (45 million in the first 24 hours) ... but the damage was somewhat more random because files were overwritten.
And now that there is a well-known CrowdStrike recovery procedure, as long as you follow it, you're okay -- but if you didn't have good backups, files overwritten by ILOVEYOU were unrecoverable.
Any event that makes the front page of a news outlet will be used as a phishing lure.
Any “threat intelligence” that alerts you to this is next to useless.
Email received a few days ago: "We need to know which version of SSH is installed on the server, as we want to ensure it is not vulnerable to external attacks." My response: "Don’t worry, SSH is accessible ONLY via VPN, and I am the only one with access to that VPN—activated only when needed—so there is no way for there to be any issues, regardless of the version used."
Email received this morning: "We’re not interested; you must provide the SSH version installed and, if it's not the latest, ensure us of the update date."
My response: "Sorry, could you explain the rationale? SSH is not exposed, it’s not listening on any public IP."
Their reply: "Provide the version."
My response: "OpenSSH_9.7, LibreSSL 3.9.0, on OpenBSD."
Their reply: "This is not considered secure. It must be OpenSSH_9.2p1 Debian-2+deb12u3."
My response: "It’s not Debian; it’s OpenBSD."
Their reply: "So the systems are insecure."
And they claim to be a cybersecurity company...
#CyberSecurity #SSH #VPN #ITSecurity #SysAdmin #TechSupport #OpenBSD #Debian
@masek we know a few other things:
The channel file update that caused this problem was for detecting malicious named pipe usage on the system by the CS kernel module
These channel file updates are pushed a few times per day.
The implication there, at least for me, is that the QA process is almost certainly entirely automated.
I have to believe that the release process probably doesn’t depend on someone doing a set of steps during the push process, including QA
I have two hypotheses:
a) the release pipeline doesn’t account for testing on a windows system that is crashed by an update and never comes back to life.
Or
b) the release pipeline doesn’t test channel file updates after they’ve been encoded for each customer, and it was some interplay between the content of the update, the encoding process, and a logic bug in the parser that resulted in the problem.
Also, on the topic of the terms and conditions preventing use for life safety situations - that is quite standard practice in the US, given how litigious we are. Most software and most services have some similar variation - I know we did at my prior employer, so I wouldn’t read too much into that.
🌪️ Our CEO @nrathaus had an engaging chat with our keynote speaker @yarden_shafir. They covered starting out in cybersecurity, tips for beginners, and future trends in the industry.
Watch now at: https://youtu.be/b51Ptn5K79U