Re: Cryptominer malware and Tomcat
Hi Pete, On 17.06.20 23:44, Pete Helgren wrote: > I am going to guess that it is one of these two known vulnerabilities: > > CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981) > The JSONDeserializer of Flexjson allows the instantiation of arbitrary > classes and the invocation of arbitrary setter methods. > > CST-7205: Unauthenticated Remote code execution via JSONWS > (LPS-97029/CVE-2020-7961) > The JSONWebServiceActionParametersMap of Liferay Portal allows the > instantiation of arbitrary classes and invocation of arbitrary setter > methods. > > Found the signature in the logs and it's pretty clear that that is > what we are up against. However, if something else comes to mind, > feel free to post back. I did come across a couple of other posts > where the OP said there was nothing but Tomcat and they also ended up > with the miner. > > I have some updating to do > Correct analysis. What you need is this update https://liferay.dev/blogs/-/blogs/security-patches-for-liferay-portal-6-2-7-0-and-7-1 And while you're at it: There has been another patch published this month https://liferay.dev/blogs/-/blogs/june-2020-security-patches-for-liferay-portal-7-1-and-7-2 Best, Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cryptominer malware and Tomcat
I am going to guess that it is one of these two known vulnerabilities: CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981) The JSONDeserializer of Flexjson allows the instantiation of arbitrary classes and the invocation of arbitrary setter methods. CST-7205: Unauthenticated Remote code execution via JSONWS (LPS-97029/CVE-2020-7961) The JSONWebServiceActionParametersMap of Liferay Portal allows the instantiation of arbitrary classes and invocation of arbitrary setter methods. Found the signature in the logs and it's pretty clear that that is what we are up against. However, if something else comes to mind, feel free to post back. I did come across a couple of other posts where the OP said there was nothing but Tomcat and they also ended up with the miner. I have some updating to do Pete Helgren www.petesworkshop.com GIAC Secure Software Programmer-Java AWS Certified Cloud Practitioner Twitter - Sys_i_Geek IBM_i_Geek On 6/17/2020 2:21 PM, Pete Helgren wrote: I have a situation where I have had "Kinsing" crypto-mining software get installed twice on a VM that runs Liferay and Tomcat. Based on what I have read about this cryto-miner, it seems to target Linux VM's running Docker images and/or an open redis port. I have none of that on this VM. The VM is running CentOS 8.  The tomcat version I am running is 8.0.32, java openjdk version "1.8.0_252" OpenJDK Runtime Environment (build 1.8.0_252-b09) OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode). It is hosting Liferay 7.0.4 GA5. The VM running Tomcat/Liferay is served through reverse proxy listening on port 443 and passes traffic back to the Tomcat instance listening on 7080. The VM has ONLY ports 7080, 7009, and 7005 open (firewalld) I am trying to sort out how the crypto miner has installed itself. Originally, I had a CentOS 7 VM but after the first episode, I started from scratch, locked down the VM and re-installed the Liferay bundle with Tomcat 8.0.32. After about 2 weeks, the miner was back. I can't figure out how it is installing itself. I read through the CVE's on this version of Tomcat and nothing jumped out at me. We don't use JMX or AJP. It's just Tomcat with Liferay. I am starting here since it's only the TC port that is open and yes, it's possible that Liferay may have a vulnerability. I just need ideas on where to start looking. I am going to try to jump to the latest Liferay/Tomcat bundle but it isn't an easy upgrade and may take a bit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Cryptominer malware and Tomcat
I have a situation where I have had "Kinsing" crypto-mining software get installed twice on a VM that runs Liferay and Tomcat. Based on what I have read about this cryto-miner, it seems to target Linux VM's running Docker images and/or an open redis port. I have none of that on this VM. The VM is running CentOS 8. The tomcat version I am running is 8.0.32, java openjdk version "1.8.0_252" OpenJDK Runtime Environment (build 1.8.0_252-b09) OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode). It is hosting Liferay 7.0.4 GA5. The VM running Tomcat/Liferay is served through reverse proxy listening on port 443 and passes traffic back to the Tomcat instance listening on 7080. The VM has ONLY ports 7080, 7009, and 7005 open (firewalld) I am trying to sort out how the crypto miner has installed itself. Originally, I had a CentOS 7 VM but after the first episode, I started from scratch, locked down the VM and re-installed the Liferay bundle with Tomcat 8.0.32. After about 2 weeks, the miner was back. I can't figure out how it is installing itself. I read through the CVE's on this version of Tomcat and nothing jumped out at me. We don't use JMX or AJP. It's just Tomcat with Liferay. I am starting here since it's only the TC port that is open and yes, it's possible that Liferay may have a vulnerability. I just need ideas on where to start looking. I am going to try to jump to the latest Liferay/Tomcat bundle but it isn't an easy upgrade and may take a bit -- Pete Helgren www.petesworkshop.com GIAC Secure Software Programmer-Java AWS Certified Cloud Practitioner Twitter - Sys_i_Geek IBM_i_Geek - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Warning "AJP13 protocol: Reuse is set to false" written logs every second of every day. Please help.
Hi Chris,
Thanks for your reply. Thanks also for your warning against interfering with
the setting allowedRequestAttributesPattern ('Setting the value to ".*" is a
violation of sane security policy'). I guessed as much, and am grateful for
your confirmation.
On the subject of mod_jk, we are apparently talking about the same thing. In
our set-up the mod_jk log is called isapi_redirect.log.
The code that generates the error is indeed /native/common/jk_ajp_common.c. The
part where the error is generated is:
case JK_AJP13_END_RESPONSE:
ae->reuse = (int)jk_b_get_byte(msg);
if (!ae->reuse) {
/*
* AJP13 protocol reuse flag set to false.
* Tomcat will close its side of the connection.
*/
jk_log(l, JK_LOG_WARNING, "(%s) AJP13 protocol: Reuse is set to false",
ae->worker->name);
}
This code snippet says that reuse is determined - at the end of a response -
from a byte obtained from some message. Which raises two questions:
1) The response to the "ping" REST request has status code 204 ("No Content").
If, as you say, a 204 response is OK, then where would the reuse byte come from?
2) Do you know a way to set the "AJP13 protocol reuse flag" to true? As far as
we know, the only "reuse" settings at our disposal are the current worker
settings, worker.workerName.connection_pool_size=500
and worker. workerName.max_reuse_connections=250.
Kind regards,
Alfred
-Oorspronkelijk bericht-
Van: Christopher Schultz
Verzonden: 16 June 2020 19:55
Aan: Tomcat Users List
Onderwerp: Re: Warning "AJP13 protocol: Reuse is set to false" written logs
every second of every day. Please help.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alfred,
On 6/15/20 09:45, Alfred Bakia wrote:
> Thanks, Chris. To respond to your remarks:
>
> 1) The warnings, "AJP13 protocol: Reuse is set to false", are being
logged by Tomcat (in the Tomcat AJP connector logs).
Weird. I can't find that string anywhere in code or other files in Tomcat, but
its right there in mod_jk:
./native/common/jk_ajp_common.c:jk_log(l, JK_LOG_WARNING,
"(%s) AJP13 protocol: Reuse is set to false",
Are you sure you are looking at the right log file?
> 2) As I mentioned earlier, the versions and settings of the servers
> (and their respective IIS web servers) are the same.
>
> In any case I have discovered "how" the warning occurs. It is indeed
> triggered by the REST API.
>
> The culprit is a REST request in the form:
>
> http://www.ourdomain.com/api/srv2/exercises/93/1431/26346/ping
>
> It is a POST request and "ping" is a custom REST method. It is just a
> ping, so the status code of the response is 204 ("No Content").
A 204 response should not cause any problem.
> I can confirm that every ping request results in the warning
> "AJP13 protocol: Reuse is set to false" being written to Tomcat's
> connector logs.
>
> Researching this on the web, I found the suggestion to add
> allowedRequestAttributesPattern=".*" to the AJP connector in
> server.xml.
>
> Is this a viable solution?
This has nothing to do with your REST API. This is a change made to recent
versions of Tomcat that may require you to allow certain non-standard variables
to be passed-over from your web server to Tomcat via AJP.
If your "ping" REST API is requiring some information to be passed from the web
server to Tomcat and you are seeing errors on the Tomcat side, then you may
have to fiddle with the allowedRequestAttributesPattern. Setting the value to
".*" is a violation of sane security policy.
But I see no evidence that your "Reuse is set to false" error is related (yet)
to the allowedRequestAttributesPattern. If you see errors in the Tomcat log,
please post them and we'll see.
The allowedRequestAttributesPattern wasn't added to Tomcat until
9.0.31 so if you really are running 9.0.21, then adding
allowedRequestAttributesPattern will accomplish nothing.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7pB3wACgkQHPApP6U8
pFg97w//T8XVtWlic/x/nUJHZUXfDs99Ou8cKcSFFI/AbBldd5k8vSxCTKg40wON
3bUooWG5GWZhVRNHH2JH0eyiKqhLmDtAzdnSp7xAkAW2fAZ2Zlv0VLb0AzJCTqRg
e1Nd9R9Ii9mjcSU5+M2WrNSourUhOT0FVYaqpvlaN89XyetHSuVIUladDuwM8kFN
3ngAtkgmIYfxXcqIPXjoNZ+s8cr1MB0qk+KkiXyOCb8XgfmZUkBMRncgqMAgEff5
p6Z/1jGVv0+S7E0+HV1yqJpakiGjVswfIjbc2s89YnVL6bvyBqUnJl4HrmOHY0bV
d3O/NQ3+vZ/Kma4e84TI5QKQx0KvQj0oBH41fFl0WmPjraKjGMTTfMCy9BjvLwdf
hbTEbZaBRvn7Tr+iR5ksrvaJTxZD1ABMb7o0uksCsPQO8h3tl3s7L5O4g0P3+7kV
/SiqDD+WyqkhmJuX86Y3MtSeMUTsg9RiXOZLLGF59TOZFeso/2O+OWYU/uImXw2X
opWW38Vowhn8O9a94RbRA67EvJFiLdWwTDoLlnVP0ZxGkdOIow0EQWfnCDKaBXOd
l+BdTG7zPbU8I3bw00cXGytyCYENt9uIZJ/XVVkyC2EAFAbEArVjWR0ocZT4W6zQ
bCc5vbHFJnNvCRh8jeSl9ORSzBFzYPt0B1kvSMkNE0U7y7mU74c=
=8kiV
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h..
Is it possible to get a callback notification when a http/http2 connection is opened/closed
Hi All, Can we get a callback notification when a http/http2 connection is opened/closed in Embedded tomcat . Thanks and Regards Arshiya Shariff
