NETWORKS & PROTOCOLS — THE HEADLINES

 2001/10/05 

FBI's most wanted

 2001/9/06 

Worm exploits buffer overflow in telnet daemon

 2001/8/28 

Researchers develop SSH cracker

 2001/8/20 

Multiple Novell NetWare 5.x problems

 2001/7/26 

Multiple vendors telnet daemon vulnerability

NETWORKS & PROTOCOLS — THE LINKS

Disclaimer: These hyper-links to external content may be submitted by visitors of this site. Their contents do not represent the opinion of this publication. The links will be reviewed by an editor and may be modified, rejected or deleted at any time.

NETWORKS & PROTOCOLS — THE NEWS

2001/10/05

14:38 +0100

FBI's most wanted

[Networks & Protocols] The FBI and the System Administration, Networking, and Security Institute (SANS) released a list of the 20 top vulnerabilities of Internet-connected systems and urged companies to close dangerous holes while warning again of virulent cyberattacks to come, report Computerworld online. "The Internet is simply not ready because of these vulnerabilities; we're not ready to withstand a major attack," said SANS Institute director Alan Paller at a press briefing.

The list of vulnerabilities, jointly prepared by Bethesda, Maryland-based SANS and the FBI's National Infrastructure Protection Center and a team of approximately 50 corporate and academic security experts, is more exhaustive than a similar list released last year that limited itself to the top 10 problems.

Citing the recent Code Red and Nimda worms, Paller said, "What many people don't know is that a very small number of vulnerabilities are used over and over in these attacks."

The top 20 list details vulnerabilities that are specific to Windows and Unix-based systems, as well as problems that are common to any system, such as no passwords or weak passwords, large number of open ports, nonexistent or incomplete logging, vulnerable Common Gateway Interface programs, unprotected Windows networking shares, and information leakage via null session (also known as anonymous log-on) connections, as well as a number of other technical issues.

But fixing these holes won't be enough to improve security at Internet connected systems, John Gilligan, the deputy CIO of the USAF and chairman of the Federal CIO Council's security committee, warned. Software makers need "a new approach to the design and fielding of their products," said Gilligan, who added that "the find and fixed patch race is something that is really starting to drain our resources." Gilligan said commercial software needs to meet higher security standards, reinforced by a "contractual or legal expectation."

"We realize that this will cost the industry additional expenses in the development and testing of software; we would gladly pay that cost upfront in the purchase price rather than incur the cost—which is enormous," he said. // c.f. SecuritySpace, Cybercrime-Alerts :: [dre].

Comments (0)

2001/9/06

09:51 +0100

Worm exploits buffer overflow in telnet daemon

[Networks & Protocols] Recently, the cyber security community received numerous reports of intruders using the buffer overflow vulnerability in the telnet daemon program, warns the FBI's NIPC. Security organizations, such as CERT/CC, cited this vulnerability in a July advisory outlining the vulnerability and solutions to address this problem.

Due to the increase of these reports and with the activity of a new worm that has targeted this vulnerability, the NIPC urges the consumers to contact their vendors to obtain the appropriate fix. This vulnerability has the potential to impact the victim by allowing an intruder to copy, delete, or execute any program on the victim's system.

A new worm called "x.c", designed to exploit this vulnerability, has been discovered. Although that specific worm has been disabled, other malicious code variants could take advantage of the same vulnerability. Vendor patches are available and NIPC urges consumers to contact their vendor to obtain the appropriate fix for their operating system.

This vulnerability affects primarily FreeBSD-derived telnet daemons (including Solaris, AIX, and several versions of Linux), but some information suggests other vendors' telnet daemons may also be subject to attack using the same method.

A list of vulnerable systems can be obtained at the above-mentioned article. It is recommended that users of these operating systems check with their vendor for applicable patches, or disable the telnet daemon entirely. // c.f. SecuritySpace :: [dre].

Comments (0)

2001/8/28

13:31 +0100

Researchers develop SSH cracker

[Networks & Protocols] Researchers at the University of California at Berkeley have discovered more vulnerabilities in Secure Shell (SSH) which allow an attacker to learn significant information about what data is being transferred in SSH sessions, including passwords.

SSH was designed as a secure channel between two machines, based on strong encryption and authentication. But by observing the rhythm of keystrokes, and using "advanced statistical techniques on timing information" (PDF) collected, attackers can pick up significant details.

Each keystroke from a user is immediately sent to the target machine as a separate IP packet. By performing a statistical study on a user's typing patterns, and applying a key sequence prediction algorithm, the researchers managed to successfully predict key sequences from inter-keystroke timings.

A password cracker program, dubbed "Herbivore," was developed on the back of the research. Herbivore is capable of learning a user's password by monitoring SSH sessions. // c.f. SecuritySpace :: [dre].

Comments (0)

2001/8/20

09:38 +0100

Multiple Novell NetWare 5.x problems

[Networks & Protocols] The latest Nomad Mobile Research Centre advisory reports that the NetWare Enterprise Web Server 5.1 has a couple of security problems, and these problems are related to additional products being used, such as GroupWise WebAccess.

When NDS browsing via the web server is enabled, if an attacker can reach that server's port 80 they can enumerate information such as user names, group names, and other system information. This is not especially a GroupWise problem, but WebAccess can "intensify" the leakage, as it allows for more objects to browse. This is simply a new flavor on an old problem (see nds1 and adv_novellleak for additional information).

Poor handling of GET commands will allow for GroupWise WebAccess servers to display indexes of the directories instead of HTML files. We have been unable to get this to work consistently. Basically, instead of issuing a "GET / HTTP/1.1" from NetCat against port 80 on the target system, using "get / HTTP/1.1" causes a directory listing to be displayed if indexing of directories is allowed, instead of a 501 or 502 error when indexing of directories is disallowed.

Nomad is awaiting an official response from Novell, including acknowledgement of both problems. They were notified a few months ago. // c.f. VulnWatch :: [dre].

Comments (0)

2001/7/26

13:32 +0100

Multiple vendors telnet daemon vulnerability

[Networks & Protocols] Most of the current telnet daemons in use today suffer from a buffer overflow in the telnet option handling. Under certain circumstances, it may be possible to exploit it to gain root privileges, reported [email protected]. CERT/CC has released its Advisory CA-2001-21 accordingly.

Vulnerable are: —BSDI 4.x default (exploitable), —FreeBSD [2345].x default (exploitable), —IRIX 6.5 (Not exploitable), —Linux netkit-telnetd prior to 0.14 (unknown), —NetBSD 1.x default (exploitable), —OpenBSD 2.x (unknown), —Solaris 2.x sparc (unknown)
Immune systems: —Linux netkit-telnetd 0.14 and above, —OpenBSD current.

By sending a specially formed option string to the remote telnet daemon a remote attacker might be able to overwrite sensitive information on the static memory pages. If done properly this may result in arbitrary code getting executed on the remote machine under the privileges the telnet daemon runs on, usually root.

The vendors have been notified of the problem at the same time as the rest of public, vendor patches for your telnet daemon that fix the bug will show up soon. The best long-term solution is to disable the telnet daemon at all, since there are good and free replacements (e.g. OpenSSH). // c.f. SecuriTeam :: [dre].

Comments (0)