{"id":14286,"url":"\/distributions\/14286\/click?bit=1&hash=d1e315456c2550b969eff5276b8894057db7c9f3635d69a38d108a0d3b909097","title":"\u041f\u043e\u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043d\u0430\u0434 \u043a\u0440\u0443\u043f\u043d\u0435\u0439\u0448\u0438\u043c\u0438 \u0418\u0422-\u043f\u0440\u043e\u0435\u043a\u0442\u0430\u043c\u0438 \u0441\u0442\u0440\u0430\u043d\u044b","buttonText":"","imageUuid":""}

Подлые конкуренты, вымогатели и двойные агенты: как мы боролись с хакерскими атаками на клиентов

Представьте, в один прекрасный день вы просыпаетесь и узнаете, что сегодня — День Конституции Украины. И сообщают об этом не новости, а ваш собственный сайт, где вы и не думали размещать ничего подобного. За 9 лет управления студией разработки Code Pilots у меня накопилось несколько историй о кибербезопасности, которыми хочу поделиться с вами.

Сохраните пароли, это же так удобно!

Впервые задуматься об ИТ безопасности меня сподвигла ситуация в далеком 2007 году. Будучи фрилансером, я насохранял пароли в Total Commander (популярный в то время файловый менеджер для обновления сайтов), передал ноутбук новому владельцу и благополучно об этом забыл. Но спустя год несколько клиентов, с которыми я работал, были взломаны. Источник утечки, удалось определить почти сразу — новый владелец позвонил и пожаловался, что его компьютер был взломан. Это был хороший урок, так как избавлять сайты клиентов от нечисти пришлось не один день, и это было не самое приятное занятие. После того случая я сделал выводы и нашел куда более надежные места для хранения паролей.

Из большинства популярных программ пароли можно извлечь за пару кликов

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

Вывод первый: храните пароли в сберегательной кассе специальном менеджере паролей. Например, в бесплатном Keepass или в также облачном Bitwarden.

Вывод второй: лучше забыть про HTTP и FTP, особенно если вы работаете в публичных местах.

Я у мамы хакер

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

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

assert(@$_COOKIE[‘123’])

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

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

Кстати, это может касаться и вас: проверьте, что откроется, если дописать после адреса вашего сайта “/.git/config”? (пример - site.ru/.git/config). Если вы видите текст, а не страницу ошибки, дело плохо - весь исходный код вашего сайта можно скачать, а вместе с ним, возможно, получить и полный доступ к вашему сайту. В проведенном нами в 2020 году исследовании, около 7% сайтов имели эту неприятную уязвимость.

День конституции

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

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

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

Определив причину, мы закрыли уязвимость, вернули сайт к прежнему виду и написали подробный отчет клиенту. А заодно закрыли подобные уязвимости у всех клиентов Code Pilots.

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

Вывод первый: регулярно обновляйте ваше ПО.

Вывод второй: обязательно делайте регулярные бекапы в отдельную локацию. Хорошей практикой является сохранение последних 7 дней, 4х последних понедельников, 12 первых чисел каждого месяца. Это сведет к минимуму риск потери данных.

Хакер, который всех сдал

Чаще всего мы сталкиваемся с DDoS-атаками: когда к сайту делается так много запросов, что он не справляется с нагрузкой и перестает нормально работать.

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

Это и произошло с нашим клиентом: после того, как его сайт перестал работать, ему в Телеграм написал исполнитель атаки. С уникальным предложением: за $300 он не только прекратит атаку, но и сдаст своего заказчика, который (вот сюрприз) оказался непорядочным и не оплатил всю сумму.

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

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

Вывод второй: если у вас нет постоянной команды поддержки сайта, имейте наготове все доступы: к сайту, к серверу, к хостингу и к DNS. Это позволит не тратить драгоценное время на их поиски. Не забываем, что они должны храниться в менеджере паролей, а не в заметке на рабочем столе.

Анонимный доброжелатель

Еще одна разновидность уже описанной атаки, но в довольно оригинальной упаковке!

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

И все бы ничего, но даже поверхностный анализ ситуации показывает, что сайт не работает не из-за какой-то уязвимости, а из-за большого числа запросов — всё тот же DDoS!

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

— Ну что вы решили?

— Вот, у нас даже всё руководство собралось, чтобы убедиться, что проблема реальна. Можете показать, как сайт перестанет работать?

— Да, конечно, смотрите.(начинается шквал запросов к сайту, но… он выдерживает нагрузку!)

— …?! (замешательство на том конце провода)

— Кажется, это банальный DDoS… До свидания!

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

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

Были ли у вас подобные истории? Буду рад увидеть их в комментариях!

0
5 комментариев
Роман Потемкин

Подскажите, пожалуйста, что за сервис по защите от ddos?

Ответить
Развернуть ветку
Дмитрий Васильев
Автор

Наиболее популярный и почти бесплатный - CloudFlare
Защиту от DDoS также предлагает Selectel и в частности Qrator

Ответить
Развернуть ветку
Роман Потемкин

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

Ответить
Развернуть ветку
Дмитрий Васильев
Автор

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

Но у в CF есть Page Rules, которыми в зависимости от паттерна атаки зачастую можно серьезно снизить нагрузку. А всё что останется - добивать автоматическими скриптами уже на стороне сервера

Ответить
Развернуть ветку
Алексей Игнатов

Основная специализация CloudFlare не DDoS, а CDN, поэтому лучше использовать более специализированный ИБ-сервис, желательно отечественный. Хороший пример - CyberFlow (https://ddos-attacks.net/). Они используют несколько центров очистки трафика (для разных уровней OSI) и производят настройку под индивидуальные параметры клиента.

Ответить
Развернуть ветку
2 комментария
Раскрывать всегда