Multiple Vulnerabilities in Xerver 4.32
Sorry for the downtime everyone! I've been quite busy this summer, but I'm back now, and I've got vulnerabilities for everybody! Well, everybody who's looking for vulnerabilities in Xerver web server at least.
Xerver is a web server written in Java and appears to be targeted at Windows users (although it is cross platform). Xerver is apparently the first result for "free web server" on Google, even edging out Apache. How it got up there, I will never know, but it makes me doubt Google's search gnomes' abilities. With ~125,000 downloads on Cnet though, I guess it isn't completely obscure.
I spent a couple of my slower evenings looking over the code, and I came across a number of serious vulnerabilities in Xerver. These vulnerabilities include insecure default settings, denial of service, http authentication bypass, source disclosure, very minor directory transversal, and limited (for now) remote code execution. These are in addition to a number of unpatched vulnerabilities already discovered by other researchers, the most serious being an authentication bypass on the configuration pages (remote configuration disabled by default), a different source disclosure vulnerability, and an HTTP response splitting attack.
This post will document the issues I found, as well as some fixes. For the impatient, you can just skip my explanations and grab my PoC Metasploit module for the authentication bypass and the source disclosure. Note that I have not yet released the remote code execution PoC, for reasons explained at the end of this post.
I contacted Xerver's lead developer, Omid Rouhani, as soon as I found these issues, and received an email back from him requesting a patch. I provided a patch that fixes the issues that I found that are not design-related, but he has yet to publish the fixes (it's been over 2 weeks now). I feel that it is best that users know the vulnerabilities exist (as they are made much worse by insecure configurations) so that they can take appropriate actions. Concerned users can grab my patched source here. The patched version addresses the HTTP authentication bypass, source disclosure, and HTTP response splitting vulnerabilities.
Insecure Default Settings
A large majority of users will, without fail, simply use the default application settings, so it is common practice to try and make these settings as secure as possible, and warn users if they try to make them less so. Xerver, however, seems to have gone out of its way to have the most insecure default settings possible. That is the only explanation for some of the atrocious configuration choices I found. These issues were present in both the initial, clean install settings and in the default settings chosen by the provided setup wizard.
- Directory listings are enabled by default. This is not *generally* a huge problem as long as everything else is securely set up.
- The default root directory is C:\ . This means that unauthenticated users have access to everything on the drive that the user who started the Xerver process does (most likely an administrator), meaning configuration files, private user data, and pretty much anything else you'd want become world accessible. And to make things worse, combined with directory listings, it's as easy as navigating the file system to the file you want.
- The configuration page has no password protection. It is not remotely available by default, but when configured this way it represents a significant vulnerability (that would allow an attacker to get code execution).
Denial of Service
You know that when one of the first comments in the code that you read says "If someone creates 150 connections to this server, no one else will be able to connect to us anymore," that DoS is going to be a bad problem. I documented three that I found right away, but there are definitely more.
- Open 150 connections very quickly. Easy enough.
- Inject a null byte into the appropriate place to convince the server to access a file that "exists" but doesn't actually exist. Causes the thread to hang indefinitely, making the DoS easier.
- Run an application that doesn't quit without user input, which hangs the thread as well for 5 minutes.
The reason this works is a bug in the code at NewConnection->accessToFolderIsOK. Xerver compares the folder being requested to it's internal list of protected folders by looping through each, and comparing the two strings. If they're equal, then the folder requires password protection, and the auth routine is entered. However, it was possible to bypass the auth routine entirely with a string that did not match the stored folder byte-for-byte (two slashes rather than one), but still allowed Java (through the Windows API) to find and read the file. To solve this issue, Xerver should be normalizing it's inputted paths to a single standard separator character, rather than letting anything and everything through. This is fixed in my patch.
In addition to this vulnerability, the method of checking usernames and passwords that Xerver uses is insecure. Rather than looking up the username in the username/password file and then checking to see if the provided password matches the given password, Xerver loops through all the known passwords and, if it finds a match, allows us to log in with that username. This means that a.) we don't need to know a username and b.) we only have to guess the weakest password. Not good.
Null Byte Injection
The following two and a half vulnerabilities are due to a null byte injection vulnerability. My patch should fix these as well.
Full Source Disclosure
A classic source disclosure vulnerability, this one relies on a null byte injection vulnerability to trick Xerver into coughing up any accessible files in plain text. The trick relies on Java's handling of strings. When looking up the mime-type of the file, Xerver uses Java's find function to search for the last "." in the requested document string and pull out the file extension. If a null byte is injected in our string, Java (unlike C) treats it as any other character; it's simply a byte to be checked. However, when Java goes to open and read the file, it has to make an external API call which uses (you guessed it) C strings. This causes our original file to be read, but handled as the mime-type of our choosing. | `` GET /admin.phpx00.txt HTTP/1.1`` | The Xerver source indicates that at least some measures were taken to prevent this (%00 is interpreted as the end of the string), it does not take into account that a malicious client could simply inject a null byte directly into the string. To fix this, Xerver should obviously be checking for and removing null bytes from input.
Filetype Restriction Bypass
This vulnerability works exactly the same as the source disclosure, only the goal is to bypass restrictions on what filetypes are allowed to be served. By default, Xerver will serve you anything you request. However, you can explicitly set certain files, like ".exe" files, to not be accessible. If, for instance, someone configured Xerver to disallow exe files but not bat files, we could still send GET /test.exe0x00.bat (with the 0x00 encoded obviously), and Xerver would happily let us execute our command anyway, for the same reason it would serve us PHP files as text.
Minor Directory Transversal Issue
This problem was very strongly protected against (especially compared to the rest of the issues) because another researcher found this particular bug in an earlier version, and a decent patch was made. That being said, I was still able to list a directory above the root directory using the same null character injection technique used on the previous two bugs. This works because Xerver searches the string to find any occurrences of /../ , but if a null byte is injected between the .. and / it won't be detected, and the directory immediately above the root directory will be listed if directory listing is enabled.
Remote Code Execution
With these bugs (and the ones discovered by previous researchers) it is possible to get remote code execution on many Xerver installations. I have written a Metasploit module that can execute code on these systems; however I am delaying a bit before releasing it to a.) possibly polish/refine the attack more and b.) to give users time to fix their installations. To prevent code execution, do NOT share your root directory, do not make the administrative panel remotely accessible, and do not allow execution of exe or bat files. My patch will not solve this issue, as it is configuration specific.