incoming port on the firewall could be opened in advance, or opened once the SIP
negotiation has ended and before the RTP streams are set up. There are several
phones with built-in support for UPnP, for example, the snom220 phone (which is
no longer available), although for phones other NAT traversal mechanisms seem to
be more popular these days.
An advantage of using UPnP is that there does not have to be a predefined well-
known port for every protocol. It allows for multiple simultanious connections for
the same program by different users. With dynamically allocated ports user A uses
different ports on the firewall than user B for the same protocol. Ports can be closed
again after usage by the program or device itself, so there should be no resource
hogging.
2 Universal Plug and Play protocol flaws
While UPnP is convenient from a user point of view – programs that need to dy-
namically have ports allocated or need special ports on the firewall to be forwarded
to them to work correctly can do this automatically – there is, unfortunately, a
price to pay. As it is defined in the current standard, UPnP has no default security
mechanism. There is add-on functionality which adds security but devices that im-
plement this functionality are very scarce, if they even exist beyond the prototype
stage.
With the current UPnP protocol there is an implicit trust relationship between all
UPnP capable devices on the same network. Every device is a peer and there is no
policy mechanism in place to check whether or not a device is allowed to make use
of a specific service.
A few simple scripts that implement only a small subset of commands that are used
in UPnP are enough in certain situations to make it possible to expose machines
and services on an internal network to the outside world. This is done by abusing
a device that implements the UPnP Internet Gateway Device profile and forward
ports on the outside interface of the Internet Gateway Device to machines on the
inside network. This makes the internal machine accessible for everyone on the
outside network, for example the Internet. Many ADSL routers and wireless access
points on the market nowadays implement this particular profile and of those devices
many are, in various ways, vulnerable to various “attacks”.
The UPnP Internet Gateway Device specifications specifically mention that it should
be possible to forward ports to internal multicast and broadcast addresses, so de-
vices can share broadcast/multicast streams, for example a TV stream. The benefit
for the sender and receiver is that only one stream has to be sent to the gateway,
which will resend it to the LAN so it can be shared between machines on the LAN,
saving bandwidth. But forwarding ports to broadcast addresses also opens up a
whole new range of attacks. To name two possible targets: the NetBIOS Naming
Service used by Windows network file sharing and the Internet Printing Protocol,
used by many printers and CUPS, both use broadcasting. It is trivial to announce
fake printers on the network and possibly divert printing traffic to off site printers.
Opening and forwarding ports in firewalls via UPnP poses a serious threat. While
at first this might seem to only affect home users and not businesses – no enterprise
range products seem to support UPnP – I tend to think otherwise. It could very
well affect business users as well, for a number of reasons:
• Many (small) businesses are connected via normal “consumer grade” ADSL
lines and have the same ADSL modem as normal home users. For a long time
Kommentare zu diesen Handbüchern