Though I’ll discuss more specific issuesrelating to vulnerability analysis later inthis article, the main point here is thatregular checks must be performed to keepup with this. It’s also important that youhave someone performing this analysiswho can look intelligently at the results tonot only identify the risks, but also ascer-tain whether a particular risk is going toaffect your website, host system or net-work or all three. It is quite easy to obtainfreeware packages to perform the assess-ments (tools such as Nessus, Saint andStealth are all freely available automatedvulnerability scanning tools which can bedownloaded and installed very quickly),but knowing what those tools are doingand knowing how to interpret the resultsof the scans will be a different matter.

For example, the N-Stalker SecurityScanner (also known as Stealth SecurityScanner) will identify weaknesses and vul-nerabilities within your Web server(somewhere in the region of 25 000 vari-ous Web server vulnerabilities arechecked, depending on the type of scanperformed). Though the tool itself is veryeasy to install and run, being GUI-basedwith easy configuration options, the out-put may require further investigation.This tool, also like many others, gives arisk level. Understandably fixing “high”or “serious” risks is going to be a priority,but the low and medium risks should not

be ignored. This is an important processof the analysis because some kind of timeline should accompany the various fix lev-els, for example:

High risks – ImmediateMedium risks – Within a weekLow risks – Within two weeks

It’s unlikely everything will get doneat once, so by applying deadlines to theproblems found even the low level issueswill hopefully be resolved. Again this isa significant factor as they could poten-tially be overlooked when a lot of time isdedicated to fixing the more seriousproblems. Clearly also, the severity of aparticular exploit cannot easily be gen-eralised, and the impacts in particularmay be more serious than “guessed” atby the tool.

The output shown in Figure 1 is a sam-ple report produced from the N-StalkerSecurity Scanner. By clicking on the linkwithin the report, the output will identifywhether the problem actually exists orwhether this was some invalid responsereceived from the Web server by the scan-ning software. In this case it’s fairly easy tocheck whether a vulnerability or unwant-ed file (which may cause a vulnerability)exists. Also, it’s worth noting that not allscanning tools are as user friendly as theexample given above.

A number of security scanners provid-ing very similar services are available bothcommercially and as freeware. Don’t befooled into thinking that by paying themoney you will be buying a completesolution. Whether it’s free or not isn’t asimportant as knowing the limitations of aparticular tool and most importantly,how it fits into the whole, wider vulnera-bility assessment process.

It’s an important part of testing tocheck the results manually from the auto-mated tools as some of the results will befalse positives, i.e., indicating a vulnera-bility when, in fact, one doesn’t exist.Though more time and more expertisewill be required to perform the testingand analysis of the results, time can actu-ally be saved because you’re not runningaround applying solutions to problemswhich don’t exist.

One particular aspect of the vulnera-bility analysis arena is the large andlooming spectre of application testing,i.e, identifying vulnerable code. This isone area where automated scanningtools are not the answer. Whether theanalysis of the code is carried out pre-liveor post live for your environment, it willpay in the long run to have this checked.More often than not, testing is per-formed after the application has beendeveloped so vulnerabilities are pickedup when looking at the live or UserAcceptance Testing phase of the applica-tion development and often little in wayof code review has been done. Codereviews should be part of the applicationdevelopment process, but I won’t go intothat debate here!

Once your application is live, someonecomes along to review your new website.Scanning tools have identified very little,but as the testing team start to look at thesite’s functionality they’ve identified aseries of flaws in the code, there’s little inthe way of regular expressions and no userinput validation on some of the formsand search fields (these are some of thecommon problems I’ve encountered insuch reviews). This could potentiallyopen up a host of problems from cross-site scripting to SQL injection and

17

vulnerability scanning

Vulnerability analysis —what is important andwhat is notPaul Sullivan, Insight Consulting

Identifying the areas of your systems and networks that can be exploited by hack-ers is a major stepping stone in shoring up holes within your defences. The prob-lem with vulnerabilities, apart from the obvious, is that you never know when thenext one’s likely to emerge. Will it affect the operating system platform, the soft-ware or will it be revealed through some poorly written code? It’s analogous to agarden full of weeds, you can up root them, poison them, even re-lay the lawn,yet at some point they’ll be back, you don’t know where, you don’t when, butthere’s a certain amount of inevitability about the whole process.

vulnerability scanning

18

automated scanning tools will not neces-sarily pick up these problems.

Another point here is to ensure you havesomeone, internally or within an externalfirm, who can do this type of review, andto decide how you will fix the problemsthey discover? If there is one flaw in thecode there are likely to be others, so a thor-ough review is required and using toolssuch as Nessus will not find the issues witha loosely secured Web application.

