📄 threat_analysis_min_security.html
字号:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"><html><head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="GENERATOR" content="Mozilla/4.76C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]"></head><body><h3>SLP Security</h3><h3>Introduction</h3> <h3>The SLP Security Problem</h3>The SLP security problem can be divided into three categories: SLPsecurity attacks, security configuration and management problems, and ignoranceof secure SLPv2 usage. The following is an introduction to problemsthat will be examined in more detail later in this document.<p>The obvious SLP security problems are those that are similar to theone that is described by the following example from <a href="broken_link.html">SLPv2Authentication - Is it worth the trouble</a> ):<blockquote><tt>Imagine that in an enterprise environment there is a maliciousor overly curious individual that would like to obtain confidential information. SLP could be exploited to obtain information from software that was otherwisesecured only by virtue of manual configuration. For example,an OpenSource help desk application consisting of "server" and "client"software is SLP enabled because the network administrators got tired ofhelping employees set up the "client" software with location and configurationinformation used to connect with the "server" software.</tt><p><tt>Since the source code is readily available, a sneaky employee makesa few modifications to the server code that allows him to obtain user namesand passwords. He recompiles the source and brings up the "rogue"help desk server. Since the "rogue" help desk server and the realhelp desk server both have similar SLP registerations, it is possible thatclients may connect to the "rogue" server instead of the real one. When the users log in, the "rogue" server saves off a copies of user namesand passwords. The malicious employee can use these user names andpasswords later to impersonate other people.</tt></blockquote>The obvious solution to this and other related SLP security problems isto build security features into the SLP protocol itself. Thisis the approach that is taken by SLPv2 and it is indeed successful in preventingnearly all of the SLP security attacks in a way that requires very littleeffort on the part of user and application developer. However, itplaces a huge security configuration and management burdon on the systemadministrator and makes (application level) interoperability between SLPimplementations difficult if not impossible. In other words, theSLPv2 security specification does a great job at solving most SLP securityproblems from a protocol perspective, but in most applications, it createsa configuration and management nighmare that challenges the fundamentalSLP usability claim"<blockquote><tt>"Using this protocol, computers using the [network] needlittle or no static configuration of network services for network basedapplications." -- RFC 2608 (abstract)</tt></blockquote>SLPv2 uses public key cryptography to generate signatures that ensure integrityof SLP messages. Authenticity of SLP message signaturesis established by the relationship of SPI and keys -- unfortunately thisis a relationship that has to be established manually or by some othertrusted PKI framework. Another unfortunate reality is thatthere are no standards for PKI frameworks to which SLP protocol implementorscan write nor are there any standard for manual configuration. The result is that none of the secure SLPv2 security implementations areinteroperable from a security configuration or management standpoint. With out security configuration and management standards, software developershave a difficult time writing management software and System administratorsare stuck with the prospect of having to manually configure key distibutionand SPI configuration.<p>Finally, very little information is given in RFC 2608 or in RFC 2614(especially) to educates developers of SLP software about the subeltiesof SLP security and how SLP must be used in order to be secure. Itturns out that there many things that developers can do to write softwarethat is resistant to SLP related attacks that do not require use of SLPv2protocol security features. As discussed later in this document,it may be possible for educated developers to write acceptibly secure SLPenabled software that does not require any security configuration or managementoverhead.<h3>Limiting SLP Security Requirements</h3>Most Internet security problems are approached with the assumption thatno one is trustworthy and that no one is trackable or accountable. This is probably not an appropriate approach to SLP security because SLPis not intended for the Internet.<blockquote><tt>SLP is intended to function within networks under cooperative administrative control. Such networks permit a policy to be implemented regarding security, multicast routing and organization of servicesand clients into goups which are not be feasible on the scale of the Internetas a whole. -- RFC 2608 (section 1.1 Applicability Statement)</tt></blockquote>In approaching the SLP security problem, one should continue to assumethat no one is trustworthy, however, it SHOULD NOT be assumed that no oneis accountable or trackable. In fact, in "networks under cooperativeadministrative control" it is very easy track and confront individualsthat corrupt otherwise insecure systems as long as it can be identifiedthat a corruption has been attempted or has occured. Because theycan be held accountable, fear of consequences keep otherwise untrustworthyindividuals in line.<p>SLPv2 security as described by RFC 2608 supplies, at the protocol level, everything that is needed to ensure that service location informationwas sent by a trusted entity (authentication) and that the informationwas not changed in<br>transit (integrity). At the application level, this means thatan application developer (probably using the SLP API) can trust *all* SLPdelivered information. This allows the developer to be morerelaxed about how service specific communication is performed.<p>Blind trust of SLP deliverd information (URLs, etc) is especially significantin common situations where confidential information (username and password)are exchanged with an entity authenticated only by the fact that it was<br>located via secure SLP. For example, LDAP enabled software usesSLP to locate an LDAP directory. If SLP information is secure, theusername and password to establish a connection with the LDAP directorycan be sent with out having to use any other method to establish the identityof LDAP directory. However, with LDAP (and many other protocols) is is now possible to establish the identity of both the "server" and "client"nodes without trusting the service location method. Infact, for any SSL or equivilant transport it is crucial to cyptographicallyestablish the identity of the "other side" in a way that is seperate fromthe URL that was used to initiate the connection. <p>As expressed in <a href="broken_link.html">SLPv2 Security - Is it worththe pain</a> , SLPv2 security does not really do much protect confidentialdata and resources unless the service-specific protocols are secure. Why would it be useful to have a secure location mechanism if protocolbeing use to actually control confidential data and resources can be easillycompromised? If SLP security is not interest toanyone unless they use SLP in conjunction with some other secure protocol. then SLP security is only valuable if it can be used without disruptingthe operation already secure software.<br> <h3>Security by Fear</h3> <p> <p>Under heavy attack, secure software ultimately has one alternative,it can stop working rather than give access to confidental data and resources. Ignoring requests for services turns out to be only alternata<p>Continuing the LDAP example from above, it is possible to write a secureLDAP enabled "client" application that uses "insecure" SLP to discoverthe LDAP server. The client would locate URLs for *all* LDAP servicesusing SLP.<br>The client would try to establish an SSL connection with each of thediscovered LDAP servers until an LDAP server that comes to an LDAP serverthat is trusted. If SLP finds an LDAP servers that is not trustedit should<br>display a warning message (thus helping to track down the rogue ormisconfigured LDAP server). In this example above there is one nochance for security compromise in the LDAP application due to it's useof SLP. There is, however a chance that "suppresion attacks"could burdon the application.<br> <h3>SLP Security Attacks</h3>As mentioned in the previous section, the use of secure service specificprotocols/frameworks in an environment "under cooperative administrativecontrol" greatly reduces the scope of the SLP security problem. Instead of having to ensure that every bit of SLP information is deliveredwith authenticity and integrity, it could be argued that SLP only has toworry about a those portions SLP delivered information that can be subvertedwith out alerting the system administrator. However, since the systemadministrators can't be expected to be constantly vigilant or timely intheir response to alerts, it is also important that SLP enabled softwarebe still be written in a way that does not compromize confidental dataor resources when under attack.<p>Since SLP controlled information is publically available, most SLP securityattacks are calculated to compromize information and resources controlledby service-specific protocols than information that is controlled by SLPitself. There are two categories of SLP attack: impersonation attacks,and disruption attacks. Impersonation attacks involve manipulationof SLP in order trick SLP enabled software into using rogue service. The ultimate goal of impersonation attacks is to obtain confidential information. Disruption attacks involve manipulations of SLP in order to disrupt orhalt normal operation of SLP enabled software with the ultimate goal ofmaking life hard for the system adminstrator.<p>If SLP enabled software uses secure service-specific protocols, impersonationattacks have almost no chance of being successful. SLP related disruptionattacks, on the other hand, have a very good chance of being successful. The following table is a list of disruption attacks that could be directedat SLP enabled software:<br> <table BORDER WIDTH="100%" NOSAVE ><tr NOSAVE><td NOSAVE><b>Attack</b></td><td><b>Description</b></td></tr><tr><td>Unauthorized Directory Agent</td><td>An unauthorized directory agent could be installed on the network withthe intention of sending incorrect information to UAs. A maliciousDA could disrupt the operation of SLP enabled applications by returningunauthorized service URLs, by returning unauthorized attributes, or bysimply not returning any results at all. Since UAs are required touse a DA if it exists, it is possible that it might attach to the unauthorized⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -