Исследователи перехватили контроль над ботнетом Torpig и ковыряли его 10 дней, пока владелцы не накатили обновление и не вернули управление себе. За это время стало понятно какого вида информацию он собирает, как он это делает, как защищается от перехвата управления и на какое поведение юзеров он рассчитан.

Авторы утверждают что Torpig это одно из самых продвинутых crimeware на сегодняшний день. У него самая лучшая программная архитектура, самые остроумные способы воровства данных, самая лучшая топология управления. Также Torpig наносит самый большой финансовый ущерб.
Оценка экономической эффективности $3-300 млн в год. Из упражнений спамеров, ботнеты похоже становятся серьёзным бизнесом.

Работает это всё следующим образом

Инсталяция

Взламываются популярные сайты и вставляется ссылка на специальный JavaScript. Браузер скачивает и выполняет вредоносный JavaScript, код в котором пытается залинковать свою dll в проводник (explorer.exe) используя известные уязвимости самого браузера, его плагинов или ActiveX объектов. Уязвимости перебираются по кругу пока одна из них не сработает. Дальше все операции выполняются как будто бы самим explorer.exe – вполне себе уважаемым процессом. Теперь загружается драйвер ядра, который подменяет оригинальный disk.sys на себя и затирает Master Boot Record (MBR)
Всё, шаг №1 выполнен – руткит Mebroot поставлен. Фокус тут в том, что после перезагрузки Mebroot выполняется самым первым, раньше чем загрузится OS и остается практически невидимым для антивирусного ПО.

Сам по себе Mebroot ничего плохого не делает, но это только платформа для других модулей которые и делают всяческие гадости. Итак, сразу после перезагрузки, каждые два часа Mebroot соединятеся с Mebroot C&C server и качает модули, например Torpig. Все соединения шифруются. Теперь и шаг №2 выполнен – Torpig установлен.

Torpig вставляет линкует свою dll в Service Control Manager (services.exe), проводник и 29 другиз популярных программ, например браузеры – IE, Firefox, Opera, FTP клиенты – CuteFTP, LeechFTP, e-mail клиенты – Thunderbird, Outlook, Eudora, мессенжеры – Skype, ICQ и такое прочее. Теперь Torpig может просматривать все данные которые эти программы манипулируют, выделять интересные куски, например логины с паролями. Каждые 20 минут Torpig закачивает всё что он там насобирал на сервер.

Топология управления

Тут интересное архитектурное решение, если адрес этого C&C сервера известен и более менее постоянен, то его легко можно отфильтровать тем самым нейтрализовав утечку данных. Исторически ботнеты это делают следующим образом – имя домена статично и не меняется, но очень часто меняются IP серверов куда замаплена DNS запись – это делает блокировку по IP не эффективной. Недостаток тут очевиден – статическое доменное имя. Mebroor и Torpig вместо этого генерируют доменные имена по специальному алгоритму, если домен заблокирован, не отвечает на запросы по ботнетовскому протоколу или не существует – генерируется следующее имя и так до победного конца.
Тут надо помнить, что регистрация домена стоит денег, но владельцам ботнета нет необходимости регистрировать все имена – достаточно удерживать контроль над хотя бы одним из доменов который сгенерируют боты. В этой силе кроется и слабость. Если алгоритм известен и предсказуем, нужно зарегистрировать следующий домен которому подчинится ботнет.

Именно так авторы статьи и перехватили управление. На 10 дней.

К чести оригинальных программистов ботнета следует заметить, что эти 10 дней не прошли даром. Они поменяли алгоритм генерации доменных имен, усложнили и внесли недетерменизм. Это сразу сделало перехват управления экономически не выгодным, например новая версия Conficker генерирует 50,000 доменных имен в день, если все их регистрировать это выливается в большие расходы – $91 – $182 млн.

Остроумные способы воровства данных

