Before we address the question, let's discuss how UDP port scanning is typically done.
When a host receives a UDP packet, what is supposed to happen is that if the host isn't listening on that port, it should reply with a ICMPPort Unreachable (ICMPType 3, Code 3). If it is listening on that port, the packet contents are fed to the listening application and processed. If the application does not understand the packet contents, it might reply with an error, but most likely will drop the packet and not reply at all.
If there is any kind of a firewall involved, either on the host itself or in the network path, then quite often no reply at all will be received for the sent packet.
So an open port and a port protected by a firewall will often look the same to a scanner. This can be a real problem when scanning UDP ports, as ports listening with a running service will look exactly like firewalled ports, which of course do not have a service available to the scanning station.
What UDP Protocol Awareness brings is a better payload. With protocol awareness, a scan of the UDPDNS port for instance (udp/53), might be a an actual dns request. A scan of an NTP (network time protocol) port could be an NTP timestamp or time request. The application receives a valid packet, and if there is a listening port, a valid response is sent back to the scanner, and the scanner can now know for certain that this port is open!
To illustrate - first, let's scan an NTP (Network Time Protocol) server's NTP port with an older version of Nmap (5.0). This behaviour is typical of most port sc
C: nmap -sU -p123 192.168.122.254
Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-28 13:17 Eastern Standard Time
Interesting ports on 192.168.122.254:
PORT STATE SERVICE
123/udp open|filtered ntp
MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)
Nmap done: 1 IP address (1 host up) scanned in 1.91 seconds
As you can see, the port shows as open/filtered. From the packet trace below, you can see that an emtpy packet is sent to udp/123, no valid NTP data is contained, and the NTP server simply drops the packet. There really is an NTPserver running, but there's no way to tell for sure using this method of scanning.
Now let's run the same scan with Nmap 5.2, which has UDPprotocol awareness.
C:nmap -sU -p 123 192.168.122.254
Starting Nmap 5.20 ( http://nmap.org ) at 2010-01-21 22:15 Eastern Standard Time
Nmap scan report for 192.168.122.254
Host is up (0.0019s latency).
PORT STATE SERVICE
123/udp open ntp
MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)
Nmap done: 1 IP address (1 host up) scanned in 6.88 seconds
The difference is immediately apparent, the port now has a state of open, instead of open/filtered. Let's take a look at the packet and see exactly why ..
As you can see, Nmap is sending an actual NTP client timestamp of the NTP server, and it gets an NTP server response back. This identifies both the fact that the host is actually listening on that port, as well as the fact that it's an actual NTP service that's listening.
Currently NMAP 5.21 supports protocol specific payloads for:
udp/1645 and udp/1812 RADIUS
This is an exciting development, allowing us to scan these particular ports with a LOT more accuracy than previously possible. Again, Fyodor and the NMAPcrew have replaced a number of other tools simply by adding some new features to NMAP - great job!
=============== Rob VandenBrink, Metafore =================
In recent years, we've seen increased energy put into web extensibility platforms. These platforms let distributed developers collaborate to produce new kinds of interactive features on websites and in the web browser itself. Because these platforms frequently enable data-sharing between multiple distinct organizations, and often sit between two completely different security domains (desktop vs. web), the security and privacy issues that arise are complex and interesting. This post explores some of that complexity: both the current state of platforms that extend the web and their associated security challenges.
Plugins, Extensions, and Mashups: A Primer
The extension platforms of the web today exist at every level of the technology stack. First there are mashup platforms, which include Facebook Apps, Google Gadgets, and YAP Apps, built on Yahoo!'s Application Platform. All these platforms are abstractions that allow developers to embed content within a host site. Often this content has a level of dynamism and interactivity that exceeds what is expected of "content" — so they're called "Applications" or "Gadgets."
A deeper type of extensibility occurs in web replacement technologies. Examples include JavaFX, Adobe Flash, Microsoft Silverlight, and Google Chrome Frame1. These technologies leverage exisiting hooks in browsers to replace native rendering and scripting technologies from the browser vendors with new environments that claim to offer a variety of benefits.
The existence of both replacement technologies and augmentation technologies for the web is made possible by the browser vendors themselves, who generally expose two different ways of extending the browser.
Browser plugins were originally intended to allow 3rd parties to add support to the browser so as to handle new types of content. They have since evolved into a rich means of embedding scriptable code into browsers, code that may (optionally) render in the browser's content area. (Microsoft calls these plugins Content Extensions, while other browser vendors have converged on the NPAPI architecture). A second, much more fragmented means of extending modern browsers is to write a browser extension (referred to as a "Browser Helper Object" by our friends in Redmond). Extensions typically have browser lifetime, as opposed to page lifetime. They also have programmatic access to manipulate the user interface of the browser.
Sandboxing vs. Code Review
In designing an extension system where developers contribute code, there's a key upfront decision that has a very deep effect on the platform — To what extent should plugins be trusted? Should plugin authors be forced to attain the approval of some body of reviewers, or do we instead rely on a software sandbox to mitigate the potential harm that could be done by untrusted code from unknown authors (and hence relax the review requirement)? The former approach can minimize upfront investment in platform development, while the latter can reduce delays in publishing 3rd party code.
In addition to increasing complexity, the sandbox-based approach constrains the creativity of developers who use the platform. The universe of what is possible is pre-defined by the platform authors, which is contrary to the idea of an extension system. Thanks to Atul Varma's recent overview of JetPack development, I now can identify this tension as Jonathan Zittrain's "Generative Dilemma".
At first glance, the platform developer might feel stuck with a binary decision between generativity vs. self service (the ability of plugin authors to publish immediately without oversight or review). A little more thought, however, reveals that in reality there's a spectrum with several interesting intermediate choices. The first hybrid to consider: a sandbox with a set of additional capabilities or permissions that may be requested by code running therein.
Building a Capable Sandbox
In many ways, browser extensions can be considered conceptual peers of the browser: They share direct access to the end user and to the resources of the machine within which they run. Additionally, given the wide target audience of modern extension systems, developers with widely varied levels of experience and grasp of security issues are empowered to author and quickly publish extensions. Providing extensions with system access to permit generativity creates a tension with the requirement that extensions run in a locked-down environment to preserve reviewless publishing and prevent accidental or malicious end-user compromise. We seem to be converging on a capability-based security model, where sandboxed code may explicitly or implicitly3 request enhanced "capabilities" or "permissions." Several of the projects mentioned here have mechanisms which allow an extension to express its required permissions:
- Chrome extensions require explicit expression of capabilities (or "permissions") in a manifest.
- In JetPack, it may eventually be possible to automatically determine the capabilities required by a given JetPack, based on the dependency graph of "superpowers" it uses (see below)
- In BrowserPlus, as in Chrome, permissions are explicitly stated in a manifest.
As different projects attempt to build capabilities-based systems, an interesting opportunity for collaboration arises. Users are going to learn to some extent what "writing to a temporary location on your disk" means. They will also learn more about "using location," and maybe also about "capturing video using a webcam." As new platforms emerge that ask the user more and more questions, it would be beneficial if these platforms shared similar capability lists, perhaps even a similar language or visual vocabulary.
From Capabilities to Meaningful Decisions
While we all seem to agree that an enumerable list of capabilities is a prerequisite to intelligent interface design, it's not clear that we've yet determined how to consolidate this information in a user interface that allows meaningful decisions. This is not for a lack of thought: Over a year ago, Dion Almaer suggested a "nuanced question" combined with good post-decision feedback. Since then, he's summarized ideas from Mozilla folks regarding a "layer [of] social trust on top of the technical security." More recently, there's been some initial discussion of a stop-light style representation of risk, which if correctly applied could distill a complex decision into a series of simple questions, (for example, Do you trust yahoo.com?) which iteratively becomes more ominous as the stakes (and the implied risk) get higher.
Better Responses Through Fewer Questions
One approach employed by BrowserPlus attempts to minimize explicit prompting and leverages mechanisms of implicit consent instead 4 by carefully crafting the API between trusted and untrusted code. One such example is file selection, where the act of navigating an operating system-supplied file picker dialog indicates implicitly that the site should be allowed to read the contents of selected file(s). Another example where this technique might be applied involves webcam access. Rather than asking the user if a site may use the webcam, pop up a window displaying the view from the webcam, allowing the user to capture a picture inside that frame (outside the control of the page), and finally after capturing "share" the capture with the page.
Architecting APIs and UI in this way can somewhat alleviate the need for explicit up-front questions and allow in-context kinesthetic decision making to occur. This approach is not without fault however, as it can also confine the freedom of UI designers. Eliminating needless questions assumes that only by asking fewer questions of higher quality, will we truly empower the user to make meaningful decisions.
Permission Prompts in Practice
In addition to ongoing thought experiments in me