Editors Note: the following article is targeted at the common Internet user and attempts to avoid technical jargon as much as possible. Its premise is that administrators and programmers already know the shortcomings of Internet security. This article assumes that the reader has covered the previous article for glossary terms and definitions and does not repeat that material.
To begin with, I want to put you in a frame of mind regarding your security. Simply put, you are fortunate if you avoid ever being attacked through means of your computer. You are less fortunate if you have been attacked, but at least were later informed or otherwise discovered it. In that case you go into damage limitation mode and fix whatever problems have arisen.
But what if you don't realize that you have even been attacked? You cannot 'fix' something that you do not know is wrong. Think of someone using your identity to access information to which they should not have access, and creating accounts in places that you do not know exist, and to which you yourself obviously have no access.
Many people are attacked on the Internet but never realize it. On many occasions, when an institution realizes that customers have been compromised, there are allegations that the attack was kept quiet, and damage likewise repaired silently.
In the previous article, we looked over a range of threats that exist for Internet users. In this article, we are going to delve a bit deeper into how these attacks are mounted. The goal is to help you understand how you are being attacked, so that you can correctly assess your level of security as you transact on the Internet.
The Common Login Page: The Common Security Hole
At the core of our identity management problems is the common login page; its vulnerability has fed a whole generation of hackers. The flaw isn't difficult to understand, either. With usernames and passwords entered either partially or completely, the level of security is weak. Upon successful authentication, the hacker has access to the online facility for the duration of the visit, without hindrance.
This is a key point to understand. A site provides a gateway into its environment, and your username and password details are the key. Once in, there are usually no further identity checks, which means that the only protection to site access - to your email, online banking and so on - is your username and password. In technical speak, we would say that after logging in, session and transaction management are continued until the user logs out, or is otherwise disconnected.
The burning question is why did we (a generation of programmers) ever design and perpetuate a system (the common login box) that we knew to be vulnerable? There are a few reasons: simplicity, complacency and evolution are near the top of the list.
Let's look at the process of attacking systems that depend on login boxes.
Attacking The Login Page
First of all, finding random sites that use login pages isn't difficult. A hacker who wants to get a sampling of educational sites with login pages constructed in ASP (Microsoft's Active Server Pages) would open up a browser with Google and enter the following:
inurl:login filetype:asp inurl:edu
The login page presented is effectively a gateway to an application.
As you enter data in the password box, asterisks appear instead of the characters typed. However, these are just a visual disguise; the password text box actually holds the password as entered. This information is passed to a program or page on the site server where the information is retrieved and tested for validity.
So what can go wrong with that? Try this yourself: Open Google and enter 'keypress recorder' in the search box, and see what comes back.
Each executable program mentioned in the search results is capable of sitting on your PC and recording keystrokes as you type them. So, for example, if one were sitting on my machine and recording my every keystroke, it would record a copy of this article as I write it. Some of them are smart and only record keystrokes in response to password prompts. Some of them are even smarter, and do not show up as running programs on the system, even though they are actually functioning. Another technique is to rename the illicit program as something that looks innocuous. For example, would you worry about "winprint.exe" if you came across it in your Windows directory?
Next, go to your Google page and enter 'screen scraper'. Now what you get is a listing of programs that grab an image of your desktop screen, like when you press the Print Screen button on your keyboard.
Now for the kicker - there are programs out there on the net that will do both of these tasks. Some of them come in the form of Trojan horse and spyware programs. These are downloaded onto your system, usually where you stumble across sites hosting pages where they are embedded - especially porn-related ones - or are perhaps received by email.
If you are infected with such a program, your confidential data will be captured as you enter it. At some time thereafter, your vital information will be appended to an email that reaches the hacker. Alternately, it may be silently 'piped' directly to a purpose-built server that harvests such information for later retrieval by the hacker.
You now know that these programs exist, and hopefully can understand that they are capable of recording and passing on vital information. In that light, it isn't difficult to see why the common logon box is such an easy target. Now think about those sites where you have submitted your credit card details, and where you have agreed to store that data for subsequent and convenient one-click purchasing...
But let's return to the attack on our login page. When the page is submitted, it passes typically with a POST or GET HTTP Request to its action target. Let us decipher some of this jargon.
HTTP stands for Hyper Text Transfer Protocol, and is the method by which pages of information are formed and transmitted across the Internet. A form can be passed in two ways: through a POST request or a GET request. Suffice to say that both are methods through which data is passed from a browser to a site. Each HTTP request can have a response, so when you submit a search for data from Google, the returning page is an HTTP Response.
Now there are two possible ways to have the data reach its intended target. It can either be encrypted using a mechanism such as Secure Sockets Layer (SSL, using a prefix of HTTPS://) or the information can be sent in the clear (HTTP://).
Either way it can be attacked, but to elaborate on how this can occur, we need to walk through a few concepts first.