Remote Heap Overflow in VMware Products

Thanks to a heads-up from "yomama" in the #snort channel, I learned of this advisory from Tim Shelton:

"A vulnerability was identified in VMware Workstation (And others) vmnat.exe, which could be exploited by remote attackers to execute arbitrary commands.

This vulnerability allows the escape from a VMware Virtual Machine into userland space and compromising the host.

'Vmnat' is unable to process specially crafted 'EPRT' and 'PORT' FTP Requests."

This implies that someone who connects to a FTP server using traffic that is processed by vmnat.exe can exploit vmnat.exe.

As a VMware Workstation user, I am glad to see they have published a new version to address the vulnerability.

Read More

Two Great Wiretapping Articles

Given the recent coverage of wiretapping in the mainstream media, I thought I would point out two excellent articles in the latest issue of IEEE Security & Privacy Magazine. Thankfully, both are available online:

• Signaling Vulnerabilities in Wiretapping Systems by Micah Sherr, Eric Cronin, Sandy Clark and Matt Blaze


• Security, Wiretapping, and the Internet by Susan Landau

Both concentrate on technical issues of wiretapping. The first concentrates on how to tap a physical line or switch, and ways to defeat those taps. The second describes why incorporating wiretap features into VoIP is a bad idea. Each article discusses relevant laws.

Read More

Brief Thoughts on Cisco AON

I received my copy of Cisco's Packet Magazine, Fourth Quarter 2005 recently. The new digital format for the magazine makes linking to anything impossible, but I found the relevant article as a .pdf.

It describes the company's Application-Oriented Networking (AON) initiative. According to this story that quotes Cisco personnel, AON "is a network-embedded intelligent message routing system that integrates application message-level communication, visibility, and security into the fabric of the network." According to this document:

Cisco AON is currently available in two products that integrate into Cisco switches and routers:

• Cisco Catalyst® 6500 Series AON module, which is primarily deployed in enterprise core or data centers


• Cisco 2600/2800/3700/3800 series AON module, which is primarily deployed at branch offices

AON is part of Cisco's Intelligent Information Network project. From the article:

"The Cisco AON module in the branch puts intelligent decision-making at the network edge. It can intercept and analyze traffic in various message formats and protocols and bridge between them, provide security, and validate messages, creating a transparent interface between trading partners and, in effect, a good business-to-business gateway. It can manage remote devices that send messages to the Cisco Integrated Services Router in the branch. It can also filter messages from multiple sources that come into the branch router for duplicates or by other criteria, aggregate them, make decisions according to instructions, and transmit selected messages to a sister AON module deployed in the data center." (emphasis added)

I find this aspect very interesting. It sounds like AON could be used to enforce protocol and security policies. I wonder if this might eventually happen on a per-port basis? Security on a per-port basis would allow validation of network traffic itself, not just whether a host should be accessing the network. Per-port security would move the job of enforcing security away from choke-point products like firewalls (which include IPSs, application firewalls, whatever) and into switches.

This is not necessarily a great idea, as this Register article confirms. One of the strengths of the Internet has been the fact that it inverted the telecom model, where the network was smart and the end device (the phone) was dumb. The traditional Internet featured a relatively dumb network whose main job was to get traffic from point A to point B. The intelligence was found in those end points. This Internet model simplified troubleshooting and allowed a plethora of protocols to be carried from point A to point B.

With so-called "intelligent networking," points A and B have to be sure that the network will transmit their conversation, and not block, modify, or otherwise interfere with that exchange to the detriment of the end hosts. As a security person I am obviously in favor of efforts to enforce security policies, but I am not in favor of adding another layer of complexity on top of existing infrastructures if it can be avoided.

Read More

Navy Installing Sun Ray Thin Clients

I've written about Sun's Sun Ray 170 thin client before. The Sun Ray is a true thin client, and to me it is the best way for enterprises to win the battle of the desktop against Microsoft-centric threats. Accordingly, I would like to congratulate the US Navy after reading Navy opts for thin-client systems onboard ships:

"Bob Stephenson, chief technology officer for command, control, communications, computers and intelligence operations at Spawar, said the Navy plans to use the thin-client systems from Sun Microsystems on all major surface ships in the fleet.

Thin clients will be installed on 160 vessels, Stephenson said. ..

Mario Diaz, Sun Microsystems' Navy sales manager, said the Navy will deploy the company's Sun Ray thin clients connected to servers running the Trusted Solaris operating system, which can collapse multiple networks onto a single network while providing separate levels of classification."

As a former Air Force officer, I'm biased towards the Air Force. However, I've written that I think the Air Force is fighting the last war, having decided to adopt "standardized and securely configured Microsoft software throughout the service." Whee, that only took what, 10 years? Kudos to the Navy for stepping forward with an innovative solutions.

