[komuW]

From the circleCI blogpost[1]: "Our investigation indicates that the malware was able to execute session cookie theft, enabling them to impersonate the targeted employee in a remote location"

I haven't seen much discussion on how this specific attacker entrypoint can be mitigated. So I'm going to make a naive attempt in this comment.

How about storing the client's IP address in the session cookie. Then whenever the server recieves the cookie, it compares the client's IP address against the one stored in the session cookie. The server denies the login if there's a mismatch. The cookie would of-course have to be signed(hmac etc) so that it is tamper proof.

One problem with this is that client IP addresses are easily spoofed[2].

So, instead of storing the client's IP address; how about we instead store the clients' SSL fingerprints[3][4]. I haven't looked much into the literature, but I think those fingerprints are hard to spoof.

1. https://circleci.com/blog/jan-4-2023-incident-report/

2. https://adam-p.ca/blog/2022/03/x-forwarded-for/

3. https://github.com/salesforce/hassh

4. https://github.com/salesforce/ja3

[mschuster91]

> How about storing the client's IP address in the session cookie. Then whenever the server recieves the cookie, it compares the client's IP address against the one stored in the session cookie. The server denies the login if there's a mismatch.

That doesn't work in environments with multiple NAT origin IPs in place, or when they're using crap like Netskope/some other "security"/"privacy"/"VPN" software, as IPs tend to randomly change with these. It would generate way too many false-positive reports.

> One problem with this is that client IP addresses are easily spoofed[2].

Only if the backend servers are badly set up. For me, I always run haproxy as the frontend and forcibly delete incoming headers (X-Forwarded-*, Forwarded), and as an added precaution the backend software is configured to only trust the haproxy origin IPs - so even in the case an attacker manages somehow to directly access the backend servers directly, they cannot get a spoofed IP past the system.

> So, instead of storing the client's IP address; how about we instead store the clients' SSL fingerprints

That requires client-side SSL authentication, which is theoretically supported by all major browsers, but very rarely used and the UI support is... clunky at best.

[komuW]

> That requires client-side SSL authentication,

I do not think it requires client side SSL. See: https://engineering.salesforce.com/tls-fingerprinting-with-j...

What is been fingerprinted is the TLS negotiation between client and server.

[eigenvalue]

These issues would be addressed by something like Tailscale, but of course they also got hacked recently…

[AYBABTME]

Then the malware will proxy via your machine.

[komuW]

yeah this just kicks the can down the road.