| 描述 | MicroCommunity (also known as HC Community Management System) v2.0 and all prior versions contain a critical unauthenticated SQL injection vulnerability in the java110-service module's business compensation endpoint. The vulnerability exists in the POST /businessApi/fallBack interface, which is intended to execute compensating SQL statements during business order rollbacks but is exposed to the public Internet without any authentication, authorization, signature verification, IP allowlisting, or input sanitization.
The endpoint is implemented in the BusinessApi.java controller class, where the fallBack method accepts an arbitrary request body as a String parameter and passes it directly to the queryServiceSMOImpl.fallBack() method without any validation. The QueryServiceSMOImpl.fallBack() implementation parses the request body as a JSON array, extracts the fallBackSql field from each array element, and passes the raw SQL string to queryServiceDAOImpl.updateSql() for immediate execution. No SQL keyword filtering, business context validation, or operation source verification is performed at any point in the call chain.
The root cause of the SQL injection lies in the MyBatis mapper file QueryServiceDAOImplMapper.xml, where the updateSql statement is defined using the dollar-sign placeholder syntax rather than the safe hash placeholder syntax. This causes MyBatis to perform raw string concatenation rather than parameterized binding, effectively turning the SQL statement into a direct call to Statement.execute() with attacker-controlled input. Because the entire SQL statement is the parameter itself, an attacker can submit any DML or DDL statement, including UPDATE, DELETE, INSERT, DROP, CREATE, ALTER, and TRUNCATE operations against any table in the application database.
The vulnerability is compounded by a critical authentication bypass in the ServiceConfiguration.jwtFilter() method. The JwtFilter is registered with only four URL patterns (the root path, /callComponent/, /flow/, and /app/). The /businessApi/ path prefix is completely excluded from the JWT authentication filter, which means the /businessApi/fallBack endpoint is reachable by any unauthenticated client on the Internet. The same authentication gap also affects other path prefixes including /ownerApi/, /privilegeApi/, /cmd/, /bill/, and /fee/*, leaving large portions of the application's API surface unprotected.
Because the fallBack method uses MyBatis executeUpdate, SELECT statements do not return results directly to the caller. However, an attacker can still exfiltrate arbitrary data by abusing a second unauthenticated endpoint (POST /businessApi/query) combined with a pre-cached BeanShell service named api.getNoticesByJava. This service is loaded into Redis at application startup and executes a parameterized query against the n_notice table using a noticeId parameter supplied by the attacker. The attack chain works by using the SQL injection to copy sensitive data from arbitrary tables into the n_notice table via INSERT...SELECT statements, then querying the api.getNoticesByJava service with the corresponding noticeId to read back the exfiltrated data as a normal JSON response. This technique enables zero-login full database exfiltration without requiring any cache refresh or administrative action.
During authorized testing on a publicly exposed production instance, the vulnerability was confirmed to allow extraction of the complete u_user table including password hashes for all users such as the administrator account, the c_mapping configuration table containing WeChat Pay merchant keys, Tencent Cloud SMS AccessKey and SecretKey, RSA public keys, FTP credentials, IoT platform credentials, and mall administrator accounts, the mysql.user table containing MySQL authentication strings, and complete schema enumeration via information_schema. The password hashing algorithm used by the application is a double MD5 of the plaintext password concatenated with a hardcoded salt value embedded in the AuthenticationFactory class. Combined with default administrative credentials, this allows an attacker to authenticate as an administrator after extracting the password hash.
The vulnerability can also be escalated to remote code execution. The c_service_sql table contains a java_script column that stores BeanShell code executed by the application's BeanShell interpreter when the corresponding service is invoked and the query_model column is set to the BeanShell execution mode. By using the SQL injection to modify the java_script column of an existing service entry with attacker-controlled BeanShell code, and then refreshing the Redis cache via the /app/flush.center.cache endpoint using default administrative credentials, the malicious BeanShell code is loaded and executed when the target service is next invoked, achieving remote code execution on the application server. This allows the attacker to read application configuration files including database credentials, execute operating system commands, and establish persistence on the host.
The CVSS v3.1 base score for this vulnerability is 9.8 Critical, with the vector string AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The vulnerability requires no privileges, no user interaction, and is exploitable over the network with low attack complexity. It results in full compromise of confidentiality, integrity, and availability of the affected system.
The vulnerability affects all versions of MicroCommunity up to and including v2.0. The vulnerable code has been present since the initial commit of the affected files and there is currently no patched version available. Any internet-exposed deployment of MicroCommunity is vulnerable, including SaaS property management installations and community owner application backends. The application is typically deployed on port 8008 directly or proxied through Nginx to ports 80 or 88, and public instances can be enumerated through standard search engine queries using application-specific fingerprint strings.
Remediation requires multiple layers of defense. First, the JwtFilter URL pattern registration must be changed to intercept all paths by default, using the wildcard pattern instead of the four specific path patterns, with only truly anonymous endpoints such as payment callbacks added to the exclusion list. Second, the /businessApi/fallBack endpoint should either be removed entirely if not needed, or restricted to internal service-to-service calls using mutual TLS or internal network IP allowlisting. Third, the MyBatis mapper must be refactored to remove the generic executeSql, updateSql, executeProc, and updateProc nodes that accept raw SQL via dollar-sign placeholder syntax. All business SQL must be defined as dedicated mapper statements using hash placeholder parameterization. Fourth, the fallBack method should be rewritten to accept a service code and operation identifier rather than raw SQL, looking up predefined compensating SQL statements from a whitelist registry and binding all dynamic values through PreparedStatement parameter setter methods. Fifth, the MySQL account used by the application must follow the principle of least privilege, with FILE, PROCESS, and SUPER privileges revoked, and DROP, ALTER, and CREATE privileges removed from business tables. Sixth, hardcoded default credentials must be removed and replaced with mandatory password setup during installation. Seventh, static analysis tools should be integrated into the continuous integration pipeline to detect unsafe placeholder usage, runtime command execution, and BeanShell interpreter invocations. Eighth, comprehensive audit logging should be implemented for all DDL operations and modifications to the c_service_sql table, including operator identity, source IP, and full SQL text, with alerting on suspicious activity.
This vulnerability represents a complete bypass of the application's security controls, allowing an unauthenticated remote attacker to read, modify, or destroy the entire application database, extract sensitive configuration secrets, escalate to remote code execution, and potentially pivot to internal network resources through credentials obtained from the configuration tables. Immediate mitigation is required for any publicly exposed MicroCommunity deployment, including temporary blocking of the vulnerable endpoint at the reverse proxy or web application firewall layer until a permanent patch is available. |
|---|