The incompetence of the turnstiles makes it a good focus for the story while the juxtaposition of the turnstiles with Jira exposes the company's hypocrisy.
The incompetence of the turnstiles makes it a good focus for the story while the juxtaposition of the turnstiles with Jira exposes the company's hypocrisy.
It's an issue but I wouldn't call it a particularly big issue. I don't think it's very damning for how much the company cares about security.
And it sounds like the turnstiles did work for actual security? Sure, they gave up on per-floor security, but that's a lot less important.
Edit: And if employees are reusing passwords then we should be getting them password managers (or SSO) as the top priority, much more than we worry about logins in cookies inside the building. I mean, there's a point where a single purpose password and a login token become the same thing.
SSO is much more common these days, but that it wasn't the case back then.
And password managers have been plenty well known for a long time.
And you can set HttpOnly to stop javascript from being able to access the cookie... but that still won't stop the attack of making them log in again.
1. Initial access to physical machine, most likely via phishing malware, reckless employees downloading untrusted content, or bad luck.
2. Malware looks for browser cookies, hoping to steal temporary credentials but instead gains persistent creds, which grant Jira access. People re-use passwords; malware tries this password against AdUser and any other systems or other corp user accounts it can find
3. Direct Jira access used to pivot, that custom Jira app is probed for app vulns (likely given design).
1. Get e-mail from boss, look at headers, find boss IP addy
2. Failing that, memorize boss office number or workstation tag, run stealthy network scan, do reverse dns lookup
3. Be a router, arp spoof mitm attack
4. ?????
5. Profit