The event triggered for User Agents that were longer than 200 characters, which is also Microsoft’s recommendation for maximum user agent lengths.  The vulnerability is in some http servers that will cause a buffer overflow and thus denial of service when the user agent is too long.  I found a tool described here and downloadable here to generate large http requests.  I ran this against a test web server with IIS and found that it never crashed the server even though I generated user agent string of several million characters.  Java seemed to crash on the client before I ever affected the web server.  (I did find that I received a URI too long when I put about 19,500 characters in the get statement.)  So I determined that my servers were not affected by this vulnerability.

I noticed in the events that were sent to me that the user agents all looked legitimate.  Most were between 200 and 250 characters, so they weren’t far over the limit.  They were all Internet Explorer strings with many .Net versions displayed.  So I spent some time googling user agent strings and found several good articles and sites that I have linked to below.

The User Agent is a string that is sent during an http request that provides the web server with information on the browser being used and the platform it is running on.  Microsoft provides a good summary here. You can see what the user agent of your browser is by going to:  http://whatsmyuseragent.com/ .  When I went to this site using firefox (my default browser) I received this:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4.  Checking my user agent from IE revealed:  Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648) I found a good article that discusses .net and the user agent string.  One point that I noticed was that .net truncates the string to 256 characters.

I also found this site that describes how to change the user agent string in various browsers.  This site is a searchable database of user agents.  And this is an interesting article on a string sniffer that collects strings into a database.  Another interesting site lists IP addresses and their known user agents and whether they are a bot or browser.

This data is very valuable for marketers, SEOs, and spammers. The problem with the data is that it identifies users with a unique id. Thus all searched from a particular user are related with this id. And with enough searches it can be possible to determine who the person is. Since AOL uses google as its search engine, this is essentually the same data that Google fought the goverment to keep it from them. Now it is all over the net. And people are finding all kinds of interesting info.

It is only a matter of time until someone releases a web interface to search and parse this data. I am sure google link spammers are already parsing this data to find the best keywords to spam. I would imagine that google will have an interesting response soon. And this is definitly going to hurt aol. I am glad that I am not using aol for anything other than aim, but it would not suprise me if I found my chats online soon.

Of course I have already downloaded the data, and though I don’t have much time with moving in two weeks, I will probably import the data in MYSQL and do a few queries. >:)

I have several ideas to extend the functionality of this tool, and I will work on them when I get time over the next few months. If you have any suggestions please let me know.

Honeybot which can be downloaded here is a Windows program that opens over 1200 TCP and UDP ports and simulates common services on them. It then captures all packet traffic to these ports and logs the packets and IP address. It is able to simulate some basic services by replying on certain ports. It is also able to capture worms and trojans by saving them to a folder. It is an easy to use program that is a good choice for getting your feet wet with honeypots.

First you will have to configure the host machine. You can put Honeybot on any Windows based host. For best results I would recommend that you run it on a dedicated box. By this I mean, don’t have anything else running on the same machine. I run it on windows XP in a virtual machine. You can use Virtual PC, or you could use its free brother, Virtual Server. Just download it from Microsoft and install your version of windows on it. I like using virtual server because it has much more advanced network options than virtual pc. You can run your honeypot on your internal network to alert you to affected machines on your network. However, you will probably get much more interesting results if you expose it to the internet. The best way to do that is to place the honeypot in a DMZ. This is the best method if you are running the honeypot from a home internet connection. You also want to run windows firewall on your machine, and make an exception for Honeybot.

If you are running your honeypot from a designated host, you will want to disable as many network services as possible. Running the command netstat -an will show you all the listening ports on your system. Also the program fport will show you the open ports and the process ID that is using it. There are a few ports you may need to disable from listening in Honeybot. You will probably want to disable port 162 (snmptrap) especially if you have a home router. Other ports you may need to disable are 67, 68 which are dns and dhcp.

After you have closed as many network ports as you can, you can start up HoneyBot. Just press the blue start button to start listening. Once it is running you can click on Debug (View, Debug) to see which ports Honeybot was unable to listen on because of the os. This will also show winsock errors too. You can also add or remove ports in the configure box, while honeybot is not running. Once it is started you should start seeing probes in a very short time.

I was very supprised by the very high amount of traffic was captured by Honeybot. After a day I had several thousand probes. The most popular probes were definitly windows messenger spam coming to ports 1024 – 1030. I also saw a lot of SQL server probes at 1433 and 1434. Honeybot also captured several worms too. I have run honeybot on both my home cable connection and with a static IP address on a T1 line. I received more scans and worms on the static ip address than with my cable.

You can also run a packet sniffer like Wireshark or Snort to get more detailed packet information with your honeypot.

Some example screenshots:

The Main screen.

An IIS Buffer overflow exploit attempt.

An attempt to run a Dabber worm.

A NetDevil trojan upload. It captured the binary file and I have figured out how to run it.

Outages
When I want to open up a document, I want to be able to access it right away. If the app goes down, I won’t be able to open my document and that will cause a loss of productivity. On the tradiditonal desktop the only time you have an outage is when your machine crashes or the app installation gets corrupted. You(or your IT department) are resonsible for keeping your machine running. If you are using an online application, you are still resonsible for keeping your machine running, but you also have to rely on the asp to keep their service running. Asps work hard to keep their application up at all times. I work for an asp, so I know how important it is to keep it up and running. Our company uses Salesforce for keeping track of our customers, and I have heard the complaints whenever salesforce goes down, or has other issues.

Bandwidth
Feature rich applications require a lot of bandwidth. With some applications, like Salesforce, email, calendars, etc, current bandwidth speeds are already adequate. When you use those applications you are typically working with small amounts of data stored in a database. Office apps like Writely and Google Spreadsheets use significantly more bandwidth. For instance, when you open a spreadsheet with Excel, Excel copies itself into memory and loads your spreadsheet. To load a spreadsheet from your computer into Google spreadsheet, the app has to download its files off Google’s servers and load into your computer. Then it has to load the document. And to save it to their servers it has to copy it across the internet. Obviously the bandwidth between your hard drive and memory is millions times faster then the pipe across the internet. For Google spreadsheets to have a chance at competing with Excel it will need to have all the features of Excel. This will make the app quite a bit bigger. Of course it only needs to copy the parts it needs when it needs it, but that will put more strain on your bandwidth.

Privacy
No big corporation is ever going to want their sensitive data stored on another corporation server. And the way these online apps work best is when the document that is being worked on is on the same server as the app. This is probably the biggest deterrent to the adoption of online apps.

Solutions
To solve the problem of bandwidth and outages, the app could cache itself on the users computer, thus making itself available during outages, and being able to load more features in the background while it works. This could also solve the privacy problem by allowing the app to open local files easier. But if you think about this approach, it is reinventing the wheel. The online app is now a client app because it is storing itself and running on the local computer. And we already have great client apps that do this. What I feel will happen is that server products will be developed to interoperate with client apps, and also provide an online interface to those apps. If you have every used Microsofts Outlook Web Access, you know that it works almost exactly like Outlook 2003. Eventually they should develop Word and Excel versions that would allow you to remotely work on your documents. This would be a great system for corporations.

In conclusion, I think that the current online office apps are a long way from becoming a threat to current client apps. As Microsoft said their features are old by over 10 years. I don’t completely understand the goal of these online apps. They are moving everything that has been on traditionally on the desktop to the server, despite the fact that computer hardware is getting faster all the time. There is obviously a cycle to software, as we are slowly starting to move back to software on the server, just like in the early days of computing with mainframes and terminals. Just now our software is on the other side of the internet.

The best program for packet capture and analysis is Ethereal. It captures packets and displays them in a nice GUI. It can also save the packets to a file and open and process captured packets files. It has the ability to process the packets by applying filters. For example, you could filter out all arp traffic, or only capture http. Ethereal also allows you to filter by TCP stream. It can display all the data portions of a packet in the stream that they came in. In this way, you could reconstruct an html page, or smtp email. However the purpose of this article is not to be a guide on Ethereal, but to show you how to arrange your network to sniff your internet connection and capture all packets coming and going across your internet pipe.

There are many reasons that you might have to want to sniff your internet connection, or even to capture and record all packets that are passing through. One reason is that it is a fascinating and great way to learn about networks and how packets flow through the network. Another reason could be to find and defeat a hacking attack or malware. You could also monitor your network to determine what users are doing and watch them. (like the nsa)

