This article aims to highlight the threatsposed by the automatic update processwhen security vulnerabilities are intro-duced into this model, and the possibilityof circumventing network protection tolaunch attacks against the corporate network.

In recent years the acceptance of activi-ties like vulnerability assessment and pen-etration testing within the corporateenterprise has risen significantly. Themedia has helped this growth by publicis-ing the dangers presented to networks byintelligent and aggressive worms thatroam the public domain.

Better configuration of historicallyweak network services and widespreadadoption of good security policy hashelped to secure environments and pro-tect from malicious threats. Even so, in

addition to badly configured networkhosts, risk from vulnerabilities discoveredwithin network services themselves hasproven extremely serious.

Programmatic shortcomings withincommon network services have led toconditions such as stack or heap over-flows. These facilitate the execution ofarbitrary code in the vulnerable process.Security compromises caused by thesebugs let attackers gain interactive shellaccess to a host, to escalate user privilegesto administrator/root levels or causeeffective denial of service to legitimateusers, among other irritations.

Patching or updating operating systems and services to maintain a secure network environment has becomedaily routine for system administrators.In large networks the number of hosts

that require accurate and timely fixescan make the task very difficult to manage.

To make it easier, more and more soft-ware developers include the capability forend-users to update their applicationsautomatically by downloading andinstalling fixes from manufacturerarchives. This technology has become awidely accepted method to acquirepatches and close newly discovered holesquickly.

But do we put enough thought intowhere the patch comes from? The wholeautomatic update process relies on usersand administrators trusting the vendor toprovide the solutions needed, and accept-ing that the patch has indeed come fromthe right source. Combine these trustconcerns with the use of “blind updat-ing”, i.e. downloading and updatingproducts without any interaction withthe administrator or user, and the potential for misuse becomes even moreplausible.

What is automatic update? Updating software is the process of pro-viding product enhancements, functionalcurrency or post-release supplements tocomputer software. With regards to secu-rity issues, the vendor or developer releas-es patches to fix discovered vulnerabilitiesthat affect the integrity or functions of aproduct.

model. The idea is to allow providers tosupply fixed bandwidth “circuits” to acustomer and to ensure that the properamount of bandwidth is always available.For example, a customer may have a fixed1Mb/s connection. The QoS capability in802.16 guarantees the customer will have1Mb/s regardless of how much data othercustomers are using.

802.16 also supports a dynamic modelwhere a customer can transmit bursts ofdata a higher bandwidth, depending onhow much bandwidth is available.

The 802.16 QoS mechanism is based onthe DOCSIS QoS mechanism. Again, theprotocol’s designers were attempting to ease

the creation and management of infrastruc-ture. QoS parameters have the ability to becontrolled from either the subscriber sideor the provider side. However the providerhas the ability to disable or ignore the sub-scribers’ requests for changes to QoS.

Faster supplyThe protocol overcomes the problems ofpushing 802.11 into a metropolitanarchitecture. It provides the core servicesexpected by a carrier when building a datanetwork. 802.16 may also cut the time tosupply high speed data circuits fromweeks (in the case of land lines) to hours.

But the current security mechanisms

are far from perfect. Even though an802.16 network does not resemble an802.11 network, the security failings ofthe two are very similar. Much as802.11i set a higher bar for WLAN secu-rity, the draft 802.16e standard willaddress the failings of the original802.16 specification.

Even so, the utility of the protocol willlikely overcome present concerns aboutthe security failings and lead to wideadoption over the next few years.

About the authorBruce Potter is currently a senior securityconsultant at Booz Allen Hamilton.

5

automatic updates

System administrators and programmers are finally hearing the message IT secu-rity professionals have been sending for years—automatic software updates canintroduce nasty code that cripples your environment.

Automatic update risks:can patching let a hacker in?Kevin Dunn, senior security consultant, NGSSoftware

Automatic update, as the name sug-gests, provides a way to do this with min-imal administrative overhead. In general,products can be configured to activelyseek new updates from vendor resourceson the Internet. These updates are oftendownloaded without notifying the systemadministrator, and in some cases may alsoinstall seamlessly within a system. Thebenefits of this process become obvious inlarge network environments, which areoften maintained by minimal supportstaff.

The necessary chore of checking manu-ally for software updates for every operat-ing system and product used in anenterprise is extremely difficult to man-age. Simply put, automatic softwareupdates allow a network pr systemsadministrator to maintain a good level ofsecurity patches, protecting against classicand emerging attacks from hackers orworms, without the need for time-con-suming manual administration.

Insecurities within automaticupdate systems In many implementations of automaticsoftware update there is a system of trustbased upon arbitrary conditions.Essentially, users or administrators needassurance that the resources provided by a vendor have indeed come from thatvendor.

The potential for misuse of this trustexists because generally it takes very littleto convince a user of legitimacy. Whenchecks are automatic it can be trivial tofalsify conditions and spoof identities.Most software update systems use a simi-lar procedure, namely searching for and

accepting an update file from theInternet, which it then downloads andinstalls onto the host system.

Updating software in this way is a dailytask for a system administrator. So it iscommon for network protection, such ascorporate firewalls, to permit update traf-fic, both inbound and outbound, to aninternal private network. Most updatesystems will use HTTP(S) to negotiatethe automatic update process or they willreplicate the proxy settings specified in auser’s browser. But they may also holdopen further ports at the firewall to allowfor a successful exchange.

Any process that can tunnel through acompany’s boundary protection shouldbe managed and monitored closely.However, many system administratorsdon’t do this for automatic softwareupdates; they place supreme faith that theautomated update process is watertight.

Although safeguards are built into theupdate processes used by major softwareproducts such as operating systems, theyare seldom exhaustive. The problem isoften worse with smaller applications orlegacy software products; they may notprovide any security checks for theirupdate processes.

Any compromise of a software updatemethodology may result in serious dam-age to a host or network. And while theeffect will be immediately obvious, thepenetration method may go undiscoveredfor a long time.

Methods of exploitation Vulnerabilities within the software updateprocess will vary depending upon themethods used by a particular system. In

general, these include the way in which adeveloper’s update server is identified, themutual authentication between host andupdate server, and the integrity of theupdate payload.

IdentificationWhen a software product automaticallychecks for the latest update, it needs to know how to identify thedeveloper/vendor update server. Themost common method for this is tohard-code the DNS name of the updateserver into the software product. Thuswhenever a system administratorrequests an update or the software beginsa periodic check, all data is requestedfrom the same archive.

Domain Name System or DNS is themethod used to map easy-to-remembernames to a host’s actual IP address. DNSallows users to request a web site bydomain name rather than by the IPaddress.

DNS is not infallible. It is possible foran attacker to spoof DNS responses orattack DNS servers directly to map sitenames to a different IP address. Anattacker on the same local network as asystem who requests an update can use acombination of ARP spoofing, packetredirection and DNS spoofing to force asystem to request product updates from amalicious server rather than the genuinehost.

Security-breaking tools that simplifythis complex process are available for freedownload.

To gain the same form of misrepresen-tation from an external point to a localnetwork will generally require an attackon a DNS name server itself. Thisrequires vulnerability within DNS serversoftware, such as BIND. BIND is notori-ously and historically problematic. If anattacker can establish the company publicDNS servers, which should be trivialusing passive information gathering tech-niques, then an attempt to poison theDNS cache of that server or others maybe possible. Over one third of theInternet’s DNS servers may be vulnerableto such attacks, judging from the manypublished accounts.

6

automatic updates

Figure 1 Software update tunneling through firewall

AuthenticationTo mitigate the risks posed by DNS issuesit is necessary to add a level of authentica-tion to the update process. Poorlydesigned software update systems do notuse authentication. They rely upon com-municating with any host that respondsto a lookup of the correct DNS name.

This is obviously a major area of insecu-rity, but the authentication methods com-monly used within software update arethemselves not without security issues.The use of arbitrary constants such aslicensing details or hard-coded credentialscan be easily discovered, modified andreused. This may be done by obtainingthe software and reverse engineeringdetails from the source code. This is madeeven easier with open source applications.Or it may be done by analyzing theupdate process from the same local net-work. If communication between a hostand the update server is conducted inclear text, it is trivial to discover authenti-cation details passed during this process.

Even when the update process happensvia encrypted channels such as SecureSocket Layer (SSL), there may still besecurity vulnerabilities. For all securetransmissions, it is essential that the secu-rity of the end-points is guaranteed.Where verification of security certificateshas been incomplete, it allows a man-in-the-middle attack. This effectively rendersthe encryption useless and allows the dis-covery of update credentials.

Data integrity It should be clear that, in a poorly securedconfiguration, it is easy to impersonatetrusted update resources and forge

authentication methods. The contents ofthe update payload may also be vulnera-ble to subversion if there are inadequatechecks.

In an insecure update system, the hostsystem that asks for available updates maysimply check an arbitrary file on theupdate server to establish if new patchesare available. If they are, the host willdownload and execute the specified filefrom the update server.

Under normal working conditions anexecutable file will install the mostrecent software update. If the system hasalready been fooled into accepting a filefrom a fake update server, simply execut-ing the file without checking the integri-ty of its content may compromise yoursecurity.

Attack payloads & scenarios Consider a fictional software updateprocess that contains the following vulnerabilities:• Uses DNS to locate vendor update

server.• Poor or no authentication between

update server and hosts.• Badly implemented encryption solu-

tions that can be circumvented.• No integrity checking for update

payload.• Update payload auto-executes upon

download.• Update system tunnels through

corporate network firewall.Readers may believe that such a poorlyimplemented automatic update systemwould not exist in real life. But they fea-ture in cases discovered during securityassessments and research.

An important question is whether everyapplication used within the network beenassessed for these flaws where they useautomatic update. It would be foolish toassume that this is the case, even of prod-ucts from large and experienced softwarevendors.

