0

I found lots of similar logs in cloud watch logs where logs from my ebs application are streaming.

I am using Platform: 64bit Amazon Linux 2017.03 v2.5.0 running Java 8

Here are the logs which are repeating:

Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://target(any -froot@localhost -be ${run{${substr{0}{1}{$spool_directory}}bin${substr{0}{1}{$spool_directory}}bash${substr{10}{1}{$tod_log}}${substr{0}{1}{$spool_directory}}tmp${substr{0}{1}{$spool_directory}}rce}} null)/wp/wp-login.php?action=lostpassword
at java.net.URI$Parser.fail(URI.java:2848) ~[na:1.8.0_131]
at java.net.URI$Parser.parseAuthority(URI.java:3186) ~[na:1.8.0_131]
at java.net.URI$Parser.parseHierarchical(URI.java:3097) ~[na:1.8.0_131]
at java.net.URI$Parser.parse(URI.java:3053) ~[na:1.8.0_131]
at java.net.URI.<init>(URI.java:588) ~[na:1.8.0_131]
at org.springframework.http.server.ServletServerHttpRequest.getURI(ServletServerHttpRequest.java:97) ~[spring-web-4.3.8.RELEASE.jar!/:4.3.8.RELEASE]
... 35 common frames omitted

Is it some kind of attack? If yes, how can I protect my app?

1 Answers1

0

Your app is receiving an invalid request, and throwing an exception. To me, that indicates that you are not actually vulnerable to this particular attack.

The attack seems to be looking for the CVE-2016-10033 vulnerability PHPMailer, which seems attributable to PHPMailer's reliance on bad documentation and your attacker is specifically trying to exploit it through a weakness in Wordpress.

You don't appear to have any of these things, so none of these things seem applicable to your system.

On the web, attempts at exploiting weaknesses to which even a casual observer should be able to determine are not actually applicable to your system are pretty common.

I see log entries all the time where people try to exploit php-related vulnerabilities even though my entire network has a zero-tolerance policy for PHP -- it's so annoying that my perimeter load balancers typically tarpit¹ any request with .php in the URI.

It may or may not be worthwhile to collect log entries with accurate timestamps and submit abuse reports to the entity controlling the IP address space that the requests are coming from. Be polite when you do this, since the person reading your mail is almost certainly not a party to the bad behavior and likely does not condone it.


¹ tarpit -- the asynchronous request handler stops servicing the connection and sets a timer to go back after an arbitrary number of seconds and return a simulated 500 Internal Server Error response, meanwhile leaving the caller "stuck in a tar pit," ignored and not consuming meaningful resources, until I eventually force their connection closed. The long delay before I respond slows them down but otherwise has a dubious practical impact, so it's mostly for schadenfreude purposes. This is done on a server in front of the actual app server, which never has to see the incoming connection at all.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86