Exploit code targets Mac OS X, iTunes, Java, Winzip...
Time for an Evilgrade
A researcher from Argentina has released an exploit package that can install malware on end user machines that run iTunes, Mac OS X, Winzip and a host of other popular software.
Evilgrade is the brainchild of Francisco Amato and works by exploiting weaknesses in the automatic upgrade feature of an affected program or operating system. It works only when a man-in-the-middle attack has first been carried out, but thanks to the domain name system vulnerability that has dominated security coverage ever since researcher Dan Kaminsky sounded the alarm three weeks ago, that's not much of a problem.
The demo here shows just how effective Evilgrade is now that the exploit code for the devastating DNS bug was folded into Metasploit. It shows how the upgrade feature on Sun's ubiquitous Java runtime environment can be targeted to remotely execute arbitrary code on a fully-patched machine.
In addition to iTunes, Mac OS X, Winzip and Java, other programs that Evilgrade can attack include Winamp, Notebook, OpenOffice, Notepad++, Speedbit and the Linkedin Toolbar.
Amato, of Infobyte Computing Security Research, isn't the only researcher who's been thinking about security weaknesses in updating features. Security consultant Derek Callaway of Security Objectives has recently issued advisories warning against serious vulnerabilities in both Lenovo laptops and Cygwin, a tool that creates a Linux-like environment on Windows PCs. Like the exploits carried out by Evilgrade, the attacks Callaway warns of also rely on a man-in-the-middle condition, in which attackers are able to sit in between the victim and a trusted site.
The DNS bug discovered by Kaminsky isn't the only way to create a man-in-the-middle condition. Other attacks involving DNS, ARP and DHCP spoofing can also suffice, and with the recent release of a program called KARMetaSploitt (a combination of Metasploit and KARMA that's included within the latest BackTrack LiveCD), there's yet another menu-driven way to achieve the effect. ®
The bad guy sits between you and the banking site and can relay all communication in both directions. Any authentication exchange can also be relayed. Once you've said OK to the message that warns you that the SSL certificate doesn't match the banking site that you think your using or isn't signed by a trusted 3rd party then your doomed!
If I understand you correctly, and I think I do, an aspect of my idea would be a prearrangement with the authenticating institution, a special password, let's say, using some form business identification as a username. Then only the true site can authenticate in this manner. The response from the authenticator would likewise be associated with the user in the same manner as a challenge question's answer only in reverse.
I think the hole in that solution is that hackers can spoof the whole thing (bank server, authentication server etc.) once they have control of your DNS.
It's a smoke-and-mirrors thing. 99.9% of users would be easily fooled by a fake banking site. You could even set up a proxy site in front of the real banking site, so that the user's transaction completes normally (i.e. not arousing suspicion) while you (the hacker) keep the session open afterwards and plunder the account.
That's why DNS hacking is so dangerous and also why I think the Evilgrade proposal isn't an earth-shattering concept in the realms of computer security. The point is, with control of your DNS a hacker can do *lots* of different things and Francisco Amato just happens to have thought of one of them.