Subverting Protocols

I l @ ve RuBoard

Subverting Protocols

Computer protocols are well-documented to help with implementing them on differing platforms. These implementations are done by many people at many locations with differing skill levels. Some are implemented by students and others by hardware vendors . Some receive careful review while others have limited support. It is not surprising that the quality of implementations varies significantly.

Known Vulnerabilities

Most successful attacks utilize known vulnerabilities. New exploits are continuously being discovered . They are documented and shared in the hacker community. They are addressed and repaired, but the patches are often not implemented on systems, so they remain vulnerable after the problem should no longer be a problem.

The National Infrastructure Protection Center released a summary of software vulnerabilities identified between December 12, 2000, and December 14, 2001. This 84-page report lists over 1200 exploits. Some of the exploits listed are not widely available on the Internet, but the potential vulnerability has been identified as a viable method of attack. ^[51]

^[51] "2001 Year End Summary," National Infrastructure Protection Center CyberNotes , Issue 2001-26, 31 December 2001.

Initially Unsecure

Many systems are shipped with security features turned off. This will often simplify the administration of the system and reduce the number of help desk calls. However, many administrators will be unaware that they need to do anything after the system is installed. The security implications are often not documented and the process of enabling the security features are not well-documented or easy to find.

3Com issued a security advisory stating that customers should immediately change the SNMP community string from the default to a proprietary and confidential identifier known only to authorized network management staff. This was due to the fact that the administrative password was available through a specific proprietary MIB variable when accessed through the read/write SNMP community string.

The advisory was issued in response to the widespread distribution of special logins intended for service and recovery procedures issued only by 3Com's Customer Service Organization under conditions of extreme emergency, such as in the event of a customer's losing passwords. Due to this disclosure, some 3Com switching products were vulnerable to security breaches caused by unauthorized access via special logins.

Customers were urged to log in to their switches and proceed to change the password via the appropriate password parameter to prevent unauthorized access to the accounts. ^[52]

^[52] "I-052: 3Com CoreBuilder and SuperStack II LAN Vulnerabilities," U.S. Department of Energy, Computer Incident Advisory Capabilities Advisory , 20 May 1998.

Improperly Configured

Improper security configurations are responsible for a great number of system compromises. There are many reasons for improper configurations, including incorrect or incomplete documentation and under trained or nonexistent administration.

Even automated administration tools have been known to improperly or inadequately secure an environment.

Interactions between systems can lead to improper security configurations. Not all combinations or interactions are tested . Installing or configuring one system may alter the configuration file which is used by both systems.

Services Which Are No Longer Used

There are many protocols that are no longer in widespread use that are still installed on systems for compatibility. Many of these obsolete protocols predate any level of concerns of security. They may have been designed when direct connected or point-to-point dial-up access was the only available network. Many of these old protocols were migrated to LANs, but were not secured since they were rapidly replaced by newer protocols.

Many computer vendors started with proprietary operating systems. These systems expanded into networking before standards were available. DEC created DECnet , Apollo had Apollo Token Ring (ATR), HP had its network services (NS), and IBM created a number of protocols. As each of these and other vendors moved into open systems, they had to implement the proprietary protocols on their open systems to allow connectivity. Many of these protocols are now obsolete but still exist in the versions of the UNIX systems from these vendors and are often installed and configured by default. Many of these proprietary protocols granted greater permissions with less authentication than current protocols.

Many of these protocols were proprietary and are not widely known. The programs which support the protocols are not part of the normal network start-up routines. An administrator will have seen the process running on all the machines of this type and not know what it does, only that it is always there. Even the vendor's help desk may not know.

In some cases, these protocols are enabled by default. Many of these early protocols have little or no security and may not be able to be adequately secured. Administrators may not know about them or what they are or what they do.

As a system manager, you must know what is installed and configured on your system. These programs may appear as unknown entries in the Internet configuration file or as daemons that are initiated during system start-up. These programs should be removed from the system if they are not being used. You must know what all the processes running on your system do, and why they are there.

I l @ ve RuBoard