petecooper
commented
3 years ago Hi @reasdf - thanks for your report. We have discussed your issue internally within the development team, please find a summary / response below.
Your first observation relating to plugin upload has been addressed in the upcoming Textpattern 4.9 release, and we are researching possible ways to relocate the plugin directory without breaking existing installations. There are existing user privilege levels already in place that restrict uploading and activating plugins, so only trusted higher-privilege users can perform this action. Randomising plugin names would not be appropriate in this case as it would break existing Textpattern installations.
Your second observation relating to article body content is something we receive communications about from time to time. We have summarised our stance here:
https://textpattern.com/weblog/security-considerations-and-user-privileges-in-textpattern#exploit1
Note that again this is partially a user privilege / trust issue. Lower tier users have fewer user privileges, and any instance of Textpattern should be secured with passwords according to the organisation's guidelines. Administrators should ensure any system they maintain is securely managed, including password strength & rotation, user privilege sanity checking and other industry standard security practices for self-hosted software.
I will leave this issue open for a short while for any other team members to comment on.
We appreciate your communication. Please refer to https://textpattern.com/contact for the preferred way of contacting us regarding vulnerabilities, loopholes and similar security issues.
Thank you, and best wishes.
abergmann
Hi I found two loopholes. In version V4.8.4。 The first one: The location where the plug-in is uploaded in the background without any security verification. You can upload Trojan files to obtain system permissions. The second one: the storage type xss exists in the place where the article is written. Next are the details of the exploit: The first vulnerability: Because the backend login location does not have a verification code and no lock policy is set, if an attacker enters the backend through brute force cracking, the attacker can upload the php Trojan file, because the file path after saving is regular , So the attacker can connect to the Trojan horse file through a hacker tool to obtain system permissions.
Access to Trojan files to verify that the vulnerability exists.
Hacking tools connect to Trojan files to obtain system permissions.
The second vulnerability: If a low-privilege user uses the vulnerability to write malicious code and publish it, all people who view this article will be attacked. He can obtain the administrator’s cookie information, and the administrator’s cookie can be used directly by the administrator. Log in to the background system with permission. You can also continue to exploit the first vulnerability after logging in.
The administrator's access to the article triggers a pop-up window to verify that the vulnerability exists.
The attacker obtains the administrator cookie.
Repair suggestions: The first vulnerability: verify the format of the uploaded file, verify the content of the file, and set the uploaded file name to random. The second vulnerability: html entity conversion or filtering of sensitive words input by the user, such as <, >,', ", script.