It is also important when consideringtesting that you use experienced individ-uals. Running some of the automatedtools against your hosts could potentiallycause a denial-of-service if the systems inquestion are unpatched or the operatingsystems have not been upgraded. Somelive environments are like this simplybecause once they achieve a working con-figuration, the attitude is “if it worksdon’t change it”. It is vital to know thesystems that are being tested, and letthose who are running the tests knowexactly what you are running and the ver-sion levels.

A lot of these automated assessmenttools will actually look for denial-of-ser-vice attacks and often have an enablingrule within them to activate such testpatterns. If it is something that isrequired and the environment is not livethen the issues are limited, however, ifthe tool identifies a lot of potential DoSvulnerabilities on your live system thenghost your host on to a test machine andthen run the exploits to prove their existence.

There are many companies in the mar-ket today providing these particular ser-vices and many companies who performthe tasks in-house. Both ways are fineproviding the checks are regular and theyare performed by someone with a goodknowledge of the tools they are using andthe techniques involved. It is also veryimportant that you ensure the scanningtools are the latest versions using the lat-est vulnerability databases, because moreand more vulnerabilities constantly cometo the fore and the solutions that are pro-vided by some automated scanning toolsmay become obsolete.Figure 1: Sample Report from N-Stalker Security Scanner

Now, most of us patch when we hearabout such vulnerabilities and feel prettysafe after doing so. However, this time weall patched in vain.

Two weeks after the patch was releasedby Microsoft, the notorious http-equivreleased information about how to circumvent Microsoft's protective measures.

On 20 September 2003, two weeksafter http-equiv published informationabout how to circumvent the previouspatch, no new patch is available. Thiseffectively left ALL users of MicrosoftInternet Explorer vulnerable to two dif-ferent variants of the Object Data vulner-ability allowing any website or email to silently execute arbitrary code on the client system.

No tricks needed for Office flaw

However, this is not the only way tointroduce malicious code on client sys-tems exploiting Microsoft software. On 3September Microsoft issued patches to fixseveral vulnerabilities, including vulnerabilities in Microsoft Office allow-ing malicious office documents to execute arbitrary code on the client system.

Microsoft claimed that the user neededto be tricked into opening a maliciousoffice document. It was soon revealedthough that this could be exploited bywebsites through Internet Explorer becauseof the office helper application allowingwebsites to include office documents.

New RPC DCOM vuln

Any IT staff member, who has notheard about the Blaster virus by nowmust have been offline for just a bit toolong. On 10 September Microsoftreleased yet another patch (MS03-039)to fix another vulnerability in the RPCDCOM service. This vulnerability canbe exploited in the same way as the onedetailed in (MS03-026), which wasexploited by the Blaster worm.

Let us hope that IT administrators andhome users learned a lesson by Blasterand have enhanced their firewall rulesand installed the patch.

Open SSH and Sendmail show they can be vulnerable too

Lately, I've been writing mostly aboutMicrosoft vulnerabilities but this time wehave also seen interesting vulnerabilitiesin core UNIX and Linux services likeSSH and Sendmail.

We regularly hear rumours about anew “root exploit” that has been dis-covered in SSH which is actively beingexploited. Usually, these rumours areuntrue but this time proof of a poten-tial vulnerability surfaced andOpenSSH hastily released a patch.Within 24 hours it was clear that a sim-ilar vulnerability still existed and yetanother patch was released.

19

The Big Picture onBig HolesSSH and Sendmail challenge Microsoft’s top spot for flaws

Thomas Kristensen, CTO, Secunia

Lately we have seen quite a few Microsoft vulnerabilities — the most noteworthybeing the Object Data vulnerability, which Microsoft attempted to fix with thepatches in security bulletin MS03-032. The Object Data vulnerability is extreme-ly easy to exploit – like MS01-020 which is still being exploited by many viruses(e.g. ‘Swen’ currently roaming the Internet). The vulnerability has already been-exploited by a spammer, who wanted to promote his porn site and by a hacker,who compromised an online hotel.

There are many important factors toremember when performing vulnerabil-ity analysis. We have briefly touched onsome of the more crucial points andthese should be taken into considera-tion to get the best out of any analysis.A quick summary is provided below.:

Vulnerability analysis factors1. Regular vulnerability assessments,

both automated and manual (i.e.monthly, quarterly, etc)

2. Re-test after fixes have been made.3. Keep automated scanning tools up to

date.4. Don’t just rely on automated scans,

vulnerabilities may exist within appli-cation code.

5. Ensure that the testing and review ofresults is conducted by an experiencedindividual in this field.

6. Look out for known vulnerabilitiesrelating to the versions of softwarerunning.

7. Check the results thoroughly by

attempting the exploit – sift out the

false/positive results.

8. Unless specified, do not run DoS

exploits.

9. Carry out vulnerability assessments

on the internal network and not just

Internet facing systems.

10.Whether the tools used are

commercial or freeware, both do the

same!

vulnerability analysis