MySQL Dynamic SQL Injection in Frostmourne 1.0 Monitor

BUG_Author: Chengxin Xu

Affected Version: frostmourne (1.0)

Vulnerability Files:

•
frostmourne-monitor/src/main/java/com/autohome/frostmourne/monitor/service/core/query/impl/MysqlDataQuery.java​

•
frostmourne-monitor/src/main/java/com/autohome/frostmourne/monitor/service/core/metric/jdbc/MysqlObjectMetric.java​

•
frostmourne-monitor/src/main/java/com/autohome/frostmourne/monitor/controller/AlarmController.java​

Description

Frostmourne Monitor contains a MySQL dynamic SQL injection vulnerability in the alarm preview/query flow. The metricContract.queryString value is treated as trusted SQL and is directly concatenated into backend queries without parameterization or whitelist validation. An authenticated attacker who can access the alarm preview functionality can first enumerate an available MySQL data name and then supply arbitrary SQL expressions that are executed by the server against the corresponding MySQL data source.​

MySQL Dynamic SQL Injection via Alarm Preview (/api/monitor-api/alarm/previewData)​

The vulnerability chain starts from the AlarmController.httpTest() endpoint exposed at /api/monitor-api/alarm/previewData. User-controlled JSON is accepted and then routed to the MySQL metric implementation without sanitizing the supplied SQL string:​

Entry Point (AlarmController.java:55-67):

代码块

@PermissionLimit(limit = false)​
@RequestMapping(value = "/previewData", method = RequestMethod.POST)​
public Protocol<Map<String, Object>> httpTest(@RequestBody AlarmContract alarmContract) {​
    try {​
        alarmAdminService.padAlarm(alarmContract);​
        DataSourceType dataSourceType = alarmContract.getMetricContract().getDataSourceContract().getDatasourceType();​
        IMetric metric = metricService.findMetric(dataSourceType, alarmContract.getMetricContract().getMetricType());​
        Map<String, Object> result = metric.pullMetric(alarmContract.getMetricContract(), alarmContract.getRuleContract().getSettings());​
        return new Protocol<>(result);​
    } catch (Exception e) {​
        return Protocol.fail(e.getMessage());​
    }​
}​

The attacker-controlled metricContract.queryString reaches the MySQL query layer through MysqlObjectMetric.pullMetric():​

Query Dispatch (MysqlObjectMetric.java:23-35):

代码块

@Override​
public Map<String, Object> pullMetric(MetricContract metricContract, Map<String, String> ruleSettings) throws DataQueryException {​
    Map<String, Object> result = new HashMap<>();​
    MetricData metricData = mysqlDataQuery.querySql(metricContract);​
    result.put("NUMBER", metricData.getMetricValue());​
    if (metricData.getLatestDocument() != null) {​
        result.putAll(metricData.getLatestDocument());​
    }​
    if (metricData.getTopNDocuments() != null) {​
        result.put("TOP_N_DOCUMENTS", metricData.getTopNDocuments());​
    }​
    Map<String, String> dataNameProperties = metricContract.getDataNameContract().getSettings();​
    result.putAll(dataNameProperties);​
    return result;​
}​

The actual vulnerable code is in MysqlDataQuery.querySql(), where the attacker-supplied SQL is concatenated directly into a subquery:​

Vulnerable Code (MysqlDataQuery.java:66-69):

代码块

@Override​
public MetricData querySql(MetricContract metricContract) throws DataQueryException {​
    String sql = "select * from ("+ metricContract.getQueryString() + ") t limit 50";​
    return collectResult(sql, metricContract);​
}​

The same untrusted SQL is then reused again in the count query path:

Secondary Injection Sink (MysqlDataQuery.java:88-90):

代码块

String collectSql = "select count(*) cnt from (" + sql + ") t";​
List<Map<String, Object>> mapList = jdbcDao.query(dataSourceContract, collectSql, new HashMap<>());​

MySQL Dynamic SQL Injection in Frostmourne 1.0 Monitor​

MySQL Dynamic SQL Injection in Frostmourne 1.0 Monitor