New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Malware detected after upgrade to 1.0.13 #264

Closed
matdave opened this Issue May 29, 2014 · 42 comments

Comments

Projects
None yet
@matdave

matdave commented May 29, 2014

After upgrading 100+ sites to 1.0.13 we have started receiving malware complaints from our host. We are at 4 sites taken down within the last few days.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako May 30, 2014

Contributor

Could you tell us, what kind of malware complaints you have received?

Contributor

Jako commented May 30, 2014

Could you tell us, what kind of malware complaints you have received?

@davidrsim

This comment has been minimized.

Show comment
Hide comment
@davidrsim

davidrsim May 30, 2014

I can confirm that we have also experienced a successful hack on a test site running 1.0.13. An investigation suggests that session manipulation allowed the hacker to successfully modify and upload files to the file system. I will email full details.

davidrsim commented May 30, 2014

I can confirm that we have also experienced a successful hack on a test site running 1.0.13. An investigation suggests that session manipulation allowed the hacker to successfully modify and upload files to the file system. I will email full details.

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave May 30, 2014

So far the hacks were on shared servers where we do not have access logs stored. The malware was named differently on each site, but contained various upload scripts, email scripts, and data scraping scripts.

matdave commented May 30, 2014

So far the hacks were on shared servers where we do not have access logs stored. The malware was named differently on each site, but contained various upload scripts, email scripts, and data scraping scripts.

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave Jun 3, 2014

Okay, 7th site in the course of a week just got hacked. The last one was a pure MODX site. Something is terribly flawed in the latest Evo.

matdave commented Jun 3, 2014

Okay, 7th site in the course of a week just got hacked. The last one was a pure MODX site. Something is terribly flawed in the latest Evo.

@garryn

This comment has been minimized.

Show comment
Hide comment
@garryn

garryn Jun 3, 2014

Member

Can you send info on the vectors being used (or any info you do have) to garry@modx.com

This needs to be looked at indeed ... thanks.

Member

garryn commented Jun 3, 2014

Can you send info on the vectors being used (or any info you do have) to garry@modx.com

This needs to be looked at indeed ... thanks.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 3, 2014

Contributor

Without an access log, the vector is almost impossible to locate. So please try to get an apache access log.

And please look into Manager -> Reports -> Manager Actions if someone has logged into the manager at not normal times and has done some actions there.

Contributor

Jako commented Jun 3, 2014

Without an access log, the vector is almost impossible to locate. So please try to get an apache access log.

And please look into Manager -> Reports -> Manager Actions if someone has logged into the manager at not normal times and has done some actions there.

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave Jun 3, 2014

The manager logs show nothing, I have emailed Garry my access logs as this one is on a different server.

matdave commented Jun 3, 2014

The manager logs show nothing, I have emailed Garry my access logs as this one is on a different server.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 3, 2014

Contributor

Just to be sure: Have you clicked on 'Search' there? Then you should see who has logged in, edited resources, uploaded files, edited files etc.

If there is nothing unusual, then it could be a hack without MODX credentials …

Contributor

Jako commented Jun 3, 2014

Just to be sure: Have you clicked on 'Search' there? Then you should see who has logged in, edited resources, uploaded files, edited files etc.

If there is nothing unusual, then it could be a hack without MODX credentials …

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave Jun 3, 2014

Well the manager log shows logs, but nothing out of the usual. It's not quite like the Forgot Manager Login hack. I sent this to Garry, but here is the server access log right before the last malicious file was inserted:

109.120.153.12 - - [02/Jun/2014:09:19:00 -0500] "GET /admin.php HTTP/1.0" 404 9105 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
109.120.153.12 - - [02/Jun/2014:09:19:04 -0500] "GET /administrator/index.php HTTP/1.0" 404 9105 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
109.120.153.12 - - [02/Jun/2014:09:19:06 -0500] "GET /wp-login.php HTTP/1.0" 404 9105 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
91.200.14.107 - - [02/Jun/2014:09:36:26 -0500] "POST /index-ajax.php HTTP/1.1" 200 81 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8"
91.200.14.107 - - [02/Jun/2014:09:36:27 -0500] "POST /index-ajax.php HTTP/1.1" 200 81 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.53 Safari/525.19"
91.200.14.107 - - [02/Jun/2014:09:36:28 -0500] "POST /index-ajax.php HTTP/1.1" 200 77181 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
91.200.14.107 - - [02/Jun/2014:09:36:30 -0500] "POST /?sid=538c8bc58952d HTTP/1.1" 200 9866 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.53 Safari/525.19"
91.200.14.107 - - [02/Jun/2014:09:36:31 -0500] "GET /?sid=538c8bc58952d&file=UploadShell.php HTTP/1.1" 200 5 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SU 3.21; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"

