InfoSec Handlers Diary Blog

New week, new scams. Two emails showed up on our ISC scam radar this morning.

One seems directed at universities, and is informing students that their email quota is exhausted and asks them to connect to a web site (studentresume. c.la) to re-enable their account. The site includes an iframe from planetchiltern. com and doesn't even TRY to look like the web site of an university. It still asks for your userid and password, though...

Another one pretends to come from Microsoft and warns users on a rapidly spreading Conficker.B infection (sic!). Conveniently enough, the email includes the "patch and removal tool".

If you fell for either of these, now would be a good time to confess to your sysadmin :).

ICMP, the Internet Control Message Protocol, was originally designed (RFC 792, 1981) to convey error conditions back to the sender of an IP packet. In today's Internet, ICMP is somewhat of an anachronism, since pretty much all programs and protocols contain their own error detection and recovery logic.

ICMP packets don't use port numbers like UDP and TCP do, but have a message type and message code field in the header instead.

ICMP/8 and ICMP/0
The ICMP packets that you probably are most familiar with are "ICMP Type 8 code 0" and "ICMP Type 0 Code 0", commonly known as "ping" and "ping reply". A "ping" is still the most commonly used command by system administrators to determine if a box is "up" and to check "round trip times" between two systems. While there are more reliable methods to accomplish either of these tasks, good old "ping" still prevails.

Ping packets can also have a data portion (payload). This triggered a big hunt for "covert channels" more than a decade ago, when an article on "Project LOKI: Arbitrary information tunneling" appeared in Phrack Magazine. Today, most firms and institutions keep "ping" blocked across their perimeter firewall, but primarily since the impact of blocking it is marginal, and not because of "covert channel" concerns. It has been a long time since mal-code authors last effectively used ping for communication. And why should they - http and https are working just fine across most corporate firewalls.

Another attack, the "smurf", relied on ICMP's ability to respond to a broadcast packet. Basically, a single "ping" sent to the broadcast address of a subnet was answered by all the active hosts on that subnet. Very neat to quickly map what's out there, but also a really good "amplifier" in a denial of service attack. This non-feature of ICMP has therefore long since been fixed: All current Operating Systems have broadcast ICMP either off by default, or support a configuration parameter to turn it off.

ICMP/3
ICMP Type 3, "Destination Unreachable", is next to "ping" the most common of the ICMPs on today's Internet, primarily thanks to the increasing use of UDP in peer to peer networks. Unlike TCP, where the recipient of a packet can respond with a "Reset" (RST) if communication is undesired or not permitted, UDP contains no such mechanism and relies on ICMP to convey its displeasure. ICMP Type 3 Code 3, "port unreachable" is the usual answer returned on an UDP packet sent to a port that is not active (listening).

One of the cool features of ICMP Type 3 is that the error messages actually contain the first few bytes of the original packet that triggered the error. Firewalls unfortunately tend to ignore this information, and only display a useless information like "Denied ICMP type=3, code=3 from 88.1.2.3 on interface outside". A good old tcpdump or decent IDS will tell you more:

At offset 0x001C (marked in blue), you can see the start of the original datagram. In this case, the system at 88.1.2.3 responded with an ICMP/3:3 "Port unreachable" because 173.2.3.4 apparently sent a DNS request for "www.ibm.com" to 88.1.2.3, and the latter does not seem to be running a DNS service. If you ever find your firewall under a deluge of ICMP/3 packets, sniffing them to determine the embedded original packets could help to tell you more.

ICMP/3 Type 4, "Fragmentation Needed but Don't Fragment Bit Set" is used to determine the maximum size per IP packet that a path between source and destination can support. This so-called "PMTU Discovery" helps to ensure that packets are sent at the maximum size that can squeeze through, which avoids fragmentation and reduces the bandwidth used for packet headers as compared to actual payload. In the frenzy to ban all ICMP through firewalls a decade ago, the rather useful ICMP 3/4 messages got blocked along with everything else. PMTU discovery is largely defunct today.

ICMP/11
An ICMP/11 packet is triggered when a packet dies off because its internal "time to live" (TTL) counter expired. IP packets start their journey with a TTL of usually 255, and this counter is decremented at every network hop the packet traverses. When the counter reaches zero, the packet is discarded, and an ICMP/11 error generated. ICMP/11 are also used by the "traceroute" program, which sends packets with deliberately low TTLs and keeps track of the origins of any ICMP/11 error message it receives. By slowly counting up from the low initial TTL, a hop-by-hop mapping of the network nodes between source and destination can be performed.

The IETF started work on a paper that lists both the "threat" of ICMP and "impact" caused when an ICMP message is blocked at the perimeter. Today, a lot of firms block everything ICMP, and accept that doing so can lead to delays and time-outs in some UDP based applications. A less paranoid and equally well accepted practice is to permit ICMP/11:0 and ICMP/3:4 error replies from the outside, but to rate-limit these packets to prevent flooding.

But this is the Cyber Security Awareness Month. So ... time to improve your awareness: If you currently have all ICMP blocked on your perimeter, sniff the ICMP traffic on the outside of the firewall for a day to see what you are missing. If you currently permit ICMP through your perimeter, sniff the ICMP traffic for a day to see what it is that you are letting through.

At first, when a pal of mine called to rant about the new tendency of his OS to go "hasta la Vista", I laughed. He is an IT professional, and a little swine flu in his computer is no big deal. Or so I thought. What started as an occasional hiccup on Thursday apparently turned into an unspectacular but complete Exitus on Friday: The computer simply didn't boot no more.

Of course we all know, often from individual experience, that a disk drive with a "mean time between failure" (MTBF) of indicated 500'000 hours is NEVER the one drive that we bought. Rather, we usually seem to get the "mean failure" version, whereas other people must be getting the "time between".

Nevertheless, this apparently hasn't taught us to be diligent with our backups. As far as backups of data on personal PCs go, most people are either in the "ignorant and negligent" or "knowing and diligent" camps. The special corner of data loss hell, the "knowing but negligent" section, seems to be solely populated by IT and technology people.

It doesn't have to be you. Go buy that USB or eSATA drive, and get that copy made TODAY.