Phishing (from password-harvesting fish-ing) is the capture of sensitive informa-tion, such as a password and otherpersonal information, from a victim bymasquerading as someone trustworthy.In practical terms, phishing usuallyinvolves the establishment of a fake website, constructed to look the same as thegenuine one, to which the attacker thentries to lure genuine users to harvest theirlog-in details.

Phishing is a modern variant of theolder family of attacks where you wouldwrite a program to display a copy of a sys-tem log-in screen that is then left running(usually in the author’s experience in aschool or university computer lab). Thenext user logs on, the program copies theirdetails to a file and then displays some sortof error message. Or, if the writer has beenreally clever, it exits neatly, passes the cre-dentials into the genuine log-in programand logs the user in anyway.

For this reason, in this article we’ll alsocover the strongly related issue of Trojansoftware designed specifically to capturepasswords as a user enters them into yourwebsite.

The problem with phishing is that itcan be totally transparent to the genuinesystem. Moreover, it is a threat to endusers, either through their browser or as aresult of the above mentioned Trojaninstalled on their system, rather than theorganisation that is the model for the disguised phisher.

Of course, the problem is that irrespective of how secure your web-site is, you potentially have millions ofusers (or customers) with little or nosecurity on their systems and scantknowledge of the threats they face.However, there are things you can do to reduce the risk of these types ofattacks and, in the interests of reducingfraud and for your own and your

customers’ sake, you should at least consider implementing some of them. I’ll begin with a bit of threatassessment.

Phishing - the threat The actual threat we are trying to addressis not really phishing, but unauthorizedaccess or compromise of authenticationcredentials. In these attacks, especiallywithin the fairly broad net we have castfor this article, the attack is mounted bycapturing the username, password andother user credentials.

Consider all the ways that this could bedone: interception of details over the net-work; shoulder surfing; accessing creden-tials directly on the systems itself; pooruse of cookies; establishment of a fakewebsite (phishing); attack on users via aTrojan “keystroke sniffer”; persuadingusers to disclose their credentials, toname but some.

Conventional wisdom Of the above list, the first few types ofattack are fairly well known, fairly wellunderstood and, in general, fairly welldefended against. Most organizationsnow accept usernames and passwordsover the Web using Secure Socket Layer(SSL) to protect information in transitbetween the browser and server.However, it is probably worth repeatingsome standard advice for the use of SSL:

workstations from a central managementstation. Further, Checkpoint providessecurity services for instant messaging,another application that is open to abuse.

Future directionsDecentralization will continue. Users arebecoming more interconnected throughnew networking and application tech-nologies. The practicality of single pointsecurity becomes less feasible each day.Next generation enterprise architectureswill have to take this into account to pro-tect assets properly.

As far as the enterprise is concerned,decentralization can be a transformation-al force. For instance, the US Departmentof Defense recognizes that if users havethe ability to share data in a more ad-hocmanner, warfighters can perform better.As a result, the idea of “power to the edge”has changed the way DoD is building itsenterprise. Its next generation enterprisearchitecture, the Global InformationGrid, leverages decentralized data accessas a strategic advantage.

Further, the architecture addresses next generation security mechanisms

that permeate the enterprise. Ratherthan central protection, the DoD is creating systems that can defend them-selves and facilitate secure informationsharing.

The US DoD is only one of manyenterprises dealing with decentralization.In the coming years, there will be moreproducts to help companies deal with thisnew architecture. In the meantime, sys-tem architects and administrators mustmake do with tools and systems designedfor more conventional networks to securean increasingly edgeless world.

5

phishing

Piers Wilson, senior consultant, Insight Consulting

One of the latest family of attacks mounted against Web-based systems, usually inthe financial sector, is that of “phishing”. The threat they pose is serious, not onlyto your organisation but to your clients.

Tips to stop your users from being phished

• Ensure that the appropriate strengthsof encryption (cipher suites are used).

• Ensure that information is not cachedat the client end.

• If possible, use hardware securitymodules (HSM) for both key storageand faster crypto processing (keysstored on Web servers themselves can be at risk from some types ofattack).

• Be aware that if you do use SSL, yournetwork-based IDS systems might notbe able to detect all attacks (someWeb-based attacks will be encryptedand hidden by the SSL itself )Consider terminating SSL sessions ata proxy server layer in front of theWeb server(s).

“Shoulder surfing” is another familiarattack type; defences against it are incommon use. We want to avoid makingit too easy to see the passwords typed in(e.g. for someone sitting behind, or nextto, a genuine user at an Internet café orautomated teller machine). Some tipsare:

• Ensure the password is blanked orasterisked on the screen.

• Don’t make log-in processes too easilyvisible (i.e. use normal sized text fonts,not huge readable input boxes forusernames).

• Make users/customers aware of theneed to avoid letting people see whatthey type at a keyboard.

Usernames and passwords (or other cre-dentials) are, of course, potentially at riskon the servers or systems themselves. SSLprotects data only in transit. Oncereceived by the application, the authenti-cation data is often stored either unpro-tected in a database or within someauthentication mechanism such as adirectory. It should go without saying thatyou need to:

• Make sure that passwords are notstored unprotected (i.e. are hashed orencrypted).

• Prevent access to the usernames andpassword information, so ensure yourapplication is not vulnerable to appli-cation weaknesses such as SQL injec-tion attacks that might compromisethis data.

• Make sure Web server/applicationsconnections to databases are controlled

and do not use a high privilege and/orunsecured account.

• Use stored procedures to perform vali-dation (and other databaseaccesses/queries), rather than doing itwithin the ASP code.

• Ensure directories or other authenti-cation solutions are protected.

• Be careful how cookies are used. It isimportant to avoid storing credentialsor other information useful to anattacker. Also, if you allow users to“Stay logged in from this computer”,make them aware that they shouldnot to do this on a public or sharedsystem.

The management of authenticated ses-sions is a subject in its own right andextends beyond cookies into the wholeprocess of keeping a valid state through-out an inherently stateless browser session.

Now on to phishing. Having appliedthe standard advice above, is there any-thing we can really do to stop peopleestablishing a fake website and luring ourusers to it? Can we take any steps to avoidthe capture of passwords on users’ ownhome systems? Is there a way to stop usersbeing fooled into disclosing their pass-words (e.g. via email)?

There is no silver bullet to kill thesethreats, but there are a number of thingsthat we can do to reduce the likelihoodand impact of these attacks. We’lldescribe the ones that we feel are mostimportant or useful below.

Getting more from your passwordsThere are a number of ways you canextend the traditional username/passwordprocess to make life harder for phisher-men. These involve ways to emulate one-time passwords or provide simplechallenge-response mechanisms.

Multiple credentials The easiest way stymie phishing attacks isto have a number of different passwordsor phrases that users must supply. This isoften done by using a password or PIN

6

phishing

Figure 1

Username wilson

PIN/Password password

Place of birth Mytown

Figure 2

Username wilson

PIN/Password password

Enter the 5th character ofyour memorable word F

Enter the 8th character ofyour memorable word K

they always give, along with a separatedata item chosen from a list of perhapsfour possible questions and answers (typi-cally mother’s maiden name, place ofbirth, memorable date, memorable per-son, etc). (See Figure 1. Note italic textwould be concealed and the bold promptswould change at each log-in.)

This means that the informationpotentially changes every time, althoughthere are only a small number of poss-ible values. It would defeat someone who happened to see a single log-in andalso would defend against the storing ofpasswords in the browser because thesecond password is different at each log-in.

Chosen charactersThe next stage is to take a password or

secret word and get the user to select asubset of characters from it. This is often used in conjunction with a fixed PIN or password. For example,given an eight-character secondary pass-word you then ask the user for the charac-ters at positions x and y as shown inFigure 2.

This makes it much harder to interceptor overlook credentials. But it is reallyonly a variant of a challenge-responsemechanism, albeit one that is simpleenough for a human to use.

There is a way of working out howmany exchanges you’d have to monitor torecover the whole word. An attackermight be able to guess it having seensome of the letters (eg. P A _ S W _ _ D)or be unlucky and see the same letter anumber of times.

Non-keyboard inputOf course neither of the above will pro-

tect against a hardware or software key-stroke sniffer. These are either a tinydevice that connects between the keyboard cable and the socket on the PC,or (much more commonly) a Trojan program that logs key strokes. One solu-tion, used by at least one bank, is to force the input of the chosen charactersusing a pull-down menu, rather than asingle character text box. They even

precede the pull-down options (i.e. the letters) with a space to prevent users shortcutting the pull-down processwith the actual key press, as shown inFigure 3.

This way the user will never enter thepassword as keystrokes but by mousemovements, which are much harder, ifnot impossible, to intercept from theclient system.

Graphical promptsSomewhere in the technological middleof these methods there is also a way that makes the user repeat a graphic astext. This is typically used when register-ing for a system; a mechanism enforcesuniqueness of the authenticationexchange and prevents interceptionwhen the accounts are set up. Graphicalinformation is slightly harder to inter-cept and replay than text. And becausethe graphical challenge is different every time, this ensures that no authen-tication processes are repeated. (SeeFigure 4.)

Site processes So far we have talked about ways to con-struct an application log-in process toreduce the opportunity for authenticationcompromise. We have also highlightedother controls that should be in place,such as database, host and network secu-rity. There are several practices andprocesses that can also help reduce therisk from this family of threats.

Registration of similar domain namesCyber squatting is nothing new, but theattack used to be that someone wouldregister the name and then try and sell itback to you. This has declined now as aresult of some fairly high profile lawsuitswhere the cybersquatters lost. The phish-ing threat, in its purest form, relates to theability of anyone to create a Web presence that, to a casual observer, isindistinguishable from a genuine site.Copying the HTML, images and lookand feel is easy; your browser downloadsall the necessary data every time a page isretrieved. If an attacker can then upload

7

phishing

Figure 3

Username wilson

PIN/Password password

Enter the 5th character ofyour memorable word

Enter the 8th character ofyour memorable word

Figure 4

Username wilson

PIN/Password password

HelpEnter the word above exactly as it appears Help

F

K

that content to a similar sounding URL,they are very close to welcoming theirfirst unsuspecting victim.

There is a risk threshold, of course:where do you draw the line? Do you reg-ister just the .com and .co.uk URL vari-ants, or some of the more exotic suffixesas well? Do you register hyphenated ver-sions, e.g. my-bank.co.uk as well asmybank.co.uk? Clearly, you could do thisad infinitum with various URL combina-tions. However, with the decreasing costof domain name registrations (.co.uk suf-fixes can be picked up for as little as £10)it is a cheap countermeasure. You also getthe side benefit that a legitimate customerhas an easier time finding your website, asvirtually every combination of letters inthe URL will work.

User awarenessOne of the biggest problems is that manyphishing attacks use social engineering.Certainly some ISPs have suffered fromattacks that abuse our trust in the tech-nology. For example, a customer willreceive an email that claims that there is aproblem with the accounts database andthat the organization needs the usernameand password to check whether they have

been affected or to repair their account.These types of attacks work, not justbecause users are easily fooled, butbecause the attackers are able to appeargenuine. They trade on the trust or disci-pline many people have dealing withonline trades, Internet access and com-puters in general. However, the solutionis education, education, education. It isimperative that users and customers knowthat they must never, under any circum-stances, disclose their passwords or cre-dentials, and why this is so important.

Organisations may even need to back thisup with limitations on their liability inthe same way that banks, retailer and oth-ers cover themselves against damages thatarise from the disclosure of ATM PINs tounauthorized people.

Raising this awareness of a potentiallylarge and diverse population can be diffi-cult logistically. If you are training staff,you can achieve this face to face, or per-haps put them through a computer-basedtraining (CBT) presentation on securitypractices. With a user base or customerpopulation running into the thousands ormillions, and because you may not wantto erect hurdles that might put off casualbrowsers or first time purchasers, theproblem is far harder. In such a case, secu-rity awareness must be to the point. Usesimple clear phrases like

“Never under any circumstance give outyour password to anyone. No Mybank.co.ukstaff will ever ask you for your password.Ever.”

or

“Protect your password, keep it secret. Anytransactions made against your accountusing your password will be charged to yourbill. Avoid fraud, protect yourself!”

These nostrums can, of course, be asfriendly or as legalistic as you like. Butyou do still need to take account of con-sumers’ basic rights, for example, the second notice above is probably arguablein court, despite your warning). Couplethis awareness with (published) limita-tions on your liability and you have gonesome way not only to protect your orga-nization, but also your customers andclients.

Note that if you intend to limit yourliability, you need to be prepared todefend your position. This means havingadequate transaction logging, so that ifyour system is abused in this way, you canclearly prove that the false transactionsdid occur, along with details about whereit originated.

Be aware, too, that in large scaleattacks (the kind that make the evening

news) you may also need to consider the publicity issues of taking a harderline on the losses brought about by the ignorance or gullibility of your users.

Reducing the phishing riskEssentially, organizations must defineclear and firm practices for communica-tions between the site (be it a bank,retail, or any other type of business) andthe user population. Once these princi-ples are set, the organization must publi-cise and repeat them as often asappropriate, perhaps especially duringan attack. Consider making this yourpolicy:

We will never send an email

to a user with a link that

allows the user to click to

our site; the URL must

always be typed in directly.

You could even use your registrationprocess to place a bookmark or desktopicon on a user’s system. But this mightnot be possible if their local settings donot permit it, and there is a risk an attack-er could divert this mechanism to a spoofor phishing site.

More proactive, positive stepsThere are many more proactive things

concerned companies can consider. Itmay be prudent to set up dummyaccounts with valid email addresses linkedto your security staff. If a phishing attackis launched against you, there is a chance(but not a certainty) that someone in theteam will get an early warning throughbeing invited to participate in whateverscam is on offer.

Another thing to consider is to providesecurity facilities for the user end of yoursystems. One UK bank offered a limitednumber of free copies of an InternetSecurity suite to its users. This was aworthwhile initiative and, althoughclearly it didn’t cover their entire userbase, it did at least give the users some-thing tangible and useful and raisedusers’ awareness.

phishing

8

By domain name registrations as a cheap

countermeasure

It is relatively easy to spot a maliciousattacker (or attackers) prowling aroundyour systems because of symptoms like these, but many successful incur-sions go unmarked and unresolved. Thisis because many real world attacks are covert, and can be exceptionally difficult to identify and parry. This arti-cle discusses the commonly spotted

blundering attacker, as well as ways to detect and deter his or her stealthiercolleagues.

Infrastructure perimeter defences are atrusted and valued resource for often-overstretched system administrative staff.Corporate firewalls and intrusion detec-tion systems (IDSs) will often detect andprevent casual attacks, as well as some

more sophisticated attempts at systemincursion. Casual attacks can be definedas invasive attacks that are easily detectedinfrastructure level threats. Examplesinclude input validation attacks or portscanning activity.

As has been proven often before, fire-walls and IDSs, although valuable, arenot infallible. In recent months browserlevel threats have proved a significantrisk to many enterprises. The recentflaws in Internet Explorer (as exploitedby Scob/Download.Ject) have shownthat the wrong browser can expose the corporation, despite perimeterdefence of a corporate firewall withactive anti-virus software, if end-usersvisit the wrong site, which may be per-fectly legitimate at all but the injectedcode level.

This may not be possible if you have millions of customers, but there isalways a possibility of making a deal with an application vendor or anInternet security company that allowsyou to offer the software (or a cut downversion) to all your customers at areduced cost. To boost take-up of suchan offer you might consider modifyingyour liability clauses for those users whotake up the offer.

You might provide the security func-tion as part of the website itself; there isat least one anti-virus vendor who letsanyone browse to its website to scan theirlocal system without having to downloadand install a piece of software (the appli-cation runs from inside a browser win-dow). Organizations at high risk couldprovide links to services like this or, commercial arrangements notwithstand-ing, offer equivalent functionality within their own site. (The softwarecompany mentioned above might evenconsider letting you re-badge its prod-uct—no harm in asking). A service likethis gives the organization a high degreeof control over the minimum levels of security at the client end.Through your site you could log when agiven user last ran a security check, and if

a new Trojan had emerged in the mean-time, suggest (or force) them to runanother.

Detecting the results of phishingattacksWhat actually happens when users havetheir identities compromised in a phish-ing attack or otherwise? Typically theattackers will try to access a number ofaccounts to change details, buy stuff,transfer money, etc. The importantpoint is that normally each user will con-nect from a different IP address. As such,in the access logs (if you collect them)you would see:

In the phishing scenario described youwill instead see:

There is clearly a pattern here; manyusers connecting from the same system

could well be evidence of suspiciousbehaviour. Detecting this pattern may notstop the theft of credentials, but it mightallow you to at least detect their subse-quent use.

Final thoughtsThis article offers many suggestions.Some are conventional good web securitypractice and so nothing new, others areinnovations taken from various sitesaround the Internet.

Whatever controls you feel are effective for your own systems, under-stand that most users will continue to use the same username and passwordfor every web site they visit, sometimeseven if they are compromised. Often the username is the email address andthe password is their easily-guessed standard web password. This means that even if you protect your systemsagainst phishing attacks, if some othercompany does not, then the credentialscaptured in a phishing attack againstthem could still be used in an attackagainst you.

About the authorPiers Wilson is a senior consultant withInsight Consulting.

9

detecting attacks

IP address 1 user name 1

IP address 2 user name 2

IP address 3 user name 3

IP address 1 user name 1

IP address 1 user name 2

IP address 1 user name 3

Ghosts in the machineMichael Kemp, technical author, NGS Software

A successful incursion by a malicious attacker can often resemble a haunting by apoltergeist. System “noise” levels rise, strange messages appear, things movearound mysteriously or even disappear entirely, and the victim (or system admin-istrator) knows neither what is happening nor why.