Category: Papers

coffee-684069_640

How to Make Electronic Cigarette Juice

If you want to enjoy your desired flavors in vaping community, here is how to make e-juice of your choice. It’s not a difficult task, and you will feel like you are making your favorite cookies. Here we go.

Checklist

  • Diluted Nicotine
  • PG/VG (Propylene Glycol/Vegetable Glycerin)
  • Flavors
  • Small bottles to fill the e-liquid
  • Syringes
  • A pair of gloves

Method

  • First, you should determine how strong nicotine you require in the electronic cigarette? If you want a strong e-cigarette, you need to prepare 50mL of 8mg/mL e-juice. So, multiply 50 by 8 to get 400mg of the required strength of nicotine. If you can’t find or your authorities don’t allow you to buy nicotine then simple order one from  and save money and energy both.
  • Now put on your gloves. Put the required quantity of nicotine in a bottle by using a syringe. You are going to prepare 8mg/mL e-juice.
  • Now add your desired flavor to the diluted nicotine to give it a favorable taste. You can add two or more flavors too. But make sure you are using only 10% of flavor dilution only. For example, if you want to prepare 50mL e-juice, you need only 5mL flavor dilution. You need to use a new syringe for this purpose. Just add the dilution into a clean syringe and drip it into the bottle where it will be mixed to nicotine.
  • Now it’s time to add the VG into the bottle. You need to put 29mLs vegetable glycerin into the jar. For this purpose, you need to use another clean syringe. You should be careful while pouring the VG into the bottle of diluted nicotine and flavors. Do not pour it as a whole. Pour 1/4th quantity and wait for a while. Then pour another 1/4th and wait for a couple of seconds again. In this way put the entire solution into the bottle.
  • Now you need to put the cap on the bottle neck and shake the mixture well to disperse it. You should shake it at least for five minutes for an evenly mixing.
  • Now it’s time to fill up your cylinders flavor into the tank and vape to enjoy its taste.

Precaution: You should be very careful while selecting the bottles to prepare e-liquid. Always choose the same sized and shaped bottles. Pour an equal quantity of diluted nicotine in all bottles. If you put all three things without measurement, it may not give you the required taste. So, the measurement is an important factor in preparing electronic cigarette juice.

Hotlinks and Persistent CSRF

[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:

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

Powered by WordPress & Theme by Anders Norén