Cooking With Technology

When targeting an individual host, the first step most attackers take is to scan and probe the system in order to gather information about it. Most generally this means scanning the system with nmap, determining open ports to find what the machine is serving, identifying the version of each service available, and then attacking the vulnerable ones.

The game changes when the attacks are automated, such as when they originate from a worm. Worms rely on only a select number of attack vectors, and without being artificially intelligent, are not capable of identifying and attacking new vulnerabilities. This means that when a worm scans, it is probing machines to determine whether they susceptible to a specific set of attacks.

But scanning is hard. It is slow. With the 2^32 addresses that exist within the IPV4 space alone, scanning with only one host can take an incredible amount of time. IPV6 is even worse. With a 64 bit address space and thus 2^64 addresses, the conventional means of scanning are extremely inefficient - a fact the IETF is well aware of. So now attackers and worm writers are faced with a new problem: how can we make this process faster?

I have an idea for a solution, and a proof-of-concept in the works to demonstrate it. Why not use IANA themselves to help? My solution involves not increasing the speed of the actual scanning, but by increasing the intelligence with which hosts are chosen to be scanned. The allocated IP blocks are published by IANA and made publicly available. Take a look at it: 41 /8 blocks are unallocated and 36 are reserved, dropping our problem space down by 77 /8 blocks. If the scanner was particularly stupid and was previously scanning the full range of IPs, this would result in 1,296,908,325 less addresses to scan, increasing our theoretical speed for a complete scan by 30%. When you are talking performance in computer science, a 30% speed increase is a big deal, and to a worm author, that relates directly to faster propagation.

The improvements are even more drastic for IPV6. Blocks of IPs cost money, so they won’t be snatched up immediately. Scanning only the allocated blocks of IPs means that the 64 bit problem space becomes less ominous. If we consider that the transition to IPV6 will occur when most addresses in the IPV4 space are used, then intelligently scanning only those addresses results in a 1.84×10^19 reduction in hosts to scan.

The long and short of it is that scanning isn’t likely to get much faster, but intelligently choosing what is scanned can produce real results that only lose effectiveness as the number of actual hosts increases. I’ll post a POC in some time that will showcase this methodology, so keep your eyes locked ;)

Ajax and the fancy “Web 2.0″ trend are causing all sorts of web applications to pop up. The most familiar examples are the many services that google is making available, and gmail especially. Gmail is, for many people, a desktop mail client replacement. And why not? It contains the functionality that one would expect in a desktop application - viewing mail, composing new messages, and creating filters to sort incoming articles of text. It is a nicely packaged application with a decent interface. It does however have one major flaw: it doesn’t control the application used to view it.

We aren’t talking cross-browser compatibility problems or the folks using text-only browsers such as lynx. The issue that spans all browsers is that they contain navigation buttons. Back, forward, and refresh, these are all elements that can make the execution of a web application occur in an order unintended by the developer. From a software engineering perspective, this presents new problems previously not encountered when designing and developing software. From a programmer’s perspective, this introduces new complexities in the code because the state of execution can change at any time. Additionally, the code monkeys have to handle sessions that may not terminate properly, half-open connections, and navigation issues that will creep up from the user jumping around your application.

A solution to this problem that hasn’t been completely explored is to combine the benefits of desktop applications with the advantages of web applications. Desktop applications are self contained, meaning the interface to that application is completely controlled by the developer. The state of execution again becomes reliable, hooks into the process’ termination can execute cleanup code, and even cross-browser issues may be ignored. Web applications need only a web browser to load them. By embedding the rendering engine of your web browser of choice (as far as I know, Mozilla’s, Internet Explorer’s, and Safari’s rendering engines can be embedded) in an application, the only thing the user see is exactly what you want them to.

The only complication that arises from this situation is the initial distribution of your application. But because the desktop ‘launcher’ application is going to be nothing more than a frame with some logic to handle any initializing or cleanup you wish to do, it is going to be a very small download. And if you are a company that produces a lot of applications, your launcher can be modified easily to support all of them from a single application. Attractive, isn’t it? This also allows for targeting an older demographic that has been slow to catch on to web trends by deploying to them something familiar: an icon on the desktop to be click clicked.

Now for the business stuff. If you already have a solid web application that conquers the navigation and other issues that plague them, you are one step away from redeploying your application to a new market. And while speaking of markets (and thus money), if your application is driven by advertisements, controlling the platform means that the user won’t be able to block your ads. Physical distribution also becomes possible at this point. Your launcher could be bundled with an installer and distributed by CD to be sold on the shelves in brick and mortar establishments. Now your application will be reaching all corners of the current software markets, bridging gaps of technical understanding, and all without your users blocking the media you want them to see. If you are just starting development with this paradigm in mind, you are going to save development time which can be refocused on implementing features for your users. The result is a better web application that is available to everyone.

The benefits gained don’t take a lot of convincing to sell. Simplified development, a cleaner application, and reaching broader markets all from changing the means of distribution?

Money. 

If only educators were required to see this (~20 minute) TED presentation before being given the minds of our students. Sir Ken Robinson focuses on creativity in the arts throughout this talk, but any programmer knows the benefit of being able to think creatively when writing code.

Sir Ken Robinson - Do Schools Kill Creativity? (via TED)

Being one of the millions of Facebook users, I was pretty happy to hear that they opened up a restricted API for those interested in developing applications that interact with it. I found myself with a few hours one weekend, and came up with a simple application using the API to check if you have any Facebook messages. Normally I wouldn’t post a task like this because it was rather trivial, but I decided to anyway because I did it in what I think is a cool way.

First, the actual code to check the messages is written in PHP and hosted on my web server. It will refresh every five seconds and check if you have new messages, displaying an icon to open a new browser window to check the messages. It can be seen here. Notice that I’m much better at writing code than designing interfaces ;) If you are interested, I’m using the official Facebook PHP5 client as a base for the web portion of the application. Full source is here.

The second part of the final application is a program written in C#. It is a small window that fits the dimensions of the used part of that page, using the maximize button to switch between the messages pane and the login pane when required. Internet Explorer is embedded in the application to do the rendering, but is stripped down in terms of navigation and context menu usage. It is still possible to navigate outside of the intended area, but this is a limitation on how Facebook designed it’s login page. The source of the application can be obtained here (zip format) and the executable itself can be obtained here (zip format). The source was built using Visual Studio 2005 - you should be able to build it without complication.

But enough of the program specifics.

Web applications are nice for developers. They develop the application in one place, and the changes are immediate to all users of the software. Feature and security updates are completely transparent, and best of all, the users don’t have to worry about them. Developer liability goes down because users aren’t running around with out of date and possibly insecure versions of their application, and users are happy because they always have the latest version of the software - a win-win situation. Even better, developers don’t have to concern themselves with deciding which operating systems or platforms to develop their primary application for because it is all online. This opens the application to a huge market of people. On the down side, web applications aren’t as accessible to as many people. Most people understand how to click an icon and use a program, it takes a higher level of acceptance to understand, for example, that their web browser could be used to replace Excel. The obvious solution to this problem is what is exemplified in the small application I’ve written to do an overall meaningless task. Embedding a browser in an application allows developers to have a binary executable that the masses are comfortable with that navigates solely to a web application that the developers prefer to maintain. With proper design, the web application can be made to always look good within the client executable, and following some rules of development will prevent people escaping to other sites from within the application. Everyone is happy.

I might expand on the idea later. There are other ways this would be useful, and some other ideas I’d like to tack to the list of supporting reasons for this concept. We’ll see :) It should also be noted that these thoughts originally came out of talking with the very intelligent Mike Manzano in my time working as his intern at Topia Technologies. See Mike, I *was* listening!