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
Related
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.
I am trying to calculate impact metrics (confidentiality, availability and integrity) in the CVSS standard.
Can anyone suggest how this is done?
You should be using the definitions provided in the standard since you are following a standard to communicate the findings in a standardized and commonly-agreed way.
Refer to this document: https://www.first.org/cvss/specification-document
First of all, there is a distinction between CVSS v2 and v3, so you would need to specify which one you use (one has 'complete' the other 'high' as possible impacts for CIA).
In any case, in order to assess the proper impact, you need to understand the vulnerability and the standard. The official standard has many different examples.
A couple here: assume you have a vulnerability that allows you to crash the Apache Web Server by sending a malformed request from remote. If we have to assign a CVSS score for the Web Server itself, Confidentiality would not be impacted as nothing is leaked, Integrity would not be impacted as no data is being manipulated. Availability however would be completely impacted, as the server would not respond anymore.
However, let's assume that we have to assign a CVSS for the same issue, only this time we do it for an operating system (e.g. the server itself on which the http server is running). While confidentiality and integrity still are not impacted, the availability of the server would be impacted only PARTIALLY. While the web server might not respond anymore, other services might (e.g. SSH, Mailserver, etc).
This was to make it clear, that CVSS cannot be calculated automatically, but has to be assessed for each vulnerability in relation to the affected software component. There are also a number of other pitfalls defined by the standard, so I strongly recommend you go read it!
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.
This question is more security related than programming related, sorry if it shouldn't be here.
I'm currently developing a web application and I'm curious as to why most websites don't mind displaying their exact server configuration in HTTP headers, like versions of Apache and PHP, with complete "mod_perl, mod_python, ..." listing and so on.
From a security point of view, I'd prefer that it would be impossible to find out if I'm running PHP on Apache, ASP.NET on IIS or even Rails on Lighttpd.
Obviously "obscurity is not security" but should I be worried at all that visitors know what version of Apache and PHP my server is running ? Is it good practice or totally unnecessary to hide this information ?
Prevailing wisdom is to remove the server ID and the version; better yet, change them to another legitimate server ID and version - that way the attacker goes off trying IIS vulnerabilities against Apache or something like that. Might as well mislead the attacker.
But honestly, there are so many other clues to go by, I wonder about whether this is worth it. I suppose it could stop attackers using a search engine to find servers with known vulnerabilities.
(Personally, I don't bother on my HTTP server, but it's written in Java and much less vulnerable to the typical kinds of attack.)
I think you usually see those headers because the systems send them by default.
I routinely remove them as they provide no real value and could, as you suggested reveal information about the server.
Hiding the information in the headers usually just slows down the lazy and ignorant villains. There are many ways to fingerprint a system.
Running nmap -O -sV against an IP will give you the OS and service versions with a fairly high degree of accuracy. The only extra info you're giving away by having your server advertise that information is which modules you have loaded.
It seems that some of the answers are missing an obvious advantage of turning off the headers.
Yes, you all are right; turning of the headers (and the statusline present e.g. at directory listings) does not stop an attacker from finding out what software you use.
However, turning this information off prevents malware which uses google to look for vulnerable systems from finding you.
tldr: Don't use it as a (or even as THE) security-measure, but as a measure to drive away unwanted traffic.
I normally turn off Apache's long header version information with ServerTokens; it adds nothing useful.
One point which nobody has picked up on, is it looks like better security to a prospective client, pen testing company etc, if you're giving out less information from your web server.
So giving less information out boosts the perceived security (i.e. it shows you have actually thought about it and done something)