Hacker News new | ask | show | jobs
by 6D794163636F756 1071 days ago
It can really depend on the nature of the vulnerability and who discovered it. Based on the timeline at the bottom of this article it seems like this was way too slow. Based on the cve information this was ranked as 9.8. The last time I dealt with a bug that bad it was log4j. It was found on a Tuesday, patched on a Thursday, announced on a Friday, and I redeployed all of our servers over the weekend.

The most egregious part in my eyes is the slow response to the initial contact. In shows that Service Now does not monitor it's reporting and that they don't care about security. If I were using a product of theirs to handle proprietary or privileged information I would no longer trust them.

1 comments

I suspect the CVSS score has been over-estimated. For the "scope" metric, the "vulnerable component" and the "affected component" are both ServiceNow itself, so that should be "unchanged": https://security.stackexchange.com/a/129205

That drops you down to an 8.8. Also, log4shell was a 10.0, which got that extra .2 points from not requiring any privs, whereas this ServiceNow vuln requires "low" privs.

Hi, ServiceNow dev here. I'd agree that the CVSS might be a little overinflated, but I don't think by much.

I would argue that ServiceNow as a singular component is flawed. It could be several applications on a single instance: Vulnerability Response, Security Incident Response, IT Service Management, IT Operations management, Vendor Risk Management, CMDB, etc.

I actually think in some instances, this vulnerability is considerably worse due the information it provides. User contact information, an inventory of the security vulnerabilities across the organization, applications & versions, Server information, etc. The social engineering issues are massive since they can spoof from essentially your service desk.

Often times ServiceNow has access to other subsystems. Midservers, provisioning tools, monitoring systems, desktop orchestration tools. These systems are often used to handle the response & monitoring. The ServiceNow teams are often understaffed and underskilled.

I've only been thinking about this for the last hour, but compromise 1 account (and I can think of at least 5 different ways that could happen) and a hacker could have:

- a complete topology of your infrastructure

- your active security vulnerabilities

- contact information for your entire company

- a very convincing spoofing method

- the ability to remotely install software on customer desktops

- the ability to monitor your response to security issues

- access to your provisioning tools

This kind of attack could go undetected for years. God forbid ServiceNow's internal instance got compromised. They can remote in to ANY instance.