A malicious attacker could force allhosts asking for updates from a systemwith these vulnerabilities to downloadand execute a bogus file with a maliciouspayload. The consequences of this willvary greatly depending upon the payloadtype and the network configuration.However some worst cases could be:• Installation of backdoor software to

facilitate future access to the compromised host.

• Viruses or other destructive malwarethat destroy vital components or affectthe integrity of user data.

• Self-replicating worms, which may ormay not contain a malicious payload.

• Distributed denial-of-service scriptsthat control network hosts and usethem to launch further attacks againstother targets.

These kinds of attack payload are noth-ing new. Many perimeter defence systemsare good enough to detect and preventsuch vectors when launched directlyagainst a network.

However, if a product update system isa conduit for delivery of such attacks, itprobably bypasses normal filtering andfacilitates disruption at the very heart ofthe network. In the case of worms, deliv-ering a payload into a corporate networknot only ravages the primary environ-ment but also probably allows the wormto spread to interconnected partners andbeyond.

Automatic updates the rightwayNow that we know the possible threatsand the damage we can turn to loweringthe risks they pose. The use of DNS,although vulnerable to compromise, isstill valid if used with other securitymechanisms.

First, use a properly designed mutualauthentication process. Rather allow a

7

automatic updates

Figure 2 Intercepting update authentication credentials

system administrator to specify theauthentication credentials for the updateserver than rely on arbitrary details hardcoded into the product. This wouldgreatly improve the security of initialnegotiations.

Second, to prevent eavesdropping ofthis authentication, design and use anencryption model. Test it thoroughly toensure that simple initialisation weak-nesses cannot compromise the integrityof the encryption tunnel.

Finally, validate the data integrity ofthe update payload to ensure that it isexactly as the vendor/developer intended.It is common to use a PKI-based digitalsignature to sign the files available fordownload. This would prove that the fileshave indeed come from the right devel-opers and have not been modified duringtransit. Considering the relative protec-tion provided by a well-implementedPKI solution, does one need more securi-ty? Yes. A multi-tiered approach alwaysprovides an extra level of protection incase any component fails.

In addition to upgrading security sur-rounding the update process, firms

should also change their administrativeprocedures. Unattended download andinstallation of patches is convenient andrequires no interaction with the user oradministrator, but it is not secure. A bet-ter procedure is to download and testsoftware updates offline before deployingit to the rest of the network. This willhighlight problems with the patch beforeit can damage anything.

This raises the administrative over-heads and reduces the benefits of usingautomatic updates, and it may be diffi-cult to do with some software. But thelack of disruption more than repays theextra care.

ConclusionsViruses, worms and other attacks havemade it essential to patch vulnerable software and systems. Automatic updatesand installations reduce the administra-tive overhead of doing this, but theprocess itself is often open to abuse.Designing the update process with securi-ty in mind and modifying the humanprocedures associated with applyingpatches, greatly reduces the risk of such

an attack. Until these threaten enterprisesand home users alike.

About the authorKevin Dunn is a senior security consultantfor NGSSoftware. After working as a soft-ware development engineer for the Ministryof Defence, he transferred to a new vulnera-bility research and analysis department toconduct penetration testing against militaryIT systems. Since joining NGSSoftware, hehas been involved with testing across manydifferent environments for many clients. Hehas also applied his specialist knowledge ofWeb applications, back-end database sys-tems and embedded network infrastructurein designing and building training coursesfor NGS.

Whilst this capability and flexibility isgenerally welcomed, consideration mustbe given to the extension in the risk pro-file that this creates to a business.Traditionally, organizations used to offeroperating system-heavy, security-ensuredlaptops that conformed to traditionalworktop security principals. PDAs usecut-down operating systems to offer simi-lar working capabilities and tend to havea somewhat reduced provision of security

functions. It is a considerable concernthat these devices may not have the appli-cation strength and robustness to ensurethat the confidentially, availability andintegrity of the information they processand manage is maintained.

In this article we will investigate thepotential pitfalls and issues that sur-round the PDA. We will also discuss thetechniques available to mitigate theserisks to an acceptable level and to there-

by establish the PDA as a secure businesstool.

Categories of riskIn order to get to grips with potentialmitigation strategies, it is essential tounderstand the risks you face. One of theeasiest ways to accomplish this is to cate-gorise risks into groups. A consolidatedapproach can then be undertaken by asso-ciating individual risks within a singlemitigation strategy.

Common risks associated with PDAsinclude unauthorized access to data andapplications, illegal interception or “tap-ping” of information in transit, unautho-rized retrieval of stored data from thedevice, potential costs of replacement fol-lowing loss or theft of the device, effectivedevice management, and staff misuse.

For almost any type of PDA, these risksgenerally fit four categories. These areauthentication, wireless communication

pda security

8

PDA security concerns Andrew Miller, Insight Consulting

Personal digital assistants (PDAs) are now commonplace in every type of busi-ness. They extend the central computing power of an organization to the roamingworker within the office environment and in the wider world. The delivery ofmultiple connectivity methods such as wireless or return-to-base technologies hasenabled a much expanded roaming computing ability.

Automatic updates reduceadministration but theprocess is open to abuse