matdave commented Jun 3, 2014

Well the manager log shows logs, but nothing out of the usual. It's not quite like the Forgot Manager Login hack. I sent this to Garry, but here is the server access log right before the last malicious file was inserted:

109.120.153.12 - - [02/Jun/2014:09:19:00 -0500] "GET /admin.php HTTP/1.0" 404 9105 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
109.120.153.12 - - [02/Jun/2014:09:19:04 -0500] "GET /administrator/index.php HTTP/1.0" 404 9105 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
109.120.153.12 - - [02/Jun/2014:09:19:06 -0500] "GET /wp-login.php HTTP/1.0" 404 9105 "-" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
91.200.14.107 - - [02/Jun/2014:09:36:26 -0500] "POST /index-ajax.php HTTP/1.1" 200 81 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8"
91.200.14.107 - - [02/Jun/2014:09:36:27 -0500] "POST /index-ajax.php HTTP/1.1" 200 81 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.53 Safari/525.19"
91.200.14.107 - - [02/Jun/2014:09:36:28 -0500] "POST /index-ajax.php HTTP/1.1" 200 77181 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
91.200.14.107 - - [02/Jun/2014:09:36:30 -0500] "POST /?sid=538c8bc58952d HTTP/1.1" 200 9866 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/1.0.154.53 Safari/525.19"
91.200.14.107 - - [02/Jun/2014:09:36:31 -0500] "GET /?sid=538c8bc58952d&file=UploadShell.php HTTP/1.1" 200 5 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SU 3.21; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)"
@barsproger

This comment has been minimized.

Show comment
Hide comment
@barsproger

barsproger Jun 4, 2014

See more about this.
I very bad english.

it`s to modx 1.0.4 if is unusefull, please delete comment.

I Have log, first log to index-ajax.php AjaxSearch query, but it an home. Late post log.

-------- 26.05.2014 01:07:55-----------

----->GET Array
(
    [sid] => 53825ba8be6ac
    [file] => UploadShell.php
)


----->POST Array
(
)


----->FILES Array
(
)
-------- 26.05.2014 01:21:06-----------

----->GET Array
(
    [sid] => 53825ec0c0c9b
)


----->POST Array
(
)


----->FILES Array
(
    [upload_1] => Array
        (
            [name] => UploadShell.php
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpUQCBKp
            [error] => 0
            [size] => 1176
        )

    [upload_2] => Array
        (
            [name] => FileSettings.php
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpmlGpqu
            [error] => 0
            [size] => 398
        )

    [upload_3] => Array
        (
            [name] => test.php
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpwk2d6y
            [error] => 0
            [size] => 24761
        )

)
-------- 26.05.2014 01:21:06-----------

barsproger commented Jun 4, 2014

See more about this.
I very bad english.

it`s to modx 1.0.4 if is unusefull, please delete comment.

I Have log, first log to index-ajax.php AjaxSearch query, but it an home. Late post log.

-------- 26.05.2014 01:07:55-----------

----->GET Array
(
    [sid] => 53825ba8be6ac
    [file] => UploadShell.php
)


----->POST Array
(
)


----->FILES Array
(
)
-------- 26.05.2014 01:21:06-----------

----->GET Array
(
    [sid] => 53825ec0c0c9b
)


----->POST Array
(
)


----->FILES Array
(
    [upload_1] => Array
        (
            [name] => UploadShell.php
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpUQCBKp
            [error] => 0
            [size] => 1176
        )

    [upload_2] => Array
        (
            [name] => FileSettings.php
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpmlGpqu
            [error] => 0
            [size] => 398
        )

    [upload_3] => Array
        (
            [name] => test.php
            [type] => application/octet-stream
            [tmp_name] => /tmp/phpwk2d6y
            [error] => 0
            [size] => 24761
        )

)
-------- 26.05.2014 01:21:06-----------
@bluesparkweb

This comment has been minimized.

Show comment
Hide comment
@bluesparkweb

bluesparkweb Jun 4, 2014

We had 2 sites infected recently with a spamming script, they also showed that index-ajax.php had been used to upload the script.
These were older versions though, so not sure if the latest version of index-ajax.php is implicated.
We are now deleting this file unless we absolutely need it, it seems to give Ajaxsearch some pretty high permissions - and It is looking like this is now definately being tested and probed by someone out there.
The OP reported this on 1.0.13, but it looks to me as if the file has not changed substantially since 1.0.9 so if it is an issue with 1.0.13 it must affect quite a few versions.

