И так сойдёт… или Дыра как средство защиты

По мотивам "И так сойдёт… или как данные 14 миллионов россиян оказались у меня в руках"...

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

И чтобы расставить все точки над E, — я вовсе не пытаюсь оценить или как-то обелить "ответственные" лица, что с одной, что с другой стороны.

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

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

Например прочитав "Утащил базу весом 5 Гб… сколько времени это качалось. Вы думаете, кто-то заметил?" я лишь усмехнулся и продолжил чтение (ибо ИМХО некоторое преувеличение допускается в такого рода статьях).

Хотя автор и сам признал что он немного лгунишка апдейтом в конце статьи.

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

Теперь почему это очевидно/вероятно (даже не принимая другие типовые ограничения во внимание):

1. Если прогуляться на сервер, то сразу увидим связку nginx/1.1.9 * PHP/5.3.10 (скорее всего fpm, но не суть, практически также оно будет себя вести и при проксировании к апачу).
2. Если вспомнить про то, что дампить можно только из инъекций, то можно грубо предположить как-оно все доберется до слоя представления и/или слоя формирования html-страницы.
3. А если вспомнить про то, как обычно происходит общение nginx и того же пых-fpm (который отправит заголовок с первым байтом после первого flush из буфера), то можно вспомнить опции типа fastcgi_read_timeout (который по умолчанию 60s и его если и меняют то для специальных location/случаев), preread_timeout и иже с ним, а также пыховый max_execution_time (по умолчанию 30s), request_terminate_timeout и т.д. и т.п.

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

То не факт, но все равно очень сомнительно. Хотя… пусть это будет "подсказка" в качестве отговорки NoraQ когда оне придут с паяльником в случае непредвиденных вопросов.

Ну да статья не об этом, поэтому допустим…
Итак подходим к самому главному.
К ответу на вопрос "Вы думаете, кто-то заметил?".

Попробую встречным вопросом: А с чего вы сразу решили, что никто не заметил?
С чего вы решили, что вам отдавали "данные" с реального банка данных?
И наконец, может ли быть так, что кто-то, где-то, что-то оставил "приоткрытым" нарочно?

Заметьте я не утверждаю что оно так. То просто мысли вслух.

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

Названий очень много и они зависят от применения в конкретном случае, но у англоязычных коллег нередко слышал обобщающие аббревиатуры IPF (от intentional pseudo flaws) и ITD (от intentional trap doors), означающие одно и то же, а именно, намеренно оставленные псевдо-изъяны или специальные дыры в защите, играющие роль ловушки для атакующего.

Кроме нескольких очевидных недостатков система безопасности, позволяющая подобные "шалости", имеет множество достоинств:

• позволяет администратору безопасности осуществлять мониторинг поведения атакующего, сбор и анализ средств и способов атаки;
• помогает выявить потенциальные риски, а также действующие дыры в безопасности системы;
• позволяет защищающейся стороне направлять действия нападающего в нужное русло, увести атаку на нужный менее "засекреченый" уровень, отдать менее ценный "ресурс" и т.д. (тем самым отодвинуть вектор атаки от настоящей системы);
• нередко отвлекает захватчика от поиска настоящих (существующих) уязвимостей;
• позволяет контролировать процесс защиты, например осуществлять контролируемый "сброс" информации ("скармливать" конкурентам заведомо ложную, или неинтересную информацию);
• и last but not least, она позволяет безопаснику держать себя в тонусе (повышение квалификации, навыков, умений, и т.д.)

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

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

Ну оно может и неплохо (если в меру), только он был не совсем прав — есть такой способ на самом деле — ничто так не повышает квалификацию, как интерактивный ITD с пропущенным через него десятком хороших пентестеров и прочих (доморощенных и не очень) атакующих всех мастей. Очень познавательно, доложу я вам...

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

Вернемся к статье о "дырах" в ФРДО...

ITD на самом деле вовсе не ограничивается "играми" с нападающим. Например тут, если почитать цели "Формирование и ведение ФРДО об образовании и (или) о квалификации, документах об обучении", то можно найти там следующее:

Ликвидация оборота поддельных документов государственного образца об образовании

Каким еще другим способом можно настолько эффективно бороться с оборотом поддельных документов, кроме как, используя IPF/ITD, собрать базу возможных кандидатов на пилку дров в каком-нибудь холодном и особенно удаленном уголке России.

Не пентестеров, вовсе нет… А к примеру, людей пытающихся почем зря эксплуатировать инъекцию для инсёрта новых документов.

Я, на месте "реализатора" (или организатора) оферты, вероятно воспользовался бы подходящим случаем и возможностью, и именно так и поступил бы.

Чем не подходящий инструмент для таких целей? И при наличии некоторого опыта, такое можно довольно легко а главное незаметно реализовать.

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

Я же, в качестве примеров "реализации" ITD, хотел здесь поведать о собственном опыте и как пентестера, попавшегося однажды на эту удочку (а может и не один раз, не факт), и в качестве безопасника, уже организовывавшего подобные системы (как ради интереса, так и enterprise-level).
С морским боем и мадамами С логами атак, протоколами мониторинга и всеми делами.
Но… Статья и так разрослась. Да и думаю в качестве вступления этого будет пока достаточно.
Попробую черкнуть позже, если статья наберет необходимое число плюсов интересно.
Время, всегда время… будь оно неладно...

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

Ну и снова возвращаясь к теме ФРДО...

[UPD] Для тех кто в танке...
Статья вовсе не про то что там было. А про то что в теории возможно (в идеальном мире если хотите)…
Т.е. то всё лирика, но с привязкой к конкретному инциденту, такой сценарий я например не могу исключить.
И не нужно про то, что это так сложно, дорого (и вообще на фиг никому не надо), ладно?...

Вот конкретный дешевый рабочий вариант (простейший ибо на коленке):

• ставим фильтр выявляющий попытки sql-инъекции;
• пробрасываем запросы от него (да хоть посредством nginx) в "песочницу";
• там пишем простейший триггер на изменения в таблице (со сливом в лог);
• пишем обработчик лога (разбор, сумматор по IP, оформление в красивую табличку);
• анализ лога раз в день на мыло товарищу майору.

Вопрос не в том было оно так или нет, а в том в теории могло бы быть, но нашему доморощенному хакеру оно в голову в принципе не пришло. И он просто вывесил это на стену.
Я сам далеко не белый и уж точно не пушистый, но вот так это не делается, от слова совсем!
[/UPD]

И пожалуйста, вот только не надо здесь про то, что "Они там все тупые/ленивые/неумехи". Правда, не надо… Оно, во первых, вовсе не про то.

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

Ну и вокруг много таких же профессионалов, не принадлежащих тем определенным структурам, но иногда готовых помочь (и за интерес и за идею и т.д.).

Ответом же на вопрос "Почему все-таки в итоге залатали" может быть: ну ажиотаж же. И… А вы уверены, что все закрыли? И что навсегда?...