Read More

Changes Coming in Sguil 0.6.1

Sguil 0.6.0p1 introduced the use of MERGE tables in MySQL to improve database performance.

Sguil 0.6.1, in development now, will bring UNION functionality to database queries. This will also improve performance.

Consider the following standard event or alert query in Sguil. This query says return Snort alerts where 151.201.11.227 is the source IP OR the destination IP. OR is a slow operation compared to UNION. Sguil 0.6.1 will use a new query.

Here we look for Snort alerts where 220.98.198.35 is the source IP address, and use UNION to return those results with alerts where 220.98.198.35 is the destination IP address.

UNION functionality was not available in MySQL 3.x, but it appeared in 4.x. Many Sguil users are running MySQL 5.x now.

Those screen shots just show the WHERE portions of the database queries. Here is each version of similar queries look like in their entirety:

Sguil 0.5.3 and older:

SELECT sensor.hostname, sancp.sancpid, sancp.start_time as datetime, sancp.end_time,
       INET_NTOA(sancp.src_ip), sancp.src_port, INET_NTOA(sancp.dst_ip), sancp.dst_port,
       sancp.ip_proto, sancp.src_pkts, sancp.src_bytes, sancp.dst_pkts, sancp.dst_bytes
FROM sancp
IGNORE INDEX (p_key)
INNER JOIN sensor ON sancp.sid=sensor.sid
WHERE sancp.start_time > '2005-08-02' AND ( sancp.src_ip = INET_ATON('82.96.96.3') OR
    sancp.dst_ip = INET_ATON('82.96.96.3') )

EXPLAIN
+----+-------------+--------+--------+--------------------------+---------+---------+-------------------+-----------+-------------+
| id | select_type | table  | type   | possible_keys            | key     | key_len | ref               | rows      | Extra       |
+----+-------------+--------+--------+--------------------------+---------+---------+-------------------+-----------+-------------+
|  1 | SIMPLE      | sancp  | ALL    | src_ip,dst_ip,start_time | NULL    |    NULL | NULL              | 100458818 | Using where |
|  1 | SIMPLE      | sensor | eq_ref | PRIMARY                  | PRIMARY |       4 | sguildb.sancp.sid |         1 |             |
+----+-------------+--------+--------+--------------------------+---------+---------+-------------------+-----------+-------------+

The actual query returns an empty set after 5mins 29.14secs on Bamm's database.

Sguil 0.6.0p1:

(
   SELECT sensor.hostname, sancp.sancpid, sancp.start_time as datetime, sancp.end_time,
          INET_NTOA(sancp.src_ip), sancp.src_port, INET_NTOA(sancp.dst_ip), sancp.dst_port,
          sancp.ip_proto, sancp.src_pkts, sancp.src_bytes, sancp.dst_pkts, sancp.dst_bytes
   FROM sancp
   IGNORE INDEX (p_key)
   INNER JOIN sensor ON sancp.sid=sensor.sid
   WHERE sancp.start_time > '2005-08-02' AND sancp.src_ip = INET_ATON('82.96.96.3')
 ) UNION (
   SELECT sensor.hostname, sancp.sancpid, sancp.start_time as datetime, sancp.end_time,
          INET_NTOA(sancp.src_ip), sancp.src_port, INET_NTOA(sancp.dst_ip), sancp.dst_port,
          sancp.ip_proto, sancp.src_pkts, sancp.src_bytes, sancp.dst_pkts, sancp.dst_bytes
   FROM sancp
   IGNORE INDEX (p_key)
   INNER JOIN sensor ON sancp.sid=sensor.sid
   WHERE sancp.start_time > '2005-08-02' AND sancp.dst_ip = INET_ATON('82.96.96.3')
)

EXPLAIN
+----+--------------+------------+--------+-------------------+---------+---------+-------------------+------+-------------+
| id | select_type  | table      | type   | possible_keys     | key     | key_len | ref               | rows | Extra       |
+----+--------------+------------+--------+-------------------+---------+---------+-------------------+------+-------------+
|  1 | PRIMARY      | sancp      | ref    | src_ip,start_time | src_ip  |       5 | const             |  108 | Using where |
|  1 | PRIMARY      | sensor     | eq_ref | PRIMARY           | PRIMARY |       4 | sguildb.sancp.sid |    1 |             |
|  2 | UNION        | sancp      | ref    | dst_ip,start_time | dst_ip  |       5 | const             |  108 | Using where |
|  2 | UNION        | sensor     | eq_ref | PRIMARY           | PRIMARY |       4 | sguildb.sancp.sid |    1 |             |
|NULL| UNION RESULT |  union1,2  | ALL    | NULL              | NULL    |    NULL | NULL              | NULL |             |
+----+--------------+------------+--------+-------------------+---------+---------+-------------------+------+-------------+

