As most of the IT folks know this vulnerability, I have a question on the affect it would have on the system that uses the libraries using log4j affected versions.
So let's say my app (APP_1) is dependent on dependency1.war. This dependency1.war is using say log4j 2.8.x version which is affected with the vulnerability mentioned.
How would this have an affect on the system APP_1 is deployed on and application itself (App_1)?
What would be a recommended way to safeguard against attacks?
Much thanks in advance :)
It is very likely that your app is at one point logging a value that is coming from a user, say a request parameter value. (This in itself is a bad programming practice but very common). If the user sends a request where this parameter is a specially crafted string then, because of this vulnerability, log4j would allow execution of another program on the host machine, for example
I am trying to check the log4j vulnerability in GeoServer, On before and after updating the old log4j package to the new package which resolves the issue. For that, I am using the Zap tool for checking the vulnerability, where I found that active scan rule alpha. This rule attempts to discover the Log4Shell (CVE-2021-44228) vulnerability. checkout this link for more information https://www.zaproxy.org/docs/desktop/addons/active-scan-rules-alpha/.
And also I am little confused about how to execute this active scan rule alpha. please share some information about its execution.
My question is whether this is the right way to check this log4j vulnerability in GeoServer? or is there are any other ways for this?
You need to enable an OAST service (via Options / OAST) first.
You can either use one of the public ones we have pre-configured or stand up your own instance.
We also recommend that you scan headers as well as this vulnerability often is exposed by them.
For more details see this blog post :) https://www.zaproxy.org/blog/2021-12-14-log4shell-detection-with-zap/
The current log4shell issue (the famous CVE-2021-44228) gives attackers a vector to execute untrusted code on vulnerable, internet-facing machines.
Could this be used to patch the vulnerability, by placing code on the target machines that patches the vulnerable libraries?
Edit: To clarify the question, this is only aimed at the technical question of whether patching running Java code remotely through this shell access vector is possible.
There seems to be at least one proof-of-concept level project that attempts to patch the vulnerability in-place, so it is technically feasible: https://github.com/Cybereason/Logout4Shell .
The authors deatail their approach in a blog post, from which it seems that the exploit-fix-combination (which they call a "vaccine") is also an advertisement for their company. Keep that in mind when evaluating it.
Legally it is a clear no.
As you are still executing code on a system you don't own without authorisation by the owner. Although this would have good intention to prevent bad hackers to attack the system, this way of solving the problem would still be illegal.
Technically, yes.
as you correctly understood, you can get full control on the system executing arbitrary code, including installing a "fix".
Realistically, it depends on how you want to implement the fix and if you find a scaling generic solution to "fix" different configured systems with the same approach.
Updating the library would require to identify the location of the vulnerable file log4j-core.jar and replace it with the fixed version, but then you also need to restart the service using the library, as the vulnerable version might already be loaded in memory. A change of the file on the disk would not be reflected in a running program.
Location of the file and running services will vary from system to system making it harder to implement a generic solution.
The exploit is already 5 days a public reported vulnerability and very easy to exploit. If you haven't patched it already, you might already be exploited. An attacker could already have installed another malicious software that is able to load any execute any new code in the future via remote control and would not require the log4j exploit any more.
If you haven't fixed the log4j vulnerability yet, updating log4j is no longer enough. You have to assume that your system is already compromised by sleeping trojans and you should reset the whole system to get rid of it.
My Suggestion is to not do it. Try to contact the owner of the system, tell them to update and reset the complete system.
There are plenty of articles online that describe how DLL Injection works and what it can be used for. There has been lots of software written (both malicious and non) to use this functionality, but there's a question that I can't find the answer to with my Google-Fu and that is...why does Windows have/allow such a technique but Linux (and its ilk) do not?
LD_PRELOAD doesn't count as it doesn't allow runtime injection. I also know about injectso but that's not official.
What problem is DLL Injection supposed to solve, and since Linux doesn't have this functionality, how does it solve that problem? If possible please provide references to backup your answer, ideally first-party ones. Thank you.
as can be seen from two other question I had I am looking for a secure webserver as there where discussion at work how safe tomcat really is.
But basically what I found on the net regarding how safe it is is greek to me. So I was hoping, someone could explain to me how safe tomcat really is? Like, is it possible to mess with java-code on the server or something like this?
I know this is probabaly a dumb question, but I really can't seem to find an answer that helps me to argument that writing an own server is not more safe than using tomcat or how it might be better to use tomcat.
Maybe someone knows a good way to secure tomcat and to minimize certain functions of tomcat? (I really dunno how to else explain it ...)
I hope you can help me.
Thnx in advance!
... dg
Writing your own server? As opposed to using Tomcat? That is a classic case of reinventing the wheel and (unless you are the NSA) likely to result in a less secure server. Rhetorical question: Why not write your own OS to go with it!
Tomcat 6 is a very mature, stable, current, well understood code base that has had zillions of very, very smart people reviewing, testing it, and operating it in production for years and years.
Tomcat is very secure.
maybe before, Tomcat was pretty unsecure, but nowadays... just anything having Apache under its name is enough for me to trust it. Anyway, security was ALWAYS imagination, there is not such thing existing in real life, so there would always be factor of (in)security.
Problem with Tomcat is like problem with Windows, no matter how 'secure' they built it, if there are millions of people out using it, hackers will have interest to invest their energy (and eventually, they will success) in finding way to break into it. So maybe to feel more secure, you can consider using something not wide used, but this will not help if hacker is intentionally hacking your site for some special reason, he will find out technology you are using and in this moment - it would be better it was Tomcat..
That is why is very important to 'get married' with open-source technologies like tomcat, since there is not big chance for a hole in system to live long, people have chance to fix things, you can always do the job yourself, do not have to wait for a new version etc.
Look at the changelog and count the security issues fixed;
Look at the CVE entries for Tomcat and see how the seem to you.
But all in all, it's a really bad idea to write your own Servlet Container, especially if the Tomcat security arguments are not clear to you.
If you need boss-convincing arguments, show him the serlvet spec you need to implement, and estimate time in the order of man-years ( not kidding! ), contrasting this with the 'download,unzip,start' option of using Tomcat.
I know this is probabaly a dumb
question, but I really can't seem to
find an answer that helps me to
argument that writing an own server is
not more safe than using tomcat or how
it might be better to use tomcat.
What you have to remember is that Tomcat has 1000s of hours of people looking at code and fixing bugs and holes. Thinking about writing secure code is easy. Doing it is extremely hard. There are lots of little things that can be overlooked which can contribute to a massive hole.
Tomcat is a secure server. However, it is even more secure to use Apache Web Server to proxy it. You can use mod_proxy to connect Apache with Tomcat using AJP or HTTP protocol. This is the safest configuration and you can leverage the many plug-in modules available for Apache Http Server.
Some tips for a secure installation:
Create a user to run Tomcat. Do not use the root user.
Uninstall the example applications.
Uninstall the manager application. If you use Apache to proxy Tomcat, you can safely keep the manager and make it available only through your local network.
While I'm no hacker, I'd find it hard to imagine how Tomcat would be your first port of call if you were trying to attack a system - after all it's running your code and is presumably behind a firewall and fronting servers. If this isn't that case, then it should be!
Once the network is as secure as possible remember Tomcat is just a Servlet engine - you're gonna have trouble exploiting with http requests. I'd focus on your application code, things like user authentication and avoiding the various injection attacks - this in my mind is the highest risk to your system and will exist whatever server you're running on.
As others have already mentioned, Tomcat is ready for production use and security of Tomcat itself is certainly better than what any small team could achieve while writing their own servlet server.
That said, the probably weakest point in a Tomcat setup is commonly the setup of the underlying OS.