When the first details trickled out about a new attack, dubbed clickjacking by the researchers who found it, the descriptions made me think of the tricks I used to pull during penetration tests ten years ago to get administrator privileges: Tricking the user into issuing a command on an attackers behalf is one of the oldest attack vectors in the book.
Most system administrators didnt know it, but they couldnt be sure what program would run when they entered a command. By naming my malicious program the same as a common utility that I knew a system administrator would run, and strategically placing the program in the right directory, I could get the system administrator to run my malicious code. With this approach you can convert a vulnerability that lets you create a file on the system into full system control.
Before web browsers and even before the graphical user interface, a computers user interface (UI) was a command line. With a command-line UI, the user types a text string into the command shell and the shell performs the operation.
For example, when the user types in
The attack works because most operating systems let users write files to directories and folders that contain executables. For example, in the days of the command-line user, an attacker could embed a malicious file named mail in a TAR archive and hope that the user would extract it to a place the command shell will find it. If the user changed their current working directory to the location of the malicious mail file and then reads their mail, the attacker would own the box.
Clickjacking is a modern twist on the old con. Users need to trust a Web browsers user interface (UI) in order to correctly issue commands to the computer. If the UI is untrusted, then a malicious actor can trick the user into issuing commands on the actors behalf. This problem isn't going away any time soon, but designers can at least up the ante in this new twist on an old cat-and-mouse game.
Imagine an attacker being able to set up a malicious website, or compromising a trusted website, and getting a button to appear that is a actually a button on a banking site or a shopping site but the victim cant actually see the button because it hovers invisibly below the attacker-generated UI. When the victim clicks on the attackers UI he is really clicking on his banks website. He just doesnt know it, because he cant trust what he sees.
Graphical user interfaces (GUIs) have just changed the details of the attack, not the concepts. Instead of creating a malicious file with a particular name and placing it along the search path, an attacker creates an icon that looks like a document file and tricks the user into clicking on it. Instead of opening a file, the user could end up installing bot software or a keylogger.
Operating systems have added features over the years to warn users that they are really executing code when they perform an action through the user interface and when executable code is not to be trusted.
This is only a partial solution. Trusted typically means not installed by the operating systems manufacturer or signed by someone the manufacturer trusts. There are, however, plenty of untrusted executable programs that users install, because many users dont really understand the importance of heeding the operating systems warnings when they are not sure what their computer is doing. A solution in some cases has been to make the operating system or applications more restrictive. For example, Outlook will not allow you to detach an executable file or visual basic script sent to you.
Now, lets enter the world of the modern web browser, where the UI is largely controlled by a remote Web site that is likely not trusted, or could even be trusted but is compromised and sending malicious content. Modern web browsers have replicated the warnings of the operating system user interface to warn the user when he might be executing a file that is downloaded over the Web. The web interface, however, offers many more opportunities for an attacker to trick a user into issuing command on his behalf.
The untrusted Web site user interface is a much more serious security problem than an untrusted command line or untrusted operating system GUI. A user can simply stumble upon an untrusted website whereas for the untrusted command line or GUI, the attacker needs to get a file onto the users system. Moreover, the flexibility in building a Web sites user interface gives the attacker a lot more possible vectors of attack.
Clickjacking isnt going to go away any time soon. Every browser or plug-in that can display a flexible user interface will need to be made more restrictive. These programs shouldnt permit the types of tricks that allow an attacker to fool the user into issuing commands on his behalf.
In the end, browser makers and plug-in developers need to find a way -- even if it inhibits design flexibility -- to let the user trust that what they see is what they will get.