bluesparkweb commented Jun 4, 2014

We had 2 sites infected recently with a spamming script, they also showed that index-ajax.php had been used to upload the script.
These were older versions though, so not sure if the latest version of index-ajax.php is implicated.
We are now deleting this file unless we absolutely need it, it seems to give Ajaxsearch some pretty high permissions - and It is looking like this is now definately being tested and probed by someone out there.
The OP reported this on 1.0.13, but it looks to me as if the file has not changed substantially since 1.0.9 so if it is an issue with 1.0.13 it must affect quite a few versions.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 4, 2014

Contributor

Ok. It has to be some issue inside of AjaxSearch. Will investigate that further.

@barsproger: Thanks for those log entries.

Contributor

Jako commented Jun 4, 2014

Ok. It has to be some issue inside of AjaxSearch. Will investigate that further.

@barsproger: Thanks for those log entries.

@davidrsim

This comment has been minimized.

Show comment
Hide comment
@davidrsim

davidrsim Jun 4, 2014

Just to confirm that our logs are showing the same as @matdave. We've removed index-ajax from our sites too.

davidrsim commented Jun 4, 2014

Just to confirm that our logs are showing the same as @matdave. We've removed index-ajax from our sites too.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 4, 2014

Contributor

Could have been a spoof of $_SERVER['HTTP_HOST'] in combination with disabled session.use_trans_sid/session.use_only_cookies that was successful here.

So please use the Valid hostnames system setting, too.

Contributor

Jako commented Jun 4, 2014

Could have been a spoof of $_SERVER['HTTP_HOST'] in combination with disabled session.use_trans_sid/session.use_only_cookies that was successful here.

So please use the Valid hostnames system setting, too.

@barsproger

This comment has been minimized.

Show comment
Hide comment
@barsproger

barsproger Jun 4, 2014

Wait 1 hour, and i send virus code how, user ajaxSearch and Ditto it`s happens/

barsproger commented Jun 4, 2014

Wait 1 hour, and i send virus code how, user ajaxSearch and Ditto it`s happens/

@janniconl

This comment has been minimized.

Show comment
Hide comment
@janniconl

janniconl Jun 4, 2014

Maybe its done with a method like this one?
https://evilzone.org/tutorials/upload-shell-with-sql-injection/
(I'm a noob a this :P deleting or updating all my index-ajax.php's though. Thx for the update Jako)

janniconl commented Jun 4, 2014

Maybe its done with a method like this one?
https://evilzone.org/tutorials/upload-shell-with-sql-injection/
(I'm a noob a this :P deleting or updating all my index-ajax.php's though. Thx for the update Jako)

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave Jun 4, 2014

All of my systems were PHP 5.4, so session.use_trans_sid was set to 0 and session.use_only_cookies was set to ON by default

matdave commented Jun 4, 2014

All of my systems were PHP 5.4, so session.use_trans_sid was set to 0 and session.use_only_cookies was set to ON by default

@davidrsim

This comment has been minimized.

Show comment
Hide comment
@davidrsim

davidrsim Jun 4, 2014

PHP Version 5.3.28
session.use_trans_sid = 0
session.use_only_cookies ON

davidrsim commented Jun 4, 2014

PHP Version 5.3.28
session.use_trans_sid = 0
session.use_only_cookies ON

@barsproger

This comment has been minimized.

Show comment
Hide comment
@barsproger

barsproger Jun 4, 2014

See and fix issue

