There is a peice of software i am using at work that has several components to it, lets call them the server and agents.
the server runs an api over https that the agents use to communicate with it.
the server can be cloud hosted or locally hosted.
the entire api is accessible without any authentication process by providing the guid for a given agent in the header of the request. the api is also available for non agents to use (though the published functionality available is slightly different its the same api with no special restrictions to identify if its an agent or just random http request from anyone)
these guids are not visible in the web front end of the server application, nor in the gui for the agent application. and the agent is not going to be running on user machines - more like IT staff only accessed vms.
the api allows extraction of passwords and other data that is stored encrypted on the db. depending on how much you trust this software you may store some very powerful credentials in there.
the guids appear to be .net generated using version 4 i think its called (sorry i have limited security knowledge) as in the first character of the third grouping is a 4 when in the MS format, i don't see any any code in the db to create the guids and its a asp.net web app that hosts the api.
calls to the api don't appear to be rate limited, even for multiple not authorised requests, there appears to be no subnet or ip address filtering going on - apparently not even on the cloud instance (though again i am no security person, maybe i am on a watch list now and everything i send them is treated differently)
these guids are stored unencrypted in the server application DB.
i raised this with the vendor as a ticket and they basically say its as per design, and to their credit they investigated this VERY fast (given the apparent size of the company).
am i crazy in thinking this is very bad?
Seems like now anyone with db access, agent access or network hardware access now has the ability to get whatever they want. also a momentary failing of https traffic for some reason (e.g. you use the cloud instance and for a short period of time someone manages to man-in-the-middle you) and until you delete those agents you are wide open. without even logging of access to extract credentials? - at least from me as the clients perspective i don't see it (other than if i went to look at IIS logs on a local instance i guess).
Apparently the guids cannot be predicted (as in i cannot register a bunch of agents with the cloud instance and predict what the next customers guid will be) but it seems weird that if i authenticate with the api the one time access token i get is many times more complicated that a guid but is only valid for that session, while the guid lasts basically forever.
You can divide agents up logically to restrict what data they have access to, something which has all of sudden become very significant now that i have found this potential hole, so maybe its just on me to make the business aware of this etc?
Maybe there is just no way round this issue for this type of application, i have never written anything like this. but at the very least i would expect some attempt at tightening this restriction
- restrict use of this key to known ip addresses (or at least generate a warning when ip addresses change or make it an option)
- only use the key in initial handshake then use a token from there on in so not all traffic is vulnerable
- maybe create a new one of these keys each time the agent successfully connects to the server
i don't know, as i said i have never written a server-agent type application, maybe i am just naive?