[opensuse] Help understanding new HTTPS breach?
All, I just saw: http://www.kb.cert.org/vuls/id/987798 It is a scary sounding attack since so much banking etc. is conducted via SSL Can someone explain the lifecycle of this attack to me? Does the vulnerability mean that an attacker could: - infect s PC (obviously linux is more difficult than windows, but Java vulnerabilities exist anywhere it is used) - use malware introduced via infection to query various banks and break SSL encryption key without the user even being logged into the protected website - watch network activity until a login to one of the banks in question occurs, then capture the login / password (Obviously, any ssl protected website could be similarly attacked. eg. gmail, salesforce, etc.) I assume that for a bad guy with the exploit in hand the hardest part of the above is monitoring the network activity at a low enough level to observe the compressed packets? Can software running with normal user privileges observe their own packets in that much detail, or does this attack require root access on the victim computer? Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Aug 12, 2013 at 10:12:13AM -0400, Greg Freemyer wrote:
All,
I just saw: http://www.kb.cert.org/vuls/id/987798
It is a scary sounding attack since so much banking etc. is conducted via SSL
Can someone explain the lifecycle of this attack to me?
Does the vulnerability mean that an attacker could:
- infect s PC (obviously linux is more difficult than windows, but Java vulnerabilities exist anywhere it is used)
After this step a malware could just sniff keypresses, trojan binaries and not bother with weird cryptography exploits. ;) The idea is here to run a malicious webpage in the browser (without it escaping the browser sandbox).
- use malware introduced via infection to query various banks and break SSL encryption key without the user even being logged into the protected website - watch network activity until a login to one of the banks in question occurs, then capture the login / password
(Obviously, any ssl protected website could be similarly attacked. eg. gmail, salesforce, etc.)
I assume that for a bad guy with the exploit in hand the hardest part of the above is monitoring the network activity at a low enough level to observe the compressed packets?
Likely yes.
Can software running with normal user privileges observe their own packets in that much detail, or does this attack require root access on the victim computer?
No. As far as understand this still needs to happen in the same TLS session somehow, and so the attack will guess a token that a malicious other site would need to send to do stuff. The compressed reply size would need to be observed somehow, which a browser session would not be able to. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Aug 12, 2013 at 10:36 AM, Marcus Meissner <meissner@suse.de> wrote:
Can software running with normal user privileges observe their own packets in that much detail, or does this attack require root access on the victim computer?
No.
As far as understand this still needs to happen in the same TLS session somehow, and so the attack will guess a token that a malicious other site would need to send to do stuff.
The compressed reply size would need to be observed somehow, which a browser session would not be able to.
If your right about it having to be the same TLS session, then the malware would need to monitor browser sessions until it sees a TLS session initiated. Then start a background crypto attack from within the same TLS session, then magically monitor the TCP/IP stack to see the compressed packet sizes to allow the crypto attack to proceed. Once successful it could observe / decode future traffic on the TLS session but not that which had already happened? As to your comment about a keylogger, are the known Java vulnerabilities such that the attacker can monitor keyboard activity. If so, I see why that would be a far more significant vulnerability that this new one. Thanks Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Aug 12, 2013 at 11:01:09AM -0400, Greg Freemyer wrote:
On Mon, Aug 12, 2013 at 10:36 AM, Marcus Meissner <meissner@suse.de> wrote:
Can software running with normal user privileges observe their own packets in that much detail, or does this attack require root access on the victim computer?
No.
As far as understand this still needs to happen in the same TLS session somehow, and so the attack will guess a token that a malicious other site would need to send to do stuff.
The compressed reply size would need to be observed somehow, which a browser session would not be able to.
If your right about it having to be the same TLS session, then the malware would need to monitor browser sessions until it sees a TLS session initiated. Then start a background crypto attack from within the same TLS session, then magically monitor the TCP/IP stack to see the compressed packet sizes to allow the crypto attack to proceed.
Once successful it could observe / decode future traffic on the TLS session but not that which had already happened?
Actually it could capture data transmitted within the session. It would not be able decrypt the session itself. But yes, so far its mostly a lab setting or for an attacker able to hook into network infrastructure like the NSA.
As to your comment about a keylogger, are the known Java vulnerabilities such that the attacker can monitor keyboard activity. If so, I see why that would be a far more significant vulnerability that this new one.
Ciao, marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 12/08/13 10:36, Marcus Meissner escribió:
After this step a malware could just sniff keypresses, trojan binaries and not bother with weird cryptography exploits. ;)
This is a key idea to understand when dealing with this kind of stuff. This attack requires a man-in-the-middle but a common trojan will never go this route, it has to be efficient and economic to produce, many other ways to steal information exist once the trojan is in :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Cristian Rodríguez -
Greg Freemyer -
Marcus Meissner