Представьте, в один прекрасный день вы просыпаетесь и узнаете, что сегодня — День конституции Украины. И сообщают об этом не новости, а ваш собственный сайт, где вы и не думали размещать ничего подобного. За 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… До свидания!
Так мы сэкономили несколько сотен тысяч рублей для нашего клиента и получили невероятные эмоции от наблюдения за безуспешными попытками атакующих.
Приятно быть на светлой стороне и помогать клиентам отбиваться от разного рода мошенников и паразитов. Помимо экономии существенных сумм, подобные истории еще и здорово поднимают боевой дух команды.
Были ли у вас подобные истории? Буду рад увидеть их в комментариях!
