Operation n

Ad-Jacking part 1

Ad-Jacking is a term I coined for this article to categorise covert Ad hacking schemes. Why Ad-Jacking, well because thats effectively what we are doing.

Understanding this paper requires us to have a little understanding around
what types of Ads make us money. So firstly let us go over the current Ad
system; the following table attempts to categorise them:

CPC	cost-per-click	Money per click
CPM	cost-per-thousand	Money per thousand impressions
CPA	cost-per-action	Money per action (i.e. a sale, survey etc)
Affiliates	Affiliate programs	Custom - can involve any of the above and more.

We really want to focus on CPC and CPM (sometimes affiliates). Why? because its guaranteed $$$ per hit, and the attacker can guarantee hits, atleast when using XSS, which part 2 of this article will discuss.

Now some of you may already know where I am going with this; for those of you who haven’t guessed, we will be discussing weaknesses in the current Ad schemes and how they can be exploited. The ideas discussed here are by know means new, but I haven’t seen any article on the Internet that really brings these weak points home.

The topics covered include but are not limited to:

• Popups
• Redirects
• IFrames
• Images
• XSSing for Fun and Profit

popups

It makes sense that this paper should start with the most common and annoying
type of ad-jacking, popups! Why do hated webmasters do it? Now that we understand CPC and CPM the reason becomes obvious.

The proof of concept code below spawns a new window (popup) with dimensions we set. This is becoming more difficult to do as a number of web browsers support popup countermeasures, but this use to be the preferred method.

window.open('http://myadspaymentsite/url=sponsorlink&ref=12345',
'window name','attribute1,attribute2')

IFrames

An IFrame is basically a new web page that is loaded into a table in your current browser. This is really powerful for displaying content from other domains, unfortunately is can also be used nicely as an ad-jacking tool.

The following code will load up an invisible iframe to our sponsored page. The nice thing here
is that our evil attacker is now making money from your visit without the user knowing. Nice
for the user, but it completely defeats the point of having Ads.

<IFRAME NAME="iframe" SRC="http://myadspaymentsite/url=sponsorlink&ref=12345"
SCROLLING="AUTO" WIDTH="0px" HIEGHT="0px" FRAMEBORDER="0"
ALLOWTRANSPARENCY="yes">Your Browser Does not Support IFrames. Please
View the Site in a Different Browser to View this frame.
</IFRAME>

Redirects

We will cover this alot more when in part 2 of this article. With the possibilities of web 2.0 superworms there is alot of potential for badness here.

The following example simply redirects the user to an ad page upon rendering a page:

javascript:document.location = 'http://myadspaymentsite/url=sponsorlink&ref=12345';

Hidden Images

This has got to be one of the most effective methods mentioned thus far. Images allow cross-domain access, but they are also invisible in most cases by default; a web page is retrieved rather then an image, and therefore no result is ever displayed. This syntax is also dead simple:

<img src="http://myadspaymentsite/url=sponsorlink&ref=12345" alt="" />

XSS for Fun and Profit

I’ll see how this paper gets on, and decide weather to releasing part 2 of XSSing for Fun and Profit, which actually involves XSS :)

Summary

This paper looked at ways to embed malicious code into pages to trick and scam Ad applications. You can be sure Google and many others know all about these scams (atleast we hope they do) and most likely have fully-feeatured analytics to detect anomalies; however, I am curious just how effective they are at detecting this when we use the two R’s, RANDOM and REALISTIC.

It is also because of these weaknesses that CPC and CPM type Ads will be replaced in the future, Google and many others are moving more towards CPA as sales and surveys are more difficult to scam.

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

Table of Contents

1. Introduction
2. attribute_escape
3. wp_nonce
4. Summary
5. References

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

• http://markjaquith.wordpress.com/2006/06/02/wordpress-203-nonces/
• http://www.wordpress.com

[Hotlinking] is the placing of a linked object, often an image, from one site into a web page belonging to a second site. The second site is said to have an inline link to the site where the object is located. Inline linking is also known as hotlinking, leeching, direct linking or bandwidth theft - wikipedia

Hotlinking has been around for ages, and the attack vector shown in this paper is not new either; I merely take two known attacks and merge them to create a super dangerous client side attack that is persistent!

I released the Web Hacking 2.0 mindmap at the beginning of this year (2007). Someone from the Phoenix OWASP chapter liked the idea and posted it on owasp.org. I have no problem with this, although an email saying how and where my work was to be used would have been nice. Enough of that, the point here is to demonstrate the concept of exploiting hotlink trust relationships. This is the primary problem with hotlinking. Site 1 is creating bandwidth problems for Site 2, however, Site 2 is now in a position of trust (persistent).

Two possible attacks are as follows:

• Attack 1: We deface the page with a lovely picture of stallowned
• Attack 2: We setup a 302 or 304 redirect on my web server with the image filename used on the site who’s trust we are exploiting. The redirect exploits a CSRF vulnerability. Everytime the page is loaded, the CSRF attack is executed. This is now persistent! Everytime a user loads the Site 1, our CSRF attack is executed.

Lets take this concept a little further. If the site is hotlinking an object or iframe type, it is now possible to turn a reflective XSS attack into a persistent XSS attack. For this attack we require both a reflective XSS vulnerability and a hotlink. What’s really neat and tidy is that an attacker can display the correct object after exploitation, remaining completely invisible to the user.

Our malicious redirects are as follows:

Redirect 302 /a.jpg http://www.owasp.org/index.php?title=Special:Userlogout
&returnto=http://michaeldaw.org
OR
Redirect 302 ^/flashobj.swf$ http://site/trusted.html?<script>alert(1)
</script>

This attack concept is a security catastrophe especially when taking Web 2.0 which is designed around this form of trust.

In summary, don’t hotlink. Rather download the file onto your local server, although with Web 2.0, this will become increasingly difficult.

Web servers can enable hotlinking protection to prevent this; however, since alot of browsers now restrict the referrer field, this security method will not really help.

Thanks to pdp (architect) for allowing me to bounce ideas off him.

References:

• XSS IMG CSRF_2

This paper includes some of my thoughts (’request for comments’) regarding minimizing the affects of client-side related browser attacks using the Trusted Computing Solution. It includes some of my initial thoughts.

Restrictions & Limitations: The semantic web is a security nightmare and certainly will not agree with these ideas. Right lets get on with it..brainstorming…

As always with security, our attempt here is not to solve every problem but rather to mitigate and complicate matters for the attacker, thus, discouraging these attacks.

Trusted Browser Security Model (TBSM):

In case your wondering or googling for this name, I made it up for the purpose of this blog entry.

TBSM for starters works towards 3 goals:

• Defines supported Client-Side technologies (i.e. JavaScript)
• Defines trusted 3rd party applications (i.e. Adobe, Quicktime)
• Defines cross-site access on both the client-side and more logically on the server-side.

In application:

Basic idea of how this works:

1. Both the client and server have XML defined security rules. These rules include what browser functionality, and 3rd party applications will be allowed to communicate with our currently selected domain name. Furthermore, we may define cross-site policies which allow us to allow or restrict which sites may be accessed from our current location.
2. The files are signed using TPM and exchanged with the client (i.e. SSL-type negotiation).
3. If the security rules are met on both sides the client is permitted to access the site. This means the client’s set of security rules are met, and the server-side security rules are adopted for the duration of the visit.

Note: Steps 2&3 can quite easily be done at the browser level without the requirement of the TPM.

Simplified:

Like any firewall, both simplified and complex rulesets exist. The TBSM idea is a shared access control list between the client and server. We pre-determine what is allowed for the duration of our session. At some point TBSM can be expanded to stateful application inspection, permitting only specific functions for browser langauges such as JavaScript.

Our major challenge at the moment is that the browser world is like the pre-firewall days. Our default rule is to ACCEPT just about anything. Such an implementation would have been to far fetching before, but with TPM now being implemented as a standard, I think this area has potential to be expanded into the browser security frontier.

Implementing this model will mitigate XSS, CSRF and client-side vulnerabilities (i.e. Universal PDF vulnerability). This will also greatly mitigate AJAX worms utilising Cross-Site vulnerabilities. With the future of TPM, we can have so much more control over what we allow and don’t allow. We can deny access by country, city or even processor type if we really wanted :)

Is it just me or is it cold in the security room? Has anyone noticed that the security community is having a hard time letting go of “traditional” vulnerabilities and welcoming the new? I am not saying that *Overflows, Format String vuls etc are finished, in fact I think they will be around for some time. What I am saying is that Web 2.0 is the “new order” on the net. Rich Internet Applications (applications that support the same features as a desktop application) are becoming more and more popular (i.e. Adobe’s Flex 2 RIA framework) and the web is growing with a plethora of development possibilities.

What does this mean? It means a revamp and upgrade of “traditional” hacking terminology. For example, the term “Backdooring” traditionally means: “… a method of bypassing normal authentication or obtaining remote access/remote support to a computer, while intended to remain hidden to casual inspection. The backdoor may take the form of an installed program (e.g., Back Orifice) or could be a modification to a legitimate program.” - WIKIPedia:Backdoor

So we embed malicious code into a Flash, PDF, DOM, HTML, Quicktime etc. Can this code be used to “bypass normal authentication?”, absolutely, can it be “hidden from casual inspection”, certainly.

I think last year we saw alot of exploitation of the “low-hanging” fruit. Why is this possible in the first place? because no one has cared until now. We have made a good start but I fear we only scratching the surface when it comes to Web 2.0 Hacking.