5 ms·
From the circleCI blogpost[1]: "Our investigation indicates that the malware was able to execute session cookie theft, enabling them to impersonate the targeted
by komuW 4y ago
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/ https://circleci.com/blog/jan-4-2023-incident-report/
2. https://adam-p.ca/blog/2022/03/x-forwarded-for/ https://adam-p.ca/blog/2022/03/x-forwarded-for/
3. https://github.com/salesforce/hassh https://github.com/salesforce/hassh
4. https://github.com/salesforce/ja3 https://github.com/salesforce/ja3
- AYBABTME 4y agoThen the malware will proxy via your machine.
- komuW 4y agoyeah this just kicks the can down the road.
- mschuster91 4y ago> 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.
- eigenvalue 4y agoThese issues would be addressed by something like Tailscale, but of course they also got hacked recently…
- komuW 4y ago> That requires client-side SSL authentication, I do not think it requires client side SSL. See: https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/ https://engineering.salesforce.com/tls-fingerprinting-with-j... What is been fingerprinted is the TLS negotiation between client and server.
- mschuster91 4y agoThat fingerprints a piece of software (and, if SSL library versions or configurations change, the version), but not a specific client. It's virtually worthless as a security measure if the endpoint is a common browser.