Apparently the new Dyer malware is bypassing SSL to swipe bank credentials. I read that it's using "process hooks" to hook the browsers and see the data BEFORE it is encrypted and sent to the bank server (using the keys from the initial SSL handshake). Can someone elaborate as to how this is achieved? and is this at the same threat level of a keylogger capturing your keystrokes or is it more covert and dangerous?
asked Jun 17, 2014 at 6:24
-
Keylogger, virus, malware, it does not matter. If you PC is infected and someone has access to your PC, SSL will not help, as the credentials will be stolen before they are even sent via secure channel.– user43488Commented Jun 17, 2014 at 7:27
-
1Yes I know that but your comment does not, in any way, help with my question. I wanted an explanation on how this is achieved and how covert and undetectable it can be.– Abbas Javan JafariCommented Jun 17, 2014 at 7:39
-
1Abbas, @edvinas.me comment actually shoots straight to the heart of the issue - once you allow the malware to run on your machine, it is no longer your machine. The precise mechanism used to bypass SSL is uninteresting, since there are trivially many possible options. It's like asking "which functions did they use" or "what language did they write it in" - possibly relevant for some niche research, but not really important to your risk model or mitigations.– AviD ♦Commented Jun 17, 2014 at 8:16
-
1Yes I understand the idea put forward by edvinas.me and it's a correct one! but it doesn't help with my question. You are correct about what you said, the technical implementations are uninteresting and personally for me, irrelevant. I was focusing on the idea as to "why is this creating so much hype in security blogs and news posts?", malware and keyloggers were always around and SSL (like you said) cannot help when it's no longer your machine. So what's new about this malware? weren't other malware and keyloggers causing similar issues for some time now? Should I edit my question to clarify?– Abbas Javan JafariCommented Jun 17, 2014 at 8:27
Add a comment
|
1 Answer
When an application "uses SSL", it actually loads a system DLL which implements the protocol. Each process maintains, in a specific zone of its address space, the list of DLL it has already loaded and where (this is under the management of the dynamic linker); a malware that can run on your system with enough local privileges will simply poke into these memory structures so that when the application wants to load the SSL implementation, it is actually redirected to a malware-controlled DLL. The malware will faithfully forward all calls to the true SSL-implementing DLL, but will also keep a copy of the data.
All these manipulations are in RAM and thus leave no permanent trace. Of course, the malware still has to "be there" and it wants to resist reboots, so it will normally leave a hook somewhere, modifying a system DLL or executable so that it is invoked again when the machine reboots.
(Nobody knows why any specific vulnerability or malware suddenly becomes the most important news in a decade and triggers a worldwide panic, while dozens of similar or even more dangerous virus just fly by with nothing more than a collective "meh" from a few specialist. The "heartbleed" case is a good example of a bug going viral for no perceivable reason.)
answered Jun 17, 2014 at 10:56
