Got 10 VestaCP servers exploited

[kobo1d]

I wasn't hacked.

I have the vestacp installed 1 year on digitalocean, and I dind't installed mail (exim,dovecot,spamassim,clamav). Maybe the reason that I am not hacked.

At the moment of attack, I was using vesta Version 0.9.8-17.

I only have 2 dedicated servers, they are in different data centers. The one that got hacked had exim/dovecot/spam/clam enabled (every service was enabled). The one that did not get hacked did not have any of those services enabled. Coincidence?

As for ports, both had the panel on default 8083. As for Vesta software both were on 0.9.8-19. One difference was that hacked server was running Centos 7 while the server that was not hacked had Centos 6.9.

Link at top:

Code: Select all

[2018-04-12] Security fix for Roundcube webmail. Please, update your systems to 1.3.6 (read more)

What about Roundcube? But i think its still not prooven, if its the real cause.
Also strange that my backdoor connection was going to some ip at client port 25 (smtp)

[kobo1d]

I just saw that the official latest version in debian 9 rep for roundcube is: Version 1.2.3
And i also found a file in

Code: Select all

/roundcube/bin

called gc.sh, when the virus cronfile was named gcc.sh
its about some cronjob -> ?!

[dpeca]

I just saw that the official latest version in debian 9 rep for roundcube is: Version 1.2.3
And i also found a file in

Code: Select all

/roundcube/bin

called gc.sh, when the virus cronfile was named gcc.sh
its about some cronjob -> ?!

it's regular script - https://github.com/roundcube/roundcubem ... /bin/gc.sh

[kobo1d]

I just saw that the official latest version in debian 9 rep for roundcube is: Version 1.2.3
And i also found a file in

Code: Select all

/roundcube/bin

called gc.sh, when the virus cronfile was named gcc.sh
its about some cronjob -> ?!

it's regular script - https://github.com/roundcube/roundcubem ... /bin/gc.sh

how nasty is this? -> https://www.cvedetails.com/vulnerabilit ... 1.2.3.html

[dpeca]

:(
but i'm sure it's already patched on all distroes, even if you have Roundcube 1.2.3 on Debian9, i'm sure it's patched version of 1.2.3 (patched against that security flaw)

if you look on github issue page, you'll find a man from Debian dev team that patch even old debian versions - https://github.com/roundcube/roundcubem ... -345473408

[kobo1d]

:(
but i'm sure it's already patched on all distroes, even if you have Roundcube 1.2.3 on Debian9, i'm sure it's patched version of 1.2.3 (patched against that security flaw)

if you look on github issue page, you'll find a man from Debian dev team that patch even old debian versions - https://github.com/roundcube/roundcubem ... -345473408

i see. oh boy, this thing seems to remain a mystery.

edit: trying a new perspective. lets say it had something todo within the mail system in combination with vesta.
how could some bypass the iptables protection of the web port? or access api without it.
is there a technique?

[dpeca]

Maybe to make option in vesta.conf
ALLOW_API='Yes'

I also moved vesta to hidden URL (on my Vesta fork), so even if hacker find a port, he also need to know custom URL (you can understand it as custom folder name)

[nextgi]

Well,

Im glad we are making full circle on our original working theory lol.

We have documented proof that the correlation between the url http://<your ip>/webmail was the vector entry point on the systems we have been examining. It may not be roundcube specific, we have yet to determine this. It may be a combined vector attack in which it leverages vesta and roundcube. However, in some situations roundcube and access to the webmail path were removed/disabled. So, this would lean towards possibly Apache? nginx? We are still investigating our selves. For those whom had access to port 8083 change and completely block in some cases has lead us to believe it was not, at least solely, reliant on VestaCPs api.

[deanhills]

I wasn't hacked.

I have the vestacp installed 1 year on digitalocean, and I dind't installed mail (exim,dovecot,spamassim,clamav). Maybe the reason that I am not hacked.

I also haven't been hacked and just like you don't have mail or FTP installed. I'm almost certain the hacker would have been looking for servers with e-mail attached as logically he'd need that to DDoS third party sites. But again, that's an unproven theory. We still don't have a clear picture of how this infection worked. For all we know those without e-mail systems may have a version of the infection waiting to happen on X Date. It may even be migrating through our Websites as we speak. Everything is possible until someone is able to replicate the exploit.

By the way, does anyone know which country location IPs the exploiter was targeting?

[dpeca]

China.
I think that I saw that target server is some server of Tencent company.

Attacker IP is in Japan, but he could be anywhere and anybody...