Thursday, November 11, 2010
Ubuntu, Apache, and Other Gotchas
Then there's GCC 4.4. They cleaned up some include headers. When I was compiling a Qt4 program whose source I downloaded from the Internet, I got an "error: ISO C++ forbids declaration of 'uint8_t' with no type". I assumed that the problem was with missing Qt4 headers, such as QtNetwork, but adding an #include "<"QtNetwork">" header did not solve the problem. I found the solution in Debian bug report 505690. One has to add #include "<"stdint.h">" (header for the Standard C library) to the Qt4 code for it to compile.
Then there's telnet. I was trying to modify the telnet source code to evade a match with the nmap-service-probes database (e.g. grep "Linux telnetd" /usr/share/nmap/nmap-service-probes). The nmap database is matching telnet byte commands and not strings, so it's not immediately obvious how to fool nmap without delving into the telnet protocol. It turns out that you don't need to modify the telnet source code to fool nmap at all. You just need to change a variable definition in the /usr/include/arpa/telnet.h header file on the system you are compiling the source code on. Really obvious, huh! (NOT!) Once you have the binary, you can either change the definition back to what it was or install the binary on another system. What I did would result in my version of telnet being unable to fully communicate with normal versions of the program, but since nmap is matching telnet byte commands, one either has to alter a byte command's number or alter the sequence of commands. It's easier to alter the numeric code to fool nmap if you are building a honeypot. The system will be used as a trap, not for production purposes. So, if you need to run telnet on a Linux honeypot and you don't want nmap screaming "Linux" at the attacker during the enumeration phase, you need to change the X Display Location (TELOPT_XDISPLOC) byte command number in the following line
#define TELOPT_XDISPLOC 35 /* X Display Location */
Redefining TELOPT_XDISPLAYLOC will likely screw up telnet connections from a X11 display terminal, but you don't want attackers or anyone else to be using telnet anyway. It's okay for them to "try" to use it though. You'll also want to change the /etc/issue.net banner to something else or your header alteration will be for naught. By the way, always perform an apt-get build-dep source "program" before you perform the apt-get -b source "program" on a Debian based system or something is liable to break during the compile.
Then there's Java. I had to install a Java version of TightVNC on the honeypot. When I tried to connect via the Internet Explorer browser, I got this error:
load: class VncViewer.class not found.
blah, blah, blah...
It's a rather common error. If you have this line:
Caused by: java.io.IOException: open HTTP connection failed, or
Caused by: java.net.ConnectException: Network is unreachable,
the cause is due to an IPv6 network setting in Linux. I first found the solution here, but the same documented workaround is detailed in bug 6342561. Unfortunately, that was not the error I got. The error I had was:
Caused by: java.io.IOException: VncViewer.class not found.
I had to copy the missing class to the root of the virtual host directory. Then the error changed to OptionsFrame.class not found. So, I copied all of the TightVNC class files (and one jar file) from /usr/share/tightvnc-java/ to the virtual host directory to be safe. Then, TightVNC worked. This was odd because if you install the TightVNC files directly from the binary archive into the virtual host directory, the class files are found in a classes subdirectory, i.e. /var/www/virtual-domain/classes. Since the default install is likely to fail with TightVNC in a virtual host directory, I wonder what the "real" default install is.