I chose to write up my account of research and discovery for Flowerfire's Sawmill 5.0.21 package as I feel it was the most interesting and more importantly most fun of all my exploits. <can you say run on sentence?> I actually happend on this software by chance, I was consulting for a small company that asked me to research some web log analysis software. They were looking for something that provided very fine grained results, as a startup web hits were very important.

I naturally did a web search for web log analyzer and turned up a number of tools, none of which I felt was a good match for the requirements. I downloaded the Sawmill package, and starting reading its about information. I was intriuged that it could be run as a standalone server or a cgi. I was impressed with the amount of analisys it provided with your standard apache weblogs. I then thought well if this is run off a webserver it had better be programmed with security in mind. I better audit it.

When attacking software, you have to choose attack vectors, think about what you want to accomplish. How can I manipulate this program to do what it isnt supposed to do? or How can I get features of this software product to give me more than what they are designed to? The best way to do this is manipulate user input. Your objective in this case is attempt to glean information using this software package about the host on which it is running. So I setup a test network on an isolated hub.

I setup a target, running ssh, apache, Sawmill and a seperate host to attack from running FreeBSD. First I played with the software I was attempting to audit, getting familar with its options and interface.  Then I started to think of attack scenarios, what if's really. What if instead of X I put in Y? What if instead of specifiying the configuration file I use another? outside of Sawmills work directory? The old .. bug. So I gave it a whirl.

I noticed while configuring Sawmill that it specifies its file name in the URL, by manipulating the file specified, you could read the contents of other files on the system. If Sawmill is running as root, you could read root owned file like /etc/shadow.

http://target-domain:8987/sawmill?rfcf+%22/etc/passwd%22+spbn+1,1,21,1,1,1,1,1,1,1,1,1+3

Well this is a common programming error, and not very interesting. What was more interesting was the fact that it could be used to read the contents of Sawmills password file. The file that stored the cyphertext for the administrator account.

The following :

http://target-domain:8987/sawmill?rfcf+"SawmillInfo/SawmillPassword"

would produce the cyphertext of the administrators password file.

The real fun for me was after I was able to pull up the sawmill cypher text, it looked simple. It didnt look like the hash output of crypt(), it looked like a home made cypher. I decided to see if I could reverse engineer the algorithm used to generate the cyphertext, at least it might be cyphertext. I did what any amateur cryptographer would do since I had the algorithm, plain text and cyphertext. I used an adaptive-chosen-plain text attack. This is where plain text is submitted to the algorithm and based on what is returned modified to provide more insight as to what calculations the algorithm is performing to transform plain text to cypher text.

After a few rounds of this it was clear that this was a monoalphabetic substition cypher. Where each letter of the alphabet is subsituted with either a letter, number or other character. This sounds harder then it is, all this consisted of (since this cypher was so simple) was submitting a as a password, checking the cyphertext output (in this case it was "=") then b as a password, checking the cyphertext output (in this case it was "G") and so on and so on. After getting to c, I typed in defghijklmnopqrstuvwxyz. Which spit out the rest of the key used to create the cyphertext. There was an even quicker way to do this, by doing a "strings" on the binary I was able to see the cypher alphabet hardcoded in to the application.

So a quick C program and I had a decoder. With these two vulnerabilties I was able to grab the password file for the Sawmill app, decrypt it and reconfigure the application to do whatever I wanted. Say instead of /var/log/httpd/apache_log as a log file to look at, I could use /etc/passwd. This would pretty much give you a jarbled but usable user list, and if the system lacked shadow utils the crypt hashes for all accounts.  

This paper is a very basic introduction to software auditing, it is intended to give the reader an insight as to the thought process when evaluating security. In a nutshell, never trust user input to be what you expect. Assume the user is malicious and attempting to abuse your trust.

References:

http://www.securityfocus.com/bid/1402

http://www.securityfocus.com/bid/1403

Further Reading:

http://mixter.void.ru/vulns.html

http://mixter.void.ru/coding.txt