Advisories

Using ICMP queries to fingerprint some networking equipment
Published: April 7, 2003.

Networking equipment can be identified using a variety of methods. The following are two new, and simple, fingerprinting methods (or observations) tailored towards networking gear…

Complete Details are available in PDF format

Cisco Field Notice – IOS Accepts ICMP Redirects in Non-default Configuration Settings
Published: February 10, 2003.

If a router has IP routing disabled it will accept bogus ICMP redirect packets and modify its routing table accordingly. With IP routing disabled, the router will act as a Host and it will comply with the Host Requirements given in the RFC 1122. If IP routing is enabled(which it is by default) ICMP redirect packets are received and recognized but ignored. The router will not update its routing table with the information present in the redirect packets.

Complete Details in PDF format

More Vulnerabilities with Pingtel xpressa SIP-based IP Phones
Published: August 20, 2002.

Pingtel (http://www.pingtel.com) develops intelligent Java-based voice-over-IP phones and softphones for service providers and enterprises.

Using the vulnerabilities enumerated within this advisory it is possible to jeopardize critical telephony infrastructure based on Pingtel’s xpressa SIP-based IP phones and softphones. Additionally, certain vulnerabilities allow an attacker to take complete control over an IP Phone or a softphone node either directly or by circumventing other SIP entities on the network by abusing the ‘node’s credentials’.

The most severe issue discussed is the way an attacker can exploit vulnerabilities with MyPingtel portal (http://my.pingtel.com) to subvert a VoIP infrastructure which includes IP Phones and/or softphones from Pingtel.

Full Details in PDF format ~500kb
Moderated version in PDF format

Multiple Vulnerabilities with Pingtel xpressa SIP Phones
Published: July 12, 2002.

Pingtel develops intelligent Java-based voice-over-IP phones for service providers and enterprises. The vulnerabilities discussed in this advisory were found using Pingtel’s xpressa voice-over-IP phones model PX-1 software versions 1.2.5-1.2.7.4.

The Pingtel xpressa SIP-based phone contains multiple vulnerabilities affecting all aspects of the phone’s operation. These vulnerabilities include: remote access to the phone; remote administrative access to the phone; manipulation of SIP signaling; multiple denials of service; remote telnet access (complete control of the VxWorks operating system); local physical administrative access, and more.

Using the vulnerabilities enumerated within this advisory it is possible to jeopardize critical telephony infrastructure based on Pingtel’s xpressa SIP phones. Additionally, certain vulnerabilities present a severe risk to an organization’s entire network infrastructure…

Full Details
Vendor Response
Vendor Recommended Upgrade: v2.0.1
Vendor Guide: “Best Practices for Deploying Pingtel Phones”

Nuisance with small (< 46bytes) IP packets and tcpdump
Published: May 28, 2002.

With IP packets smaller than 46 data bytes the tcpdump program will display the Ethernet trailer information when asked to strip-off any link-layer information (-x option) when it is displaying captured data. The trailer information will look like a valid IP packet data. Read More

A crash course with Linux Kernel 2.4.x, IP ID values & RFC 791
Published: April 13, 2002.

This is an update of my original postings about the IP ID handling in the ICMP and UDP protocols with Linux Kernel 2.4.x. This posting also examine TCP. It highlights the cases which we need to expect IP ID value of zero with Linux Kernel 2.4.x. Read More

Identifying PGP Corporate Desktop 7.1 with PGPfire Personal Desktop Firewall Installed (no need to be enabled) on Microsoft Windows Based OSs
Published: January 25, 2002.

Network Associates PGP Corporate Desktop version 7.1 alters the TCP/IP stack of the MS operating system it is installing its PGPfire Personal Desktop Firewall product on… Read More

ICMP Echoing Integrity Problems with the IP Header’s 3Bits flags and Offset Fields
Published: Saturday, July 7, 2001.

…Looking closely at the trace above, we can see that the DF bit is set with the offending UDP datagram. Look at the ICMP Port Unreachable error message at the echoed data part, the Bit order has changed from 4000 to 0040… Read More

Identifying OpenBSD 2.6-2.9 based machines using ICMP Port Unreachables
Published: Tuesday, June 26, 2001.

…During my research on X (to be published at the Black Hat Briefings 2001 July 11-12) I have found a new fingerprinting method that involves the same field value. With this method the IP Total Length field value being echoed (with an ICMP Port Unreachable Error Message) is 20 bytes less than the original value… Read More

Fingerprinting Linux Kernel 2.4.x based machines using ICMP
Published: Wednsday, May 9, 2001.

While playing with Linux Kernel 2.4.2, I have encounter a rather simple operating system fingerprinting method using the ICMP protocol targeting machines based on Linux Kernel 2.4… Read More

Fun with IP Identification Field Values (Identifying Older MS Based OSs)
Published: Saturday, May 5, 2001.

RFC 791 gives a description about the IP Identification field.

The identification field value is used to uniquely identify the fragments of a particular datagram. Fragments of a particular datagram are assembled if they have the same source, destination, protocol, and Identifier. The identifier is being chosen to be unique for this “this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet”… Read More

Several Misbehaviors with the ICMP implementation (and the ‘ping’ utility) with MS based operating systems
Published: Wednsday, May 2nd, 2001.

RFC 792 (Internet Control Message Protocol) suggests how the ICMP Identifier field and the ICMP Sequence Number field should be used… Read More

Foundry Networks Networking Devices Padded Bytes with ICMP Port Unreachable(s) – The 12 Bytes from No Where
Published: Wednsday, December 6, 2000.

Foundry Networks networking devices will pad extra 12 bytes of data with their ICMP Port Unreachable Error messages. Our first example is with a ServerIron switch running software version 7.1.02T12 eliciting an ICMP Port Unreachable error message… Read More

LINUX ICMP Error Message Quoting Size Differences (The 20 Bytes from No Where)
Published: Wednsday, December 6, 2000.

We must understand that there are differences between the different ICMP Error messages, not only with their meaning, but also with their implementation. I was expecting that several characters with the ICMP Error messages will be the same along all of the ICMP Error Messages, but I was wrong regarding few operating systems.

The most interesting case is with the LINUX operating system based on Kernel 2.2.x and 2.4.t-x. … Read More

ICMP Error Message Quoting Size with Different Operating Systems
Published: Saturday, November 25, 2000.
Corrected: Wednsday, December 6, 2000.

Each ICMP error message includes the Internet Protocol (IP) Header and at least the first 8 data bytes of the datagram that triggered the error (the offending datagram); more than 8 bytes may be sent according to RFC 1122.

Most of the operating systems will quote the offending packets IP Header and the first 8 data bytes of the datagram that triggered the error. Several operating systems and networking devices will parse the RFC guidelines a bit different and will echo more than 8 bytes. … Read More

Novell Netware Echoing Integrity Bug with ICMP Fragment Reassembly Time Exceeded
Published: Thursday, November 23, 2000.

Novell Netware operating systems have a unique pattern with ICMP Fragment Reassembly Time Exceeded error messages they produce.

In general, when an ICMP error message is produced, the offending packet’s IP Header + at least 8 bytes of data are echoed with the error message. If we examine closely the next example, we can see that the Offending packet’s IP TTL field value echoed back is zero. We expect this value to decrement from the value initially assigned, but not to be zero. Since this value should change from one hop to another, the Checksum need to be recalculated each time. With the error message we can see that the Checksum echoed is miscalculated.

…And again this is a Fragment Reassembly Time Exceeded ICMP error message and not ICMP Time Exceeded in Transit error message. … Read More

Using the TOS Byte’s Unused Bit (Fingerprinting WIN2K, ULTRIX and more)
Published: Friday, November 17, 2000.

RFC 1349 states that the last field of the TOS byte, the “MBZ” (must be zero), is unused and must be zero. The RFC also states that routers and hosts ignore the value of this bit.

This is the only statement about the unused bit in the TOS Byte in the RFCs. The RFC states: “The originator of a datagram sets this field to Zero”.

Obviously it was meant that this field would be always zero. But what will happen if we would set this bit with our ICMP Echo Requests? Will this bit be zero out on reply or will it be echoed back? … Read More

Precedence Bits Echoing (Fingerprinting WIN2K, Ultrix, HPUX, OpenVMS and more)
Published: Friday, November 17, 2000.

… The precedence bits behavior is a problem. RFC 1122, which defines the requirements for Internet Hosts, does not outline the way to handle the Precedence Bits with ICMP.

RFC 1812, Requirements for IP version 4 routers state that: “An ICMP reply message MUST have its IP Precedence field set to the value as the IP Precedence field in the ICMP request that provoked the reply”.

Echoing back the Precedence field value has its logic, because the TOS field should be echoed back with an ICMP Query replies, and both the Precedence field and the TOS field were to dictate very explicit types of behavior with certain types of data.

As you can see we do not have a clear ruling about this issue. I was thinking it might be a ground for an operating system fingerprinting method. … Read More

TOS bits (=field) Echoing with ICMP Error Messages
Published: Friday, October 20, 2000.

RFC 1394 specify that an ICMP error message is always sent with the default TOS field value of 0000 (TOS field=TOS bits in the TOS Byte).

When an offending packet with a TOS field value of 0000 is eliciting an ICMP error message from an offended host, the TOS field value with all the operating systems I have checked will be set to 0000…

What will happen if the TOS field with the offending packet will be set to a value different than the default (0000)? … Read More

Precedence field value in ICMP Error Messages with LINUX Kernels 2.2.x & 2.4
Published: Thursday, October 19, 2000.

This is a corrected post for the post I have sent to Bugtraq on 14.10.2000 Titled “TOS Field value in ICMP Error Messages with LINUX Kernels 2.2.x & 2.4”.

Each IP Datagram has an 8-bit field called the “TOS Byte”, which represents the IP support for prioritization and Type-of-Service handling.

The “TOS Byte” consists of three fields.

The “Precedence field”, which is 3-bit long, is intended to prioritize the IP Datagram. It has eight levels of prioritization… Read More

FreeBSD 4.x Bug with ICMP Error Messages
Published: Saturday, October 14, 2000.

It is long known that FreeBSD uses a wrong IP Identification number with its ICMP Error Messages. This fact was discovered by Fyodor long ago.

I wish to identify were the problem is…. Read More

TOS Field Value in ICMP Error Messages with Linux Kernels 2.2.x & 2.4.x
Published: Saturday, October 14, 2000.

RFC 1349 states that ICMP Error messages should be sent with TOS field value of 0x00. Nearly all stack implementations send back 0x00 as the TOS field value when generating an ICMP error message. All but LINUX.

Fyodor had outlined in his paper “Remote OS Identification by TCP/IP Fingerprinting” the fact that LINUX is using the value of 0xc0 (an unused precedence value) as its TOS field value with ICMP Port Unreachable error messages… Read More

ICMP Timestamp with code!=0 – LINUX 2.2.x and 2.4.x changed pattern
Published: Sunday, October 8, 2000.

With previous post to bugtraq I have already outlined the fact that Microsoft Windows 98/98 SE/ME, and the Microsoft Windows 2000 Family that have answered an ICMP Timestamp requests with the code field set to zero, do not produce any reply back when they are queried with ICMP Timestamp request with Code field set to a value different than zero.

When I have tried this on LINUX machines based on Kernel 2.2.x & 2.4.x I have encountered a different pattern of behavior… Read More

Using the Unused (Identifying Sun Solaris & HPUX 11.0 OSs)
Published: Tuesday, September 12, 2000.
Corrected: Wednsday, September 13, 2000.

RFC 791 defines a three bits field used for various control flags in the IP Header. Bit 0 of this bits field is the reserved flag, and must be zero according to the RFC.

What would happen if we would decide to break this definition and send our ICMP Query requests with this bit set (having the value of one)?

Sun Solaris, and HPUX 11.0 would echo back the unused bit… Read More

The DF Bit Playground (Identifying Sun Solaris)
Published: Tuesday, September 12, 2000.
Final Correction: Sunday, October 8, 2000.

RFC 791 defines a three bits field used for various control flags in the IP Header.

Bit 0 is the reserved flag, and must be zero.

Bit 1, is called the Don’t Fragment flag, and can have two values. A value of zero (not set) is equivalent to May Fragment, and a value of one is equivalent to Don’t Fragment. If this flag is set than the fragmentation of this packet at the IP level is not permitted, otherwise it is… Read More

IP TTL Field Value with ICMP (Oops – Identifying Windows 2000 again, and more)
Published: Thursday, Auguat 31, 2000.

The IP TTL field value with ICMP has two separate values, one for ICMP query messages and one for ICMP query replies. The TTL field value help us identify certain operating systems and groups of operating systems. It also provide us with the simplest means to add another check criteria when we are quering other host(s) or listening to traffic (sniffing)… Read More

DF Bit Echoing with ICMP
Published: Monday, Auguat 21, 2000.

Some operating systems, when receiving an ICMP Query message with the DF bit set, would set the DF bit with their replies as well. Sometimes it would be in contrast with their regular behavior, which would be not setting the DF Bit in their replies for a regular query that comes with the DF bit not set…. Read More

TOSing OSs out of the window / Fingerprinting Windows 2000 with ICMP
Published: Wednsday, Auguat 16, 2000.

RFC 1349 define the usage of the Type-of-Service field in the IP Header with ICMP datagrams. It distinguishes between ICMP error messages, ICMP query messages, and ICMP reply messages… Read More

Identifying SUN Solaris Machines using ICMP Address Mask Requests with a little twist
Published: Saturday, Auguat 5, 2000.

It appears that only some of the operating systems would answer an ICMP Address Mask Request. Those operating systems include: ULTRIX OpenVMS, Windows 95/98/98 SE/ME, NT below SP 4, and SUN Solaris machines. How can we distinguish between those who answer the request? … Read More

Identifying Windows 98/98SE/ME/2000 Using Wrong Codes with ICMP Timestamp Requests
Published: Saturday, Auguat 5, 2000.

I have decided to map which operating systems would answer to an ICMP Timestamp Request that would have its code field not set to zero.

Interesting results were produced. The Microsoft Windows 98/98 SE/ME, and the Microsoft Windows 2000 Professional/Server that have answered to ICMP Timestamp requests with the code filed set to zero, now did not produce any reply back… Read More

OS fingerprinting method to distinguish between Windows boxes and the rest of the world
Published: Saturday, June 24, 2000.

During my research on ICMP I have encountered a new OS fingerprinting method. When a wrong code is sent along with the correct type of ICMP ECHO Request message Microsoft Windows Boxes would act differently than other operating systems would on the ICMP ECHO Reply… Read More

Advertisements

%d bloggers like this: