Hack on 1.0.5 in assets/cache

Hello,

This morning, someone uploaded a file called 207db.php in assets/cache
Since 11am, mails are sent from my server

I don't know if I can attach here the 207db.php file.

I've deleted the file from assets/cache. I've changed ftp password. What can I do now ?

Thank you !

What are the permissions on your files and folders? Is your server using some form of suexec?

Actually these are questions you should be asking your hosting technical support. There isn't anything MODx itself can do to keep your server from being compromised.

assets/cache is 777 in order cache can work. If I put 775, I get an error in MODx manager that cache won't work.

I don't know about suexec, I ask to my server admin

If you use 644/755 for permissions then you have suphp or suexec enabled on your server. If you need to give more permission to a file/folder then you don't have it enabled.

I would highly recommend enabling suphp on your server.

Yes, I have suexec :

"--with-suexec-caller=apache" \
"--with-suexec-docroot=/" \
"--with-suexec-gidmin=100" \
"--with-suexec-logfile=/var/log/httpd/suexec_log" \
"--with-suexec-uidmin=100" \
"--with-suexec-userdir=public_html" \
"--with-suexec-bin=/usr/sbin/suexec" \

Could this file be created with a form with POST ?

What is the difference between suexec and suphp ? Thanks

They are all methods of having a script run as its owner (you) rather than the global Apache user. One method is to use an Apache module used when PHP itself is an Apache module. The other (there are several programs to do this) is to use when PHP is run as a separate application from Apache, CGI or FastCGI.

Your phpinfo() view in System Info will tell you how Apache is running PHP (module or CGI)

When you install MODx all files and folders are owned by your user. Normally a .php script called by the web server will run as the web server's user (www, nobody... it depends on the server's configuration). This being the case, unless the file/folder's permissions allow anybody to write to it, a .php script cannot write to your fiiles or folders. Changing the user from the web server's user to the owner of the script will allow it to write, but still nobody else can.

Since you get an error message that it can't write to the cache folder if you change the permission to 755 (owner can read, write and open a folder but everybody else can only open and read) that means suexec is not enabled. Another quick way to check is to use the MODx Manager's file manager and see if it allows you to upload files into any folder.

A form's POST cannot write a file by itself; a file will only be written if the script processing the POST does so.

A common way for files to get inserted into a website is when the site owner's computer is compromised with a Trojan program that monitors activity or searches its hard drive for login and password information, sending that information to the hacker. That way the hacker gets the owner's FTP login and password and can do whatever he wants with the site. In such a case, changing password's won't help until the owner cleans up his computer.

Hello Susan,

I've checked about suEXEC and it is installed :


When I upload files with FTP before installing MODx, folders are created with usera / groupa and 755.

As I used feedX, I noticed that the folder created in assets/cache is apache / apache and 755. MODx can then write to assets/cache/feedx

Why this folder is created with apache / apache ?
Why MODx can then write into it and not in assets/cache with usera / groupa and 755 ?

It seems that with apache, MODx can write into it... but not when the folder is usera / groupa

Any ideas ? Thanks for your help !

Hello Perrine,

I've investigated this vulnerability and reported it privately at the ModX team @ Feb 16 22:39
The ModX team will look at this today (Monday/USA time).

It is indeed possible with a "POST" to create these files.
To find the post, check the creation time 207db.php in assets/cache and lookup this date in your access logs.
(You will find a POST, on the same time)

I'll send you a PM with basic instructions to disable this kind of hack.

Also it would be a good practice to chmod the cache folder to 700 an test.
Only your PHP user needs access to this folder.

Kind Regards,
Roel Strauven

Hey Folks. We're actively working on this issue and will have a resolution posted ASAP. Thanks to Roel for his help and research.