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

По мотивам «И так сойдёт… или как данные 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 и т.п. Общались — знаем.

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

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

FavoriteLoadingДобавить в избранное

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *