Usually the web code and network architecture can’t be changed because “that phase of the project has completed”, or the app is from a third party and can’t be changed. So the safeguards we have left to work with are necessarily band-aids… things that can be applied to offer some protection that require little or no changes to the network and applications. Usually that means deploying a web application firewall.

I did a vulnerability assessment of one web app that had a PHP-based discussion forum. It allowed users to upload file attachments to postings and upload a profile photo so it would appear beside each message.

Of course, the application accepted anything at all for file uploads… scripts, executables, malicious PDF and MS Office files, GIFARs, you name it, and faithfully spit it back verbatim to every visitor of the site. For various reasons the code couldn’t be changed, so we had to invent a way to retrofit file upload sanitization. Good old suhosin to the rescue. The suhosin extension can be added to most PHP installations with no side effects, and has a handy optional setting suhosin.upload.verification_script. Point it to a script and all PHP file uploads can be checked server-wide, regardless of what checks (or lack thereof) the PHP apps do themselves.

The requirement

The client had to comply with a policy to check all uploads with a virus scanner. They were also concerned about malicious image uploads… the GIFAR issue was hot at the time, and we filled them in about image handling flaws pop up frequently in Windows. Malicious or revealing metadata in image files (e.g. comments, EXIF and IPTC) was also flagged as a concern.

Virus scanning was easily accomplished with ClamAV, but being certain that JPEGs were sanitized was trickier. After a bit of investigation we settled on simply converting images to an intermediary format, then converting back to JPEG.

It resulted in a minor loss in quality, but guaranteed the images viewed by other users were free of crafted bytes, metadata, appended data like GIFAR (which also works with JPEGs), and even most steganography.

The code

The suhosin.upload.verification_script can be written in any language. It must be executable by the web server process and print a ’1′ on standard output if the file is okay. Any other output causes the upload to fail.

The verification script is called immediately after a file is uploaded to PHP, but before the PHP app can call move_uploaded_file(). The script gets the temporary name of the uploaded file (same as returned by PHP’s $_FILES["file"]["name"] ) but no other info such as size or MIME type.

Our verification script scanned all uploads with clamdscan, then used a call to file to determine filetype. JPEGs were then run through GraphicsMagick to convert to BMP and back to JPEG format.

Why BMP? After some testing we determined that was the best available format that handles JPEG color ranges and doesn’t support metadata.

GraphicsMagick is a fork of the better-known ImageMagick that is faster and claims to have fewer bugs (it wouldn’t help to process potentially malicious files with a library that itself has buffer overflows). Apparently it’s the library used by Flikr.

Here’s a simplified version of the script:

#!/bin/sh
# EXAMPLE ONLY. NOT FOR PRODUCTION USE.
# Executable locations:
CLAMDSCAN=/usr/local/bin/clamdscan
LOGGER=/usr/bin/logger
FILE=/usr/bin/file
GM=/usr/bin/gm # GraphicsMagic
# Output file locations:
LOGFILE=/var/tmp/php_upload_check-$$.log
QUARANTINE_DIR=/var/tmp

$CLAMDSCAN --quiet --log=$LOGFILE $1
if [ $? -eq 0 ]
then
    # This example can only sanitize JPEG files, so try to
    # verify the file is a JPEG before mangling it:
    if [ `$FILE -bi $1` = 'image/jpeg' ]
    then
        # Convert to BMP then back to JPEG which should
        # remove all comments, EXIF, and IPTC metadata,
        # out-of-range bytes in the image stream, most stego,
        # and any appended payloads (e.g. GIFAR-style JAR
        # archives or regular ZIP files)
        $GM convert jpg:$1 bmp:- | gm convert bmp:- jpg:$1
    fi
    # No more tests. Tell Suhosin the file seems okay:
    echo 1
    rm -f $LOGFILE
    exit 0
fi

# File must not have passed, so preserve it and the log:
mv $1 $QUARANTINE_DIR

#Log the event to syslog:
$LOGGER -t php_upload_check -p authpriv.warn \
    "Malicious PHP upload. Scanlog in $LOGFILE. File in $QUARANTINE_DIR/$1"

# Print '0' to STDOUT to tell Suhosin the file seems bad:
echo 0

The above script logs bad file events to syslog and preserves the uploaded file and virus scan report so an administrator can troubleshoot problems and verify an attempted attacks.

It’s straightforward to use this method to retrofit  just about any file upload policy onto a PHP site. It could also be used to resize, rotate, and watermark images. One downside is that a suhosin upload scanner cannot return status messages to the original PHP application. Users will see their upload failed, but not why.

Obviously it’s better if the web application does validation of file uploads, but too often the only choice available is to use hacks like this.

Related posts:

• Hardening PHP servers with suhosin
• Core GRASP – SQL injection prevention for PHP
• Month of PHP bugs summary

It was grim. The talk (given by this guy) mainly focused on how business logic, passwords and encryption keys are being embedded into client-side Flash applications, under the mistaken assumption that compiled Flash is an impenetrable black box.

But as we’ve known for decades, everything client side can be tampered with. Flash in particular can be easily decompiled into original source code, often exposing all manner of vulnerabilities.

By now most web developers understand basic browser security issues like hidden fields aren’t and Javascript can be viewed and changed by the user. But switch to a client-side environment where the code is “compiled” like Java applets, Flash, MS Silverlight or Adobe AIR and many developers reset to a default mindset that seems to be:

1. The “compiled” code and data cannot be viewed or altered.
2. Communications between a “compiled” client and the server cannot be viewed or altered.
3. Only my client can communicate with the server and use it’s exposed APIs

It may be a shocking to learn, but even compiled C code can be decompiled with at least some fidelity to the original source. Bytecode compiled apps like Flash and  Java are much easier: flash apps can be returned to near-original source code with SWFScan, Java with Cavaj and others. And no need for fancy tools when plain text (e.g. embedded passwords) can be pulled from any binary using the good old Unix strings command.

Traffic between client and server is easily intercepted with Paros or WebScarab (yes, even when encrypted by SSL), and these tools are also great for mapping server-side APIs for which an attacker can write their own code to invoke the methods.

AJAX apps are not compiled, but widely-used optimizers like YUI compressor seem to lead to that “security through compiler” mindset. I even had a developer argue the sensitive code in their Javascript library was secure because it was “stored on the server” (as an external .js file).

It’s not just web apps though. I’ve seen the same assumptions in all fat client code, whether elderly Powerbuilder and Visual Basic apps or the latest .NET, C or C++. However, most of those are deployed in the semi-trusted environment of an organization’s intranet. Still vulnerable, but at least not exposed to the entire universe.

Is there something special about web development that prevents improvement? Sometime in 1998 I wrote Writing Security Web Applications and 11 years later the same mistakes are being made, both in regular web applications and “rich” ones.

Only now instead of passwords and encryption keys being stored in the clear in hidden form fields and cookies, they’re embedded in Flash, along with business logic talking directly to internet-exposed server APIs.

As I said, OWASP meetings are depressing.

No related posts.

At Blackhat this year Core Security released an interesting patch for the PHP source code called CORE GRASP that attempts to prevent SQL injection at the parser level. It uses data labeling to track input from untrusted sources then prevents it from reaching the SQL server.

This is similar to the taint mechanism Perl has used for years. Ruby and other languages provide a similar feature. In Perl with taint checking enabled, a variable receiving external data is labeled as “tainted” and prevented from being used with a list of potentially harmful operations: accessing the file system or network, running shell commands and so on. Any variable receiving content from a tainted variable also becomes tainted. To remove the taint label, a variable must be sanitized by filtering it though a search and replace regular expression. Perl doesn’t check that the filtering actually removes potentially malicious characters… just that the developer remembered to do so. Taint mode in Perl is more of a reminder to developers than a highly robust security mechanism.

Looking at the whitepaper, the technique used by GRASP goes much further than Perl taint. Every character in a variable receives a label, not just the entire variable. Untrusted data is not simply blocked from being sent to the SQL server… the characters are examined for known SQL metacharacters and allowed through if not in a list of known exploits. GRASP can also work the other way… database fields for internal use only can be labeled and data originating from them can be prevented from reaching the web browser.

Core describes GRASP as a prototype, not for use in production. Currently it is specific to one version of PHP and only looks for SQL injection attacks against MySQL, not Postgres or MS SQL. The whitepaper describes other attacks this technique could be used to mitigate (XSS, shell injection) but those are not detected by this prototype. On nice thing is that Core claims GRASP does work with Suhosin .

The technique used by GRASP sounds remarkably similar to the Precise Tainting paper published by researchers at the University of Virginia in 2005: labeling individual characters from untrusted input then checking for malicious content before passing to a vulnerable backend.

Identifying SQL injection inside the PHP engine should be more accurate than protocol-level filtering used by mod_security and other web application firewalls, though according to the paper the performance hit is a massive 30%. One day the PHP developers may even implement native taint checking… legendary SATAN and Postfix developer Wietse Venema said recently he’s working on an implementation. Unfortunately the PHP developers have a history of rejecting security improvements to PHP.

Related posts:

• Month of PHP bugs summary

Yet another reason not to trust Flash content and to run host-based firewalls on your intranet workstations and servers. With flaws like these and problems like DNS rebinding , code executed in browsers are no longer limited to accessing their origin server. We can retire the outdated concept of network perimeter.

It’s not practical to disable Flash, but if you use Firefox or another Mozilla browser, the FlashBlock extension at least lets you decide which Flash content your browser can execute.

Related posts:

• Major new flaw in Adobe Flash Player – Windows, Linux and Mac
• Remote exploit in Adobe Flash player
• Disarming Adobe PDF Viewer

VPN and other crypto product vendors do the same. They get away with this because to many people, crypto is still magical security dust.

But wait! Did you know you only have to buy the dust SSL certificate, not actually sprinkle it around install it on the server? Magic indeed!

I learned this recently when someone asked me to check out a little online store. They were about to make a purchase then noticed the credit card entry page began with “http://” and the SSL padlock icon was missing.

Not uncommon. Many mom-and-pop sites try to skip the cost of SSL certificates hoping customers either won’t notice or won’t mind. However, what was confusing about this unencrypted storefront was that it sported a large “Verified by GeoTrust” button.

You’ve seen these and similar assurance stickers from other SSL vendors (check out Geotrust’s front page for a live example). Clicking the button pops up a window showing the http URL, company name and the reassuring words “Site Security Confirmed”.

Now, it’s technically possible for a form to originate from an unencrypted URL then submit the data to an SSL URL. However, a quick look at the HTML of this order form revealed the “action=” went to the same unencrypted URL and there was javascript or other tricks involved… the form really was sending card numbers and other private info entirely in the clear. So how could this be “Security Confirmed”?

A technical person might expect an SSL verification function to check the http_referer to determine the originating site, verify the URL began with “https://”, then retrieve the certificate from the server, verify that it’s subject Common Name matches the URL and has not expired or been revoked. More thorough checks might include some simple automated auditing and portscans of the server, like “Hacker Safe“.

Too technical, it seems. It appears all this SSL vendor’s verification button does is:

1. Checks that the button is being displayed on the web site it says it is (using good old unspoofable DNS, of course).
2. Verify an SSL certificate has been sold to the web site and has not expired or been revoked.

The result is a site can be unencrypted and still have “site security confirmed”. I guess this means SSL is no longer “security dust”… it’s graduated to “security talisman”. Just possessing an SSL certificate is enough. No need to actually use it.

When we notified the site owners that their order-taking page was unencrypted, they argued that we were mistaken… previous customers had reported the same thing but the Geotrust button “confirmed everything was okay”.

It took some effort to convince them the button was lying. Later it turned out the site did have a valid certificate installed and ready to use, but their web developer had screwed up and used “http” instead of “https” in the shopping cart app and related URLs. A quick search and replace fixed the issue.

Having the Geotrust button actually reduced the security of this site. The owners trusted what the button said over the tell-tale lack of SSL indicators in their web browser. Probably many customers did the same: noticed the missing SSL then placed orders anyway after being reassured by the button. The situation could have gone on for years.

But what do you want for nothing? The verification button is provided free, right? Actually no… businesses must pay the SSL vendor extra to be able to use it on their sites.

Related posts:

• Web site trust certifications untrustworthy?
• High assurance SSL certificates
• DNS security talk

If you haven’t been following along, Jeff Forristal of SPI Dynamics has written an excellent summary of the Month of PHP Bugs on his blog. Well worth reading. He also recommends several compile-time flags and php.ini settings to disable high risk functions, including a couple settings that aren’t listed by phpinfo() that I wasn’t aware even existed.

However, as the Month of PHP Bugs has demonstrated, the design of PHP (and quality of most PHP code) is such that disabling specific functions and tweaking php.ini is far from being a complete solution. I strongly recommend also installing the Suhosin extensions, sitting your web servers behind an application layer filter such as mod_security, and of course continually monitoring activity on the network and servers.

Related posts:

• Hardening PHP servers with suhosin
• Port scanning with Adobe Flash
• Core GRASP – SQL injection prevention for PHP