Security Watch

New Buffer Overflow Vulnerability?

The latest Windows vulnerability alert might be like preaching to a bored choir.

• By Russ Cooper
• 10/03/2005

While the vulnerability certainly lends itself to a worm, the attack path is the same as so many other existing worms that it belies reasonableness to think that corporations would not already be protecting themselves. In other words, increased alerting is intended to reach companies that are already ignoring existing security threats, which sounds like an action doomed to failure, although it does allow for media coverage of the company doing the alerting.

Cisco IOS Firewall Authentication Proxy for FTP and Telnet Sessions Buffer Overflow: Cisco IOS contains a buffer overflow vulnerability in the Firewall Authentication Proxy for FTP and Telnet sessions that allows a remote attacker to cause a denial-of-service condition or execute arbitrary code on the affected system running IOS.

IOS can be configured to dynamically open ports based on user profiles, typically stored in a TACACS (Radius) server. When a connection is attempted through a port configured in this fashion, the router will expect the connection to be authorized by verifying that the connection is associated with an initial login, or is attempted with a valid user ID and password. Typically, this authentication would not be seen by the user at the time of the port access, but instead be associated with an initial login, usually when they dialed into the systems.

To be sure, this is not the user ID/password that a remote system -- such as a Microsoft IIS server configured to support FTP -- would typically expect. This is not a user ID/password that could be provided in a URL, for example. As such, it is a configuration for IOS, which is not as common as it was years ago. However, routers may be configured to support this authorization if, for example, there are frequent file drops by partners. Routers will not be trivially configured to be vulnerable; your router administrators should be very aware whether or not your routers support the vulnerable modules.

Thus far proof-of-concept code has not been produced, but given the attention paid to the IOS Executing Arbitrary Code talk at the recent Black Hat conference, there may well be groups looking for such opportunities to exploit routers.

Symantec Anti-Virus Corporate Edition Information Disclosure Issue: The clear text logfile Symantec\LiveUpdate\Log.Liveupdate stores login credentials and is accessible to an authenticated user with limited privileges.

In thinking about the potential abuse of this information, the threat becomes miniscule, if not non-existent. The “problem” is that the log file contains the credentials you use to connect to a LiveUpdate server. It also contains the DNS name of the LiveUpdate server you use.

The perceived attack scenario involves spoofing the DNS name of that LiveUpdate server, say, by placing an entry in your local Hosts file. This is already possible if your systems point themselves at Symantec’s publicly accessible LiveUpdate servers, since those names are well known. This, however, would not affect those systems that use an internal LiveUpdate server. By reviewing the log contents, the name of that internal LiveUpdate server could be found, and therefore it could be spoofed also. If this name were spoofed, it would be possible to prevent you from obtaining AV updates, possibly leaving you open to some future malware. It would also be possible to create a covert channel to a malicious server, since traffic perceived to be to/from the LiveUpdate server may be overlooked in log reviews.

Access to your credentials could allow a criminal to collect valid login information, possibly to sell to users of illegal copies of the software.

In any event, this information is only available to someone already on the system. So for it to be abused in malware, that malware will have to run first in order to take advantage of the information disclosure vulnerability. Otherwise, it could be abused by an internal user with malicious intent hoping to harm your network.

All in all, pretty boring stuff.

Physical Security
Hurricane Katrina/Rita and Typhoon Nabi: The Cybertrust Intelligence Team recently held a lengthy discussion about backup generators and disaster recovery. In summary, several points were emphasized:

• While performing regular tests of your backup generator is important, don’t forget to keep your fuel stores topped up just as regularly. Fuel used for testing is often overlooked.
• Fuel storage contingency needs to provide for the possibility that additional supplies cannot come in a timely fashion. Forty-eight hours seems to be commonly accepted as a reasonable amount of time to expect refueling. Clearly, in these instances, that time was grossly inadequate.
• Equally, natural gas has often been considered more reliable than fuel oil. Without a method to store it, in addition to being able to receive it via a non-standard route (e.g., a refilling capability that does not rely upon infrastructural delivery), natural gas can be less reliable than fuel oil. Fuel oil can be delivered in a wide variety of containers and almost always put into generators in a simple fashion.
• The location of your backup facilities is as important as their capabilities. If you are in flood-ridden areas, having a backup generator in your basement isn’t likely to help.
• True redundancy is expensive and requires a considerable amount of over-engineering. For example, when the first World Trade Center bombing occurred, most computer rooms were flooded by sprinkler systems. Tandem computers in those facilities continued to run because they had power supplies both in the bottom, and top, of the computer towers.