Post by dlevere on Mar 1, 2015 5:58:13 GMT -4
Written by Stephen Tomkinson
In today’s (28 February) closing keynote talk at the Abertay Ethical Hacking Society’s Secuir-Tay conference I discussed how it was possible to build a malicious Blu-ray disc.
By combining different vulnerabilities in Blu-ray players we have built a single disc which will detect the type of player it’s being played on and launch a platform specific executable from the disc before continuing on to play the disc’s video to avoid raising suspicion. These executables could be used by an attacker to provide a tunnel into the target network or to exfiltrate sensitive files, for example.
Background
The Blu-ray specification not only provides superior video quality over the previous generation of DVD's, it also supports a richer interactive user experience, with dynamic menus, embedded games and access to the latest trailers downloaded from the Internet. These rich features are built using BD-J, a variant of Java which allows disc authors to build a range of user interfaces and embedded applications, structured into Xlets. Xlets are analogous to the web’s Applets which have long been a source of security concerns.
Xlets run in a Java Virtual Machine secured using the standard security policy mechanisms which are enforced by a SecurityManager class. The exact operations granted to a disc differ from player to player, but generally the security policy will prevent a disc from accessing anything outside of its virtual file system and ensure that a disc is not interacting directly with the underlying operating system.
There is a range of Blu-ray device specifications including BD-Live which is the 2.0 player profile. This profile is the most interesting for us as it states the drive has an Internet connection (WI-FI or Wired) and 1 Gb of local storage, typically implemented in physical players via a user-supplied USB flash drive.
Anyway as stated I set out to discover and exploit weakness which could yield a credible threat scenario against both software and hardware Blu-ray players… and I succeeded!
Vulnerability 1 - Windows - Cyberlink PowerDVD
Blu-rays have been supported by PowerDVD since 2009 and the security mechanisms haven’t really changed since that early release. PowerDVD comes with a range of additional Java classes which provide functionality internal to the player, but which are still callable by Xlets on the disc. One of these is the CUtil class which provides access to functions implemented in native code which fall outside of the SecurityManager’s control. These functions allow the player to obtain the current licence details, the ability to pop-up windows confirmation dialogs and most usefully for us an ability to read arbitrary files from the disc.
Additionally Cyberlink have written their own SecurityManager for limiting the functionality of an Xlet. As this is written in Java we can decompile the bytecode and take a closer look:
The checkPermission method should evaluate the given permission and throw a SecurityException if the Xlet has not been granted permission for that requested action. However, we see that at the beginning of the method there are a number of “short cuts” which will instantly return out of the method without any security checks having been performed.
The first check (and the one with the most interesting name) is a call to “isIgnoreSecurity()”, unfortunately however this returns a static final value that is designed to be set by CyberLink developers at compile time.
The next check uses the CUtil class we mentioned previously, but the third check looks in a list of Thread objects for the current Thread. If we can manipulate that list and embed our current thread into it, then the SecuirtyManager will be effectively disabled. Looking elsewhere in the SecurityManager we find a method which does exactly that:
By first calling the enterMiddleWare() method we’re now free to call previously inaccessible methods, such as Runtime.exec() to launch arbitrary executables.
As Blu-ray discs will auto-play on systems with PowerDVD installed, we now have a mechanism to bypass Window’s auto-run mitigations.
Vulnerability 2 - Physical Blu-ray Players
There’s already a wealth of published work on “rooting” blu-ray players, and the work by Malcom Stagg (www.malcolmstagg.com/bdp-s390.html) provided an initial foothold for this work. The exploit provided by that site makes use of a debug line left in the shell script used to launch the web browser.
The debug line tries to launch a library from an attached USB stick, which can be substituted for a library containing attacker controlled code. However, we can’t easily socially engineer a victim to insert a USB stick then launch the web browser, so the aim was to find a way of performing a similar effect from an innocent looking blu-ray disc.
Having used the previous exploit to get a shell on the player we can start looking at what other avenues are available. Being an embedded system, it’s typically a fairly minimal system - a version of Linux with most command line functionality provided by BusyBox.
Looking at the listening network services we see there are two services which are bound to localhost (the “net inf” daemon and the “ipc” daemon):
These two daemons aren’t accessible to external network users, but as our Xlets are executing on the same system they will have network access to them. Handily these two daemons also have equivalent client applications on the player named ipcc and netinfc. From these we can determine that the IPC daemon includes an “execute” function which will run a command provided over the network. As everything on the player runs as root, this gives us a way in if we can emulate the client.
For this, rather than reverse engineering the IPC protocol, we can simply use the tcpdump command (handily included on the player) to dump the TCP stream for a valid execute request of something on the disc from the IPC client application. From this PCAP dump we can extract the TCP stream and write a Java Xlet which replays the same byte stream to the daemon. This gives us a working exploit to launch arbitrary executables on the disc from the Blu-ray’s supposedly limited environment.
Putting it all together
To combine these two exploits into a single disc we need to detect the player we’re running on. Under PowerDVD we can request the Java system property of “http.agent” which will return “CyberLink PowerDVD”.
However, a similar request on our physical player results in a SecurityException. In doing so the exception includes a stacktrace back down to the vendor specific classes. We can simply catch the exception and look through the stacktrace to determine the player we’re on.
Once our exploits have launched we can continue to run additional BDJ code, in our case we use this to start a video on the disc to avoid raising suspicion.
Remediation
We are working with the vendors to resolve these issues with varying degrees of success, but in the meantime there are some things you can do to reduce your exposure to these vulnerabilities:
In today’s (28 February) closing keynote talk at the Abertay Ethical Hacking Society’s Secuir-Tay conference I discussed how it was possible to build a malicious Blu-ray disc.
By combining different vulnerabilities in Blu-ray players we have built a single disc which will detect the type of player it’s being played on and launch a platform specific executable from the disc before continuing on to play the disc’s video to avoid raising suspicion. These executables could be used by an attacker to provide a tunnel into the target network or to exfiltrate sensitive files, for example.
Background
The Blu-ray specification not only provides superior video quality over the previous generation of DVD's, it also supports a richer interactive user experience, with dynamic menus, embedded games and access to the latest trailers downloaded from the Internet. These rich features are built using BD-J, a variant of Java which allows disc authors to build a range of user interfaces and embedded applications, structured into Xlets. Xlets are analogous to the web’s Applets which have long been a source of security concerns.
Xlets run in a Java Virtual Machine secured using the standard security policy mechanisms which are enforced by a SecurityManager class. The exact operations granted to a disc differ from player to player, but generally the security policy will prevent a disc from accessing anything outside of its virtual file system and ensure that a disc is not interacting directly with the underlying operating system.
There is a range of Blu-ray device specifications including BD-Live which is the 2.0 player profile. This profile is the most interesting for us as it states the drive has an Internet connection (WI-FI or Wired) and 1 Gb of local storage, typically implemented in physical players via a user-supplied USB flash drive.
Anyway as stated I set out to discover and exploit weakness which could yield a credible threat scenario against both software and hardware Blu-ray players… and I succeeded!
Vulnerability 1 - Windows - Cyberlink PowerDVD
Blu-rays have been supported by PowerDVD since 2009 and the security mechanisms haven’t really changed since that early release. PowerDVD comes with a range of additional Java classes which provide functionality internal to the player, but which are still callable by Xlets on the disc. One of these is the CUtil class which provides access to functions implemented in native code which fall outside of the SecurityManager’s control. These functions allow the player to obtain the current licence details, the ability to pop-up windows confirmation dialogs and most usefully for us an ability to read arbitrary files from the disc.
Additionally Cyberlink have written their own SecurityManager for limiting the functionality of an Xlet. As this is written in Java we can decompile the bytecode and take a closer look:
The checkPermission method should evaluate the given permission and throw a SecurityException if the Xlet has not been granted permission for that requested action. However, we see that at the beginning of the method there are a number of “short cuts” which will instantly return out of the method without any security checks having been performed.
The first check (and the one with the most interesting name) is a call to “isIgnoreSecurity()”, unfortunately however this returns a static final value that is designed to be set by CyberLink developers at compile time.
The next check uses the CUtil class we mentioned previously, but the third check looks in a list of Thread objects for the current Thread. If we can manipulate that list and embed our current thread into it, then the SecuirtyManager will be effectively disabled. Looking elsewhere in the SecurityManager we find a method which does exactly that:
By first calling the enterMiddleWare() method we’re now free to call previously inaccessible methods, such as Runtime.exec() to launch arbitrary executables.
As Blu-ray discs will auto-play on systems with PowerDVD installed, we now have a mechanism to bypass Window’s auto-run mitigations.
Vulnerability 2 - Physical Blu-ray Players
There’s already a wealth of published work on “rooting” blu-ray players, and the work by Malcom Stagg (www.malcolmstagg.com/bdp-s390.html) provided an initial foothold for this work. The exploit provided by that site makes use of a debug line left in the shell script used to launch the web browser.
The debug line tries to launch a library from an attached USB stick, which can be substituted for a library containing attacker controlled code. However, we can’t easily socially engineer a victim to insert a USB stick then launch the web browser, so the aim was to find a way of performing a similar effect from an innocent looking blu-ray disc.
Having used the previous exploit to get a shell on the player we can start looking at what other avenues are available. Being an embedded system, it’s typically a fairly minimal system - a version of Linux with most command line functionality provided by BusyBox.
Looking at the listening network services we see there are two services which are bound to localhost (the “net inf” daemon and the “ipc” daemon):
~ # netstat –ltpnActive Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.1.105:54400 0.0.0.0:* LISTEN 708/bdpprog
tcp 0 0 127.0.0.1:58530 0.0.0.0:* LISTEN 705/ipcd
tcp 0 0 192.168.1.105:52323 0.0.0.0:* LISTEN 708/bdpprog
tcp 0 0 127.0.0.1:55050 0.0.0.0:* LISTEN 704/netinfd
tcp 0 0 192.168.1.105:22222 0.0.0.0:* LISTEN 708/bdpprog
tcp 0 0 192.168.1.105:50001 0.0.0.0:* LISTEN 898/upnpunr
tcp 0 0 0.0.0.0:50002 0.0.0.0:* LISTEN 708/bdpprog
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN 1099/telnetdThese two daemons aren’t accessible to external network users, but as our Xlets are executing on the same system they will have network access to them. Handily these two daemons also have equivalent client applications on the player named ipcc and netinfc. From these we can determine that the IPC daemon includes an “execute” function which will run a command provided over the network. As everything on the player runs as root, this gives us a way in if we can emulate the client.
For this, rather than reverse engineering the IPC protocol, we can simply use the tcpdump command (handily included on the player) to dump the TCP stream for a valid execute request of something on the disc from the IPC client application. From this PCAP dump we can extract the TCP stream and write a Java Xlet which replays the same byte stream to the daemon. This gives us a working exploit to launch arbitrary executables on the disc from the Blu-ray’s supposedly limited environment.
Putting it all together
To combine these two exploits into a single disc we need to detect the player we’re running on. Under PowerDVD we can request the Java system property of “http.agent” which will return “CyberLink PowerDVD”.
However, a similar request on our physical player results in a SecurityException. In doing so the exception includes a stacktrace back down to the vendor specific classes. We can simply catch the exception and look through the stacktrace to determine the player we’re on.
Once our exploits have launched we can continue to run additional BDJ code, in our case we use this to start a video on the disc to avoid raising suspicion.
Remediation
We are working with the vendors to resolve these issues with varying degrees of success, but in the meantime there are some things you can do to reduce your exposure to these vulnerabilities:
[*]Don’t use any removable media from unconfirmed origins.
[*]Use the AutoPlay section of control panel to stop discs playing as soon as they’re inserted:
[*]Many physical players have settings to prevent discs from accessing the Internet for privacy reasons. In practice this can disable all BDJ network access including access to localhost which will effectively block the second vulnerability.
[*]Consider if network connectivity is essential for your hardware Blu-ray player usage and if not do not connect it to network/Internet.