A typical Small Office/Home Office will be setup like this:

The internet comes in through the cable modem, and into the combination router, switch, and wireless access point. This is a pretty nice setup for a small network, because it combines all the network devices into one. However this is not a good setup for sniffing and data capture.

The main problem with sniffing on this network is the switch. In a traditional ethernet network with hubs, all packets flow to each port on the hub. This is called a collision domain. Switches are designed to break up collision domains. This breakup helps the network function much more efficeintly and drop much less packets. It also provides added security because all packets in the network are not able to flow past each ethernet adapter. However we cannot easily sniff the network if we can not see all the traffic. On some high end switches there is a management port which can be configured to mirror all traffic on a single port. This port can then be sniffed and monitored. But an easier way to monitor the small network shown above is with a hub as shown below:

Here a hub is placed in between the cable modem and the router. A monitoring computer can then be connected to the hub to sniff all internet traffic.You may think that this would defeat the purpose of a switched network and slow down your internet traffic. However a hub does not start dropping packets until greater than 50% of its bandwidth is used up. If you are using a 100mbs switched, then you would have to generate greater than 50mbps traffic. With a typical cable 5mbps internet connection, you will never even come close.

The only drawback to this setup is NAT. NAT (Network Address Translation) is a technology that the router uses to allow many hosts to share an internet connection which has only 1 IP address. This setup above will sniff everything outside your nat. So if you have multiple computers behind the nat you will not be able to tell which one is generating which traffic. (While doing some monitoring, I noticed that in this configuration, my sniffer was picking up lots of ARP and DHCP traffic from other cable users in my subnet) In order to sniff the internet traffic inside the NAT, you need one more device in a configuration like this:

In this configuration the Hub and monitoring computer are placed inbetween the router and a second switch. This allows all traffic headed to the router and then out the internet to be watched. The only drawback to this is that it requires another switch to be added. One way to do it is to get a second Router/Switch/Wireless ap and just disable the routing features. This is how I did it to monitor my home network. Larger networks are layed out in a similar fashon, with a switch connected to a router which goes out to the internet. There are many other ways to do this same thing. For larger networks, an ethernet tap can put onto the router port. This is a device that allows you to tap into the ethernet port and see all the packets on the wire. This is what would be used in higher bandwidth networks. But for small home networks, I think a hub is the easiest way to setup a sniffer to capture all the internet traffic.

Another approach would be to build a linux router using an extra computer. This would eliminate the need for a hub altogether. You could then use snort, or tcpdump to capture all the traffic. The major drawback to this method is that you would need to setup the router and maintain it. There are many good tutorials on the internet to build a linux router, however it is still difficult. The small home routers are easy to setup and use.

For a monitoring computer, you can use an extra computer lying around or you can use a computer on your current network. I added an extra nic to my computer, gave it a static ip address in a different subnet than my main network, and sniffed the data that passed by it. If it has an ip address that is in a different subnet than your current network, you don’t have to worry about your computer trying to use the nic for data transfer. For example, my main nic is: 192.168.5.50 with a subnet of 255.255.255.0, so I put the other nic into 10.0.0.1. I also gave it a blank default gateway. The os will not route traffic down the second NIC, because there is nowhere for it to go.

This setup is a great way to learn about packets and how they flow, and monitor your network for suspscious activity, or just to see what everyone is doing.

The first thing that I learned was that Dell support people will bug you until you fix your computer. A hard drive went bad in one of our production servers. So I called Dell Gold support (which thankfully has american techs.) to get a replacement. After a lot of discussion, the tech told me to run a firmware update which would fix the issue. So I had to explain to him that it was a production server, and to do the fix he wanted would require me to schedule downtime and then go in to the hosted environment on a Saturday and perform the fix. So finally I got him to send me a replacement drive. But even since I have explained to him that the server is in a hosted facility an hour away from my office, he still calls me everyday to find out if the drive worked. I hate calling Dell tech support. But I have to to get parts under warranty.

Another thing I learned was that biometric fingerprint scanners do not recognize your finger if you have a cut on it. To access the hosted facility where our production equipment is kept, I have to have my right index finger scanned. I had a bad paper cut on it last week, and the scanner wouldn’t pick it up. Fortunatly there was a security gaurd there who accepted my photo ID and let me in. Seems to me like that could be a flaw in biometrics.

