5 ms·

It seems like malware stealing browser cookies of authenticated sessions can work around even U2F, and highlights a bit of a hole in how sessions are protected

by g_p 4y ago

It seems like malware stealing browser cookies of authenticated sessions can work around even U2F, and highlights a bit of a hole in how sessions are protected (or not), and where it may make sense to reauthenticate the user when in doubt.

Gigachad 4y ago
You’d almost want to pair the session with some kind of hardware like the TPM or Secure Enclave to prevent it being transferable.
- no_time 4y ago
  If someone call steal your session, what is stopping them from making requests on your behalf?
  - anonym29 4y ago
    in practice, this would probably work something like: - hardware enclave contains public and private key pair - browser retrieves public key, sends to remote host (website) - website sends back a unique token with the response to every valid request from that client (kinda like anti-csrf tokens) - browser asks enclave to write a message containing that token, signed with private key - when the browser sends the next request, include the cryptographically signed message containing the last token received by the server - website checks that the returned signed message includes the correct token, and has a valid cryptographic signature matching the provided pubkey this would be entirely transparent to the end user and would prevent simple replay attacks with the token, which seems to be Gigachad's idea (prevent it from being transferred) unfortunately, as you point out, even provided the adversary cannot retrieve the private key, this means that as long as the secure enclave is connected and accessible, and as long as the adversary maintains code execution on the victim machine, the attacker could simply issue requests necessary to perform account takeover from the victim machine, rather than their own machine. in security, it is extremely challenging to design systems that remain secure even when an adversary has access equal to or exceeding that of legitimate, authorized users, as is typically the case when malware is dropped on a machine, which is probably the most common way cookies with secure and httponly flags set get stolen. Sadly, the security model of most x86 operating systems like Windows is well-suited to protecting system administrative functions, like installing drivers, but is poorly suited to protecting ring 3 / userland software (like the cookies from your browser, which are stored on disk) from other ring 3 / userland software (like that cookie stealer that just got ran with the same privileges of your freshly-exploited PDF reader) obligatory xkcd: https://xkcd.com/1200/ https://xkcd.com/1200/ Somewhat interestly, the security model of modern mobile operating systems like Android and iOS is ostensibly much better at protecting against threats like this - even if you install a blatantly malicious app, if you're not rooted, that app is not able to simply read your browser's cookie file from disk. That sort of security model can feel extremely restrictive from the perspective of 'typical' x86 OS users, but will feel right at home for anyone using special compartmentalization-based security-focused OS's like Qubes, where your PDF reader gets opened in a disposable VM entirely distinct from your browser's VM. This isn't unhackable, but as someone who hacks for a living (red team at big tech co), it's a barrier that would stop me unless a fresh, public Xen escape CVE drops tomorrow.
noodlesUK 4y ago
I figure that some kind of MAC sandboxing for cookies and similar credentials probably seems like a good idea. I think that macOS has something like this with per-application sandboxes, but I don't know how effective this is.

by g_p 4y ago

Gigachad 4y ago

You’d almost want to pair the session with some kind of hardware like the TPM or Secure Enclave to prevent it being transferable.

no_time 4y ago
If someone call steal your session, what is stopping them from making requests on your behalf?
- anonym29 4y ago
  in practice, this would probably work something like: - hardware enclave contains public and private key pair - browser retrieves public key, sends to remote host (website) - website sends back a unique token with the response to every valid request from that client (kinda like anti-csrf tokens) - browser asks enclave to write a message containing that token, signed with private key - when the browser sends the next request, include the cryptographically signed message containing the last token received by the server - website checks that the returned signed message includes the correct token, and has a valid cryptographic signature matching the provided pubkey this would be entirely transparent to the end user and would prevent simple replay attacks with the token, which seems to be Gigachad's idea (prevent it from being transferred) unfortunately, as you point out, even provided the adversary cannot retrieve the private key, this means that as long as the secure enclave is connected and accessible, and as long as the adversary maintains code execution on the victim machine, the attacker could simply issue requests necessary to perform account takeover from the victim machine, rather than their own machine. in security, it is extremely challenging to design systems that remain secure even when an adversary has access equal to or exceeding that of legitimate, authorized users, as is typically the case when malware is dropped on a machine, which is probably the most common way cookies with secure and httponly flags set get stolen. Sadly, the security model of most x86 operating systems like Windows is well-suited to protecting system administrative functions, like installing drivers, but is poorly suited to protecting ring 3 / userland software (like the cookies from your browser, which are stored on disk) from other ring 3 / userland software (like that cookie stealer that just got ran with the same privileges of your freshly-exploited PDF reader) obligatory xkcd: https://xkcd.com/1200/ https://xkcd.com/1200/ Somewhat interestly, the security model of modern mobile operating systems like Android and iOS is ostensibly much better at protecting against threats like this - even if you install a blatantly malicious app, if you're not rooted, that app is not able to simply read your browser's cookie file from disk. That sort of security model can feel extremely restrictive from the perspective of 'typical' x86 OS users, but will feel right at home for anyone using special compartmentalization-based security-focused OS's like Qubes, where your PDF reader gets opened in a disposable VM entirely distinct from your browser's VM. This isn't unhackable, but as someone who hacks for a living (red team at big tech co), it's a barrier that would stop me unless a fresh, public Xen escape CVE drops tomorrow.

noodlesUK 4y ago

I figure that some kind of MAC sandboxing for cookies and similar credentials probably seems like a good idea. I think that macOS has something like this with per-application sandboxes, but I don't know how effective this is.