I know Patrick. He works with Steven from rack911, these guys really know what they’re talking about.
3 Likes
Time to update again boys, and girls.
Default config for RHEL includes the plugin that is problematic.
2 Likes
Seems like it has nothing to do with the VestaCP thing though.
[…] it’s possible to exploit the unsanitized, user-controlled “_uid” parameter (in an archive.php _task=mail&_mbox=INBOX&_action=plugin.move2archive request) to perform an MX (IMAP) injection attack by placing an IMAP command after a %0d%0a sequence
I don’t think you can place files in /etc using IMAP.
So here is the bit that is curious.
What could be done, is placing the file with roundcube. This gets your script on the server. Then use the API on VestaCP to launch the script as admin using sudo to said script. Said script then can do what ever, i.e. install the virus.
If you have enough access to run scripts under root, you could just wget/curl the script to the server directly.
Maybe, assuming that part isn’t sanitized partially. It might be easier to use the api to run a command or script like …/…/…/…/tmp/sys*/tmp/gcc.sh
Yeah, just checked. Even in the June 2016 edition the api had some “escapeshallarg()” functions protecting the api. Though it still looks like shit. wants to create for() loops so badly!
2 Likes
Funny a while back he was praising it as doing things right, suddenly it’s a mess. Wasn’t any cleaner back then. I’m not confusing him with someone else am I? Pretty sure it was rack911.
Vestacp is fairly reasonable. There is however some security concerns in the backup system that I had seen.
It is however not a pool of security holes like kloxo or gplhost.
- Steven from Rack911 (source)
If anything I’d expect it to have more security issues back then, than now. Though I guess he didn’t inspect it too too much. Or Patrick just happened to catch more issues than Steven.
1 Like
That was 4 years ago. Pretty sure many things have changed.
Probably not that Steven thinks I’m a dick, but I still refer people to him constantly 
1 Like
Steve rocks!
Bumps the fuck out of this thread.
Updates are live.
dpkg -l | grep vesta
ii vesta 0.9.8-21 amd64 Vesta
ii vesta-ioncube 0.9.8-21 amd64 ionCube Loader for Vesta
ii vesta-nginx 0.9.8-21 amd64 Vesta Nginx
ii vesta-php 0.9.8-21 amd64 Vesta php-fpm
ii vesta-softaculous 0.9.8-21 amd64 softaculous plugin for Vesta
2 Likes
Bumpity bump.
time to hear what really happened and why shutting down port 8083 or the vesta-nginx wouldn’t have helped at all?
sadly their main dev Serghey seems to burry everything underneath other fixes instead of providing complete information.
start with this tiny commit delete eval from roundcube configs · serghey-rodin/vesta@1940066 · GitHub and ask yourself what it’s doing there and pay attention to what file it changes.
<?php/* +----------------------------------------------------------------- - Pastebin.com - that’s how the file looked on infected machines… watch out for lines 685 and 797
1 Like
So what you are saying is… roundcube was part of the attack method.
I am saying there was a roundcube config file that had been tampered with. this enabled the attacker to send a request to the webmailer including malicious code as header var ‘accept-charset’, which in the end would be executed through the eval-lines in that config.
you can do that e.g. with a curl request to the /webmail url and adding something like
--header "Accept-Charset: fwrite(fopen('/tmp/update','w'),'Hello Munzy');"
traces in the logfiles would be a single barely noticable HEAD request without further clues …
this config file including those eval commands is NOT part of any default roundcube install but gets pulled from the vesta config repos during the install process. given the original timestamps of the file it’s been there from some date in december 2017 and got replaced some time after the DDOS happened - but only in the repos and not on the VMs. that’s why I am saying, machines that only got desinfected or maybe even reinstalled directly after the DDOS but before the repo got cleaned, would have been vulnerable until this update now.
for me this also makes sense if you think about the missing pattern on which VMs got hacked - only those that have been installed after december 2017 … got pretty much nothing to do with port 8083 or not, though this of course was the first most common conclusion to be made.
2 Likes
It makes a lot of sense. Up to a certain point the best detail we had was only as strong as an instance of “it kind of looks like the attacker hit roundcube.”
Boxes were being hit left and right and it had been occurring for at least 24 hours before I took down my instances, where I had replaced roundcube with manual installations. I wasn’t hit. That’s not a strong piece of evidence but one I’d toss in a bucket full of all the little pieces we’ve had.
An easy way to tell if you had the compromise as @Falzo showed is to run:
ls -lah /etc/roundcube/
If the defaults.inc.php is updated recently, May 18th and on. You had the eval attribute.
I’m nobody but I recommend not using Vesta for anything involved in a business.
Up until this happened vesta was a pretty decent alternative to cpanel which ultimately allowed some businesses to provide a cheaper service.
Edit: fuck. Sorry for the thread necro 