Тут старый добрый фишинг поднятый на новый уровень. В своём конфигурационном файле Torpig читает имена банковских сайтов. Если юзер посещает такой сайт, Torpig вставляет HTML форму прямо в страницу сайта. Это происходит прямо в DOM-e браузера. Определить это очень трудно – URL сайта верный, стили и картинки соблюдены, и даже SSL тут не спасёт. Все сертификаты верны. Пользователя просят якобы подтвердить свою личность введя номер карты, налоговый номер и прочее.

За 10 дней, Torpig наворовал 300ооо логинов с паролями, 1600 номеров кредитных карт и 8300 логинов в онлайн банкинг. Всего в забеге участвовало 180ооо инфицированных хостов.

Саму цетовую схему взял тут. Недостаток оригинального файла – это полный export всего подряд, а нужно всего только цвета поменять.

Объясняет, как latency коррелирует с прибылью, почему сайты вообще медленно грузятся в браузере и рассказывает как это можно исправить. Утверждает он следующие интересные вещи:

Влияние latency на доход

Google: +500 ms  -20% traffic
Yahoo: +400 ms  -5-9% full-page traffic
Amazon: +100 ms  -1% sales

На конференции Velocity 2009 докладчикам от  AOL, Google, Microsoft и Shopzilla задали вопрос “почему это важно – уделять внимание производительности?”

• Microsof (Bing): увеличение времени отклика на 2 секунды это -1,8% запрос/пользователь и -4,3% дохода с пользователя
• Google: увеличение времени отклика на 400 ms это -0,59% запрос/пользователь
• AOL: 25% падение количества page hits при удвоении времени отклика
• Shopzilla: Ускорение с 7секунд до 2х дало +25% page hits, +7-12%  дохода и 50% экономия на железе

Почему сайты медленно грузятся?

Согласно Souder-а причины могут быть следующие:

• Тормозит back-end
• Тормозит front-end
• Тормозит интернет

Steve говорит, что 80-90% всего времени тратится на front-end и соответсвенно оптимизировать надо как раз эту часть в первую очередь. И дешевле всего и эффект виднее.

Как исправить

Вот его 14 правил:

1. Делать меньше HTTP запросов
2. Использовать CDN
3. Не забыть про Expires
4. Использовать Gzip компрессию
5. Все стили на верх страницы
6. Все скрипты – вниз
7. Избегать CSS expressions
8. Выносить JS и CSS во внешние файлы
9. Уменьшать DNS lookups
10. Сжимать JS
11. Избегать redirect-ов
12. Выкинуть повторяющийся JS
13. Не забыть про ETags
14. Сделать AJAX контент cacheable

Сама презентация поясняет основные приёмы ускорения загрузки страниц:

• сначала грузим только то, что надо для отображения станицы, затем всё остальное
• 6 способов загрузить JS и чем они отличаются
  XHR Eval, XHR Injection, JS in Iframe, JS DOM Element, JS Defer, document.write Script Tag
• как прятать от пользователя что мы ещё не все загрузили (индикатор загрузки в браузерах)
• несколько неблокирующих способов грузить JS
• способы вызова/инициализации JS со страницы, он называет это “coupling techniques”
  hardcoded callback, window onload, timer, degrading script tags, script onload
• какие домены лишние, а какие наоборот надо добавить в round-robin DNS
• почему для статики HTTP 1.0 лучше чем HTTP 1.1
• фокусы с flush() на разных языках
• эффективные и не эффективные CSS

Область практической применимости очевидна и огромна. “Deployed Software” это коммерческий софт. Утверждается, что лучше всего работает в кластерах, уязвимости обнаруженные на одном из хостов, автоматически накатываются на все остальные.

Идея такова:
это самое “Deployed Software” постоянно мониторится на подозрительную активность, например переполнение буферов, подозрительные передачи управления и прочее некорректное поведение. Это само по себе не новость, обычно после обнаружения такой активности приложение прерывается, при повторении – блокируется.

Тут на самом деле две проблемы:

• Если система high availability – ни о каком прерывании или блокировках не может быть и речи.
• Скорость латания дыр в коммерческом софте не велика – буквально через месяц программисты выпускают патч.

Новость тут в том, что ClearView, так называется система, обещает чинить баги и устранять уязвимости в реальном времени без рестартов и человеческого вмешательства.

ClearView сначала собирает статистику поведения во время нормального выполнения, они называют это “инвариантами выполнения”, затем отслеживает активность, при обнаружении подозрений автоматически патчит бинарный код пытаясь восстановить “инварианты выполнения”. Умеет сама тестировать различные варианты исправлений, накатывать и откатывать заплатки. Т.е. фактически пытаться держать систему в устойчивом состоянии, фильтруя input или блокируя и исправляя код.

P.S.
Ещё два шага и программы будут писать сами себя.

Жили были item-ы и было у них sequential numeric id.

То, что оно sequential – это тяжелое наследие царского режима, потом пришли большевики, но ничего сделать было уже нельзя.

#0

И вот, при Николае-батюшке, было это autoincrement поле в MS SQL, item-ы получали id при вставке и никто горя не знал. Очевидно для того, что бы узнать это id на клиенте надо вставлять item-ы один за другим.

#1

Нагрузка возросла – власть поменялась, хостов баз данных стало больше одного, генерацию вынесли в отдельную таблицу. Простой инкремент. Продолжали вставлять один за другим.

#2

Нагрузка возросла – сделали вставку item-ов сразу пачками, а генерацию соответсвенно тоже поменяли, что бы генерировать сразу на всю пачку за один запрос. Стандартная hi-lo процедура (см ниже). Скажем, если вставляется 10 записей – один запрос на генерацию 10 ids.

#3

Нагрузка возросла – сделали пре-генерацию id наперёд блоками и кеширование этого блока на клиенте. Скажем, если вставляется 10 записей – один запрос на генерацию 1000 ids. 10 используются сразу, а 990 ждут следующего раза.

При порядка 700 витках (threads), которые всё время пишут в базу, эффект поразительный.

А вот если бы сесть и подумать, можно было бы сразу с последнего пункта начать…

hi-lo cхема выглядит так:

Таблица в БД

