Port 8096 allows unauthenticated access from any IP.

[GabrielBrascher]

ISSUE TYPE

• Bug Report

COMPONENT NAME

API

CLOUDSTACK VERSION

master

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

CloudStack provides CloudStack API Unauthenticated Access through port 8096. It should not be open to the Internet in any case. If this port is not properly blocked by a firewall it could be really serious.

STEPS TO REPRODUCE

Using 8080:
http://:8080/client/api?command=listClusters&response=json&listAll=true&page=1&pagesize=20&_=1556128046728

{"listclustersresponse":{"uuidList":[],"errorcode":401,"errortext":"unable to verify user credentials and/or request signature"}}

Using 8096:
http://:8096/client/api?command=listClusters&response=json&listAll=true&page=1&pagesize=20&_=1556128046728

listed all clusters of the zone

EXPECTED RESULTS

curl: (7) Failed to connect to <acs-environment> port 8096: Connection refused
[1]   Exit 7                  curl http://<acs-environment>:8096/client/api?command=listClusters

ACTUAL RESULTS

listed all clusters of the zone

FIX proposal

I have implemented a fix that binds the port 8096 with the loopback address (127.0.0.1). Tested and so far it looks all right. Still need to open a PR.

[rohityadavcloud]

Not a bug, ships disabled by default. This is a useful feature for testing etc. integration.api.port can be used to turn off and on.

[GabrielBrascher]

Closing this issue. However, I think that port 8096 is not disabled by default, at least on ACS environments deployed via deb packages. Thanks for the feedback, @rhtyd.

[onitake]

I don't think "works as designed" is going to cut it here.

The upgrade docs from 4.5 explicitly mention this management port needs to be active during the upgrade procedure, so scripts can access the API unauthenticated: http://docs.cloudstack.apache.org/en/4.11.2.0/upgrading/upgrade/upgrade-4.5.html#system-vms-and-virtual-routers

Nothing says that the port is a serious security risk and should be disabled afterwards.

I think a forced binding to localhost would be useful to avoid a potential foot-gun.

Also, what would be the correct value to disable this feature? The value is interpreted as "int", but what would "disable" be? 0? -1?

[onitake]

The code treats null as disabled: https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/ApiServer.java#L409-L412

But there doesn't seem to be a way to set this variable to null it's only validated as an integer.... https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/ApiServer.java#L228-L234

[GabrielBrascher]

@onitake I agree, I have seen some gray lines on this implementation as well. However, it is possible to disable it when setting with 0 (zero). I tested it myself prior to closing this issue.

The fact that it was configured by default with 8096 concerns me (acs deployed via deb packages on ubuntu). @onitake we might need to take a closer look on the documentations and eventually update it.

@rhtyd @PaulAngus @andrijapanic @borisstoyanov is this port really needed to stay open for testing purposes or we could leave it bound with 127.0.0.1, performing such tests inside the ACS management node?

[rohityadavcloud]

I would advise to keep the feature as is, and improve the cloudstack-sysvmadm to accept apikey or secret key, or username password for authentication. The script maybe rewritten to use cloudmonkey.

[onitake]

That sounds promising.
Perhaps it makes sense to deploy a local access key during CloudStack installation (or upgrade), that can then be used by the admin script.
Or, the documentation should state that the user must obtain and deploy an access key on the system together with cloudmonkey early on after installation.

However, I think that the main issue is that many CloudStack installations are under risk right now, because users might not understand the consequences of opening port 8096 when they followed the guide. This is pretty serious, IMHO.