Another lesson is that high transactional SQL databases should be built on a Fibre Channel san instead of an ISCSI san. We have been researching a san solution from EMC for our database for several months, and have been recently evaluating an Equallogic ISCSI system. It is a sweet system that is easy to setup and maintain and doesn’t perform well with sql server. They gave us a demo unit, which we were able to get running with our database in very little time. But after testing it out and comparing it to our current system, which uses the SCSI drives in the server, we found it to be slower than our server. They told us some special tweaks to do, but that didn’t make it any faster. After some discussions with some smart EMC engineers, we learned a bunch of things that explained it. This is definitly something to remember for the future, and something to keep an eye on in the industry.

The last thing that I learned was that big relevant new articles can be annoying. This has happened to me several times, but not as bad as last week. Slashdot discussed an article that claimed a huge security hole in a particular version of RealVNC. Since we used to use RealVNC on a regular basis, many people panicked. I had noticed the article several days before when it first came out on a different website, and took the time to verify that the one server we still use vnc on did not have that version. We were completely safe. Then Friday morning, my inbox was cluttered with emails from people asking if I had seen it, and would we get hacked. I had to answer numerous emails explaining that we were fine, we didn’t even use VNC anymore, and besides, we already had other security features (like hardware firewalls, and vpn) which would assure our security even if we had the vulnerable software. It is pretty annoying when well-meaning people, who have no idea how the system is set up, make a huge deal over something that I have already seen and looked into. But I am sure that is something that I will have to deal with for the rest of my IT career.

I figured it must be some virus or spyware, but multiple scans revealed nothing, and I keep a close eye on my computer too. So I tried IE7 and got the same result. When I tried to access the homepage from my home computer via my vnc connection, it came up just fine. So I rebooted my work pc. Same thing. I then tried it from another work computer(a brand new Dell laptop right out of the box no spyware there). And got the same capcha screen! So my conclusion is that google is blocking my IP address from the home page. Everytime I reopen my browser I have to reenter a capcha code. This is pretty annoying, since I open my browser a lot. If it doesn’t go away in the next day or two, I am definitly going to move my homepage to something else. Has this happened to anyone else?

Update:

I learned from some comments on Digg, that this is related to some Di Vinci Code Quest that Google is running from the personalized homepage.  I’m not sure why I was affected, but it seems that this has happened to a lot of people.  The Quest is ending soon, so it should soon return to normal.

A detailed Microsoft Knowledge base article on the Port Reporter can be found here.
The Port Reporter can be downloaded here.
The Port Reporter Parser can be downloaded here.

To install both of these tools, first download them. Then when you first run the setup you will have to extract the files to a temporary folder, and run the setup from there. Port Reporter is installed as a service, but its startup type is set to manual. It can be started by going into the services and clicking start.

The log files are stored by default in the c:\windows\system32\logfiles\portreporter folder. The tool makes three log files. One is an initial log file, that logs the ports, processes, and modules that are in use when the service starts. The next file logs when a port is used. It captures: date, time, protocol, local port, local IP address, remote port, remote IP address, PID, module, and user context for each port connection that is made. The last log file captures detailed information for each use of a port. The port reporter by default will start a new log when a file reaches 5mb in size.

I found that after running the service for a day that it stored about 40mb of log information. Of course I use Firefox, IE, IM, remote desktop, vnc, ssh, and plenty of different network stuff all day long, so I would expect the logs to be huge. I would not recommend using the Port Reporter all the time, but instead you should run it for a day to get a good idea of the different connections that you computer makes. Then when you need to log port use, perhaps to try to find a trojan, or another security problem, you know what should be normal.

The Port Reporter Parser is a great tool for digging through the log files. Instead of opening up the logs in notepad, this tool will neatly display the log in a grid, with sortable columns. It can analyze the data and display a wide variety of statistics. Double clicking on a record in the main grid will bring up its associated module information from the larger log.

In conclusion, I have not used this program for very long, but it logs a wealth of great information that would be very helpful for detecting attacks and security breaches. For example, the tool could be installed on users computers, and the logs analyzed to determine if the user has installed malware, or some unwanted programs on there computer. It would also be useful for logging port access on a server.