CREATE TABLE IDTable(
TableName varchar(255) NOT NULL,
NextID bigint NOT NULL,
CONSTRAINT IDTable1_PK PRIMARY KEY CLUSTERED( TableName ASC)

SQL запрос на генерацию примерно так

DECLARE @LocalTempTable  table(id int)
DECLARE @NEXTID INT
DECLARE @CNT INT

BEGIN TRAN
SELECT @NEXTID = (SELECT NextID FROM IDTable WITH (UPDLOCK) WHERE TableName = @@TABLENAME)
SET @CNT = 0
WHILE(@CNT < @@COUNT)
BEGIN
INSERT INTO @LocalTempTable(id) VALUES(@NEXTID + @CNT)
SET @CNT = @CNT + 1
END
UPDATE IDTable WITH (UPDLOCK) SET NextID = @NEXTID+@CNT WHERE TableName = @@TABLENAME
COMMIT
SELECT id FROM @LocalTempTable

Где TABLENAME это имя последовательности, а COUNT это размер пачки.

Самый интересный фокус тут это SELECT … WITH (UPDLOCK). Клиенты делают запросы указывая размер пачки, а потом либо тратят ее всё как в случае #2 либо кешируют часть про запас, как в случае #3.

Некоторые размер пачки хранят прямо в таблице, отсюда и название. У этого подхода есть одно достоинство – можно централизованно управлять сколько ID создать. Но это же одновременно и недостаток – часто нужно здесь создать1000 штук, а тут только 10.

Вот тут есть не плохой обзор доступных способов получения ID

Обычные распределённые системы, RDBMS и J2EE контейнеры, целостность ставят во главу угла. Все эти фокусы с блокировками и распределенными транзакциями даются дорогой ценой. Эта цену большие распределенные системы платить не готовы, им нужно прежде всего availability. Поэтому Google, Amazon и некоторые другие крупные компании построили свои собственные инфраструктуры.

Werner Vogels, Amazon VP & CTO, популярно объясняет почему двух фазный коммит это плохой выбор если нужно строить scalable систему. Он ещё, ведет блог All things Distribtued для тех кому интересно.

Для того что бы система расширялась нужны асинхронные, stateless сервисы, а целостность приходится компенсировать сложными согласованиями-компенсациями в случае ошибок. Ну и конечно, модель данных оказывает существенное влияние на производительность. Чем проще – тем быстрее. Тут можно вспомнить про Dynamo от Amazon и MapReduce/BigTables от Google.

CAP Theorem-а утверждает, что система может удовлетворять не более двум требованиям из трех: целостность (consistency), доступность (availability) и терпимость к разделению (partition tolerance).

Где:
целостность (consistency) – гарантирует, что все клиенты всегда прочтут одинаковые данные, в не зависимости к какому узлу в кластере они обратились. Операция записи атомарная для всех узлов.

доступность (availability) – гарантирует, что в в случае любого (разумного) отказа, клиенты все равно смогут получить доступ к копии их данных.

терпимость к разделению (partition tolerance) – гарантирует, что система остается работоспособной даже если авария сети приведет к образованию двух или более под-кластеров.

У этой теореме существует формальное доказательство. Работа 2002 года, ссылается на публикации конца 80-х начала 90-х.

«Вы — руководитель проекта, который начинается с завтрашнего дня и заканчивается ровно через год. Все планы утверждены, команда подобрана, роли определены. И вдруг… Становятся известны результаты проведенного маркетингового исследования, которые говорят о том, что конкурирующая компания планирует выпуск такого же продукта с той же функциональностью, но месяцем раньше. Ваш топ-менеджмент настаивает на завершении проекта тремя месяцами раньше.»
Из ограничений: нельзя уменьшать функциональность и качество, увеличивать объём ресурсов и стоимость.

Что должно сразу приходить в голову хорошему руководителю проекта?
Ему должны сразу приходить идеи и идеи во множестве.
Например

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

Или вот

1) вторым быть проще (не помню, где читал)
2) вы не уточняете, увеличивать стоимость чего нельзя. если речь идет только о разработке, то можно увеличить маркетинговый бюджет
3) есть утопические варианты вроде саботажа =)
4) группировка функциональности и запуск «облегченной» версси продукта за 6 месяцев, и выпуск полной за 12.

Отсюда

The law of big numbers insures that all probabilities becomes certanties.

Очень удобно, никаких дополнительных программ, только браузер. Перед инсталляцией нужно не забыть поставить PHP development module

apt-get install php5-dev

А потом обернуть нужный код в

xhprof_enable();

<some code is here>

$xhprof_data = xhprof_disable();

и готово.

Я для удобства обернул вообще все вызовы, и отдавал ссылку на страницу с собранной статистикой прямо в HTTP header. Выглядело вот так

// start profiling
xhprof_enable();

<some code is here>

// stop profiler
$xhprof_data = xhprof_disable();
include_once $XHPROF_ROOT . "/root/xhprof/xhprof-0.9.1/xhprof_lib/utils/xhprof_lib.php";
include_once $XHPROF_ROOT . "/root/xhprof/xhprof-0.9.1/xhprof_lib/utils/xhprof_runs.php";
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_foo");
header("x-company-name-profile: http://xhprof.company-name.com/index.php?run=$run_id&amp;source=xhprof_foo");

xhprof.company-name.com прописал в hosts на своём компьютере. А на сервере добавил в конфигурацию Apache виртуальный хост

<virtualHost *:80>
    ServerName xhprof.company-name.com
    DocumentRoot /root/xhprof/xhprof-0.9.1/hprof_html
    <directory /root/xhprof/xhprof-0.9.1/hprof_html>
        AllowOverride All
    </directory>
</virtualHost>

Любопытно конечно сравнить с другим профайлером – XDebug