The actual query returns an empty set in .33secs on Bamm's database.

Read More

Guidance Software 0wn3d

This morning I read stories by Brian Krebs and Joris Evers explaining how Guidance Software, maker of host-based forensics suite Encase, was compromised. Guidance CEO John Colbert claims "a person compromised one of our servers," including "names, addresses and credit card details" of 3,800 Guidance customers. Guidance claims to have learned about the intrusion on 7 December. Victim Kessler International reports the following:

"Our credit card fraud goes back to Nov. 25. If Guidance knew about it on Dec. 7, they should have immediately sent out e-mails. Why send out letters through U.S. mail while we could have blocked our credit cards?"

Guidance could face severe financial trouble. According to reporter Joris Evers:

"Guidance stored customer names and addresses and retained card value verification, or CVV, numbers, Colbert said. The CVV number is a three-digit code found on the back of most credit cards that is used to prevent fraud in online and telephone sales. Visa and MasterCard prohibit sellers from retaining CVV once a transaction has been completed."

Reporter Krebs explains the implications:

"Companies that violate those standards can be fined $500,000 per violation. Credit card issuers generally levee such fines against the bank that processes payment transactions for the merchant that commits the violations. The fines usually are passed on to the offending company."

Since Guidance's customers include "hundreds of security researchers and law enforcement agencies worldwide, including the U.S. Secret Service, the FBI and New York City police," I don't think those customers will tolerate this breach of trust.

Why did it take Guidance at least 12 days (from the first known fraudulent purchases on 25 Nov to the reported discovery on 7 Dec) to learn they were owned? I think this is an example of a company familiar with creating host-centric forensic software, but unfamiliar with sound operational security and proper policy, architecture, and monitoring to prevent or at least detect intrusions. Furthermore, who will be fired and/or fined for storing CVVs indefinitely?

Read More

Disk Ring Buffer in Tcpdump 3.9.4

I finally got a chance to try Tcpdump 3.9.4 and Libpcap 0.9.4 on FreeBSD using the net/tcpdump and net/libpcap ports. I was unable to install them using packages, so I used the ports tree. I initally got the following error:

===>  Extracting for tcpdump-3.9.4
=> MD5 Checksum OK for tcpdump-3.9.4.tar.gz.
=> SHA256 Checksum OK for tcpdump-3.9.4.tar.gz.
===>  Patching for tcpdump-3.9.4
===>   tcpdump-3.9.4 depends on shared library: pcap.2 - not found
===>    Verifying install for pcap.2 in /usr/ports/net/libpcap
===>  WARNING: Vulnerability database out of date, checking anyway
=> libpcap-0.9.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://www.tcpdump.org/release/.
libpcap-0.9.4.tar.gz                          100% of  415 kB   73 kBps
===>  Extracting for libpcap-0.9.4
=> MD5 Checksum OK for libpcap-0.9.4.tar.gz.
=> SHA256 Checksum OK for libpcap-0.9.4.tar.gz.
===>  Patching for libpcap-0.9.4
...edited...
===>  Installing for libpcap-0.9.4
===>   Generating temporary packing list
===>  Checking if net/libpcap already installed
[ -d /usr/local/lib ] ||  (mkdir -p /usr/local/lib; chmod 755
/usr/local/lib)
install  -o root -g wheel -m 444 libpcap.a /usr/local/lib/libpcap.a
ranlib /usr/local/lib/libpcap.a
[ -d /usr/local/include ] ||  (mkdir -p /usr/local/include; chmod 755
/usr/local/include)
install  -o root -g wheel -m 444 ./pcap.h /usr/local/include/pcap.h
install  -o root -g wheel -m 444 ./pcap-bpf.h  /usr/local/include/pcap-bpf.h
install  -o root -g wheel -m 444 ./pcap-namedb.h
/usr/local/include/pcap-namedb.h
[ -d /usr/local/man/man3 ] ||  (mkdir -p /usr/local/man/man3; chmod 755
/usr/local/man/man3)
install  -o root -g wheel -m 444 ./pcap.3  /usr/local/man/man3/pcap.3
===>   Compressing manual pages for libpcap-0.9.4
===>   Registering installation for libpcap-0.9.4
===>   Returning to build of tcpdump-3.9.4
Error: shared library "pcap.2" does not exist
*** Error code 1

Stop in /usr/ports/net/tcpdump.

I took at look at the Makefile for net/tcpdump and saw this:

# TODO: Add strict sanity check that we're compiling against a
# version of libpcap with which this tcpdump release is compatible.
#
.if defined(TCPDUMP_OVERWRITE_BASE) || !defined(WITH_LIBPCAP_BASE)
LIB_DEPENDS=    pcap.2:${PORTSDIR}/net/libpcap
.endif

I noticed this created when building libpcap-0.9.4:

/usr/ports/net/libpcap/work/libpcap-0.9.4/pcap.3

I also saw this on the system:

/usr/src/contrib/libpcap/pcap.3

So I changed tcpdump's Makefile like so:

LIB_DEPENDS=   pcap.3:${PORTSDIR}/net/libpcap

I was then able to finish the installation. (I emailed the port maintainer asking if my fix made sense.) I ran Tcpdump:

orr:/usr/ports/net/tcpdump# /usr/local/sbin/tcpdump -V
tcpdump version 3.9.4
libpcap version 0.9.4
Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ]
                [ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ]
                [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ]
                [ -W filecount ] [ -y datalinktype ] [ -Z user ]
                [ expression ]

Note this is not the version installed on the base system:

orr:/usr/ports/net/tcpdump# tcpdump -V
tcpdump version 3.8.3
libpcap version 0.8.3
Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ]
                [ -E algo:secret ] [ -F file ] [ -i interface ] [ -r file ]
                [ -s snaplen ] [ -T type ] [ -w file ] [ -y datalinktype ]
                [ expression ]

To look at the new man page for 3.9.4, I had to tell 'man' where to find the new man pages:

man -M /usr/local/man tcpdump

In the man page I saw the following two options:

       -C     Before writing a raw packet to a  savefile,  check  whether  the
              file  is  currently  larger than file_size and, if so, close the
              current savefile and open a new one.  Savefiles after the  first
              savefile  will  have the name specified with the -w flag, with a
              number after it, starting at 1 and continuing upward.  The units
              of  file_size  are  millions  of  bytes  (1,000,000  bytes,  not
              1,048,576 bytes).
...edited...
       -W     Used in conjunction with the -C option, this will limit the num-
              ber of files created to the specified number,  and  begin  over-
              writing  files  from  the  beginning, thus creating a 'rotating'
              buffer.  In addition, it will name the files with enough leading
              0s to support the maximum number of files, allowing them to sort
              correctly.

Awesome. Let's try it. Here I tell Tcpdump to save five 10 million byte files using the -W 5 and -C 10 switches.

orr:/home/richard$ sudo /usr/local/sbin/tcpdump -n -i fxp0 -s 1515 -C 10 -W 5 -w /nsm/test1.lpc
tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 1515 bytes

If I watch the /nsm directory, I see these files being created. Here the first four files have already appeared:

-rw-r--r--   1 root   sguil   10000114 Dec 19 16:29 test1.lpc0
-rw-r--r--   1 root   sguil   10000018 Dec 19 16:29 test1.lpc1
-rw-r--r--   1 root   sguil   10000110 Dec 19 16:29 test1.lpc2
-rw-r--r--   1 root   sguil   10001244 Dec 19 16:30 test1.lpc3
-rw-r--r--   1 root   sguil    7913472 Dec 19 16:30 test1.lpc4

Soon the first three files are already overwritten, and the fourth file is being overwritten as I check on the /nsm directory again:

-rw-r--r--   1 root   sguil   10000264 Dec 19 16:30 test1.lpc0
-rw-r--r--   1 root   sguil   10001286 Dec 19 16:30 test1.lpc1
-rw-r--r--   1 root   sguil   10000858 Dec 19 16:30 test1.lpc2
-rw-r--r--   1 root   sguil    1245184 Dec 19 16:30 test1.lpc3
-rw-r--r--   1 root   sguil   10000214 Dec 19 16:30 test1.lpc4

So, this system works as advertised. Unfortunately, the file naming convention simply adds 0,1,2,3, or 4 to the end of the specified file name of test1.lpc. This is not how Tethereal handles file naming. I am not sure yet if Tcpdump's system will be suitable for my needs. I imagine that when capturing GB-sized files is involved, the file timestamps may be enough to differentiate them?

By the way, people always ask "Why don't you use Tcpdump's -s 0 option to automatically specify a snaplen?" Here's why:

orr:/home/richard$ sudo /usr/local/sbin/tcpdump -n -i fxp0 -s 0 -C 10 -W 5 -w /nsm/test1.lpc
tcpdump: listening on fxp0, link-type EN10MB (Ethernet), capture size 65535 bytes

65535 bytes? That's IP's theoretical maximum. What's so good about that? It seems hamfisted.

Read More