[q] => ./assets/snippets/ajaxSearch/ajaxSearchPopup.php
    [search] => data
    [as_version] => 1.9.0
    [ucfg] => &tplAjaxResults=`@CODE:[[{{}}Ditto?parents=`0` &filter=`id,…,1`]{[**]{}]

barsproger commented Jun 4, 2014

See and fix issue

[q] => ./assets/snippets/ajaxSearch/ajaxSearchPopup.php
    [search] => data
    [as_version] => 1.9.0
    [ucfg] => &tplAjaxResults=`@CODE:[[{{}}Ditto?parents=`0` &filter=`id,…,1`]{[**]{}]
@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 5, 2014

Contributor

Fixed with AjaxSearch 1.10.1. The MODX evolution github bugfix branch includes that version too.

Contributor

Jako commented Jun 5, 2014

Fixed with AjaxSearch 1.10.1. The MODX evolution github bugfix branch includes that version too.

@fourroses666

This comment has been minimized.

Show comment
Hide comment
@fourroses666

fourroses666 Jun 5, 2014

Contributor

So for fast updating from older sites just paste /index-ajax.php and /assets/snippets/ajaxSearch/ ?
(I don't think I have any sites which uses ajaxsearch thow maybe 1 or 2 max.)

Maybe this kind of stuff can be added to PackageManager in the future (1 click bugfix/update)

Contributor

fourroses666 commented Jun 5, 2014

So for fast updating from older sites just paste /index-ajax.php and /assets/snippets/ajaxSearch/ ?
(I don't think I have any sites which uses ajaxsearch thow maybe 1 or 2 max.)

Maybe this kind of stuff can be added to PackageManager in the future (1 click bugfix/update)

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 5, 2014

Contributor

Two possible solutions:

  • (fast) Update AjaxSearch to 1.10.1
  • (best) Update MODX to 1.0.14
Contributor

Jako commented Jun 5, 2014

Two possible solutions:

  • (fast) Update AjaxSearch to 1.10.1
  • (best) Update MODX to 1.0.14
@fourroses666

This comment has been minimized.

Show comment
Hide comment
@fourroses666

fourroses666 Jun 5, 2014

Contributor

thanks, always wondered where the index-ajax.php was for :)

cool new version always good to hear 👍

Contributor

fourroses666 commented Jun 5, 2014

thanks, always wondered where the index-ajax.php was for :)

cool new version always good to hear 👍

@Nicola1971

This comment has been minimized.

Show comment
Hide comment
@Nicola1971

Nicola1971 Jun 5, 2014

Contributor

is not the first time that ajaxsearch is "at risk". same story for the old (0.9x) FlexSearchForm snippet (note: always delete it from old modx installations), but quoting fourroses666 "cool new version always good to hear" :)

...shame about the package manager, but already installed on all my sites

Contributor

Nicola1971 commented Jun 5, 2014

is not the first time that ajaxsearch is "at risk". same story for the old (0.9x) FlexSearchForm snippet (note: always delete it from old modx installations), but quoting fourroses666 "cool new version always good to hear" :)

...shame about the package manager, but already installed on all my sites

@bluesparkweb

This comment has been minimized.

Show comment
Hide comment
@bluesparkweb

bluesparkweb Jun 6, 2014

round of applause for Jako though - quick work much appreciated!!

bluesparkweb commented Jun 6, 2014

round of applause for Jako though - quick work much appreciated!!

@fourroses666

This comment has been minimized.

Show comment
Hide comment
@fourroses666

fourroses666 Jun 6, 2014

Contributor

yup thanks allot 💯 👍

Contributor

fourroses666 commented Jun 6, 2014

yup thanks allot 💯 👍

@nick0

This comment has been minimized.

Show comment
Hide comment
@nick0

nick0 Jun 6, 2014

Well done to all - and thanks for fixing so quickly Jako

nick0 commented Jun 6, 2014

Well done to all - and thanks for fixing so quickly Jako

@barsproger

This comment has been minimized.

Show comment
Hide comment
@barsproger

barsproger Jun 8, 2014

Where is my thanks ))
Jako respect for you.

barsproger commented Jun 8, 2014

Where is my thanks ))
Jako respect for you.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 8, 2014

Contributor

Thanks for showing the vector.

Contributor

Jako commented Jun 8, 2014

Thanks for showing the vector.

@Jako Jako closed this Jun 8, 2014

@AgelxNash

This comment has been minimized.

Show comment
Hide comment
@AgelxNash

AgelxNash Jun 9, 2014

Contributor

This vulnerability has already 1.5 years http://modx.im/blog/security/317.html (rus). Fixed long in ClipperCMS and custom by Dmi3yy

Contributor

AgelxNash commented Jun 9, 2014

This vulnerability has already 1.5 years http://modx.im/blog/security/317.html (rus). Fixed long in ClipperCMS and custom by Dmi3yy

@yama

This comment has been minimized.

Show comment
Hide comment
@yama

yama Jun 9, 2014

Collaborator

Maybe, this vulnerability has already fixed in Japanese edition by since 2012.
https://github.com/modxcms/evolution/blob/bugfix/index-ajax.php#L12-L18
I think, these codes should be into config.inc.php or documentparser.class.inc.php.

Collaborator

yama commented Jun 9, 2014

Maybe, this vulnerability has already fixed in Japanese edition by since 2012.
https://github.com/modxcms/evolution/blob/bugfix/index-ajax.php#L12-L18
I think, these codes should be into config.inc.php or documentparser.class.inc.php.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 9, 2014

Contributor

https://github.com/modxcms/evolution/blob/bugfix/index-ajax.php#L12-L18 have just been introduced to avoid session hijacking in that file the same way as in index.php.

The main vulnerability was not fixed in Evo custom or ClipperCMS. The bad thing was hidden in AjaxSearch and is caused by allowing the post of template code with @bindings and don't check/remove this @bindings.

Contributor

Jako commented Jun 9, 2014

https://github.com/modxcms/evolution/blob/bugfix/index-ajax.php#L12-L18 have just been introduced to avoid session hijacking in that file the same way as in index.php.

The main vulnerability was not fixed in Evo custom or ClipperCMS. The bad thing was hidden in AjaxSearch and is caused by allowing the post of template code with @bindings and don't check/remove this @bindings.

yama added a commit to modxcms-jp/evolution-jp that referenced this issue Jun 9, 2014

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave Jun 9, 2014

Last week I just removed index-ajax.php from all of my sites, and this week we have 3 more that were hacked.

matdave commented Jun 9, 2014

Last week I just removed index-ajax.php from all of my sites, and this week we have 3 more that were hacked.

@Haprog

This comment has been minimized.

Show comment
Hide comment
@Haprog

Haprog Jun 9, 2014

Collaborator

You also need to remove or update the AjaxSearch snippet files.

Collaborator

Haprog commented Jun 9, 2014

You also need to remove or update the AjaxSearch snippet files.

@matdave

This comment has been minimized.

Show comment
Hide comment
@matdave

matdave commented Jun 9, 2014

@Haprog

This comment has been minimized.

Show comment
Hide comment
@Haprog

Haprog Jun 9, 2014

Collaborator

@matdave Good point. I'm not totally sure now, but I think you need to either upgrade to MODX 1.0.14 or do both points 1 and 2.

Collaborator

Haprog commented Jun 9, 2014

@matdave Good point. I'm not totally sure now, but I think you need to either upgrade to MODX 1.0.14 or do both points 1 and 2.

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 9, 2014

Contributor

@matdave You are right: If AjaxSearch snippet is called anywhere on the page, you have to update to AjaxSearch 1.10.1. Deleting index-ajax.php is not enough. Sorry, but I did not see that part of the issue.

Contributor

Jako commented Jun 9, 2014

@matdave You are right: If AjaxSearch snippet is called anywhere on the page, you have to update to AjaxSearch 1.10.1. Deleting index-ajax.php is not enough. Sorry, but I did not see that part of the issue.

@bossloper

This comment has been minimized.

Show comment
Hide comment
@bossloper

bossloper Jun 9, 2014

Contributor

@Jako "If AjaxSearch snippet is called anywhere on the page" - though presumably only in 'ajax' mode? I.e. if AjaxSearch is used in none 'ajax' mode with the parameter: &ajaxSearch='0' then there is no immediate issue with AjaxSearch?

Contributor

bossloper commented Jun 9, 2014

@Jako "If AjaxSearch snippet is called anywhere on the page" - though presumably only in 'ajax' mode? I.e. if AjaxSearch is used in none 'ajax' mode with the parameter: &ajaxSearch='0' then there is no immediate issue with AjaxSearch?

@fourroses666

This comment has been minimized.

Show comment
Hide comment
@fourroses666

fourroses666 Jun 9, 2014

Contributor

why is ajaxsearch default anyway, I personally use it 1 out 50 sites and could be downloaded with package manager?

i really would like to see packagemanager default the sooner the better.. (off topic)

Contributor

fourroses666 commented Jun 9, 2014

why is ajaxsearch default anyway, I personally use it 1 out 50 sites and could be downloaded with package manager?

i really would like to see packagemanager default the sooner the better.. (off topic)

@Jako

This comment has been minimized.

Show comment
Hide comment
@Jako

Jako Jun 9, 2014

Contributor

@uxello It is that bad: AjaxSearch has only to be called on the page to cause the vulnerability.

Contributor

Jako commented Jun 9, 2014

@uxello It is that bad: AjaxSearch has only to be called on the page to cause the vulnerability.

@bossloper

This comment has been minimized.

Show comment
Hide comment
@bossloper

bossloper Jun 9, 2014

Contributor

Thanks Jako.

Contributor

bossloper commented Jun 9, 2014

Thanks Jako.

yama added a commit to modxcms-jp/evolution-jp that referenced this issue Jun 10, 2014

@akinyeleolubodun

This comment has been minimized.

Show comment
Hide comment
@akinyeleolubodun

akinyeleolubodun Oct 5, 2015

Thanks so much. This is so insightful. I was just thinking of dropping MODx as the CMS for my clients because I am tired of this issue of malware. I will try this and I pray all should be okay.

akinyeleolubodun commented Oct 5, 2015

Thanks so much. This is so insightful. I was just thinking of dropping MODx as the CMS for my clients because I am tired of this issue of malware. I will try this and I pray all should be okay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment